Як оцінювати задачі?

TL;DR

1. Перевірити вхідні дані задачі та заестімейтити естімейт.
2. Детально розпланувати реалізацію задачі.
3. Розбити задачу на підзадачі.
4. Оцінити складність кожної з підзадач.
5. Ревʼю естімейта з @ye.pohranichna

Вступ

Оцінка будь-якої задачі має проходити певний набір етапів:

• До-планувальний етап
• Планувальний етап
• Етап переведення плану у час
• Ревʼю естімейта
• Перенесення естімейту в Jira

1. До-планувальний етап

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

Чек-ліст:

• Чи є апі? (поверхнева оцінка)
• Чи є макет? (поверхнева оцінка)
• Чи є дока з описом задачі? (поверхнева оцінка)
• Чи є специфічні вхідні дані — якщо вони потрібні? (репродакшен степс, середовище, етс)

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

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

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

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

2. Планувальний етап (найважливіший)

Переводимо задачу в статус "Investigation". Також можна створити на себе ж таску в джирі з назвою "Естімейт задачі (назва задачі)" і в неї трекати час, витрачений на естімейт.

В кінці цього етапу ми зможемо розділити задачу на підзадачі та знати, скільки часу на них потрібно.

Як саме планувати задачу:

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

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

Немає різниці в якому саме форматі ви зображатимете для себе план реалізації. Хтось робить це в гугл доці або в ексельці, хтось вручну на папірцях в клітинку.
Важливо, щоб вам було зручно і зрозуміло, які блоки робіт входять в задачу.
(Про кінцеве оформлення естімейту описано в розділі "Ревью естімейта")

Оцінка вхідних даних

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

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

Розбиття задачі на підзадачі + нюанси

Коли план реалізації зрозумілий, ми ділимо задачу на підзадачі.

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

В ідеалі, кожна підзадача має бути такою, що її можна зробити не більше ніж за 1 день. Якщо підзадача займає більше – ми розбиваємо її на менші.

Але, може скластися ситуація, коли якась задача на стільки непередбачувана, що ми не можемо її оцінити, або оцінка є дуже розпливчастою, наприклад, від пів дня до тижня. Нажаль, на такі задачі ради немає, і тоді їх можна лишити "як є", при цьому, письмово обґрунтувавши цю невизначеність.

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

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

Чек-ліст питань, які допоможуть спланувати задачу:

• які апішки потрібні (на беці) чи вони є?
• розібратись в нюансах апішек, якщо вони є
• розбити роботу предметно на те, що саме треба робити: які блоки верстати, які компоненти створювати, які компоненти з потрібних є в нашій лібє (ВАЖЛИВО: опираючись на макет)
• чи потрібно буде щось рефакторити?
• чи треба писати апішки (на боці клієнта, мається на увазі) ?
• чи треба дописувати стор ?
• чи треба робити щось сильно нове? (консультація з тим, хто шарить або закласти додатковий час на новизну)
• чи треба залучати сторонні бібліотеки?
• чи треба писати документацію?
• закласти час на тести

3. Етап переведення плану у складність (використовувати за потреби)

На цьому етапі кожна з підзадач оцінюється по 5-бальній шкалі складності:

• 1 — дуже просто
• 2 — просто
• 3 — середньо
• 4 — складно
• 5 — дуже складно

Чому не сторі-поінти? — щоб на перший час спростити користування гайдлайном і процес естімейту. якщо виявиться, що ця система якимось чином не підходить, то тоді вертатися до сторі поінтів, і всякої такої штуки.

Важливий момент: ми оцінюємо не час виконання, а саме складність. Я думаю (можливо, думка має бути скоригована), уявлення про складність має бути +- однаковим для всіх. При цьому, складність переходить в час, але час буде у всіх різним. І це повністю окей.

4. Етап переведення складності у час

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

Також на цьому етапі варто закладати час на ревью кожної підзадачі.

5. Ревʼю естімейта

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

Залучаємо Лізу (@ye.pohranichna) для цього 🙂
В коментах до таски, яку оцінювали, залишаємо естімейт з відміткою Лізи.

Формат оформлення естімейту приблизно такий:

Загальний естімейт: 2d 2h

1. Назва підзадачі 1 (8h)
   • крок 1
   • крок 2
   • крок 3
2. Назва підзадачі 2 (3h)
3. Назва підзадачі 3 (3h)
4. Назва підзадачі 4 (4h)
   • крок 1
   • крок 2

Важливо: 1 підзадача = 1 таска в джирі = 1 ПР

Нагадую, кожна підзадача має бути такою, що її можна зробити не більше ніж за 1 день.

Кінцевим результатом етапу ревью має бути апрувнутий естімейт та проінформований про це ПМ.

Перенесення естімейту в Jira

Лише після апруву, естімейт переноситься в джиру.

Тут можливо декілька нюансів через поточні налаштування джири, а також поточні домовленості:

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

Назви сабтасок мають бути конкретними, щоб по ним було зрозуміло, який блок робіт в межах сабтаски проводиться.

Коли сабтаски створені, то далі ми проставляємо свої естімейти в графу "original estimate": в основну таску, а також в кожну підтаску.
Це дуже важливий етап! Його не можна пропускати!
Адже саме завдяки цьому менеджери зможуть відстежувати прогрес по задачі.

Кінцевим результатом цього етапу є новостворені таски в джирі та проставлений в них естімейт.

Як оперувати гіт-гілками у випадку великих фіч:

1. Створюється окрема гілка для всієї фічі - по-суті гілка основної таски.
2. Від неї "відколюються" гілки для сабатсок, які після ревью в неї ж і мерджаться.
3. На тест передається лише основна таска.
4. Сабтаски закриваються після ревью з коментом "Робота по підтасці завершена. Тестування буде проходити в межах основної таски"

Кінцеві артефакти оцінки задачі

• План задачі, описаний у таску в джирі.
• Таска в джирі розбита на підтаски (як правило, має бути завжди, але можуть бути виключення).
• Проставлений реальний (з закладеними ризиками) часовий естімейт у кожну з тасок.

Чек-лісти

Чек-ліст перед плануванням задачі

• Чи є апі? (поверхнева оцінка)
• Чи є макет? (поверхнева оцінка)
• Чи є специфічні вхідні дані — якщо вони потрібні? (репродакшен степс, середовище, етс)

Чек-ліст питань, які допоможуть спланувати задачу

• які апішки потрібні (на беці) чи вони є?
• розібратись в нюансах апішек, якщо вони є
• розбити роботу предметно на те, що саме треба робити: які блоки верстати, які компоненти створювати, які компоненти з потрібних є в нашій лібє (ВАЖЛИВО: опираючись на макет)
• чи треба писати апішки (на боці клієнта, мається на увазі) ?
• чи треба дописувати стор ?
• чи треба робити щось нове? (закласти додатковий час на новизну, час на розібратись)
• чи треба писати документацію?
• закласти час на тести

Розумні думки, які не понятно куди запхати

• Прострочений естімейт - це не трагедія.
  Якщо під час реалізації виявилось, що задача зайняла більше часу - так буває. Важливо в процесі виконання тримати менеджера в курсі цього, а також побачити, який досвід можна взяти, якщо естімейт вийшов неточним.
• Якщо виконання задачі в 2-3 рази швидше проставленого естімейту - це також ознака неточного естімейту. І варто розглянути, чому так відбулось.
  З точки зору менеджмента такі речі також заважають плануванню реліза. Хоча, звісно, це значно приємніша ситуація, ніж коли задача прострочена.
• Строння ліба - це біла пляма естімейту.
  Майже неможливо передбачити, до яких проблем може призвести її використання. Тому важливо попередити менеджера про це, а також тримати його в курсі просування по тасці.
• Час на ревью бажано додавати в кожну підзадачу, а не створювати на це окрему.
  Адже кожна підтаска матиме свій ПР, а отже окремо проходитиме ревью.