простий шлях

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

Чому так відбувається? Тут є безліч пояснень (включаючи «світ несправедливий і ми всі помремо»). Я розповім про один з них. Воно не те щоб повністю пояснює проблему, скоріше, є одним з факторів. Цей фактор я для себе називаю «простий шлях».

Простий шлях означає, що програміст (менеджер і так далі) розраховує на те, що все буде просто. Він (або вона, іноді навіть воно) буде працювати цілеспрямовано, ні на що не відволікаючись, ніяких проблем виду «торкнув в одному місці - завалилося в іншому» не буде, буде все добре і красиво. Насправді, так не буде, звичайно. І ще (як ніби цього мало) простий шлях означає, що реалізований буде найпряміший сценарій. Не буде ні обробки несподіваних ситуацій (щось на кшталт «у користувача раптово не виявилося кредитної карти»), ні обробки помилок від зовнішніх систем, ні просто обробки помилок (наприклад, в середині візард відвалилася з'єднання з БД; що робити, з якого кроку відновлювати роботу?). А про те, що ось це все зробити теж потрібно, при оцінці люди замислюються мало.

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

Що ж із цим вдіяти? Ну, варіантів отримати більш адекватну оцінку - маса. На цю тему книги написані, великі такі. Наприклад, деякі множать на два (три, чотири) рази оцінку програміста і записують в план ці страшні цифри. А потім наступний менеджер знову помножить на два, ага. Деякі детально опрацьовують завдання до початку роботи над нею, будують всі сценарії і коли всі варіанти зрозумілі - дають оцінку (деякі потім її множать на, скажімо, півтора - на всякий випадок). Є й інші способи, вони приходять з досвідом і відвідування тренінгів. Особисто мені на даний момент наймиліше оцінка в папуг.

Цей спосіб звичайно оцінки використовується в Agile, зокрема в Scrum. Але можна і поза Agile, хто ж вам завадить щось. Завдання при такому підході оцінюються в так званих ідеальних годинах або в feature point'ах. І нові завдання ми оцінюємо по суті по відношенню до старих - стара завдання зайняла три папуги, ця трохи складніше, ага, нехай буде п'ять. І так як стару задачу ми оцінювали теж за «простому шляху», то й нову так само оцінимо. Але подивимося, що стара зайняла 3 дні, значить, ця займе 5 днів, швидше за все. Природно, чим довше команда працює разом, тим оцінка стає точніше. Я поганенько пояснюю, хороші пояснення з прикладами є багато де, в будь-методичці по Scrum як мінімум.

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

Опубліковано: 26/01/12 @ 10:09
Розділ Різне

SEO Блог

простий шлях

Рекомендуємо: