'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

7


Слайд 7

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


Слайд 8

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


Слайд 9

10


Слайд 10

11


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

16 Цель


Слайд 16

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


Слайд 17

18


Слайд 18

19


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

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


Слайд 23

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


Слайд 24

25


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

29


Слайд 29

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


Слайд 30

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


Слайд 31

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


Слайд 32

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


Слайд 33

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


Слайд 34

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


×

HTML:





Ссылка: