Роберт Мартин - Чистый Agile. Основы гибкости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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