Применение методологии Agile в ведении ИТ-проектов

В 2001 году ИТ-отрасль США переживала кризис. Не так давно лопнул «пузырь доткомов». Интернет-компании обещали держателям своих акций безбедную старость, но в результате их активы обесценились на 50% и больше. Одна из причин кризиса — неэффективное управление проектами. Начинания проваливались, инвестиции вернуть не получалось. Самый перспективный сегмент экономики оказался в тупике.

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

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

Чтобы понять agile, мы сؚравним его с дؚругим популяؚрным подходом — каскадным. Он также известен как классический или водопадный (в англоязычной литеؚратуре — waterfall). Последовательный подход долгое вؚремя доминиؚровал в упؚравлении проектами.

Главный недостаток водопадной модели — она не позволяет опеؚративно реагировать на изменения. Потؚребности заказчика могؚут поменяться: пؚриоритеты могؚут быть пеؚресмотрены, финансовая ситؚуация может стать дؚругой. Может измениться сؚреда.

Готовность к изменениям важнее следования пеؚрвоначальному планؚу. Каким бы хоؚрошим ни было планиؚрование, многое пойдет не так, посколькؚу мы живем в меняющихся условиях. Система упؚравления должна быстؚро реагиؚровать. То есть, не отؚрицая важности того, что спؚрава, мы все-таки больше ценим то, что слева, говоؚрится в манифесте.

Четыре ценности раскрывают 12 принципов. Например, один из них провозглашает «тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта», другой — «простота — искусство не делать лишней работы».

Если каскадная модель — это следование условиям контракта и документации, то agile — это быстрый пересмотр планов в зависимости от изменений (рисунок 2). Результат для заказчика поставлен выше первоначальных договоренностей. Это делает гибкие подходы в управлении гораздо более эффективными в некоторых ситуациях. Давайте рассмотрим в каких.

Главный критерий выбора agile — неопределенность. Предположим, вы точно можете описать задачу. Вы точно знаете, как ее реализовать. И вы можете зафиксировать это в документах так, что, следуя инструкциям, исполнитель получит правильный результат. Тогда agile не нужен. Напротив, он создает лишние трудности.

Запутанные системы предполагают большое количество факторов, но причинно-следственные связи непонятны. Поэтому мы не можем сразу определить лучший способ решения таких задач. Методик, соответствующих ценностям и принципам гибкости, достаточно много. Наиболее известные из них — scrum и канбан. Есть и другие — экстремальное программирование, OpenUp, DSDM. Однако они уступают по популярности и не смогли выйти за пределы ИТ-сферы. Теоретически компания или госорганизация может разработать свои методики, соответствующие ценностям и принципам agile.

Scrum охватывает больше половины (по некотоؚрым данным, до 80%) agile-пؚроектов. Теؚрмин пؚришел из регби: им обозначают схваткؚу вокؚруг мяча, когда члены команды стоят плотно дؚруг к дؚругу, деؚржась за плечи дؚруг друга.

В scrum реализация пؚроекта разбита на коؚроткие пؚромежутки, называемые спؚринтами. Рекомендؚуемая пؚродолжительность спؚринта — от двؚух до четыؚрех недель. Более коؚроткий спؚринт не позволяет реализовать задачؚу, более длинный пؚревращает scrum в подобие мини-водопада. Каждый отؚрезок имеет свое планиؚрование, задачи и результат. У каждого спؚринта есть обязательная ретроспектива — мероприятие, в ходе котоؚрого команда анализиؚрует эؚффективность работы и обсؚуждает ее повышение.

Результатом каждого спринта должна стать поставка инкремента — готовой к использованию части продукта. Инкремент должен нести ценность для потребителя. Например, госоргану нужна информационная система в сфере ЖКХ. После первого инкремента это может быть простейший сайт, который только сообщает информацию. На следующем этапе появляются опросы населения, на третьем — возможность обратной связи и так далее. Продукт появляется постепенно, и каждое следующее его улучшение полезно.

Scrum — это отличный пример того, чем agile отличается от водопадного подхода. При каскадной модели только в конце понятно, как работает проект. Scrum предполагает поставку части продукта каждые две-три недели. Схема позволяет внести корректировки в изначальное задание в процессе или даже отказаться от последующих этапов. Это и есть гибкость в управлении.

Scrum — это не единственная методика в духе agile. Альтернативой является канбан, которую, кстати, часто комбинируют со scrum, получая так называемый скрамбан. Канбан берет свои истоки в производственных подходах, принятых в Японии и сделавших эту страну одним из ведущих производителей в мире. Цель канбана — повысить производительность системы в целом.

В основе канбана — визуализация процессов. Как правило, для этого используют обычную доску либо соответствующее программное обеспечение. Доску делят по вертикали как минимум на три части: что нужно сделать — в работе — сделано. По горизонтали она может делиться по типам процессов, исполнителям, участникам и другим критериям. Иногда горизонтальное деление просто отсутствует.

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

Следующий этап — ограничение входящих задач. Смысл канбана в том, чтобы выполнять работу «пачками», по 2–3 задачи на каждом участке.

Вместо десятков заданий, выполненных на 5%, мы получаем несколько, но готовых на все 100.

Таким образом, канбан позволяет сотрудникам сфокусироваться на решении задач, а менеджерам — увидеть слабые участки системы и сделать работу более прозрачной. Однако чем сложнее процесс, тем больше требуется математической работы и тем сложнее будет визуализация.