Kitobni o'qish: «Пользовательские истории. Искусство гибкой разработки ПО»

Посвящается Стейси, Грейс и Зоэ. Без вашей поддержки у меня ничего бы не вышло.

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

© ООО Издательство "Питер", 2017

Предисловие Мартина Фаулера

Одно из самых выгодных последствий популярности разработки программного обеспечения (ПО) по методологии Agile – распространение идеи разбиения больших, объемных требований на компактные фрагменты. Благодаря этим фрагментам – историям – отслеживать прогресс разработки проекта намного проще. Когда истории реализуют постепенно, каждый раз полностью интегрируя их в проект, всем очевидно, что проект понемногу растет. Рассматривая истории, которые приносят пользователям очевидную выгоду, разработчики могут планировать развитие проекта и определять, над чем нужно работать в следующую очередь. К тому же такая прозрачность подталкивает пользователей к активному участию в разработке – они больше не гадают месяцами и годами, чем занята команда разработки.

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

Построение карт историй (story mapping) – это техника, позволяющая увидеть цельную картину, чего не удастся сделать с помощью простого набора историй.

Вот, собственно, и все – описание книги уместилось в одном предложении, но этого вполне достаточно, чтобы оценить преимущества метода. Обзор цельной картины облегчает взаимодействие с пользователями, позволяет избежать разработки ненужных функций, а также ориентирует на релевантный опыт использования. Когда я обсуждаю с коллегами по Thought-Works применяемый ими процесс разработки пользовательских историй, построение карт регулярно упоминается в качестве основной техники. Часто оказывается, что коллеги изучили эту технику как раз на семинарах Джеффа, поскольку именно он разработал ее и лучше всего может ей обучить. С помощью данной книги еще больше людей смогут узнать об этой технике непосредственно из первых уст.

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

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

Мартин Фаулер, 18 июня 2014 года

Предисловие Алана Купера

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

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

Более чем разумно программировать только одну функциональность ПО в каждый момент времени. Это идеальная стратегия, проверенная временем. Кроме того, многолетним опытом разработки было доказано, что использование такого подхода при проектировании цифровых продуктов, как одна функциональность в каждый момент времени, порождает монстров, подобных Франкенштейну, а не качественные программы.

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

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

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

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

Метод построения карт историй, созданный Джеффом, находят полезным разработчики, и точно так же его оценивают дизайнеры. Карты историй – Розеттский камень нашего цифрового века.

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

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

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

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

Алан Купер, 17 июня 2014 года

Предисловие Марти Когана

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

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

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

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

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

С благодарностью в адрес Бена Хоровица и его книги «Хороший менеджер продукта, плохой менеджер продукта» я приведу здесь лишь важнейшие различия между сильными и слабыми командами.

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

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

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

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

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

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

• Хорошие команды постоянно пробуют новые идеи и вводят различные усовершенствования, но делают это осторожно, чтобы не навредить эффективности бизнеса. Плохие команды ждут разрешения что-то попробовать.

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

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

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

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

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

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

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

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

• Хорошие команды концентрируются на своей целевой аудитории. Плохие команды концентрируются на конкурентах.

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

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

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

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

Марти Коган, 18 июня 2014 года

Об авторе

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

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

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

В настоящее время Джефф работает как независимый консультант, тренер процессов Agile, тренер процессов дизайна продуктов и инструктор. Множество статей, эссе и презентаций, посвященных различным аспектам разработки продуктов Agile, можно найти на сайте agileproductdesign.com и в Crystal Clear Алистера Коберна. Джефф – основатель и модератор дискуссионной группы Yahoo! по теме юзабилити в Agile, колумнист в StickyMinds.com и IEEE Software, сертифицированный тренер Scrum, а также обладатель премии Agile Alliance’s 2007 Gordon Pask за вклад в развитие Agile.

Вступление

 
Живи в этом, плавай в этом, смейся в этом, люби в этом,
А еще оно уберет подозрительные пятна с простыней,
Развлечет во время визита к родным
И превратит сэндвич в банкет.
 

Том Уэйтс. Проходите, не стесняйтесь

На самом деле эта книга должна была быть совсем небольшой… чем-то вроде памфлета.

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

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

Составлять карты до смешного просто. Работая вместе с другими, я озвучиваю историю работы с продуктом, записывая каждый шаг, предпринимаемый пользователем, на листочках-стикерах и наклеивая их слева направо. Затем мы возвращаемся к началу и обсуждаем каждый шаг в деталях, записывая подробности на листочках и наклеивая их сверху вниз под соответствующим шагом. В результате получается простая, напоминающая таблицу структура, излагающая историю слева направо и раскрывающая детали сверху вниз. Быстро и очень интересно. А эти детали образуют бэклог (backlog)¹ историй для наших проектов, разрабатываемых по Agile.

Сложно ли написать об этом книгу?

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

Если вы используете процесс разработки, описанный в методологии Agile, то ваши бэклоги и так, наверное, заполнены пользовательскими историями (user story). Я думал: раз создание историй является настолько распространенной практикой, писать о них книгу будет напрасной тратой времени. Но, как оказалось, я ошибался. Через полтора десятилетия после того, как истории впервые были описаны Кентом Беком, они стали наиболее популярны, а также наименее правильно понимаемы и используемы, чем когда-либо. Это меня огорчает. А главное, это сводит на нет все выгоды, которые мы получаем от составления карт историй.

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

Почему я?

Я люблю создавать. Когда я разрабатываю какую-нибудь функциональность для программного обеспечения, а люди с удовольствием ею пользуются, это очень радует и мотивирует меня. И я не слишком люблю методологии. Я бы сказал, мне надо разобраться в принципе какой-то методики или практики, чтобы как следует ею овладеть. Только сейчас, имея более чем 20-летний опыт разработки программного обеспечения, я начинаю понимать, как учить других тому, что умею сам. Я также понимаю, что то, чему я учу, постоянно меняется. На этой неделе я что-то изучил, а на следующей оно уже изменилось. Способы объяснить это другим людям меняются почти так же часто. Все это многие годы удерживало меня от написания книги.

Но время наконец пришло.

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

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

Если вы используете истории и страдаете, эта книга – для вас

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

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

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

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

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

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

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

Для кого еще эта книга

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

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

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

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

 Тренеры процессов Agile и Lean, если они хотят помогать командам и отдельным людям действовать эффективнее, должны прочесть эту книгу. Кроме того, подумайте только, насколько неверное представление об историях сформировалось у сотрудников вашей организации! Применяйте истории, простые упражнения и практики, описанные в этой книге, чтобы помочь вашим командам развиваться.

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

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

А если это все-таки вы, давайте начнем.

Используемые соглашения

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

Подзаголовки внутри каждой главы будут подсказывать вам направление темы

Обращайте на них внимание, чтобы найти что-либо нужное или пропустить материал, неинтересный вам в данный момент.

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

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

Врезки используются для описания:

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

• конкретных упражнений. Вы сможете использовать их, чтобы начать практиковаться в чем-либо специфическом;

• историй и примеров, предоставленных другими. Возможно, вы почерпнете из них хорошие идеи и сможете применить их в своей компании.

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

Как устроена эта книга

Однажды я купил замечательный лазерный принтер. Первое, что я увидел, открыв коробку, был бумажный буклет, на котором красовалась надпись большими яркими буквами: «СНАЧАЛА ПРОЧТИТЕ ЭТО». Я задумался, стоит ли так поступать на самом деле, ведь, как правило, я пренебрегаю инструкциями. Но позже очень радовался, что послушался этого предупреждения, потому что, как оказалось, в разных местах внутри принтера было закреплено много пластиковых деталей, чтобы уберечь его от повреждений при транспортировке, и, если бы я включил принтер, не убрав их, скорее всего, он был бы безнадежно испорчен.

Эта история, наверное, кажется здесь неуместной, но это не так.

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

Построение карт историй с высоты птичьего полета

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

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

Интуитивное понимание пользовательских историй

В главах 6–12 рассказано многое о пользовательских историях: как они работают в реальности, как организовать их использование в проектах Agile или Lean наилучшим образом. В дополнение к картам историй там приведены несколько маленьких примеров, которые могут оказаться полезными в ежедневной практике разработки. Даже если вы ветеран Agile, обещаю, вы узнаете об историях что-то новое для себя. А если вы в историях новичок, то узнаете достаточно, чтобы поразить самого заносчивого Agile-всезнайку в офисе.

Лучшие бэклоги

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

Лучшая разработка

Главы 16–18 шаг за шагом посвятят вас в тонкости тактики использования историй. Вы научитесь доводить истории до конца, не упускать их из виду в процессе разработки, добиваться их точного исполнения, а также извлекать опыт из каждой истории, трансформированной вами в рабочее ПО.

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

Перейдем к делу.

Сначала прочтите это

В этой книге нет введения.

Да, вы все прочитали правильно. И сейчас, наверное, задаетесь вопросом: «Почему же в книге Джеффа нет введения? Может быть, он забыл его написать? Не пора ли ему на покой? Или введение съела его собака?»

Нет, я не забыл написать введение. И мне не пора на покой (по крайней мере я туда не собираюсь). И моя собака не съедала введения, хотя насчет морской свинки своей дочери я не был бы так уверен. Это просто потому, что за долгое время я убедился: авторы тратят кучу времени, пытаясь убедить меня прочесть их книгу, и большая часть этого времени приходится на введение. Самое интересное во всех книгах начинается примерно с третьей главы. Кроме того, я уверен, что не я один всегда пропускаю введение.

Так что эта книга начинается прямо здесь.

И вам ни в коем случае нельзя пропускать эту часть, так как на самом деле она самая важная. Я буду доволен, если вы вынесете из книги всего две мысли. Вот эти две мысли.

• Цель работы с историями не написание идеальных историй.

• Цель разработки продуктов не создание продуктов.

Сейчас я все объясню.

Игра в испорченный телефон

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

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

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

Перед вами обложка книги Джен Ятис «Торты, которым не повезло», опубликованной в издательстве Эндрю Мак-Милла (спасибо Джен и Джону Ятис за предоставление иллюстрации). Книга получилась по мотивам ее очень забавного сайта cakewrecks.com (только не ходите туда, если у вас нет по меньшей мере часа свободного времени). На сайте собрана коллекция по-идиотски украшенных тортов, логика их создателей не поддается объяснению, хотя Джен и предпринимает попытки сделать это. Так, одна из самых часто встречающихся и в книге, и на сайте тем – неверно понятые требования. Джен, конечно, не называет их требованиями, ведь это слишком формальный термин, вместо этого она употребляет слово «записи», так как исполнитель слушает и записывает, понимая буквально то, что слышит. Глядя на эти фото, я могу вообразить сотрудника кондитерской, который слушает заказчика и записывает его пожелания, а потом передает их кому-то, кто будет украшать торт.

Заказчик: «Здравствуйте, я хотел бы заказать торт».

Работник: «Конечно, что бы вы хотели на нем написать?»

З.: «Вы могли бы написать “Всего хорошего, Алиса” фиолетовым цветом?»

Р.: «Конечно».

З.: «А вокруг надписи пусть будут звезды».

Р.: «Без проблем. Я записал ваши пожелания и прямо сейчас передам их кондитеру-декоратору. Торт будет готов к завтрашнему утру».

Вот что получилось в результате.

Вот еще один пример. В разработке программного обеспечения такие вещи мы называем нефункциональными требованиями.

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

Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов²? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.

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

Общие документы не дают единого понимания.

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

Единое (общее) понимание – это когда мы оба хорошо понимаем, что и почему представляет себе каждый. Очевидно, что между кондитерами и людьми, дававшими им инструкции, такого понимания не было. И в NASA какой-то важный начальник не обеспечил одинакового понимания того, как работает система управления, всеми участниками процесса. Уверен, если вы трудитесь в сфере разработки ПО, то быстро вспомните аналогичную ситуацию: два человека были уверены, что пришли к соглашению относительно функции, которую хотели добавить в проект, но оказалось, что они представляли себе совершенно разные вещи.

Единое понимание – это невероятно просто

Мой бывший коллега Люк Баррет первым показал мне этот комикс, чтобы описать проблему. Я спросил, где он его видел, но он так и не вспомнил (кто-то, возможно, не получает авторских отчислений). Годами я наблюдал, как Люк демонстрирует эти четыре слайда в презентации PowerPoint, и всегда воспринимал их как нечто забавное, но довольно банальное. Видимо, я туговато соображаю: лишь много лет спустя осознал, что этот комикс иллюстрирует, наверное, самую важную особенность работы с историями при разработке ПО.

Суть в том, что если у меня есть какая-то идея, я ее записываю на бумаге, а вы затем это читаете, то вполне можете представить что-то совершенно иное, чем я. При этом можно спросить каждого: «Вы согласны с содержанием этого документа?», и все дружно ответят: «Да! Да, мы согласны!» Но если мы соберемся вместе и начнем обсуждение, вы можете описать мне, что думаете, а я смогу задать вопросы. Беседа пойдет живей, если мы можем описать наши мысли, рисуя картинки либо фиксируя идеи на стикерах или карточках. Если у каждого из нас будет возможность объяснить свои мысли с помощью слов и картинок, мы придем к общему мнению. Однако здесь мы осознаем, что все понимают всё по-разному, и это очень неприятно. Но по крайней мере теперь проблема известна.

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

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

Перестаньте пытаться написать идеальную документацию

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

Правильный ответ: просто не занимайтесь документами.

Перестаньте пытаться составлять идеальные документы.

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

Истинная цель использования историй – достижение единого понимания.

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

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

Хорошие документы похожи на фотографии из отпуска

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

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

Хорошо это или плохо, но именно так работают документы.

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

Документируйте, чтобы активизировать воспоминания

Я пару раз слышал шутку: «Мы перестали писать документацию, и поэтому у нас теперь Agile». Это называется: кто знает – тот поймет, потому что на самом деле процесс, управляемый историями, требует для работы множества документов. Но зачастую эти документы совсем не похожи на традиционные задокументированные требования.

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

Когда вы описываете историю, почти все может быть использовано как инструмент коммуникации. А поскольку мы обсуждаем истории, пишем массу заметок и рисуем кипы рисунков, надо их где-то хранить. Мы складываем их, чтобы позднее просмотреть, фотографируем, включаем в разные документы.

Но помните: самое важное и нигде не записанное – это то, что мы вспомним при прочтении. Вот он, фактор фотографии из отпуска.

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

Чтобы облегчить вспоминание, фотографируйте, а также записывайте короткие видео по результатам обсуждений.

Обсуждайте то, что действительно нужно

Многие люди уверены, что их работа – формирование и сбор требований. Но это не так.

На самом деле ваша работа – изменить мир.

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

До и после

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

Вот как я изображаю эту модель.

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

• Какие новые продукты вы можете создать.

• Какие функции добавить в существующий продукт.

• Как улучшить создаваемые продукты.

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

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

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

Суть не в программах

Все, что находится между идеей и выпуском продукта в свет, называется объемом работы. Это то, что мы создаем. Люди, занятые разработкой программного обеспечения по Agile, обычно измеряют скорость работы и стараются увеличить ее. Те, кто создает ПО, разумеется, беспокоятся о стоимости готового продукта, в том числе о временных затратах на его создание, планируемых и реальных.

Но в таком случае объем работы не является основным, ведь мы заботимся не о количестве работы. Нас интересует то, что получается в итоге, – реальный результат. Реальный результат – то, что получается в результате работы (отсюда и название), и его нелегко оценить, поскольку невозможно измерить результат, не доведя работу до конца. Кроме того, реальный результат нельзя измерить количеством добавленных функций или новыми возможностями, предъявленными пользователям. По сути, мы фиксируем, что именно люди делают иначе для достижения своей цели теперь, в результате сделанных вами изменений, и, самое главное, стала ли их жизнь несколько лучше³.

Ну вот вы и изменили мир.

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

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

Плодотворное обсуждение историй включает в себя вопросы «Для кого?» и «Почему?», а не только «Что?».

Ладно, не только о людях

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

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

ваша компания не получит того, чего хочет, пока заказчики или пользователи не получат того, чего хотят они.

Развитием процесса становится выбор людей, на которых мы будем фокусироваться, проблем, которые нужно решить, а затем идей, которые можно внедрить в работающее ПО. После этого – если заказчики покупают, пользователи используют и все они довольны, – бизнес, который спонсировал данную разработку, начинает получать выгоду. Это может выразиться в возрастании прибыли, снижении издержек, повышении лояльности заказчиков, увеличении доли рынка. Таким образом, многие сотрудники вашей компании получают удовлетворение. Это и вас должно порадовать, ведь вы только что помогли своей компании получить выгоду, одновременно принеся пользу реальным людям. Это стратегия «вин-вин», или стратегия обоюдной выгоды.

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

Программируйте меньше

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

у нас никогда не будет достаточно времени или ресурсов, чтобы разработать все, что нужно, – никогда!

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

Минимизируйте объем работы, максимально увеличивайте результат и долгосрочный эффект.

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

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

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

Страшные слова на букву «Т»

На протяжении почти всего первого десятилетия моей карьеры в IT, которое я провел за созданием ПО для розничной торговли, я вообще обходился без слова «требования» – ну или очень редко его слышал. Этот термин попросту не годился для обозначения того, что я делал. У меня было множество отдельных заказчиков, каждый из которых имел собственное представление о том, что ему подходит. Также я всегда помнил, что работаю на компанию, которая делает деньги, продавая мой продукт. Фактически я проводил долгие часы на выставках, помогая компании продавать наш продукт широкому кругу покупателей. В конце дня я знал, что мне придется работать с этими заказчиками после того, как они получат продукт, разработанный мной и моей командой, и я прилагал все усилия, чтобы действовать в их интересах. Это не означало, конечно, что я мог дать каждому абсолютно все, что он хотел, потому что все хотели разного. Кроме того, ни моя компания, ни команда не располагали неограниченным временем, поэтому я усердно работал над выявлением хотя бы того, что я могу изменить, чтобы люди были довольны. Казалось бы, такое положение вещей должно раздражать, но на самом деле это очень интересная часть работы.

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

«Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете».

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

Что я услышал в ответ?

«Это нужно для соответствия требованиям».

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

Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом:

«Это. Для. Соответствия. Требованиям».

И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись».

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

Помните: ваша работа заключается не в том, чтобы достичь соответствия требованиям. Ваша работа в том, чтобы изменить мир.

Вот и всё

Запомните эти три вещи, даже если больше ничего не вынесете из книги.

• Истории не требования в письменной форме; создание историй с использованием слов и картинок – механизм выработки одинакового понимания.

• Истории не требования, а дискуссии о решении задач вашей организации, заказчиков и пользователей. Результатом этих дискуссий становится соглашение о том, что именно нужно разработать.

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

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

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

А сейчас настало время обсудить самый интересный момент в составлении историй – построение карты историй.

Глава 1. Общая картина

«Обожаю разработку Agile! Каждые пару недель у нас начинает работать что-то новенькое! Но, кажется, я уже запутался и не вижу общей картины».

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

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

Слово на «А»

Если вы читаете эту книгу, то, наверное, знаете, что построение карт историй – способ работы с пользовательскими историями так, как это принято в процессах Agile. На текущий момент практически любая книга о разработке Agile так или иначе воспроизводит «Agile-манифест разработки программного обеспечения» (Agile Manifesto), написанный еще в 2001 году группой ребят, которым надоели громоздкие непродуктивные процессы разработки ПО, распространенные в то время. Я очень рад, что они его написали. Еще я рад тому, что долгосрочный эффект их работы затронул так много людей.

Мне жаль разочаровывать вас, но я не собираюсь приводить здесь этот манифест и рассуждать, почему он так важен. Думаю, вы и так это отлично знаете. Кстати, если вы не читали манифест, стоит сделать это.

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

Но вы, наверное, недоумеваете: что общего у Agile-методов и этого котика? Да, в общем, ничего. Но гибкая разработка определенно связана с этой книгой, с историями, а также с развитием карт историй.

<Звучит ретромузыка>

Я работал в одном стартапе в Сан-Франциско в 2000 году, когда компания приняла на работу Кента Бека (это тот самый парень, который придумал экстремальное программирование и впервые изложил идею историй) в качестве консультанта по наладке процесса разработки ПО. Я совершаю этот исторический экскурс, чтобы показать, что мысль о применении историй на самом деле очень стара. Если вы только начинаете работать с историями, то уже потеряли статус первооткрывателя, который могли бы иметь лет десять назад. Кент и другие пионеры экстремального программирования знали, что все известные в прошлом способы добиться точного соответствия требованиям не работали как следует. И у Кента возникла простая мысль, что все должны собраться вместе и рассказывать истории. Таким образом можно выработать единое понимание и вместе найти наилучшее решение.

Истории надо рассказывать, а не писать

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

Истории называются историями из-за способа их использования, а не потому, что их надо записывать.

Еще до того, как я в полной мере осознал, почему истории получили такое название, я понял, что могу написать множество историй – в виде предложения или краткого заголовка, на карточках или стикерах. Я могу менять их местами и расставлять в соответствии с приоритетом, выбирая самые важные из них. Как только я решу, что одна из историй более важная, чем другая, можно начать ее обсуждение. Это было суперкруто! Почему я раньше не записывал ничего на карточках, чтобы удобно было организовать работу таким образом?

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

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

Изложение истории с начала до конца

В 2001 году я покинул команду, где тогда работал, и начал изменять привычный ход событий. Я и моя команда пытались выработать такой подход к работе с историями, который позволял бы сконцентрироваться на полной картине. Мы разрабатывали общее видение нашего продукта, вместе находили компромиссы и соглашения. У нас было множество карточек с заголовками историй, с помощью которых мы организовывали свои идеи, а также разбивали большую картину на мелкие части, которые отправляли в очередь на разработку. В 2004 году я написал первую статью о таком принципе работы, но не употреблял термин «карты историй» до 2007 года.

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

Впервые я услышал определение паттерна от своей подруги Линды Райзинг: когда вы кому-то рассказываете о своей грандиозной идее, а он отвечает, что тоже придумал и использует что-то подобное, это значит, что вы не изобрели нечто новое, а открыли паттерн.

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

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

Сегодня компании одна за другой перенимают идею карт пользовательских историй. Моя подруга Мартина, работающая в SAP, в письме, написанном в сентябре 2013 года, сообщила: «…К настоящему моменту было проведено более 120 заседаний рабочих групп по картам пользовательских историй. Они так понравились многим представителям заказчиков! Это отлично зарекомендовавший себя рабочий подход в SAP».

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

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

Гэри Левитт и плоский бэклог

Несколько лет назад я познакомился с Гэри Левиттом. Гэри был бизнесменом и как раз запускал новый веб-продукт. Этот продукт и сейчас работает, он называется Mad Mimi, что согласно задумке Гэри означало «маркетинговый интерфейс музыкальной индустрии»⁶. Гэри музыкант, и у него есть собственная группа. Он самостоятельно занимался административными делами, а кроме того, помогал управляться с ними и другим, работал в музыкальной студии и делал записи для клиентов.

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

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

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

Я был знаком с человеком, работавшим с Гэри. Мой друг видел, что Гэри вне себя от беспокойства, и очень хотел ему помочь. Кто-то из наших общих знакомых спросил меня, не хочу ли я поговорить с Гэри и помочь ему организовать его идеи. Мы познакомились и договорились встретиться в его офисе на Манхэттене.

Говорите и пишите

Беседа началась. По мере того как Гэри рассказывал, я записывал ключевые слова его идей на карточках. У меня есть что-то вроде мантры, я люблю ее повторять, когда составляю карты пользовательских историй. Она звучит как «говорите и пишите», что означает: не дайте словам пропасть втуне. Запишите их на карточки, к которым сможете обратиться позднее. Вы удивитесь тому, как взгляд на пару слов, записанных на карточке, вызывает в памяти целое обсуждение. Мы можем двигать карточки по столу, выстраивая их в разном порядке. Мы начинаем использовать полезные слова вроде «это» и «то», означающие записанное на карточках. Это экономит уйму времени. Я должен был заставить Гэри вытащить свои мысли наружу – это крайне важно для обеспечения общего мнения. Для него это было непривычно, но я без труда фиксировал идеи на карточках по мере того, как он их излагал.

Говорите и пишите: записывайте тезисы на карточках или стикерах, чтобы зафиксировать свои мысли по мере того, как рассказываете истории.

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

Вот как в конце дня выглядел пол.

Мысль – запись – объяснение – место

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

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

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

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

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

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

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

Оформите свою идею

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

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

Опишите своих пользователей и заказчиков

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

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

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

Типы пользователей в Mad Mimi

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

Изложите свои истории

После этого я предложил: «Ну что ж, давай представим себе будущее. Предположим на минуту, что продукт выпущен и работает, и обсудим день жизни кого-то, кто использует его, а затем начнем составлять истории: сперва он делает одно, затем – другое, третье и т. д.»

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

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

Перемещение карточек друг относительно друга позволяет вам общаться без слов.

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

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

Составление карты пользовательских историй поможет вам обнаружить пробелы в ней.

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

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

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

Гэри жил в Нью-Йорке и при обсуждении листовок представлял себе все те крутые штуки, которые постоянно видел на стенах и фонарных столбах города. Одни выглядели так, словно кто-то склеил вместе текст и журнальные фотографии, а потом размножил полученное на ксероксе, но другие и в самом деле смотрелись эстетично и элегантно. Записав какое-то количество деталей, я предложил Гэри оставить их в покое, чтобы вернуться к ним позже, а сейчас продолжить обсуждение истории и продвинуть ее дальше. Утонуть в деталях очень легко, особенно если вам очень интересен предмет обсуждения. Но когда нужно получить общую картину, очень важно добраться до конца истории, прежде чем погружаться в мелочи. Еще одна мантра, которую я использую при работе с историями: «Мысли на милю вперед и на дюйм вглубь». Для тех, кому привычнее метрическая система: «На километр вперед и на сантиметр вглубь». Дойдите до конца истории, прежде чем тонуть в деталях.

Сосредоточьтесь на протяженности истории, прежде чем погружаться в ее глубину.

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

«А сейчас, – сказал я, – давай вернемся назад, проработаем детали, а также рассмотрим некоторые альтернативы».

Основная история Mimi

Просмотрев карту Гэри, вы можете заметить такие основные действия, как:

• регистрация;

• изменение набора сервисов;

• просмотр статистики моей группы;

• работа с календарем концертов;

• работа с аудиторией;

• публикация анонсов шоу;

• подписка на рассылку группы;

• просмотр предложений онлайн.

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

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

• запустить рекламу представления;

• просмотреть автоматически созданную Mimi рекламную рассылку;

• отредактировать рекламную рассылку;

• проверить созданную рассылку.

Обратите внимание на то, как ясно короткие глагольные фразы, написанные на карточках, говорят, что хочет сделать определенный тип пользователя. Такие формулировки облегчают воссоздание цельной последовательной истории: «Теперь администратор группы хочет опубликовать анонс о представлении. Чтобы сделать это, он должен запустить рекламу представления, затем просмотреть автоматически созданную Mimi рассылку, затем отредактировать ее, потом…» Достаточно просто вставить «а потом» в промежутке между двумя карточками, чтобы получить связную историю.

Займемся вариантами и деталями

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

• В чем особенности действий пользователя на данном этапе?

• Какие альтернативные вещи они могут сделать?

• Как можно сделать этот этап по-настоящему крутым?

• Как исправить ситуацию, если что-то пойдет не так?

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

Детали

Если бы вы заглянули в историю шага, например, «Отредактировать рассылку», то увидели бы такие детали:

• загрузить изображение;

• прикрепить аудиофайл;

• разместить видео;

• добавить текст;

• изменить разметку;

• использовать ранее созданную рассылку как шаблон.

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

Заметьте, что и на этих карточках использованы простые глагольные фразы, которые облегчают изложение историй. Мы можем составить из этих карточек историю, применяя связку «или он может», например, вот так: «Чтобы отредактировать рассылку, он может прикрепить аудиофайл, или добавить видео, или…» Очень удобно!

«А что сейчас? – спросил я у Гэри. – У нас есть и другие пользователи, и решить они хотят другие задачи. Хочешь обсудить их? Только, по-моему, если мы будем продолжать, то нам потребуется другая комната, побольше. И еще, Гэри: даже на разработку всего вот этого уже понадобится куча денег. Мы можем обсудить и все остальное, но у нас уже есть довольно много. По-моему, даже если запустить продукт только с этой частью, он будет классным».

Гэри согласился: «Давай на этом остановимся».

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

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

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

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

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

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

Артджайл – творчество в искусстве встречается с творчеством в IT

Сиди (Клэр) Дойл, менеджер продуктов и тренер Agile (Assurity Ltd, Веллингтон, Новая Зеландия)

Предисловие

The Learning Connexion (TLC) – колледж искусств в Веллингтоне, Новая Зеландия. Там изучают искусство и творчество. Программы TLC уникальны, так как они основаны на обучении действием, то есть изучении теории одновременно с практикой. Под руководством преподавателей студенты трудятся над работами на темы, которые сами выбрали для исследования.

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

У сотрудников TLC не было никакого опыта работы с IT-проектами. Все маленькие приложения, применяемые в колледже, когда-то были написаны чьими-то братьями, друзьями, соседями с использованием простых технологий вроде Microsoft Excel или Access. Единственное коммерческое приложение, используемое для составления официальных отчетов, повторно обрабатывало данные из других четырех источников.

Как бывшая студентка, я поддерживала контакты с сотрудниками колледжа, и поэтому, когда им понадобилась помощь, они обратились ко мне. К 2009 году я имела девятилетний опыт работы в IT, а в последние три года, с того самого момента, как впервые услышала о методологии Agile, мечтала сделать какой-нибудь проект, применив ее. И вот наконец звезды сошлись: правильное место, правильный проект и правильный момент, чтобы осуществить мечту!

Проект «Феникс»

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

До того как я показала членам команды картинку (основу карты историй), каждый из них имел собственное представление о том, что они делали, но, как сказала руководитель проекта Алиса, возможно, впервые все они получили ясную картину своего бизнес-процесса, а также связей всех шагов между собой.

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

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

Согласно диаграмме, основными этапами процесса были Запрос – > Допуск – > Вступительные экзамены – > Классы – > Итоговая работа – > Завершение – > Выпуск.

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

Когда дело дошло до расстановки приоритетов, пришлось разделить все на категории «Обязательно», «Желательно» и «Неплохо бы». Здесь все очень просто: то, что «Обязательно нужно», располагалось выше разделительной линии, а все остальное – ниже. После того как мы обработали шаг «Вступительные экзамены», команда усвоила принцип и за остаток дня доделала все остальное. И моя помощь не понадобилась! Кроме того, они взяли на себя расстановку подзаголовков, которые были нужны, чтобы лучше описать процесс: «Сначала должно быть закончено все вот это, а затем – вот то». Таким образом, когда мы добрались до конца, они, действуя группой, создали обширную картину шагов, которые делает студент, начиная от вступительных экзаменов и заканчивая выпуском.

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

Глава 2. Планируйте разработать меньше

У вас никогда не будет достаточно людей, времени или денег, чтобы разработать все, что нужно. Никогда.

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

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

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

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

Сотрудникам Globo.com лучше, чем кому-либо на планете, известно, что такое дедлайны, не подлежащие смещению. Например, компания хочет выпустить новую версию Fantasy Football Game – браузерной игры, которая дополняется и обновляется регулярно к чемпионату мира по футболу – самому громкому событию в футбольном мире. Если Globo.com не будет успевать к чемпионату, то перенос даты выхода игры их не спасет. Почему? Да потому что никто не изменит дату начала чемпионата. Globo.com планирует также выпустить разную функциональность и контент к Олимпийским играм, которые пройдут в Бразилии в 2016 году⁸, и я могу гарантировать, что это будет сделано вовремя – иначе никак! Кроме того, в компании выпускается масса функциональности и контента к выходу огромного количества телевизионных программ и реалити-шоу. Ничто из этого не может быть перенесено, если Globo.com запаздывает с разработкой. Компания всегда должна закончить работу вовремя. И так как это очень важно для бизнеса, Globo.com отлично справляется. Не потому, что люди там работают быстрее, чем в любом другом месте, – быстро, конечно, но не настолько быстро. Секрет в том, что они умеют делать меньше.

Составление карт помогает достичь единого мнения в больших группах

Посмотрите на рисунок.

Это всего лишь фрагмент огромной карты, созданной в результате совместной работы представителей восьми команд из трех разных групп Globo.com. Команды из «Спорта», «Новостей» и «Развлечений» составили вместе эту карту, чтобы продумать и распланировать работу, которая потребуется для преобразования, модернизации и обновления их основной системы управления контентом. С помощью этой системы компания управляет всеми сайтами новостей, спортивных событий, мыльных опер, публикует рекламу, ищет гостей реалити-шоу и делает еще многое. Такая огромная система должна быть способна обработать огромное количество видеофайлов и фотографий, счетчики и итоги голосования в реальном времени, экстренные новости и т. д. Система должна делать очень многое, и делать это без проблем.

В тот день, когда я пришел в офис Globo.com, они как раз составили эту карту и, судя по всему, вот-вот должны были угодить в ловушку плоского бэклога. Отдельные команды разработали собственные бэклоги с элементами, расставленными по степени важности. Было понятно, что предстоит огромный объем работы и что каждая группа зависит от остальных. Например, для хорошего новостного сайта требовалась работа не только группы новостей, но и других, которые создадут основные компоненты, нужные сайту для работы: фотографии, видео, данные, полученные в реальном времени, и еще многое.

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

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

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

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

Анатомия большой карты

Карта Globo.com – хороший пример того, на что похожа типичная карта после того, как вы обрисовали, связали и исследовали множество деталей.

Карту организует каркас

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

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

Карта и ее значение для совместного выпуска продукта

Эта карта была создана различными командами Globo.com. Над ней работали команды, ответственные за видеоматериалы, и команды, создающие ПО для внутреннего пользования, применяемое редакторами для создания контента и управления им. Были команды, ответственные за метаданные и связи между данными – всю эту семантическую разметку, в которую я, честно говоря, никогда не вникал. Были и те, кто занимался внешним представлением и обеспечивал хорошую картинку для конечных пользователей и/или потребителей. И конечно, много людей, выполняющих специфические функции, связанные со спортом, новостями или развлечениями.

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

Карта в изложении истории, включающей много пользователей и систем

Карта началась с того, что слева обозначили названия специалистов, а также их действия по настройке расположения на экране текста, иллюстраций и видео. Затем в дело вступали другие люди, которые из этих материалов формировали страницы сериалов или новостных веб-сайтов. После них – редакторы, которые добавляли на страницы контент. Таким образом, весь каркас повествовал о том, как много людей в Globo.com занято конструированием контента на веб-сайте и управлением этим контентом.

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

Хроника повествования такой большой системы затрагивает множество различных пользователей и системных историй. Мне удобно располагать наклейки или простые ярлычки с обозначением персонажей над каркасом, в результате чего легко понять, о ком конкретно мы говорим на определенном этапе истории. Можно очеловечить в том числе и процессы сервера или какие-либо компоненты, имеющиеся в системе. Например, мои друзья в SAP для элементов системы создают фантастических персонажей и используют изображения R2D2 или C3PO из «Звездных войн».

Карты помогают вам распознать дыры в истории

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

После того как вы визуализировали весь продукт или какую-то функциональность, гораздо проще играть в игру «Что, если». Именно в этот момент мы начинаем задумываться: «Что будет, если что-то пойдет не так?» или «А что с этими, другими пользователями?». Играйте во «Что, если» с любыми сомнениями, которые у вас есть, и добавляйте наклейки в основную часть карты, где затем появятся идеи, которые нужно воплотить в программном обеспечении. В главе 1 Гэри играл во «Что, если», рассматривая варианты и альтернативы. Когда вы и другие команды проделаете это, то удивитесь тому, какое огромное количество проблем может обнаружиться при взаимодействии разных команд.

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

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

Свои границы расширяет понимание, а не проект.

Всегда слишком много

Когда я покидал команду реорганизации системы управления контентом в Globo.com, все было прекрасно – все отлично знали, что им делать, и понимали задачу одинаково. Однако, вернувшись через несколько дней проведать ребят, я обнаружил их в растерянности – они поняли, насколько огромная работа им предстоит, а потребуется на нее, скорее всего, больше года. И, как уже догадался проницательный читатель, когда разработчик предполагает сделать что-то за год, на самом деле это означает два. Не потому, что он некомпетентен или не умеет планировать свое время, – просто-напросто оценить временные затраты на то, чего прежде не делал, очень нелегко. Ну и, конечно, все мы склонны смотреть на жизнь с оптимизмом.

«Задача слишком велика! Нужно сделать так много и это займет так много времени!» – говорили сотрудники Globo.com.

«И что, все-все это необходимо реализовать?» – спросил я, на что они, конечно, ответили:

«Разумеется! Это же все части одной большой системы управления контентом!»

«Но ведь обычно вы не делаете проекты так долго. Я знаю вашего генерального директора, он наверняка захочет увидеть результаты гораздо раньше, верно?»

«Так и есть, – подтвердили они. – Он хочет видеть что-то рабочее к выборам в Бразилии, то есть через несколько месяцев».

«А нужно ли, чтобы к этим выборам работало все?»

Ага! Стоило мне задать этот вопрос, как у них в головах словно зажглась лампочка. Конечно же, все им было не нужно. До этого момента они концентрировались на выявлении последовательностей и зависимостей, предполагая, что должны реализовать все задуманное. Это было возможно, вопрос только в сроках. Но теперь наконец фокус сместился на реалистичный результат.

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

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

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

Отделите релиз минимального работоспособного продукта

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

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

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

Составьте план релизов

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

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

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

Обратите внимание: этот список не является набором функциональностей. Это перечень достижений в реальном мире – вы же помните, что ваша работа заключается не в создании программного обеспечения, а в изменении мира? Трудность заключается в выборе людей, чей мир вы должны изменить в этот раз, и определении того, как именно это сделать.

Секрет выбора приоритетов при разработке программ – концентрация на конкретных ожидаемых результатах.

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

Не пытайтесь расставить приоритеты в функциональностях вместо результатов

Заметим: команда Globo.com начинала с огромной задачи обновления всей системы управления контентом. Обновление системы – результат, которого хотела достичь команда. Это сулило множество преимуществ. Очень важно было разбить этот поистине монстрообразный результат на более мелкие, больше подходящие для фокусирования.

Запомните: результаты, которые мы кладем в основу расстановки приоритетов, – это конкретные изменения в поведении конкретных людей, вовлеченных в конкретные действия и процессы. Сконцентрировавшись на выборах в Бразилии, Globo.com стала ориентироваться лишь на людей, которые следят за новостями – особенно за обновляющимися данными голосования. Но в результате этого за бортом остались зрители мыльных опер, спортивные болельщики и множество других типов пользователей. Этим людям придется довольствоваться старой версией сайта несколько дольше. Помните, что невозможно удовлетворить всех и каждого одновременно.

Волшебство? Так и есть

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

Много раз и я сам, и команды, с которыми работал, фиксировали в карте мысли, возникшие по поводу замечательного продукта, а потом ужасались тому, какой огромный объем работы нужен, чтобы воплотить все их в жизнь. Критически важным кажется все! Но затем мы немного остываем и задумываемся о конкретных людях, которые пользуются нашим продуктом, а также о том, что им нужно для достижения успеха. Эти мысли мы излагаем в паре предложений. А потом стоит лишь отсечь все лишнее – и все поражены тем, как на самом деле мало нужно, чтобы выпустить жизнеспособное решение! Это волшебство.

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

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

Поиск маленького жизнеспособного релиза

Крис Шинкл, SEP

FORUM Credit Union – один из самых больших и технически развитых кредитных союзов в стране. Хотя культура разработки ПО в компании отличается и креативностью, и компетентностью, ее сотрудники обратились в SEP за помощью в создании новой банковской онлайн-системы, которая должна была конкурировать с типовыми коммерческими решениями. Целью было добавление возможности пользоваться мобильным банкингом, СМС-банкингом, а также лично управлять своими финансами.

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

После того как карта была составлена, SEP обучила сотрудников FORUM составлять простую модель расстановки приоритетов.

• Конкурентное преимущество – преимущество, которое отличает их от конкурентов.

• Спойлер – функциональность, которая стремится перекрыть чужое конкурентное преимущество.

• Фактор снижения затрат – функциональность, введенная для снижения затрат организации.

• Минимальный пакет – минимальный набор функций, необходимый для успешного конкурирования на рынке.

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

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

Дуг Тру, генеральный директор FORUM, о значении карт историй для запуска проекта сказал так: «Когда мы начали работу по проекту с использованием карт историй и персонажей, я чувствовал некоторый скепсис. Честно говоря, мне казалось нецелесообразным тратить на это время. Но на следующий день польза от потраченного времени стала очевидной. Сейчас я уже не могу представить себе запуск такого большого и сильно затрагивающего интересы пользователей проекта без этого предварительного процесса».