Agile не имеет непосредственного отношения к управлению проектами, хотя часто упоминается в контексте проектной деятельности. Например, можно услышать, как Agile противопоставляется классическим методам управления проектами или входит в пятерку или десятку самых популярных. И довольно странно видеть его рядом со Scrum и Канбаном в рейтингах как сущность одного с ними порядка.
Чтобы разобраться в этом, обратимся к истории появления Agile. По итогам всех научно-технических революций в прошлом веке сложилось понимание, что IT-компании создают некие продукты. И эти продукты с инженерной точки зрения безусловно «красивое», но далеко не всегда конечные пользователи могут оценить эту красоту.
Представьте, например, что вы участвуете в проектировании тепловоза. Ваша команда из лучших побуждений предлагает: «Сделаем для машиниста сенсорную панель управления! Это же классное решение!» Однако реальность такова, что у машиниста руки постоянно в масле, а значит, сенсорная панель будет сразу же заляпана и обругана. Поэтому вашему тепловозу нужны тривиальные кнопки. Подобных нюансов может возникать множество.
Почему agile-философия не для управления проектами
В 2001 году разработчики и ИТ-инженеры выпустили Manifesto for Agile Software Development, в котором они задекларировали свои ценности. Основной посыл манифеста заключался не в том, чтобы продвигать новый подход к управлению, а в том, чтобы создавать замечательные продукты для своих клиентов.
Авторы манифеста исходили из того, что в динамично развивающемся мире клиент не всегда знает, чего он хочет. Так как сами инженеры никогда не были на месте клиента, они плохо понимают, что ему надо, и делают то, что им самим кажется уместным. При этом совершенствовать свои продукты они могут сколь угодно долго, увлеченно вкладывая огромные ресурсы. Такая установка уже прямо противоречит проектной логике, которая подразумевает четкие сроки и запланированный бюджет.
Итак, на Agile-манифест надо смотреть именно с точки зрения разработчиков и инженеров, а не руководителей проектов.
1
Люди и взаимодействие важнее процессов и инструментов. Мы не всегда понимаем, чего хочет клиент. Более того, клиент иногда сам не понимает, чего ему следовало бы захотеть, чтобы решить свою проблему.
2
Работающий продукт важнее исчерпывающей документации. Документы могут быть сколь угодно объемны и прекрасны, но клиенту нужно, чтобы все работало так, как он этого ждет.
3
Сотрудничество с заказчиком важнее согласования условий контракта. Каким бы ни было техзадание, все равно в него придется вносить корректировки, чтобы в полном объеме реализовать все то, что уже хочет и еще захочет клиент.
4
Готовность к изменениям важнее следования первоначальному плану. Если мы не знаем, какую проблему решает клиент, то придется так или иначе подстраиваться под его видение.
Как и для чего появились agile-инструменты
Когда возникла необходимость подобрать инструменты для практической реализации этих ценностей, разработчики обратились к Toyota Production System. Здесь они нашли инструменты, которые предназначались для стабильно работающего конвейера, способного бесконечно долго выпускать классные продукты. Но это не инструменты проектного управления!
Все agile-практики направлены на то, чтобы с постоянно растущим качеством создавать для клиента тот продукт, который ему нужен. «А давайте вместе подумаем, как создать более качественный продукт, который точно понравится клиенту!» – такая установка вступает в конфликт с целями проекта, когда нужно выдать конкретный результат в четко заданный срок. Именно поэтому agile в чистом виде может помогать достигать высокого качества в проектах, но не отвечает на вопросы соблюдения сроков и бюджетов.
Когда agile-инструменты применимы в управлении проектами
Философия agile не формулировалась для управления проектами: она предполагает деятельность, направленную на создание и постоянное развитие продукта в будущем. Однако отдельные инструменты гибкого подхода – Канбан, Scrum и т. п. – вполне можно применять в рамках реализации проекта.
Scrum предполагает, что у вас небольшая команда из 3–5 человек. Максимум – из семи. У всех определенные роли: один проектирует, другой создает, третий тестирует. В реальном проекте три человека даже в течение целого года могут создать только очень небольшой результат. Отсюда возникает потребность в масштабировании подхода (см. LeSS – Large Scale Scrum). Однако следует помнить, что изначально Scrum направлен на сплоченность команды и поддержание единого информационного поля, чтобы каждый помнил о цели: о создании классного продукта для клиента. Поэтому если у вас небольшая проектная команда, можно выбрать Scrum и этого будет достаточно. Но Scrum не отменяет того, что весь проект надо планировать. Потому что если двигаться итерациями без планирования на средне— и долгосрочную перспективы, то в таком творческом режиме вы не сможете адекватно оценить бюджет и ваш проект быстро превратится в бардак.
Другой пример – Канбан. Допустим, вам повезло, и все работы в проекте имеют свой маленький жизненный цикл, каждый компонент итогового результата должен быть спроектирован, реализован и пройти приемку качества. В таком случае разумно строить непрерывно работающий конвейер, в котором есть участки проектирования, реализации, тестирования, а также ресурсы в таком объеме, чтобы в работе конвейера не возникало «бутылочных горлышек» или роста «складских остатков». Равномерное распределение ресурсов на участках конвейера позволяет добиться ритмичности работы – у вас не будет ситуации, когда проектировщики не спешат, а производители потом зашиваются.
Эти инструменты соответствуют философии agile, и вы можете ими воспользоваться в проекте, не разделяя саму философию agile, но при этом понимая, с какой целью вы их внедряете.
Возможно, результат вашего проекта превратится в продукт, который потребуется постоянно поддерживать и развивать, и тогда вы сможете применить agile-практики в полном объеме. Но пока проект остается проектом, вам придется смириться с тем, что ограничения по срокам и бюджету превалируют над стремлением к совершенству.
