Ситуація: запит від керівництва на оцінку трудомісткості проекту, який планується показати на щорічній виставці за кордоном.
Проблема: оцінка трудомісткості (скільки часу займе розробка) поєднується з цілями проекту ("показати на виставці у визначений час").
Рішення: ітеративне вирівнювання цілей та оцінок. Наприклад: урізання функціоналу для запобігання зривам термінів здачі проекту.
2 . Говорити «Так» тоді , коли ви , насправді , розумієте «Ні».
Ситуація: за столом переговорів інтравертивні розробники та екстравертивні, досвідчені "продажники".
Питання: через який час розробники погодяться на всі "вкидання" "продажників"?
3. Давати обіцянки на ранній стадії Конуса невизначеності.
Горизонтальна вісь: час
Вертикальна вісь: значення помилки , яка закладається при оцінці трудомісткості
Проблема: не можна давати обіцянки в той момент часу (крайня ліва частина конуса) , коли величина помилки ще занадто велика. За МакКоннелом межа впевненості десь в районі 1,5 x , тобто той момент часу , коли ймовірна помилка становитиме 1,5 рази як у більшу , так і в меншу сторону. Давати обіцянки раніше цього моменту - свідомо піддавати себе занадто великому ризику.
4 . Припускати, що недооцінка надає нейтральний вплив на результати проекту.
Проблема: вартість переоцінки зростає лінійно (за законом Паркінсона ) . У той же час вартість недооцінки збільшується лавиноподібно у міру того, як зростає помилка недооцінки необхідних зусиль. У разі недооцінки прогнозувати додаткові зусилля куди складніше , ніж у випадку переоцінки .
5 . Фокусуватися на методах оцінки на противагу досвіду практики застосування.
Оцінка трудомісткості в основі своїй - це не тільки конкретні методики , а й практика їх застосування. Це набір вдалих підходів , які добре зарекомендували себе . Мистецтвом же є застосування потрібної методики в потрібний час і в потрібному місці.
6 . Робити оцінки в «Зоні неймовірності».
Тут доречна фраза: "9 жінок за 1 місяць не народять дитину".
Зменшення строків при заданій трудомісткості не може відбуватися нескінченно - є межа. Так от ідея даного пункту полягає в тому , щоб не виробляти оцінок за цією межею . Такі оцінки не можуть бути заможними . Межа зменшення знаходиться десь близько 25 % від номінальних оцінок.
7. Переоцінювати вигоду від нових методів і технологій.
Використання нових технологій пов'язане з :
- витратами на навчання
- ризиками , пов'язаними з використанням неперевіреної технології
- вигода від використання більш досконалої технології виявляється менше , ніж зазвичай заявлено
Особиста рекомендація макКоннела : «Вважати, що використання нової технології на початку гарантовано знизить продуктивність розробки».
8. Використовувати тільки один метод оцінки трудомісткості.
У цьому пункті автор застерігає від двох речей:
- використання тільки однієї методики оцінки
- усереднення значень , отриманих різними методиками
При використанні різних методик важливо зрозуміти , чому виникли розбіжності .
9 . Нехтувати спеціалізованим ПО для оцінки трудомісткості.
Моделювання за допомогою комп'ютерних програм може підвищити адекватність оцінок. Природно, використання спеціальних засобів не гарантує вам надійний і співвідношення оцінок. Але при вмілому використанні може помітно підвищити їх точність.
10 . Давати поспішні оцінки.
Останнє, але від цього не менш важливе , затвердження складається в застереженні від використання поспішних, необгрунтованих оцінок. Важливо завжди брати невеликий таймаут для проведення хоча б невеликих попередніх оцінок.
Як на мене все ж частіше (читай - практично щоденно) зустрічаються 10 "Майже смертних гріхів в оцінці трудомісткості розробки ПЗ", короткий опис яких поданий нижче:
20. Оцінювати скільки часу займе зробити «ЦЕ » до того , як хто-небудь розбереться , що ж «ЦЕ » все-таки таке
19. Припускати , що найбільш достовірні оцінки надходять від людей з найсильнішими голосовими зв'язками
18. Розповідати кому-небудь , що Ви пишете книгу з оцінки трудомісткості ПО , тому що вони запитають «І коли ви плануєте закінчити свою книгу (прим., оцінюєте термін закінчення ) ? »
17 . Робити оцінки нового проекту , порівнюючи його з попереднім проектом ...
... Оцінки якого перевищені ... і в підсумку розуміючи , що Ви засновуєте плани нового проекту на результатах попереднього проекту замість того , щоб використовувати інформацію , адекватну поточної ситуації
17а . Робити оцінки нового проекту , порівнюючи його з попереднім проектом ...
... В якому було дуже багато позаурочної роботи ... і в підсумку розуміючи , що Ви так само закладаєте багато позаурочної роботи в новий проект
16. Припускати , що відділ продажів робить оцінки краще, ніж самі розробники
15. Робити оцінки , припускаючи , що ніхто не піде на тренінг ...
... Не піде на мітинг ... нікого не « зірвуть » на інший проект ... ніхто не буде потрібен для підтримки « ключового замовника» ... не піде у відпустку ... не захворіє ...
14. Давати оцінки з високим ступенем точності ( напр. , « 64,7 дня» ) в той час , коли вони засновані на оцінці з низькою точністю ( + - « 2 місяці» )
13. Вірити , що результати оцінки , виконані в комерційному ПО , не йдуть ні в яке порівняння з результатами , виконаними олівцем на серветці
12. Міркувати , що чим раніше ми почнемо відставати від плану, тим більше часу нам буде потрібно , щоб скоротити відставання
11. Доводити , що розробники (прим., спеціально ) занижують свої оцінки так , щоб вони виглядали привабливо
... Останній проект , який вдалося закінчити завчасно , був ще за Рейгана!
За матеріалами вебінару Стіва Макконнела "10 Deadly Sins of Software Estimation"
Немає коментарів:
Дописати коментар