Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик Страница 51

Тут можно читать бесплатно Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик. Жанр: Научные и научно-популярные книги / Деловая литература. Так же Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте «WorldBooks (МирКниг)» или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.
Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик

Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик краткое содержание

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

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта.

Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик читать онлайн бесплатно

Мифический человеко-месяц или как создаются программные системы - Брукс Фредерик - читать книгу онлайн бесплатно, автор Брукс Фредерик

• Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (ЧМ) 1/3 . То есть оптимальное время в месяцах изменяется как кубический корень предполагаемого объема работ в человеко-месяцах — формула, полученная из оценки размера и других факторов в его модели. Следствием является кривая, дающая оптимальную численность занятых.

• Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.

• Кривая стоимости резко растет, если запланированный график короче оптимального.

• Практически ни один проект невозможно завершить быстрее, чем за [3] Л расчетного оптимального графика вне зависимости от количества занятых в нем! Этот примечательный результат дает менеджеру программного проекта солидное подкрепление, когда высшее руководство требует принятия невозможного графика.

Насколько верен закон Брукса? Были даже проведены тщательные исследования закона Брукса (намеренно упрощенного), согласно которому выделение дополнительных людей для отстающего графика проекта лишь задерживает его выполнение. Лучше всего это сделано Абдель-Хамидом (Abdel-Hamid) и Мадником (Madnick) в честолюбивой и ценной книге «Динамика программного проекта: интегрированный подход». [16] В книге разработана количественная модель динамики проекта. Глава о законе Брукса более подробно вникает в то, что происходит при различных допущениях относительно того, кого добавляют, и когда. Чтобы исследовать это, авторы развивают собственную тщательную модель программного проекта среднего размера, предполагая, что у вновь добавляемых людей есть кривая обучения, и учитывая дополнительные издержки на общение и обучение. Они приходят к выводу, что «добавление новых людей к запаздывающему проекту всегда приводит к его удорожанию, но не всегда к более позднему завершению» (курсив авторов). В частности, увеличение численности работников в начале проекта гораздо безопаснее, чем в конце, поскольку добавление новых людей всегда вызывает отрицательный эффект, для компенсации которого требуются недели.

Штуцке (Stutzke) предлагает более простую модель для проведения аналогичных исследований, и с тем же результатом. [17] Он проводит подробный анализ процесса и издержек, связанных с привлечением новых работников, явным образом учитывая отвлечение наставников от непосредственной работы над проектом. Он проверял свою модель на реальном проекте, в котором численность работником была удвоена, благодаря чему удалось уложиться в первоначальный график, несмотря на отставание в середине. Он рассматривает альтернативы добавлению новых работников, особенно сверхурочную работу. Наибольшую ценность представляют его многочисленные практические советы о том, как привлекать новых работников, обучать их, обеспечивать инструментарием и т.д., чтобы минимизировать отрицательный эффект увеличения персонала. Особенно достойно внимания его замечание, что дополнительно привлекаемые на поздних стадиях проекта работники должны быть игроками команды, стремящимися войти в игру и вписаться в процесс, а не пытаться изменить или усовершенствовать сам процесс!

Штуцке считает, что дополнительная тяжесть обмена информацией в крупном проекте имеет второй порядок малости, и не включает ее в свою модель. Не вполне ясно, учитывают ли ее Абдель-Хамид и Мадник, и если да, то как. Ни в одной из моделей не учитывается то обстоятельство, что работа должна быть перераспределена — процесс, который для меня часто оказывался нетривиальным.

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

Кадры решают все (или почти все)

Некоторые читатели удивляются, что большая часть рассуждений МЧ-М посвящена административным сторонам программной инженерии, а не многочисленным техническим проблемам. Такой перекос частично вызван той ролью, которую я играл в IBM Operating System/360 (теперь MVS/370). Если смотреть глубже, это происходит от убеждения, что качество людей, занятых в проекте, их организация и администрирование имеют гораздо большее значение для успеха, чем инструменты, которыми они пользуются, или применяемые ими технические решения.

Последующие исследования подкрепили мою уверенность. Модель COCOMO Бёма признает, что качество команды является важнейшим фактором ее успеха, практически вчетверо более важным, чем следующий за ним по значимости. Большинство научных исследований по программной инженерии сосредоточилось на инструментах. Я люблю хороший инструмент и жажду его. Тем не менее отрадно видеть продолжение исследовательских программ в отношении заботы о людях, их роста и поддержки, а также развития управления разработкой программного обеспечения.

Человеческий фактор. Крупным достижением последних лет стала книга Демарко (DeMarco) и Листера (Lister) «Человеческий фактор: продуктивные проекты и программы», изданная в 1987 году. В основе ее лежит положение о том, что «главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические». Она изобилует такими жемчужинами, как «задача менеджера не заставить людей работать, а сделать так, чтобы они могли работать». В ней говорится о таких прозаических вещах, как помещение, мебель, совместное питание команды. Демарко и Листер приводят реальные данные из своего «Программирования военных игр», которые показывают поразительную корреляцию между производительностью программистов из одной и той же организации, а также между характеристиками рабочих мест и уровнем продуктивности и наличия ошибок.

В помещениях наиболее продуктивных программистов тише, они более личные, лучше защищены против непрошеного вторжения, и они просто больше… Понимаете ли вы, что покой, пространство и уединенность способствуют лучшей работе ваших теперешних работников или (с другой стороны) способствует привлечению и сохранению лучших работников?[18]

Я искренне рекомендую эту книгу всем моим читателям.

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

В своей практике я наблюдал, возможно, с полдюжины передач проекта, и ни одна из них не была успешной. Можно с успехом передавать задания. Но во всех случаях попытки передать проект новая команда фактически начинала сначала, несмотря на наличие хорошей документации, некоторого продвижения в проекте и некоторых людей из передающей команды. Я думаю, что разрушение спаянности прежней команды приводит к выкидышу проекта, находящегося в эмбриональном состоянии, и осуществлению его с начальной точки.

Сила отказаться от власти

Если согласиться, что, как я неоднократно доказывал на протяжении этой книги, творчество исходит от личностей, а не организационных структур и процессов, тогда главная задача менеджера программного проекта — создать организационную структуру и рабочий процесс, способствующий творчеству и инициативе, а не подавляющие их. К счастью, эта проблема присуща не только программным организациям, и над ней работали многие большие умы. Е. Ф. Шумахер (E. F. Schumacher) в классической работе «Малое прекрасно: экономика ради людей» предлагает теорию организации предприятий, максимизирующую творческую активность и радость работников. В качестве первого принципа он выдвигает «принцип вспомогательной функции» из энциклики Quadragesimo Anno папы Пия XI:

Передача большему и вышестоящему сообществу того, что могут делать меньшие и нижестоящие организации является несправедливостью и в то же время серьезным злом и нарушением правильного порядка. Ибо всякая общественная деятельность по сути своей должна предоставлять помощь членам социальной группы, а не разрушать и поглощать их… Тем, кто управляет, следует быть уверенными, что чем лучше среди различных сообществ сохраняется дифференцированный порядок в соблюдении принципа второстепенной функции, тем крепче будет власть и эффективность в обществе, тем более счастливым и процветающим государство.[19]

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы
    Ничего не найдено.