Работа с agile командами

10.1 Гравитация все еще существует

Мы уже видели много примеров agile авторов, которые просят прекратить не доверять agile. Обобщения были сделаны в книге, выпущенной под эгидой IBM [Ambler 2012] с целью рассеивания различных возражений:

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

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

[Возражение: agile не обеспечивает масштабирования.] Agile определенно масштабируем. Большие команды должны быть организованы по-другому. Предполагается, что большие agile команды используют продукты, подобные IBM Rational Requirements Composer, для моделирования требований.

И так далее. Доверьтесь нам, и agile решит все ваши проблемы. Это не самый хороший совет, исходящий от такой почтенной компании, менеджерам, обязанным с осторожностью принимать важные решения.

Истина в том, что программная инженерия имеет свои законы, устанавливающие пределы нашим ожиданиям. За примером такого закона обратимся к работе Боема [Boehm 1981], опубликованной еще в восьмидесятых годах. С тех пор ее выводы неоднократно подтверждались в различных исследованиях. В ней утверждается, что для любого ИТ-проекта существуют две характеристики – номинальная стоимость и номинальная длительность проекта и что невозможно существенно влиять на значения этих характеристик. Рис. 10.1 иллюстрирует эту картину.

Рис. 10.1. Номинальные значения и возможные отклонения

Большая точка представляет точку номинала. В соответствии с проведенными исследованиями можно уменьшить время поставки, увеличивая расходы (нанять больше разработчиков или менеджеров или тех и других). Кривая на рисунке показывает зависимость между стоимостью и временем. Но кривая заканчивается в точке, характеризующей 75 % от номинального времени. Серая зона – это зона недостижимых значений. Невозможно получить результаты за меньшую стоимость, невозможно уменьшить время поставки более чем на четверть номинального времени.

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

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

В том самом спонсируемом IBM исследовании, утверждающем, что agile готов к развертыванию где-либо, приводятся данные, что 54 % опрошенных организаций пытались применить и отказались, по меньшей мере, от одного из agile подходов. Характерно, что в заключительном выводе утверждается, что продвигаемые методы (Scrum, Kanban, Lean) превосходны. Любому непредвзятому человеку ясно, что приведенная статистика служит предостережением: с осторожностью подходите к выбору agile методов.

Очевидно, что agile методы обладают рядом достоинств (иначе не было бы смысла в существовании этой книги). Но не следует надеяться на чудо. Устанавливайте реальные цели и стремитесь к их достижению.

10.2 Об одном заблуждении: "либо что, либо когда"

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

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

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

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

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

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

Для большинства потребителей этот трюк: выбирайте "либо что, либо когда" не работает. Потребители хотят знать "когда", точно так же, как и "что". Авторы agile надеются на "образованных", понимающих потребителей, которые с сочувствием относятся к трудным реалиям программистской жизни. Большинство потребителей, конечно, не поедут в летний лагерь повышать образование, они не попадут в эту ловушку даже при условии, что их зачислят в лагерь "посредственностей и бюрократов" (в терминологии авторов, упоминаемых в начальных главах). Называйте нас бюрократами сколько угодно, но мы хотим потратить определенную сумму денег, установить, какие бизнес-результаты должны быть получены, и установить время их получения.

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

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

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

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

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

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