Основные принципы и «Манифест гибкой разработки программного обеспечения»»

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по «гибкой» разработке программного обеспечения.

Четыре основополагающих принципа Agile-манифеста.

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

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

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

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

То есть, не отрицая важности того, что справа, больше ценится то, что слева.

Суть agile-подхода, изложенного в «Манифестегибкой разработки ПО» для заказчика можно коротко сформулировать так:

- разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;

- в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;

- команда разработки сотрудничает с Заказчиком в ходе всего проекта;

- изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Двенадцать принципов Agile-разработки.

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

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

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией, как с самой командой, так и внутри команды.

7. Работающий продукт – основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10. Простота – искусство минимизации лишней работы – крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

Четвёртый принцип подчёркивает необходимость тесного сотрудничества

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

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

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

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

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

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

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

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

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

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