Чтобы понять почему адаптивные подходы получили популярность нужно понять историческую перспективу. Какая была ситуация на 1995-1996 год (даты выпуска XP, Scrum)? Что в корне изменилось?

И самое важное: О чём на самом деле говорил Винстон Ройс в докладе 1970 года?

И если посмотреть на эту картину в целом, то выясняется что:

1. В 1970 году время от Идеи до Результата составляло минимум неделю, потому что цепочка такая: Идея - Алгоримизация - Кодирование - Набивка перфокарты или ленты - ОЧЕРЕДЬ в вычислительный центр - Выполнение программы - Результат.

Выполнение полного цикла проверки Идеи - это ДОЛГО! И стоимость ошибки ДОРОГАЯ! Поэтому ключевая мысль Винстона Ройса такая: пишите БОЛЬШЕ документов, чтобы БЫСТРЕЕ делать программное обеспечение.

Как же так, почему дополнительные затраты времени на документацию приводят к ПОВЫШЕНИЮ скорости разработки? Тут всё просто, в момент создания документов обосновывающих решения, выполняются мыслительные эксперименты по доказыванию жизнеспособности Идеи и выбранного решения. Что в свою очередь, приводит к тому что в каждый следующий шаг попадают проверенные данные.

2. За время пути собака смогла подрасти, с 1990 уже распространены микроЭВМ и время от идеи до результата составляет 1-2 часа худшем случае. Это значит, что нам НЕ НУЖНА вся документация чтобы быстрее создавать программное обеспечение.

3. Когда микро-ЭВМ появились у многих, и появилось много разработчиков ПО, и они были фанатами (или фанатиками), то появилась другая проблема: "Ваша задача безусловно важна, но мне как инженеру интересно делать то, что МНЕ интересно делать, и мне интересней совершенствовать свои навыки разработки программного обеспечения". Из-за такого подхода деньги и цели бизнеса, это совсем не тот приоритет у инженера по разработке программного обеспечения (ПО) и с этим тоже нужно что-то делать.

4. Когда разработчики создают ПО, часто информация к ним приходит в искаженном виде. Потому что "пиши больше документов", а эти документы пишут Аналитики, который ПРИДУМЫВАЮТ "что нужно Клиенту", потому что Клиент сам не знает что хочет, и оперирует терминами и решениями которые ИЗВЕСТНЫ ему. Часто Аналитики выступают в роли "переводчиков" исходя из предпосылки, что "Клиент точно знает что хочет" - а это не так. Другими словами Клиент приходит с ГИПОТЕЗОЙ о решении, но все думают, что он лучше всех что-то знает. "Но кто-то крикнул из ветвей: Жираф большой, ему видней!" (с)

В результате, при накоплении такого опыта к 199х годам появилось понимание, что проблема недопонимания между Бизнесом и инженерами системная. Так как Заказчик (Клиент) НИКОГДА не получал то что ему действительно было нужно.

5. В американском мире Контракты жесткие. Это значит что Клиент хочет получить за свои деньги то, что ему представили в ТЗ. Но когда он получает "то что в ТЗ" , но "это не то" (потому что п.4), он расстраивается и начинаются разборки кто, что не то сделал.

6. Об улучшениях процессов разработки программного обеспечения задумываются только в к крупных корпорациях, так как мелкие компании заняты выживанием. А в американской культуре принят "индивидуализм" (В противовес русской и восточной культуре общинности). Это отражается в виде организации пространства персональными загончиками - кубиклами. (Их можно увидеть Что можно увидеть в натальных сценах фильма "Матрица" или в фильме "Офисное пространство"). Такая организация рабочего пространства приводит к низкому уровню коммуникаций между сотрудниками.

Исходя из этой исторической перспективы и предпосылок появляются решения:

  1. Мы не знаем точно Цели Клиента - давай адаптировать постоянно.
  2. Чтобы Адаптировать постоянно - "путешествуй налегке", меньше документов. Но нужны "тесты первыми", чтобы ничего не "падало" при изменениях.
  3. Если Клиент не знает саму Цель - давай посадим его рядом и сделаем рамочный контракт с оплатой команды (тут стоит упомянуть, что почти все авторы подходов работали во внутреннем ИТ больших не-ИТ компаний)
  4. Стоит постоянно напоминать Разработчику, что "важно не его совершенствование, а работающий программное обеспечение".

Ну а следствия этих изменений появляются в виде поддерживающих практик, принципов, ценностей.

Как применять Agile в своей среде

Если в вашей среде верны предпосылки подходов из главы выше, то да вы можете применять в некоторыми поправками:

  1. Если не хотите переплачивать ищите истинную проблему Заказчика и определяйте Цель.
  2. "Путешествие налегке" - это не значит "отсутствие документов", это значит что документы нужны такие, которые помогут развивать и поддерживать ваш Продукт даже в случае, когда вся команда поменяется.
  3. Инвестируйте в качество - без максимально превосходного качества и автоматизации проверок нельзя постоянно адаптироваться под изменения.
  4. Если вы хотите чтобы инженеры делали то, что вы говорите быстро и без детальной проработки, придётся их "усыновить" и взять на себя все расходы связанные с ошибками проектирования.
  5. показывать разработчику как используется его решение хорошая практика. Это их мотивирует.
  6. Постоянная погоня "давай попробуем" стоит денег и больших. Это оправдано только в маркетинговых проектах. Ищите способы не делать того, чего можно не делать но получить результат.

Agile-подходы и BIPULSE

  • BIPULSE - система которая помогает сдавать проекты вовремя. Это значит вы должны определиться с Целью прежде чем запускать проект.
  • BIPULSE поддерживает Ритм Agile-процесса, и множество метрик для непрерывного совершенствования процессов.
  • BIPULSE поддерживает метрики Экстремального программирования (eXtreme Programming), для лучшего планирования новых проектов.