История и предпосылки появления Agile-подходов
Применяя любые управленческие подходы необходимо их применять осмысленно, а не просто потому что "это модно" и "это популярно", "это у ХХХ получилось". И если "Свод знаний по управлению проектом" это сборник лучших практик, где почти в каждой главе указано "выбрите нужные для вас", то такого нельзя сказать про адаптивные подходы (Agile-подходы). Поэтом давайте разбираться с Agile-подходами к разработке программного обеспечения, почему появились и в чём ключевые отличия.
Чтобы понять почему адаптивные подходы получили популярность нужно понять историческую перспективу. Какая была ситуация на 1995-1996 год (даты выпуска XP, Scrum)? Что в корне изменилось?
И самое важное: О чём на самом деле говорил Винстон Ройс в докладе 1970 года?
И если посмотреть на эту картину в целом, то выясняется что:
1. В 1970 году время от Идеи до Результата составляло минимум неделю, потому что цепочка такая: Идея - Алгоримизация - Кодирование - Набивка перфокарты или ленты - ОЧЕРЕДЬ в вычислительный центр - Выполнение программы - Результат.
Выполнение полного цикла проверки Идеи - это ДОЛГО! И стоимость ошибки ДОРОГАЯ! Поэтому ключевая мысль Винстона Ройса такая: пишите БОЛЬШЕ документов, чтобы БЫСТРЕЕ делать программное обеспечение.
Как же так, почему дополнительные затраты времени на документацию приводят к ПОВЫШЕНИЮ скорости разработки? Тут всё просто, в момент создания документов обосновывающих решения, выполняются мыслительные эксперименты по доказыванию жизнеспособности Идеи и выбранного решения. Что в свою очередь, приводит к тому что в каждый следующий шаг попадают проверенные данные.
2. За время пути собака смогла подрасти, с 1990 уже распространены микроЭВМ и время от идеи до результата составляет 1-2 часа худшем случае. Это значит, что нам НЕ НУЖНА вся документация чтобы быстрее создавать программное обеспечение.
3. Когда микро-ЭВМ появились у многих, и появилось много разработчиков ПО, и они были фанатами (или фанатиками), то появилась другая проблема: "Ваша задача безусловно важна, но мне как инженеру интересно делать то, что МНЕ интересно делать, и мне интересней совершенствовать свои навыки разработки программного обеспечения". Из-за такого подхода деньги и цели бизнеса, это совсем не тот приоритет у инженера по разработке программного обеспечения (ПО) и с этим тоже нужно что-то делать.
4. Когда разработчики создают ПО, часто информация к ним приходит в искаженном виде. Потому что "пиши больше документов", а эти документы пишут Аналитики, который ПРИДУМЫВАЮТ "что нужно Клиенту", потому что Клиент сам не знает что хочет
, и оперирует терминами и решениями которые ИЗВЕСТНЫ ему. Часто Аналитики выступают в роли "переводчиков" исходя из предпосылки, что "Клиент точно знает что хочет" - а это не так. Другими словами Клиент приходит с ГИПОТЕЗОЙ о решении, но все думают, что он лучше всех что-то знает. "Но кто-то крикнул из ветвей: Жираф большой, ему видней!" (с)
В результате, при накоплении такого опыта к 199х годам появилось понимание, что проблема недопонимания между Бизнесом и инженерами системная. Так как Заказчик (Клиент) НИКОГДА не получал то что ему действительно было нужно.
5. В американском мире Контракты жесткие. Это значит что Клиент хочет получить за свои деньги то, что ему представили в ТЗ. Но когда он получает "то что в ТЗ" , но "это не то" (потому что п.4), он расстраивается и начинаются разборки кто, что не то сделал.
6. Об улучшениях процессов разработки программного обеспечения задумываются только в к крупных корпорациях, так как мелкие компании заняты выживанием. А в американской культуре принят "индивидуализм" (В противовес русской и восточной культуре общинности). Это отражается в виде организации пространства персональными загончиками - кубиклами. (Их можно увидеть Что можно увидеть в натальных сценах фильма "Матрица" или в фильме "Офисное пространство"). Такая организация рабочего пространства приводит к низкому уровню коммуникаций между сотрудниками.
Исходя из этой исторической перспективы и предпосылок появляются решения:
- Мы не знаем точно Цели Клиента - давай адаптировать постоянно.
- Чтобы Адаптировать постоянно - "путешествуй налегке", меньше документов. Но нужны "тесты первыми", чтобы ничего не "падало" при изменениях.
- Если Клиент не знает саму Цель - давай посадим его рядом и сделаем рамочный контракт с оплатой команды (тут стоит упомянуть, что почти все авторы подходов работали во внутреннем ИТ больших не-ИТ компаний)
- Стоит постоянно напоминать Разработчику, что "важно не его совершенствование, а работающий программное обеспечение".
Ну а следствия этих изменений появляются в виде поддерживающих практик, принципов, ценностей.
Как применять Agile в своей среде
Если в вашей среде верны предпосылки подходов из главы выше, то да вы можете применять в некоторыми поправками:
- Если не хотите переплачивать ищите истинную проблему Заказчика и определяйте Цель.
- "Путешествие налегке" - это не значит "отсутствие документов", это значит что документы нужны такие, которые помогут развивать и поддерживать ваш Продукт даже в случае, когда вся команда поменяется.
- Инвестируйте в качество - без максимально превосходного качества и автоматизации проверок нельзя постоянно адаптироваться под изменения.
- Если вы хотите чтобы инженеры делали то, что вы говорите быстро и без детальной проработки, придётся их "усыновить" и взять на себя все расходы связанные с ошибками проектирования.
- показывать разработчику как используется его решение хорошая практика. Это их мотивирует.
- Постоянная погоня "давай попробуем" стоит денег и больших. Это оправдано только в маркетинговых проектах. Ищите способы не делать того, чего можно не делать но получить результат.
Agile-подходы и BIPULSE
- BIPULSE - система которая помогает сдавать проекты вовремя. Это значит вы должны определиться с Целью прежде чем запускать проект.
- BIPULSE поддерживает Ритм Agile-процесса, и множество метрик для непрерывного совершенствования процессов.
- BIPULSE поддерживает метрики Экстремального программирования (eXtreme Programming), для лучшего планирования новых проектов.