Як оцінювати великі завдання

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

image

Трохи про Planning Poker
Три роки ми використовували Planning Poker. При цьому підході кожен програміст в закриту оцінює історію в 0.5, 1, 2, 3, 5, 8, 13, 20, 40 умовних одиниць (story points). Потім люди, які дали найбільш високі і низькі оцінки, пояснюють, чому це завдання здається їм такої складної, або навпаки — простий. Обговорення триває, поки все не прийдуть до єдиної оцінки.

Після завершення спринту скрам майстер підраховує скільки story point завершених історіях. Виходячи з зібраної статистики він визначає, скільки завдань поміститься в наступний спринт.

В чому власне проблема

Розбираємося в історії на ходу

Щоб дати оцінку користувача історії, розробники повинні розуміти як її реалізовувати, хоча б у загальних рисах. Щоб розуміти, як реалізовувати, потрібно розуміти, чого хоче клієнт. Все це з'ясовують і обговорюють під час оцінки. На одну історію команда витрачає по 5-30 хвилин. При цьому в обговоренні беруть активну участь 2-3 людини, які краще розбираються в темі. Інші витрачають час даремно.

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

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

Ілюзія точності оцінки великих історій

Одну історію ми оцінюємо в 20. Ще десять історій оцінюємо по 2 кожну. Оцінка десяти маленьких історій в сумі дорівнює однієї великої. Однак, велику історію майже завжди роблять довше, ніж кілька маленьких з тієї ж оцінкою.

При такому способі оцінки 20 > 2*10.

Чому так відбувається? Чим більше розмір історії, тим більше можливостей забути щось врахувати при її оцінці. Навіть якщо все врахувати, ймовірність недооцінити на 50% одну історію більше, ніж ймовірність настільки ж недооцінити десять історій.

Наскільки відсотків ти закінчив свою роботу?

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

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

40 = невідомість

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

Та ж проблема, хоч і меншою мірою, стосується оцінок 20, 13, 8. Якщо історію, описану парою речень, оцінюють в 13 або 20, — це також означає, що у розробників немає повного розуміння, як її робити. Намагатися всією командою докладно описати розв'язання задачі під час оцінки — неефективна витрата часу. Цим може зайнятися і один чоловік. Для вирішення цієї проблеми, ми за завданням призначали відповідального, який розписував рішення до командного оцінки. Однак, не було чітких критеріїв, наскільки докладно розписувати рішення. Іноді достатньо і пари пропозицій, а іноді потрібно кілька абзаців, щоб рішення задачі було зрозумілим.

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

У підсумку наш процес проектування-оцінки виглядає так:

  1. На вході користувача історія — мінімальна функціональність, яка принесе користь клієнта. У користувача історії обов'язково повинен бути Definition of Done (DoD) зрозумілий менеджеру або клієнту, щоб її можна було прийняти.
  2. Якщо історія виглядає занадто великий, то виділяється MVP: викидається все, без чого клієнт може на перших порах обійтися. По завершенні цієї історії робиться наступна, в якій вже додана функціональність буде розширюватися.
  3. За цією історією призначається відповідальний, який у разі необхідності розбиває історію на окремі завдання так, щоб кожне завдання можна було робити паралельно з іншими. Часто зустрічаються власні історії, які не має сенсу розбивати на завдання: або вони не параллелятся, або історія занадто маленька. По можливості завдання потрібно робити такими, щоб їх можна було протестувати незалежно. Тоді тестування можна буде розпочати після завершення першого завдання, а не чекати, поки дороблять всю історію.
  4. Потім відповідальний розбиває кожну задачу на підзадачі. Кожна підзадача — пункт, з описом від одного речення до абзацу. Він може не мати ніякого сенсу для непрограммистов. Окремі підзадачі кшталт «написати клас» і «написати тести на цей клас» — це нормально. Розбиваючи на підзадачі відповідальний керується наступними правилами:

    • всі підзадачі повинні бути приблизно однакового мінімального розміру (1 story point)
    • для кожної підзадачі повинно бути зрозуміло, що в ній треба зробити

    • підзадачі є зрозумілий програмісту DoD (клас написаний, тести проходять)
  5. Команда оцінює завдання. При командному оцінці відбувається рев'ю того, наскільки добре відповідальний пропрацював рішення і розбив завдання на підзавдання, немає чи серед підзадач занадто великих або дуже маленьких. При цьому:

    • якщо конкретна підзавдання комусь незрозуміла, її розписують докладніше;
    • якщо команда вирішує, що підзавдання занадто велика, її розбивають на частини;

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

Аргументи за

Швидкий етап командного оцінки

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

  • Які підзадачі незрозумілі?
  • Які підзадачі варто розділити?
  • Які підзадачі варто об'єднати?

Формалізація якості проектування

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

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

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

Чітке розуміння наскільки завдання завершено

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

Аргументи проти

Потрібен час на підготовку завдання до командної оцінкою

Поділ однієї задачі на підзадачі зазвичай займає в районі 5-30 хвилин, але на деякі історії, що складаються з декількох завдань, у складних випадках може йти пара днів.

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

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

Це ж не агильно

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

Можливий ефект прив'язки

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

  • занадто велика — розділити;
  • занадто маленька — об'єднати з іншого;
  • в самий раз.
При цьому, перед голосуванням всі, кому незрозуміла підзавдання, можуть задати питання.

Розробник не може рости виконуючи завдання, у яких вже все продумано до нього

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

не Можна швидко дати оцінку великої історії

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

Я рекомендую використовувати для попередньої оцінки старі добрі людино-тижня: пів тижня, одна, дві, місяць. Після оцінки історії командою, люди, що дали експертну оцінку, можуть швидко дізнатись наскільки вони помилилися — достатньо перевести їх людино-тижні в story point'и (середню швидкість одного розробника ми знаємо зі статистики).

По можливості намагайтеся не оцінювати завдання до пріоритезації. Якщо після оцінки історії її надовго відкладе, то ви втратите час:

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

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

  • оцінюємо історії з допомогою Planning Poker,
  • приоритезируем,
  • розробник розписує до рішення підзадач,
  • команда оцінює це рішення,
  • розробник пише код.
При такому підході ви все одно отримуєте рев'ю результату проектування до того, як розробник почне писати код. Хоча сумарно такий процес швидше за все займе більше часу.

Приклад
Для прикладу візьмемо таку фічу: хочемо реалізувати push-повідомлення в браузері зі своїм js-плагіном для підписки, з блекджек і поетесами. В ідеалі хочемо:

  • js-плагін працює у всіх браузерах, які підтримують push-повідомлення;
  • js-плагін працює як на https так і на сайтах http;
  • відправляти повідомлення можна як масово вручну, так і за подією для окремих споживачів;
  • відстежувати доставки та кліки в повідомленнях.
Виділимо з цієї фічі MVP — викинемо все що можна, щоб при цьому вийшла корисна хоча б для одного з клієнтів фіча:

  • приберемо підтримку Safari, так як у нього своя реалізація push-повідомлень;
  • приберемо підтримку http сайтів, так як для їх підтримки потрібно писати складний хак;
  • залишимо тільки масову відправку повідомлень, так як більшості клієнтів з https сайтів потрібна в першу чергу саме масова відправка;
  • на початку обійдемося без статистики, так що відстеження доставки і кліків відкладемо на потім.
MVP фічі можна розбити на наступні задачі, кожну з яких можна робити незалежно:

  1. js-бібліотека відповідає за передплату і відображення повідомлень.
  2. Мікро-сервіс, відправляє пуш повідомлення.
  3. UI для масової відправки повідомлень.
Трохи повивчаємо гугловскую документацію web push повідомлень, після чого розіб'ємо першу задачу на підзадачі:

  1. Реалізувати в js-бібліотеці наступні методи:
    • перевірка, що браузер підтримує пуш повідомлення;
    • перевірка, підписаний користувач сайту на повідомлення;

    • підписка на повідомлення.
  2. Написати тести, що перевіряють, що ці методи коректно працюють в браузерах, які підтримують і не підтримують пуш повідомлення.
    Ми використовуємо для цього BrowserStack. В якості альтернативи в цьому пункті може стояти завдання протестить js-методи вручну в різних браузерах.
  3. Навчитися працювати з serviceWorker'ами.
    Обробкою push-повідомлень займається serviceWorker. Ми раніше їх не використовували, тому виділимо 1S на вивчення нової технології.
  4. Написати serviceWorker, обробляє повідомлення. Додати реєстрацію цього serviceWorker'а метод підписки.
  5. Написати тести на serviceWorker.
В результаті ми оцінили першу задачу в 5S (якщо, звичайно, команда погодиться з таким розбиванням). Таким же чином розбиваються і інші завдання.

Трохи про статистику
Оцінка команди підказує, коли історія буде готова. Для цього враховується кількість story points, виконаних за попередні тижні.

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

Щоб така оцінка працювала, необхідно домовитися про максимальні терміни на рев'ю і приймання. Наприклад, у нас відповідальний за рев'ю завдання зобов'язаний зробити перше рев'ю протягом 2 днів з моменту відправки завдання на рев'ю, а доопрацювання за результатами рев'ю повинен приймати протягом дня.

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

Дооцінка завдань

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

Недоцененные story point's не можна використовувати при підрахунку швидкості команди. Якщо команда в минулому спринті зробила історій на 50 story point'ів і під час спринту дооценила їх на 10 story point'ів — це не значить, що наступного спринт можна взяти 60 story point'ів. Беріть 50, так як і цього разу ви могли щось недооцінити.

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

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.