В журнале «Метод» (№ 1 за 2019 год) опубликован гид по agile — гибким подходам в управлении. Знание гибких методик стало обязательным для проектных менеджеров в развитых экономиках, в том числе и тех, кто работает в госсекторе. Например, администрация США использует agile в 80% ИТ-проектов. В России об agile в госуправлении заговорили в 2016 году, и для многих эта тема пока непонятна. Прочитав этот исчерпывающий гайд, вы разберетесь в терминологии, плюсах и минусах agile, а также в наиболее популярных методиках: scrum и канбан.
В 2001 году ИТ-отрасль США переживала кризис. Не так давно лопнул «пузырь доткомов». Интернет-компании обещали держателям своих акций безбедную старость, но в результате их активы обесценились на 50% и больше. Одна из причин кризиса — неэффективное управление проектами. Начинания проваливались, инвестиции вернуть не получалось. Самый перспективный сегмент экономики оказался в тупике.
Тем не менее были те, кто рос на общем фоне, и они решили научить остальных своим методикам. В феврале 2001 года 17 успешных ИТ-менеджеров собрались на горнолыжном курорте, чтобы написать руководство по управлению в отрасли. Однако руководства не вышло. Вместо этого они написали аgile-манифест — набор принципов и ценностей. По замыслу ИТ-менеджеров, следуя этим ценностям, можно повысить эффективность управления.
Рисунок 1. Сравнение эффективности каскадного подхода (водопад) и agile в ИТ-проектахЗа последние 18 лет подходы к управлению, выстроенные на основе agile-манифеста, доказали свою эффективность. По данным PricewaterhouseCoopers (исследование опубликовано в июле 2017 года), agile-проекты в среднем заканчиваются успешно в 42% случаев. Для проектов, где используют традиционный подход, эта цифра составляет всего 14% (подробнее об эффективности agile — на рисунке 1). Рост эффективности — та причина, почему гибкие подходы распространились из ИТ сначала в различные отрасли бизнеса (промышленность, торговля, банки), а потом и в государственный сектор.
«Негибкий» предшественник agile
Чтобы понять agile, мы сравним его с другим популярным подходом — каскадным. Он также известен как классический или водопадный (в англоязычной литературе — waterfall). Последовательный подход долгое время доминировал в управлении проектами. Именно его недостатки заметили 17 ИТ-менеджеров в начале 2000‑х. Именно его недостатки должен был компенсировать agile.
Каскадный подход предполагает, что проект последовательно проходит через несколько этапов: формирование технического задания — дизайн — реализация — тестирование — обслуживание. Модель предусматривает переход на следующий этап только после завершения предыдущего. Заказчик и исполнитель контактируют только при приемке этапов.
Главный недостаток водопадной модели — она не позволяет оперативно реагировать на изменения. Потребности заказчика могут поменяться: приоритеты могут быть пересмотрены, финансовая ситуация может стать другой. Может измениться среда. Например, приняты существенные правки в законодательство. Это требует внесения критических изменений во всю идеологию проекта, но водопадная модель этого не позволяет.
Хотя каскадная модель внешне очень логична, она создает значительные риски при исполнении. Давайте посмотрим, что предлагает agile.
Философия гибкости: четыре принципа
Agile, или гибкие подходы в управлении, — это не конкретная методика и не набор методик. Это комплекс ценностей и принципов. Перейти на agile — значит создать систему управления проектами, которая им следует.
Философия agile построена на четырех ценностях, изложенных в agile-манифесте. Давайте разберем их подробно. Мы выделили жирным сам текст манифеста и поставили рядом свои комментарии.
Рисунок 2. Сравнение каскадного подхода (водопад) и гибких подходов (agile)Люди и взаимодействие важнее процессов и инструментов. Это значит, что, хотя процессы и инструменты важны, они не самоцель. Важно выполнить задачу, а не соблюсти процедуры.
Работающий продукт важнее исчерпывающей документации. Это значит, что все промежуточные работы не несут ценности для заказчика. Ему не нужна техническая документация или дизайн, ему нужен результат.
Сотрудничество с заказчиком важнее согласования условий контракта. Это значит, что результат важнее бумаг. Часто исполнитель «закрывается» от заказчика первоначальными условиями. Это неприемлемо: напротив, условия должны меняться под ситуацию.
Готовность к изменениям важнее следования первоначальному плану. Каким бы хорошим ни было планирование, многое пойдет не так, поскольку мы живем в меняющихся условиях. Система управления должна быстро реагировать. То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева, говорится в манифесте.
Четыре ценности раскрывают 12 принципов. Например, один из них провозглашает «тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта», другой — «простота — искусство не делать лишней работы». Чтобы понять основы agile, нам будет достаточно только ценностей, но мы все равно рекомендуем ознакомиться с полным списком принципов на сайте манифеста по ссылке agilemanifesto.org/iso/ru/manifesto.html.
Если каскадная модель — это следование условиям контракта и документации, то agile — это быстрый пересмотр планов в зависимости от изменений (рисунок 2). Результат для заказчика поставлен выше первоначальных договоренностей. Даже если постановщик задачи решает пересмотреть генеральную линию проекта, agile-система должна это выполнить. Это делает гибкие подходы в управлении гораздо более эффективными в некоторых ситуациях. Давайте рассмотрим в каких.
Когда нужен agile: разбираем матрицу Стейси
Главный критерий выбора agile — неопределенность. Предположим, вы точно можете описать задачу. Вы точно знаете, как ее реализовать. И вы можете зафиксировать это в документах так, что, следуя инструкциям, исполнитель получит правильный результат. Тогда agile не нужен. Напротив, он создает лишние трудности.
Схема принятия решений представлена на рисунке 3 — это так называемая матрица Стейси. Она имеет две оси, соответствующие степеням определенности в отношении технологий и в отношении результата. Если эта степень очень высокая, подходят любые методы, в том числе и водопадная модель. В остальных случаях лучше использовать agile.
Рисунок 3. Матрица неопределенности СтейсиВыделенные на рисунке области соответствуют доменам по теории запутанности, известной как Cynefin Framework. Эта теория делит все системы на четыре домена по степени неопределенности: простые, сложные, запутанные и хаотичные. Простые задачи — это те, которые любой может решить по инструкции. Сложные системы также можно описать, но в них слишком много переменных. Поэтому для решения таких задач нужны профессионалы.
Запутанные системы предполагают большое количество факторов, но причинно-следственные связи непонятны. Поэтому мы не можем сразу определить лучший способ решения таких задач. Нам необходимы гипотезы и эксперименты. Хаотичные системы — это запутанные в кубе. Число факторов еще больше, причинно-следственные связи в основном неизвестны.
Agile нужен для запутанных и хаотичных систем. В простых и сложных лучше работает водопад. Для построения работы в философии agile существуют специально разработанные методики.
Scrum: управление в стиле регби
Методик, соответствующих ценностям и принципам гибкости, достаточно много. Наиболее известные из них — scrum и канбан. Есть и другие — экстремальное программирование, OpenUp, DSDM. Однако они уступают по популярности и не смогли выйти за пределы ИТ-сферы. Теоретически компания или госорганизация может разработать свои методики, соответствующие ценностям и принципам agile.
Scrum охватывает больше половины (по некоторым данным, до 80%) agile-проектов. Термин пришел из регби: им обозначают схватку вокруг мяча, когда члены команды стоят плотно друг к другу, держась за плечи друг друга.
В scrum реализация проекта разбита на короткие промежутки, называемые спринтами. Рекомендуемая продолжительность спринта — от двух до четырех недель. Более короткий спринт не позволяет реализовать задачу, более длинный превращает scrum в подобие мини-водопада. Каждый отрезок имеет свое планирование, задачи и результат. У каждого спринта есть обязательная ретроспектива — мероприятие, в ходе которого команда анализирует эффективность работы и обсуждает ее повышение.
Результатом каждого спринта должна стать поставка инкремента — готовой к использованию части продукта. Инкремент должен нести ценность для потребителя. Например, госоргану нужна информационная система в сфере ЖКХ. После первого инкремента это может быть простейший сайт, который только сообщает информацию. На следующем этапе появляются опросы населения, на третьем — возможность обратной связи и так далее. Продукт появляется постепенно, и каждое следующее его улучшение полезно.
Scrum — это отличный пример того, чем agile отличается от водопадного подхода. При каскадной модели только в конце понятно, как работает проект. Scrum предполагает поставку части продукта каждые две-три недели. Схема позволяет внести корректировки в изначальное задание в процессе или даже отказаться от последующих этапов. Это и есть гибкость в управлении.
Постигаем канбан
Scrum — это не единственная методика в духе agile. Альтернативой является канбан, которую, кстати, часто комбинируют со scrum, получая так называемый скрамбан. Канбан берет свои истоки в производственных подходах, принятых в Японии и сделавших эту страну одним из ведущих производителей в мире. Цель канбана — повысить производительность системы в целом.
В основе канбана — визуализация процессов (рисунок 4). Как правило, для этого используют обычную доску либо соответствующее программное обеспечение. Доску делят по вертикали как минимум на три части: что нужно сделать — в работе — сделано. По горизонтали она может делиться по типам процессов, исполнителям, участникам и другим критериям. Иногда горизонтальное деление просто отсутствует.
Рисунок 4. Простейшая визуализация канбан-доски Задачи выписывают на карточки и делят между тремя вертикальными сегментами. Таким образом, мы видим, сколько задач у нас в работе, сколько ждут своей очереди, а сколько — уже выполнены. Визуализация делает процесс прозрачным.
Следующий этап — ограничение входящих задач. Смысл канбана в том, чтобы выполнять работу «пачками», по 2–3 задачи на каждом участке. То есть команда или сотрудник берет в работу несколько заданий, доводит их до конца и только после этого преступает к следующим. Вместо десятков заданий, выполненных на 5%, мы получаем несколько, но готовых на все 100.
Визуализация и последовательное выполнение задач открывает нам участки с низкой производительностью. Мы видим, где задачи пролетают, а где они двигаются медленно. Когда мы нашли участки низкой эффективности, мы можем их реформировать или усиливать. Это влияет на производительность системы в целом.
Таким образом, канбан позволяет сотрудникам сфокусироваться на решении задач, а менеджерам — увидеть слабые участки системы и сделать работу более прозрачной. Однако чем сложнее процесс, тем больше требуется математической работы и тем сложнее будет визуализация.
Как узнать больше
Цель статьи — рассказать об основах agile. Мы не разобрали многих важных вещей: программное обеспечение по управлению проектами (например, Jira или Trello), артефакты scrum, пороки команд по Ленсиони, планирование спринта, структуру и численность scrum-команд. Чтобы внедрить гибкое управление в своей организации, вам потребуются дополнительные материалы.
Обратите внимание на методические рекомендации по применению гибких подходов в организациях государственной власти, не требующих привлечения подрядных организаций. Рекомендации доступны на сайте gosagile.ru.
От редакции мы можем посоветовать три книги. Первая — это труд создателя методики scrum Джефа Сазерленда. Ее российский перевод «Scrum: революционный метод управления проектами» доступен на сайтах издательств и в Сети. Вторая — «Постигая agile. Ценности, принципы, методологии» за авторством Эндрю Стеллмана и Дженнифер Грин. Третья — это «Канбан. Альтернативный путь в agile» создателя технологии Дэвида Андерсона.
Ну и, конечно, следите за статьями журнала «Метод» — мы продолжим освещать и теорию, и практику agile в проектном управлении в следующих номерах.
К. В. ОВЧАРУК
