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

Выработайте привычку кратко записывать свою мысль перед тем, как ее озвучить.

1. Если вы используете карточки или стикеры, запишите на них несколько слов об идее, как только она придет в голову .

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

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

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

Я пришел к Гэри не за тем, чтобы сформулировать его требования. И первым, что мы обсудили, был вовсе не набор функций. Нам пришлось ненадолго вернуться и начать сначала.

Предметом первого обсуждения стала сама идея продукта. Мы говорили о бизнесе Гэри и его целях. Зачем вы это создаете? Сформулируйте, какие преимущества даст этот продукт вам и другим людям, которые будут его использовать. Какие задачи он будет решать для этих людей и для вас? Читая это, вы, наверное, догадались, что я думал о модели «до и после». Я пытался понять, какие результаты хочет получить Гэри, а не какую работу он планирует проделать.

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

Мы с Гэри продолжили обсуждение. Следующей темой разговора стали заказчики, которые купят продукт, и пользователи, которые будут непосредственно с ним работать. Мы перечислили различные типы пользователей. Обсудили преимущества, которые они получат, задались вопросом, почему они будут использовать продукт, а также что, как мы предполагаем, будут с ним делать. Что продукт должен включать в себя с точки зрения пользователей? Ответы записали на целую груду бумажек. Карточки, на которых были указаны наиболее важные пользователи, сами оказались на верхних позициях. Забавно, что иногда это работает и таким образом – без явного намерения.

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

Гэри выбрал одну, и после этого мы наконец приступили к составлению историй.

Вот разные пользователи Mad Mimi, которых описал Гэри. Уже простое перечисление их типов и краткие списки задач помогли понять, что тут многовато всего. Даже не начав обсуждать функциональность, мы решили отложить разработку для некоторых типов пользователей.