Мы перевели на русский язык этот исторический документ и приглашаем вас окунуться в истоки подхода, чтобы глубже понять его суть.
Agile Альянс
Встреча состоялась в Сноубёрде, Юта, в феврале 2001 года.
На ней собрались 17 человек: Кент Бек, Майк Бидл, Ари ван Бенникум, Алистер Коберн, Уорд Каннингем, Мартин Фаулер, Джеймс Греннинг, Джим Хайсмит, Эндрю Хант, Рон Джеффрис, Джон Керн, Брайан Марик, Роберт С. Мартин, Стивен Дж. Меллор, Кен Швабер, Джефф Сазерленд и Дэйв «Практичный» Томас. (Если бы Дэйв А. Томас из Object Technology International смог приехать в ту неделю, у нас было бы два Дэйва Томаса в числе подписантов!)
Каждый из присутствующих видел эту встречу по-своему. То, что следует в этом приложении, — моя версия [Алистер Коберн] (но я показал этот текст остальным).
Целью нашей встречи было выяснить, есть ли что-то общее между различными “легкими” методологиями: Adaptive Software Development, XP, Scrum, Crystal, Feature-Driven Development, Dynamic System Development Method (DSDM) и “прагматичным программированием”.
- Кент Бек, Уорд Каннингем, Рон Джеффрис, Джеймс Греннинг и Роберт Мартин привнесли свои взгляды на XP, а также свой значительный опыт и личные пожелания.
- Мартин Фаулер поделился своим богатым опытом как в XP, так и в общей оценке методологий.
- Джим Хайсмит представлял Adaptive Software Development и идеи о возникающих свойствах сложных адаптивных систем.
- Я [Алистер Коберн] был там, защищая свои интересы в методологиях “под проект” и “методологиях по требованию”.
- Джефф Сазерленд, Кен Швабер и Майкл Бидл представляли Scrum (Schwaber 2001).
- Джон Керн из TogetherSoft представлял Feature-Driven Development, метод, описанный в книге “Java Modeling in Color with UML” (Coad 1999).
- Ари ван Бенникум из Нидерландов представлял DSDM (Stapleton 1997).
- Энди Хант и Дэйв «Практичный» Томас, авторы книги “The Pragmatic Programmer”, защищали интересы опытных программистов, не привязанных к какой-либо одной методологии.
- Брайан Марик представлял точку зрения тестирования программного обеспечения.
- Стивен Дж. Меллор присутствовал, чтобы защитить свои интересы в разработке, управляемой моделями. Возможно, он был больше всего удивлен тем, что смог согласиться с большинством того, что было сказано, и подписал как манифест, так и принципы.
- Были и другие, кого пригласили и кто, безусловно, внес бы свой вклад и подписал документы, но перечисленные — это те, кто был там, спорил, формулировал и подписывал соглашения.
Мы надеялись, что сможем действительно о чем-то договориться.
Никто из нас не был заинтересован в объединении практик для создания условной “Единой Легковесной Методологии (ULM)”.
Учитывая индивидуализм в комнате, было действительно удивительно, что мы вообще на чем-то сошлись.
Мы договорились о четырех вещах:
- На первом уровне мы согласились в необходимости реагировать на изменения. Мы согласились, что слово “гибкий” (agile) отражает наше намерение и позволяет обсуждать более тяжелые гибкие методологии для крупных и критически важных проектов.
- На втором уровне мы договорились о четырех основных ценностях, описанных в манифесте.
- На третьем уровне мы едва согласились на двенадцать более детальных утверждений, согласующихся с этими четырьмя ценностями.
- Было ясно, что на четвертом уровне — детальных практиках проекта — мы не договоримся. Мы согласились, что это полезно для индустрии и что мы должны продолжать инновации и конкуренцию в мире идей, чтобы открыть больший набор гибких практик разработки программного обеспечения.
С этими соглашениями и принятием термина “Agile” 17 человек создали Agile Alliance.
Манифест
Давайте внимательнее посмотрим на формулировки манифеста.
“Мы раскрываем лучшие методы разработки программного обеспечения, делая это сами и помогая другим делать это.”
Мы (люди в группе) — практики разработки программного обеспечения, а не просто наблюдатели, устанавливающие правила для других. Мы чувствуем, что скорее “раскрыли” практики, чем изобрели их, и хотим ясно дать понять, что будем продолжать работать, помогая, а не только рассказывая.
“Благодаря этой работе мы пришли к ценности…”
Идеи не возникли в вакууме, а являются результатом нашего прямого опыта и размышлений над ним.
Прежде чем перечислить четыре ценности, я забегу вперед и посмотрю на завершающее предложение:
“То есть, хотя ценность есть в элементах справа, мы больше ценим элементы слева.”
Мы признаем, что инструменты, процессы, документация, контракты и планы имеют ценность. Но мы считаем, что люди, цепляющиеся за правые элементы списка, не справятся так хорошо, как те, кто держится за левые.
Мы также хотим признать, что некоторые люди не согласны с одним или всеми нашими ценностями. Один человек, увидев наш список, сказал: “Я могу согласиться с тремя пунктами из четырех.” Мы приняли, что такого рода несогласие может привести к конструктивным разговорам.
Лично для меня важно оставить место для разногласий. Наша индустрия все еще не согласна в том, что критично для успешной разработки программного обеспечения. Лучший подход на данный момент — просто заявить о своих позициях. Очевидно, этот момент важен и для других подписантов.
С учетом этого давайте посмотрим на четыре ценности манифеста:
1. “Люди и взаимодействие важнее процессов и инструментов.”
Первая часть — это внимание к людям в команде, а не к ролям в процессной диаграмме. Хотя описание процесса необходимо, чтобы запустить группу людей, люди не являются заменяемыми “элементами”, как мы уже видели.
Вторая часть — это внимание к взаимодействию между людьми. Новые решения и недостатки старых решений возникают в обсуждениях между людьми. Качество взаимодействий имеет значение.
Что выражает эта первая ценность, так это то, что мы предпочли бы использовать недокументированный процесс с хорошими взаимодействиями, чем документированный процесс с враждебными взаимодействиями.
2. “Работающий продукт важнее исчерпывающей документации.”
Работающая система — это единственное, что говорит вам, что команда достигла результата. Запущенный код беспощадно честен.
Документы, показывающие требования, анализ, дизайн, потоки экранов, диаграммы последовательности взаимодействия объектов и тому подобное, удобны как подсказки. Члены команды используют их как вспомогательные средства для размышления над собственным опытом, чтобы предположить, как будет выглядеть будущее.
Документы служат маркерами в игре, используемыми для построения образа ненадежного будущего.
С другой стороны, совокупный акт сбора требований, проектирования, кодирования и отладки программного обеспечения раскрывает информацию о команде разработки, процессе разработки и природе проблемы, которую нужно решить. Эти вещи вместе с запущенным конечным результатом предоставляют единственную надежную меру скорости команды, недостатков группы и представление о том, что команда действительно должна строить.
Документы могут быть очень полезны, как мы видели, но их следует использовать вместе с фразами “ровно столько, сколько нужно” и “едва достаточно”.
3. “Сотрудничество с заказчиком важнее согласования условий контракта.”
Третья ценность описывает отношения между людьми, которые хотят, чтобы программное обеспечение было построено, и теми, кто его строит. Различие в том, что в правильно сформированном гибком развитии нет “мы” и “они”, есть только “мы”.
Сотрудничество связано с сообществом, дружелюбием, совместным принятием решений, быстротой коммуникации и связями с взаимодействиями между людьми. Внимание к сотрудничеству с заказчиком указывает на дружеские отношения (что не исключает конфликтов) через специальные области и организационные границы. Утверждение “есть только мы” относится к тому факту, что оба необходимы для создания хорошего программного обеспечения.
Хотя контракты иногда полезны, сотрудничество укрепляет разработку как при наличии контракта, так и без него. Хорошее сотрудничество может спасти ситуацию с контрактом, когда она находится под угрозой. Хорошее сотрудничество иногда может сделать контракт ненужным. В любом случае, сотрудничество — выигрышный элемент.
4. “Готовность к изменениям важнее следования плану.”
Последняя ценность касается адаптации к быстро меняющимся изменениям проекта.
Построение плана полезно, и каждая из гибких методологий содержит специальные активности по планированию. Они также содержат механизмы для работы с изменяющимися приоритетами.
Scrum, DSDM и Adaptive Software Development призывают к разработке с жесткими временными рамками (timeboxed development) с переприоритизацией после (а не в течение) каждого временного блока (XP позволяет переприоритизацию внутри временного блока). Периоды временных блоков обычно находятся в диапазоне от двух до четырех недель. Жесткое ограничение по времени гарантирует, что у команды есть время и спокойствие для разработки работающего программного обеспечения. Относительно короткие фазы разработки, которые Scrum называет “спринтами”, позволяют спонсорам проекта менять приоритеты в соответствии со своими потребностями.
Построение плана полезно. Обращение к плану полезно до тех пор, пока он не отходит слишком далеко от текущей ситуации. Удерживание устаревшего плана не полезно.
Размышления о Манифесте
Необходимость разных способов работы в разных ситуациях не отражена в манифесте, но Джим Хайсмит и я любим всегда держать эту мысль в уме.
Быть гибким для проекта на 100 человек — это не то же самое, что для проекта на 10 человек.
Гибкий проект на 100 человек будет использовать более тяжелую методологию, чем гибкий проект на 10 человек. Это соответствует принципам проектирования методологий.
Также, в соответствии с принципами проектирования методологий, может быть правильнее сократить 90 человек из проекта на 100 человек, оставить 10 лучших людей и затем запустить гибкий проект на 10 человек, который доставит ту же систему в тот же временной период.
Некоторые люди в комнате рекомендуют гибкие методологии в первую очередь для ситуаций с высоким уровнем изменений. Мой опыт показывает, что грубые сюрпризы возникают даже в якобы стабильных проектах. Я все еще жду случая, когда набор гибких ценностей не будет уместен.
Поддержка ценностей
Группа из 17 человек быстро согласилась с этими четырьмя ценностями. Разработка следующего уровня утверждений оказалась более сложной, чем мы могли решить в оставшееся время встречи. Принципы, включенные в этот раздел, составляют текущий рабочий набор.
Эти утверждения должны развиваться по мере того, как мы узнаем восприятие людьми наших слов и как мы сами придумываем более точные формулировки. Я буду удивлен, если эта конкретная версия не станет устаревшей вскоре после публикации книги.
Это принципы, с которыми мы согласились, и мой комментарий к каждому из них.
1. Наша высшая цель — удовлетворить потребности заказчика через раннюю и непрерывную доставку ценного программного обеспечения.
Мы заинтересованы в доставке программного обеспечения, которое соответствует своей цели. Странно, но некоторые компании, которые я посещаю, кажется, не ценят фактическую доставку программного обеспечения. Гибкая разработка сфокусирована на доставке.
Ранняя доставка позволяет получить быстрые победы и раннюю обратную связь о требованиях, команде и процессе.
Частая доставка позволяет команде продолжать побеждать, получать быструю обратную связь и вносить изменения в направлении проекта и приоритетах в середине проекта.
Продолжительность, используемая для доставок, должна согласовываться для каждого проекта, потому что доставка обновлений на ежедневной или еженедельной основе может вызвать больше беспокойства у пользователей, чем это стоит. Когда пользователи не могут усваивать изменения в системе так часто, как каждые три месяца, команда проекта должна организовать другой способ получения этой обратной связи и убедиться, что процесс работает до конца тестирования и интеграции.
Это утверждение подчеркивает доставку тех элементов, которые имеют наибольшую ценность для клиентов. С изменениями настроения потребителей, интенсивной конкуренцией и колебаниями на фондовом рынке практически невозможно гарантировать поток доходов для проекта, который требует год или больше для доставки.
Это утверждение указывает на то, что ценность будет доставлена рано, чтобы в случае, если спонсоры потеряют финансирование, они не остались с кучей долговых расписок, а с работающим программным обеспечением, которое приносит ценность покупателям.
2. Доставляйте работающий продукт часто, с периодичностью от нескольких недель до нескольких месяцев, предпочитая более короткий временной интервал.
Эта половина “ранней и частой” доставки определяет длину рабочих циклов. Я встречал редкие проекты, которые могут проводить инкрементальную разработку с четырехмесячными циклами, но большинство использует циклы от одного до трех месяцев. Использование более коротких циклов редко, потому что пользователи обычно не могут воспринимать более частые изменения.
На проекте Winifred (Cockburn 1998), контракте с фиксированной ценой, включающем 50 человек в течение 18 месяцев, мы зафиксировали наши циклы для доставок пользователям на три месяца. Зная, что это действительно слишком долго ждать обратной связи, мы убедились, что некоторые экспертные пользователи приходят и имеют две возможности просмотреть запущенный код внутри каждого цикла. Эти два просмотра пользователями были гибко запланированы, обычно около шестой и восьмой недель.
Если пользователи могут принимать изменения каждый месяц, и команда разработки может соответствовать текущим запросам на изменения, то более короткий цикл обратной связи лучше.
3. Работающий продукт — главный показатель прогресса.
Это третье упоминание о работающем программном обеспечении. Этот принцип утверждает это твердо: полагайтесь на честность, которая приходит с запущенным кодом, а не на долговые расписки в виде планов и документов. Вы можете использовать и другие меры прогресса, но работающий код — это то, на что можно положиться.
Гибкие методологии придают большое значение тому, чтобы что-то запустить и настроить как можно раньше и развивать это со временем. Не все проекты одинаково подходят для крошечных эволюционных шагов. Решение о том, как разбить гигантскую архитектуру на большом проекте на более мелкие части, которые можно построить и протестировать инкрементально, требует некоторой работы. Однако это можно сделать и это стоит усилий.
4. Приветствуйте изменяющиеся требования, даже на поздних стадиях разработки. Гибкие процессы обращают изменения в конкурентное преимущество заказчика.
Гибкие процессы могут принять поздние изменения в требованиях именно благодаря ранней и частой доставке работающего программного обеспечения, использованию итеративных техник и техники жестких временных рамок, постоянному вниманию к архитектуре и готовности обновлять дизайн.
Если ваша компания может быстро доставлять и реагировать на позднюю информацию, а компания вашего конкурента не может, то ваша компания может опередить конкурентов на программном фронте. Это часто приводит к значительной разнице на рынке.
Все гибкие методологии имеют какой-то механизм для включения поздних изменений в требования, как уже обсуждалось. Детали различаются в зависимости от методологии.
5. Бизнес-заказчики и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Индустрия завалена проектами, спонсоры которых не потратили время, чтобы убедиться, что они получили то, что им нужно. Фрейкс и Фокс сообщили об исследовании, показывающем сильную корреляцию между связями с пользователями и успехом или провалом проекта (Frakes 1995).
Лучшие связи — это через экспертные знания на месте и ежедневные обсуждения. Слово “ежедневно” относится к оптимальной точке, где обсуждения происходят постоянно и по требованию. Ежедневные обсуждения не практичны на большинстве проектов, что означает, что проект не находится в оптимальной точке. Утверждение указывает, что чем дольше требуется, чтобы получить информацию до и от разработчиков, тем больше ущерба будет нанесено проекту.
6. Стройте проекты вокруг мотивированных людей. Дайте им среду и поддержку, в которой они нуждаются, и доверьте им выполнение работы.
Мы предпочли бы видеть мотивированных, умелых людей, которые хорошо общаются и не используют никакого процесса вообще, чем хорошо определенный процесс, используемый немотивированными индивидами.
История Ди Хока о ранней системе VISA дает экстремальный пример этого.
Индивидуумы делают проекты успешными. Их мотивация связана с гордостью за работу, дружелюбием и сообществом в проекте.
Впервые я столкнулся с этим утверждением в интервью о проекте с Дэйвом А. Томасом, тогдашним президентом очень успешной компании Object Technology International. Он сказал:
“Мы нанимаем хороших людей, даем им инструменты и обучение, чтобы они могли выполнить свою работу, и не мешаем им.”
Я продолжаю находить доказательства в поддержку его рекомендации.
7. Наиболее эффективный и действенный метод передачи информации в команде разработки — личный разговор.
Это прямо вытекает из всего того, что мы обсуждаем. Я не буду останавливаться на этому пункте подробно.
8. Лучшие архитектуры, требования и дизайны возникают в самоорганизующихся командах.
Мы провели некоторые обсуждения вокруг выбора слов в этом принципе. Насколько самоорганизующимися мы имеем в виду: полностью самоорганизующимися или просто позволяющими хорошим идеям исходить от любого человека на проекте? Мы имеем в виду, что они возникают таинственно, возникают маленькими шагами со временем или возникают как логическое следствие человеко-центрированных правил, которые использует команда?
Я предпочитаю средний из трех вариантов. Джим предпочитает последний из трех. Никто из нас не имеет в виду первый из трех, который возникает из непонимания слова “возникающий” как “удачный”. Наша общая точка зрения — признание того, что детали системного дизайна удивляют даже самых опытных проектировщиков.
Мы настаиваем на том, чтобы архитектура могла корректироваться со временем, так же как требования и процесс. Архитектура, которая слишком жестко зафиксирована слишком рано, не сможет адаптироваться к неизбежным сюрпризам, возникающим во время реализации и при изменении требований. Архитектура, которая растет поэтапно, может следовать изменяющимся знаниям команды и меняющимся желаниям пользовательского сообщества.
9. Постоянное внимание к техническому совершенству и хорошей архитектуре повышает гибкость.
Аккуратный, хорошо инкапсулированный дизайн легче изменять, а это означает большую гибкость для проекта. Поэтому, чтобы оставаться гибкими, архитекторы должны изначально создавать хорошие решения. Они также должны регулярно пересматривать и улучшать свои разработки, чтобы учесть лучшее понимание системы, которое приходит со временем, и исправить моменты, когда они жертвовали качеством ради краткосрочных целей.
Управление техническим долгом
Уорд Каннингем иногда сравнивает очистку дизайна с погашением долгов. Идя дальше, он обсуждает управление техническим долгом в проекте.
Поспешные добавления в систему соответствуют взятию взаймы, принятию долга. Рефакторинг системы соответствует погашению этого долга. Иногда, как он отмечает, целесообразно взять на себя долг и внести быстрые изменения, чтобы воспользоваться возможностью. Однако, так же как долг накапливает проценты и растет со временем, растут и затраты на проект при отсутствии рефакторинга этих поспешных изменений в дизайне.
Учитывая богатый опыт присутствующих, мне было интересно увидеть такое внимание к качеству дизайна одновременно с вниманием к коротким временным рамкам, легкой документации и людям.
10. Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны быть в состоянии поддерживать постоянный темп неопределенно долго.
У этого утверждения есть две стороны. Одна связана с социальной ответственностью, другая — с эффективностью проекта. Не все на встрече были заинтересованы подписаться под платформой социальной ответственности, но мы все согласились с вопросом эффективности.
Люди устают, когда долго и непрерывно работают. Их скорость замедляется не только во время переработок, но и в обычные часы. Они допускают больше ошибок в своей работе. С уменьшением отдачи дополнительные часы становятся менее эффективными. Это часть нелинейности человеческого фактора.
Бдительная и вовлеченная команда более гибка, чем усталая, медленно работающая, даже без учета всех вопросов социальной ответственности. Переработки — симптом того, что что-то пошло не так в планировании проекта.
11. Простота — искусство максимизации объема невыполненной работы — необходима.
Простота необходима. С этим легко согласиться. Однако понятие простоты настолько субъективно, что трудно сказать о нем что-то полезное. Поэтому мы были рады обнаружить, что все можем поддержать это утверждение.
В проектировании процессов разработки простота связана с достижением результата без лишних действий, максимизацией невыполненной работы при создании хорошего программного обеспечения. Джон Керн напоминает нам замечание Паскаля:
«Я написал это письмо длиннее, чем хотел, потому что у меня не было времени сделать его короче».
Этот комментарий раскрывает сложность создания простых вещей. Громоздкую модель легко создать. Создание простого дизайна, который эффективно справляется с изменениями, более сложно.
С точки зрения методологии и людей, Джим Хайсмит любит цитировать Ди Хока:
«Простая, ясная цель и принципы порождают сложное, интеллектуальное поведение.
Сложные правила и регламенты порождают простое, глупое поведение».
12. С регулярными интервалами команда размышляет о том, как стать более эффективной, и соответственно настраивает и корректирует свое поведение.
Насколько легким должен быть процесс для любого проекта? Едва достаточным и, вероятно, легче, чем вы ожидаете.
Насколько продуктивно мы работаем в проекте? Уделите время размышлениям о том, что вы делаете. Если ваша команда будет проводить час вместе каждые две недели, размышляя о своих рабочих привычках, вы сможете развить свою методологию так, чтобы она была гибкой, эффективной и подходящей к контексту вашего проекта. Если вы не можете сделать это, что ж… вы останетесь там, где находитесь.
Размышления о поддерживающих принципах
Заставить 17 человек согласиться с любым набором слов сложно. Чем более детализирован совет, тем больше на первый план выходят личный опыт и философия каждого из людей.
Мы надеемся, что четыре основных ценности и двенадцать поддерживающих принципов дадут вам достаточно информации, чтобы построить собственный гибкий подход к выполнению вашего проекта.
