Книга: Пользовательские истории. Искусство гибкой разработки ПО
Назад: Еще один секрет верной оценки временных затрат
Дальше: Итерации и прирост

Регулируйте свой бюджет

Еще на самой ранней стадии Майк и Аарон работали вместе с программистами, которым доверяли, над начальной оценкой временных затрат. Они рассматривали эту величину как бюджет и старались хорошо организовать его.
С каждым небольшим фрагментом, который создавала команда, они могли получить измерения реальных затрат времени. Каждый кусочек работы расценивался как трата средств из бюджета. К примеру, могло оказаться, что бюджет израсходован наполовину, в то время как выполнена лишь треть работы по реализации запланированной функциональности. Этого, конечно, никто не ожидал, но по крайней мере они могли стать еще внимательнее и каким-то образом на это реагировать. Например, можно было бы позаимствовать бюджет у других функциональностей, над которыми команда в то время работала. Или немного упростить функциональность, но так, чтобы не особенно затронуть интересы пользователей. В конце концов они могли просто смириться с неизбежным и поискать способы как-то изменить ожидания людей, которым пообещали сделать работу к определенной дате.
В зависимости от того, насколько плохо будут обстоять дела, понадобится увеличение запасов пива.
Разделяя карту на срезы для перехода к стратегии разработки, ребята стараются как можно раньше выявить элементы, которые, скорее всего, подорвут бюджет. Это рискованные элементы, и найти их можно, только обсуждая продукт со всей командой.
Выявление рисков при составлении карт историй
Крис Шинкл, SEP
Крупная компания по обеспечению безопасности хотела создать беспроводную систему контроля доступа для зданий средних размеров (школы, кабинеты врачей, магазины и т. п.) в средней ценовой категории. Компания обратилась в SEP для разработки встроенного программного обеспечения для замков, а также беспроводного терминала ZigBee, с помощью которого обеспечивалось взаимодействие с ними.
Проект был невероятно интересным с технической точки зрения, но одновременно богатым вероятностью сесть в лужу: ограниченный бюджет, узкие временные рамки, изменения, вносимые руководством по ходу разработки, непроверенные технологии, а также постоянное увеличение объема работы.
Естественно, все немедленно пошло наперекосяк. Команда проекта нарушила сроки выполнения нескольких промежуточных этапов. Клиент был недоволен, и, конечно, команда была деморализована. В ходе поиска причин сложившейся ситуации разработчики выяснили, что главной причиной нарушения сроков стала незапланированная работа, в основном вызванная неопределенностями и оправдавшимися рисками. Нужно было срочно что-то менять.
Команда немедленно взялась за решение проблемы, как поступили бы на ее месте все умные люди. Что же они придумали? Они решили модифицировать карту историй.

 

 

С высокоуровневой точки зрения они увеличили частотность и точность своей карты историй. Увеличивая частотность отображения истории для каждого временного промежутка, соответствующего релизу, они ожидали повышения вероятности обнаружения рисков, а увеличив точности карты, которая теперь включала рискованные истории наряду с обычными действиями, задачами и деталями, надеялись визуализировать, обсуждать и обрабатывать риски.
Результаты оказались поразительными.
Команде было известно, что ширина и глубина обычной карты историй позволяют ощутить размер проекта. Кроме того, разработчики знали, что количество способов прохождения карты – хороший индикатор уровня сложности. Но так как риски и неопределенности не были отображены на карте историй, она не отражала действительный объем работы (включая исследования), которую требовалось проделать.
Новая карта, включающая в себя рискованные истории, позволила оценить объем и сложность работы более точно. Эти величины оказались лучше на ней представлены потому, что их составляли не только известные запланированные истории, но и новые, неизвестные рискованные истории. Их можно было расценивать как знания, которые команда должна была получить, прежде чем уверенно двинуться вперед, работая с известными историями.
Как вы уже догадались, новая карта оказалась куда более полезной для планирования, чем прежняя. На ней были хорошо видны риски и неопределенности, проработка которых требовала времени. Возможность запланировать это время сделало работу команды куда более предсказуемой и гибкой.
Обнаружилось и еще одно выгодное следствие такого подхода: возможность измерять и обновлять то, как сотрудники продвигаются в исследованиях. Вдобавок к традиционной диаграмме сгорания задач команда теперь обновляла и диаграмму снижения рисков. Особенно полезно это было в тех случаях, когда заказчик был недоволен состоянием диаграммы сгорания задач, но мог оценить усилия команды по диаграмме снижения рисков.
К концу дня вся команда была убеждена, что снижение частоты создания карт историй и добавление рискованных моментов – отличные способы приближения карты историй к реальности.
Что сделал бы да Винчи? Я часто задаю себе этот вопрос. Ладно, хорошо, не задаю. Но, возможно, мне следовало бы так поступать.
По сути Майк и Аарон выбрали ту же стратегию, которой пользуются художники, когда хотят завершить свои произведения вовремя. Точно такой же подход я применяю при создании программного обеспечения на протяжении многих лет. А когда я познакомился со своими будущими друзьями в Globo.com, оказалось, что и у них такой же подход, потому что, как я уже говорил, даже если они запоздают с разработкой нового интерактивного продукта к Олимпиаде, Олимпийский комитет не станет переносить открытие Игр. Я также думаю, что и вы привыкли следовать той же стратегии, даже не задумываясь над этим.
Начну объяснение с того, чего не делал Леонардо да Винчи, но, к сожалению, часто пытаются проделать обычные люди, занимающиеся созданием программного обеспечения.
Представьте себе, что вы Леонардо да Винчи и собираетесь написать картину, следуя той же стратегии, к которой традиционно прибегают большинство команд в мире разработки. Вы можете начать работу с четким представлением о картине, по крайней мере вам так кажется. Вы разбиваете картину на несколько частей. Допустим, на эту работу отведено пять дней и каждый день вы рисуете по одной части. А к концу пятого дня – бах! – вы закончили! Что может быть проще?

 

 

Проблема лишь в том, что в реальности это не работает, по крайней мере для художников. Что-то создать таким образом можно, если предположить, что изначальное видение точно и правильно. Необходимо также, чтобы автор был высокопрофессионален и способен точно выделить части работы без визуального представления их в контексте. Если вы поступаете подобным образом при разработке программного обеспечения, это называется стратегией постоянного прироста (инкрементальной). По сути, таким образом каменщик строит стену, и этот способ хорошо работает, если размеры всех кусочков одинаковы и хорошо определены – как у кирпичей.
Когда в детстве я учился рисовать, то тоже наступил на эти грабли. Я любил изображать животных и, как правило, начинал с головы. Я работал над головой, пока она не становилась, по моему мнению, идеальной, а затем переходил к рисованию остальных частей тела – ног, туловища и пр. Но когда работа подходила к концу, мне становилось очевидно, что пропорции животного на рисунке совершенно не согласованы. Голова была слишком велика или слишком мала по сравнению с телом, ноги соединялись с ним под неестественным углом, а поза животного была вообще ни на что не похожа. Но все это можно было списать на особое видение талантливого шестилетнего художника, ведь, как мы знаем, все шестилетние художники очень талантливы.
Намного позже я осознал ценность предварительного наброска всей композиции. В данном примере я должен был сначала верно определить пропорции, уточнить позу, а может быть, даже изменить первоначальный замысел рисунка.
Мне, к сожалению, не приходилось наблюдать за Леонардо, но, я полагаю, он делал что-то очень похожее.

 

 

Даже Леонардо да Винчи, вероятно, признал бы, что его первоначальное видение картины не было идеальным, а он кое-что понимал в рисовании. В первый день, как мне представляется, он рисовал эскиз композиции или, может быть, делал легкий набросок. Я уверен, что на этом этапе он вносил в композицию небольшие изменения: «Хм, кажется, здесь самое важное – ее улыбка. Надо убрать руку от губ. А эти горы на заднем плане… Кажется, они слишком высокие, недостает пространства».
К середине недели Леонардо уже нанес на картину большую часть форм и красок, но все еще мог вносить изменения и делал это. К концу недели, видя, что не укладывается в назначенный срок, Леонардо прикладывает все усилия к проработке деталей картины. Некоторые до сих пор гадают, почему у Моны Лизы нет бровей: это осознанное решение художника или ему просто не хватило времени проработать эту особенность?
«Работу над великим произведением искусства невозможно завершить – ее можно только прервать» (Леонардо да Винчи).
Эту цитату приписывают Леонардо да Винчи. Фраза означает, что мы можем продолжать добавлять и улучшать что-то бесконечно, но в какой-то момент все-таки придется прерваться и выпустить наше произведение в мир. И если Леонардо и множество других великих художников могут служить для нас примерами, мы – люди, которые смотрят на их работы, – даже не догадываемся, что работа была прервана. Для нас она выглядит завершенной.
Назад: Еще один секрет верной оценки временных затрат
Дальше: Итерации и прирост