Гибкая методология разработки ПО

В предыдущем тематическом посте мы рассмотрели 12 основных методологий программирования (и да, забыли Kanban). Самое время взглянуть на каждый из пунктов подробнее, познав суть, преимущества и недостатки, область применения. Начнем с одного из фундаментальных понятий — Agile-разработки.

Историческая справка

В 1970 году Уинстон Ройс опубликовал статью под названием «Управление разработкой больших программных систем» (Winston Royce, «Managing the Development of Large Software Systems»). В ней он жестко прошелся по традиционной каскадной модели, показав, что при неитерационной разработке качество продукта получается низкое, а цена каждой ошибки начального уровня велика. Кстати, именно Ройс впервые ввел понятие водопада для описания последовательного программирования.

В качестве альтернативы он привел гибкую модель разработки, когда продукт разрабатывается одновременно несколькими группами программистов, а объем определяется порядком итерации. Алгоритм такой: сначала планируется, создается и тестируются базовые возможности приложения, оно получает фидбэк от клиентов или руководства, после чего устраняются недостатки, добавляется функциональность, цикл повторяется вновь и так далее до бесконечности. В идеале каждая итерация должна занимать 2−4 недели, занятость программистов на всех этапах создания продукта должна быть равной.

Курица, яйцо и манифест

Идея гибкой разработки получила массу поклонников и, как следствие, ответвлений. Чтобы хоть как-то объединить их, в 2001 году свет увидел Agile Manifesto — идеологический набор правил разработки, что-то вроде «Цели и задачи в области качества» на предприятиях. Он содержит 4 идеи и 12 принципов, описанных в том числе на русском языке. Основа — регламентация приоритета между документами, инструментами и человеческими отношениями. В Agile ответ категоричен — люди и их желания первичны. Описанное в манифесте не является чем-то уникальным, подавляющее большинство моделей и методологий разработки основываются на том, что клиент всегда прав, а исполнитель должен иметь мотивацию и соответствующие условия труда. Однако именно здесь описанное стоит понимать буквально.

Основные этапы

Однако вернёмся к концепции гибкой разработки. Графически её можно представить следующим образом:

Важно помнить, что Agile — это общая концепция. Где-то под циклом понимается путь от анализа и планирования до выпуска, где-то это просто этап разработки, связанный с определённым уровнем сложности. Но везде есть 4 стадии:

1. Планирование. Ограниченный по времени этап из-за большого числа итераций и постоянно меняющихся требований.
2. Обратная связь. Она может поступать от клиентов, программистов, тестировщиков и самих разработчиков — любых заинтересованных лиц.
3. Реализация. Собственно сама разработка кода и графики.
4. Тестирование. Автоматическое или ручное выявление ошибок и несоответствий требованиям заказчика.

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

Преимущества и недостатки

Начнём с плюсов:

1. Максимальная удовлетворённость клиента. У него есть постоянный контакт с разработчиками, его пожелания быстро находят отклик в проекте.
2. Благоприятная атмосфера в коллективе. Даже в случае разногласий эффективнее все решать словами.
3. Высокие цели. Постоянный фидбек предполагает внимание к мелочам, эргономике, соответствию трендам.
4. Безопасность. Множество итераций исключает существование ошибок, допущенных в самом начале.

Но есть и минусы:

1. Слабое внимание к документации. В случае возникновения претензий и конфликтных ситуаций аргументов в свою защиту у исполнителя просто не будет.
2. Проблемы с реализацией комплексных продуктов. Если в самом начале разработки были заложены ограничения — на поздних этапах исправлять их будет сложно.
3. Вероятность отказа клиентов в процессе разработки. Если у заказчика нет четкого понимания, что он хочет видеть на выходе — выполнять его требования очень сложно.
4. Влияние иерархии. Руководители принимают все решения, так как все процессы цикла реализуются параллельно. Важность рядовых программистов минимальна.

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

Что почитать

Отечественный и зарубежный рынок насыщен книгами по гибкой разработке, поэтому интересующимся не составит труда найти себе подходящее чтиво. Вот мой список ТОП-3:

1. «Постигая Agile. Ценности, принципы, методологии», Эндрю Стеллман, Дженнифер Грин. Издательство O’Reilly редко разочаровывает, эта книга - определённо не исключение. В ней вы узнаете и про общую концепцию, и подробнее про Scum, Kanban, XP и Lean.
2. «Гибкая разработка программ на Java и C++. Принципы, паттерны и методики», Роберт С. Мартин. Agile в прикладном применении.
3. «Пользовательские истории. Гибкая разработка программного обеспечения», Майк Кон. Истории правильного и неправильного применения гибкой разработки ПО, советы по внедрению конкретных методологий.

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