Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 148

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

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

Что теперь? Если истории нужны для планирования и управления дискуссиями, с помощью которых разрабатывается программное обеспечение, похоже, всем нам придется очень много разговаривать.

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

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