Оцінювання задач у гнучкій розробці: від історії до спринту
У процесі роботи над Agile-проєктом, команда планує свою діяльність на майбутні спринти, створюючи так звані “історії користувача”. Кожна історія – це окрема, самостійна функціональна одиниця, що описує певну дію разом із критеріями її успішного виконання.
Спринт зазвичай триває від двох до чотирьох тижнів. За цей період команда повинна визначити обсяг роботи, який вона здатна виконати в межах цього спринту, зберігаючи при цьому темп та дотримуючись встановлених термінів.
У традиційному підході до управління проєктами, оцінка роботи часто виражається в людино-днях. Тобто, визначається, скільки працівників потрібно для виконання певного завдання. Таким чином, при оцінюванні фокус завжди зосереджений на кількості днів та необхідній кількості людей.
У гнучких проєктах все відбувається інакше. Тут вже не вимірюють зусилля в днях або кількості задіяних людей. Більше того, використання людино-днів як одиниці виміру категорично відкидається. Натомість команда використовує єдину, загальноприйняту оцінку для кожної історії, що відображає її загальну складність.
Яке саме значення використовувати – не має принципового значення. Однак, найпоширенішим методом є застосування так званих “Story Points” (балів історії). Як правило, це числа Фібоначчі, що починаються з 0, 1, 2, 3, 5, 8, 13, 21 і так далі. Кожне наступне число є сумою двох попередніх. Це дозволяє чітко розрізнити загальну складність різних історій, оскільки кожне наступне число значно більше за попереднє.
Але не варто обмежуватися лише Story Points. Можна використовувати, наприклад, розміри одягу (XXS, XS, S, M, L, XL, XXL) або навіть назви тварин із зоопарку. Головне, щоб команда погодила між собою єдиний підхід.
В кінцевому підсумку, оцінка залежить від спільної думки усієї команди щодо того, яке число (або тварина) найкраще відображає загальну складність конкретної історії. Важливо розуміти, що це не про час. Час для спринту визначено на початку, і він залишається постійним. Команда має завершити кожну історію, взяту в спринт, саме в рамках цього спринту.
Компоненти оцінки балів історії
Оцінювання за допомогою балів історії – це не лише визначення складності задачі. Команда повинна розглянути кілька різних аспектів і відобразити їх у кінцевому значенні оцінки.
Кінцева оцінка – це комбінація різних факторів, виражена в одному числі. Розглянемо, що саме має враховувати така оцінка:
#1. Технічна складність
Якщо оцінювання проводять розробники, то технічна складність є першим аспектом, на який вони звернуть увагу.
І це цілком логічно. Саме технічні спеціалісти найкраще розуміють, як оцінити технічні аспекти історії. При цьому команда може використовувати наступні підказки:
- Порівняння з іншими, вже оціненими історіями.
- Кількість файлів коду, які потрібно створити або змінити.
- Обсяг змін, які необхідно внести у оточуючі системи.
- Складність алгоритму або логіки процесу.
#2. Зовнішні залежності та ризики
Часто успіх історії залежить не лише від зусиль команди, але й від внеску інших команд або окремих осіб, які не входять до її складу.
Оцінювати простіше ті історії, які команда може виконати самостійно. Якщо ж потрібна допомога ззовні, ситуація ускладнюється. Для інших людей, ці завдання можуть не бути пріоритетними. Команда має враховувати цей фактор при оцінюванні.
Ступінь впливу цього фактора на загальну оцінку залежить від попереднього досвіду команди. З часом команда набуває розуміння того, як зовнішні фактори можуть ускладнити успішне завершення історії.
#3. Фактор повторного використання
Необхідно також враховувати, скільки вже наявних компонентів команда може повторно використати для виконання історії. Якщо частина необхідної функціональності вже існує, то немає потреби розробляти її з нуля. Це значно прискорює процес.
Таким чином, можливість повторного використання може зменшити загальну оцінку, навіть якщо без цього історія була б набагато складнішою.
#4. Розуміння власної команди
На відміну від оцінки в людино-днях, оцінка в балах історії враховує знання про можливості та досвід команди.
З часом, працюючи разом, члени команди починають краще розуміти один одного, їхні сильні сторони та навички. Враховуючи цей фактор, команда може більш об’єктивно оцінювати складність історії.
Якщо історія вимагає спеціальних навичок, і хтось з команди володіє ними на високому рівні, то виконання задачі не буде складним. Якщо ж у команді немає необхідних навичок, то на вивчення теми знадобиться більше часу, що має бути відображено в оцінці.
Процес оцінювання історії
Оцінка кожної історії – це результат колективної роботи. Ніхто не має домінувати в процесі визначення складності задачі. Мета полягає в тому, щоб команда обговорювала оцінку, доки усі не прийдуть до згоди щодо єдиного значення.
Оцінювання можна проводити безпосередньо під час обговорення деталей спринту, або ж виділити для цього спеціальний час.
Приклад процесу оцінювання
- Оберіть інструмент для оцінювання, наприклад, Planning Poker або дошку Miro.
- Розмістіть історію на дошці. Обговоріть її деталі, переконайтеся, що всі розуміють завдання.
- Розпочніть оцінювання. Кожен член команди обирає число зі шкали Фібоначчі.
- Перегляньте результати. Обговоріть різницю в оцінках. Запропонуйте тим, хто поставив найменшу оцінку, пояснити свій вибір, а також тим, хто поставив найвищу. Мета – досягти єдиного розуміння складності історії.
- Проведіть повторне оцінювання. Здебільшого команда дійде згоди щодо одного-двох варіантів. Знову обговоріть відмінності. Залежно від ситуації, команда обере одне з цих чисел або ж проведе ще один раунд оцінювання.
- Оцінювання завершується тоді, коли всі члени команди погоджуються з кінцевою оцінкою. Це має бути рішення всієї команди, а не окремих її учасників. В майбутньому, будь-хто з команди може виконувати цю історію, тому важливо, щоб усі були згодні зі складністю.
Зобов’язання щодо плану спринту
Після оцінювання історій, команда має перелік історій з оцінками та пріоритетами. Далі команда переходить до планування спринту, вибираючи історії для наступного спринту.
Вибір історій базується на наступних критеріях:
✅ Історії з найвищими пріоритетами розглядаються першими.
✅ Команда враховує свій досвід щодо кількості балів історії, які вони здатні виконати за один спринт. Це розуміння приходить з часом та досвідом.
✅ Важливо враховувати не лише загальну кількість балів та пріоритет, а і розподіл навичок між членами команди. Наприклад, якщо в команді є лише двоє фронтенд-розробників, не варто обирати лише історії, що стосуються фронтенду. Це призведе до перевантаження цих двох людей, а решта команди буде залучена недостатньо. Ефективність залежить від поєднання знань команди та її можливості швидко створювати контент.
Фактор швидкості
Швидкість команди – це показник її готовності до роботи в майбутньому спринті. Це не пов’язано з кількістю очок історії.
Для точного планування спринту, об’єднуються два фактори:
- Швидкість команди – вимірюється в днях. Один день роботи одного члена команди – це одна одиниця швидкості. Команда з 10 людей, що працюють протягом 2 тижнів, має швидкість 100.
- Середня кількість балів історії, що виконується за спринт – вимірюється в балах історії. Це число базується на попередньому досвіді.
Потрібен час та практика для визначення оптимальних значень.
Переваги та поширені помилки
Часто команди ускладнюють собі процес переходу до гнучких методологій. Потрібно “зрозуміти” концепцію, перш ніж почати працювати в цьому режимі.
На жаль, цей перший крок є найскладнішим. У консервативній корпоративній культурі цей процес може тривати навіть роки.
Коли команда “зрозуміє” принцип оцінювання, відбудуться наступні зміни:
- Зникає необхідність розраховувати людей або дні для визначення термінів виконання.
- Команда навчиться створювати історії, які можна виконати в рамках спринту. Якщо історія виявиться заскладною, її поділять на кілька менших історій.
- Команда точно оцінює кожну частину роботи. Під час планування спринту, чітко зрозуміло, коли це буде зроблено.
- Підвищується надійність та передбачуваність роботи команди.
- Члени команди працюють “на одній хвилі”. Вони розуміють історію приблизно однаково. З часом, можливо, не потрібно буде навіть проводити оцінювання, так як усі будуть бачити однакове значення, і це дозволить приступати до роботи без формальних процедур.
Якщо ж команда не розуміє процесу, то можуть виникати такі помилки:
- Продовження використання оцінки в людино-днях. Спроби конвертувати бали історії в дні.
- Керівництво порівнює команди на основі кількості балів історії за спринт. Це некоректно, так як кожна команда оцінює історії по-різному.
- Оцінка складності для однієї команди може означати намалювати коло, а для іншої – будинок з чотирма вікнами та двома дверима.
- Обмеження шкали оцінювання до 2-4 значень. Не потрібно боятися використовувати весь спектр чисел Фібоначчі.
- Оцінювання проводиться лише старшими співробітниками. Думка кожного члена команди повинна враховуватися.
Заключні слова
Перехід від традиційних методів до гнучкого оцінювання – складний процес, що вимагає адаптації з обох сторін. Команда та керівництво повинні розуміти процес. У випадку, якщо хтось не розуміє, перехідний період може виявитися непростим.
Проте, коли всі починають розуміти процес, відбуваються позитивні зміни. Команди краще оцінюють та планують свою роботу, а керівництво отримує більш передбачувані результати та дорожні карти.
Далі перевірте нездорові процеси, які можуть зіпсувати ваш спринт.