Валерий Николаевич Фунтов
Agile. Процессы, проекты, компании

Полная версия

© ООО Издательство «Питер», 2020

© Серия «IT для бизнеса», 2020

© В. Фунтов, 2018

Предисловие автора к изданию

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

Данная книга подробно рассказывает об особенностях разнообразного использования Agile, дает многочисленные примеры его применения за пределами ИТ-отрасли. Она не для айтишников. Им не надо ее читать. У книги конкретная аудитория – это все те, кто работает за пределами разработки программного обеспечения. Соответственно перестроен и язык, по возможности используется обычная (не айтишная) лексика. Фокус не только на Скраме, но и на всем Agile-мышлении и подходе. Знания сформированы разными практиками (в том числе практикой автора) и многочисленными источниками. Цитируется много фактов и примеров, даны аккуратные ссылки. Все, что описано, можно немедленно применять на практике, также по Agile, мелкими итерациями, анализируя эффекты и проводя корректировки. Надо просто пробовать.

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

В книге 15 рисунков и более 100 примеров. Интернет-ссылки даны прямо в тексте – это поможет тем, кто будет использовать электронную версию, тут же изучить материал, не набирая ссылку вручную. В тексте всей книги термины Agile и Lean даются на английском языке. Scrum и Kanban, если они упоминаются отдельно, русифицированы как Скрам и Канбан. Это вызвано уже сложившейся практикой в России. В комбинации с другими терминами или практиками сохранены англоязычные написания.

В книге четыре приложения, включающие пример Agile-договора, чек-лист для выбора жизненного цикла проекта, пример устава команды и короткий тест с вопросами, похожими на те, которые дают при сертификации ACP.

Успехов вам в постижении Agile, дорогие читатели!

С уважением, В. Н. Фунтов, доктор экономических наук, PMP. Санкт-Петербургский международный институт менеджмента. Санкт-Петербург, 2019

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Введение

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

Джон Симпсон, вице-президент по маркетингу компании Jama Software, 2011

71 % организаций хотя бы иногда применяют гибкие методы управления проектами.

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

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

Чем является Agile – подходом, методологией, практикой, методикой или фреймворком, – не так важно. В конкретной ситуации можно применять любое из этих понятий. Главное, что Agile позволяет обеспечить очень быструю реакцию заказчика или потребителя на характеристики создаваемого продукта или результата, дает возможность компании или проектной команде учесть их замечания и предложения, немедленно внедряя это на последующем шаге и минимизируя потери на изменения. А сочетание Agile-фреймворков и бережливого управления (Lean Management) дает сильнейший синергетический эффект, поскольку бережливость основана на цепочке создания ценности и минимизации потерь времени или ресурсов. Объявляемая в проекте или компании гибкость заключается в достижении ценности для заказчика, правильном построении жизненного цикла проекта, в создаваемом продукте или результате, во взаимодействии с заказчиком или потребителями, в выборе только необходимой документации, применении только тех процессов и только в таком объеме, при которых создается ценность и минимизируются потери, и т. д.

Суть Agile изложена в многочисленных публикациях (в конце книги есть список литературы). В подавляющем большинстве использование Agile связано с ИТ-отраслью. Задействование же в других отраслях является достаточно нетипичным и фрагментарным, хотя и происходит относительно давно. Но, как отмечается, даже при таком частичном его применении компании, использующие Agile в своем бизнесе (примеры приведены дальше в книге), добиваются очень неплохих результатов в виде быстрого обновления или расширения своего ассортимента услуг или продуктов; дисциплинированной и систематизированной работы своих исполнителей, вовлеченных в постоянное совершенствование предложений клиентам; тесной и продуктивной связи с конечными потребителями услуг/продуктов, выражающейся в постоянном тестировании нововведений. В недавнем опросе 4452 членов Scrum Alliance более половины респондентов сообщили, что их организации используют Скрам не в ИТ-направлениях. В список вошли разработки продуктов (11 %), операционный менеджмент (3 %), продажи и маркетинг (2 %) и даже работа руководителей высшего звена (1 %).

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

Для понимания некоторых аббревиатур и терминов приведу небольшой справочник.

Спринт 1
История

Нельзя держать все в голове. Для управления крупным проектом просто необходимы инструменты контроля.

Льюис Фрид

Введение

При прохождении этого спринта вы узнаете об истории Agile и курьезных примерах его применения. В качестве ценного результата сможете использовать знания в споре, на корпоративной вечеринке или на семинаре. Без истории не узнать настоящего.

1.1. Первый Agile

Творческий подход может означать всего лишь то, что больше нет возможности поступать так, как обычно.

Рудольф Флеш

Кто был в начале?

В ИТ-проектах у истоков Agile стояли Даррелл Ригби, Джефф Сазерленд (автономная исследовательская группа Skunk works в LockheedMartin Corporation, см. врезку на с. 19), Хиротака Такеучи и др. Эта первая тройка известна и сейчас.

Д. Ригби – партнер бостонского офиса консалтинговой компании 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-манифест? 11–13 февраля 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 2013–2015 гг., где она неожиданно снизила рейтинг использования Agile в проектах, сведя его применение к «малым проектам».

Рис. 1.1. Кривая разочарований

1.3. Интересное про Agile

Из всех трудностей, с которыми столкнулось NASA, отправляя человека на Луну, управление было, наверное, самой сложной задачей.

Роджер Лаунис, историк NASA

Agile и автомобиль

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

При введении Генри Фордом на сборочных линиях Ford Motors конвейера с четким разделением труда и последовательностью работ с различными ресурсами, специализирующимися на различных задачах сборки, стоимость изготовления автомобиля значительно снизилась и он стал доступен для всех. Фактически отрасль отказалась от Agile и добилась огромных успехов в производительности. Однако успешность такого конвейера требует важных критических условий: 1) минимизации обратного движения, переделок и доработок, высокой стандартизации деталей, подходящих к любому автомобилю, без подгонки и корректировки; 2) немногочисленности переходящих партий (в идеале единичного потока), поскольку переход больших партий увеличивает время выполнения на каждом этапе и приводит к позднему обнаружению проблем качества (Satyashri Mohanty, http://tocpeople.com/). В отсутствие этих условий оптимальным становится Agile. Ниже, в разделе 6.7, мы вернемся к Agile-проекту уникального автомобиля и еще раз проиллюстрируем преимущества Agile на инновационных направлениях.

Провалы Agile

1. Крупнейший проект по разработке ПО с использованием «как бы гибких» подходов и бюджетом 2 млрд фунтов стерлингов в Британской флагманской правительственной программе реформы социального обеспечения Universal Credit провалился с треском. И хотя Agile был объявлен тогда универсальным инструментом, конфликты между премьер-министром и министрами, отсутствие непрерывной связи с заказчиком, который отмалчивался или отписывался, корпоративная культура Департамента по труду и пенсиям, «водопадные» контракты с HP, Accenture, Capgemini и IBM, формирование гигантской Agile-команды из 1500 человек (!) и использование таких же гигантских итераций в два года были в полном противоречии с Agile. В итоге укрепилось мнение, что Agile и государственный бюрократизм совмещаются с трудом. Почему был выбран Agile, так и осталось непонятным, возможно, как дань моде^[1].

2. В США наиболее громкий провал Agile был связан с запуском системы медстрахования Obama Care. Программа включала предоставление определенным категориям американских граждан бесплатных полисов страхования. Для этого надо было заполнить анкету на сайте и дождаться решения определенных служб. Миллионы бросились заполнять анкеты, и это им удавалось сделать, а вот отправить – нет. Возникал какой-то сбой сервера. Система умерла через шесть месяцев после старта. Был привлечен внешний эксперт, который, оценив ситуацию, проделал весь путь с конца, собрал все вместе и добился корректного функционирования системы.

Agile и летное искусство

Майк Кон, ведущий консультант и практик Agile, один из основателей Agile- и Scrum-альянсов, организаций, развивающих, поддерживающих и популяризующих Agile и Скрам в мире, писал: «В 1960-х гг. в США был летчик, военный стратег Джон Бойд. Он придумал теорию OODA (петля Observe – Orient – Decide – Act (“Наблюдение – Ориентация – Решение – Действие”)), по которой воздушный бой выигрывает не самый лучший самолет с технической точки зрения, а пилот, принимающий максимальное количество решений за определенный отрезок времени и моментально реагирующий на изменяющиеся обстоятельства. Бойд заслужил прозвище Сорокасекундный Бойд, так как в воздушном бою мог победить любого пилота менее чем за 40 секунд. В общем, побеждает наиболее быстрый и гибко мыслящий (Agile. – Примеч. авт.). Теория Бойда активно применялась в те времена в военной сфере»^[2].