Д. Ригби партнер бостонского офиса консалтинговой компании Bain & Company (www.bain.com), входящей в большую тройку консалтинговых компаний вместе с McKinsey & Company и Boston Consulting Group. Он возглавляет глобальные экспертные группы компании по инновациям и розничной торговле и публикует статьи.
Дж. Сазерленд генеральный директор, основатель, тренер, консультант консалтинговой и образовательной фирмы Scrum Inc. (www.scruminc.com).
Х. Такеучи преподает на кафедре стратегии Гарвардской школы бизнеса.
Сама история
Еще в 1990-х гг. в ответ на преобладающие в то время неповоротливые (по мнению пользователей) методы управления разработками ПО был создан ряд «гибких» подходов: RAD (быстрая разработка приложений, 1991 г.); DSDM (метод разработки динамических систем, 1994 г.); Скрам (1995), Crystal Clear и экстремальное программирование (XP) (1996); FDD (Feature driven development, 1997 г.) и др. Их уже тогда называли гибкими, хотя все они возникли до публикации Agile-манифеста, официально объявившего миру об Agile.
Как родился Agile-манифест? 1113 февраля 2001 г. на лыжном курорте The Lodge at Snowbird в горах Юты 17 «организационных анархистов» и одновременно авторитетнейших разработчиков ПО собрались, чтобы просто пообщаться, покататься на лыжах, поесть, расслабиться и попытаться прийти к общему знаменателю в поисках альтернативы негибким процессам и основанным на документации разработкам ПО.
Почему Snowbird в горах Юты?
Джим Хайсмит президент компании Information Architects, Inc., автор книги Adaptive Software Development: A Collaborative Approach to Managing Complex Systems («Адаптивная разработка ПО: совместный подход к управлению сложными системами»), а также один из отцов-основателей Agile-манифеста, вспоминал, что «очень серьезные баталии проходили при обсуждении места проведения! Были серьезные возражения против Чикаго в зимнее время года: холодно и нечего делать. В Юте тоже холодно, но есть чем заняться, по крайней мере тем, кто катается на лыжах. В Ангилье на Карибских островах жарко и весело, но дорого добираться. В конечном счете Snowbird и катание на лыжах победили».
Почему Agile?
Почему Agile, а не, например, Light? Потому что Алистер Коберн, также один из участников, счел неподходящим термин light («легкий»): «Я не возражаю, что методологии могут называться легкими или тяжелыми, но я не уверен, что хочу, чтобы на меня ссылались как на легковесного участника конференции легковесных методологов. Это как-то ассоциируется с горсткой худых, дистрофичных, легковесных людей, пытающихся вспомнить, какое сегодня число».
Гибкость за пределами ИТ
Термин Agile manufacturing появился также в начале 1990-х, когда представители промышленности, правительства и научных кругов США собрались вместе (и конечно, не на горнолыжном мероприятии), чтобы выяснить, как сделать Штаты конкурентоспособными в производстве. Озвученные идеи первоначально были описаны как «гибкое производство», а позже как «гибкость предприятия». В 1991 г. группа в составе 15 руководителей из 13 компаний разработала стратегию 21st Century Manufacturing Enterprise Strategy и создала Agile Manufacturing Enterprise Forum. В 2001 г., в год создания Agile-манифеста, Рик Доув, один из участников форума, публикует Response Ability: The Language, Structure, and Culture of the Agile Enterprise, где описывается, как подготовить организации к реагированию на меняющуюся среду.
Skunk works
Авиастроительная компания LockheedMartin Corporation создала около завода пластмассы исследовательскую лабораторию с очень сильным запахом. Сотрудники лаборатории сами назвали себя Skunk works, дословно «скунсодельня», «вонючая фабрика», и впоследствии это имя было формально закреплено за лабораторией. Skunk works одна из первых автономных исследовательских групп, созданная внутри компании для сложной творческой задачи проекта радикальных инноваций в области конструкции самолетов. Группа работала практически без контроля сверху, со своим бюджетом, в состоянии секретности по отношению ко всей организации, и стала одной из первых гибких команд.
1.2. Agile: ценности и принципы
Обыденная, повторяющаяся, знакомая с давних пор текущая производственная деятельность стремится вытеснить новую, эпизодическую стратегическую деятельность.
Закон планирования ГрешемаAgile-манифест
К моменту своего рождения Agile-манифест закрепил уже накопившуюся массу знаний и подходов к управлению разработками в виде четырех ценностей.
1. Люди и взаимодействие гораздо важнее процессов и инструментов.
2. Работающее ПО важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, все-таки больше ценится то, что слева. Такое замечание сопровождает все варианты Agile-манифестов в других разделах.
В своих дополнительно разработанных 12 принципах Agile-манифест провозгласил следующее.
1. Наивысший приоритет удовлетворение потребностей заказчика с помощью регулярной и ранней поставки ценного ПО.
2. Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающее ПО следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри нее.
7. Работающее ПО основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота как искусство минимизации лишней работы крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Примечания автора
1. Перевод Agile-манифеста на русский язык разный, поэтому не удивляйтесь некоторым различиям с теми версиями, к которым, возможно, вы уже привыкли. Как источник было выбрано официальное издание Agile Practice Guide от PMI®, опубликованное на русском языке в начале 2018 г.
2. В тексте Agile-манифеста упоминается ПО. Как уже говорилось выше, данная книга посвящена Agile за пределами ИТ-отрасли. Поэтому в дальнейшем будем использовать более широкий термин «продукт». Просто мысленно замените «ПО» на «продукт» и звучание манифеста будет не только айтишным.
Agile и Lean
C 2001 г. все фреймворки, практики и разработки, разделяющие вышеприведенные ценности и принципы, стали называться гибкими. Спустя год даже появилась рабочая группа, объединенная затем в Agile-альянс. Позже, после ряда разногласий и обсуждений о связи Agile и Lean-подходов, Agile-апологеты приняли Lean, Канбан и их комбинации, что, несомненно, дало сильнейший синергетический эффект. Появились такие термины, как Scrumban, Lean Scrum и др. Сейчас устоялась позиция, которая помещает зонтик, или семейство, Agile в область Lean Management.
Апгрейд Agile-манифеста
В 2011 г. были опубликованы видоизмененные и усиленные ценности Agile (свободный перевод автора книги):
команда и ответственность важнее индивидуумов и их взаимодействия;
передаваемая бизнес-ценность важнее работающего продукта;
развитие партнерства (с заказчиком) важнее сотрудничества с заказчиком;
готовность к изменениям важнее реакции на изменения.
Что сейчас?
Д. Ригби, Дж. Сазерленд и Х. Такеучи написали в Harvard Business Review: «С помощью Agile удалось достичь радикальных улучшений в решении задач в ИТ-отрасли. Возможности, которые несет внедрение Agile в других корпоративных подразделениях (и направлениях), огромны». И в то же время график ажиотажа относительно Agile (рис. 1.1) показал, что мир уже находится в точке после «пика завышенных ожиданий» и продвигается ближе к «впадине разочарования».
Возможным подтверждением этого являются оценки компании Standish Group в отчетах CHAOS Manifesto 20132015 гг., где она неожиданно снизила рейтинг использования Agile в проектах, сведя его применение к «малым проектам».
Рис. 1.1. Кривая разочарований