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

Введение

При прохождении этого спринта вы узнаете об истории 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, отправляя человека на Луну, управление было, наверное, самой сложной задачей.

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: процессы, кейсы, проекты

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

Agile и процессы

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

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

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

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

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

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

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

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

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

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