Agile. Процессы, проекты, компании

Валерий Николаевич Фунтов, 2019

Новая книга известного тренера-преподавателя и директора многочисленных учебных программ по проектному управлению В. Н. Фунтова посвящена применению гибких методов в современных компаниях, а особенно применению 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].

1.4. Agile: процессы, кейсы, проекты

Операционный менеджмент — это освещение тоннеля, стратегический менеджмент обеспечивает наличие света в конце тоннеля, а проектный менеджмент — это двигатель поезда, который и движет организацию вперед.

Джой Гамз, директор Project Auditors LLC

Agile и процессы

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

♦ максимальный визуальный контроль, цвет, карточки, доски, общий вид и доступность информации для всех участников;

♦ работу исполнителей в процессах вместе и рядом, в одном помещении или использование, например, «аквариумных» видеоокон при удаленной работе;

♦ работу внутреннего владельца процесса, его участников, внутреннего заказчика процесса сообща, снижение потерь информации;

♦ внимание к постоянно формируемой ценности создаваемых результатов для внутреннего заказчика, коммуникации с помощью встреч, моментальные и эффективные решения, постоянное общение;

♦ лидерство и поддержку (далее введем термин «обслуживающее лидерство») владельца процесса, который задает направление и определяет правила сотрудничества и работы;

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

Business agility, или бизнес-гибкость

Если говорить о компании в целом и управлении ею, то Agile дает ей способность понимать и реализовывать изменения внутри или снаружи и соответствующим образом реагировать, чтобы обеспечить ценность для своих внутренних потребителей и внешних клиентов. Agile — это:

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

♦ уход от последовательного цикла планирования, реализация итераций для обучения и обратной связи и адаптация как продукта, так и процессов.

Бизнес-гибкость

Исследования показали, что в руководстве компаний, с которым проводили беседы, большинство были хорошо осведомлены о том, как быть гибкими в процессах бизнес-аналитики, архитектуры процессов и эластичности инфраструктуры, но не смогли сами быть таковыми в выполнении этих процессов.

С подачи гендиректора и сооснователя компании Systematic Майкла Хольма была реорганизована работа руководства, юридического и финансового отделов, отделов продаж и персонала в виде следующих шагов:

✓ пересмотрена деятельность заместителей генерального директора, от многих из них отказались;

✓ вице-президенты покинули свои кабинеты и стали работать со своим персоналом как Agile-команды;

✓ кабинеты стали комнатами осведомленности (situational awareness room — SIT) о ситуации с продажами и прогрессом разработок, были вывешены белые доски с актуальной информацией и инфопанели;

✓ почти вдвое сократили количество периодических отчетов, остальные данные вносили в цифровом виде;

✓ стала применяться приоритизация важнейших для бизнеса вопросов: коммерческие предложения и удовлетворенность клиентов;

✓ использовались ежедневные 20-минутные утренние летучки — что было сделано вчера, чем заняться сегодня, какая и кому нужна помощь;

✓ проводились еженедельные (и даже ежемесячные) встречи вице-президентов с подчиненными;

✓ был организован онлайн — и видеодоступ ко всем сотрудникам.

Бизнес-гибкость проявляется в следующих направлениях:

♦ рынок: это оперативность или отклик рынка и оптимальные каналы, работа с большими данными, дизайн-мышление (сервис-дизайн);

♦ организационные моменты: распространение корпоративных знаний, цифровая культура и психология и управление изменениями;

♦ процессы: постоянная бизнес-аналитика, эластичность решений, организации и процессов, инновации в ПО и поиск/цепочка поставок.

Agile и управление кейсами

Кейс — это управление «решением конкретной задачи» для VIP-клиента или в особых условиях, например в работе врачей, юристов, консалтинге, исследованиях, проектировании или в общественных инициативах. Кейс включает описание конкретной исходной ситуации и способ ее разрешения, пути, выбранные участниками, их действия, материалы, относящиеся к делу, и полученный результат. К характеристикам кейса относится следующее^[3]:

♦ объектом управления является проблема (задача), а не собственно процесс;

♦ кейс объединяет участников, бизнес-процессы, контент;

♦ в ходе исполнения происходят (или вероятны) изменения процессов, подзадач, участников;

♦ высокий уровень неопределенности задач, недостаточно информации на старте;

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

Процесс работы с кейсом может включать шесть этапов.

1. Ассесмент (выяснение ситуации клиента кейса и ее оценка).

2. Планинг (планирование необходимых шагов).

3. Вмешательство (принятие мер).

4. Мониторинг (контроль, наблюдение за исполнением мер).

5. Оценка (оценка результатов, планирование помощи даже в случае неблагоприятного развития).

6. Реассесмент с повторением этапов 1–5.

Когда управление кейсом учится на прошлых ситуациях и формирует «лучшие практики», вводится термин «адаптивный кейс-менеджмент» (Adaptive Case Management, ACM, предложен в 2010 г. компанией Workflow Management Coalition). Такая технология позволяет гибко управлять решением задачи в зависимости от развития ситуации. Оформляют кейс, только если это имеет ценность в дальнейшем.

Agile и проекты

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

Примечания

1

http://www.milresource.ru/Boyd.html

2

Кон также написал очень хорошие книги, такие как «Agile: Оценка и планирование проектов», «Scrum. Гибкая разработка ПО», «Пользовательские истории. Гибкая разработка ПО» (см. список литературы).

3

https://habrahabr.ru/post/185858/