Минимизируйте объем работы, максимально увеличивайте результат и долгосрочный эффект.
Хитрость здесь в том, чтобы внимательно рассмотреть людей, чьи проблемы вы пытаетесь решить. В эту группу входят лица, которые принимают решение о покупке вашего продукта для решения каких-то задач в своей организации, а также те, кто непосредственно с ним работает, то есть пользователи. Иногда это одни и те же люди, иногда – нет.
В вашем бизнесе есть множество возможных пользователей и заказчиков, на которых вы можете сфокусироваться. Ваша бизнес-стратегия должна подсказать, кого именно выбрать, чтобы получить желаемый долгосрочный эффект. Но уверяю вас: ни у одного бизнеса нет достаточных ресурсов, чтобы сделать счастливыми всех – это просто невозможно!
Поймите меня правильно: выработка большего объема продукта за меньшее время – это всегда хорошо, но никогда не решает всех проблем.
Страшные слова на букву «Т»
На протяжении почти всего первого десятилетия моей карьеры в IT, которое я провел за созданием ПО для розничной торговли, я вообще обходился без слова «требования» – ну или очень редко его слышал. Этот термин попросту не годился для обозначения того, что я делал. У меня было множество отдельных заказчиков, каждый из которых имел собственное представление о том, что ему подходит. Также я всегда помнил, что работаю на компанию, которая делает деньги, продавая мой продукт. Фактически я проводил долгие часы на выставках, помогая компании продавать наш продукт широкому кругу покупателей. В конце дня я знал, что мне придется работать с этими заказчиками после того, как они получат продукт, разработанный мной и моей командой, и я прилагал все усилия, чтобы действовать в их интересах. Это не означало, конечно, что я мог дать каждому абсолютно все, что он хотел, потому что все хотели разного. Кроме того, ни моя компания, ни команда не располагали неограниченным временем, поэтому я усердно работал над выявлением хотя бы того, что я могу изменить, чтобы люди были довольны. Казалось бы, такое положение вещей должно раздражать, но на самом деле это очень интересная часть работы.
По мере того как компания росла, на работу поступало все больше людей, привыкших к традиционному процессу разработки. Однажды ко мне пришла начальница другой команды и сказала:
«Джефф, нужно, чтобы вы внесли вот эти изменения в продукт, над которым сейчас работаете».
«Нет проблем, – ответил я, – только расскажите мне, для кого мы делаем эти изменения и какие задачи люди будут решать с их помощью».
Что я услышал в ответ?
«Это нужно для соответствия требованиям».
«Я вас понял, – кивнул я. – Мне только нужно знать подробнее, для кого мы внедряем эти штуки, как эти люди будут их использовать, а также какой этап их рабочего процесса изменится».
Она посмотрела на меня так, словно я был самым тупым человеком на свете, и повторила с нажимом:
«Это. Для. Соответствия. Требованиям».
И в этот момент я осознал, что слово «требования» на самом деле означает «заткнись».
Вот что означают требования для большинства людей. Они перестают говорить о людях и проблемах, которые надо решить. Правда же состоит в том, что, даже если вы сделаете лишь часть того, что требуется, пользователи вполне могут остаться довольными[4].
Помните: ваша работа заключается не в том, чтобы достичь соответствия требованиям. Ваша работа в том, чтобы изменить мир.
Вот и всё
Запомните эти три вещи, даже если больше ничего не вынесете из книги.
• Истории не требования в письменной форме; создание историй с использованием слов и картинок – механизм выработки одинакового понимания.
• Истории не требования, а дискуссии о решении задач вашей организации, заказчиков и пользователей. Результатом этих дискуссий становится соглашение о том, что именно нужно разработать.
• Ваша работа состоит не в том, чтобы больше разрабатывать за меньшее время, – вы должны стремиться увеличить результат и долгосрочный эффект, получаемые в ходе изменений, которые вы решили сделать.
Изначальный смысл историй – принципиально новый способ мышления при столкновении с проблемами, которые возникают при совместной работе над программным обеспечением (а также в любой другой деятельности). Если вы можете эффективно работать вместе с другими людьми и создавать нечто решающее проблемы, то скоро начнете править миром. Или как минимум той его частью, где работают с вашим продуктом.
Раз уж вы читаете эту книгу, я надеюсь, вы хотите изучить самую суть использования историй. Я надеюсь, вы работаете вместе с другими людьми и в ходе этого сочиняете истории о ваших пользователях и заказчиках, а также о том, как им помочь. Я надеюсь, вы рисуете картинки и составляете большие модели из стикеров. Я надеюсь, вы увлеченный и творческий человек. Я надеюсь, вы ощущаете, что создаете что-то значимое. Это чистая правда, если вы делаете все правильно. И это доставляет вам удовольствие.
А сейчас настало время обсудить самый интересный момент в составлении историй – построение карты историй.
Глава 1. Общая картина
«Обожаю разработку Agile! Каждые пару недель у нас начинает работать что-то новенькое! Но, кажется, я уже запутался и не вижу общей картины».
Если бы я получал по 10 центов с каждого, от кого слышу что-то подобное о разработке Agile, то у меня была бы уже… хм… целая куча десятицентовиков. Словом, я слышал это множество раз. Вы, наверное, тоже слышали, а может, и сами высказывались в этом духе. Что ж, у меня для вас хорошие новости. Следование методологии Agile и управление разработкой посредством историй не всегда означает непременную утрату масштабного видения. Вы можете продолжать дискутировать о своем продукте в целом и одновременно видеть изменения, происходящие каждые несколько недель.
Поскольку вы терпеливо прочли главу «Сначала прочтите это», я не буду подробно останавливаться на самих историях и перейду к тому, как карты историй решают одну из самых больших проблем в разработке Agile. Если вам уже приходилось сталкиваться с составлением карт историй в проектах Agile, информации, содержащейся в этой главе, вполне хватит, чтобы приступить к делу.
Слово на «А»
Если вы читаете эту книгу, то, наверное, знаете, что построение карт историй – способ работы с пользовательскими историями так, как это принято в процессах Agile. На текущий момент практически любая книга о разработке Agile так или иначе воспроизводит «Agile-манифест разработки программного обеспечения» (Agile Manifesto), написанный еще в 2001 году группой ребят, которым надоели громоздкие непродуктивные процессы разработки ПО, распространенные в то время. Я очень рад, что они его написали. Еще я рад тому, что долгосрочный эффект их работы затронул так много людей.
Мне жаль разочаровывать вас, но я не собираюсь приводить здесь этот манифест и рассуждать, почему он так важен. Думаю, вы и так это отлично знаете. Кстати, если вы не читали манифест, стоит сделать это.
На то место, которое занял бы в книге этот манифест, я лучше помещу смешное фото с котенком[5]. Почему? Да потому, что, как доказано, смешные фотографии котиков притягивают в Интернете больше внимания, чем какой бы то ни было манифест.
Но вы, наверное, недоумеваете: что общего у Agile-методов и этого котика? Да, в общем, ничего. Но гибкая разработка определенно связана с этой книгой, с историями, а также с развитием карт историй.
<Звучит ретромузыка>
Я работал в одном стартапе в Сан-Франциско в 2000 году, когда компания приняла на работу Кента Бека (это тот самый парень, который придумал экстремальное программирование и впервые изложил идею историй) в качестве консультанта по наладке процесса разработки ПО. Я совершаю этот исторический экскурс, чтобы показать, что мысль о применении историй на самом деле очень стара. Если вы только начинаете работать с историями, то уже потеряли статус первооткрывателя, который могли бы иметь лет десять назад. Кент и другие пионеры экстремального программирования знали, что все известные в прошлом способы добиться точного соответствия требованиям не работали как следует. И у Кента возникла простая мысль, что все должны собраться вместе и рассказывать истории. Таким образом можно выработать единое понимание и вместе найти наилучшее решение.
Истории надо рассказывать, а не писать
Когда я впервые услышал слово «история», оно мне не понравилось. Я признаю это. То, что мы должны упрощать важные вещи, в которых нуждаются люди, называя их историями или сценариями, казалось мне неправильным. Но я тугодум, что мне уже было известно из обсуждения общего мнения. Мне потребовалось некоторое время, чтобы понять следующее.
Истории называются историями из-за способа их использования, а не потому, что их надо записывать.
Еще до того, как я в полной мере осознал, почему истории получили такое название, я понял, что могу написать множество историй – в виде предложения или краткого заголовка, на карточках или стикерах. Я могу менять их местами и расставлять в соответствии с приоритетом, выбирая самые важные из них. Как только я решу, что одна из историй более важная, чем другая, можно начать ее обсуждение. Это было суперкруто! Почему я раньше не записывал ничего на карточках, чтобы удобно было организовать работу таким образом?
Проблема была в том, что одна карточка могла представлять собой нечто, внедрение чего в продукт заняло бы у разработчика несколько часов. Или дней. Или недель. Или целый месяц – кто знает? Точно не я – во всяком случае, пока мы не начнем говорить об этом.
Начав обсуждение истории во время работы над своим первым проектом Agile, я невольно вызвал неприятный спор, когда оказалось, что история слишком велика. Мне хотелось, чтобы он был реализован в течение следующей итерации, но разработчики, с которыми я разговаривал, доказали мне, что это невозможно. У меня было смутное ощущение, что я что-то делаю не так. Разработчики выделили небольшую часть, о внедрении которой на следующей итерации можно было говорить, но я был раздражен тем, что нам не удалось поговорить масштабно, рассмотрев все в целом. На самом деле мне хотелось знать, сколько времени займет разработка большой функциональности, которую хотелось получить в итоге. Я надеялся, что дискуссия поможет мне оценить это, но ничего не вышло.