Книга Гибкое управление проектами и продуктами - Борис Вольфсон
Шрифт:
Интервал:
Закладка:
1. Исследование продукта:
• выявление ролей и персонажей по проектам;
• построение карт историй;
• прототипирование основных интерфейсов;
• сессия для выявления основных рисков и выработки контрмер.
2. Создание высокоуровневой архитектуры продукта:
• выбор платформы реализации;
• диаграмма предметной области/высокоуровневая диаграмма классов.
Цели: отработать процессы по запуску спринта и проведению Scrum of Scrum.
1. Старт первого спринта с командами:
• проведение планирования спринта и разбиение user story на задачи;
• проведение покер-планирования для оценки user story.
2. Scrum of Scrum:
• определение сроков проведения Scrum of Scrum;
• проведение первого Scrum of Scrum;
• отработка механизма эскалации проблем;
• отработка механизма синхронизации деятельности команд.
Цели: отработать завершение спринта и провести ретроспективу на основе качественных показателей.
1. Проведение демонстрации и получение обратной связи.
2. Ретроспектива (что было сделано хорошо, что было сделано плохо, список улучшений): определение скорости команды эмпирическим путем.
Цели: отработать старт спринта и планирования на основе количественных показателей, начать внедрение базовых практик экстремального программирования.
1. Планирование и старт второго спринта: планируем, исходя из скорости предыдущего спринта.
2. Тренинг и мастер-класс по практикам экстремального программирования:
• внедрение системы непрерывной интеграции – полная сборка продукта происходит автоматически и непрерывно;
• выработка и внедрение стандартов кодирования.
Цели: отработать завершение спринта и провести ретроспективу на основе количественных показателей, используя инструменты бережливого производства.
1. Изучение практики инструментов бережливого производства (Lean):
• виды потерь при производстве;
• Value Stream Mapping для текущего процесса;
• пять «почему».
2. Демонстрация.
3. Ретроспектива с применением инструментов бережливого производства:
• разбор причин опоздания по невыполненным задачам;
• пять «почему» по каждому дефекту.
Цели: отработать старт предрелизного спринта и понять, как в будущем избежать таких «стабилизационных» спринтов, начать активно использовать автоматизированное тестирование.
1. Планирование и старт третьего спринта:
• особое внимание уделяем недоделанным историям пользователей, которые не успели выполнить из-за ограничения по скорости команды;
• рассматриваем возможность снизить скорость команды, чтобы успеть все к релизу.
2. Внедрение модульных и приемочных тестов:
• проведение тренинга по приемочным тестам;
• покрытие 5 % основного бизнес-функционала продукта приемочными тестами;
• проведение тренинга по модульным тестам;
• покрытие 50 % кода, реализованного за спринт, модульными тестами.
3. Внедрение рефакторинга.
Цели: сделать первый Agile-релиз продукта и выработать серьезные меры по улучшению процессов на основе информации, полученной за три спринта.
1. Кайзен-сессия на ретроспективе: диаграмма Исикавы по глобальным проблемам проекта и выработка мер по устранению проблем.
2. Завершение третьего спринта: первый релиз продукта – обязательно, чтобы конечные пользователи его попробовали и предоставили обратную связь.
3. Post-mortem релиза в рамках ретроспективы.
Цели: научиться планировать релиз и управлять им.
1. Планирование релиза:
• начало ведения диаграммы burndown-релиза;
• отбор владельцем продукта пользовательских историй для релиза;
• возможная переоценка журнала пожеланий командой «на пальцах».
2. Внедрение (трех-) четырехзвенной архитектуры.
3. Планирование и старт четвертого спринта: скорость команды считаем эмпирически по трем предыдущим спринтам.
Цель: внедрение статистического управления качеством.
1. Завершение четвертого спринта.
2. Внедрение основ статистического управления качеством:
• статистика по дефектам;
• диаграмма Парето по модулям;
• контрольные карты Шухарта.
Цель: внедрение канбана для команды поддержки или основной команды.
1. Планирование и старт пятого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.
2. Переход на Scrumban команды поддержки или основной команды:
• тренинг по канбан (четыре часа) для членов команды;
• отказ от жестких итераций.
3. Внедрение разработки через тестирование:
• тренинг и мастер-класс по разработке через тестирование;
• покрытие тестами модулей ядра системы (не менее 50 % строк кода).
Цель: улучшение внутреннего качества ядра системы.
1. Частичный рефакторинг модулей ядра системы: определение стратегии рефакторинга и выбор модулей.
2. Завершение пятого спринта.
Цель: запуск «идеального» спринта.
1. Планирование и старт шестого спринта: анализируем и изменяем scope по диаграмме сгорания релиза.