Планирование конструирования — PERT, CPM, оценки
Доступ к данным — Основы БД, SQL, конфигурации. Карта — о разделе.
Планирование — не "нарисовать Gantt и забыть"
Планирование конструирования — это не "красивая диаграмма для начальника". Это ответы на вопросы, без которых разработчик сидит в неопределённости — что кодировать завтра, что блокирует релиз, сколько времени заложить на интеграцию с банком.
Мини-словарь
| Термин | По-человечески |
|---|---|
| WBS | Дерево задач: от "релиз 1.0" до "написать JWT middleware" |
| Гантт | Календарь: кто что делает какие дни |
| CPM | Находит цепочку задач без запаса — задержка там сдвигает весь проект |
| PERT | Три оценки (оптимист/реалист/пессимист) для неизвестной задачи |
| Float (резерв) | Сколько можно задержать задачу без срыва дедлайна проекта |
| Velocity | Сколько story points команда реально закрывает за спринт |
| Planning Poker | Команда сравнивает сложность задач относительно друг друга |
На стадии конструирования план отвечает на четыре вопроса:
- Что кодировать — декомпозиция до модулей и задач (WBS).
- В каком порядке — зависимости между API, миграциями, интеграциями.
- Сколько времени — оценки с учётом неопределённости.
- Где узкое место — критический путь и буфер на баги/review (отладка, Git в команде).
Базовые оценки времени — Оценка трудозатрат; параметрические (COCOMO, Function Points) — 7-13/1. Здесь — сетевое планирование и связь с Agile-оценками.
Методы оценки длительности (PMBoK)
PMBoK (Project Management Body of Knowledge) перечисляет типовые способы оценки длительности работ — они применимы и к задачам конструирования в WBS:
| Метод | Суть | Когда на коде |
|---|---|---|
| Экспертная оценка | Опыт команды + история похожих проектов | "Интеграция с банком у нас занимала 2 недели" |
| Оценка по аналогам | Параметры прошлого проекта (срок, размер, сложность) | Новый CRUD-модуль "как каталог в прошлом году" |
| Параметрическая | Статистическая связь (LOC, story points, function points) | COCOMO, velocity × points |
| Оценка по трём точкам | O, M, P → формула PERT | Новая технология, внешний API |
| Анализ резервов | Буфер (%, дни) на неопределённость расписания | Резерв на review, баги, sick leave |
Анализ резервов — явное закладывание временных резервов (буферов) в план: в процентах от оценки задачи или в фиксированных днях. По мере уточнения проекта резерв используют, сокращают или снимают. На практике "неделя 8 как буфер" в примере релиза — тот же принцип.
Три разработчика по 40 часов параллельно дают 120 человеко-часов, но только 40 календарных при полной загрузке.
Gantt показывает календарь;
WBS-сумма — трудозатраты.
WBS — от проекта к задачам кодирования
Work Breakdown Structure — иерархия работ "сверху вниз": продукт → подсистемы → модули → листовые задачи, которые можно оценить и назначить.
Интернет-магазин (релиз 1.0)
├── Модуль Auth
│ ├── API login / refresh
│ ├── JWT middleware
│ ├── Миграция users
│ └── Unit-тесты auth
├── Модуль Catalog
│ ├── CRUD товаров
│ ├── Поиск и фильтры
│ └── Integration с Auth
├── Модуль Billing
│ ├── Платёжный адаптер
│ └── Webhook обработка
└── Инфраструктура
├── CI pipeline
└── Staging deploy
Правила хорошего WBS:
| Правило | Зачем |
|---|---|
| Лист оцениваем (часы, points) | Иначе план — декорация |
| У задачи один ответственный | Нет "все и никто" |
| Лист ≤ 1–2 недели работы одного человека | Иначе скрытые риски |
| Имена глагольные ("Реализовать…", "Покрыть тестами…") | Понятен результат |
На конструировании листья WBS часто совпадают с модулями из §2: граница задачи ≈ граница merge request.
Диаграмма Ганта
Диаграмма Ганта — календарная шкала: горизонтальные полоски = длительность задач; стрелки = зависимости "B после A".
| Элемент | Смысл |
|---|---|
| Полоска | Длительность задачи в календарных днях |
| Параллельные полоски | Ресурсы работают одновременно |
| Milestone (ромб) | "Alpha-сборка", "Заморозка API", "Code freeze" |
| Baseline | Зафиксированный план для сравнения с фактом |
Инструменты: MS Project, GanttProject, Jira Advanced Roadmaps, YouTrack, Notion timeline, GitLab milestones.
Ограничение Gantt: хорошо показывает когда, но слабо — логику зависимостей на больших графах. Для поиска критического пути используют сетевую диаграмму (CPM/PERT).
CPM — метод критического пути
Critical Path Method (CPM) строит ориентированный граф задач и находит самую длинную цепочку без резерва времени.
- Критический путь — последовательность, задержка любой задачи на которой сдвигает дедлайн проекта.
- Резерв (float, slack) — сколько можно задержать некритическую задачу без вреда для финиша.
Мини-пример с расчётом
Задачи (дни): A(3) → B(4) → D(2) и параллельно A(3) → C(5) → D(2).
B(4)
↗ ↘
Start → A(3) → D(2) → Finish
↘ ↗
C(5)
| Путь | Сумма | Критический? |
|---|---|---|
| A → B → D | 3 + 4 + 2 = 9 | Да |
| A → C → D | 3 + 5 + 2 = 10 | Да (длиннее!) |
Критический путь: A → C → D (10 дней). У B есть float = 10 − 9 = 1 день (можно начать на день позже или растянуть на день).
Forward / backward pass (для экзамена)
| Обозначение | Смысл |
|---|---|
| ES (Early Start) | Раньшее начало |
| EF (Early Finish) | ES + длительность |
| LS (Late Start) | Позднее начало без сдвига проекта |
| LF (Late Finish) | Позднее окончание |
| Float | LS − ES (или LF − EF) |
Для конструирования: критический путь часто проходит через ядро домена, интеграцию и миграции данных — их недооценка срывает релиз, даже если "мелочь по UI" готова раньше.
PERT — три оценки длительности
Program Evaluation and Review Technique — когда длительность неизвестна точно (новая технология, внешний API, сложный refactor).
| Оценка | Смысл |
|---|---|
| O (optimistic) | Минимум при удачном стечении |
| M (most likely) | Наиболее вероятная |
| P (pessimistic) | Максимум при проблемах |
Ожидаемая длительность (бета-распределение):
TE = (O + 4M + P) / 6
Стандартное отклонение:
σ = (P − O) / 6
Числовой пример
Задача "Интеграция с платёжным шлюзом":
| O | M | P |
|---|---|---|
| 3 дня | 5 дней | 12 дней |
TE = (3 + 4×5 + 12) / 6 = 35/6 ≈ 5,8 дня
σ = (12 − 3) / 6 = 1,5 дня
Как читать TE: вес 4 у "наиболее вероятной" оценки M — она сильнее влияет на результат. Широкий разброс O=3 и P=12 говорит о риске: закладывайте буфер в план (неделя 8 в примере релиза ниже).
σ — разброс: чем больше, тем неопределённее задача; на совещании стоит разбить её на spike "подключиться к sandbox банка" и отдельно "боевую интеграцию".
Та же формула — метод трёх точек в Оценка трудозатрат. PERT добавляет сетевой контекст — TE подставляют в узлы графа, затем ищут критический путь уже по ожидаемым, а не только детерминированным длительностям.
PERT — задача с высокой неопределённостью (первый раз с технологией).
Одна оценка M — типовой CRUD по шаблону.
Planning Poker — относительная сложность в Agile, потом перевод в часы через velocity.
Стратегии планирования конструирования
| Стратегия | Суть | Когда |
|---|---|---|
| Top-down | Срок фиксирован → режем scope / добавляем людей (осторожно: закон Брукса) | Контракт с дедлайном |
| Bottom-up | Сумма оценок WBS → календарь + параллелизм | Внутренний продукт |
| Critical chain | Буфер на цепочку, а не на каждую задачу | Много зависимостей |
| Rolling wave | Детально планируем ближайшие 2–4 недели, дальше — грубо | Agile, неясный хвост релиза |
| Milestone-driven | Жёсткие точки: "API freeze", "feature complete" | Инкременты + V-модель |
На практике гибрид: rolling wave внутри спринта + milestone на релиз + CPM для интеграционной недели.
Planning Poker и конструирование
Planning Poker — командная оценка относительной сложности (story points), не календарных дней. Связка с конструированием:
| Шаг | Действие |
|---|---|
| 1 | Story оценили в points (Poker) |
| 2 | Разработчик раскладывает на технические подзадачи (API, миграция, тесты) |
| 3 | Подзадачи суммируются в часы и сверяются с velocity команды |
| 4 | Если не влезает — режем story или выносим spike |
Spike (исследование) — отдельная задача с time-box, часто с PERT-оценкой (широкий разброс O/P).
Отличие от PERT: Poker сравнивает сложность ("эта story как прошлая X"); PERT — время одной задачи с разбросом.
Эффект привязки (anchoring)
Planning Poker снижает эффект привязки — если влиятельный участник первым называет "50 story points", остальные подсознательно тянутся к этому числу, даже чтобы "показать единство". В Poker оценки скрыты до вскрытия — каждый фиксирует своё мнение до группового давления. При большом расхождении "влиятельный" участник аргументирует выбор; команда пересматривает оценку по сути задачи, а не по авторитету. Техника — разновидность Wideband Delphi (итеративное согласование экспертов без публичного якоря).
Планирование тестирования параллельно (V-модель)
Тест-план не после кода — иначе V-модель только на бумаге.
| Фаза конструирования | Параллельно в QA |
|---|---|
| Детальный проект модуля | Черновик модульных кейсов |
| Написание unit-тестов (dev) | Review сценариев на "дыры" |
| Сборка инкремента / alpha | Integration, smoke, regression |
| Feature freeze | System, нагрузка, security |
| Release candidate | UAT, приёмка |
См. тест-план, ПМИ, пирамиду тестов.
Разбор — релиз интернет-магазина за 8 недель
Команда — 2 backend, 1 frontend, 1 QA. Billing — интеграция с банком (PERT — O=5, M=8, P=15 → TE≈9 дней) и критический путь.
| Неделя | Конструирование | Тест / QA | Риск |
|---|---|---|---|
| 1 | Каркас CI, Auth API | Test plan Auth | — |
| 2 | Auth frontend, JWT | Unit + smoke Auth | — |
| 3–4 | Catalog API + UI | Integration catalog | Параллельно с Auth hardening |
| 5 | Billing (критический путь) | Regression 1–4 | Задержка здесь = срыв всего |
| 6 | NFR: кэш, логи, rate limit | Load smoke | — |
| 7 | Документация API, tag release | UAT сценарии | — |
| 8 | Буфер / hotfix | Приёмка | Без буфера неделя 8 = 0 |
Урок: если Billing сдвинулся на +1 неделю, без недели 8 как буфера срывается приёмка. Float у некритичных задач (например, "улучшить фильтры") можно жертвовать, чтобы подтянуть Billing.
Связь с управлением конфигурацией и релизом
План конструирования включает точки заморозки:
- API freeze — контракты не меняются без versioning.
- Code freeze — только bugfix в релизную ветку.
- SCM tag — воспроизводимая сборка.
Подробнее — 7-13/3 (SCM, релизы).
Типичные ошибки
- Нет критического пути — оптимизируют некритичные задачи (иконки), пока горит интеграция.
- 100% загрузка людей — нет буфера на review, баги, sick leave.
- Тест "в конце" — regression за два дня перед prod.
- Один Gantt на год без обновления — план расходится с реальностью после первого change request.
- Points без декомпозиции — story "8 points" без tech tasks; в спринте внезапно "не успели миграцию".
Частые вопросы на экзамене
Чем CPM отличается от Gantt?
Gantt — календарное представление; CPM — логика зависимостей и поиск критического пути (часто оба используют вместе).
Что такое float?
Запас времени у некритической задачи; у критической float = 0.
Зачем Planning Poker, если есть PERT?
Poker — относительная оценка в команде Agile; PERT — абсолютное время с разбросом для отдельных рискованных задач.
Рекомендую читать дальше
| Тема | Материал |
|---|---|
| Модели ЖЦ | Модели жизненного цикла для конструирования |
| COCOMO, PM | 7-13/1 |
| SCM, релизы | 7-13/3 |
| Оценка в команде | Оценка трудозатрат |