Waterfall і Agile: і все-таки, звідки ефект?

    Усім добрий день! Цей короткий пост присвячений розгляду моделей процесів розробки Waterfall і Agile (на прикладі Scrum і / або Kanban). І ось в чому справа: з точки зору замовника, процес не настільки важливий, скільки термін і бюджет задовільного з точки зору функціоналу результату. І якщо відомо, що (зміни не враховуються) витрати Waterfall-процесу йдуть по S-кривої, а витрати Agile-процесу накопичуються лінійно (так як ресурси використовуються одночасно всі), то як вони повинні відрізнятися по ефективності. Щоб дослідити це питання, необхідно побудувати моделі і порівняти їх, і для цього буде використана нескладна математика.
 
 
     
Рада № 30: Вважайте всюди, де це можливо. Якщо рахунок неможливий — обчислюйте. Використовуйте оцінки, отримані на підставі одного лише експертного судження, тільки лише в крайньому випадку.
Макконнел С. Скільки коштує програмний проект (2007).

 
 
 

Передісторія

Управління проектом, умовно, можна розділити на дві складові — на планування і управління ходом.
 
З цієї точки зору для waterfall все ясно — склали покроковий (аналітика-розробка-тестування) календарний план завдань за оцінками термінів, розподілили завдання і вперед реалізовувати.
 
Зі Scrum і Kanban ненабагато складніше: послідовність планування здійснюється через пріоритети в backlog, розробка контролюється або через burndown chart для всього проекту (в Scrum), або за допомогою lead time (в Kanban). Оцінка складності завдань тягне за собою і оцінку термінів — через трійку ітерацій або завдань стає ясною швидкість, на основі якої можна давати оцінку дати закінчення.
 
У даному пості хід проекту моделюватися НЕ буде (це взагалі собі цілком окрема задача), а буде порівнюватися ефективність планова.
 
 

«На кінчику пера»

План представимо як дві складові:
 
     
Сумарна кількість одиниць (аналог storypoints) складності завдань на весь продукт проекту (P ),
 Кількість притягається в момент t персоналу n (t) <= N (рівність у випадку Agile).
 
Далі, позначимо як r — час на реалізацію однієї одиниці складності завдання одним фахівцем, c — вартість одного фахівця за одиницю часу, T назвемо сумарний час проекту, S — його бюджет, p = p (t ) — кількість виконаної роботи на момент часу t .
 
Тоді для Agile ми маємо, що за одиницю часу ми виконаємо стільки роботи, скільки N людина виконують за раз одиниць завдання:
 
 p 'A (t) = N / r => (Знаючи, що спочатку виконаної роботи немає) p A (t) = N * t / r .
 
Звідки, власне, ясно наступне:
 
 T A = r * P / N; S A (t) = c * N * t; S A = c * r * P .
 
 це все і так ясно взагалі-Очевидно ж, скільки в сумі людина попрацюють, да помножити на час, та на вартість, стільки і буде коштувати проект. У той же час він коштує стільки, скільки коштує вирішити одну задачу, помножити на кількість завдань.
 
 
На цьому поки з Agile закінчимо, на щастя модель його плану виявилася (у моїй версії) досить проста. Все стає складніше з Waterfall-планом, так як в ньому залучаються фахівці по ходу проекту. При цьому, однак, залишається основне співвідношення:
 
 p '(t) = n (t) / r .
 
Вся справа у виборі функції n (t) . Ми знаємо, що в нулі вона нуль, і в кінці проекту — нуль. Більше ми нічого не знаємо. Далі будемо припускати, що вона симетрична, досягає в середині значення N , і росте квадратично (я вибрав квадратичну функцію з тих міркувань, що це найпростіший варіант при заданих умовах).
 
 n (t) = N * 4 * (T — t) * t / T 2 .
 
Знаючи, що p (0) = 0 , можна виписати інтеграл p '(t) :
 
 p (t) = 2 * N * t ^ 2 / (r * T) — 4 * N * t ^ 3 / (3 * r * T ^ 2) => T = 3 * P * r / (2 * N) .
 
 О! А ось це вже цікаво! При обраному законі залучення команди до проекту за часом, довжина проекту виростає в півтора рази! А адже ситуація із залученням не всього персоналу відразу типова для Waterfall.
 
 це все знову-таки інтуїтивно Ясно, що якщо люди роблять завдання відразу, то це скорочує термін. У той же час, якщо весь час задіяний максимум — N людина — то це і є ситуація мінімуму для часу проекту.
 
 
Що у нас з вартістю? Її також можна знайти інтергірованіем (по t ).
 
 s '(t) = c * n (t) => s (t) = 2 * c * N * t ^ 2 * (3 * T — 2 * t) / (3 * T ^ 2) ,
 
звідки
 
 S W = 2 * c * N * T / 3 = c * P * r .
 
Бюджет той же.
 
 не дивно І з чого йому бути іншим, якщо обсяг робіт той же?
 
 

Криві

Переконаємося, що ми отримали S-криву на відрізку [0; T] . Підставимо значення с = 1, r = 2, P = 100, N = 10 і отримаємо T = 30 .
 
Графік p = p (t) для Waterfall:
 
 
Графік s = s (t) для Waterfall:
 
 
 S-подібна крива Це не логістична крива , так як у нас план визначає кількість виконаної роботи в момент часу, а не кількість людина залежить від того, скільки роботи в який момент має бути виконане.
 
 

Трохи висновків

 
Хтось вважатиме даний пост капітанство, і буде недалекий від істини. Адже звичайно, моделі злегка «людожерські», і не враховують зміни (які, по суті, є оновленнями планів). У той же час, якщо збирати різну кількість людей на Waterfall і Agile, терміни можна буде зрівняти, але бюджети будуть різні.
 
Я не буду говорити, що Agile оптимальний (незважаючи на те, що це екстремум за термінами при такому моделюванні) — занадто багато спрощень в моделях. Але цілком можливо, що розглянута механіка пояснює деяку різницю між ефектами при різних підходах, і хтось візьме на озброєння розглянутий принцип для оптимізації своїх проектних планів: залучати якомога більшу кількість людей до вирішення завдань відразу — може знизити термін при збереженні бюджету (хоча і може здаватися, що бюджет збільшиться).
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.