Як навчитися робити кращі оцінки? [зачинено]

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

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

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

Я думаю, що більше за все це є досвід досвіду.

Закон Мерфі Тайм - менеджмент: Для того, щоб з'ясувати , як довго що - то буде брати, з'ясувати , як довго вона повинна прийняти і подвоїти його.

Потім перейдіть до наступної вищої одиниці часу. Таким чином, ми виділяємо два тижні на одноденний проект.

Ви можете вчитися, роблячи їх колективно .

Я використовую Планування покеру . Це методика оцінки на основі консенсусу .

Ваша оцінка повинна бути відстежена і порівняна з тим, що ви ефективно зробили. Ви отримаєте Швидкість .

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

Оцінка програмного забезпечення Steve McConnell (MS Press) - це добре прочитане.

Головне з оцінкою програмного забезпечення узагальнено наступним

Без історичної інформації ваші оцінки марні.

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

Ще кілька моментів, про які слід пам’ятати:

1. Це стане лише повільніше . Застосування правила 80/20 означає, що важча робота настане пізніше, якщо ваш проект управління не буде дуже дисциплінованим.
2. Оцінка! = Планування. Оцінка - це процес з'ясування зусиль, необхідних для того, щоб щось зробити. Планування - це процес внесення його в графік.
3. 60% ефективності - це майже все, на що можна сподіватися. 70% - утопія. Якщо ви оцінюєте в днях, складіть це. Якщо ви оцінюєте за години, не забудьте застосувати це пізніше.
4. Згадайте довгий хвіст . Оцінки - це груба здогадка про те, як довго це "ймовірно" буде коригуватися для певного рівня ризику та невідомості. Довгий хвіст вступає в гру, оскільки фактична необхідна робота ніколи не буде меншою за 0. ОТОХ, максимальна кількість часу, яке знадобиться, обмежується лише тим, скільки часу ви готові витратити на нього, перш ніж відмовитися. Як сказав колишній мій начальник, "усі оцінки становлять +/- x% і це ніколи не мінус".

Я здивований, що ніхто не згадував техніку оцінювання в стилі PERT, описану в «Чистому кодері» Роберта Мартіна . У цьому методі ви оцінюєте, скільки часу знадобиться для 3-х сценаріїв: оптимістичного ( O), номінального ( N) та песимістичного ( P). Тоді очікувана тривалість = (O+4N+P)/6і ви отримаєте стандартне відхилення (P-O)/6.

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

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

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

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

Якщо мені доведеться робити оцінку за годину, я намагаюся виконувати їх лише для невеликих завдань в рамках ітерації. Я вимірюю все за південні оцінки (4, 8, 12 годин), якщо я не знаю, що це може бути менше. Але я рідко щось оцінюю менше ніж за 1 годину.

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

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

По-третє, слід часу (зусилля). Вам слід принаймні розмежувати:

• Аналіз
• Дизайн
• Код
• Тестування блоку (включають виправлення дефектів)
• Інтеграційне тестування (включаючи виправлення дефектів)

• Тестування на прийняття з користувачем (включаючи виправлення дефектів)

  Було б чудово, якби ви виміряли зусилля на виправлення дефектів для кожного типу тестування, але це додає складності, тому ви зможете зробити це згодом.

По-четверте, визначте основні базові елементи для оцінки. Наприклад:

• Кількість автоматизованих процесів (аналіз)
• Кількість об'єктів моделі домену (Дизайн)
• Кількість форм та звітів (Код)

По-п’яте, співвіднесені основні елементи та зусилля. Наприклад:

• Аналіз зусиль = X людино-годин / автоматизований процес
• Проектні зусилля = Y людина-години / об'єкт доменної моделі
• Кодове зусилля = Z людино-годин / форма (або звіт); кількість форм = А * моделей доменної моделі
• Одиничне випробування на одиницю = M% * Кодове зусилля
• Інтеграційне тестування = N% * Кодове зусилля
• Намагання на тестування прийняття = P% * Зусилля з кодом

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

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

Погляньте на http://en.wikipedia.org/wiki/Personal_Software_Process , він справді працює.

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

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

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

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

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

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

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

Ви можете спробувати скласти облік того, що було оцінкою, і що було фактичним для різних завдань, щоб створити достатньо запису, щоб потім знати, який множник мати для конкретних речей, які повторюються у вашому списку. Зрозуміло, що це проба та помилки, але це, здається, працює добре для мене. Є ще що можна сказати протягом багатьох випробувань до того, як з'явиться закономірність. Це, мабуть, схоже на безліч інших відповідей, які б сказали, що можна звестись до "Просто зроби!" тому що це насправді, як більшість з нас розвивали навички. Чи є головним болем бачити, наскільки можна помилятися при складанні оцінок? Так, але якщо оцінки покращаться, то з часом всі можуть бути щасливими.

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

Замість того, щоб написати про це книгу, я просто запропоную невелику пораду щодо використання методу оцінювання:

• Розбийте своє завдання на більш дрібні компоненти. Оцініть кожне завдання якнайкраще.

• Додайте завдання для планування та проектування (яке включає те, що ви зараз робите.) Оцініть його.

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

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

• Складіть кошторис завдання, щоб отримати загальну оцінку.

• Вперед і помножте цю загальну оцінку на два †:40. Це дасть вам час на забивання:

  1. Закінчіть речі, які ви не помітили у своєму початковому списку завдань
  2. Закінчіть речі, про які ви не могли б знати, поки не почали працювати
  3. Включіть відгуки інших людей та внесіть зміни
  4. Перебивайте інші речі, що відбуваються навколо вас, як зустрічі
  5. Завершуйте випередження оцінки частіше, ніж позаду

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

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

Формула, яка працює при роботі над собою:

1. зробіть розбивка тодо до 1 - 4 години зернистості. Я вважаю, що я з ними зазвичай точний

2. "коефіцієнт невідомих": помножити на коефіцієнт 2, піднятий на кількість невідомих. Тобто, якщо ви плануєте розробляти програму couchdb, але тепер знайте що-небудь про JavaScript та http .. додайте 2 ^ 2 як мультифактор.

3. контекст-перемикач-фактор: кратний на 1,5, якщо ви працюєте в ідеальній обстановці (вдома в навчальному куточку тощо), або 2,5, якщо будете працювати в недосконалому середовищі (офіс / багатолюдне місце тощо)

Я вважаю, що це знаходиться в межах +/- 20% від фактично зайнятого часу !!

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

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

Для відкривачів читайте "Економіка програмного забезпечення", Баррі Боем та "Контроль програмних проектів" Тома ДеМарко. Після того, як ви прочитали та засвоїли ці два, прочитайте "Оцінка вартості програмного забезпечення за допомогою COCOMO 2", Баррі Боем.

Що я маю сказати далі, це допоможе вам ЛОТІВ взяти клас ймовірностей та статистику, навіть основну кулінарну книгу.

Жодна оцінка не є ідеальною. Існує деяка ймовірність приходу рано, а деяка ймовірність приходу пізно. Початкова детальна модель COCOMO Boehm дала прогнози, які виявилися в межах 30% від фактичного результату, що перевищує 60% часу. Це було набагато краще, ніж те, що було загальним, коли він писав і видав книгу.

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

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