Тикаючи пальцем в небо, чи еволюція однієї метрики

Це замітка виросла з ненаписаного коментаря до колонки Сергія Малярова «Простий шлях» - поділюся, якими способами ми користуємося, щоб знизити невизначеність оцінок у розробці та запрошу ідей з удосконалення.


«Місіонер середньовіччя розповідає , що знайшов точку, де небо стосується Землі »

Гравюра Каміля Фламмаріона, розфарбована Хуго Хайкенвельдером;

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

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

підзадача * Первісна оцінка (ч) * Уточнена оцінка (ч) * Фактична трудомісткість (ч) * Залишилось (ч)

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

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

Ось поруч 2 графіка розподілу щільності ймовірностей - Гаусса, з 20%-ной дисперсією, яке звично нашому інтуїтивному уявленню про ймовірність, і Пуассона. Що ми бачимо:

Разом - у другій версії таблички збору метрики у нас кожен рядок має вигляд:

підзадача * Первісна оцінка (ч) - min * Первісна оцінка - max * Уточнена оцінка (ч) * Фактична трудомісткість (ч) * Залишилось (ч)

Також ми знаємо, що сума уточнених оцінок - це оцінка випадкової величини, розподіленої приблизно відповідно до розподілу Пуассона.

Вдумливий читач напевно вже вирахував, звідки береться lambda (інтенсивність потоку подій): якщо одна подія - це якась елементарна одиниця трудомісткості, то відносна інтенсивність - це кількість таких одиниць в одному акті декомпозиції (тобто, фактично, на скільки підзадач в середньому розбивається одна наша велика задача). Природно, оцінка може бути ієрархічної.

Все? Як би не так. Насправді, ця модель теж досить наївна: наш сферичний програміст в Вакуум рухається тільки вперед, він не виправляє помилок і не замислюється про те, що в світлі останніх змін вимог, первісна архітектура потребує корегування. Тобто, на кожен обсяг зробленої роботи доводиться ще якийсь обсяг виникає технічного боргу. І чим вище зв'язність програми, тим більше цей обсяг технічного боргу залежить від загального обсягу вже написаного коду.

Разом, наступна інкарнація нашої таблички має вигляд:

підзадача * Первісна оцінка (ч) - min * Первісна оцінка - max * Уточнена оцінка (ч) * Фактична трудомісткість (ч) * Залишилось (ч) * Технічний борг * Помилки

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

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

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

можна якось виділити способи розробки, дружні планування? Так, якщо намагатися, щоб:

Як подібний підхід співвідноситься до agilе, чи можна всю цю танець з імовірностями замінити простий метрикою - співвідношення ідеального і реального часу?. Ну, в принципі, так, як будь-яку діфференцііруемую функцію можна замінити лінійною в околі певної точки. Методика ХP дасть нам множник, що переводить ідеальний час в реальне, що працює в околицях якоїсь точки і для якогось проекту. Мені там не подобаються дві речі:

А в нашому варіанті статистичні коефіцієнти відповідає фізичним змістом моделі і беруться більш-менш осмислено - ними можна керувати, ступінь коректності декомпозиції завдань можна формально перевірити, і породжує метрика дає нам уявлення про хід проекту.

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

З моєї точки зору, цінність оцінки трудомісткості полягає не в тому, що ми можемо отримати якусь цифру і сказати її клієнту: за межами однієї-двох ітерацій це все одно занадто неточно, а в тому, що розробка, сполучена з процесом безперервного планування, йде простіше і, в разі розробки на замовлення, краще представимо для клієнта. Правда, при цьому клієнт повинен розуміти статус і обмеження цих оцінок.

Опубліковано: 14/02/12 @ 07:58
Розділ Різне

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

18 лютого, Одеса - Ciklum PHP Суботник
Грейди : оцифровка програмістів. частина перша
43-й випуск подкасту « Відверто про IT кар'єризм ». Бесіда з PR -менеджером компанії Sigma Анастасією Комори
Акція від PostPR : Ваші передплатники - це Ваші очки в PostPR
22 лютого, Львів - Lviv QA Conference