свидетельствует верхняя кривая конуса неопределенности. Вероятность того, что пятиминутное задание выйдет из-под контроля, довольно мала. В отличие от нее, пятимесячная задача, которая более чем в 30 000 раз масштабнее, имеет гораздо больше шансов на то, что с ней могут быть связаны неизвестные нам неизвестные факторы.
Таким образом, когда разработчики разбивают объемные задачи на более мелкие, они тем самым сокращают количество неизвестных, преобразуя их в известные неизвестные. Вы не можете полностью исключить неизвестные факторы, но, работая с частями меньшего размера, вы можете взять их под контроль, чтобы они стали более управляемыми и оказывали более предсказуемое влияние на разработку продукта. Проекты, реализуемые с применением «водопадного» подхода, как правило, являются масштабными, и печально известны тем, что их реализация занимает гораздо больше времени, чем предполагалось изначально.
Помимо описанного выше преимущества, некоторые фанаты Agile указывают в качестве недостатка «водопадного» подхода тот факт, что он подразумевает жесткую зависимость выполняемых шагов процесса от сделанного на предыдущем этапе. Однако такая критика является слишком огульной. Можно подумать, будто Agile позволяет просто подключиться на любом шаге процесса разработки и тут же начать что-то кодировать. На самом деле это не так. Даже следуя Agile-подходу, необходимо пройти этап проектирования, прежде чем перейти к написанию программного кода; вы просто делаете это быстрыми, но гораздо более мелкими шагами.
Стоит отметить, что для некоторых проектов «водопадный» подход является наилучшим. Например, вряд ли кому-нибудь пришла бы в голову идея отправить человека в космос на минимально жизнеспособной версии космического корабля. Я начинал свою карьеру с проектирования атомных подводных лодок. Могу вас уверить, что мы многократно проверяли все технические задания и по нескольку раз пересматривали проекты, прежде чем приступить к строительству. В таких ситуациях риск неудачи слишком высок и связан с жизнями людей. Кроме того, в отличие от написания программного кода для веб-сайта, в который при желании или необходимости можно быстро внести изменения, поменять что-то в структуре космического корабля или подводной лодки, после того как они уже построены, гораздо сложнее, если вообще возможно. Когда риск неудачи или стоимость внесения изменений слишком высоки, лучше потратить больше времени на подготовительные этапы, чтобы максимально повысить степень уверенности в будущем успехе.
Основные принципы гибкой разработки были изложены в «Манифесте Agile», который был написан в 2001 году (вы можете ознакомиться с Манифестом и принципами Agile по ссылке: http://agilemanifesto.org). Agile поощряет раннюю и непрерывную поставку работающего программного обеспечения с ориентацией на создание ценности для потребителей. Ключевой частью Agile является определение продукта с точки зрения потребителя и использование с этой целью пользовательских историй. Как уже было сказано в главе 6, история пользователя – это краткое описание преимуществ, которые должен предоставлять конкретный функционал. Это описание включает как самого персонажа – для которого предназначены эти преимущества, так и его цели. Хорошо написанные пользовательские истории обычно соответствуют шаблону:
Я как [тип пользователя]
хочу [что-то сделать],
чтобы [получить желаемую пользу].
Agile также способствует тесной межфункциональной коммуникации и сотрудничеству, когда бизнесмены и разработчики постоянно работают вместе, в идеале – лицом к лицу. Вместо побуждения к соблюдению жесткого плана, Agile обеспечивает гибкость, позволяющую быстро реагировать на изменения. Команды разработчиков достигают этого, выполняя работу мелкими частями в коротких итеративных циклах с обратной связью и обучением в противовес стремлению заранее и подробно определить весь набор требований к заданию. Наконец, Agile – это постоянное совершенствование процесса разработки продукта с помощью обратной связи и экспериментов.
Существует несколько различных разновидностей Agile-разработки, включая экстремальное программирование (сокращенно XP) и бережливую разработку программного обеспечения. Далее я приведу краткий обзор двух наиболее часто используемых методологий Agile: Scrum и Канбан.
Scrum
Scrum является наиболее популярной методологией Agile. Ее относительно легко внедрить, благодаря существованию множества предписывающих руководств о том, как практиковать Scrum. Ключевым аспектом Scrum является то, что команда работает в условиях строгого соблюдения фиксированных временных интервалов. Каждый рабочий интервал, называемый спринтом или итерацией, представляет собой заранее спланированный промежуток времени. Особенно распространены двухнедельные спринты, но есть команды, использующие недельные, трехнедельные и четырехнедельные спринты.
Все выполняемые командой разработчиков задачи берутся из так называемого бэклога незавершенных пользовательских историй. Бэклог – это упорядоченный по приоритетности список заданий. Пользовательские истории пишутся и помещаются в бэклог продукта владельцем продукта – это одна из трех видов ролей, применяемых в Scrum. Владелец продукта, или сокращенно ВП, отвечает за использование информации, полученной от потребителей и других заинтересованных сторон, для создания бэклога незавершенных пользовательских историй. Обычно роль владельца продукта в команде берет на себя менеджер по продукту. В некоторых компаниях функции ВП выполняет специальный сотрудник. В этом случае он находится в тесном взаимодействии с менеджером по продукту. В небольших стартапах, которые не могут позволить себе иметь выделенного продакт-менеджера, его роль обычно примеряет на себя один из основателей компании.
Вторая роль Scrum-команды имеет обобщенное название: «член команды разработчиков». В руководстве по Scrum говорится, что команда разработчиков должна быть многопрофильной и обладать всеми навыками, необходимыми для выполнения работы. В состав Scrum-команды обычно входят несколько разработчиков, чья работа заключается в оценке масштаба пользовательских историй и в создании продукта. Носителями этой важной роли также являются UX-дизайнеры, визуальные дизайнеры и специалисты по обеспечению качества (QA). В соответствии с традиционными принципами Scrum, внутри команды не должно существовать иерархических различий; признается лишь деление на роли. Дизайнеры занимаются реализацией пользовательских историй, разрабатывая пользовательский опыт, который они передают через созданные ими дизайн-проекты. Хорошо написанные пользовательские истории включают в себя критерии приемлемости, которые используются для подтверждения того, что история завершена и работает именно так, как было задумано. Специалисты по контролю качества проверяют, соблюдены ли критерии приемки, и обеспечивают качество продукта.
Идеальная численность Scrum-команды составляет от пяти до девяти человек. Возможно, вы слышали о «правиле двух пицц»: если двух пицц недостаточно, чтобы накормить всех членов команды, значит, вас слишком много. Численный состав команды должен быть достаточным для выполнения значительного объема работы за один спринт. Но при этом команда должна быть достаточно мала, чтобы оставаться сплоченным коллективом и не иметь проблем с коммуникацией, часто присущих многочисленным группам.
Третья роль – Scrum-мастер, чья работа заключается в том, чтобы помогать команде в процессе разработки и повышать ее производительность. В крупных компаниях один и тот же Scrum-мастер может работать как с одной, так и с несколькими Scrum-командами. Зачастую эту роль берет на себя ведущий разработчик или менеджер по разработке. Хотя это не согласуется с руководящими принципами Scrum, иногда эта роль
