Идея историй на самом деле очень проста. Может быть, даже слишком проста. Множество людей, занятых в разработке программного обеспечения, воспринимают обсуждения как что-то очень непривычное… и, может быть, даже слегка неприятное. В результате многие скатываются к простому обсуждению требований, к которому они привыкли.
Когда Кент Бек впервые сформулировал идею историй, он не называл их пользовательскими историями, а просто употреблял слово «истории» – именно их, как он надеялся, вы будете составлять. Но вскоре после того, как были изданы его первые книги по экстремальному программированию, термин «истории» получил полезное уточнение «пользовательские» – таким образом, мы не забываем, что обсуждение должно вестись с точки зрения людей, находящихся вне программного продукта. Но, как оказалось, недостаточно лишь изменить имя.
Классный шаблон Connextra
Это моя подруга Рэчел Дэвис. У нее в руках карточка историй.
В конце 1990-х Рэчел работала в компании под названием Connextra, которая была одним из первых адептов экстремального программирования, процесса Agile, откуда берут свое начало истории. Когда работники Connextra начали использовать истории, почти сразу обнаружились несколько распространенных проблем. Большинство людей, которые составляли в Connextra истории, работали в отделах продаж и маркетинга, поэтому они были склонны просто записывать функциональности, нужные пользователям. Но когда приходило время дискуссий между разработчиками, им приходилось искать того, кто предложил функциональность, и начинать настоящее обсуждение, включающее все «Для кого?» и «Почему?». Простая запись названия функциональности никак не помогала им понять, с какими людьми следует поговорить, или начать правильное обсуждение. Кроме того, в то время не было достаточного количества информации о том, что может или должно быть на карточках. Шаблон развивался в Connextra постепенно, с течением времени. Он был детищем не одной Рэчел, а скорее являлся следствием желания всей организации создавать по-настоящему значительные вещи.
Ребята из Connextra использовали этот шаблон некоторое время, а потом захотели поделиться своим замечательным изобретением с другими. Они напечатали стопку карт-образцов, которые продемонстрировали на XPDay 2001, небольшой конференции в Лондоне. На фотографии Рэчел держит именно такую карточку. Это последняя карточка из того набора и, возможно, последняя из существующих, поэтому ее можно назвать историческим памятником.
Вот как выглядит этот шаблон:
Как [тип пользователя], я хочу [сделать то-то и то-то], таким образом я смогу [получить такую-то выгоду].
Ребята из Connextra использовали этот простой шаблон для составления описаний своих историй. Они обнаружили, что написание этого небольшого дополнения перед началом изложения истории помогает им остановиться на минуту и сформулировать для себя: для кого, что, почему. И если выяснится, что данных недостаточно, составление истории оказывается под вопросом.
Когда приходит время начать обсуждение истории, ребята берут эти карточки и читают описания, которые дают отправную точку для дискуссии.
Используйте простой шаблон историй, чтобы открыть обсуждение.
Если у вас есть отдельная карточка, не принадлежащая карте историй, то шаблон – отличный способ завязать обсуждение. Помните, в главе 1 я упомянул одну из карточек в карте Гэри, где было написано: «Загрузить изображение»? Эта карточка была одной из деталей шага «Отредактировать рассылку». Я всегда пишу на карточках, составляющих карту, такие короткие глагольные фразы – они означают действия, которые люди выполняют, используя мой продукт. Но когда я рассматриваю какую-то карточку в отдельности, мне нужно увидеть историю внутри большого путешествия пользователя по продукту, которое представляет собой карта. Поэтому я могу сказать: «Как администратор музыкальной группы, я хочу загрузить изображение и отредактировать свою рассылку таким образом».
Это очень эффективный прием. Выше карты могут находиться листочки с действиями разных типов пользователей, а цель пользователя записывается на карточке, находящейся выше той, на которую вы смотрите в данный момент.
Но не забывайте, это только запуск обсуждения. Продолжиться оно должно примерно так.
• «Почему администратору группы может понадобиться отредактировать рассылку?»
• «Ну, наверное, потому, что на рассылке должно быть фото группы, а оно там не появляется автоматически. Кроме того, администратор, вероятно, хочет, чтобы его рассылка выделялась и привлекала внимание – кому интересны стандартные рекламки?»
• «Это звучит разумно. А где, как вы думаете, люди наподобие администраторов хранят такие фотографии?»
• «Да где угодно. Они могут быть на жестком диске компьютера, в аккаунте Flickr и вообще в любом месте в Интернете».
• «Да? Признаться, я об этом не думал, я предполагал, что они хранят их только на жестких дисках».
• «Нет, много людей, с которыми мы говорили, хранят фотографии в самых разных местах. Наверное, стоит это учесть».
Именно так и выглядели большинство моих дискуссий с Гэри. По мере обсуждения мы делали записи на доске или на самих карточках, а вскоре начали даже рисовать эскизы наших идей.
Как видите, этот короткий шаблон совершенно не годится для того, чтобы служить спецификацией. Но когда мы используем его, чтобы начать обсуждение, оно идет куда живее и активнее, чем если бы мы просто начали говорить о загрузке файлов.
Как вновь открыть для себя ценность коротких обсуждений
Мэт Кроппер, ThoughtWorks
Я работал в компании ThoughtWorks бизнес-аналитиком на проекте для правительственного агентства Великобритании. Мы несли ответственность не только за предъявление продукта, но и за обучение команды клиента некоторым практическим приемам методологии Agile. Это было не так-то просто, ведь у нас была большая команда – около 25 технологических или бизнес-специалистов. Представьте себе 25 человек в одной комнате, у каждого свои пожелания о режиме кондиционера, и вы поймете, в какой ситуации мы оказались.
Мы с владельцем продукта договорились, что напишем истории, а потом в начале двухнедельной итерации вся команда соберется и распланирует разработку. В силу необходимости на этом совещании присутствовало очень много людей, что и привело к полному провалу.
«Почему мы должны делать вот так?»
«Эти истории слишком длинные/короткие».
«В этом нет никакого смысла!»
«Я настаиваю, чтобы техническая реализация данного аспекта выполнялась вот так и никак иначе».
Это был долгий и утомительный спор. Честно признаюсь, уходя с совещания, я чувствовал себя ужасно и воспринял все происходившее как личное поражение.
Однако следовало что-то предпринять, чтобы все исправить, и мы решили от одного общего совещания, где обсуждалось бы все и сразу, перейти к небольшим, более фокусированным обсуждениям. Например, на первой неделе итерации мы привели в порядок бэклог. Это сделала небольшая группа людей (владелец продукта, менеджер проекта, бизнес-аналитик и технический архитектор), которые выступали в роли пользователей различных историй. В результате, когда мы позднее формировали итоговый бэклог с участием всей команды, недоумения и недовольства было куда меньше. На этих встречах мы скорректировали и усовершенствовали наши истории, а, например, расстановку приоритетов и оценку сложности реализации проигнорировали. Это сработало.
Мы также старались, чтобы процесс создания историй был более конструктивным. Если у меня возникали какие-то идеи по поводу истории, над которой я работал, я размещал их в верхней части доски с карточками в колонке «Анализ». Каждый день на совещании нашей команды я рассказывал о своей работе над конкретной историей и мог попросить кого-то из команды разработчиков уделить мне время. Мы садились и обсуждали, в каком направлении пойдет работа, как правило затрагивая технические аспекты, а затем записывали все это на бумаге. Мы не использовали Trello, где обычно хранилась наша доска с карточками в электронном виде, а вместо этого концентрировались на личных обсуждениях, иногда с помощью доски для записей. Работа в маленькой группе с глубоким погружением в детали очень полезна, а поскольку это обсуждение редко продолжалось больше 20 минут, оно никому не доставляло неудобств. Всем очень понравилось сотрудничать, содействуя общему делу.
К счастью, огромные совещания по наполнению бэклога ушли в прошлое. Кроме того, мы обнаружили, что размер историй постепенно становится постоянным. В результате этого планирование итераций проходило куда легче, а обсуждения стали более активными. Соответственно, возросло качество документирования историй и качество всей нашей работы.
Шаблонные зомби и снегоочиститель
Термин «шаблонные зомби» впервые появился в книге Тома Де-Марко и его соавторов «Адреналиновые наркоманы и шаблонные зомби: понимание паттернов поведения проектов». Название говорит само за себя, но я приведу и авторское определение.
«Шаблонный зомби: проектная команда допускает, чтобы работа управлялась шаблонами, а не направляет процесс осознанно, чтобы обеспечить выпуск продукта наилучшим образом».
Мы, в принципе, склонны злоупотреблять простотой использования таких вещей, как шаблон. Я неоднократно наблюдал, как люди мучаются, изо всех сил пытаясь впихнуть в шаблон идеи, которые в него не помещаются. Истории работы серверной части или функций, обеспечивающих безопасность данных, не так-то легко составить. Я также видел, как люди пишут и думают, ориентируясь на собственное представление о чем-то, а не на точку зрения людей, которые должны получить выгоду: «Как владелец продукта, я хочу, чтобы вы сделали кнопку для загрузки файла, таким образом мы удовлетворим требования заказчика». Просто ужас.
И это еще не самое худшее! По мере роста популярности универсальных шаблонов у некоторых людей складывается впечатление, что история не история, если она не записана по форме. Многие даже отказываются от использования заголовков и пишут на каждой карточке только длинные предложения по шаблону. Представьте себе, как бы вы пытались прочесть список историй, записанных таким образом. Представьте, как кто-то читает историю с помощью карты историй, где так выглядит каждый стикер. Ни один мозг этого не выдержит.
Все это меня бесконечно огорчает. Ведь истинная ценность историй не в том, что записано на карточке, – она заключается в том, что мы изучили и осознали, излагая историю.
История может быть историей, даже если она составлена не по шаблону.
Человек на этой фотографии учиться кататься на горных лыжах. Если вы когда-нибудь тоже этому учились и вам помогал инструктор, то вы хорошо знаете, что делает этот человек. Он выполняет прием торможения «плугом» – сводит носки лыж вместе и скользит на внутренних ребрах. Это самый простой способ контролировать скорость и оставаться в вертикальном положении, несмотря на то что к вашим ногам прикреплены две скользкие доски. Это самый лучший прием для начинающих лыжников. Но это не просто самый лучший прием – это самый лучший обучающий прием. В программе соревнований горнолыжников на Олимпийских играх нет упражнения «плуг». Ни один катающийся на склоне горы не будет восхищен вашим великолепным исполнением «плуга». Но, разумеется, стесняться здесь нечего. Видя, что вы катаетесь таким способом, все понимают, что вы новичок и пока учитесь.
Мне кажется, шаблоны историй работают точно так же, как «плуг». Используйте их, чтобы составлять описания к своим первым историям. Читайте их вслух, чтобы инициировать обсуждение. Но не слишком расстраивайтесь, если однажды обнаружится, что они работают не всегда. Как и техника «плуга» для горнолыжников, это не лучший выбор для сложного пути.
Мой любимый шаблон: если я записываю истории на стикерах или карточках и они не отправляются сразу же на большую сложную карту, то я даю им простые короткие названия, а затем записываю под ними:
Кто:
Что:
Почему:
Под каждый ответ отводится несколько строчек, ведь нужно перечислить каждого конкретного «Кто?», немного рассказать о «Что?», а также привести несколько различных причин для «Почему?». Кроме того, я люблю оставить на карточке место, чтобы добавить еще немного информации после того, как мы начнем обсуждать эту историю. Меня ужасно раздражает, когда некоторые пишут название истории прямо посередине карточки, ведь теперь на ней нельзя сделать никаких пометок! Но, конечно, тут я уже придираюсь.
Чек-лист: о чем говорить
По-настоящему обсудите «Кто?». Пожалуйста, не говорите о пользователях вообще. Будьте конкретны. Ясно называйте тех пользователей, которых подразумеваете. Например, с Гэри мы говорили об администраторе группы или ее фанатах.
Говорите о разных типах пользователей. У многих видов программного обеспечения, особенно коммерческого, существует множество типов пользователей, работающих с одной и той же функциональностью. Обсудите функциональность с точки зрения разных пользователей.
Говорите о заказчиках. В случае разработки коммерческих продуктов заказчик (или лицо, принимающее решение о покупке) зачастую может быть одновременно и пользователем. Но, рассматривая корпоративные продукты, необходимо обсуждать также тех, кто принимает решение, организацию в целом и выгоды, которые они получают.
Говорите обо всех заинтересованных сторонах. Обсуждайте людей, спонсирующих покупку программы. Говорите о других людях, которые могут сотрудничать с вашими пользователями.
Случаи, когда можно учитывать только одного пользователя, очень редки.
Как следует обсудите «Что?». Я очень люблю, когда истории начинаются с пользовательских задач – действий, которые пользователи хотят выполнить, применив мой программный продукт. Но что же делать с сервисами, работа которых не видна в пользовательском интерфейсе, – теми, которые авторизуют вашу кредитную карту для покупки или пускают вас на сайт страховки? Вашим пользователям не приходится явно делать выбор, чтобы авторизовать свои кредитные карты или подтвердить введенные данные для авторизации. Поэтому не только можно, но и нужно обсудить самые разные сервисы и системы, которые могут их вызывать. Стоит также рассмотреть особые компоненты UI и поведение экрана. Просто не упускайте из виду заинтересованных людей и их мотивы.
По-настоящему обсудите «Почему?». Обговорите самые разные заботы и нужды пользователей. Как следует погрузитесь в «Почему?», потому что, как правило, их несколько и они накладываются друг на друга. Можно очень долго «тыкать их палочкой», чтобы наконец выявить истинные мотивы, лежащие в основе всего.
Обсудите мотивы других пользователей. Обсудите мотивы компании, в которой работают пользователи. Обсудите мотивы всех сторон, заинтересованных в бизнесе. Исследуя «Почему?», можно сделать множество интереснейших открытий.
Обсудите то, что происходит за рамками программного обеспечения. Подумайте, где и когда люди могут использовать ваш продукт, как часто они это делают. Представьте себе, кто еще может присутствовать при использовании продукта. Все эти факторы могут вам помочь нащупать наилучшее решение.
Обсудите, что произойдет, если все пойдет не так. Что будет, если произойдет какой-то сбой? Что случится, если система вдруг прекратит работу? Какими альтернативными способами пользователи могут достичь своих целей? Как они удовлетворяют свои нужды сейчас?
Обсудите вопросы и предположения. Если вы проговорите все это, то, скорее всего, столкнетесь со многими вещами, о которых не знаете. Сформулируйте свои вопросы и обсудите, насколько важно получить ответы перед тем, как приступить к работе над программным обеспечением. Нужно решить, кто проделает все необходимое для получения информации, и сохранить вопросы до следующего обсуждения. Как вы убедитесь, порой для полного рассмотрения некоторых историй требуется очень долго их обсуждать.
Запланируйте время на проверку своих предположений. Действительно ли вы понимаете пользователей? Вы точно знаете, чего они хотят? Реальны ли их проблемы? Смогут ли они, используя ваше решение, справиться с этими проблемами?
Рассмотрите также свои технические предположения. На какие базовые системы мы полагаемся? Будут ли они в самом деле работать так, как мы планируем? Есть ли какие-то технические риски, которые необходимо учесть?
Все эти вопросы и предположения могут потребовать дополнительного исследования или изучения. Составьте для этого особый план.
Обсудите вероятность нахождения лучшего решения. По-настоящему крутые результаты получаются тогда, когда в ходе обсуждения истории участники отклоняют первоначальные предположения о том, каким должно быть решение, возвращаются к рассматриваемой проблеме, а затем все вместе приходят к другому решению, более эффективному и экономичному в реализации.
Обсудите «Как?». Очень часто, присутствуя на обсуждении историй, я слышу чей-то раздраженный голос: «Мы должны обсуждать, что мы делаем, а не как!». Под этим обычно подразумевается, что нужно обсуждать действия и мотивы пользователей, а не код, который необходимо написать. А я чувствую точно такое же раздражение, когда мы говорим только о «Что?», не затрагивая «Почему?». В действительности при хорошем обсуждении мы стремимся к оптимизации всех трех составляющих. На самом деле нехорошо, когда кто-то предполагает, что определенное решение или какой-то способ технической реализации является требованием. Поэтому без явного обсуждения «Как?» (а если вы разработчик, вы неизбежно думаете об этом аспекте) очень трудно оценить стоимость решения. А слишком дорогое решение никак не может быть наилучшим.
Уважительно относитесь к опыту и компетентности других участников обсуждения. Не стоит указывать высококвалифицированному техническому специалисту, как ему делать свою работу. Не говорите кому-то хорошо знакомому с пользователями и их работой, что он ничего не понимает. Задавайте вопросы и искренне пытайтесь научиться чему-то друг у друга.
Обсудите, сколько времени понадобится. В конце концов все-таки приходится принять несколько решений, чтобы продвинуться вперед и что-то построить или не построить. Эту ситуацию можно сравнить с решением о покупке товара, не имеющего ярлычка с ценой.
В мире программного обеспечения понятие стоимости в первую очередь связано с временем, которое потребуется на написание кода. На ранних этапах вполне допустимо использовать понятия «очень долго» или «пару дней». Еще лучше сравнить то, что вы обсуждаете, с чем-то уже законченным: «Это похоже на те улучшения для комментариев, которые мы реализовали в прошлом месяце». По мере того как мы все ближе подбираемся к началу разработки, все дольше обсуждаем и принимаем все больше решений, оценки трудозатрат должны становиться все более точными. Но не забывайте: в любом случае мы говорим лишь об оценках, а не об обязательствах.
Сделайте «фото из отпуска»
Поскольку нужно очень многое обсудить и хорошо бы ничего не забыть, убедитесь: вы записали самое важное, что позволит позднее припомнить принятые решения, а также вопросы и предположения, в которых следует хорошенько разобраться. Не забудьте озвучивать ход своих мыслей, чтобы и все остальные понимали, что записывается.
Если вы пишете на бумаге, прихватите ее с собой и заглядывайте в нее позднее. Если записи сделаны на стене, можно просто обращаться к ним по мере надобности. Кроме того, если вы общаетесь как настоящая команда, то обнаружите, что вам не нужно беспрестанно все повторять. Люди и так будут помнить подробности обсуждения, особенно если вы сопровождали его документами и простыми рисунками… теми самыми «фото из отпуска».
Эта небольшая группа сейчас обсуждает историю. По мере обсуждения они визуализируют свои идеи и делают заметки о решениях.
Мой любимый подход именно такой. Я делаю записи на большом листе бумаги или доске прямо во время разговора. Я люблю сделать прямо на доске пометку о том, кто присутствовал на обсуждении, а затем фотографирую свои записи. Затем любым способом отправляю фото всем присутствующим. Я хорошо знаю, что в любую минуту могу припомнить детали или записать их более формально, если вдруг понадобится. Если у меня не получится точно припомнить, что было сказано, наверняка это вспомнит другой участник обсуждения: я всегда знал, что записывать имена участников – хорошая идея.
Придется о многом позаботиться
Да, обсуждение истории включает в себя множество составляющих, и это может немного пугать. В этот момент вы, возможно, с тоской вспоминаете старые добрые времена, когда все, что вам нужно было, – это правильно понять требования, и хотите вернуться туда, где вам не приходилось по-настоящему решать задачи. Вы просто должны были создать, что сказано, а о том, правильны ли инструкции, заботился кто-то другой. Но я уверен, что на самом деле и вам, и почти всем прочим людям нравится решать проблемы. Так что это ваш шанс.
Возможно, обсудив все, о чем мы здесь говорили, вы получите огромный объем информации, которую необходимо хранить и отслеживать, а на стикеры или карточки она никак не помещается. Все в порядке. Так и должно быть. Давайте поговорим о том, что необходимо писать на карточке, а чем можно пренебречь.