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