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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SEO Блог

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

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