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

Шаблонные зомби и снегоочиститель

Термин «шаблонные зомби» впервые появился в книге Тома Де-Марко и его соавторов «Адреналиновые наркоманы и шаблонные зомби: понимание паттернов поведения проектов»[16]. Название говорит само за себя, но я приведу и авторское определение.

«Шаблонный зомби: проектная команда допускает, чтобы работа управлялась шаблонами, а не направляет процесс осознанно, чтобы обеспечить выпуск продукта наилучшим образом».

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

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

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

История может быть историей, даже если она составлена не по шаблону.

Человек на этой фотографии учиться кататься на горных лыжах[17]. Если вы когда-нибудь тоже этому учились и вам помогал инструктор, то вы хорошо знаете, что делает этот человек. Он выполняет прием торможения «плугом» – сводит носки лыж вместе и скользит на внутренних ребрах. Это самый простой способ контролировать скорость и оставаться в вертикальном положении, несмотря на то что к вашим ногам прикреплены две скользкие доски. Это самый лучший прием для начинающих лыжников. Но это не просто самый лучший прием – это самый лучший обучающий прием. В программе соревнований горнолыжников на Олимпийских играх нет упражнения «плуг». Ни один катающийся на склоне горы не будет восхищен вашим великолепным исполнением «плуга». Но, разумеется, стесняться здесь нечего. Видя, что вы катаетесь таким способом, все понимают, что вы новичок и пока учитесь.

Мне кажется, шаблоны историй работают точно так же, как «плуг». Используйте их, чтобы составлять описания к своим первым историям. Читайте их вслух, чтобы инициировать обсуждение. Но не слишком расстраивайтесь, если однажды обнаружится, что они работают не всегда. Как и техника «плуга» для горнолыжников, это не лучший выбор для сложного пути.

Мой любимый шаблон: если я записываю истории на стикерах или карточках и они не отправляются сразу же на большую сложную карту, то я даю им простые короткие названия, а затем записываю под ними:

Кто:

Что:

Почему:

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

Чек-лист: о чем говорить

 По-настоящему обсудите «Кто?». Пожалуйста, не говорите о пользователях вообще. Будьте конкретны. Ясно называйте тех пользователей, которых подразумеваете. Например, с Гэри мы говорили об администраторе группы или ее фанатах.

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

Говорите о заказчиках. В случае разработки коммерческих продуктов заказчик (или лицо, принимающее решение о покупке) зачастую может быть одновременно и пользователем. Но, рассматривая корпоративные продукты, необходимо обсуждать также тех, кто принимает решение, организацию в целом и выгоды, которые они получают.