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

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

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

Аналогия

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

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

Устранение технических долгов для получения готовых к использованию инкрементов

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

Таблица 7.3 предоставляет в первой колонке типичную работу, которую проделывает команда девелоперов, чтобы превратить требования бэклога продукта в стабильный функционал. Вторая колонка, обозначенная «Обычно», содержит количество единиц работы, которую команды привыкли делать предварительно до конца предиктивного, традиционного, проекта для каждой задачи из первой колонки. К примеру, разработчики привыкли тратить 12 единиц работы на анализ требований. Они привыкли тратить 10 единиц работы, создавая компоненты архитектуры. Это относительные цифры, показывающие, что разработчики тратят на две единицы больше работы в первом пункте, или на 20 % больше работы, чем по второму пункту.