Гибкое управление проектами и продуктами - Борис Вольфсон

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 по диаграмме сгорания релиза.