Agile в проекте на смертельном марше Алексей Корсун Консультант по управлению IT-проектами 09 декабря 2009. - презентация

1 Agile в проекте на смертельном марше Алексей Корсун Консультант по управлению IT-проектами 09 декабря 2009

2 2 Содержание доклада Как вытащить из кризиса убыточный проект с тяжёлым наследством Как убедить инвесторов и команду, что это действительно возможно Как сделать всё это быстро

3 3 Дано: Проект, 2.5 года, распределенная команда Вышел в Live – много проблем и запросов новой функциональности. Расходы на поддержание проекта значительно превышают доходы Скорость разработки новых вич по оценке инвесторов и покупателей – низкая.

4 4 Задача: Добиться повышения качества для удовлетворения существующих клиентов. Ускорить выпуск новых вич. Сделать это быстро – в течение полугода, иначе программа реформ менеджмента будет просто свёрнута как доп. расход.

5 5 Как добиться результатов быстро? Правильно выбрать направление реформ Определить самые важные изменения, которые принесут ощутимую пользу в ближайшее время Быстро провести сами реформы При этом, не похоронить проект ещё больше, забывая о важных задачах, но с результатом в отдалённом будущем

6 6 Достичь согласия в составе изменений Дерево нежелательных явлений Определить какие проблемы есть Найти корень проблем Дерево перехода к желаемой реальности Чего хотим достичь Как этого достичь Почему это сработает

7 7

8 8 Дерево нежелательных явлений

9 9 Что хочется получить? Снизить количество дефектов Быстро выпускать вичи (быстро – значит много и с маленьким time-to-market) Предпринимать не только реактивные действия, но и находить время на развитие инфраструктуры системы

10 10

11 11

12 12 Дерево перехода (3)

13 13 Подводные камни кризисного проекта Нет доверия между инвестором и командой Чувство вины ( overcommitment) Неверие в планы Слово мы Нет времени – надо делать дело. Гонка Addiction to urgency (делаем то, что принесёт краткосрочный успех)

14 14 Общее видение реформ Мы придём к: Снижению числа дефектов Быстрому выпуску вич Активности Если у нас будут: Понятные цель и приоритеты Лучшие коммуникации Быстрые циклы обратной связи И если мы не будем гнаться, создавая заторы.

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

16 16 Цель

17 17 Маркетинг и продажи – вперёд Задача – не внедрение Agile, а скорость достижения цели Гибкость порой бывает минусом. Цена ошибки снижается – думать перестают, излишне полагаясь на попробуем Ошибки позиционирования на рынке, прощавшиеся до кризиса, сейчас – вопрос выживания.

18 18

19 19

20 20 Ошибки позиционирования Цель – есть. Есть Vision. Но цель – не достигает цели ;-) Итоги: Несфокусированность Параллельные проекты Непонятные приоритеты Нет финансовых результатов

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

22 22 Решение Долгое обсуждение с продавцами и маркетингом при участии разработчиков того, что действительно хорошо может наш продукт Выжимка из видения из шести строк по образцу: Для: (клиентов) Которым нужно: (преимущество/решение проблемы) Наш продукт, являющийся: (категория продукта) Позволит: (выгоды) В отличие от конкурентов: Основные особенности:

23 23 Доведение целей до команды Приоритезированный Backlog как средство коммуникации между маркетингом и разработчиками Цель и план итерации Фокус на Почему делаем именно это. Taskboard Фокус на Done, ограничивая WIP Операционные показатели: метрики

24 24 Заторы Заторы перепроизводства?

25 25

26 26 Лучше меньше, да лучше Иногда, чтобы увеличить скорость, нужно её снизить Признаки, когда это стоит сделать: Желание выделить команду пожаротушения Экспедирование срочных проблем Избыток быстрых путей В этих случаях стоит делать меньше, чтобы стабилизировать процесс. Высвободившееся время стоит инвестировать в оптимизацию процесса, чтобы устранить положительную обратную связь

27 27 Результат снижения скорости Уменьшение количества открываемых багов, через полтора месяца позволило освободить ресурсы QA и задействовать их в тестировании Mainline, что увеличило качество и скорость Значительно улучшили инфраструктуру разработки – юнит-тесты, автоматический сбор метрик, архитектурные улучшения итп.. В освободившееся время проводилось обучение Agile, архитектуре системы – обмен знаниями

28 28 Быстродействующий Agile

29 29 Залог быстрого внедрения – согласие команды и общее понимание целей.

30 30 Фокус на людях и коммуникациях Ретроспективы Мотивация - видно улучшения Устранили страх изменений Отдельное совещание по улучшениям Парное программирование или ревью повысило качество освободило необходимые ресурсы QA Stand-upы Решили проблемы изобретения велосипедов Всем понятен прогресс и кто что делает

31 31 Фокус на качестве Agile version control (feature-branches) Стабилизация Mainline – гарантия релиза Unit-tests Код лучшего качества на выходе Безопасный рефакторинг Снижение кол-ва дефектов --> Разгружает тестеров Continious integration Поддержка Mainline Releasable Раннее информирование о проблемах сборки

32 32 Фокус на скорости Короткие итерации Планирование проще и реалистичнее Ритм Синдром студента Сфокусированность работы – Get Done Нет задач завершённых на 90% Ограничение WIP Стимулирует взаимодействие Нет проблемы: пары нет, код проревьювить некому

33 33 Итоги за 5 месяцев Time-to-market – 3 недели с момента запуска в разработку. Производительность выросла на 25% (40SP/30 SP) Стабильность повысилась - кол-во critical issue уменьшилось с 7 в месяц до 1. Тесты повысили скорость фикса багов Запущен процесс постоянного совершенствования Мораль повысилась (по ретроспективам) Кроссфункциональность снизила риски Очень интересный опыт внедрения Agile

34 34 Какие проблемы остались не решены Два офиса. Комментарий инвестора - так стабильнее. А на решение проблем коммуникации средств недостаточно. Непрозрачность структуры расходов и доходов не позволяет повысить эффективность принятия решений. Приходится основываться на догадках.

35 35 Алексей Корсун Консультант по управлению IT-проектами