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

8. Профит!!!

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

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

Если же вы приняли решение «да», настало время засучить рукава и взяться за работу. Именно об этом следующая глава.

Видя простые модели описания Agile Development, я часто замечаю, что с левой стороны, где они начинаются, расположен большой список – бэклог продукта . Я считал бы это смешным, если бы многие люди не думали, что это очень просто. Получение хорошего, выверенного бэклога из накопившихся возможностей неизбежно займет очень много времени и сил – он не появится сам по себе. И конечно, этот бэклог не может просто состоять из того, что люди хотели бы создать. Это отдельный исследовательский процесс, который начинается с концентрации на углубленном изучении «Для кого?», «Что?» и «Почему?».

Исследовательская работа обычно не направлена на создание пригодного к предъявлению программного продукта. Ее основная цель – выработка углубленного понимания того, что мы можем создать. Речь идет о постановке и поиске ответов на следующие вопросы.

• Какие проблемы мы решаем в действительности?

• Какое решение было бы наиболее полезным для нашей организации и клиентов, покупающих или использующих наш продукт?

• Как должно выглядеть решение, наиболее удобное и эффективное в использовании?

• Что мы имеем возможность реализовать , учитывая имеющиеся время и средства?

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

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

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

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

1. Сформулируйте идею с точки зрения бизнеса.

2. Постарайтесь понять, каким образом вы можете помочь заказчикам и пользователям .

3. Сформируйте видение вашего решения.

4. Минимизируйте его, а также составьте план , как выявить и затем создать минимально жизнеспособное решение.

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

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