Менеджмент проектов-Грищенко / lectures / lecture-04-conspect
.pdf11
—Вряд ли — становится очевидно, что 30 человек, скорее всего, не смогут сработаться за такой короткий срок.
—60 за 2 месяца?
—Ну это уже смешно!,— ответите вы…
—А 120 разработчиков за 1 месяц?
—Ну а это вообще не смешно. Издевательство просто…
Из этого диалога видно, что «сжатие» сроков при заданной трудоёмкости не может происходить бесконечно — есть предел. Так вот идея данного пункта состоит в том, чтобы не производить оценок за этим пределом. Такие оценки не могут быть состоятельными. Предел «на сжатие», по мнению Стива МакКоннела, находится где-то около 25% от номинальных оценок.
12.Не переоценивайте выгоду от новых методов и технологий
1.Использование новых технологий сопряжено с:
1.затратами на обучение
2.рисками, связанными с использованием непроверенной технологии
3.тем, что выгода от использования более совершенной технологии оказывается меньше, чем обычно заявлено
Личная рекомендация Стива: «Считать, что использование новой технологии в первый раз снизит продуктивность разработки». И снова тезис: «Нет серебряной пули».
13.Не используйте только один метод оценки трудоемкости
1.В этом пункте автор предостерегает от двух вещей:
1.от использования только одной методики оценки
2.от усреднения значений, полученных разными методиками
2.При использовании разных методик важно понять, почему возникли различия.
14.Используйте специализированное программное обеспечение для оценки трудоемкости
1.Моделирование при помощи компьютерных программ может повысить адекватность оценок. Естественно, использование специальных средств не гарантирует вам надёжность и адекватность оценок. Но при умелом использовании может заметно повысить их точность. Кроме того, автор даёт ссылку на сайт своей компании, где доступны бесплатные инструменты для проведения компьютерной оценки трудоёмкости разработки ПО. Одно из главных достоинств специального ПО в том, что
12
результаты выглядят более убедительно для «потребителей» оценок.
15.Не давайте поспешных оценок
1.Последнее, но от этого не менее важное, утверждение состоит в предостережении от использования поспешных, необоснованных оценок. Важно всегда брать небольшой таймаут для проведения хотя бы небольших предварительных оценок.
Список литературы
1.Мицель А., Шелковников К., Истомин Н. Методы оценки трудоемкости проектов по созданию программных систем
2.Методы оценки проекта разработки ПО. http://habrahabr.ru/blogs/pm/24872/
3.COCOMO — Википедия. http://ru.wikipedia.org/wiki/COCOMO
4.На старт! Внимание! И? http://itc.ua/articles/na_start_vnimanie_i_21814/
5.С. Архипенков. Обзор метода функциональных точек. http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml
6.Десять смертных грехов в оценке трудоёмкости разработки программного обеспечения. http://habrahabr.ru/blogs/pm/75903/