Як я враховую зміни або забуті завдання в оцінці?

Для обробки оцінок рівня завдань та звітності про час я використовував (приблизно) техніку, яку описав Стів Макконнелл у главі 10 Оцінки програмного забезпечення. Зокрема, коли настає час для створення оцінок рівня завдань (безпосередньо перед початком кодування на проекті), я визначаю завдання на досить детальному рівні, так що, коли це можливо, у мене немає завдань з одноточкою, 50 % -впевненість у собі впевненість перевищує чотири години. Таким чином, процес оцінки завдань допомагає створити програмне забезпечення, допомагаючи мені не забувати завдання під час оцінки. Я також придумую можливий діапазон годин для кожного завдання, і, використовуючи статистичні розрахунки, які описує МакКоннелл, разом з моїми історичними даними точності, я можу генерувати оцінки на інших рівнях довіри за бажанням. Я відчуваю, що цей метод спрацював досить добре для мене. Нам потрібно поставити завдання та їх оцінки в TFS для відстеження, тому я використовую оцінки у відсотках впевненості, які мені кажуть використовувати.

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

Я буду радий уточнити, про що я прошу, якщо потрібно - дайте мені знати, що незрозуміло.

Книга « Вальсинг з ведмедями: управління ризиком щодо програмних проектів» (автор DeMarco та Lister, автор «Peoplewareware») має надзвичайно сприятливий підхід до цього. Ось моя реінтерпретація:

Зробіть оцінку "все іде ідеально". Звичайно, все рідко іде ідеально, так що низька ймовірність того, що станеться, скажімо, 0,1 відсотка. Іншими словами, лише один проект на тисячу іде ідеально за планом. Саме це більшість людей використовує як свою "оцінку", яка, очевидно, божевільна.

Натомість слід вважати оцінки як розподіл ймовірностей. Ця оцінка "ідеального світу" є найбільш лівою точкою розподілу ймовірностей оцінки.

Далі зробіть оцінку "якщо такі речі йдуть так, як для подібних проектів, як ця". Ця оцінка допомагає приймати "зовнішній вигляд" ( http://wiki.lesswrong.com/wiki/Outside_view ), уникаючи помилок планування ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).

Далі зробіть оцінку "Я на 90% впевнений, що ми зробимо X". Будьте дуже, дуже впевнені, маєте на увазі 90% впевненості. Іншими словами, ви розраховуєте зайняти більше часу, ніж ця оцінка, лише один раз на кожні десять проектів, які ви робите.

Тепер ми можемо використовувати вашу першу оцінку як оцінку ймовірності 0,1%, другу - як оцінку ймовірності 50% (сезон за смаком), а третю - як оцінку 90%, що дасть вам хорошу криву.

Скажімо, ваші оцінки 0%, 50% та 90% були 1 травня, 1 червня та 1 серпня, тоді крива вашої оцінки виглядатиме приблизно так:

     100 |                                  ......
         |                        ..........
% chance |                ........
of being |          ......
  done   |      ....
         |   ...
         |...
       0 +-----------------------------------------
          \           \           \           \
           May 1st     June 1st    July 1st    August 1st

Зверніть увагу, як з часом зростання ймовірності сповільнюється. Якщо хтось попросив вас оцінити 99,9% у цьому сценарії, це може бути 1 січня наступного року.

Одним словом - надзвичайна ситуація.

Надзвичайна ситуація - це сума, яку ви додаєте за "інші речі" - речі, які ви не можете врахувати в інших місцях своєї оцінки. Чи охоплює SMc це в програмі "Оцінка програмного забезпечення"? Я не можу згадати, і моя копія працює (я у відпустку відповідаю на це - як мені сумно) ...

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

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

Ця остання частина є критичною - це не лише "речі, які займають трохи більше часу, ніж я думав", це "модуль планування третьої сторони, про який нам сказали, що ми повинні використовувати, оскільки це стандарт компанії може не вирішити цю задачу". Те, як ви обчислюєте, яку кількість непередбачуваних ризиків потрібно додати, - це відсотковий шанс, який ризик може виявитись у вигляді десяткової (так 50% = 0,5), в рази більший від впливу цього ризику (так у прикладі кажуть, що вам потрібно вручну написати CRON робочих місць замість використання планувальника, і це займе 10 днів, це число 10 днів).

Отже, якщо є 50% шансів на те, що ваш ризик відбудеться, і вам знадобиться 10 днів зусиль, щоб обійти його, якщо він дійде, ви додасте 5 днів. Додайте всі значення для всіх виявлених ризиків проекту та додайте їх до загальної суми.

2) Shit Happens Contingency - найкращий опис, який я коли-небудь чув для нього, навіть якщо він не елегантний. Це ІТ-проект, лайно трапляється. Ніколи не виходить так, як ти думаєш, це займе більше часу, пропуститься тощо. Як правило, надзвичайна ситуація SH буде становити від 10% (абсолютний мінімум) до 25% (хоча може бути і вище), причому 15% буде приблизно типовим, точний рівень залежить від рівня невизначеності та загального ризику (переміщення постів цілей, невизначених вимог тощо) ).

Якщо ваш прем'єр-міністр не приймає випадки SH (і це можливо, він може не мати досвіду ІТ-проектів або бути сліпим оптимістом), тоді просто додайте його до всіх індивідуальних сум. Якщо він знає, що робить, у нього складеться власний журнал ризику і полюбить вас за роздуми над цим матеріалом. Звичайно, якщо він має якусь кваліфікацію PM (наприклад, PRINCE2), він буде про це знати.

3) Непередбачувані зміни - саме тут ви впевнені, що клієнт підніме зміни, але не хоче, щоб це було суперечкою. Додайте або X днів, або X%, і він переходить у банк для змін, які піднімає клієнт. Є два способи боротьби з цим: або ти їм розповідаєш про це, і це їх витратити, або ти не розповідаєш їм про це.

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

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

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

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

Ви стурбовані тим, що додаючи додаткові завдання, ви перекривите свою історичну точність? Або ви думаєте, що не враховуючи зайвих завдань, викривите точність?

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