Зміст:
оцінка програмного проекту
Піксабай
Вступ
Оцінка просто важка. На жаль, це також дуже потрібно. Компанії використовують оцінки для проектування графіків випусків, прийняття зобов’язань перед своїми клієнтами, вирішення того, чи варта запропонована функція, відстеження швидкості команд та ефективного визначення пріоритетів роботи. Керівники часто хочуть знати, коли якась функція чи продукт буде готовий до виробництва. Зрештою, розробка програмного забезпечення не є тривіальною інвестицією. Без оцінок, як керівник проекту зробив би оцінку? Якби люди могли точно передбачити майбутнє, люди не вигравали б у кінних перегонах 2% випадків. Оцінка - це велика загадка. Компаніям важливо і потрібно попросити своїх людей зробити неможливе: передбачити майбутнє.
Спочатку давайте розглянемо деякі популярні методи оцінки (на випадок, якщо ви пропустили хвилювання). Тоді ми зможемо подивитися, що це означає для нас та наших проектів.
Модель ворожки
Ця модель майже не вимагає зусиль для складання оцінки. Оцінювачі трохи замислюються над тим, що потрібно зробити для реалізації та тестування функції, тоді вони викидають число. Це звучить як "… (довга пауза)… Мммммм… 6 тижнів." Потім усі кивають, і ми рухаємось далі. Вони могли б провести досить довгий час на передній панелі, обговорюючи те, що вони знають про вимоги (що, мабуть, не є повною картиною). Цей ретельний аналіз робить їх оцінку більш надійною. В кінці проекту завжди є прийняте обгрунтування, чому оцінка була настільки далекою від реальності. Завжди є непередбачені обставини, які можуть послужити козлом відпущення. Часто нікому не спадає на думку, що модель сильно недолікована.
То як ми можемо покращити цей процес? Я знаю! Ми можемо використовувати техніку декомпозиції (тобто розділяй і володарюй). Цей підхід передбачає, що ви знаєте повний обсяг функції або проекту на передній частині. Кожна функція розбита на шматочки розміром укусу. Кожен шматок оцінюється (стиль ворожбита), потім ми складаємо їх, щоб отримати загальну оцінку функції / проекту. Це, безумовно, більш складний підхід, але здається кращим з двох причин:
- Менші відрізки роботи, як правило, легше надійно оцінити.
- Незважаючи на те, що ще існує можливість помилок (+/- деяка сума), існує припущення, що помилки скасують одна одну, коли ви все складете, і ви отримаєте більш надійну загальну оцінку.
Принципова вада такого підходу полягає в тому, що окремі дописувачі (люди, які фактично виконують роботу) загалом недооцінюють. Вони все ще значно кращі за тих, хто знаходиться над ними та навколо них, але це не високий рівень. Це не схоже на випадок, оскільки ми всі бачили випадки, коли розробники дивували себе, виконуючи щось достроково. Але це одна точка даних, а не тенденція. Люди насправді час від часу виграють у казино; витрачайте гроші в казино щодня протягом року, і у вас буде менше грошей, ніж було. Якщо ви відстежуєте оцінки порівняно з фактичними показниками протягом року-двох, ви виявите, що оцінки дійсно не відповідають реальності. Хоча багато ділових людей абсолютно впевнені, що розробники ліниво заповнюють свої кошториси і витрачають зайвий час на "золото" або перевірку своїх запасів,дані свідчать про інше. Стратегія "скасування" не працює.
Отже, що тепер? Давайте відкинемо модель ворожок і перейдемо до підходу, який базується на розмірі. Виявляється, хоча люди досить жахливо оцінюють час завершення, ми насправді досить добре говоримо, наскільки щось велике. Ми особливо добре маємо порівняльний розмір ("він більший за цей, але менший за той, що там"). Якщо ми думаємо з точки зору розміру чи складності, а не часу, наш мозок обробляє це більш надійно. Тоді ми можемо взяти значення розміру і розрахувати фактичну кількість годин для проекту на основі чудової магічної формули! І саме тоді на сцену виходить популярна модель функціональних точок (етап ліворуч).
Аналіз функціональних точок (FPA)
Для аналізу функціональних точок нам потрібно визначити п’ять типів речей у нашому додатку: зовнішні входи, зовнішні виходи, зовнішні запити, файли зовнішнього інтерфейсу та внутрішні логічні файли (не хвилюйтеся занадто про визначення; їх можна дослідити пізніше). Кожен приклад цих (функція) має складність, пов'язану з нею (низьку, середню або високу). Ми використовуємо таблицю нижче, щоб з’ясувати, скільки балів призначається кожній функції.
Тепер, якщо ми складемо бали для всіх наших функцій, ми можемо отримати число, як 457 функціональних точок для нашого проекту. Тоді нам просто потрібна формула, щоб визначити кількість годин… На основі нашого останнього проекту, наш “коефіцієнт доставки” становив 15 функціональних балів на людину на місяць. Це приблизно 30 місяців роботи, що для моєї команди з 12 чоловік має зайняти трохи більше двох з половиною місяців!
Це, безумовно, є більш складним, ніж наша попередня модель. Насправді є чотири ключові сфери складності, які слід визнати.
- П’ять типів компонентів не обов’язково інтуїтивно зрозумілі, і легко забути внести щось у список або віднести його до неправильного сегмента.
- Таблиця, яка використовується для фактичного генерування функціональних точок, містить магічні числа, для перевірки яких знадобиться багато зусиль. Чи правильно відкалібровані ці цифри для формування надійних оцінок для моїх команд?
- Швидкість доставки (критична частина головоломки) розраховується на основі продуктивності вашої команди. Як часто нам потрібно обчислювати нове число? Насправді дуже мало вказівок щодо цього.
- Що являє собою низьку, середню або високу складність? Як ми це визначаємо, щоб усі це розуміли? Чи не отримання цього права є критичним для точності наших розрахунків?
У цьому дуже простому прикладі є кілька рухомих частин, і ми навіть не обговорювали більш складні моделі складності та інші дані, які можуть увійти в дію (напр. Ставка витрат, рівень підтримки, щільність дефектів тощо). Більше рухомих частин означає більше можливостей для виникнення помилок. Ми зараз робимо оцінку занадто складною? Ми не платимо розробникам, щоб приділяти багато часу оцінці. Я не можу продати кошторис своїм клієнтам. Мені потрібне робоче програмне забезпечення. Чи є щось ще там?
Поворотливий
Тепер давайте коротко розглянемо спритну сутичку (достатньо для порівняння). Як зазначалося раніше, люди жахливо оцінюють час і досить добре володіють порівняльним розміром. Ось кілька термінів, які слід зрозуміти:
- Спринт - часовий проміжок часу (зазвичай два тижні).
- Історія користувача - дискретна робота, бажано достатньо невелика, щоб виконати її одна людина в спринті. Це те, що ми оцінюємо.
Найпопулярнішою стратегією є використання послідовності Фібоначчі (0, 1, 2, 3, 5, 8, 13) для оцінок. Це не лінійно - у міру того, як ви піднімаєтеся по шкалі, розмір проміжків збільшується. Ключовим є те, що прогалини повинні бути досить широкими, щоб не було причин сперечатися щодо незначних відмінностей. Як тільки ви перевищуєте 3, різниця між 4 і 5 або 7 і 8 настільки незначна, що безглуздо витрачати час на хешування, який це. Послідовність бази-2 також буде працювати (0, 1, 2, 4, 8, 16 тощо).
“Але почекайте, це лише цифра. Що це означає? Скільки годин - очко? " Окуляри не призначені для прямого співвідношення з годинами, тому що, якщо вони це зробили, у команди буде спокуса повернутися до підрахунку в годинах, а потім якось перетворити це на бали. Як вже обговорювалося раніше, точність наших оцінок походить від порівняльного розміру та не оцінки кількості годин, які щось займе. Якщо ви даєте команді можливість мислити за кількістю годин, ви порушуєте свою здатність точно оцінювати.
Скажімо, ви почали з калібрувальної вправи. Затягніть свою команду в кімнату і проведіть їх по списку з 10-12 історій користувачів. Виберіть той, який маленький, але не найменший, і зробіть його спочатку. Перегляньте його та оголосіть, що ця історія - “3”. Ви не питаєте. Ви розповідаєте. Потім перейдіть до наступної історії. "Якщо це було 3, що це таке?" Зараз команда розмірковує історії порівняно з іншими історіями. Зрештою, вони матимуть досить хороше уявлення про те, що означає «1», «2» тощо. Вони не оцінюють. Час не має значення. Вони розмірковують історії порівняно з іншими історіями, які вже мають номер. Потім ви можете помістити приклади історій для кожного числа в послідовності в документ, який називається лінійкою. Вони можуть використовувати це як посилання, якщо не впевнені, що таке "5".
Тепер ось ключ. Чарівним соусом, що робить цю роботу, є "швидкість" (кількість балів, яку команда може набрати в спринті, в середньому на 3-4 спринту). Скажімо, ваш спринт - два тижні, а ваша команда з 8 чоловік має середню швидкість 35 балів. Ви отримуєте 35 балів за 640 годин роботи (8 х 80 годин). Якщо ми з’ясуємо, що функція займе близько 100 балів, щоб почати роботу, щоб закінчити, тоді я знаю, що це приблизно 6 тижнів роботи та ~ 1900 годин. Команда дуже добре справляється з послідовним розміром історій, і ви використовуєте це для планування проекту. Цей розрахунок працює, тому що тривалість однакова від спринту до спринту.
Щоб зробити довгострокове планування на високому рівні, ви можете попросити своїх потенційних клієнтів розбити функції високого рівня на проміжні історії, що складаються з одного рядка, і поставити на них значення балів. Буде втрачено ступінь точності, але ви використовуєте модель, яку вони вже розуміють. Більш точним шляхом буде відносний розмір на рівні функції. "Ця функція більше, ніж ця 40-бальна, менша, ніж ця 120-точкова, і трохи більша, ніж 65-точкова, яку ми щойно зробили". Історії згруповані в “епопеї”. Якщо кожна функція є епосом, в кінці ви дізнаєтесь, скільки балів потрібно для завершення цієї функції. Зберігайте історію цього, і ви можете використовувати його для планування випуску.
Висновок
Сьогодні існує безліч методологій. У кожного є плюси і мінуси. Якось нам потрібно з’ясувати, як максимізувати точність наших оцінок, щоб ми могли приймати правильні рішення. Це не означає, що наші оцінки повинні бути точними. Вони просто повинні бути досить точними, щоб бути корисними. Якщо ви не розумієте оцінку, ви можете припустити, що оцінки були неточними, оскільки команда не зробила хорошої роботи. Вони не оцінили правильно, або не виконали проект належним чином. Побиття триватиме доти, поки оцінки не покращаться. Але оцінки ніколи не повинні використовуватися як зобов'язання. Це найкраща здогадка, виходячи з обмеженої інформації, якою ми маємо сьогодні. Коли з’являється нова інформація, ми маємо дозволити переглянути оцінки. Все інше очікує неможливого, що є проблемою з лідерством (а не з командою).
Підхід Скрама набагато простіший, ніж той, що ми бачимо при аналізі функціональних точок. І я б сказав, що це набагато надійніше, ніж чарівні таблиці з магічними цифрами. Це приносить найбільший удар (мінімальні зусилля з досить високим ступенем точності). З точки зору зусиль, це не створює важкого процесу для розуміння та використання команд. Штучна оцінка спритного може насправді відбутися дуже швидко, як тільки всі зрозуміють деталі оцінюваної роботи. Це, звичайно, краще, ніж витягувати цифри з повітря. Використання швидкості використання робить щось дуже важливе: воно включає історичні дані в обчислення. Кожного спринту ви перераховуєте свою швидкість. Це критично важливо, оскільки з часом пропускна здатність змінюється. Команди, які використовують FPA, можуть отримати рівень доставки з попереднього проекту,що в деяких випадках було кілька місяців тому. З тих пір, напевно, багато чого змінилося. Я пропоную вам дослідити Agile і реально докласти зусиль, щоб зрозуміти сюжетні моменти та швидкість. Не відмовляйтеся оцінювати за годинами лише тому, що це те, що ви розумієте. Я вірю, що ти пізніше подякуєш собі.