Метод BigBook для менеджера проектов

В 1996 году некая компания BigBook разрабатывала весьма продвинутый программный продукт, предвестника Google Maps. Перспективы для продукта открывались замечательные, но, как это часто бывает, команда не укладывалась в намеченные сроки запуска.

Руководитель компании совершил классическую ошибку управления, удвоив количество разработчиков в попытке ускорить завершение проекта. Программисты, однако, были продвинутые, читавшие «Мифический человеко-месяц» Фреда Брукса: Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше. #

Как бы то ни было, попытки повторить аргументы Брукса эффекта не возымели. Тогда разработчики договорились провернуть один трюк.

К следующему совещанию каждый разработчик купил и принес с собой экземпляр книги Брукса, положив в общую стопку, повторяя руководителю: Это очень срочно! Вы должны немедленно прочесть эту книгу. Мы купили вам несколько копий чтобы вы могли читать ее быстрее.

Нужный эффект был достигнут. История, правда, умалчивает, помогло ли это завершить проект успешно.

(оригинал)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: менеджмент

anonymous 20.09.2010 18:56

Спасибо за информацию, Maverik. Мой ящик — [email protected]. На случай, если Вам что-нибудь попадется по метотоду функциональных точек.

Відповісти

Підтримати

Eugine Kosenko 20.09.2010 18:56

А с другой стороны, Гугль по ключевым словам «function points» выдает гору материалов, например: http://www.sei.cmu.edu/str/des...Возможно, если аккуратно ограничить поиск сайтом construx.com, то можно найти и методичку. К сожалению, сейчас по быстрому ничего не могу найти. Точно помню, что там были какие-то таблицы с расчетами. И формат файла скорее всего будет doc или pdf. Надеюсь, Вы сможете найти эти материалы.Кстати, недавно узнал, что правильное название метода на русском языке — «метод функциональных единиц». По этому запросу тоже много чего выдается, например, http://itc.ua/article.phtml? ID...

> Если Вам не трудно, вышлите какую-нибудь ссылочку на подробное описание этой методики. Или скиньте на мыло.К сожалению, в полном объеме эта методика, скорее всего, является коммерческим ноухау. Я узнал об этой методике из книги Steve McConnell’s Software Project Survival Guide. На сайте книги есть дополнительные материалы к ней. В частности, есть условно-бесплатная программа Construx Estimate, где реализована эта методика. И я еще помню, что там была отдельная методичка по этому вопросу, только не помню, чтобы там была реализация. Вот сходу могу подсказать только: http://www.construx.com/Page.a...Нужно порыться поблизости, где-то должна быть и методичка. Я попробую поискать. Укажите почту, по которой можно с Вами связаться, или напишите мне.

Здравствуйте всем! Maverik, Вы писали о методе функциональных точек. Мне очень нужна методика со всем своим описанием и формулами. Я пишу диплом и нужно провести оценку. На основе СОСОМО уже провела. Но нужно сравнение и еще по какой-нибудь методике. Если Вам не трудно, вышлите какую-нибудь ссылочку на подробное описание этой методики. Или скиньте на мыло.Заранее благодарна.

Хорошая тема, только сейчас нашел) +ХПо поводу Монте-Карло — на деле используется повсюду, хотя по уму уже давно пора оставить на втором-третьем плане и заменить другими моделями...

Насчет «множества параметров», то, например, метод «функциональных точек» (functional points, я не знаю как это хорошо перевести) требует что-то около десятка параметров, таких как «количество диалоговых окон», «количество печатных форм», «количество сущностей» и т.п. Каждый параметр должен быть задан трижды (минимальное, максимальное и ожидаемое значение), а затем все это смешивается с помощью «магических коэффициентов». Я когда-то ради интереса пытался оценить один проект, сравнив результаты по SLOC и функциональным точкам. Получилось довольно хорошее совпадение в теории, которое совершенно не сошлось с практикой: -).Вообще же, мне еще ни разу не удавалось поработать классическим руководителем, у которого оказалось бы достаточно времени и денег для организации такой ерунды, как оценка трудоемкости проекта. Всегда находились дела поважнее...Кстати, совсем забыл добавить, что первое название книги Йордона — «Путь камикадзе», что звучит не менее интригующе, чем у Брукса: -).

Да, а дифуры можно не искать, если бы были под рукой, то можно было бы посмотреть как забавную игрушку, но не более того.Проблема в том, что если они и существуют то содержат множество параметров, которые на реальных проектах врядли удасться формализовать и замерить, а попытки это сделать могут встать дороже гипотетического выигрыша от собственно применения дифуров:)

Спасибо большое за столь обширный ответ и за множество ценных ссылок, будем учить матчасть:)

Вдогонку: там же, на сайте construx есть обширная статья, сопровождающая SG, в ней подробно описан механизмы «скользящей оценки» и другие формулы, в частности, там великолепно изложен метод «функциональных точек» и таблицы оценок по SLOC. Если будете искать серьезно, найдите обязательно, не пожалеете!

Честно говоря, цитаты на тему диффуров видел примерно 3 года назад на одном из российских форумов для руководителей проектов. К сожалению, ссылки утеряны, но там и так были общие слова.Я подозреваю, что сами дифуры являются жестким коммерческим ноухау, и потому охраняются лучше, чем курица, несущая золотые яйца: -). А вот в существование таких моделей заставляет поверить наличие специализированного программного обеспечения, результаты работы которого явно смахивают на аналогичный обсчет методами Монте-Карло. Я, например, одно время игрался с Construx Estimate (http://www.construx.com/produc...), которая выдает весьма занятные результаты, хотя и оставляет впечатление игры в «Монополию» после ведения реального бизнеса: -).Вообще говоря, грамотной оценке трудоемкости проекта посвящена целая глава в книге Стива МакКоннела (Steve McConnell) «Руководство по выживанию программных проектов» (Software Project Survival Guide (Pro — Best Practices), http://www.amazon.com/gp/produ...). Как по мне — это лучшее руководство по управлению проектами из всех, включая документацию по RUP и MSF. На сайте компании Construx есть раздел, посвященный поддержке этой книги (http://www.construx.com/surviv...), в частности, оценке трудоемкости проектов (http://www.construx.com/produc...), это включает в себя курсы и прочие виды информации, возможно, что именно там есть ссылки на более серьезные исследования.Правило «в 2 раза на четверть» я мог прочитать в той же книге (давно было, уже не помню), а мог узнать из книги Эда Йордона (Ed Yourdon) «Руководство разработчика по выживанию в безнадежных проектах» (извините, к сожалению, нет времени искать ссылки), которую я считаю по классу не хуже «Мифического человеко-месяца».Если это вопрос принципа, скажите, я попробую таки найти соответствующие цитаты и источники, и даже ссыклки на дифуры; -). А пока что будем считать, что sapienti sat...: -)

Любопытно, а можно пару ссылочек на углубленные исследования? Лучше на эмпирические формулы:), но можно и на дифуры, просто ради общего развития:)

Max Ischenko Founder в DOU.ua 20.09.2010 18:56

У Брукса вообще был опыт весьма специфический — проекты такого размера все-таки очень редки. Я где-то читал что около 90% проектов выполняются командами разработчиков до 10−14 человек.OFF: Привет вашему тестировщику.; -)

Кстати, еще вдогонку. Сам Брукс подчеркивает, что все его максимы неприменимы для работ, которые он сам метко называет «уборкой урожая». Собственно, основное мастерство руководителя и заключается в том, чтобы превратить разработку на определенном этапе в «уборку урожая», тогда человеко-месяц отнюдь не выглядит таким уж мифическим.

На самом деле, со времен Брукса было множество исследований на эту тему. Существует приблизительная эмпирическая формула, что удвоение штата ускоряет разработку примерно на четверть. Это слабый результат, но он вполне положительный. Важным условием для этой формулы является то, что применять ее нужно до начала разработки, во время оценки сроков, а не тогда, когда проект уже горит (в последнем случае я называю аналогичные попытки «тушить пожар бензином»).Есть и более продвинутые методы, уточняющие оценку Брукса, они основаны на стохастических оценках с использованием систем нелинейных дифуравнений.

Иван Пирог 20.09.2010 18:56

Красавцы!!! =:)

+1:)

ashtu 20.09.2010 18:56

Метод BigBook для менеджера проектов

17 коментарів

Підписатись на коментарі