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

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

• 1.
  Agile в проектена смертельном марше Алексей Корсун Консультант по управлению IT -проектами 09 декабря 200 9
• 2.
  Содержание доклада Каквытащить из кризиса убыточный проект с тяжёлым наследством Как убедить инвесторов и команду , что это действительно возможно Как сделать всё это быстро
• 3.
  Дано : Проект, 2.5 года , распределёненая команда Вышел в Live – много проблем и запросов новой функциональности . Расходы на поддержание проекта значительно превышают доходы Скорость разработки новых фич по оценке инвесторов и покупателей – низкая .
• 4.
  Задача : Добитьсяповышения качества для удовлетворения существующих клиентов . Ускорить выпуск новых фич . Сделать это быстро – в течение полугода , иначе программа реформ менеджмента будет просто свёрнута как доп . расход.
• 5.
  Как добиться результатовбыстро ? Правильно выбрать направление реформ Определить самые важные изменения , которые принесут ощутимую пользу в ближайшее время Быстро провести сами реформы При этом , не похоронить проект ещё больше , забывая о важных задачах , но с результатом в отдалённом будущем
• 6.
  Достичь согласия всоставе изменений Дерево нежелательных явлений Определить какие проблемы есть Найти корень проблем Дерево перехода к желаемой реальности Чего хотим достичь Как этого достичь Почему это сработает
• 8.
  Дерево нежелательных явлений
• 9.
  Что хочется получить? Снизить количество дефектов Быстро выпускать фичи (быстро – значит много и с маленьким time-to-market ) Предпринимать не только реактивные действия , но и находить время на развитие инфраструктуры системы
• 12.
  Дерево перехода (3)
• 13.
  Подводные камни кризисногопроекта Нет доверия между инвестором и командой Чувство вины (  overcommitment ) Неверие в планы Слово “ мы ” Нет времени – надо делать дело . “ Гонка ” Addiction to urgency ( делаем то , что принесёт кратксрочный успех )
• 14.
  Общее видение реформМы придём к : Снижению числа дефектов Быстрому выпуску фич Активности Если у нас будут : Понятные цель и приоритеты Лучшие коммуникации Быстрые циклы обратной связи И если мы не будем “ гнаться ”, создавая заторы .
• 15.
  Итог анализа Командадостигла согласия в том , что : Дрейф целей и “ заторы перепроизводства ” являются одними из самых критичных проблем текущего этапа проекта . Внедрение Agile- методологий может помочь проекту увеличить скорость и , что не менее важно , качество
• 16.
  Цель
• 17.
  Маркетинг и продажи– вперёд Задача – не внедрение Agile, а скорость достижения цели Гибкость порой бывает минусом . Цена ошибки снижается – думать перестают , излишне полагаясь на “ попробуем ” Ошибки позиционирования на рынке , прощавшиеся до кризиса , сейчас – вопрос выживания .
• 20.
  Ошибки позиционирования Цель– есть . Есть Vision. Но цель – не достигает цели ;- ) Итоги : Несфокусированность Параллельные проекты Непонятные приоритеты Нет финансовых результатов
• 21.
  Проблемы позиционирования выливаютсяв “ дрейф ” цели . В условиях необходимости денег “ сейчас и быстро ” продавцы “ бросаются ” на любого клиента , соглашаясь на любые фичи . При этом понимания к каким клиентам надо идти – нет . Усилия пропадают впустую .
• 22.
  Решение Долгое обсуждениес продавцами и маркетингом при участии разработчиков того , что действительно хорошо может наш продукт Выжимка из видения из шести строк по образцу : Для: (клиентов) Которым нужно: (преимущество / решение проблемы) Наш продукт , являющийся : ( категория продукта ) Позволит : (выгоды) В отличие от конкурентов: Основные особенности :
• 23.
  Доведение целей докоманды Приоритезированный Backlog как средство коммуникации между маркетингом и разработчиками Цель и план итерации Фокус на “ Почему делаем именно это ”. Taskboard Фокус на Done, ограничивая WIP Операционные показатели : метрики
• 24.
  “ Заторы ” перепроизводства ?
• 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 -проектами [email_address]