Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!20.10.2024
Оцінювання задач
Я як розробник не люблю детально оцінювати роботу в часі. Зокрема тому, що в мене практично завжди стоїть декілька паралельних задач, плюс підтримка, плюс допомога. В таких обставинах оцінки не складаються. Виходить, найточніша оцінка — це чи я встигну зробити задачу на цій ітерації. І це більше обіцянка-зобовʼязання, ніж оцінка.
З іншого боку, в оцінювання є надважливий побічний ефект: воно примушує розглянути задачу ближче. Розбити її на кроки. Помітити брак інформації або рішень. Це, може, й не необхідно для виконання, але значно його спростить.
У нас наразі є нарада “для збагачення задач”. Оцінюванням ми там не займаємось, натомість командою обговорюємо все наплановане та висвітлюємо незрозумілі моменти. Також інколи розкладаємо на підзадачі. Мабуть, моя улюблена нарада. Зовсім не сумую за дебатами “це задача на 2 бали або на 3”.
В оцінювання є й інший бік: для ефективного керування потрібно знати, скільки займе та чи інша робота, щоб координувати її з іншими командами та планами. Так от, я колись працював на клієнта, в якого релізи були жорстко та беззастережно привʼязані до календаря. Там я на практиці побачив закон Паркінсона: робота заповнює весь відведений час. Звісно, ніколи не було такого, щоб графік був вільний — навпаки, майже кожний реліз був спішним. Але з тим, кожний реліз відбувався, в цілком робочому стані.
Дехто сприймає закон Паркінсона, як наслідок ліні, але я з цим не згодний, принаймні для нашої роботи. Програмування — творча діяльність; в ній завжди є що доробити… або залишити не доробленим.
Тому я вважаю, що для високорівневого планування розробки ПЗ достатньо мати вірні приблизні оцінки — може, в місяцях — та ставити за мету дотримуватись цих термінів. Але! Щоб вірно оцінити роботу навіть в місяцях, без деталізації не обійтися. Можна це назвати… оцінюванням з одного балу.