Текст книги "Чистый Agile. Основы гибкости"

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

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

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

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

Итак, встреча намечалась в Сноуберде.

Сноуберд

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

Однако мы все собрались в Сноуберде в гостиничном номере с прекрасным видом из окна.

Пришли 17 человек. С тех пор нас не раз критиковали за то, что все собравшиеся были белыми мужчинами среднего возраста. Критика была бы вполне справедлива, если бы не одно «но». Дело в том, что в списке приглашенных фигурировала одна женщина – Агнета Якобсон, но она не смогла приехать.

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

У всех 17 из нас были довольно разные взгляды на пять различных легковесных методологий. Сторонников экстремального программирования было больше всех. Это были Кент Бек, Джеймс Греннинг, Уорд Каннингем, Рон Джеффрис и я.

Сторонников Scrum было немного меньше – Кен Швабер, Майк Бидл и Джефф Сазерленд.

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

Остальные участники были относительно самостоятельны. Например, Энди Хант и Дейв Томас пропагандировали прагматизм в программировании. Они даже написали работу на эту тему. Брайан Марик был консультантом по тестированию. Джим Хайсмит был консультантом по управлению разработкой и сопровождению программного обеспечения. Стив Меллор следил за честностью каждого, потому что был сторонником подходов, управляемых моделями, к которым многие из нас относились с недоверием. И, наконец, присутствовал Мартин Фаулер. У него были личные взаимоотношения с командой, занимавшейся экстремальным программированием, однако к каким-либо «фирменным» методикам он относился довольно скептически. Мнения всех присутствующих он воспринимал благожелательно.

Я почти ничего не помню из того, что произошло за два дня нашей встречи. Другие участники событий видят картину по-своему, не так, как я[19]19
  Не так давно увидела свет история события, изложенная в литературном журнале The Atlantic за авторством Кэролайн Мимбс Найс: Caroline Mimbs Nyce. The winter getaway that turned the software world upside down // The Atlantic. 08.12.2017. URL: https://www.theatlantic.com/technology/archive/2017/12/agile-manifesto-a-history/547715/. Когда я это все писал, то еще не ознакомился с той статьей, поскольку мне не хотелось путать свои воспоминания, которые я изложил здесь.


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

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

Я считаю, что это был мой единственный вклад в проведение встречи.

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

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

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

Это ключевая идея Манифеста Agile, и, кажется, никто отчетливо не помнит, кто первый обозначил ее на доске. Как мне помнится, это был Уорд Каннингем. Но сам Уорд приписывает это авторство Мартину Фаулеру.

Посмотрите на фотографию на сайте agilemanifesto.org. Уорд говорит, что сделал снимок, чтобы запечатлеть тот самый момент. На фото можно разглядеть Мартина Фаулера у доски и прочих участников встречи, которые собрались вокруг него[20]20
  Слева направо, полукругом около Мартина Фаулера, на фотографии представлены: Дейв Томас, Энди Хант (или, возможно, Джон Керн), я (меня можно узнать по синим джинсам и мультитулу на ремне), Джим Хайсмит, кто-то, Рон Джеффрис и Джеймс Греннинг. Кто-то, уже не помню кто, сидел позади Рона. Возле его ботинка на полу, похоже, находится одна из карточек, которые мы использовали при группировке по сходству.


[Закрыть]. Это придает правдоподобность высказыванию Уорда о том, что идея на самом деле принадлежала Мартину.

С другой стороны, возможно, и хорошо, что мы никогда уже этого не узнаем точно.

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

• Люди и взаимодействие важнее процессов и инструментов.

• Работающий продукт важнее исчерпывающей документации.

• Сотрудничество с заказчиком важнее согласования условий контракта.

• Готовность к изменениям важнее следования первоначальному плану.

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

Название Agile не сулило легкого успеха. Было много разных претендентов. Мне понравилось что-то вроде «легковесный» (lightweight), но кроме меня – никому. Остальные считали, что в таком названии подразумевалась несущественность. Им полюбилось слово «адаптивный» (adaptive). Кто-то вспомнил слово agile[21]21
  С англ. «живой», «проворный», «гибкий». – Примеч. пер.


[Закрыть], а кто-то заметил, что в то время это слово было в ходу в армии. В результате, хотя никому особо не нравилось слово agile, его выбрали в качестве названия как наименьшее из зол.

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

После событий в Сноуберде

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

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

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

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

Краткий обзор Agile

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

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

Правило креста

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

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

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

Графики на стенах

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

Присмотримся к рис. 1.2. Представим, что такой график висит на стене кабинета, где ведется разработка проекта. Разве это не было бы потрясающе?

Рис. 1.2. Скорость работы команды

Этот график отражает производительность команды разработчиков за каждую неделю. Единицы измерения – единицы сложности (story point). Мы поговорим о них позже. Просто посмотрите на этот график. Каждый может сделать вывод, взглянув на график, насколько быстро продвигается работа команды. Менее чем за десять секунд можно понять, что средняя скорость работы составляет 45 единиц в неделю.

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

Рис. 1.3. Диаграмма сгорания задач

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

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

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

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

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

Agile – это в первую очередь подход, который срабатывает только тогда, когда есть обратная связь. Каждая неделя, день, час и даже минута проходят в зависимости от результатов предыдущей недели, дня, часа или минуты. Соответствующие поправки вносятся уже после. Это относится как к управлению отдельными программистами, так и командами программистов целиком. Без необходимых данных не получится эффективного управления[22]22
  Этот принцип тесно связан с циклом НОРД – петлей Джона Бойда, кратко изложенным здесь: https://ru.wikipedia.org/wiki/Цикл_НОРД. Boyd J. R. A Discourse on Winning and Losing. Air Force Base Maxwell, Alabama: Aeronautics University Library, 1987. Document No. M-U 43947.


[Закрыть].

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

Почему же эти данные настолько важны? Разве можно эффективно вести управление проектом без таких данных? Мы пытались. Три десятка лет. И все получилось так, как получилось…

Первое, о чем нужно знать

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

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

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

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

Собрание

Каскадная модель пророчила нам способ пойти в обход этой задачи. Чтобы объяснить, насколько это было соблазнительно и неэффективно одновременно, я приведу в пример одно собрание.

Было первое мая. Большой босс созвал подчиненных в конференц-зал.

Босс начал: «У нас новый проект. Нужно его закончить к первому ноября. Никаких требований у нас пока нет. Нам их огласят в ближайшие пару недель. Сколько времени понадобится на анализ проекта?»

Мы вопросительно стали коситься друг на друга. Все молчали, боясь сказать лишнего. Никто понятия не имел, что на это ответить. Кто-то промямлил: «Так у нас же нет требований, от чего отталкиваться?»

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

Кто-то вопросительно пробормотал: «Два месяца?» Начальник воспринял это как согласие на условия: «Отлично! Как раз то, что я думал. Теперь скажите мне, сколько займет проектирование?»

И снова все застыли в недоумении, комнату наполнила мертвая тишина. Считаем. И осознаём, что до первого ноября всего полгода. Вывод напрашивается сам собой. «Два месяца?» – спросите вы.

«Совершенно верно! – большой босс лучезарно заулыбался. – Как я и думал. И на реализацию у нас остается два месяца. Всем спасибо, все свободны!»

Многие читатели наверняка вспомнили, что что-то такое с ними уже было. У кого такого не было, что ж сказать, вы счастливчики!

Этап анализа

Итак, предположим, что мы ушли из конференц-зала и разбрелись по кабинетам. Что делать дальше? Начинается этап анализа – значит, нужно что-то анализировать. Но что именно мы называем анализом?

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

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

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

Затем первого июля происходит чудо. Анализ завершен.

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

Этап проектирования

А что теперь делать? Конечно же, будем проектировать. Но что представляет собой проектирование?

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

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

И тогда случается новое чудо. Первого сентября мы внезапно завершаем проектирование. А почему так? Да потому что. Первое сентября. По графику работ мы должны были уже закончить. Незачем медлить.

Итак, еще одна вечеринка. Воздушные шары и речи. И мы прорываемся к следующему этапу – реализации.

Было бы замечательно провернуть такую схему еще разок. Эх, если бы точно так же можно было бы завершить этап реализации! Но так уже не выйдет. Потому что по завершении реализации требуется завершить и весь проект. Анализ и проектирование не приносят плодов в двоичном виде. У них нет однозначных критериев завершенности.

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

Этап реализации

А вот у реализации как раз есть отчетливые критерии завершенности. Тут уже не получится аккуратно схалтурить, выдав мнимый результат за действительный[23]23
  Однако разработчики сайта healthcare.gov определенно пытались.


[Закрыть].

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

Между тем требования к проекту продолжают меняться. Добавляются новые функции. Старые функции исчезают или корректируются. Нам бы вернуться назад, провести новый анализ и внести изменения в проектирование, но… осталось лишь две недели. И ударными темпами мы вбиваем все эти изменения в код.

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

Примерно 15 октября кто-то говорит: «Эй, а какое сегодня число? Когда сдавать?» И тут мы понимаем, что осталось всего две недели и к первому ноября мы ни за что не закончим. И вдруг впервые наши заказчики узнают, что с проектом возникают какие-то неувязочки.

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

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

Марафон на выживание

И начинается марафон на выживание. Клиенты злятся. Заинтересованные стороны дошли до белого каления. Давление нарастает. Работаем сверхурочно. Кто-то уходит с проекта. Просто ад!

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

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

Преувеличение?

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

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

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

Способ получше

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

Просто. Доступно. Очевидно. И неправильно.

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

Проект по Agile начинается с анализа, однако анализ сопровождает весь цикл разработки. На рис. 1.4 изображена схема, объясняющая принцип ведения проекта в целом. Справа – дата сдачи проекта, 1 ноября. Помните, первое, что надо знать, – это срок сдачи. Срок требуется поделить на закономерные интервалы, называемые итерациями, или спринтами[24]24
  Понятие «спринт» используется в Scrum. Мне оно не нравится, потому что намекает на то, что нужно нестись изо всех сил. Проект по разработке – это марафон. А кому нужен спринт во время марафона?


[Закрыть].

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

Рис. 1.4. Схема проекта

Нулевая итерация

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

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

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

Некоторые думают, что Agile – это просто каскадная модель в миниатюре, которая повторяется многократно.

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

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

Данные благодаря Agile

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

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

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

Рис. 1.5. Расчет новой даты завершения проекта

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

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

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

Рис. 1.6. Чем больше итераций, тем проще рассчитать сроки сдачи проекта

Надежда против управления

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