Приклад звіту Digital Polygraph
Ця сторінка показує не внутрішню механіку калькулятора, а його практичний результат: що саме отримує користувач після завершення оцінювання і як читати сформований звіт.
Нижче наведено реальний двосторінковий приклад звіту, автоматично сформованого Digital Polygraph за введеними даними. У ньому зафіксовано обраний маршрут створення продукту, розподіл трудомісткості між етапами, тривалість робіт за поточного складу команди, інженерні горизонти поставки та опис обраних користувачем параметрів, за якими виконано розрахунок
Перша сторінка: маршрут, трудомісткість, тривалість і команда
Модель поставки
Верхня частина звіту показує який маршрут створення продукту було обрано для оцінювання. У цьому прикладі використано повний цикл:
ТЗ → ЕП → ТП → РП → ВП
Той самий маршрут одразу перекладено мовою продуктових віх: Виявлення вимог → Прототип → MVP → Реліз-кандидат → Експлуатація. Тому читач бачить не лише назви інженерних стадій, а й продуктову зрілість, до якої приводить кожна з них.
Трудомісткість за етапами
Перший графік показує, де саме зосереджена інженерна робота. Загальна трудомісткість у цьому прикладі становить 2484 людино-дні, але звіт не обмежується одним підсумковим числом: він показує внесок окремих стадій у загальний обсяг робіт.
Тривалість за поточного складу команди
Другий графік переводить трудомісткість у календарний горизонт з урахуванням чисельності команди на кожній стадії. У цьому прикладі розраховано:
Команда за етапами в цьому прикладі: ТЗ=3, ЕП=4, ТП=4, РП=10, ВП=6 FTE. FTE означає еквівалент повної зайнятості одного виконавця.
Трудомісткість відповідає на питання «скільки роботи?». Тривалість і склад команди відповідають на питання «скільки часу і якими ресурсами?».
Друга сторінка: інженерні горизонти і вихідні параметри
Розраховані інженерні горизонти поставки
Головний блок другої сторінки показує коли продукт досягає кожної контрольної віхи і який розмір команди передбачено на відповідній стадії. Час у таблиці є накопиченим від початку проєкту.
| Горизонт | Цільова віха | Час від старту | Команда |
|---|---|---|---|
| H0 | Виявлення вимог | 0,39 року (~91 робочий день) | 3 FTE |
| H1 | Прототип | 0,61 року (~144 робочих дні) | 4 FTE |
| H2 | MVP | 0,84 року (~198 робочих днів) | 4 FTE |
| H3 | Реліз-кандидат | 1,39 року (~327 робочих днів) | 10 FTE |
| H4 | Експлуатація | 1,74 року (~408 робочих днів) | 6 FTE |
Це перетворює загальну оцінку на послідовність перевірюваних проміжних фінішів. Замість одного далекого «релізу колись» з'являється маршрут, на якому видно, коли очікується Prototype, MVP, Release Candidate і готовність до експлуатації.
Що саме було оцінено
Нижня частина другої сторінки зберігає контекст розрахунку. Це важливо: число трудомісткості не повинно існувати окремо від опису продукту, для якого воно отримане.
У прикладі звіт фіксує, зокрема:
- обраний тип комп'ютера;
- обраний функціональний обсяг;
- технічну складність;
- архітектурну складність;
- інноваційність програмного забезпечення;
- частку використання стандартного програмного забезпечення;
- обрану схему розробки.
Таким чином, звіт зберігає разом результат оцінювання і опис умов, за яких цей результат було отримано. Він не розкриває внутрішню механіку розрахунку, але дозволяє зрозуміти, який саме продукт і який маршрут оцінювалися.
Фіксовані віхи, гнучке виконання
Інженерні стадії у звіті не означають, що команда зобов'язана виконувати роботу як жорсткий каскадний процес. Користувач обирає маршрут: скільки стадій входить до нього, які саме стадії потрібні та до якої продуктової цілі вони мають привести.
Після вибору маршруту кожна інженерна стадія задає рамку і вимірюваний проміжний фініш. А вже всередині цієї рамки команда може організовувати роботу за Scrum, Agile, Kanban або іншою методологією: спринтами, backlog'ом, planning poker, власним ритмом планування та перегляду результатів.
Маршрут обирається. Віхи фіксуються. Рух залишається agile.
Тому інженерна оцінка і Scrum не суперечать одна одній. Вони працюють на різних рівнях: звіт фіксує куди і до якого моменту має прийти продукт, а методологія команди визначає як саме організувати рух усередині цього відрізка.
Що можна прочитати з одного звіту
Звіт Digital Polygraph дає можливість відповісти на конкретні питання про майбутній продукт:
- Що саме оцінювалося? — функціональний обсяг і характеристики продукту збережені у звіті.
- Який маршрут обрано? — видно набір інженерних стадій і продуктових віх.
- Скільки роботи потрібно? — показано трудомісткість загалом і за окремими етапами.
- Скільки часу це займає? — розраховано тривалість за поточного складу команди.
- Яка команда потрібна? — для кожної стадії вказано FTE.
- Коли з'явиться Prototype, MVP, Release Candidate і Production? — це показують горизонти H0-H4.
Отримайте звіт для свого продукту
Вище показано обидві сторінки реального прикладу звіту. Щоб отримати такий самий структурований результат для власного програмного продукту, пройдіть оцінювання Digital Polygraph.
Про принципи, на яких побудовано структурний опис продукту, — у статті «Принципи внутрішньої будови калькулятора трудомісткості». Про перетворення трудомісткості на строки й план команди — у статті «Інженерний метод управління строками поставки ПЗ».