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

Одиниць виміру для оцінки складності вигадано вдосталь. Є нормальні одиниці – години, є «стандарт індустрії» сторіпоінти (цілковите ошуканство), є екзотичні футболки, папуги, нормалізовані щось-там і т.д. Окремо йдуть шкали виміру, способи оголошення, методи страхування та кількість оцінюваних процесів. Тонкощів вистачає, особливо, коли потрібна команда, а не індивідуальна, оцінка розробки.

Забудьте про цифри,
вони не важливі !

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

А до чого тут містика ?

Ви працюєте в компанії освічених людей – у декого по 2 диплома, тривалий інженерний досвід, вони читали про гнучке планування та критичне мислення. Але якщо хтось і навчається плануванню, то не через формалізацію процесів. 

Оцінювання – містична командна практика, якої неможливо навчитися по книгах, лише між своїх колег та за сприятливих умов.

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

Як виглядає іскра ?

Як посмішки та дружне підштрикування на зустрічах, як дейлік, який стартує флудом за 5 хвилин до початку, як азартні суперечки на рефайментах, як включені камери та висунуті язики. Ця містика приємно придуркувата, інколи не дуже серйозна, вміє сваритися, боронитися та радіти. 

Як цю іскру запалити в своїй команді? Щоб точно, так ніхто не зна! Але є умови, які сприяють її появі.

Психологічна безпека та щирість.

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

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

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

Спільне моделювання та дизайн.

Коректній оцінці завжди передують активності, на яких спочатку спільно створюють фічу, а потім спільно розбирають по цеглинах. Чим раніше команда долучається до ціннісного формулювання задач, тим більше контексту вони мають для прийняття рішень під час розробки ПЗ. Проведення спільних воркшопів з моделювання ІТ архітектури, з UX/UI дизайна, з декомпозування та пріоритезації.

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

Неадекватне оцінювання є наслідком браку контекста.
Жорстка привʼязка до складу учасників діскавері процеса та неможливість впливати на дизайн тільки посилюють фрагментарність сприйняття.

Звісно треба вміти і в години, і в футболки, і знатися на фокус-покус факторах, і на підрахунках обʼємів спринтів, і на хитрощах, як менеджерів заспокоювати, і тямити різницю між «закласти ризики» та «оцінити ризики» – ці технічні речі спрощують планування. Але завжди памʼятаємо, що коректна оцінка – це побічний продукт згладженості. Скрам Майстре, допоможи команді знюхатись. 

Мої спостереження та лайфгаки:

1. Бекендерам простіше влучити в оцінку, ніж фронтендерам (хех, мабуть фронтенд таки складніший?)

2. Якщо тестувальники своїми руками не дизайнили фічу, вони занадто оптимістичні в прогнозах.

3. Оцінюють ті люди, хто моделював, декомпозував та пріорітезував фічу. Тобто хто дизайнів – той і оцінює, інакше це буде гадання.

4. Чим виразніша декомпозиція користувацького функціоналу, тим простіше влучити в оцінку. У вас є MVP фічі? Виокремить з нього ще одне MVP, а потім приберіть зайве, а тепер перегляньте ваші оцінки.

5. Не оцінюйте окремі екрани, кнопки, форми, інтерфейси чи переходи. Оцінюйте логічно завершені послідовності, невелички use case або user story.

⚠️ Планування розробки повинне чіпляти тему реліза на прод. Нікого не цікавить оцінка кодінгу, чи тестування задачі на фіча-гілці, лише “коли можна користуватись? ”. Спробуйте плануватись від зворотного – “що ми зможемо зарелізить в кінці спринта?”

✊ Легких планувань та зрозумілих оцінок

До речі, ось тут, я написав статтю про різницю між спроможністю та винуватістю в команді, текст буде гарним доповненням до теми зі оцінкою.