Deadline management
-
Upload
eugene-sheretov -
Category
Business
-
view
737 -
download
0
description
Transcript of Deadline management
Что ответить заказчику на вопрос: «Когда же все будет готово?»
Евгений Шеретов
Лидер проекта в компании Ciklum, Днепропетровск
Сертифицированый ScrumMaster
Более 6-ти лет опыта разработки в IT
3 года применения Scrum/Agile методологий
Skype: sheretov_ev
Email: [email protected]
Почему я?
Поделиться опытом взаимодействия с заказчиком
Показать свое видение, как удовлетворить требования заказчика
Вы узнаете:
Как сохранить доверие заказчика;
Как научиться общаться с ним на одном языке.
Научитесь:
Расчитывать дедлайн проекта;
Отслеживать и реагировать на изменения.
А также:
Вы увидете, как эффективно визуализировать
результаты работы команды над продуктом.
Когда будет сделан продукт?
И нужно ему совсем немного:
Он хочет, чтобы его похвалили
Он хочет, чтобы его труд оценили
Он хочет знать, что сказать своему начальству
А без вас он никак!
Заказчика, ожидающего ответа...
Кучу требований:
Шаг 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 – Как удовлетворить ожидания заказчика