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

Билль о правах

Во время встречи в Сноуберде Кент Бек заявил, что цель Agile – построить мост над пропастью, существующей между клиентами и разработчиками. Для этого Кент Бек, Уорд Каннингем, Рон Джеффрис и некоторые другие составили «Билль о правах».

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

Права клиента

У клиента есть следующие права:

• Ознакомиться с общим планом, знать, что и когда можно получить и за какие деньги.

• Получать наилучшую, насколько это возможно, отдачу от каждой итерации.

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

• Изменять решения, функциональность и приоритеты, не неся непомерных расходов.

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

Права разработчика

У разработчика есть следующие права:

• Знать, что требуется от команды, а также иметь четкое представление о поставленных приоритетах.

• Выполнять работу качественно, несмотря ни на какие обстоятельства.

• Получать помощь от коллег, руководителей и самих клиентов.

• Проводить оценку задачи и уточнять ее в зависимости от обстоятельств.

• Брать на себя личную ответственность и не позволять возлагать на себя лишнее.

Все эти утверждения звучат весьма громко. Давайте рассмотрим их по очереди.

Клиенты

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

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

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

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

Проще говоря, нельзя соглашаться с невозможностью изменить объем и сроки работ. И объем работ, и сроки должны быть гибкими. Мы представляем такую гибкость с помощью кривой вероятностей. Например, согласно нашей оценке, вероятность того, что мы выполним первые десять историй к назначенному числу – 95 %. С вероятностью 50 % мы выполним вовремя следующие пять. И с вероятностью 5 % мы выполним еще пять историй в требуемый срок.

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

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

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

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

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

Клиенты имеют право на изменения решений, функциональность и приоритеты, не неся при этом непомерных расходов.

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

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

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

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

Разработчики

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

Разработчики имеют право на ознакомление с тем, что требуется от команды, а также на четкое представление о поставленных приоритетах.

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

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

Разработчики имеют право на качественное выполнение работы, несмотря ни на какие обстоятельства.

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

Разработчики имеют право на помощь от коллег, руководителей и самих клиентов.

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

Разработчики имеют право на оценку задачи и ее уточнение в зависимости от обстоятельств.

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

Разработчики имеют право самостоятельного принятия на себя ответственности и недопущения возложения на себя лишнего.

Профессионалы принимают предложения по работе, а не назначение заданий. Разработчик имеет полное право говорить «нет», если его не устраивает какая-либо работа или задание. Может быть такое, что разработчик не уверен в своих способностях выполнить ту или иную задачу или, может быть, считает, что кто-то другой справится лучше, чем он. Или, допустим, разработчик отказывается из личных или моральных соображений[33]33
  Вспомните разработчиков из «Фольксваген», которые «согласились» выполнить задание обойти испытания на количество выбросов вредных веществ в атмосферу. https://ru.wikipedia.org/wiki/Дело_Volkswagen.


[Закрыть].

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

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

Заключение

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

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

Глава 3. Методы взаимодействия с клиентами

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

Планирование

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

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

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

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

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

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

Трехвариантный анализ

Есть один метод, который неплохо подходит для больших задач. Это трехвариантный анализ. Такие оценки включают в себя три положения: лучший случай, допустимый случай и худший случай. С помощью такого анализа можно предречь исход с различной вероятностью. Худший случай – это когда мы уверены в сроках на 95 %. Допустимый – на 50 %, а лучший – на 5 %.

Например, я могу быть на 95 % уверен, что задание будет выполнено в течение трех недель. Только на 50 % я могу быть уверен, что оно будет выполнено за две недели. И 5 % вероятности, что получится уложиться в одну неделю.

Можно представить вероятность и иначе. Представим, что у нас 100 схожих заданий. Пять из них будут выполнены в течение недели, 50 – в течение двух недель, а 95 из них – в течение трех недель.

Существует целый математический метод, связанный с управлением трехвариантными оценками. Кому интересно, могу предложить изучить технику оценки и анализа программ и проектов (PERT)[34]34
  https://ru.wikipedia.org/wiki/PERT.


[Закрыть]. Это мощный метод управления крупными проектами и портфелями проектов. Если вы отдельно не изучали эту технику, не стоит думать, что прочитав о ней, вы уже все знаете. PERT выходит далеко за рамки графиков, которые вы видели в Microsoft Project.

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

Истории и единицы сложности

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

Пользовательская история – это сокращенное описание функции программы с точки зрения пользователя. Например:

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

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

Еще рано точно говорить о подробностях, поэтому подробности опущены, а описание упрощено. Мы стараемся отложить уточнение подробностей как можно на более долгий срок, до тех пор пока не начнется разработка по этой истории. Поэтому оставим историю в сокращенном виде как предпосылку для дальнейших действий[35]35
  Это одно из определений истории, данное Роном Джеффрисом.


[Закрыть].

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

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

Вспомните, что во Вторую мировую войну боевые действия планировались[36]36
  Ну, в какой-то степени, все равно.


[Закрыть] с помощью карточек, поэтому я считаю этот метод проверенным.

Истории для банкоматов

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

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

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

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

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

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

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

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

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

Оценка историй

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

Однако еще начало нулевой итерации, и это самая первая, оценочная встреча. До этого оценка историй не проводилась.

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

Потом мы оценим реализацию истории в пунктах. История «вход» получит 3 единицы по сложности разработки соответствующей функции (рис. 3.1). Почему 3? А почему бы и нет? История «вход» средняя по сложности, поэтому она получает средний балл. Три – это средний балл при шестибалльной шкале оценки историй.

Рис. 3.1. История «вход» получает три единицы сложности

Теперь история «вход» становится эталоном. С ней будут сравнивать все истории при проведении оценки. Так, например, выход из системы гораздо проще, чем вход в нее. Поэтому история «выход» получает единицу. Выдача наличных, вероятно, в два раза сложнее, чем вход, поэтому эта история получает 6 единиц. Внесение наличных представляет собой примерно то же самое, что и выдача, однако эту историю реализовать чуть легче. Отдадим ей 5 единиц. И, наконец, реализация перевода не сложнее, чем реализация входа, поэтому она получает те же 3 единицы.

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

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

Единицы сложности историй должны быть линейными. История на карточке, оцениваемая в 2 единицы, должна быть вдвое легче той, что оценена в 4. Впрочем, линейность не обязана блюстись в совершенстве. Помните, что это оценка, поэтому точность намеренно остается размытой. На историю, оцененную в 3 единицы, Джим может потратить два дня, если больше не появится ошибок, на которые приходится отвлекаться. А Пэт сможет выполнить ее за день, если работает из дома. Эти оценки слишком расплывчаты, неотчетливы и неточны, поэтому их нельзя связывать с определенными промежутками времени.

Но в таких расплывчатых и неотчетливых оценках есть своя прелесть. Эта прелесть – закон больших чисел[37]37
  https://ru.wikipedia.org/wiki/Закон_больших_чисел.


[Закрыть]. При многократном выполнении задания размытость сводится на нет! Это преимущество мы будем использовать позднее.

Планирование первой итерации

Между тем пришло время планировать первую итерацию. Встречу по ее планированию можно считать началом. Эта встреча по плану должна составлять одну двадцатую продолжительности всей итерации. То есть если итерация длится две недели, на нее требуется затратить полдня.

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

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

Важно осознавать, что скорость не является обязательством. Команда не дает обещание, что 30 единиц будут выполнены за итерацию. Она даже не обещает постараться выполнить эти 30 единиц. Эта скорость не более чем предположение о том, сколько единиц в лучшем случае будут выполнены к концу итерации. А такое предположение не может отличаться высокой достоверностью.

Прибыль от вложений

Теперь заинтересованные стороны нарисовали квадрат и поделили его на четыре участка (рис. 3.2).

Рис. 3.2. Квадрат с четырьмя участками

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

С помощью этого квадрата выполняется расчет окупаемости инвестиций (ROI). Здесь нет формальностей и не нужно никакой математики. Заинтересованные стороны просто смотрят на карточку и делают вывод, основываясь на оценках приоритета и сложности истории.

Например: «Вход довольно важен, но также и сложен. С ним подождем. Выход тоже важен, но будет попроще. О! Давайте его! Выдача наличных… сложно, очень сложно. Но нам в первую очередь важно показать как раз эту функцию. Поэтому делайте ее».

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

Промежуточная проверка

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

К середине итерации должно быть выполнено много историй. А сколько единиц должно оставаться? Правильно, столько же, сколько и сделано. В нашем случае это 15. Чтобы провести промежуточную проверку, нужно уметь делить на два.

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

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

В пятницу после обеда подводится итог итерации с демонстрацией. Оказывается, выполнено лишь 18 единиц. Итерация провальна?

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

Вчерашняя погода

Теперь мы знаем, сколько единиц сложности историй мы можем выполнить за неделю – около 18. Как думаете, сколько единиц запланируют заинтересованные стороны в понедельник, в начале следующей итерации? Без сомнений, восемнадцать. Это называют вчерашней погодой. Вчерашняя погода лучше всего предскажет, какая погода будет сегодня. А вернее всего ход текущей итерации может предсказать то, что получено в ходе предыдущей.

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

Нет, не стоит. Они сами все увидят. Поэтому заинтересованные стороны добавляют шесть дополнительных единиц, чтобы по плану вышло 24.

Конечно, выходит так, что команда успевает выполнить только 22. Поэтому на следующую итерацию планируется 22 единицы.

Окончание проекта

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

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

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

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

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

Истории

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

Истории должны соответствовать следующим атрибутам качества (критерии INVEST).

• Независимость (Independent). Пользовательские истории независимы друг от друга. Это значит, что истории необязательно выполнять в каком-то определенном порядке. Например, выход не нужно выполнять после входа.

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