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

689 views

Published on

Published in: Technology, Health & Medicine
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
689
On SlideShare
0
From Embeds
0
Number of Embeds
55
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Ресурсов - нет, денег не дают, хотят результаты и быстро. При этом могут выкинуть в любой момент. Мораль в коллективе плохая. Что может Agile и какой итог он должен показать, чтобы сказали - да, стоит продолжать.
  • И вот с последним – проблема – инерция . Вообще все три цели надо преследовать вместе и постоянно . Лестница приставлена к верной стене Все изменения сделать не успеем Нужно показать эффект раньше , чтобы усилить желание всей команды продолжать Заручиться поддержкой Найти адептов
  • Менеджеры говорят одно Разработчики другое Важно услышать обе точки зрения , при этом очень осторожно подводить к этому . Пример противоречия : “ хороший процесс подбора кадров ” и “ неквалифицированные кадры ”
  • Для упрощения многие связи в НЖЯ убрал и некоторые промежуточные элементы тоже
  • Менеджер должен думать и о маркетинге Про исправление , увы , не скажу - коммерческая тайна .
  • Интересные циклы положительной обратной связи (негативной) . Положительная обратная связь дестабилизирует систему делая процесс неустойчивым .
  • Скорость QA и скорость Dev меряли отдельно – сравнивая пропускную способность и её изменения .
  • Agile на Смертельном Марше

    1. 1. Agile в проекте на смертельном марше Алексей Корсун Консультант по управлению IT -проектами 09 декабря 200 9
    2. 2. Содержание доклада <ul><li>Как вытащить из кризиса убыточный проект с тяжёлым наследством </li></ul><ul><li>Как убедить инвесторов и команду , что это действительно возможно </li></ul><ul><li>Как сделать всё это быстро </li></ul>
    3. 3. Дано : <ul><li>Проект , 2.5 года , распределёненая команда </li></ul><ul><li>Вышел в Live – много проблем и запросов новой функциональности . </li></ul><ul><li>Расходы на поддержание проекта значительно превышают доходы </li></ul><ul><li>Скорость разработки новых фич по оценке инвесторов и покупателей – низкая . </li></ul>
    4. 4. Задача : <ul><li>Добиться повышения качества для удовлетворения существующих клиентов . </li></ul><ul><li>Ускорить выпуск новых фич . </li></ul><ul><li>Сделать это быстро – в течение полугода , иначе программа реформ менеджмента будет просто свёрнута как доп . расход. </li></ul>
    5. 5. Как добиться результатов быстро ? <ul><li>Правильно выбрать направление реформ </li></ul><ul><li>Определить самые важные изменения , которые принесут ощутимую пользу в ближайшее время </li></ul><ul><li>Быстро провести сами реформы </li></ul><ul><li>При этом , не похоронить проект ещё больше , забывая о важных задачах , но с результатом в отдалённом будущем </li></ul>
    6. 6. Достичь согласия в составе изменений <ul><li>Дерево нежелательных явлений </li></ul><ul><ul><li>Определить какие проблемы есть </li></ul></ul><ul><ul><li>Найти корень проблем </li></ul></ul><ul><li>Дерево перехода к желаемой реальности </li></ul><ul><ul><li>Чего хотим достичь </li></ul></ul><ul><ul><li>Как этого достичь </li></ul></ul><ul><ul><li>Почему это сработает </li></ul></ul>
    7. 7.
    8. 8. Дерево нежелательных явлений
    9. 9. Что хочется получить ? <ul><li>Снизить количество дефектов </li></ul><ul><li>Быстро выпускать фичи (быстро – значит много и с маленьким time-to-market ) </li></ul><ul><li>Предпринимать не только реактивные действия , но и находить время на развитие инфраструктуры системы </li></ul>
    10. 10.
    11. 11.
    12. 12. Дерево перехода (3)
    13. 13. Подводные камни кризисного проекта <ul><li>Нет доверия между инвестором и командой </li></ul><ul><li>Чувство вины (  overcommitment ) </li></ul><ul><li>Неверие в планы </li></ul><ul><li>Слово “ мы ” </li></ul><ul><li>Нет времени – надо делать дело . “ Гонка ” </li></ul><ul><li>Addiction to urgency ( делаем то , что принесёт кратксрочный успех ) </li></ul>
    14. 14. Общее видение реформ <ul><li>Мы придём к : </li></ul><ul><li>Снижению числа дефектов </li></ul><ul><li>Быстрому выпуску фич </li></ul><ul><li>Активности </li></ul><ul><li>Если у нас будут : </li></ul><ul><li>Понятные цель и приоритеты </li></ul><ul><li>Лучшие коммуникации </li></ul><ul><li>Быстрые циклы обратной связи </li></ul><ul><li>И если мы не будем “ гнаться ”, создавая заторы . </li></ul>
    15. 15. Итог анализа <ul><li>Команда достигла согласия в том , что : </li></ul><ul><li>Дрейф целей и “ заторы перепроизводства ” являются одними из самых критичных проблем текущего этапа проекта . </li></ul><ul><li>Внедрение Agile- методологий может помочь проекту увеличить скорость и , что не менее важно , качество </li></ul>
    16. 16. Цель
    17. 17. Маркетинг и продажи – вперёд <ul><li>Задача – не внедрение Agile, а скорость достижения цели </li></ul><ul><li>Гибкость порой бывает минусом . Цена ошибки снижается – думать перестают , излишне полагаясь на “ попробуем ” </li></ul><ul><li>Ошибки позиционирования на рынке , прощавшиеся до кризиса , сейчас – вопрос выживания . </li></ul>
    18. 18.
    19. 19.
    20. 20. Ошибки позиционирования <ul><li>Цель – есть . Есть Vision. </li></ul><ul><li>Но цель – не достигает цели ;- ) </li></ul><ul><li>Итоги : </li></ul><ul><li>Несфокусированность </li></ul><ul><li>Параллельные проекты </li></ul><ul><li>Непонятные приоритеты </li></ul><ul><li>Нет финансовых результатов </li></ul>
    21. 21. <ul><li>Проблемы позиционирования выливаются в “ дрейф ” цели . </li></ul><ul><li>В условиях необходимости денег “ сейчас и быстро ” продавцы “ бросаются ” на любого клиента , соглашаясь на любые фичи . </li></ul><ul><li>При этом понимания к каким клиентам надо идти – нет . Усилия пропадают впустую . </li></ul>
    22. 22. Решение <ul><li>Долгое обсуждение с продавцами и маркетингом при участии разработчиков того , что действительно хорошо может наш продукт </li></ul><ul><li>Выжимка из видения из шести строк по образцу : </li></ul><ul><ul><li>Для: (клиентов) </li></ul></ul><ul><ul><li>Которым нужно: (преимущество / решение проблемы) </li></ul></ul><ul><ul><li>Наш продукт , являющийся : ( категория продукта ) </li></ul></ul><ul><ul><li>Позволит : (выгоды) </li></ul></ul><ul><ul><li>В отличие от конкурентов: </li></ul></ul><ul><ul><li>Основные особенности : </li></ul></ul>
    23. 23. Доведение целей до команды <ul><li>Приоритезированный Backlog </li></ul><ul><ul><li>как средство коммуникации между маркетингом и разработчиками </li></ul></ul><ul><li>Цель и план итерации </li></ul><ul><ul><li>Фокус на “ Почему делаем именно это ”. </li></ul></ul><ul><li>Taskboard </li></ul><ul><ul><li>Фокус на Done, ограничивая WIP </li></ul></ul><ul><li>Операционные показатели : метрики </li></ul>
    24. 24. “ Заторы ” перепроизводства ?
    25. 25.
    26. 26. “ Лучше меньше , да лучше ” <ul><li>Иногда , чтобы увеличить скорость , нужно её снизить </li></ul><ul><li>Признаки , когда это стоит сделать : </li></ul><ul><ul><li>Желание выделить команду “ пожаротушения ” </li></ul></ul><ul><ul><li>Экспедирование срочных проблем </li></ul></ul><ul><ul><li>Избыток “ быстрых путей ” </li></ul></ul><ul><li>В этих случаях стоит делать меньше , чтобы стабилизировать процесс . </li></ul><ul><li>Высвободившееся время стоит инвестировать в оптимизацию процесса , чтобы устранить положительную обратную связь </li></ul>
    27. 27. Результат снижения скорости <ul><li>Уменьшение количества открываемых багов , через полтора месяца позволило освободить ресурсы QA и задействовать их в тестировании Mainline, что увеличило качество и скорость </li></ul><ul><li>Значительно улучшили инфраструктуру разработки – юнит-тесты , автоматический сбор метрик , архитектурные улучшения итп .. </li></ul><ul><li>В освободившееся время проводилось обучение Agile, архитектуре системы – обмен знаниями </li></ul>
    28. 28. “ Быстродействующий Agile”
    29. 29. Залог быстрого внедрения – согласие команды и общее понимание целей .
    30. 30. Фокус на людях и коммуникациях <ul><li>Ретроспективы </li></ul><ul><ul><li>Мотивация - видно улучшения </li></ul></ul><ul><ul><li>Устранили страх изменений </li></ul></ul><ul><ul><li>Отдельное совещание по улучшениям </li></ul></ul><ul><li>Парное программирование или ревью </li></ul><ul><ul><li>повысило качество </li></ul></ul><ul><ul><li>освободило необходимые ресурсы QA </li></ul></ul><ul><li>Stand-up’ ы </li></ul><ul><ul><li>Решили проблемы изобретения велосипедов </li></ul></ul><ul><ul><li>Всем понятен прогресс и кто что делает </li></ul></ul>
    31. 31. Фокус на качестве <ul><li>Agile version control (feature-branches) </li></ul><ul><ul><li>Стабилизация Mainline – гарантия релиза </li></ul></ul><ul><li>Unit-tests </li></ul><ul><ul><li>Код лучшего качества на выходе </li></ul></ul><ul><ul><li>Безопасный рефакторинг </li></ul></ul><ul><ul><li>Снижение кол-ва дефектов </li></ul></ul><ul><ul><li>--> Разгружает тестеров </li></ul></ul><ul><li>Continious integration </li></ul><ul><ul><li>Поддержка Mainline Releasable </li></ul></ul><ul><ul><li>Раннее информирование о проблемах сборки </li></ul></ul>
    32. 32. Фокус на скорости <ul><li>Короткие итерации </li></ul><ul><ul><li>Планирование проще и реалистичнее </li></ul></ul><ul><ul><li>Ритм </li></ul></ul><ul><ul><li>“ Синдром студента ” </li></ul></ul><ul><li>Сфокусированность работы – Get Done </li></ul><ul><ul><li>Нет задач завершённых на 90% </li></ul></ul><ul><li>Ограничение WIP </li></ul><ul><ul><li>Стимулирует взаимодействие </li></ul></ul><ul><ul><li>Нет проблемы : пары нет , код проревьювить некому </li></ul></ul>
    33. 33. Итоги за 5 месяцев <ul><li>Time-to-market – 3 недели с момента запуска в разработку. </li></ul><ul><li>Производительность выросла на 25% (40SP/30 SP) </li></ul><ul><li>Стабильность повысилась - кол-во critical issue уменьшилось с 7 в месяц до 1. </li></ul><ul><li>Тесты повысили скорость фикса багов </li></ul><ul><li>Запущен процесс постоянного совершенствования </li></ul><ul><li>Мораль повысилась (по ретроспективам) </li></ul><ul><li>Кроссфункциональность снизила риски </li></ul><ul><li>Очень интересный опыт внедрения Agile </li></ul>
    34. 34. Какие проблемы остались не решены <ul><li>Два офиса. Комментарий инвестора - так стабильнее. А на решение проблем коммуникации средств недостаточно. </li></ul><ul><li>Непрозрачность структуры расходов и доходов не позволяет повысить эффективность принятия решений . Приходится основываться на догадках . </li></ul>
    35. 35. <ul><li>Алексей Корсун </li></ul><ul><li>Консультант по управлению IT -проектами </li></ul><ul><li>[email_address] </li></ul>

    ×