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

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

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

Работой можно управлять, используя всего три переменные. Первая (А) – это требования, функциональные возможности, которые предоставит планируемое программное обеспечение. Вторая переменная (В) – время, которое теперь мы измеряем в блоках по 30 дней. Третья переменная (С) – законченная работа, которая измеряется в пригодных к применению функциональных возможностях или в количестве требований и функциональных возможностей, выполненных в каждый из 30-дневных периодов и совокупно.

Таким образом, можно создать график для управления проектом.

1. Бэклог требований по оси Y , или вертикальной оси. Работа по выполнению каждого требования разбита по размеру. Давайте предположим, что у нас есть пять требований. Каждое требует выполнения 2, 3, 5, 3 и 8 блоков работы. Они создают объем работы по оси Y из 21 блока. Блоки расположены в порядке, в котором вы хотите превращать их в пригодные к использованию функциональные возможности. Давайте, скажем, порядок сверху вниз будет 2, 3, 5, 3 и 8.

2. Время отложим по горизонтальной оси Х . Блоки по 30 дней, что составляет протяженность одной итерации.

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

4. Объем выполненной работы и готовые к использованию функциональные возможности вычисляются в конце каждой итерации. Мы планируем, что первые два требования, которые состоят из двух и трех блоков работы, будут закончены в течение первой итерации. Мы предполагаем закончить следующий фрагмент функциональных возможностей, состоящий из пяти блоков работы, во второй итерации. К этому времени мы обычно уже корректируем планы относительно того, что же делать дальше. Мы уже видели первые два инкремента и часто на этом этапе находим непредвиденные или измененные требования для следующей итерации. Если такого не случилось, мы продолжаем, как планировалось. Тем не менее план и будущие требования без проблем могут изменяться в конце каждой итерации. Размер инкрементов измеряется в тех же единицах, что и требования по оси Y .

5. Команда разработки создала 3, 5 и 5 блоков функциональных возможностей в первые три периода времени. Получившийся график показан на рис. 2.3.

Рис. 2.3. Диаграмма сгорания работы

План, или прогноз, в начале работы показывает, что вы начали с 21 блока работы.

За каждую итерацию предполагалось выполнять пять блоков. Соответственно, мы нанесли это на график. Прогнозная линия на графике показывает, что все функциональные возможности планируется закончить за пять итераций.

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

Эмпиризм обеспечивает ряд факторов.

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

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

3. Предсказуемость. Прогноз может быть неправильным, и завершение произойдет на несколько недель позже, чем планировалось. Эту вероятность можно предположить в конце первой итерации, возможно, после второй, и, скорее всего, она станет очевидной к концу третьей. Все, кто будет пользоваться результатами разработки, могут начать параллельно синхронизировать свои планы. Кроме того, бюджет можно пересмотреть и утвердить раньше.

4. Управление рисками. Команда разработки закончила только два блока работы в каждой из первых трех итераций. В конце третьей прогноз показал, что окончание разработки не случится ранее середины десятой итерации. Если начальный бюджет был 100 тысяч долларов, новый прогноз предполагает перерасход средств на 150 тысяч. Если возврат инвестиций в размере 250 тысяч долларов невозможен, то проект можно отменить уже после третьей итерации.

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