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