Главная Партнеры Контакты  
Юридическая компания — «Основной закон», консультации и помощь в возвращении депозитов, защита по кредиту

ЮК
"ОСНОВНОЙ ЗАКОН"  

г. Киев, бул. Пушкина, 2а                
тел.: (044) 334-99-77                               
         (095) 407-407-3
         (096) 703-11-82

график работы: пн.- пт. с 9:00 до 18:00
          
                           

 












Рассматривается вопрос о предоставление нотариусам права выдачи извлечения из Реестра прав на недвижимое имущество.
Министерством юстиции был разработан проект Закона «О внесении изменений в некоторые Законы Украины относительно предоставления информации о государст...


Держреєстрація речових прав на нерухоме майно та їх обтяжень у 2014 році буде здійснюватись за новою - удосконаленою та спрощеною - процедурою.
Постанова Кабінету Міністрів "Про затвердження порядку державної реєстрації прав на нерухоме майно та їх обтяжень і Порядку надання інформації з Держа...




Система Orphus


Який метод оцінки проекту краще - гнучкий або звичайний?

  1. Звичайні методи оцінки
  2. історичні відомості
  3. групова оцінка
  4. Малюнок 1. Результати підготовки
  5. Малюнок 2. Форма оцінки
  6. Малюнок 3. Оцінки на дошці
  7. параметрична оцінка
  8. Гнучкі методи оцінки
  9. покер планування
  10. Малюнок 4. Приклад карт покеру планування
  11. Таблиця 1. Розміри футболки в сюжетних балах
  12. Оцінка великого числа сюжетів
  13. Порівняння між гнучкими і звичайними методами оцінки
  14. Таблиця 2. Порівняння гнучких методів зі звичайними
  15. Складові кращої оцінки
  16. висновок
  17. Ресурси для скачування

Точна оцінка може мати вирішальне значення для вашого проекту

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

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

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

Звичайні методи оцінки

Багато оцінки проектів будуються на використанні історії попередніх проектів або знаннях експертів в предметній області (Subject Matter Experts - SME). У наступному розділі ми розповімо про методи, заснованих на схожості між проектами.

історичні відомості

PROBE (Proxy Based Estimating - оцінка на основі подібності)

Цей метод запропонував Уоттс Хамфрі з Інституту програмного забезпечення при Карнегі-Меллонском університеті в рамках PSP (Personal Software Process - персональний процес програмування). Він заснований на припущенні, що якщо інженер створює компонент, схожий на той, що він вже створив, то на це піде приблизно стільки ж зусиль, що і минулого разу. При використанні методу PROBE зберігають детальну інформацію по кожному створеному компоненту. Потім, коли необхідно оцінити новий проект, він розбивається на компоненти, які порівнюються з історичною інформацією. Потім використовується формула для оцінки кожного завдання.

COCOMO II

У 1980 році була розроблена конструктивна модель вартості (Constructive Cost Model - COCOMO). Вона заснована на аналізі результатів статистичного дослідження 63 проектів розробки програмного забезпечення. Десять років по тому з'явилася оновлена ​​версія COCOMO II , Що охоплює сучасні життєві цикли розробки і використовує більш широкий набір даних. Нова модель приймає набір вхідних змінних і обчислює цільову оцінку, засновану на раніше вивчених проектах.

групова оцінка

У 1940 році був розроблений процес Wide Band Delphi . Він залежить від групової оцінки: керівник проекту вибирає секретаря і групу оцінки. Неупереджений секретар організовує наради. Він також забезпечує загальне участь. Керівник проекту повинен бути членом групи оцінки, щоб група знала пріоритетність вимог.

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

Малюнок 1. Результати підготовки
Точна оцінка може мати вирішальне значення для вашого проекту   Один з основних навичок, необхідних будь-якому керівникові проекту, - хороша здатність оцінювати обсяги роботи

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

Малюнок 2. Форма оцінки

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

Малюнок 3. Оцінки на дошці

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

параметрична оцінка

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

Use Case Point (UCP)

Цей метод розроблений в 1993 році. Він заснований на використанні для оцінки розміру програмного забезпечення прикладів з уніфікованої мови моделювання (Unified Modeling Language - UML). UCP оцінює багато елементів, такі як виконавці, технічна складність і складність середовища. Потім всі вони вставляються в формулу для розрахунку загального розміру.

UCP = (UUCW + UAW) × TCF × ECF

де:

  • UUCW: нескоригований вага прецеденту;
  • UAW: нескоригований вага виконавця;
  • TCF: коефіцієнт технічної складності;
  • ECF: коефіцієнт складності середовища.

Детальніше див. В документі Use case point an estimation approach .

Function Point Analysis (FPA)

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

FP = UAF × VAF

де:

  • FP: функціональний бал;
  • UAF: нескоригований функціональний бал;
  • VAF: поправочний коефіцієнт.

Детальніше див. На веб-сторінці Fundamentals of FPA .

трьохточкові оцінки

Цей метод знімає невизначеності оцінки з використанням методу оцінки та аналізу програми (Program Evaluation and Review Technique - PERT). Метод PERT обчислює загальну оцінку за трьома оцінками і аналізує результат за допомогою математичної формули.

E = (O + 4M + P) / 6

де:

  • E: оцінка;
  • O: оптимістичний сценарій для найкращого випадку;
  • P: песимістичний сценарій для найгіршого випадку;
  • M: найбільш ймовірний сценарій.

Детальніше див. На веб-сторінці PERT Technique .

Гнучкі методи оцінки

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

покер планування

Покер планування - один з найпопулярніших методів гнучкої оцінки. Він гарантує активну участь усіх членів через гру. Гра починається з роздачі кожному члену групи набору карт. Кожен набір карт містить власний номер, в значній мірі відповідний послідовності чисел Фібоначчі: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34 і т.д. Як видно з малюнка 4, ці числа являють собою відносну оцінку опису функціональності (сюжету). Нуль означає, що сюжет занадто тривіальний; 20 означає, що сюжет потрібно розбити на більш дрібні. Числа Фібоначчі використовуються для того, щоб створити невизначеність, яка веде до обговорення, особливо при великих числах. Але повернемося до гри. Кожен член команди починає оцінювати деякий сюжет і показує карту з оцінкою цього сюжету. Члени групи, що дали найбільшу і найменшу оцінки, викладають свої аргументи. Ці пояснення змушують команду переосмислити міркування, після чого учасники обмінюються досвідом і припущеннями. Вся команда переоцінює сюжет знову і знову, поки не прийде до консенсусу. Детальніше див. На веб-сторінці Planning poker .

Малюнок 4. Приклад карт покеру планування

Визначення розміру футболки

При цьому методі лунають карти розмірів. Кожна карта містить певний розмір: дуже малий (XS); малий (S); середній (M); великий (L) і дуже великий (XL). Карти розкладаються на столі горизонтально. Члени команди спільно розподіляють сюжети за категоріями відповідного розміру. Коли всі сюжети розсортовані, команда присвоює кожному розміру еквівалентний сюжетний бал, як показано в таблиці 1. Наприклад, розмір XS відповідає 1 балу, S - 2 балами, M - 4 балами і т.д. Цей метод гарантує, що всі сюжети будуть оцінені в балах.

Таблиця 1. Розміри футболки в сюжетних балах

Розмір футболки Сюжетні бали XS 1 S 2 M 4 L 6 XL 10

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

Оцінка великого числа сюжетів

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

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

Порівняння між гнучкими і звичайними методами оцінки

Перші питання, які приходять на розум: «Який же метод слід використовувати?» І «Який метод краще?». Це спірні питання, на які немає точної відповіді. Існує безліч досліджень в цій області, які доводять, що це залежить від багатьох факторів, таких як тип проекту. Ці фактори наведені в таблиці 2.

Таблиця 2. Порівняння гнучких методів зі звичайними

Гнучкі методи Звичайні методи Розміри проекту Малі та середні проекти Великі проекти Життєвий цикл програмного забезпечення Гнучкий життєвий цикл. Наприклад, екстремальне програмування (XP) і scrum Традиційний життєвий цикл. Наприклад, водоспад і спіраль Розмір групи оцінки Як правило, від п'яти до дев'яти осіб. Може бути менше п'яти осіб. Може бути один, якщо це експерт в предметної області. Співпраця в команді Високий ступінь участі всіх членів групи, таких як відповідальний за продукт, група розробників, група тестування. Не всі методи вимагають участі всіх членів групи. Історичні відомості Методи оцінки не вимагають історичної інформації. Більшість методів залежить від історичної інформації. Час оцінки оцінка може займати багато часу, так як вона заснована на досягненні консенсусу. Може займати менше часу в порівнянні з гнучкими методами. Система присвоєння балів Складність балів. Наприклад, розміри сюжетних балів. Параметричні бали. Наприклад, Functional Point Analysis і Use Case Points. Принцип оцінки Відносна оцінка. Абсолютна оцінка.

Складові кращої оцінки

Вибір хорошого методу оцінки - необхідна умова успіху вашого проекту. Оцінка - один з найбільш важливих елементів планування. Чим точніше оцінка, тим вище якість управління кінцевими результатами і менше простоїв. Так як же виміряти, чи хороші ваші оцінки? Визначте різницю між оцінкою і реальністю. За визначенням, хороша оцінка в 75% випадків знаходиться в межах 25% від фактичного результату (Конте, Дансмор і Шень, 1986 г.).
Який би метод оцінки ви не вибрали, існують складові, які неодмінно покращать його.

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

висновок

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

Ресурси для скачування

Схожі теми

  • Оригінал статті: Is your project's best estimation method Agile or conventional? .
  • Software Cost Estimation with COCOMO II, Barry Boehm et al. (Prentice Hall PTR, 2000 г.)
  • Analysis of Effort Estimation Model in Traditional and Agile , Manjula, R., and R. Thirumalai Selvi
  • Review on Traditional and Agile Cost Estimation Success Factor in Software Development Project, Mansor, Zulkefli, Saadiah Yahya, and Noor Habibah Hj Arshad. (International Journal of New Computer Architectures and their Applications (IJNCAA) 1.4 (2011): 942-952)
  • A comparison between agile and traditional software development methodologies , "Awad, MA, (University of Western Australia, 2005 р
  • Agile estimating and planning, Cohn, Mike. (Pearson Education, 2005)

Підпишіть мене на повідомлення до коментарів

Які методи можна використовувати, і коли?
Секретар бере з колоди сюжетних карт, що лежить на столі, одну і питає у команди: «Чи вважати цей сюжет великим, середнім або малим?
» І «Який метод краще?
Так як же виміряти, чи хороші ваші оцінки?
Главная Партнеры Контакты    
Cистема управления сайта от студии «АртДизайн»