Как только команда обработала все детали (в разумной степени), мы расставляем пользовательские истории в бэклоге по приоритету. В зависимости от размера проекта и его фазы иногда это делается скорее на уровне пользовательских операций, а не пользовательских историй. Обычно мы пользуемся простыми техниками голосования, например точечной техникой, но иногда применяем для голосования упрощенную модель Кано, согласно которой команды помечают пользовательские истории как «обязательно», «желательно» и «опционально». Результаты этого простого голосования также являются хорошей основой для окончательной расстановки историй с участием других заинтересованных сторон, конечных пользователей и заказчиков.
Как прокомментировал один из владельцев продукта, «владельцы продукта часто сталкиваются со сложной задачей – им необходимо поместить множество требований в очень узкие временные рамки. Мы пригласили наших заказчиков на однодневный семинар по картам историй, и оказалось, что это очень эффективный и продуктивный способ выработки одинакового понимания наших приоритетов».
Детали, подробные оценки затрат и другие мелочи обычно не входят в семинар, но, как правило, обсуждаются в меньших группах позднее.
2. Масштабирование карт пользовательских историй
Чтобы масштабировать и развернуть процесс, команда тренеров, которая начинала работу, приготовила материалы: шаблоны карт, сделанные в программе Excel, шаблоны для персонажей, стандартную повестку дня семинара, выдержки из документации, а также шпаргалки с описанием метода. Кроме этого, было разработано собственное внутреннее приложение для составления карт пользовательских историй.
Но материалы – это одно, а проведение семинара – совершенно другое. Поэтому мы снова настоятельно рекомендуем привлечь к процессу опытного тренера. Чтобы обеспечить организацию достаточным количеством тренеров, первичная тренерская команда подготовила специалистов. Эти начинающие тренеры провели несколько семинаров под присмотром наставников, помогали на индивидуальных сессиях и наконец были готовы руководить семинаром абсолютно самостоятельно. Мы также проводили семинары и тренировки тренеров в других офисах SAP по всему миру. Чтобы обрести уверенность, что мы учимся друг у друга, и для обмена опытом мы запустили огромную сеть для хранения документации и общения, где тренеры могли опубликовать свои вопросы и полезные практики. И конечно, очень многое мы почерпнули из опыта Джеффа.
Наши усилия по масштабированию пользовательских карт историй в конце концов принесли плоды. Мы провели более 200 семинаров под руководством тренеров в различных офисах во многих местах, и сейчас большинство команд способны продуктивно работать с картами пользовательских историй самостоятельно.
Глава 6. Реальные примеры применения историй
Карты историй – невероятно простая идея. Применяя простую карту, вы можете работать с другими людьми, чтобы изложить историю использования продукта и увидеть результат своей работы в целом. Затем вы дробите эту цельную картину на части, чтобы правильно распланировать разработку. Основу всего составляет простая концепция историй в Agile.
Убийственно простая идея Кента
Изначальная идея историй принадлежит невероятно умному парню по имени Кент Бек. В конце 1990-х Кент и его коллеги работали в области разработки программного обеспечения. Кент обратил внимание на то, что одна из крупнейших проблем в разработке программ берет свое начало из традиционной работы с бумажными документами, где подробно описано, чего мы хотим, – их принято называть требованиями. К настоящему моменту вы уже знаете, что с ними не так: разные люди могут читать один и тот же документ и понимать его совершенно по-разному. Они могут даже подписаться под этим документом, свидетельствуя, что пришли к соглашению.
Лишь позднее, когда мы погружаемся в глубину разработки программы – или даже еще немного позднее, когда она предъявлена пользователям, – выясняется, что на самом деле мы думали не об одном и том же. И конечно, большинство людей объясняют отсутствие общего понимания неудачными требованиями.
Давайте задержимся здесь на минуту. Я имел удовольствие работать с множеством команд. Очень часто работа начиналась с обсуждения наших самых больших затруднений. И разумеется, чаще всего я первым делом узнавал о «неудачных требованиях». Каждый тычет пальцем в этот несчастный документ. Автор документа готов сгореть со стыда – наверняка он должен был написать больше или меньше либо, может быть, использовать какие-то новейшие техники составления документации. Те, кто подписал этот документ, ощущают себя не лучше и поэтому занимают оборонительную позицию: «Вы что, ожидали, что я вчитаюсь в каждую деталь? В конце концов мы обсуждали это целыми днями! Я думал, вы поняли, что я сказал. Я вообще не понимаю, откуда взялся этот дурацкий документ!» А те, кто работал над самим программным продуктом, и вовсе сбиты с толку – они выполнили свою задачу, руководствуясь этим злосчастным документом, но оказалось, что все по-прежнему неправильно. В общем, все хотят отправить эти бумаги в печку и немедленно написать новую, лучшую документацию.
Мы оба можем прочитать один и тот же документ, но понять его по-разному.
Но разное понимание документа – это лишь половина проблемы. Мы тратим уйму денег и времени, воплощая в жизнь то, что описывает этот документ, и все только для того, чтобы позднее обнаружить: для решения изначально поставленной задачи нужно совершенно иное. Да, вы поняли меня правильно – все эти документы, как правило, содержат совершенно неверные вещи. Документы обычно описывают то, что нам нужно, но не почему оно нужно. Если некто работающий над программным продуктом может просто поговорить с кем-либо, кто хорошо разбирается в будущих пользователях этого продукта и мотивах их работы с продуктом, чаще всего он найдет гораздо более эффективный и экономичный способ удовлетворить этих пользователей. Не нужно уточнять, что чаще всего у нас попросту нет такой информации.
Лучшие решения – результат сотрудничества между людьми, у которых есть какие-то проблемы, и другими людьми, которые могут их решить.
Простая идея Кента заключалась в том, чтобы прекратить это – перестать тратить силы на написание идеальной документации, а вместо этого собираться вместе и рассказывать истории. Истории получили свое название не потому, что их нужно было записывать, а из-за того, как они должны были использоваться. Разрешите мне подчеркнуть это еще раз для закрепления. Прямо сейчас отложите все дела и громко прочитайте вслух.
Название «истории» произошло от того, как они должны использоваться, а не из-за того, что вы должны их записывать.
Идея Кента очень проста. Если мы соберемся вместе и обсудим проблему, которую решаем с помощью программного продукта, а также поговорим о том, для кого и почему мы это делаем, то в конце концов придем к решению и выстроим одинаковое понимание.
Просто – не значит легко
Некоторое время назад я стал замечать, что развитие работы с историями ушло немного в сторону: множество людей пишут книги, преподают и используют эту технику, концентрируясь на написании
