В документе представлено руководство по внедрению методологии Agile в компании за 14 недель, включая подготовительный этап и серию спринтов, каждый из которых имеет свои цели и задачи. Рекомендуется использование цикла Деминга (PDCA) и подходов Shu-Ha-Ri для успешного перехода на гибкие методы разработки. Описание включает шаги с планирования, оценками и адаптацией Agile к специфике бизнеса для команд от 20 до 50 человек.

1. Как внедрить Agile за 14 недель<br />Вольфсон БорисВерсия 0.3 (альфа)<br />Содержание TOC \o \"
1-2\"
\h \z \u <br />Введение PAGEREF _Toc306189680 \h 2<br />Принципы внедрения PAGEREF _Toc306189681 \h 3<br />Цикл Деминга (PDCA-цикл) PAGEREF _Toc306189682 \h 3<br />Shu Ha Ri PAGEREF _Toc306189683 \h 3<br />График и содержание внедрения PAGEREF _Toc306189684 \h 4<br />Неделя №1 (подготовка к трансформации) PAGEREF _Toc306189685 \h 4<br />Неделя №2 (нулевой спринт) PAGEREF _Toc306189686 \h 4<br />Неделя №3 (старт первого «калибровочного» спринта) PAGEREF _Toc306189687 \h 4<br />Неделя №4 (завершение первого «калибровочного» спринта) PAGEREF _Toc306189688 \h 5<br />Неделя №5 (старт второго спринта) PAGEREF _Toc306189689 \h 5<br />Неделя №6 (завершение второго спринта) PAGEREF _Toc306189690 \h 5<br />Неделя №7 (старт третьего спринта) PAGEREF _Toc306189691 \h 5<br />Неделя №8 (завершение третьего спринта) PAGEREF _Toc306189692 \h 6<br />Неделя №9 (старт четвертого спринта) PAGEREF _Toc306189693 \h 6<br />Неделя №10 (завершение четвертого спринта) PAGEREF _Toc306189694 \h 6<br />Неделя №11 (старт пятого спринта) PAGEREF _Toc306189695 \h 6<br />Неделя №12 (завершение пятого спринта) PAGEREF _Toc306189696 \h 6<br />Неделя №13 (старт шестого «идеального» спринта) PAGEREF _Toc306189697 \h 7<br />Неделя №14 (завершение «идеального» шестого спринта) PAGEREF _Toc306189698 \h 7<br />Введение<br />Основная цель составления данного плана по внедрению Agile: дать четкую и краткую инструкцию по трансформации компании/подразделения в гибкую и эффектную бизнес-единицу по производству программного обеспечения.<br />План рассчитан на небольшие компании размером примерно от 20 до 50 человек и нуждается в адаптации под конкретную компанию. Для компаний (или отдельных команд) меньшего размера, можно использовать этот же план за исключением масштабирования методологий. <br />Будем считать, что в компании по исторически сложившимся обстоятельствам используется «методология» Code&Fix. В качестве допущений будем использовать следующие положения<br />длина спринта – 2 недели,<br />длина релиза фиксирована – 3 итерации,<br />внедрение Agile поддерживается руководством;<br />План внедрение рассчитан на то, чтобы не отрываться серьезно команды от производства, и сделать внедрение управленческих и технологических инноваций частью корпоративной культуры компании.<br />453453570739000Предполагается, что организацией внедрения будет заниматься один человек, работая полный день над этой задачей. Это может быть как внешний тренер/консультант, так и внутренний эксперт-внедренец. <br />Автор: Вольфсон Борис <br />http://www.facebook.com/borisvolfson<br />http://twitter.com/borisvolfson<br />borisvolfson@gmail.com <br />Благодарности за замечания и предложения:<br />Дмитрий Паньшин <br />Михаил Подурец<br />Сергей Рогачев<br />Андрей Свердлов<br />Евгений Сорокин<br />Принципы внедрения<br />Цикл Деминга (PDCA-цикл)<br />При организационных изменениях очень помогает использования здравого смысла и научного подхода. Традиционным методом в данном случае является цикл Деминга, который состоит из 4 шагов:<br />302958524574500Plan (планирование)Производится анализ системы и вырабатываются возможные подходы к улучшениям и определяются желаемые результаты<br />Do (исполнение)Решения, выработанные на предыдущем шаге, реализуются.<br />Check (проверка)Производится анализ, полученных результатов, на предыдущем шаге.<br />Act (корректировка)Выполняются корректирующие действия, для уменьшения отклонений от плана.<br />Shu Ha Ri<br />Внедрение методологии и практик можно разбить на три этапы, и важно, чтобы компания и отдельные команды их прошли, не застряв на одном из них. Названия<br />Shu (守:しゅ – «защита», «подчинение») — изучение традиционной мудрости — изучение методологии, работа строго по книжкам, руководствуясь предписаниями тренера/внедренца.<br />Ha (破:は - “отделение”, “отклонение”) — отступление от традиции — понимание методологии на очень глубоком уровне и ее адаптация под требования проектов/бизнеса/внешней среды<br />Ri (離:り - “покидание”, “отделение”) — превосходство над традицией — осознанное отступление от методологии, например, переход со Scrum на Scrumban.<br />Важно, что необходимо пройти все этапы не перепрыгивая их: достаточно стандартная ситуация, когда команда, не может делать Scrum перепрыгивает на Kanban, что в итоге выливается в классический Code and Fix.<br />График и содержание внедрения<br />План состоит из трех частей:<br />Подготовка компании к трансформации: сбор и анализ информации, получение знаний и навыков сотрудниками компании.<br />Первый релиз: знакомство с основными элементами Scrum и Lean<br />Второй релиз: адаптация Agile к бизнесу компании <br />Неделя №1 (подготовка к трансформации)<br />Цели: собрать и проанализировать основную информацию о компании, дать основным участникам базовые знания об Agile<br />Изучение и описание текущих бизнес-процессов компании<br />Составление карты бизнес-процессов в графическом или текстовом виде, касающихся разработки ПО/веб-сайтов<br />Изучение проектов и организация их в портфель проектов<br />Составление списка с проектов<br />Разработка методологии приоритезации, принятия решений о запуске/завершения проектов<br />Приоритезация и балансировка портфеля проектов<br />Буткемп по основам Scrum (Однодневный тренинг по основам скрама с деловыми играми)<br />Каждый участник тренинга должен понимать роли, процессы и артефакты Scrum<br />Продвинутое обучение скрам-мастеров (4-х часовой тренинг)<br />Скрам-мастера должны получить дополнительные знания и навыки по процессам Scrum, навыки фасилитации и организации работы команд.<br />Продвинутое обучение владельцев продуктов (4 часовой тренинг)<br />Владельцы продуктов должны получить дополнительные знания и навыки по управлению продуктами (выявление ролей пользователей, проведение сторимаппинга, управление беклогом, управление релизами)<br />Неделя №2 (нулевой спринт)<br />Цели: выработать понимание продукта и создать высокоуровневую архитектуру<br />Исследование продукта<br />Выявление ролей и персонажей по проектам<br />Сторимаппинга<br />Прототипирование основных интерфейсов<br />Сессия для выявления основных рисков и выработки контрмер<br />Создание высокоуровневой архитектуры продукта<br />Выбор платформы реализации<br />Диаграмма предметной области / высокоуровневая диаграмма классов<br />Неделя №3 (старт первого «калибровочного» спринта)<br />Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum<br />Старт первого спринта с командами<br />Проведение планирования спринта и разбиение юзер-стори на задачи<br />Проведение покер-планирования для оценки юзер-стори<br />Scrum of Scrum<br />Определение сроков проведения Scrum of Scrum<br />Проведение первого Scrum of Scrum<br />Отработка механизма эскалации проблем<br />Отработка механизма синхронизации деятельности команд<br />Неделя №4 (завершение первого «калибровочного» спринта)<br />Цели: отработать завершения спринта и провести ретроспективу на основе качественных показателей<br />Проведение демонстрации и получение фидбека<br />Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений)<br />Определение эмпирически скорости команды<br />Неделя №5 (старт второго спринта)<br />Цели: отработать старт спринта и планирования на основе количественных показателей, начать внедрения базовых практики экстремального программирования<br />Планирование и старт второго спринта<br />Планируем исходя из скорости предыдущего спринта<br />Тренинг и мастер-класс по практикам экстремального программирования<br />Внедрение системы непрерывной интеграции: полная сборка продукта происходит автоматически и непрерывно<br />Выработка и внедрение стандартов кодирования<br />Неделя №6 (завершение второго спринта)<br />Цели: отработать завершения спринта и провести ретроспективу на основе количественных показателей, использую инструменты бережливого производства<br />Изучение практик и инструментов бережливого производства<br />Виды потерь при производстве<br />Value Stream Mapping для текущего процесса<br />«5 почему»<br />Демонстрация<br />Ретроспектива с применением инструментов бережливого производства<br />Разбор причин не успевания по несделанным задачам<br />«5 почему» по каждому дефекту<br />Неделя №7 (старт третьего спринта)<br />Цели: отработать старт предрелизного спринта и понять, как в будущем избежать таких «стабилизационных» спринтов, начать активно использовать автоматизированное тестирование<br />Планирование и старт третьего спринта<br />Особое внимание уделяем недоделанным историям пользователей, которые не успели сделать из-за ограничения по скорости команды<br />Рассматриваем возможность взять поменьше скорость команды, чтобы успеть всё к релизу<br />Внедрение модульных и приемочных тестов<br />Проведения тренинга по приемочным тестам <br />Покрытие 5% основного бизнес-функционала продукта приемочными тестами<br />Проведения тренинга по модульным тестам<br />Покрытие 50% кода, реализованного за спринт, модульными тестами<br />Внедрение рефакторинга <br />Неделя №8 (завершение третьего спринта)<br />Цели: сделать первый Agile-релиз продукта и выработать значительные меры по улучшению процессов на основе информации, полученной за три спринта.<br />Кайдзен-сессия на ретроспективе<br />Диаграмма Исикавы по глобальным проблемам проекта и выработка мер по устранению проблем<br />Завершение третьего спринта<br />Первый релиз продукта: обязательно, чтобы его попробовали конечные пользователи и дали свой фидбек.<br />Post-mortem релиза в рамках ретроспективы<br />Неделя №9 (старт четвертого спринта)<br />Цели: научиться планировать и управлять релизом<br />Планирование релиза<br />Начало ведения бёрндауна релиза<br />Отбор владельцем продукта юзер-стори для релиза<br />Возможная переоценка беклога командой «на пальцах»<br />Внедрение (трех)четырехзвенной архитектуры <br />Планирование и старт четвертого спринта<br />Скорость команды считаем эмпирически по трем предыдущим спринтам<br />Неделя №10 (завершение четвертого спринта)<br />Цели: внедрение статистического управления качеством<br />Завершение четвертого спринта<br />Внедрение основ статистического управления качеством<br />Статистика по дефектам<br />Диаграмма Парето по модулям <br />Диаграммы Шухарта<br />Неделя №11 (старт пятого спринта)<br />Цели: внедрение Kanban для команды саппорта<br />Планирование и старт пятого спринта<br />Анализируем и изменяем скоуп по релиз-бёрндауну<br />Переход на Scrumban команды саппорта<br />Тренинг по Kanban (4 часа) для членов команды<br />Отказ от жестких итераций<br />Внедрение разработки через тестирование<br />Тренинг и мастер-класс по разработке через тестирование<br />Покрытие тестами модулей ядра системы (не менее 50% строк кода)<br />Неделя №12 (завершение пятого спринта)<br />Цели: улучшение внутреннего качества ядра системы<br />Частичный рефакторинг модулей ядра системы<br />Определение стратегии рефакторинга и выбор модулей<br />Завершение пятого спринта<br />Неделя №13 (старт шестого «идеального» спринта)<br />Цели: запуск идеального спринта<br />Планирование и старт шестого спринта<br />Анализируем и изменяем скоуп по релиз-бёрндауну<br />Неделя №14 (завершение «идеального» шестого спринта)<br />Цели: завершение идеального спринта<br />Завершение шестого спринта<br />Релиз продукта<br />Post-mortem релиза в рамках ретроспективы<br />Анализ бёрндауна релиза<br />