Чем отличатся методологии?

Почему так много методологий?

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

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

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

Подход	Метод оптимизации	Комментарий
Code&Fix	Максимальная эффективность здесь и сейчас	Процесс определяется менеджментом исходя из краткосрочных целей повышения производительности. Никаких практик здесь не определено по следующим причинам: повысить производительность «сегодня» можно только снижением качества работы.
Waterfall	Максимальная эффективность достижения очень четко поставленной задачи	Определяется четкий план достижения конечной цели. Критерием эффективности является мера отклонения от плана.
RUP	Закрытие рисков практиками и артефактами	RUP описан в виде набора ролей, активностей и артефактов. Процесс строится следующим образом: менеджер выбирает и внедряет подходящие практики. Необходимость практики определяется наличием соответствующего риска. Например, если в проекте путаница с требованиями, имеет смысл ввести роль «requirements engineer» Особенность RUP в том, что огромный упор делается на архитектурные риски.
CMMi, ISO9001 и прочие стандарты качества	Соответствие лучшим практикам индустрии/компании/ Организации	Процесс сверяется с некоторым золотым стандартом. Стандарт существует на уровне целей (goals) и доопределяется на уровне компании соответствующими практиками. Процесс проекта «тейлорится», то есть из процесса, определенного на уровне компании, выбрасываются ненужные на уровне проекта практики либо добавляются новые.
Scrum	Максимальная устойчивость к изменениям	С изменениями Scrum борется, используя следующие принципы: итеративность, инкрементальность, самоорганизация. Практики Scrum обеспечивают максимальную эффективность следования принципам
Extreme Programming	Максимизация качества кода	Принципы KISS (Keep It Simple, Stupid), и YAGNI (you ain’t gonna need it) дополняются практиками OOP, Test Driven Development, Refactoring, Continuous Integration и другими. Итеративность также считается необходимой.
Kanban	Максимизация пропускной способности	Определены три практики Kanban: Limit WIP, визуализация и каденция.
Lean Development	Минимизация lead time (времени с начала разработки) и потерь (waste)	Определены семь принципов: Eliminate Waste, Amplify Learning, Decide As Late As Possible, Deliver As Fast As Possible, Empower The Team, Build Integrity In и See the Whole. Метод использования следующий: существующий процесс компании оптимизируется устранением потерь, простоев и т.д. (waste). Командный принцип работы. На уровне разработки часто используется Scrum и другие разновидности Agile.

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

В таблице приведены вещи далеко не одного порядка. Например, Waterfall – это определение жизненного цикла, а RUP – описание методологии. Вместе в одной табличке они потому, что за ними стоят разные цели оптимизации.

Совместимость подходов

В принципе, из таблички становятся понятно, какие методологии совместимы, а какие нет. Например, Code&Fix не совместим ни с чем, так как фундаментально противоречит на уровне методов оптимизации. Некоторые сочетаются очень и очень хорошо, например Scrum и Extreme Programming.

Опишу вкратце несколько на практике встречающихся связок и соответствующих кейсов

Waterfall и RUP. «Классический» вариант внедрения RUP. Если из RUP выкинуть итеративность, но оставить фазы, получится водопадный процесс. Он будет «обогащаться» морем артефактов и ролей. Такой процесс чрезвычайно эффективен для высасывания денег из заказчика. Если заказчик будет менять требования, выписывайте «Запрос на изменение» и требуйте оплаты вперед :-)!

Scrum & XP. Итог смешения – классический Agile с быстро меняющимися требованиями, короткими итерациями и пристальным вниманием к техническому совершенству. Подходы дополняют друг друга. Практики самоорганизации из Scrum позволяют команде эффективнее добиваться высокого качества, и качество обеспечивает дешевизну изменений.

XP & Code&Fix. XP будет полностью соответствовать подходу Code&Fix, если вы аккуратно выберете оттуда подходы KISS и YAGNI, общения с заказчиком лицом к лицу и «отсутствия документации», но выкинете очень дорогие практики по автоматизации тестирования и парному программированию. На вопросы «где план?» и «где требования?» страшно обижаться и отвечать «у нас же XP!» :-)

Scrum & RUP. Короткие итерации и большой упор на архитектурные риски. Короткие итерации и самоорганизация позволяет справляться с вызовами постоянных изменений. Упор на архитектуру решает трудности технически сложных проектов. Scrum станет намного богаче, если вы будете знать, что такое Feasibility Study и как оно проводится, как разбивать систему на компоненты, как использовать Use Cases и т.д.

RUP & XP. Это означает RUP и практики из XP с упором на техническое совершенство кода, в частности Test Driven Development и Refactoring.

Scrum & Kanban. Сам по себе канбан очень прост и внедрение его без понимания «духа Agile» может превратить разработку в слабоуправляемый хаос, который будет очень далек от оптимального. Например, разделение технологической цепочки может узаконить отсутствие кроссфункциональности: «я программист, это моя колонка на доске». В итоге часть времени программист будет простаивать. Внедрение некоторых принципов и практик Scrum (таких, как самоорганизация и daily scrum) превращает канбан-команду в очень эффективную.

Lean & Scrum. На уровне разработки Scrum сам по себе полностью соответствует принципам Lean. На более высоком уровне оптимизации процесса компании Scrum не применим. Здесь сработает Lean.

Scrum и CMMI. Также часто встречающийся гибрид. Если в организации есть необходимость соответствовать стандарту и при этом эффективно отрабатывать изменения требований, то не так сложно внедрить CMMI на уровне компании и Scrum на уровне проекта. Можно даже найти асессора, который вам выдаст сертификат.