глава 12

Глава 12. Оцінка трудовитрат

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

Так як же нам оцінювати трудовитрати? На цю тему сказано і написано чимало слів (і навіть математичних формул). Кращі з них базуються на точному обсязі коду, який вам ще тільки належить написати. Так-так, існують методи, за допомогою яких завжди можна точно сказати, скільки часу буде потрібно, щоб написати стільки-то і стільки-то тисяч рядків коду. Дуже зручно, чи не так? Адже будь-хто може відразу ж підрахувати, скільки саме рядків коду займе реалізація того чи іншого завдання. (Уловили сарказм?)

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

Ось три правила для ефективної оцінки трудовитрат:

l Робіть все якомога простіше.

l Використовуйте знання про те, що вже траплялося в минулому.

l Отримуйте уроки з власного досвіду.

обсяг завдання

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

Неважливо, в яких одиницях ви будете вимірювати обсяг робіт. Головне, вибрати одного разу одиницю виміру і надалі використовували тільки її. У цій книзі ми вимірюємо трудовитрати в ідеальних тижнях. В цілому, ідеальна тиждень - це те ж саме, що звичайна людино-тиждень, з тією лише різницею, що в першому випадку програміст 100% свого робочого часу відводить вирішення даної конкретної задачі.

(Ви вже напевно помітили слабину в нашому підході. Добре, говорите ви, а якщо я тільки почав роботу над проектом, і мені ще просто нема з чим порівнювати? Загляньте в главу 15, де ми викладаємо абсолютно незадовільний спосіб вирішення цієї проблеми.)

Оцінка трудовитрат - завдання для всієї команди. Розробники обговорюють побажання замовника, обмірковують, як багато часу може зайняти реалізація такої функціональності і, нарешті, виносять рішення про обсяг трудовитрат. При цьому думки розробників можуть розділитися: одним завдання здається досить складною, тому вони стверджують, що реалізовувати її доведеться довго і важко, інші вважають її зовсім простий. У таких ситуаціях ми користуємося правилом: «Даєш оптимізм!». Іншими словами, якщо і після докладного обговорення у розробників і раніше немає єдиної думки, ми зупиняємося на найменшій оцінці.

Не забувайте: оцінка трудовитрат це не обіцянка зробити все точно в строк. Одна-дві помилка не представляє для проекту ніякої небезпеки. Наша головна мета - відточувати своє вміння визначати обсяги робіт, і з кожним разом давати все більш точні оцінки трудовитрат. Взявши за основу саму скромну оцінку, ми вбиваємо одразу двох зайців: по-перше, підтримуємо напруга в самому процесі визначення трудовитрат, так що оцінки не виростають до потворно величезних розмірів; по-друге, підтримуємо напруга в команді, так що розробники швидко відвикають від необґрунтованого оптимізму. Ті програмісти, чий оптимізм вже одного разу «вийшов боком» всій команді, в наступний раз остерігатимуться давати зайве оптимістичні оцінки.

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

Згодом ви будете уточнювати початкові оцінки трудовитрат, і це дозволить вам вказати на картці додаткову інформацію: наприклад, про зниклих залежностях, про виниклі технологічні проблеми (або їх зникнення, що теж трапляється).

Скільки можна встигнути зробити за одну ітерацію

Наш підхід вам відомий: принцип «вчорашньої погоди». В кінці кожної ітерації ми вимірюємо обсяг виконаної роботи і робимо висновок, що в наступній ітерації зробимо стільки ж. Однак коли ми розповідали вам повчальну історію про метеорологічну системі, ми мали на увазі тільки загальний принцип. Щоб застосувати його до процесу планування версій системи, ми повинні спочатку вирішити, в чому вимірювати обсяг того, що ми робимо. Можна, звичайно, вважати кількість реалізованих побажань замовника, але ж побажання бувають різні.

Значить, потрібно навчитися вимірювати обсяг будь-яких завдань. Тоді в кінці кожної ітерації ми визначимо, скільки побажань замовника нам вдалося реалізувати, і запишемо, скільки ідеальних тижнів пішло на кожне побажання. Після цього ми підрахуємо загальний обсяг ідеального часу, який пішов на виконання всіх побажань, і відповімо на питання, скільки ідеального часу в одній ітерації.

Це просте правило йде врозріз з одним із постулатів теорії управління проектами: «Робота займає стільки часу, скільки його є в наявності». Можливо, для деяких видів діяльності це справедливо, але тільки не для команди хороших розробників, які зацікавлені в кінцевому результаті.

Майте на увазі, підвищувати швидкість роботи шляхом збільшення числа співробітників - досить ризиковане заняття. Як ми вже пояснювали в сьомому розділі, залежність в даному випадку буде нелінійної, а результат позначиться тільки через деякий час. Не намагайтеся передбачити його заздалегідь - краще виміряйте його, коли він з'явиться. Зрозуміти, коли нові співробітники почнуть приносити істотну користь, надзвичайно складно. Ніхто не знає заздалегідь, скільки часу їм знадобиться, щоб увійти в курс справи.

Крім цього, ми будемо вимірювати швидкість роботи кожного програміста. Можна, наприклад, сказати, що швидкість цього програміста - 5 ідеальних робочих днів. Це означає, що він може гарантовано відпрацювати 5 ідеальних робочих днів за кожну ітерацію. У більшості розробників швидкість буде приблизно такою ж. А ось ті, хто працюють неповний робочий день або, наприклад, недавно прийшли в команду, з такою швидкістю працювати не зможуть.

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

Такий ефект може давати ціле безліч тісно пов'язаних один з одним факторів. Наприклад, одна команда краще розуміє, або ж використовує кращий інструментарій. А може бути, одна команда робить більш оптимістичні оцінки трудовитрат, тому їй доводиться працювати з меншою швидкістю, щоб компенсувати ці оцінки. Зрештою, всі ці міркування про ідеальний часу - грандіозна вигадка, покликана вирішити важку проблему визначення трудовитрат, необхідних для виробництва програмного забезпечення.

Що таке «ідеальний час»

Ті, хто працюють за методологією ХР, нерідко сперечаються про одиниці для обчислення обсягу робіт.

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

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

Календарний обсяг роботи - це число співробітників, помножене на календарний час. Команда з шести чоловік працює по тридцять робочих днів кожну календарну тиждень. За чотири тижні вони вироблять двадцять чотири календарних робочих тижні. Якщо один з розробників працює неповний робочий день, то за той же чотиритижневий період команда зможе виробити лише двадцять дві календарних робочих тижні.

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

Саме тому в ХР прийнято оперувати іншим поняттям: ідеальним часом (ideal time). Ідеальним називається той період часу, протягом якого ви працюєте над поставленим завданням, не відволікаючись на будь-яку іншу діяльність і при цьому відчуваєте, що ваша продуктивність близька до максимально можливої. Якщо всі оцінки виражені в ідеальному часу, можна не турбуватися про можливі перервах та інших факторах, які будуть відволікати нас від основного завдання. Наприклад, нам потрібно оцінити обсяг нового завдання, яка дуже схожа на ту, що на минулому тижні забрала в нас два ідеальних дня. В такому випадку, це завдання ми оцінимо точно так же. При цьому час, який буде реально витрачено на цю задачу, може істотно відрізнятися від передбачуваного, але за цим ми стежимо окремо.

Ми говоримо «ідеальний час», а маємо на увазі «ідеальний обсяг робіт». Команда з шести чоловік за робочий тиждень може виробляти, наприклад, тільки десять ідеальних робочих днів. Як правило, оцінюючи ту чи іншу задачу, розробники кажуть: «Це займе три ідеальних дня». Насправді вони мають на увазі «три ідеальних робочих дня», але це занадто довго.

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

(Франческо Чирилло (Francesco Cirillo) якось розповів нам, що одного разу купив і приніс на роботу тридцятихвилинний кухонний таймер в формі помідора. З тих пір в команді з'явився вираз «завдання на шість помідорів».)

Нам подобається оперувати поняттям «ідеальна тиждень», тому що слово «тиждень» ясно вказує на зв'язок зі звичним уявленням часу, а слово «ідеальний» не дає забути, що в реальності все виходить не так, як було заплановано. Крім того, поняття «ідеальна тиждень» дуже зручно використовувати при складанні першого плану (див. П'ятнадцяту главу цієї книги).

Ідеальним називається час, який ви витратите на виконання взятих на себе завдань. При цьому воно не включає в себе ті моменти, коли ви комусь допомагаєте (наприклад, під час парного програмування). Деяким може здатися, що необхідно враховувати весь час, коли ви не займаєтеся безпосереднім програмуванням, однак насправді тут вступає в дію принцип «вчорашньої погоди». Інакше кажучи, ви самі побачите, скільки часу віднімуть у вас ті чи інші завдання.

(Якщо ви вже знайомі з іншими матеріалами по ХР, то вам напевно зустрічався термін коефіцієнт навантаження (load factor). Коефіцієнтом навантаження ми називаємо відношення календарного обсягу робіт (протягом ітерації) до швидкості роботи. Таким чином, команда з п'яти чоловік, що працює двотижневими ітераціями, виробляє десять робочих тижнів за кожну ітерацію. Якщо швидкість команди дорівнює чотирьом, то коефіцієнт навантаження такої команди складе 2,5 (10: 4).) Раніше ми нерідко використовували при плануванні поняття коефіцієнта навантаження, проте тепер прийшли до висновку, що набагато легше оперувати одним поняттям швидкості.

Уточнюємо початкові оцінки

Що добре в процесі визначення трудовитрат, так це те, що з часом він стає все краще і краще. Чим більше завдань ви робите, чим більше отримуєте реальних цифр, тим точніше команда може оцінити ту чи іншу задачу. Постарайтеся всіма силами підтримати цю тенденцію. Не чекайте хороших результатів від початкових оцінок. Пам'ятайте, що з часом вони будуть робитися все краще і точніше.