Часть 2. Манифест и принципы гибкой разработки

Данный материал является продолжением цикла статей, посвящённых теме гибких методов разработки программного обеспечения. В первой части цикла (см. "КВ" №33) мы выяснили, что гибкие методы появились как попытка исправить недостатки традиционных инженерных методологий разработки, основанных на детальном предварительном планировании и водопадном жизненном цикле. Ближе к концу 90-х годов в противовес тяжеловесным и излишне формализованным инженерным методологиям появилось целое семейство новых "легковесных" методологий, таких, как Scrum, XP, DSDM, Crystal и т.д. В феврале 2001 года на встрече группы создателей и лидеров легковесных методологий было решено в качестве объединяющего названия использовать слово agile (гибкий, быстрый, проворный). Тогда же были созданы два основополагающих документа, определяющие наполнение слова agile: Манифест и Принципы гибкой разработки программного обеспечения. Цель сегодняшней статьи - понять основные идеи гибкой разработки, познакомившись с содержанием этих двух документов.

Agile - новое семейство методологий разработки

Итак, в феврале 2001 года, по сути, официально оформилось новое направление развития методологий разработки программного обеспечения. На смену хаосу ранних подходов к разработке (code-and-fix) и строгой формализации инженерных методологий пришло семейство гибких методологий, основанных на Манифесте и Принципах разработки программного обеспечения.

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

Манифест гибкой разработки

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

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

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

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

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

Принципы гибкой разработки

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

Первый и второй принципы тесно связаны с последней из альтернатив Манифеста. Наивысшим приоритетом в гибких методологиях считается не точное следование начальному плану проекта, а удовлетворение заказчика и достижение тех бизнес-целей, ради которых затевался проект. Таким образом, трактовка понятия успеха проекта в agile отличается от традиционных подходов, в которых проект считался успешным, если были удовлетворены все 3 основных проектных ограничения (бюджет, сроки, объём требований). Гибкие методологии небезосновательно настаивают на том, что само по себе выполнение плана ещё не приносит никакой пользы, более того, именно изменения в начальном плане могут в итоге придать наибольшую ценность проекту (прежде всего, потому, что они основаны на обратной связи и наиболее свежей информации о внутренних и внешних факторах, например, таких, как положение на рынке, состояние аналогичных продуктов у конкурентов и т.п.).

Третий принцип призывает использовать итерационный жизненный цикл для разработки программного обеспечения (мы говорили о проблемах водопадного цикла в нашей первой статье). Длина итерации отличается в различных гибких методологиях, но обычно составляет от 1 до 6 недель (в зависимости от методологии, типа проекта и т.д.). Общее правило при этом - чем короче, тем лучше.

Четвёртый принцип подчёркивает необходимость тесного сотрудничества команды проекта и заказчика в течение всего жизненного цикла проекта. Как афористично пишут М. Фоулер и Дж. Хайсмит [3], многие заказчики думают, что заказное программное обеспечение можно купить так же, как мы покупаем автомобиль: договориться о цене, заплатить и спокойно ожидать получения своей покупки. Однако в случае с софтом полученный в итоге продукт будет, скорее всего, как небо и земля розниться с ожиданиями заказчика. Чтобы получить на выходе что-нибудь путное, необходимо работать в тесном контакте с командой проекта, обеспечивая обратную связь.

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

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

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

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

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

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

Заключение

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

Константин РАЗУМОВСКИЙ,
krazumov@gmail.com

Ссылки:

1. agilemanifesto.org - Манифест гибкой разработки программного обеспечения
2. agilemanifesto.org/principles.html - принципы гибкой разработки программного обеспечения.
3. www.ddj.com/architect/184414755 - Статья соавторов Манифеста М. Фоулера и Дж. Хайсмита, содержащая анализ Манифеста и Принципов гибкой разработки.

Манифест гибкой разработки программного обеспечения

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

• Личности и их взаимодействия выше, чем процессы и инструменты.
• Работоспособное программное обеспечение выше, чем обширную документацию.
• Сотрудничество с заказчиком выше, чем переговоры по контрактам.
• Умение реагировать на изменения выше, чем следование плану.

Таким образом, хотя и существует ценность в понятиях, стоящих в правой части этих сравнений, мы ценим понятия, стоящие в левой части, больше.

Принципы гибкой разработки программного обеспечения

1. Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.
2. Приветствуйте меняющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения как средство получить конкурентные преимущества для заказчика.
3. Поставляйте работоспособное программное обеспечение часто: от раза в несколько недель, до раза в несколько месяцев, отдавая предпочтение коротким интервалам.
4. Представители бизнеса и разработчики должны работать вместе в течение всего проекта.
5. Стройте проекты вокруг мотивированных личностей. Предоставьте им среду и поддержку, в которой они нуждаются, и доверьте им самим сделать работу.
6. Наиболее эффективный способ передать информацию в команду проекта (а также передавать её внутри команды) - это непосредственное живое общение.
7. Основной мерой прогресса проекта является работоспособное программное обеспечение.
8. Гибкие процессы поощряют разработку с постоянной скоростью. Спонсоры проекта, разработчики и пользователи должны быть способны поддерживать постоянную скорость на неограниченной дистанции.
9. Непрерывное внимание техническому совершенству и хорошему дизайну увеличивает степень гибкости.
10. Простота - искусство максимизации работы, которую не надо делать, - является существенным фактором.
11. Наилучшие архитектуры, требования и дизайн создаются самоорганизующимися командами.
12. Через регулярные промежутки времени команда должна проводить анализ того, как стать более эффективной и улучшать свой процесс работы.