Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

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

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

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

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

Результаты оказались поразительными.

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

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

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

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

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

Что сделал бы да Винчи?Я часто задаю себе этот вопрос. Ладно, хорошо, не задаю. Но, возможно, мне следовало бы так поступать.

По сути Майк и Аарон выбрали ту же стратегию, которой пользуются художники, когда хотят завершить свои произведения вовремя. Точно такой же подход я применяю при создании программного обеспечения на протяжении многих лет. А когда я познакомился со своими будущими друзьями в Globo.com, оказалось, что и у них такой же подход, потому что, как я уже говорил, даже если они запоздают с разработкой нового интерактивного продукта к Олимпиаде, Олимпийский комитет не станет переносить открытие Игр. Я также думаю, что и вы привыкли следовать той же стратегии, даже не задумываясь над этим.

Начну объяснение с того, чего не делал Леонардо да Винчи, но, к сожалению, часто пытаются проделать обычные люди, занимающиеся созданием программного обеспечения.