Сергій Поволяшко. Чому розмір має значення? - доповідь з SPMConf

Публікуємо статтю на підставі доповіді Сергія Поволяшко (Харків, Україна) з конференції менеджерів проектів в ІТ Software Project Management Conference

Почнемо з аналогії. Ви замовляєте нові меблі, хочете, щоб було скільки-то тумбочок, шафок, поличок. Певних розмірів, з певних матеріалів, у певний термін, за певну суму. І вам все одно, скільки людина, якої кваліфікації, якими інструментами і в який час доби це будуть робити, правда?
Важливий результат — кількість, матеріали та розміри всіх компонентів.
Розглянемо в моїй доповіді наступні моменти:
— що таке розмір і чому він важливий;
— методики його визначення;
— коли має сенс визначати і застосовувати;
— модель розміру;
— для чого корисний розмір;

Ми не будемо говорити про наукових методиках, так як про них можна почитати і без мене, поговоримо про практичне застосування. Я б хотів вести доповідь в інтерактивному форматі, щоб ми разом оцінювали ситуацію. Отже, почнемо.




Для відповіді на це питання, ви співвідносьте його з якоюсь базовою величиною. Наприклад, історія, очікування замовника, кількість співробітників, критичність багів, стадія розробки програми. Про них і поговоримо більш докладно.



От зверніть увагу на дані картинки, як ви думаєте, що у цих схожих процесах дійсно важливо? Нам важливий результат, для конкретного випадку він вимірюється в кубометрах. Наприклад, ви замовляєте фундамент для своєї дачі. Природно, виходячи з ваших ресурсів, у вас буде один з двох варіантів, але, в кінцевому підсумку, вам важливо, щоб було вирито певну кількість кубометрів. Ми отримуємо перший висновок, в будь-якій роботі, стартапі, проект важливий результат, отже,Результат (розмір результату) — первинний, спосіб досягнення результату — вторинний.
Давайте знову глянемо на схожі картинки і знайдемо ряд важливих критеріїв і на них.



Визначивши такі важливі критерії, давайте поглянемо на формулу. Вона досить умовна і потрібна для розуміння.

Кількість = (продуктивність * розмір) / якість
, де Розмір, ще раз підкреслю, умовна одиниця обсягу роботи.

Чим гірше робимо, тим більше виправляємо — яскравий приклад цієї формули.

Це все плавне прелюдія до того, щоб поговорити про методики одиницях і з точки зору розміру.



Першим пунктом йде найдавніша і найбільш неправильна методика — рядка коду, це всім зрозуміло чому. Потім йде також стара методика — функціональні точки, більше наукові, і якщо чесно, до недавнього часу я не зустрічав людини, який би користувався ним. Не буду вдаватися в подробиці, тільки зауважу, що вони засновані на відмінності з точки зору користувачів системи. В кінці я надам слайд з посиланнями на більш докладну інформацію про порушені в доповіді темах.
Наступний пункт — use case points. Це теж досить замудренная методика, але, за моїми відчуттями, вона ближче до життя, ближчий до реальності. Вона заснована на діаграмах Використання. Якщо в специфікації написано опис тест-кейсів, то перетворю складність тест-кейсів, додаючи складності поправочного коефіцієнта (є навіть спеціальний софт, який дозволяє це зробити), теж можна отримати case points, які теж приводять до людино-годинах. Story points розташовуються внизу. Чому? Тому що Story points можуть відрізнятися всередині проекту і всередині команди, в залежності від обсягів проекту до настрою команди і формат її роботи.
І власне, останній пункт — Специфічні одиниці і методики, осмислено відображають обсяг робіт або його істотну частину, з приводу якої у мене в кінці презентації буде опис. Специфічні означають, що є певний рід діяльності, де є стандартні типові операції, які можна вивести з урахуванням розміру проекту, про який я буду говорити пізніше.
Добре, а тепер давайте виділимо чому важливий розмір?
  • Відображення реального обсягу робіт;
  • Абстрагування від рівня знань і досвіду виконавців(всі співробітник виконують завдання за різний час);
  • Використання у метриках для оцінки ефективності (якості, кількості, SLA, KPI (треба враховувати і розмір, без нього не працює));
  • Постановка і контроль очікувань «віддачі» (припустимо, всі знають, що раз в тиждень від команди тетсирования чекають тест-репорт раз в тиждень);
  • Подальший розрахунок трудовитрат, термінів;
  • Прогнозування часу, строків, якості;
  • Використання в Моделі Розміру (всі ці function points, user case points, story points і т. д. і складають такі моделі розміру)


Без такого «ваги», який дають критерії та метрики, сам по собі розмір теж не має значення. Тому потрібно розуміти, в яких випадках розмір потрібен. Коротко можна вказати на слайді.



Прикладами можуть стати регрессионное тестування, оцінка кількості співробітників в команді, надання проекту бюджету і т. д. Якщо ми говоримо про те, що розмір потрібен, значить, існують ситуації, коли розмір не важливий. Отже, для справедливості, давайте їх зазначимо.



З урахуванням нових знань давайте перейдемо до кейсу з реального життя, який зробили хлопці в нашому «Стратоплане», заздалегідь хочу висловити їм свою подяку, що вони це зробили. У чому полягає кейс? У чому полягає робота?

Є певний продукт, у якого є ядро, таке симпатичне хороше ядро, на цей продукт є кінцевий замовники, які хочуть його конфігурувати. Сам по собі продукт включає високо конфигурированное ядро, на яке можна написати форми, поля і тд.



Кожен замовник приходить і просить, щоб це ядро було налаштовано під певні потреби бізнес-процесу. Що вони під цим розуміють? Наприклад, додатково конфігурують форми екрану, бізнес-логіка, звіти, запити і т. д. Це ядро виходить певною базою, до якої застосовуються деякі конфігураційні інструментарії і отримують певний продукт. Хоч це і звучить складно, це досить просто.
В результаті ця конфігурація розгортається на це ядро. Повторюся, що необхідність у такому продукті виникає, коли діяльність типова і часто повторюється, є дискретний елемент. Подумали, зібрали дані, скільки людино-годин займає той чи інший інструмент сконфігурованої логіки і що вийшло?
Вийшла така модель Розміру, якої достатньо для попередньої оцінки. Вона повністю передає всю ідею.



У першій рядку описані, які дискретні елементи у нас є: екранні форми, звіти, бізнес-об'єкти і т. д. Це кількість умовних одиниць в стовпцях, «х2» і «х3» — це те, у скільки разів збільшиться час для такого дискретного елемента і, отже, кількість кейсів. В залежності від специфікації беруться дані і вважаються, складаючи чистий розмір. Потім йде Калібрування, де враховуються вимоги, де 1 — «добре», а 3 — ні. Враховуємо, були минулі напрацювання, потім наскільки високий рівень виконавця. Потім всі перемножується і виходить калібрований розмір. І взявши для прикладу, 1 од. за 2 людини-години, ми отримуємо кінцевий критерій, що враховує особливості для декількох специфікацій. У реальному житті у цій моделі більше коефіцієнтів, але для наочності моделі досить і цих. Модель Розміру хороша, коли дозволяє терміново надати дані щодо термінів для замовника, наприклад.

Як і обіцяв корисні посилання, які могли бути корисні для більш глибокого вивчення теми:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.