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

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

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

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

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

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

.

Рис. 7.5

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

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

Рис. 7.6. Инкрементальный прогресс в сторону готовой к использованию функциональности

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

Дэвид уловил идею прозрачности и предсказуемости. Команда разработки – только общую идею Scrum. Они перенесли непредсказуемость разработки каскадного процесса внутрь Scrum.

Прозрачность инкрементов должна была позволить Дэвиду управлять рисками и добиваться предсказуемости. В начале проекта Дэвид со Scrum-командой определили план выпуска. После спринта № 1 он оценил динамику приближения к будущей цели путем оценки того, что, как он думал, было рабочим инкрементом, и принял решение о том, что необходимо сделать в спринте № 2 в рамках движения к цели. Если бы он знал, что прогресс был недостаточным, то мог бы отменить проект. Однако из-за того, что инкремент был непрозрачным, он не мог эффективно принять решение.

Когда команда разработки оценила объем работы, которая не была доделана в течение первых трех спринтов, это добавило еще 14 единиц работы. Расхождение между планом и реальным прогрессом в конце третьего месяца разработки отражает эти «скрытые» 14 единиц работы, как показано на рис. 7.7.

Рис. 7.7. Реальная и планируемая законченная работа

В конце третьего спринта Дэвид верил, что 30 % работы уже сделано, как показано на рис. 7.5. Он думал, что может начать использовать эти 30 % готового продукта. К сожалению, инкремент не был законченным. Как показано на рис. 7.7, чтобы устранить расхождение между диаграммой сгорания задач, которую Дэвид считал правдивой, и реальной диаграммой, нужны два дополнительных спринта, чтобы сделать три предыдущих инкремента пригодными для использования в бизнесе.

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

Когда проект «закончен», «завершен» или «финализирован», не должно быть недоделанной работы. Этот важный момент – одно из наиболее неявных, но фундаментальных требований Scrum-подхода.

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