Pull to refresh
0

Особенности применения Scrum в заказной разработке

Reading time 3 min
Views 16K
В этой статье я расскажу об особенностях Scrum в заказной разработке, которая отличается от «тепличных» условий внутренней разработки. Можно ли применять Scrum в условиях рынка и на что надо обратить внимание прежде всего. Добро пожаловать под кат и в комментарии.

Как продать Scrum заказчику?

Первый вопрос, который обычно возникает, это «Как продать Scrum заказчику?», ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:
  • каждые две недели получать новый функционал, который можно попробовать и выпустить на рынок для заработка денег,
  • каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО,
  • регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта;

Второй вопрос, который появляется сразу после первого: «Как отразить процесс в контракте?». Самым лучшим вариантом здесь будет заключение контракта типа «Время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но надо заметить, что при таком подходе и риски перекладываются на него. Еще отмечу, что при таком подходе резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.

Традиционным для нашей страны является подход по заключению контрактов с фиксированной стоимостью (Fixed price), который, казалось бы, переносит многие риски на исполнителя. В действительности исполнитель старается все эти риски заложить в стоимость контракта. Этот подход трудно назвать гибким, так как обе стороны пытаются победить друг друга, вместо того, чтобы искать решение Win-Win, основанное на взаимном доверии.

Нулевой спринт

О нулевом спринте многие молчат, мол это «вотерфолл», или пишут совсем чуть-чуть. Буквально год или два назад наконец-то начали активно обсуждать эту фазу проекта, причем, на данный момент в основном обсуждается продуктовая часть. С нее и начнем.

Самым главным документом в проекте, с которого обязательно стоит начать его разработку, является видение (vision) проекта. Этот краткий документ описывает, что представляет собой продукт, кто, когда, как и где будут его аудиторией, основные фазы проекта, бизнес-модель для монетизации и так далее. Словом, заменяет целый пакет документ, который принято делать в более тяжеловесных методологиях. Для создания видения можно использовать инновационные игры, разного рода мозговые штурмы и фреймворки.

Следующим этапом идет выявление персон и их активностей (вплоть до отдельных юзер-стори), которые фактически являются легковесным и более визуальным вариантом экторов и юзкейсов. Уже традиционно данную активность Scrum-команды реализуют в виде Story mapping, результатом которого становятся доски и целые стены с визуализацией активностей в проекте:



Обязательно надо вытащить представителей заказчика на процессы по выработке видения и Story mapping (а на последний еще потенциальных пользователей).
Обратная сторона монеты – это выбор платформы для разработки и создания архитектуры. Конечно, я имею в виду не Big Upfront Design, а более гибкий подход, ведь десятки или сотни диаграмм, пылящихся в дальнем ящике стола – это не наша цель. Наша задача сделать продукт, минимизировав потери.



В самом простом случае можно ограничиться диаграммой предметной области с максимально простым синтаксисом, который будет понятен и заказчику. В более сложных случаях эту диаграмму стоит дополнить до диаграммы классов и набрать в корзину архитектуры еще несколько UML-диаграмм, которые помогут описать динамическую часть вашей системы.
Можно взять ICONIX в качестве подмножества UML и процесса (см. мою презентацию c AgileDays в Екатеринбурге), но он будет скорее замещать Story Mapping, чем дополнять его.
В нулевой спринт входит и подготовка к первому спринту. Для этого необходимо юзер-стори описать, спроектировать для них интерфейс и оценить. Работу лучше всего построить в таком порядке, так как он способствуем более качественному пониманию требований и их оценке.

Практики Scrum или посадить заказчика на итеративную иглу

Не буду подробно останавливаться на традиционных практиках Scrum’а, хочу отметить лишь, что в них надо по возможности вовлекать заказчика. Программа-минимум – это посещение заказчиком всех демонстраций: вам жизненно необходимо подсадить заказчика на свой ритм работы, чтобы он хотел получать очередной инкремент функционала, как наркотик :) Это сильно поможет выстроить атмосферу доверия между вами.

Программа-максимум — вытаскивать представителя заказчика и на другие мероприятия. Например, посещение покер-планирования поможет заказчику лучше осознать размеры ваших задач и понимать, что команда работает с высокой скоростью. Участие заказчика в ретроспективах позволит глубже погрузиться в проблемы и риски команды, при этом он сможет принять активное участие в совершенствовании процессов.

В следующий раз мы поговорим о том, как скрестить управление рисками и Agile.

Автор: Борис Вольфсон — Руководитель департамента разработки Softline
Tags:
Hubs:
+23
Comments 25
Comments Comments 25

Articles

Information

Website
www.softline.ru
Registered
Founded
1993
Employees
1,001–5,000 employees
Location
Россия
Representative
Softliner