Расширенная диаграмма выгорания, недельный Статус и SDD-конвейер производства агентов
Расширенная диаграмма выгорания и недельный «Статус»
В «Гелиосе» разработка агента представляется как наблюдаемый полуавтоматизированный производственный поток. Его управленческий экран одновременно показывает стадии, недельные результаты, первоначальный и добавленный объём работ, а также статистический прогноз даты завершения. ^telegram-helios-extended-burndown-and-weekly-status-2026-09-12
Управленческий инструмент
Расширенная диаграмма выгорания работ — отчетный экран проекта агента. Она должна отвечать не только на вопрос «сколько первоначальной работы осталось», но и показывать:
- исходный объём заказа;
- выполненный и оставшийся объём;
- работу, добавленную после начала заказа;
- текущую стадию производства агента;
- результаты недельных спринтов;
- ручные ожидания: доступы, разрешения, согласования и тестирование;
- прогноз срока получения финального результата на основании фактической скорости и накопленной статистики.
Инструмент сохраняет принятое внутри «Гелиоса» название «расширенная диаграмма выгорания», но аналитически является гибридом:
| Представление | Что показывает |
|---|---|
| Burndown | Как уменьшается оставшийся объём работ |
| Burnup | Как растёт выполненный объём и меняется общий scope |
| Cumulative flow | Где копятся задачи и возникают очереди по стадиям |
| Forecast | Вероятностный коридор срока завершения |
Элементы burnup принципиальны: обычный burndown плохо объясняет добавленную работу и может создавать ложное впечатление падения производительности команды.
Недельный ритм и документ «Статус»
Спринт длится одну неделю и формируется из трёх входов:
1. актуальных данных проекта; 2. действующей спецификации; 3. обратной связи заказчика.
Результатом каждого спринта становится «Статус» — внутренний публичный отчётный документ компании «Синергия». Публичность здесь означает доступность участникам и пользователям корпоративной среды, имеющим право видеть проект; она не подразумевает публикацию конфиденциальных сведений во внешнем интернете.
«Статус» даёт обзор произошедшего за период:
- что планировалось и что завершено;
- что изменилось в спецификации и объёме;
- какая новая работа добавлена и почему;
- какие проверки и ревью пройдены;
- что заблокировано людьми, доступами или регламентами;
- какой прогноз срока актуален;
- что планируется на следующую неделю.
Субагент формирования «Статуса»
Отдельный отчетный субагент автоматически собирает события спринта и выпускает дайджест-summary-review по корпоративному стандарту. Он не должен сочинять управленческую картину из свободного текста: источниками служат версионируемые спецификации, планы, задачи, результаты тестов, решения заказчика и журнал изменений.
Минимальные проверки субагента:
- все утверждения связаны с событиями или артефактами;
- исходный и добавленный scope разделены;
- блокировки имеют владельца и возраст;
- прогноз содержит метод расчёта и диапазон неопределённости;
- сведения о доступах и клиентах проходят корпоративную политику видимости;
- изменения требований трассируются до обратной связи заказчика.
SDD-конвейер производства агента
| Стадия | Артефакт или результат | Основной исполнитель |
|---|---|---|
| 1. Intake | Набор данных и итоговый summary заказчика | Инициирующий агент + человек |
| 2. SDD | Формализованные спецификации и критерии приёмки | Агент спецификации + reviewer |
| 3. Planning | План реализации и зависимости | Планирующий агент |
| 4. Decomposition | Исполнимые задачи, распределённые между субагентами | Оркестратор |
| 5. Implementation | Код, конфигурации, интеграции и документы | Специализированные субагенты |
| 6. Review | Независимая проверка реализации и соответствия SDD | Review-агент |
| 7. Testing | Результаты испытаний и обратная связь | Наладчик или заказчик |
| 8. Status | Недельный публичный дайджест и обновлённый прогноз | Статус-субагент |
Каждая задача должна сохранять трассировку: данные заказчика → спецификация → план → задача → реализация → тест → решение/статус. Это связывает производство агента с Everything as Code и превращает историю разработки в воспроизводимое кифу «Партии компании».
Ручной контур и человеческие ограничения
Наиболее ручная часть потока — тестирование и организационный ввод в эксплуатацию. Есть два режима:
- наладочный: тестирование выполняет Павел как наладчик без привлечения заказчика;
- заказческий: проверку и приёмку выполняет заказчик.
Скорость этого участка определяется не только технической сложностью. Отдельно учитываются:
- получение учетных записей и доступов;
- разрешения на системы и данные;
- security/compliance-согласования;
- ожидание решений и обратной связи людей;
- бюрократические процедуры компании.
Эти ожидания нельзя смешивать с активным временем разработки. На диаграмме они должны отображаться отдельным классом блокировок — иначе статистический прогноз будет систематически ошибочным.
Минимальная модель данных
Для первой реализации достаточно событийной модели:
| Поле | Назначение |
|---|---|
sprint_id, period | Недельный отчетный интервал |
stage | Текущая стадия SDD-конвейера |
scope_origin | Первоначально заказанный объём |
scope_added | Добавленная после старта работа |
remaining, completed | Остаток и выполненный объём |
change_source | Источник изменения: заказчик, тест, риск, регламент |
blocked_reason, blocked_since, owner | Человеческая или техническая блокировка |
evidence_uri | Ссылка на спецификацию, задачу, тест или решение |
forecast_p50, forecast_p85 | Медианный и консервативный прогноз завершения |
Единицей объёма на первом этапе может быть число атомарных задач. После накопления истории целесообразно перейти к throughput/cycle-time и вероятностному прогнозированию методом Monte Carlo, не подменяя статистику субъективными story points.
Ключевой ценный результат
Главная ценность экрана — не декоративная отчётность, а объяснимый прогноз срока изготовления агента, который учитывает:
- фактическую производительность полуавтоматизированного конвейера;
- изменения объёма после заказа;
- распределение задач между субагентами;
- результаты ревью и тестирования;
- задержки, связанные с участием людей и корпоративной бюрократией.
Концепция расширяет Executive Dashboard «Гелиоса» от наблюдения за уже внедрёнными агентами к прозрачному наблюдению за самим процессом их производства.