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

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

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

После этого у Дэвида был еще один, более трудный, разговор с командой разработки. Он выразил разочарование по поводу того, что прогресс не был прозрачным. Дэвид был смущен: ему преподносили процесс как 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, чтобы устранить расхождение между диаграммой сгорания задач, которую Дэвид считал правдивой, и реальной диаграммой, нужны два дополнительных спринта, чтобы сделать три предыдущих инкремента пригодными для использования в бизнесе.