agile на Смертельном Марше

Agile в проекте на смертельном марше

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

09 декабря 2009

2

Содержание доклада

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

Как убедить инвесторов и команду, что это действительно возможно

Как сделать всё это быстро

3

Дано:

Проект, 2.5 года, распределёненая команда Вышел в Live – много проблем и запросов

новой функциональности. Расходы на поддержание проекта

значительно превышают доходы Скорость разработки новых фич по оценке

инвесторов и покупателей – низкая.

4

Задача:

Добиться повышения качества для удовлетворения существующих клиентов.

Ускорить выпуск новых фич. Сделать это быстро – в течение полугода,

иначе программа реформ менеджмента будет просто свёрнута как доп. расход.

5

Как добиться результатов быстро?

Правильно выбрать направление реформ

Определить самые важные изменения, которые принесут ощутимую пользу в ближайшее время

Быстро провести сами реформы

При этом, не похоронить проект ещё больше, забывая о важных задачах, но с результатом в отдалённом будущем

6

Достичь согласия в составе изменений

Дерево нежелательных явлений Определить какие проблемы есть Найти корень проблем

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

7

8

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

9

Что хочется получить?

Снизить количество дефектов

Быстро выпускать фичи (быстро – значит много и с маленьким time-to-market)

Предпринимать не только реактивные действия, но и находить время на развитие инфраструктуры системы

10

11

12

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

13

Подводные камни кризисного проекта

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

принесёт кратксрочный успех)

14

Общее видение реформ

Мы придём к: Снижению числа дефектов Быстрому выпуску фич Активности

Если у нас будут: Понятные цель и приоритеты Лучшие коммуникации Быстрые циклы обратной связи

И если мы не будем “гнаться”, создавая заторы.

15

Итог анализа

Команда достигла согласия в том, что: Дрейф целей и “заторы перепроизводства”

являются одними из самых критичных проблем текущего этапа проекта.

Внедрение Agile-методологий может помочь проекту увеличить скорость и, что не менее важно, качество

16

Цель

17

Маркетинг и продажи – вперёд

Задача – не внедрение Agile, а скорость достижения цели

Гибкость порой бывает минусом. Цена ошибки снижается – думать перестают, излишне полагаясь на “попробуем”

Ошибки позиционирования на рынке, прощавшиеся до кризиса, сейчас – вопрос выживания.

18

19

20

Ошибки позиционирования

Цель – есть. Есть Vision.

Но цель – не достигает цели ;-)

Итоги: Несфокусированность Параллельные проекты Непонятные приоритеты Нет финансовых результатов

21

Проблемы позиционирования выливаются в “дрейф” цели.

В условиях необходимости денег “сейчас и быстро” продавцы “бросаются” на любого клиента, соглашаясь на любые фичи.

При этом понимания к каким клиентам надо идти – нет. Усилия пропадают впустую.

22

Решение

Долгое обсуждение с продавцами и маркетингом при участии разработчиков того, что действительно хорошо может наш продукт

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

23

Доведение целей до команды

Приоритезированный Backlog как средство коммуникации между

маркетингом и разработчиками Цель и план итерации

Фокус на “Почему делаем именно это”. Taskboard

Фокус на Done, ограничивая WIP Операционные показатели: метрики

24

““ЗаторыЗаторы””

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

25

Сроки срываются, оценки ненадёжны

Долгий цикл разработки

Очень много багов и сайд-эффектов

Нет автоматических тестов, feature-

branches

Большое время на поиск причин багаАрхитектура сложна

в поддержке

Не хватает времени на улучшения

Перегрузка QA - не всё успевают

проверять

26

“Лучше меньше, да лучше”

Иногда, чтобы увеличить скорость, нужно её снизить Признаки, когда это стоит сделать:

Желание выделить команду “пожаротушения” Экспедирование срочных проблем Избыток “быстрых путей”

В этих случаях стоит делать меньше, чтобы стабилизировать процесс.

Высвободившееся время стоит инвестировать в оптимизацию процесса, чтобы устранить положительную обратную связь

27

Результат снижения скорости

Уменьшение количества открываемых багов, через полтора месяца позволило освободить ресурсы QA и задействовать их в тестировании Mainline, что увеличило качество и скорость

Значительно улучшили инфраструктуру разработки – юнит-тесты, автоматический сбор метрик, архитектурные улучшения итп..

В освободившееся время проводилось обучение Agile, архитектуре системы – обмен знаниями

28

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

29

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

30

Фокус на людях и коммуникациях

Ретроспективы Мотивация - видно улучшения Устранили страх изменений Отдельное совещание по улучшениям

Парное программирование или ревью повысило качество освободило необходимые ресурсы QA

Stand-up’ы Решили проблемы изобретения велосипедов Всем понятен прогресс и кто что делает

31

Фокус на качестве Agile version control (feature-branches)

Стабилизация Mainline – гарантия релиза Unit-tests

Код лучшего качества на выходе Безопасный рефакторинг Снижение кол-ва дефектов --> Разгружает тестеров

Continious integration Поддержка Mainline Releasable Раннее информирование о проблемах сборки

32

Фокус на скорости Короткие итерации

Планирование проще и реалистичнее Ритм “Синдром студента”

Сфокусированность работы – Get Done Нет задач завершённых на 90%

Ограничение WIP Стимулирует взаимодействие Нет проблемы: пары нет, код проревьювить некому

33

Итоги за 5 месяцев

Time-to-market – 3 недели с момента запуска в разработку.

Производительность выросла на 25% (40SP/30 SP) Стабильность повысилась - кол-во critical issue

уменьшилось с 7 в месяц до 1. Тесты повысили скорость фикса багов Запущен процесс постоянного совершенствования Мораль повысилась (по ретроспективам) Кроссфункциональность снизила риски

Очень интересный опыт внедрения Agile

34

Какие проблемы остались не решены

Два офиса. Комментарий инвестора - так стабильнее. А на решение проблем коммуникации средств недостаточно.

Непрозрачность структуры расходов и доходов не позволяет повысить эффективность принятия решений. Приходится основываться на догадках.

35

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

KorsunAO@gmail.com