Embed Size (px)
DESCRIPTION
Михаил Ганчиков -
Citation preview
Think Results.
ПЛАНИРОВАНИЕ И ЗАПУСК ПРОЕКТА ПРИ НУЛЕВОЙ ВИДИМОСТИ –
ПРАКТИЧЕСКИЙ ОПЫТМихаил Ганчиков, руководитель проекта
First Line Software 2011
2
О ЧЁМ ЭТА ПРЕЗЕНТАЦИЯ?
■ Нулевая видимость – это когда о проекте неизвестно ничего, кроме сроков ...и требования выполнить все требования
■ Есть масса способов избежать такой ситуации но мы не будем их обсуждать
■ Что делать, если не удалось избежать? управлять бюджетом
3
СОДЕРЖАНИЕ
■ 1. Оценка проекта, планирование бюджета и роста команды
■ 2. Работа с требованиями и отслеживание изменений
■ 3. Контроль за состоянием проекта, внесение корректировок
■ 4. Недостатки подхода■ 5. Полученные результаты и выводы
4
1. АНАЛИЗ И ОЦЕНКА ТРЕБОВАНИЙ
■ Трата времени на сбор требований может не дать желаемого результата
■ Для старта проекта достаточно понимать функционал на концептуальном уровне и иметь несколько детализированных историй
■ Оценка историй относительно друг друга позволяет абстрагироваться от человеко-дней
5
ПРОБЛЕМЫ И РЕШЕНИЯ
■ Пробелы в требованиях заполняются предположениями
команды■ Неясность технической реализации
определяет степень риска для каждой истории
риски влияют на длительность проекта
6
ОЦЕНКА ПРОЕКТА■ Общий объём работ:
, где St – история, M – общее кол-во историй, Risk –
коэффициент риска
■ Проектная норма риска (SP в день):
N𝑃𝑒𝑟𝑠𝑜𝑛 𝐷𝑎𝑦𝑠 = Story PointsSt ∗ RiskSt𝑀
𝑆𝑡=0
Ratio = σStory PointsN𝑃𝑒𝑟𝑠𝑜𝑛 𝐷𝑎𝑦𝑠
7
ПЛАНИРОВАНИЕ РОСТА КОМАНДЫ
■ Наличие полной команды в начале проекта может замедлить ход и
демотивировать людей■ Строительство команды
лучше вести итеративно, наращивая ядро вокруг lead’ов и senior’ов
8
ПРОИЗВОДИТЕЛЬНОСТЬ КОМАНДЫ
■ Лишь часть команды влияет на её производительность
■ При росте числа людей сокращается производительность ядра
■ Новые члены команды не могут работать с той же скоростью, что и все
остальные
9
ПЛАН ВЫПОЛНЕНИЯ РАБОТ■ Плановая норма на sprint (Target burn-up):
, где N – “производящая” часть команды
17/0
6/11
08/0
7/11
29/0
7/11
19/0
8/11
09/0
9/11
30/0
9/11
21/1
0/11
11/1
1/11
0100200300400500600700
Actual Scope, SP
Weeks
Stor
y Poi
ntsPRsQJhFsYlhDathLnMPqDc
S𝑆𝑡𝑜𝑟𝑦 𝑃𝑜𝑖𝑛𝑡𝑠 = NDevelopers ∗Ratio
10
2. РАБОТА С ТРЕБОВАНИЯМИ
■ Technical Product Owner ищет простые решения формулироует технические задачи для
команды анализирует результаты приёмки и
тестирования заказчиком определяет изменения (change requests)
функционала
11
РАБОТА С ТРЕБОВАНИЯМИ - 2
■ Команда может помочь TPO в поиске технического решения выполненяя исследовательские задачи
■ Product Owner должен следить за приоритезацией историй в backlog’е и помнить о фиксированном количестве story
points, которые может сделать команда
12
3. КОНТРОЛЬ СОСТОЯНИЯ ПРОЕКТА■ Анализ состояния проекта по 3
параметрам (story points): плановая норма на спринт (Target
burn-up) фактический объём выполненных
историй (Completed scope) общий объём product backlog’а
(Actual scope)
13
КОНТРОЛЬ СОСТОЯНИЯ ПРОЕКТА - 2
17/0
6/11
08/0
7/11
29/0
7/11
19/0
8/11
09/0
9/11
30/0
9/11
21/1
0/11
11/1
1/11
0
100
200
300
400
500
600
700
Completed Scope, SP Completed Scope Extrapolation, SPActual Scope, SP Planned Scope, SP
Week
Stor
y Poi
nts
PRsQJhFsYlhDathLnMPqDc
14
ЧТО ДАЛЬШЕ?
■ Почему нужна переоценка бэклога в середине проекта? появление новых историй – change request’ов детализация требований для существующих
историй может повлиять на их оценку полученные знания о предметной области
позволяют сделать оценку более точной■ В случае роста бэклога – эскалировать
руководству
15
4. НЕДОСТАТКИ ПОДХОДА
■ Снижение производительности■ Снижение качества продукта
0 1 2 3 4 5 6 70
0.2
0.4
0.6
0.8
1
1.2
1.4
Ratio (bugs/SP)
16
СПОСОБЫ БОРЬБЫ ЗА КАЧЕСТВО
■ TDD (test driven development)■ Автоматизированное регресс-тестирование■ Acceptance тестирование на стороне
заказчика cоставление сценариев на основе
acceptance-тестов
17
5. ВЫВОДЫ И РЕЗУЛЬТАТЫ
■ Закладка рисков в оценкузалог того, что проект не останется без запаса по времени
■ Факторы роста команды, нагрузки на ключевых игроков
должны учитываться при расчете объема работ
■ Работа с требованиями должна продолжаться до конца проекта
■ Мониторинг плановых и фактических показателейпозволяет не упустить момент, когда нужно просить
заказчика остановиться и пересмотреть требования
