Agile-менеджмент. Лидерство и управление командами Аппело Юрген

Евангелие от Agile

Вначале инженеры сотворили компьютеры и программное обеспечение. Программное обеспечение же было бесформенно и нефункционально, и тьма царила над пользователями. И инженеры сказали: «Да будет структура». И возникла структура.

И даже в избытке.

За последние пять-шесть десятков лет многие инженеры-компьютерщики озаботились проблемой нестабильности качества при разработке ПО. Она объяснялась тем, что разные команды пользовались разными методами разработки, в основном созданными на коленке. И инженеры окунулись в работу. В результате возник ряд формализованных подходов. Родилась профессия разработчика программного обеспечения. Отправной гипотезой служило представление, что создание ПО – чисто инженерная задача. В результате появилось большое количество моделей, методов, подходов и технических приемов, которые, по идее, должны были помочь программистам повысить качество готовых программ. Но странное дело – при реализации большинства проектов эти методы оказывались неэффективными. Гораздо чаще их результатом становилось возникновение очередной бюрократии. Проекты по разработке ПО занимали столько времени и требовали создания такого количества документации, что «формальные» требования к продукту успевали по нескольку раз измениться за то время, что проект находился в разработке. Тем временем небольшим командам программистов удавалось выпускать на рынок продукты гораздо более высокого качества, на порядки дешевле и существенно быстрее. На их стороне были энтузиазм, дисциплина, гибкость и методы, адаптируемые под каждый проект. Эволюция произвела на свет динозавров, но вся пища доставалась муравьям.

В начале 1990-х была предложена новая методология под названием быстрая разработка приложений (Rapid Application Development, RAD). В рамках этой методологии наиболее успешным командам разработчиков удавалось сочетать некоторые формализованные методы, позаимствованные у «тяжеловесного» инженерного подхода (контроль за внесением изменений в техдокументацию, инспекции и применение контрольных показателей), с такими продиктованными практикой методами, как создание прототипов, выпуск инкрементных версий ПО и тесное сотрудничество с заказчиком [McConnell 1996]. В результате такого скрещивания формализованных и неформализованных методик возникли первые «легкие» методологии, включая эволюционное управление разработкой (Evo) (1988), Scrum (1995), методы разработки динамических систем (DSDM) (1995), методы Crystal (1997), Экстремальное программирование (XP) (1999), разработка, управляемая функциональностью (FDD) (1999), прагматическое программирование (1999) и адаптивная разработка ПО (2000).

Как следствие внезапного и почти одновременного появления множества методик, статей, книг и семинаров по «легким» методологиям (некоторые даже сравнивали его с Кембрийским взрывом), у лидеров движения возникла идея собраться и обсудить положение дел. В 2001 году они встретились на лыжном курорте в штате Юта. Там и был выбран термин «гибкие методологии» (Agile), заменивший применявшуюся ранее терминологию, а также был создан Agile-манифест разработки ПО (рис. 2.2).

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

Впоследствии группа наиболее авторитетных представителей Agile-движения создала Agile Alliance[4] – некоммерческую организацию, которая ставит себе целью продвижение гибких методологий во всем мире. Возникла целая новая экосистема, состоящая из конференций, консультантов, книг и журналов. В результате процессы разработки программного обеспечения стали Agile c большой буквы А, превратившись в нечто более глубокое, чем просто набор практик, которые можно использовать при разработке софта. Признавая, что проекты по разработке программного обеспечения существуют в области, которая располагается между упорядоченностью и хаосом, Agile-подходы, по сути, превратились в образ жизни.

Фундаментальные принципы Agile-методологий

В наши дни численность людей, которые разделяют ценности и принципы Agile-методологий, составляет несколько миллионов человек. Опросы подтверждают, что большинство разработчиков программного обеспечения во всем мире придерживаются по крайней мере некоторых из «основных Agile-практик» [VersionOne 2009].

Фундаментальные принципы Agile-методологий были неоднократно описаны, и у многих авторов это получается гораздо лучше, чем у меня. И все же я чувствую необходимость привести в своей книге их краткий обзор. Будучи практиком гибких методологий, я предпочитаю делать все так, как удобно лично мне; поэтому кратко опишу их основные положения, перечислив «семь измерений», в которых «живут» проекты по разработке ПО, – и еще раз вернусь к этой теме в главе 11 «Развитие компетенций».

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

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

Качество играет определяющую роль в успехе продукта, поэтому в центре внимания Agile-методологий находится техническое совершенство. Высокий технический уровень обеспечивается посредством разработки через тестирование (написание протокола тестирования готового продукта предшествует созданию собственно программного кода), ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист готовности элементов), итеративной разработки (адаптация кода в результате появившихся изменений или других обстоятельств) и рефакторинга (непрерывная оптимизация кода даже при отсутствии изменений в функциональности). Сторонники гибких методологий признают необходимость последовательного улучшения дизайна; под этим понимается, что в начале проекта архитектура продукта не разрабатывается в деталях (а только в самом базовом виде) и выявляется при дальнейшем развитии проекта.

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

У Agile-методологий особые отношения со временем. В Agile-проектах даты поставки, бюджеты и крайние сроки могут устанавливаться почти произвольно. Программное обеспечение создается короткими отрезками, часто в рамках тайм-боксов или «спринтов», и поставляется в виде инкрементных релизов; при этом каждый из релизов сам потенциально является готовым к поставке продуктом. Это позволяет владельцам бизнеса управлять графиком проекта, сдвигая дату сдачи готового продукта вперед или назад в зависимости от того, в какие сроки они хотят сделать доступной ту или иную функциональность. Тем временем команда стремится найти для себя оптимальную скорость разработки, которую она сможет поддерживать практически бесконечно.

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

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

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

Методологии, конкурирующие с Agile

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

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

Менее крупным, но весьма способным игроком будет также движение за мастерство программирования