Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

Ранее разработка программного обеспечения была скорее неудачной, в первую очередь по причине использования предиктивных процессов для комплексных работ. Переход к Scrum, эмпирическому процессу, значительно увеличивает шансы на успешное завершение проекта разработки программного обеспечения.

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

В предыдущей главе мы узнали, что эмпирический процесс – правильный для девелопмента программного обеспечения. Теперь давайте посмотрим, как эмпиризм работает и как можно с его помощью создать ПО. Мы изучим эмпиризм через призму гибкого процесса разработки программного обеспечения, который мы назвали Scrum.

В эмпирическом процессе информацию получают путем наблюдения, а не предсказания. Известно, что эмпирические процессы лучше всего подходят для сложных задач, когда неизвестного больше, чем изученного. Чтобы в этой ситуации эмпирический процесс работал, должно выполняться два требования.

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

2. Прозрачность . Когда мы проводим проверку, то должны иметь возможность оценить, что мы видим в тех же условиях, в которых находится наша цель. Если наша цель – разработка системы с определенными признаками или функционалом, то мы должны проверять то, что составляет часть этого признака, функции или их сочетания. Если бы мы использовали предиктивный процесс, то должны были бы задать требования для разработки программного обеспечения, которое может занять годы. Но мы знаем, что в случае с программным обеспечением в течение такого долгого периода накапливается слишком много рисков и потерь. Вместо этого мы используем короткие периоды, обычно 30 дней или меньше. (Позднее мы обсудим значение более коротких периодов.) По окончании первых 30 дней проверяем результаты и определяем, что делать дальше для достижения нашего видения, и, если необходимо, вносим изменения.

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

Таблица 2.1. Бэклог требований для организации бизнес-операций

Бэклог – это постоянно меняющийся список наших идей для этого продукта, мы можем добавлять, изменять и удалять из него пункты, когда захотим. В бэклоге продукта мы определяем порядок работы, поэтому наиболее важные требования должны быть вверху списка.

Во-первых, мы должны удостовериться, что наша идея осуществима. Сможем ли мы в течение 30 или меньше дней создать то, что будет полезным и оправдает дальнейшую работу над программным обеспечением?

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

Мы начинаем с наиболее важных пунктов, но члены команды могут добавлять идеи, которые, как они считают, должны быть включены в бэклог, – например, стабильность программного обеспечения. Мы обсуждаем эти требования, а затем помогаем команде разработчиков продумать лучший способ их реализовать. Несмотря на то что мы не разработчики программного обеспечения, мы можем выбирать среди альтернатив и уточнять вопросы для них.

Давайте сформулируем определения для того, что мы описали.

Итерация . Это повторение серии шагов или процессов, обычно с целью приближения к желаемой цели или результату. Каждое повторение процесса также называется итерацией, а результаты одной итерации используются как стартовая точка следующей. Для вас первые 30 дней – это первая итерация.

Частота . Этот термин относится к длине итерации. Частые итерации контролируют риски путем постоянного инспектирования прогресса, чтобы гарантировать, что потери не происходят и контроль сохраняется. Оптимальная частота находится в диапазоне не меньше недели и не более месяца.

Инкремент (приращение). Это частица целого, которая увеличивается со временем. Функциональный результат итерации в процессе разработки называется инкрементом. Приращение создается повторение за повторением, пока мы не получим полезную систему.

Прозрачность. Инкремент должен быть полностью законченным и пригодным к использованию, без необходимости доработки. Незаконченную работу, или прототипы, нельзя считать прозрачной, потому что мы не можем проверить, насколько прототипы закончены и сколько работы осталось, чтобы их закончить.

Итеративно-инкрементальный процесс . Это способ разработки программного обеспечения через последовательность итераций, каждая из которых генерирует полное приращение функционала, основанное на всех предыдущих приращениях. Итерации продолжаются до тех пор, пока цель не будет достигнута.

Мы начинаем первую итерацию. Команда разработки превращает наши требования в прирост функционала. Каждая итерация начинается с планирования, затем команда разрабатывает то, что было запланировано, и потом все проверяют результирующий инкремент программного обеспечения.