Документ рассматривает исторические методологии разработки программного обеспечения, начиная с модели водопада и спиральной модели до современного agile подхода, включая Scrum и Extreme Programming. Основное внимание уделяется различиям между итеративными и инкрементными моделями, а также их потенциальным преимуществам и недостаткам. В документе также обсуждаются ключевые идеи и принципы, сформулированные в манифесте Agile.

1. Методологии разработки ПО

2. Хронология
• 1970 — статья Уинстона Ройса «Managing the Development of
Large Software Systems» [Royce, 1987]; первое упоминание о
методике, близкой к современной «модели водопада»,
название «модель водопада» в статье не использовано.
• 1976 — опубликована работа Тома Гилба Software Metrics, где
впервые использовался термин «эволюционная методология».
[Ларман, Базили, 2003]
• 1986 — статья Барри Боэма «A spiral model of software
development and enhancement» [Boehm, 1986]; посвящена
спиральной модели разработки программного обеспечения.
• 1998, июнь — Rational Corporation выпускает новую версию
продукта Rational Unified Process 5.0 [Якобсон и др., 2002]
• 2001, февраль — появление Manifesto for Agile Software
Development [Manifesto for Agile Software Development, 2001],
где закреплены основные положения гибких методов.

3. Водопадная модель
Сокращенная модель

4. Водопадная модель
Полная модель

5. Водопадная модель
Историческая перспектива

6. Итеративная / инкрементная
модель
• С точки зрения структуры жизненного
цикла модель итеративная, так как
представима серией многократных
повторений одинаковой операции.
• С точки зрения развития продукта модель
инкрементная, то есть основанная на
приращениях продукта.
• В основе лежит цикл PDSA.

7. Итеративная / инкрементная
модель
«‘Эволюция’ — прием, предназначенный для создания
видимости стабильности. Шансы успешного создания
сложной системы будут максимальными, если она
реализуется в серии небольших шагов и если каждый
шаг заключает в себе четко определенный успех, а
также возможность ‘отката’ к предыдущему успешному
этапу в случае неудачи. Перед тем, как пустить в дело
все ресурсы, предназначенные для создания системы,
разработчик имеет возможность получать из реального
мира сигналы обратной связи и исправлять возможные
ошибки в проекте...»
Том Гилб
«Software metrics», 1976

8. Итеративная / инкрементная
модель
• Жизненный цикл проекта разбивается на мини-проекты, которые сами по
себе также зачастую являются полным жизненным циклом, только
охватывающим меньший функционал.
• В сжатые сроки можно проанализировать, в какой момент времени были
приняты неправильные или неоптимальные решения, и, при необходимости,
вернуться не на исходные позиции, а на соответствующий этап.
• При наличии ресурсов, возможна организация параллельной разработки на
ряде этапов (см. «Deadline. Роман об управлении проектами» Тома ДеМарко).
• Возможность раннего начала тестирования (как профессионального, так и
пользовательского), соответственно и нахождения критичных ошибок на
начальных этапах.
• Возможность маневрирования, многократной смены приоритетов в течение
процесса разработки и, как следствие, наличие возможности сдачи в
эксплуатацию не законченного или не соответствующего изначально
определенным требованиям, но работающего проекта, удовлетворяющего
заказчика.
• Снижение неопределенности и соответственно рисков.

9. Спиральная модель (1986)

10. Спиральная модель (2003)

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

12. Agile / гибкие методологии
• 11-13 февраля 2001 года ряд 17 «лидеров гибких
методологий» сформировали группу под
названием Agile Alliance.
• Слово agile (быстрый, ловкий, стремительный)
отражало в целом их подход к разработке ПО,
основанный на богатом опыте участия в
разнообразных проектах в течение многих лет.
• Этот подход под названием "Быстрая разработка
ПО" (Agile software development) базируется на
четырех идеях, сформулированных ими в
документе «Манифест быстрой разработки ПО"
(Agile Alliance's Manifesto).

13. Agile Alliance’s Manifesto
4 положения:
• индивидуумы и взаимодействия между ними ценятся выше
процессов и инструментов;
• работающее программное обеспечение ценится выше
всеобъемлющей документации;
• сотрудничество с заказчиками ценится выше формальных договоров;
• реагирование на изменения ценится выше строгого следования
плану.
4 условия успешности:
• если позволяет людям легче выразить свои мысли;
• если выполняет задачи, невыполнимые вручную;
• если автоматизирует утомительные и подверженные ошибкам
действия;
• если облегчает общение между людьми.

14. SCRUM
• Takeuchi H., Nonaka I. The new product
development game (1986)
• Scrum – термин, означающий схватку
вокруг мяча регби.
• Процесс формализован в 1995 году Кеном
Швабером

15. SCRUM
Методология определяет правила:
• планирования и управления списком требований к продукту для достижения
максимальной прибыльности от реализованной функциональности;
• планирования итераций для максимальной заинтересованности команды
в результате;
• взаимодействия участников команды для максимально быстрой реакции на
существующую ситуацию;
• анализа и корректировки процесса разработки для совершенствования
взаимодействия внутри команды.
• 3 роли
• 3 практики
• 3 документа
Подробнее: http://www.scrum.org/

16. eXtreme Programming (XP)
• Бек К. Экстремальное программирование. СПб.: Питер, 2002. — 224 с.
• 12 подходов:
– разработка через тестирование (Test Driven Development);
– игра в планирование (Planning Game);
– заказчик всегда рядом (Whole Team, Onsite Customer);
– парное программирование (Pair Programming);
– непрерывная интеграция (Continuous Integration);
– рефакторинг (Design Improvement, Refactoring);
– частые небольшие релизы (Small Releases);
– простота (Simple Design);
– метафора системы (System Metaphor);
– коллективное владение кодом (Collective Code Ownership);
– стандарт кодирования (Coding Standard or Coding conventions);
– 40-часовая рабочая неделя (Sustainable Pace, 40-hour week).

17. См. также
• Rational Unified Process - http://www-
01.ibm.com/software/awdtools/rup/
• Feature Driven Development -
http://www.featuredrivendevelopment.com/
• Chaos Model -
http://info.psu.edu.sa/psu/cis/biq/se501/files/ch
aos93.pdf
• The Cathedral and the Bazaar -
http://www.amazon.com/Cathedral-Bazaar-Eric-
S-Raymond/dp/1607962284