Корисні метрики для оцінки проектів
Навіщо щось виміряти?
Є проект. Ваш улюблений, рідний, якому ви бажаєте рости та процвітати. Але як ви оціните його процвітання, якщо немає критеріїв цього процвітання? Як ви зможете оперативно зреагувати на проблеми до того, як вони стали невиправними, якщо не використовуватимете «датчик майбутньої Ж»? Як ви зрозумієте, що саме слід покращувати, якщо вам невідоме джерело проблем?
Якщо коротко, то метрики потрібні, щоб ефективно керувати проектом: діагностувати проблеми, локалізувати їх, виправляти і перевіряти, чи вибрані вами способи вирішення проблеми допомагають.
Я поділюся різними типами метрик, кожні з яких перевірені та принесли чималу користь. Щоразу, впроваджуючи їх, будь-якій команді дуже ліньки і некомфортно: доводиться зберігати додаткову інформацію, щось міряти, розводити бюрократію. Але коли ми вперше отримуємо від будь-якої метрики користь, на зміну лінощів приходять дисципліна і глибоке розуміння важливості тієї чи іншої метрики.
А якщо не приходять, то метрику можна сміливо викинути ;)
Історія 1: Хто впустив його сюди?
В одній чудовій компанії керівництво скаржилося на «неякісний продукт», провиною чому тестування. Моїм завданням було проаналізувати причини цього прикрого непорозуміння і якось їх вирішити, причому природно вчора.
Завдання #1 для мене стало очевидним:оцінка % пропущених помилок: а чи правда, що тестувальники щось пропускають? Для цього ми ввели в баг-трекер поле «повідомив клієнт», помітили таким чином старі баги і порахували. Відсоток становить трохи більше 5%, причому далеко не всі з них були критичними.
Чи багато це чи мало? На мій досвід це досить хороший відсоток. Звідки тоді думка, щотестувальники багато пропускають?
Ми ввели ще одне поле: відтворюється на релізній версії. Щоразу, реєструючи нову помилку з тестового стенду, тестувальники перевіряли, чи є вона в останній версії користувача: можливо, користувачі просто не повідомляють конкретні помилки? Результат за перший місяць - близько 40% помилок, зареєстрованих у баг-трекер, відтворюються в релізній версії.
Виходить, ми пропускаємо дійсно багато, але користувачі не повідомляють про конкретні помилки, а ось думка «ваш софт — відстій!» вони явно формується. Таким чином ми сформували метрики-датчики: що не так:
- % пропущених у релізну версію помилок
- % помилок, повідомлених користувачем
Для відповіді на це питання нам потрібно копати далі, і шукати нові метрики, які дадуть відповідь на це запитання.
В даному випадку ми для всіх пропущених помилок додали ще одне поле: «Причина пропуску». І на вибір вказуємо, чому не завели цю багу раніше:
- невідома вимога (не знали чи не зрозуміли, що це було потрібно)
- не врахували тест (не додумалися тестувати це ТАК)
- не протестували (тест був, його перевірили, але потім функціонал зламався, а повторно цю область не перевіряли)
Брейнштормінг «як розв'язати цю загадку» призвів до різних рішень: щотижневе обговорення пропущених дефектів у групі тестування, узгодження тестів з аналітиками та розробниками, пряме спілкування з користувачами для дослідження їх оточення та умов тощо. Впроваджуючи потихеньку ці нові процедури, ми знизили лише за 2 місяці % пропущених помилок до 20%. НЕ розширюючи команду, НЕ збільшуючи терміни.
Історія 2: Звідки дрова?
Ця історія стосується одного із моїх власних проектів. Ми розробляємо якийсь потрібний і корисний сервіс, і терміни розробки не дуже гріли мою душу. Природно, у мене на проекті все ну дуже добре з тестуванням, але чому розробка ледве плететься?
Звичайно, я почала зі спроб виміряти свої суб'єктивні відчуття «повільно». Як це зрозуміти? Із чим порівняти? KLOC на місяць? Фіч в ітерацію? Середні зриви термінів щодо плану? Звичайно, перші 2 метрики нічого корисного не принесуть, тому я почала дивитися % зривів термінів по фічах (ітерації у нас не мають фіксованого набору фіч, тому серйозно спізнитися не можуть - що за 2 тижні встигли зробити і протестувати, те й викладаємо). Але фічі!
Я стала аналізувати: в середньому на 1 невелику фічу припадає від 15 до 40 багів, а час на їхній фікс йде більше, ніж на розробку самої фічі. Чому? Чи багато це чи мало? Розробники скаржаться, що дуже багато прохань на зміну вже розробленого функціоналу — чи це правда чи суб'єктивна помилкова оцінка?
Копаємо далі. Я вводжу в бідний нещасний набряклий від додаткових полів баг-трекер поле: «Причина появи помилки». Не пропуски, як у Історії #1, саме ПОЯВИ. Це поле заповнює розробник у момент комміту, коли він ужеточно знає, що як він виправляв. І варіанти відповіді такі:
- Код (ось взяли та накосячили)
- Нерозуміння вимог («Ах я ж не зрозумів, що саме це було потрібно!»)
- Зміна вимог (product owner подивився на результат і сказав «не, насправді потрібно по-іншому, а не так, як я спочатку просив»)
Варіантів вирішення проблеми ми знайшли багато, починаючи від найму технічного письменника, який визнаватиме вимоги у product owner'а і документуватиме докладно все те, що ми описуємо в пару рядків і закінчуючи product owner'ом, переведеним у секретарі, цілодобово документуючим нові фічі . Жоден з цих варіантів нам не сподобався, вони надто бюрократичні для команди з 4 розробників, що сидять в одному кабінеті. Тому ми зробили таке:
- Product owner коротко, як і завжди, описує нову фічу
- Розробник, коли доходить до неї, ретельно обмірковує спосіб реалізації, як це виглядатиме, що з цією фічею йому взагалі робити
- Після цього розробник і РВ сідають разом, і розробник докладно розповідає свої думки на тему світлого майбутнього фічі, що розробляється.
- Розробник за жодних умов не починає роботу над новою фічею, не пройшовши вищеописаний алгоритм дій і не погодивши своє бачення з РВ
- Тестувальник найчастіше бере участь у цьому процесі, заздалегідь підказуючи складні моменти, які він тестуватиме
вартових «болталок» на тиждень, на які відривається 2-3 особи. Кількість багів, що заводилися, знизилося, з них помилок коду стало більше 50% — тому нашим наступним завданням буде впровадження code review, т.к. Тепер у нас нова «головна проблема».
Але від метрики-аналізатора ми повернулися до метрики-датчика і зрозуміли, що жодного разу з весни не зірвали терміни за фічею більше ніж на 50%, хоча до цього середнє значення зриву було від 50% до 100%, а іноді й більше.
І це лише початок! ;-)
Історія #3: Хто гальмує розробників?
Ще одна історія стосується мого зовсім недавнього досвіду у сторонній компанії. Справжній-справжній Agile, щотижневі ітерації… Та щотижневі зриви термінів!
Причина, заявлена керівництвом компанії: «Розробники допускають надто багато багів».
Я почала аналізувати, як це відбувається. Я просто брала участь у процесі та спостерігала з боку, як це дуже здорово описано у книзі Імаї «Гемба Кайдзен». І ось що я побачила: Релізи по четвергах, п'ятниця підготовчий до нової ітерації день. У вівторок-середу з'являється збирання на тестування. У середу-четвер заводяться дефекти. У п'ятницю, замість підготовки до нової ітерації, розробники екстрено виправляють баги і так щотижня.
Я попросила в таск-трекері, де дублюються фічі з дошки, проставляти статуси за фічею: фіча прийнята в розробку, фіча віддана на тестування, фіча протестована і відправлена на доопрацювання, фіча протестована і прийнята в реліз.
І як ви думаєте, який середній термін між «фічем віддано на тестування» та «фічем протестовано і відправлено на доопрацювання»? 1,5 дні!
Причому іноді - з ЄДИНИМ блокуючим дефектом.
Розробники у цій компанії скаржилися нагальмівних тестувальників, але тестувальники та керівництво були проти розробників: "ви самі повинні тестувати і не віддавати сирий продукт". Але ж кесареві кесарево!
Отже, метрика є, 1,5 дня неприпустимо багато, хочемо скоротити щонайменше втричі — це має прискорити релізи на день. Як це зробити? Знову брейншторм, знову купа ідей, 90% учасників процесу наполягають, що «розробники повинні тестувати самі».
Термін з 1,5 до 0,5 днів ми скоротили дуже швидко, але на практиці ми досягли іншої, більш серйозної зміни: % переведених у статус «відправлено на доопрацювання» фіч знизився майже з 80 до майже 20! Тобто у 4 рази! Тобто 80% фіч тепер одразу приймався після переведення в статус «тестування», тому що незадовго до переведення в цей статус проходило тестування «на льоту», яке так сильно скорочує і час реєстрації помилок, і вартість їх виправлення.
До речі, історія 3 — єдина, де ми одразу досягли поставленої мети. Зриви ітерацій все ще бувають, але тепер це виняток, і майже щочетверга команда розробки йде додому вчасно, а в п'ятницю, правда, починається підготовка до наступної ітерації.
Я дуже не хотіла малювати сухі формули, філософствувати та теоретизувати. Я розповіла конкретні історії зі свіжого (2012!) досвіду. Історії, в яких ми скорочували терміни та підвищували якість, не змінюючи бюджет.
Ви все ще не готові використати метрики з користю?