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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот и всё

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

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

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

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

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

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

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

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

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

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

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

Слово на «А»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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