Deadline management

Preview:

Citation preview

Что ответить заказчику на вопрос: «Когда же все будет готово?»

Евгений Шеретов

Лидер проекта в компании Ciklum, Днепропетровск

Сертифицированый ScrumMaster

Более 6-ти лет опыта разработки в IT

3 года применения Scrum/Agile методологий

Skype: sheretov_ev

Email: she@ciklum.net

Почему я?

Поделиться опытом взаимодействия с заказчиком

Показать свое видение, как удовлетворить требования заказчика

Вы узнаете:

Как сохранить доверие заказчика;

Как научиться общаться с ним на одном языке.

Научитесь:

Расчитывать дедлайн проекта;

Отслеживать и реагировать на изменения.

А также:

Вы увидете, как эффективно визуализировать

результаты работы команды над продуктом.

Когда будет сделан продукт?

И нужно ему совсем немного:

Он хочет, чтобы его похвалили

Он хочет, чтобы его труд оценили

Он хочет знать, что сказать своему начальству

А без вас он никак!

Заказчика, ожидающего ответа...

Кучу требований:

Шаг 1 – Выделяем User Stories

Шаг 2 – Оцениваем User Stories

Шаг 3 – Выставляем приоритеты

Шаг 4 - Дробим User Stories спринта

Шаг 5 – Рассчитываем скорость

Шаг 6 – Прогнозируем Release scope

Шаг 7 – Определяем ежедневные усилия

Шаг 8 – Прогнозируем дату релиза

Шаг 9 – Визуализируем процесс

Шаг 10 – Реагируем на изменения

В роли ... Я хочу ..... Потому, что ....

Разбиваем спецификацию на User Stories

Сохраняем соотношения между спецификацией и User Stories

Получаем набор User Stories :

Сортируем User Stories по сложности

Даем оценку User Stories в юнитах (Джоулях)

Оцениваем сложность и объем User Stories

Оцениваем риски выполнения User Stories

Даем ПИ для просмотра и определения приоритетов Владельцу Продукта

Наполняем Спринт Беклог

Разбиваем ПИ спринта на задачи

Задачи не должны превышать 8-10 часов

Прогнозируем скорость команды:

Яблоко – 5 ю = 15 ч

Черника – 3 ю = 6 ч

Гранат – 21 ю = 27 ч

Сумма:

29 ю = 48 ч

Скорость:

1 ю – 1.65 ч

Зависит от:

◦ Процесса оценки задач

◦ Скорости каждого члена команды

Будьте готовы к тому, что скорость постоянно меняется:

◦ Состав команды

◦ Тип задач

◦ Мотивация команды

◦ Опыт команды

Оценка всех User Stories релиза

3 + 5 +21 + 2 + 13 = 44 ю

Рассчитываем весь Release Scope, учитывая скорость команды:

44 * 1.65 = 72 ч

Прогнозируем оставшиеся User Stories в часах:

◦ Клубники – 2 ю * 1.65 = 3 ч

◦ Бананы – 13 ю * 1.65 = 22 ч

Определяем ежедневные усилия команды

Прогнозируем Burndown Chart

Ежедневная вытяжка информации по всем ПИ релиза

Управляем ограничениями ◦ Время/Дедлайн

◦ Скоуп работы

◦ Ресурсы

Шаг 1 – Выделяем User Stories

Шаг 2 – Оцениваем User Stories

Шаг 3 – Выставляем приоритеты

Шаг 4 - Дробим User Stories спринта

Шаг 5 – Рассчитываем скорость

Шаг 6 – Прогнозируем скоуп релиза

Шаг 7 – Рассчитываем усилия команды

Шаг 8 – Прогнозируем дату релиза

Шаг 9 – Визуализируем процесс

Шаг 10 – Реагируем на изменения

Визуализация компенсирует профессионализм разработчиков.

Предварительная

оценка НЕ будет

меняться в течении

проекта.

Спецификация не будет меняться.

Визуализируйте процесс, покажите команде

Используйте ключевые слова в названии User Stories

Ссылайтесь на разделы спецификации каждой User Stories

Используйте Security Buffer для переработок, выясняйте причины.

Оценивайте User Stories всей командой

Празднуйте успех релиза!!!

1 – Как выполнять оценку продукта, основываясь на спецификации

2 – Как рассчитывать дедлайн релиза

3 – Как визуализировать процесс разработки

4 – Как реагировать на изменения

5 – Как удовлетворить ожидания заказчика

Евгений Шеретов

Email: she@ciklum.net, sheretovev@gmail.com.

Skype: sheretov_ev.

Recommended