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