Які способи оцінки завдань використовують розробники

Привіт всім! Теорія, необхідна старту у створенні, дуже велика. У якихось спеціалістів (backend-розробників Java та інших мовах) її більше, а інших (наприклад, frontend-розробників Javascript — React Native) — трохи менше. Однак і в одних, і в інших має бути великий запас як технічних, а й “організаційних” знань. Ці "організаційні" знання - одна з точок перетину для frontend-і backend-розробників. Сьогодні я хочу поговорити про один із аспектів таких нетехнічних, організаційних знань — про оцінку завдань (estimation). І так як я працював тільки в Agile методології (яка за фактом вважається найпопулярнішою), в його частині, Scrum , розглядатиму оцінку завдань буду в контексті Scrum . Відразу скажу, що оцінка, яка називається ще естімацією, важка. Особисто для мене як для розробника це один із найважчих/небажаних аспектів роботи. Необхідно враховувати безліч різних чинників, які можуть спричинити оцінку завдання. При цьому плани подальшої розробки будуть відштовхуватися від ваших прогнозів.

А якщо не вгадати з оцінкою?

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

Як проводиться оцінка часу

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

Що таке Story points

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

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

Як НЕ треба використовувати стори поінти

На превеликий жаль, сторі поінти часто застосовують не за призначенням. Сторони поінти можуть помилятися, якщо вони використовуються для оцінки людей, визначення докладних термінів та ресурсів, а також коли їх помилково приймають за міру продуктивності. Натомість командам необхідно їх використати, щоб зрозуміти обсяг/складність роботи в кожному завданні та для розміщення пріоритетів. Можливо, що частини, які оцінені як складніші, варто робити в першу чергу, щоб їх вдалося зробити до кінця спринту , а легші відсунути на пізніше. Нагадаю вам, що таке спринт у контексті Scrum методології: Наскільки довгий цей часовий проміжок, визначається на початку розробки за домовленістю команди та замовника. Це може бути проміжок два тижні або місяць, або будь-який інший термін. Як правило естімація завдань ведеться на початку спринту, щоб спланувати можливий обсяг виконаної роботи до його кінця, коли виконана робота надається замовнику. Воно допомагає бачити ваш прогрес у розробці продукту, отримувати фідбек від замовника та скоригувати розвиток проекту згідно з баченням замовника. Але все ж таки ми трохи відволіклися: повернемося до естімації. Оцінка завдань лише одним розробником була надто суб'єктивною. Тому зазвичай це командна робота. Технік для командної оцінки чимало. Сьогодні ми розглянемо саму використовувану з них Scrum poker . Для цієї техніки потрібен менеджер, який буде кимось типу ведучого цього Scrum poker -а. Це може бути людина спеціалізації Scrum Master , ну або PM .

Що таке Scrum Poker

Scrum poker — або планування покеру — це техніка оцінки, яка заснована на досягненні домовленості. В основному використовується для оцінки складності майбутньої роботи або відносного об'єму завдань при розробці ПЗ. Відразу зазначу, що Scrum poker — звичайна практика розробки, і вам точно потрібно знати, що це за звір. Для цього процесу зазвичай використовується певний додаток або сайт, який дозволяє нам організовувати командну оцінку того чи іншого завдання. Як це відбувається? Команда бере елемент невиконаної роботи (нове завдання, функціонал), коротко обговорює можливі підводні камені та інші нюанси, пов'язані з ним. Після цього кожен учасник обирає картку з числом, що відображає оцінку складності. Ах, та при оцінці застосовуються не типовий ряд, а числа Фібоначчі . Числа Фібоначчі такі популярні в scrum poker -і тому, що між ними згодом збільшується проміжок (нагадує рівні піраміди). Існують завдання, які мають величезну складність, і малою кількістю сторі поінтів тут не обійтися. Пояснення для незвичайних карток:

невідома кількість ендпоінтів

нескінченно довге завдання

потрібна перерва

Більше рідкісні методи эстимации:

• у розмірах футболок -S, M, L, XL
• або в собаках - чихуахуа, мопс, такса, бульдог і так далі (як на мене, це дивна одиниця оцінювання завдань = D)

Потім команда порівнює поставлені оцінки одному й тому завдання різними розробниками, і якщо вони сходяться, відмінно! Якщо ж ні, необхідно обговорити причини відмінностей у оцінці (аргументи). Після цього можна спільно дійти єдиного естімейту, з яким усі плюс-мінус будуть згодні. А чому взагалі використовується покер для планування серйозного програмного проекту? Адже це якось дивно. Насправді подібна гейміфікація спонукає членів команди мислити незалежно, пропонуючи показати свій результат одночасно зі своїми тиммейтами. Це, своєю чергою, дозволяє уникнути залежності від поглядів інших членів команди. Адже інакше менш досвідчені розробники поглядатимуть і орієнтуватимуться на оцінки досвідченіших членів команди, що зведе нанівець корисність їхньої власної оцінки. Але при одночасному розтині результатів це, по суті, неможливо. Як приклад програми для планування у форматі Scrum Poker можна взяти програму від Atlassian .

Приклад оцінки задачі

Уявимо, що ваша команда виділила деяку шкалу для оцінювання в сторі поінтах: Починається Scrum Poker за завданням, і ви оцінюєте його так:

• ви ніколи не працювали з імплементацією аналогічного функціоналу раніше - +3
• функціонал задачі середнього обсягу - +2
• реалізація задачі має високу складність - +3
• висока складність написання тестів для даного функціоналу - +3

За підсумком виходить 11 стор. поінтів, але так як такої картки немає, ви пропонуєте 13. Інший ваш колега оцінює завдання:

• працював з аналогічним завданням раніше - +1
• функціонал задачі середнього обсягу - +2
• реалізація завдання має середню складність - +2
• середня складність написання тестів для даного функціоналу - +2

У підсумку у нього виходить 7 стор. поінтів, але такого в числах Фібоначчі немає, і він ставить картку з максимально наближеним числом - 8. Інші члени команди, відповідно, ставлять оцінки, відштовхуючись від своїх суб'єктивних поглядів. Далі ви показуєте свої результати і виявляєте, що майже всі ваші колеги поставабо естімацію 13, крім одного розробника, який поставив 8. У такому разі йому дається слово, і він наводить докази. А вони, наприклад, такі: він працював раніше з таким же завданням, і вона не така складна, як це може здатися, і в результаті він переконує інших членів команди змінити своє рішення з 13 на 8 стор. поінтів, кажучи, що він допоможе тому, хто займеться цим завданням, розібратися з нею. Або виконає її сам. І взагалі-то не важливо, прислухаються до його доводів інші чи ні, адже так чи інакше оцінка буде присвоєна даному завданню, і команда перейде до ознайомлення з наступною. Перші рази оцінки будуть неточними, як і прикидки обсягу робіт, які ви плануєте зробити за наступний відрізок часу (спринт). Адже ці вчинки робляться саме за естімаціями. Через деякий час, приблизно через місяці через три, команда почне більш точно оцінювати завдання, та й стане видно середній обсяг робіт, який може виконати команда за спринт. Але це загальне планування обсягу робіт, це більше про час, а в даному випадку може бути багато різних факторів, що впливають. Наприклад, пішов у відпустку на два тижні один із розробників. Тобто потрібно викреслити певний обсяг робіт, що плануються (планованого функціоналу). Або в команду прийшов новий розробник, але при цьому повноцінно на нього не треба розраховувати, т.к. Необхідно враховувати час адаптацію до проекту, зване онбордингом . Це може бути тижнів зо два, плюс-мінус тиждень, залежно від складності проекту. На цьому у мене сьогодні все, сподіваюся, я трохи покращив ваші пізнання в такій нетехнічній частині знань як естімація завдань. Якщо ж ви хочете заглибитися в цю тему, як і в деталі Scrum, раджу прочитати книгу Джеф Сазерленд "SCRUM". За наслідки я не ручаюся, адже можливо, після неї у вас з'явиться настирливе бажання стати Scrum Master = D