Процесс

Несмотря на то, что доминирующая парадигма Agile-методологий – люди, а не процессы, это совсем не означает, что последние не важны. Наиболее важными процессами в этом контексте будут минимальное планирование (или планирование методом набегающей волны), ежедневное личное общение (часто это происходит в формате ежедневных стендапов) и мониторинг хода проекта через оценку работающего продукта (по функциональным возможностям, принятым клиентом). Приверженцы гибких методологий также признают необходимость непрерывного улучшения, в ходе которого процессы разработки подвергаются регулярной переоценке и перенастройке посредством анализа и ретроспектив (ретроспективных совещаний).

Конфликт

Все вышеизложенное отражает мое понимание сущности Agile-методологий. Естественно, это не более чем моя точка зрения. Некоторые разработчики, практикующие гибкие методологии, могут не согласиться с приведенным мной кратким описанием. Но это вытекает из самого характера Agile-методологий. Я даже мог бы включить понятие «конфликт» в качестве восьмого измерения, присущего этим методологиям. Как вы увидите позже, наличие внутреннего конфликта – естественное свойство сложных систем и необходимое условие для креативности и инноваций. Великая честь оказаться среди людей, которым ничто не доставляет такого удовольствия, как возможность совершенствовать друг друга.

Редко когда попадаются игры, не предусматривающие конкуренцию между игроками, и лишь немногие системы обходятся без конфликта. Без расхождения во взглядах между разными людьми жить было бы не так интересно. К счастью, в мире гибких технологий предостаточно здоровой конкуренции, например между Scrum и Экстремальным программированием, Scrum и канбаном и даже между Scrum и Scrum![5] Но гибкие методы разработки не будут здесь единственными игроками. Существует несколько сильных и многообещающих конкурирующих подходов, в основе которых лежат идеи, аналогичные идеям Agile-методологий, дополняющие их, а часто и входящие с ними в прямое противоречие.

Одними из самых крупных конкурентов будут методологии бережливой разработки программного обеспечения (Lean software development), переносящие идеи бережливого производства в область разработки ПО. Семь принципов бережливого производства [Poppendieck 2009: 193] основываются на четырнадцати принципах Дао Toyota (философии управления компании Toyota) и четырнадцати принципах менеджмента Э. Деминга. Между Agile– и Lean-методологиями много общего, поэтому часто они играют на одной стороне, ими занимаются одни и те же эксперты, у них одни и те же фанаты, а их развитие освещается в одних и тех же блогах, журналах и ТВ-шоу. С управленческой точки зрения Lean-методологии – с их акцентом на сокращении непродуктивных затрат и оптимизации систем в целом – внесли большой вклад в развитие гибких методологий. Хотя бережливые методологии разработки ПО возникли на несколько лет позднее Agile, они сравнялись с ними по числу консультантов, коучей, профессиональных консорциумов[6] и проводимых конференций.

Менее крупным, но весьма способным игроком будет также движение за мастерство программирования, основополагающим документом которого стал манифест в защиту мастерства программирования (рис. 2.3), о котором говорят, что он одновременно расширяет Agile-манифест и бросает ему вызов. Сторонники этого движения считают, что разработчики ПО вовсе не инженеры, а мастера. (Некоторые полагают вполне уместным сравнение с распространенной в Средневековье моделью мастеров и подмастерьев.) В общем, это движение – шустрый и бесстрашный новый игрок, возникший рядом с бережливыми и гибкими методологиями и имеющий свои собственные конференции, книги и форумы (хотя и не в таком количестве). Эти три «легкие» методологии вместе стали отличной командой, несмотря на периодически возникающие между ними бурные споры.

Но и тяжеловесы все это время тоже не стояли на месте. Возможно, наиболее известным (и наиболее спорным) из них будет методология CMMI (Capability Maturity Model Integration). Ее разработка с 1987 года ведется Институтом программной инженерии, исследовательским центром на базе Университета Карнеги – Меллон. Проект начался с создания протокола оптимизации процессов разработки ПО, но постепенно трансформировался в более абстрактную модель, которая в настоящее время применяется для оптимизации процессов и в других отраслях. В модели описываются пять уровней зрелости процессов в двадцати двух процессных областях, и она ставит себе целью порождение рекомендаций по их оптимизации. Но данная модель лишь указывает, в каких именно процессных областях возможна оптимизация. Она не дает рекомендаций относительно конкретных ее способов. По этой причине некоторые сторонники Agile полагают, что, несмотря на свой объем (документация, описывающая методологию CMMI, насчитывает многие сотни страниц), она все же совместима с гибкими методологиями, поскольку последние дополняют ее, давая рекомендации, в том числе и по конкретным способам оптимизации процессов. Но, как это всегда бывает среди сторонников гибких технологий, и тут не обходится без споров. Многие считают, что, несмотря на благие намерения, положенные в ее основу, CMMI в силу своей тяжеловесности уводит компании в сторону бюрократии и создания не вполне дееспособных команд, которые весьма впечатляюще выглядят со стороны, но не могут блеснуть реальными результатами.

С такой же смешанной реакцией столкнулась и методология, изложенная в «Руководстве к своду знаний об управлении проектами» (Guide to Project Management Body of Knowledge, PMBOK), издаваемом и поддерживаемом Институтом управления проектами. Интересно, что это руководство первоначально возникло как описание лучших практик в области проектного менеджмента в целом. С момента первого издания в 1987 году оно подверглось нескольким переработкам и стало ближе к идеологии Agile в качестве реакции на успехи, достигнутые проектными менеджерами, практикующими гибкие методологии. В отличие от CMMI, методология, продвигаемая в рамках PMBOK, предлагает проектным менеджерам конкретные рекомендации относительно управления проектами. И хотя рекомендуемые ею практики не всегда хорошо сочетаются с принятыми в гибких методологиях, многие проектные менеджеры предпринимают активные попытки преодолеть имеющиеся расхождения. То же самое можно сказать о PRINCE2 – похожей методологии, издаваемой и поддерживаемой британским министерством государственной торговли. Эта методология используется главным образом в Европе.

Последним важным направлением в этом списке будет унифицированный процесс разработки ПО, наиболее известный в версии унифицированный процесс Rational (Rational Unified Process, RUP). Он был разработан в 1997 году компанией Rational Software (сейчас принадлежит IBM). Для разработчиков ПО процесс RUP будет тем же, чем для проектных менеджеров стали методологии, изложенные в руководстве PMBOK. В нем содержится описание стандартизированных методов проектного управления, которые могут (и должны) адаптироваться к конкретным проектам; однако документация составлена таким образом, что весь подход зачастую воспринимается как бюрократический. Сторонники гибких методологий считают, что процесс разработки формируется в ходе проекта, начинаясь с минимального числа практик. В рамках RUP продвигается противоположный подход, в котором изначально предписывается большое количество практик с сопровождающей их рекомендацией, что в ходе проекта от ненужных практик можно отказаться. (Я часто сравниваю этот подход с покупкой Boeing 747, который владелец затем разбирает на части, чтобы собрать велосипед для поездок за покупками.) Неудивительно, что на фоне многочисленных успехов Agile-методологий этот подход подвергся нескольким ревизиям с целью сделать его более гибким, в результате чего возникли такие его модификации, как гибкий унифицированный процесс (Agile Unified Process, AUP), открытый унифицированный процесс (OpenUP) и минимально необходимый гибкий процесс (Essential Agile Process, EssUp). Но ни один из них не нашел широкого применения, сравнимого с распространением Agile-методологий.