Часть 1. Почему Agile — это не серебряная пуля

Часть 2.

Мы открываем серию дискуссий, посвященных практическому применению Agile к управлению проектами, где постараемся объективно рассказать про особенности аджайл-подходов, подкрепив их разбором практических примеров российских и зарубежных проектов. Начнем с границ применимости...

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

Во первых, Agile не является методологией. Это — прежде всего образ мышления, набор ценностей и принципов (см. Agile Manifest), а потом уже набор фреймворков. Это новая система координат и ценностей (?), которая не может существовать локально в отдельной взятой команде или ИТ-департаменте. Она требует сил и энергии для повсеместной «организационной» трансформации.

Пример. «Оптимум системы не равен сумме локальных оптимумов» Э. Голдратт. Часто многие компании рассказывают об успешности внедрения Scrum или XP на уровне команд разработки. Есть итерации, стенд-апы и пр. Но если посмотреть «сверху», то никаких изменений на уровне всей организации не произошло. Точнее, реализовалась локальная оптимизация в ИТ. Нет ожидаемого эффекта, аджайл стал очередной «игрушкой» для программистов. По прежнему продукты выходят в продакшн раз в полгода, с заказчиками не выстроены прозрачные взаимоотношения, а ошибки копятся из релиза в релиз. В этом случае мы реализовали «механический» Скрам — скопировали процесс, но не изменили ценностную систему координат.

—Во вторых, важно понимать, что влияет на выбор инструмента управления проектом. Ведь Agile, как и «waterfall», PRINCE2 или RUP — лишь один из множества существующих подходов. И перед стартом очередного проекта необходимо учесть много факторов, прежде чем выбрать наилучший. В погоне за явными и неявными ожидаемыми преимуществами Agile (выпускать продукты на рынок быстрее, с лучшим качеством и более высокой удовлетворенности клиентов), мы забываем о дифференциации методов, забываем учитывать, когда один подход может быть лучше, чем другой.

Что могут включают в себя эти факторы:

• Наличие ограничений (объем, сроки, бюджет)

• Особенность клиентов

• Количество рисков

• Доступные ресурсы

• Изменчивость требований

Пример. Очень часто аджайл становится некоторым «абсолютным оружием» в компании. Мы торопимся его применять (а скорее всего — пытаемся применять) для всех проектов, объясняя последующие неудачи недостаточным опытом, очередной неработающей в отечественных условиях западной методологией, плохим переводом :) и пр.

Так что же такое аджайл — «серебряная пуля» или очередной БОЛЬШОЙ миф? Где границы применимости? Почему для одних проектов эффект применения есть, а для других приводит к провалу? Возможный вариант ответа будет в нашей следующей дискуссии, в который мы поговорим о Модели Кеневин (Cynefin framework) и теории запутанности.

Но прежде интересно узнать, был ли в вашей практике опыт выбора между подходами к ведению ИТ — проектов? Какие методологии вы обычно используете и с каким результатом? Один из лучших недавно услышанных ответов был таким: «мы стараемся действовать по PMBOK, но получается аджайл...» Это ваш случай?