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

Хоча досвідченому розробнику порівняно можливо оцінити, скільки часу знадобиться на реалізацію коду, коли шаблон і проблема, що вирішується кодом, добре зрозуміли, як можна зробити хорошу оцінку, коли, хоча кінцева мета добре зрозуміла, реалізація - це 95% теоретичне / вирішення проблем і має дуже малий обсяг реалізації?

Моя робота часто складається із завдань для досягнення чітко визначених цілей, однак я мушу знайти спосіб досягти цієї мети, і поки я не зрозумію рішення, мені не зрозуміло, які можуть бути додаткові бар'єри. Більш конкретно, я часто працюю над генерацією коду або автоматизованими засобами маніпулювання кодом. Після того, як рішення буде повністю вирішено і інструмент вдосконалений, він безпосередньо зробить 95% фактичних змін дуже швидко. Однак я не маю жодного способу оцінити, скільки додаткових питань, можливо, доведеться вирішити для того, щоб генератор чи інструмент аналізу вирішували непередбачувані крайові випадки.

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

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

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

Перше - дати оцінку. Сама оцінка не є єдиним числом - це зобов'язання. "Скільки часу займе ABC" -> "Близько 5 днів" означає, що його приблизно 5 днів. Однак хороша оцінка - це діапазон, коли ви на 90% впевнені, що будете мати її в такому діапазоні. Якщо ви хочете сказати: "Я на 90% впевнений, що це займе 1 і 5 днів", тоді скажіть це. Не працюйте з "Я думаю, це займе від 1 до 10 днів, тому 5 днів, мабуть, приблизно в середньому" - це не оцінка, і ви помилитесь 50% часу.

Ну, 50% або більше часу програмісти - це горезвісні недооцінки часу виконання завдань.

Розглянемо конус невизначеності:

^{_{Зображення з http://www.construx.com - повна стаття на веб- сайті http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Ucurityity/}}

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

З кожною оцінкою, яку ви даєте, ви повинні бути на 90% впевнені, що оцінка знаходиться в цьому діапазоні. Ви можете помилятися - 10% часу випаде з цього діапазону.

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

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

Ключовим моментом для оцінки є ітеративний процес його вдосконалення після трохи роботи.

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

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

З Як відповісти, коли вас запитують про оцінку?

Що сказати, коли запитують оцінку

Ти кажеш: "Я повернуся до тебе".

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

З глави 4 Оцінки програмного забезпечення:

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

Бос : AJ, у нас є 3 собаки, 2 кролики, катапульта та монахиня. Нам потрібно знайти спосіб дістати всі 7 (так, катапульта теж) через 20-футову стіну і в озеро з іншого боку, не собаки їдять жодних кроликів, і не потопаючи монахині. Скільки часу вам знадобиться придумати рішення?

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

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

Мораль цієї історії полягає в тому, що якщо у вас недостатньо інформації, щоб зробити обґрунтовану оцінку, то не варто . Ще ні. Отримайте більше інформації. Дослідження більше. Як правило, це цілком нормально, щоб сказати: "Я повернуся до вас за 2 дні з більш солідними цифрами".

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

Я б запропонував вам спробувати щось посередині між відповідями tylerl та MichaelT із наступним:

• розділити роботу, яку потрібно виконати на 3 або 4 фази. Фази повинні бути:
  1. Аналіз проблеми
  2. Прототипування рішення
  3. Рішення в реальному світі
  4. Оцінка результатів (тест)
• надайте оцінку лише для фази 1 (аналіз), грунтуючись на вашому досвіді, або на фазах 1 + 2 (аналіз + прототип) вашому керівництву. Потім надайте їм оцінку для фаз 3 + 4, коли проблемні фази 1 і 2 виконані (або, принаймні, достатньо просунуті, щоб ви могли мати впевненість у своїй оцінці).

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

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

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

Перше питання, яке я б задав собі, це проблема, яку можна вирішити? Це не інтелект чи питання, пов'язані з силою мозку, а практична реальність. Якщо ви не перебуваєте в світі місячних знімків Google, де відмова є очікуваним результатом, важка реальність така , що я буду очікувати , щоб доставити це , що б це виявляється. Здається, грубе правило, чи ми вже знаємо, яким має бути 90% рішення?

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

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

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

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

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

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

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

Таймбоксинг, в основному.