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

Слід звернути увагу !!! Будь-яка оцінка з огляду на абстрактний характер є суб’єктивною. Скажімо час легше виміряти, а ось продуктивність нажаль значно складніше.

Точність estimate -ів залежить:

  • від досвіду
  • від рівня володіння командою технологій
  • від того в яких проектах брали участь учасники раніше
  • наскільки проект є унікальним, до якого належить домейну

В деякій мірі від перфекціонізму… Наприклад оцінили роботу в «два тижні», базово все зробили за три дні, а решту часу пішло на поліпшення, в результаті зайняло два тижні. Інколи складність полягає у непередбачуваності.

Класичні прийоми оцінки

Poker estimate — команда збирається на мітинг, озвучується завдання, всі учасники на картках пишуть свої estimate, потім їх порівнюють. Автори найбільшого і найменшого значень обґрунтовують свою оцінку. У кінці команда приходить до спільної думки по загальному estimate і окремих завданнях.

Порівняння зі схожими вже раніше виконуваними завданнями — підґрунтя на що ми опираємось у цьому випадку є терміни, які у нас тоді вийшли фактично. Ще є complexity factor, якщо робили щось схоже, але легше / простіше. Враховуємо такий фактор у розрахунках, але із множенням.

Bottom up & top down — спочатку робиться декомпозиція завдання на задачі і оцінюється по-окремо кожна підзадача, потім підсумовуємо. З іншого боку намагаємося оцінити завдання окремо в цілому. Якщо між двома значеннями велика різниця, намагаємося зрозуміти, звідки береться ця різниця?

Стороння експертиза — запрошуються сторонні фахівці й просимо їх зробити для нас оцінку і порівнюємо її зі своєю оцінкою.

У цьому от місці нам варто поговорити про поняття Технічного боргу. Посилання на блог Martin Fowler і трішки цитуємо та ілюструємо.

Технічний борг (Technical Debt) — це метафора, придумана Уордом Каннінґемом, яка визначає думати про справу як деяку сутність, фінансовий борг. Зусилля, необхідні для додання нових особливостей виступають своєрідною платою за борг.

Уявіть, потрібно додати нову функцію. Вимоги сформульовані чітко, для додавання нового функціоналу знадобиться чотири дні, але з поняттям технічного боргу ми підстраховуємось і значить знадобиться шість днів, так щоб гарантовано виконати роботу. Різниця на два дні — це відсотки за боргом. А коли у мене з’являться подібна feature то я уже чітко зможу сказати коли за скільки я справлюсь. Точність оцінки буде вищою.

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

До загальної оцінки додається додатковий час на:

Ризики — 5-20% зверху на ризики. Зазвичай, найскладніші або самі незрозумілі частини системи і будуть найбільш ризикованими, тому, якщо вже є декомпозиція, можна накинути тільки на ці частини. Зазвичай ризик постфактум звучить як «в процесі розробки з’ясувалося, що доведеться переробити щось та і там».

Підстраховка на несподівані моменти форс-мажори — хтось хто володіє важливою інформацією/робить важливу роботу захворів чи звільнився не дай Боже? Сюди ж можна додати виснаження, вигарання, втому від рутини.

Out of scope — вимоги мають властивість оновлюватися і додаватися, це нормально. Ненормально вважати, що початковий естімейт їх покриє. Переглядайте естімейти систематично.

Час на комунікацію — включення у естімейт нормально часу на спілкування з колегами, на code review, на менторинг, на перемикання між завданнями.

Індивідуальна швидкість роботи — коригування на звичайну практику оцінювати по середній мідловій швидкості.

Час на подумати — не варто забувати, що для ознайомлення з завданням і подумати як краще його реалізувати потрібен час.

З наслідків непотрапляння в оцінку:

  • зрив планів релізу;
  • дефіцит бюджету;
  • овертайми;
  • збитки для компанії (в разі замовлень з фіксованою ціною);
  • недовіра і нелояльність клієнта (якщо оплата погодинна);
  • стрес всім по ланцюжку.

Що таке Estimate від команди QA?

Оцінка тестування — логічно це діяльність, яка орієнтована на підрахунок, скільки часу буде потрібно для виконання завдань тестування (перевірки якості). Скільки інформації потрібно зібрати? Скільки часу витратити на збір цієї інформації для прийняття рішення, в контексті даного проекту?

Відповіді, звичайно, залежать від складності, розуміння завдання тестувальником, розуміння продукту іншими зацікавленими особами, присутності перешкод для тестування.

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

Перш за все estimate -и як і саме тестування потрібно розділити на частини:

  • Writing test cases
  • Testing new features
  • Regression testing чи працюють справно старі функції
  • Automation testing

Як оцінити зусилля на тестування?

Перелік методик оцінювання тестування програмного забезпечення:

  • WBS (Work Breakdown Structure)
  • Wideband Delphi technique
  • Point Software Testing Estimation Technique
  • Use – Case Point Method
  • Function Point/Testing Point Analysis
  • Percentage distribution
  • Ad-hoc method

Декомпозиція task into subtasks

  1. Створіть WBS (Work Breakdown Structure), розділивши тестовий проект на невеликі шматочки (tasks).
  2. Розділіть модулі на підмодулі.
  3. Далі розділіть підмодулі на функції.
  4. Розділіть функціональні можливості на підфункціональності.
  5. Перегляньте всі вимоги до тестування, щоб переконатися, що вони додані в WBS.
  6. Визначте кількість завдань (tasks), які Ваша команда повинна виконати.
  7. Оцініть необхідні зусилля для кожного завдання (task -у).
  8. Оцініть тривалість кожного завдання (task -у).

У методі Delphi WBS, Work Breakdown Structure розподіляється на команду, що складається з 3-7 осіб для переоцінки завдань. Підсумкова оцінка базується на основі консенсусу команди.

Цей метод більше говорить про досвід, узагальнені витрати зусиль на ітерацію,  а не про будь-яку статистичну формулу.

Чи буде у Jira Stories уся необхідна інформація для QA Estimates — так коли Workflow у Jira гарно оптимізований.

Three-Point estimation (метод 3-х точок)

При триточковій оцінці спочатку виробляються три значення для кожної задачі на основі попереднього досвіду чи найкращих здогадок наступним чином

На основі цього складають 3 варіанки оцінки: оптимістичний, реалістичний та песимістичний. По-друге, не варто робити різницю між нижньою і верхньою межами більше, ніж 20%.

  • Найкращий варіант для виконання завдання (a) — 120 людино-годин (близько 15 днів).
  • Наймовірніший варіант виконання завдання (b) є 170 людино-годин (приблизно 21 день).
  • Найгірший варіант для виконання завдання (c) — 200 людино-годин (близько 25 днів).

Підсумкова оцінка підраховується за формулою: Е = а + (4*m) + b / 6

У наведеній нище формулі, середньому значенні SD — стандартне відхилення, це значення може дати інформацію про ймовірність правильності оцінки.

Standard Deviation (SD) = (E − O)/6

Use-Case Point Method

Use-case method — суть обрахувати Use-case -и.

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

Function Point / Testing Point Analysis

Дана оцінка базується на обсязі проекту згідно документу requirement specification.

Ключовий фактор тестове покриття: функції або можливості продукту покриті тест-кейсами.

FP (Функціональні точки) — це внутрішні файли, зовнішні інтерфейси, користувацькі входи/виходи, запити тощо.

Формула Caper Jones:

Кількість Тестових випадків(тест-кейсів)=кількість Функціональних точок(FP)x1.2

Процентний розподіл

Методика передбачає, що тестувальник раніше вже протестував подібні проекти і збирались показники з цих проектів. Плюс у цій техніці всім етапам життєвого циклу розробки програмного забезпечення (SDLC) оцінки поділяються на відсотки %. Які теж можуть грунтуватися на минулих даних подібних проектів.

Узагалі щоб оцінки, які базуються на минулому досвіді були більш правдивими потрібно мотивувати себе і дисципліновувати команду постійно оцінювати всі завдання, які надходять, і порівнювати в кінці початкову оцінку з реально витраченим часом (щоб вираховувати, а потім враховувати куди пішов зайвий час, і чому ми переоцінили).

Ідеї як побудувати таблиці можна підгледіти ось тут

Або вести хронометраж наступним чином:

Як схематично виглядає розробка графіку робіт:

Є задачі які ми можемо виконувати паралельно, а деякі слід виконувати виключно послідовно.

Не варто також плутати оцінку завдання і тривалість завдання. Це два різних поняття. Оцінюватися завдання може у 8 людино-годин, а тривалість може розтягнутися на тиждень.

Наші кроки:

  • Окреслюємо завдання які протестовуватимемо
  • Проставляються логічні зв’язки між роботами
  • Робимо оцінки
  • Оцінюємо ймовірну складність фіксів
  • Визначаємо ресурси
  • Оптимізуємо ресурси (кількість виконавців)

Наявність Графіку Виконання Тестування не дає 100% гарантії того, що він буде робочим. Як тільки розпочалася робота, потрібно постійно проводити моніторинг і контроль того як по ньому працюють.

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.