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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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