+38 (093) 580-29-22 info@lokhnin.com

The Mythical Man Month: Essays on software systemsНедавно перечитал книгу, которая уже давно стала классикой. Мифический человеко месяц или как создаются программные системы. 25 дет назад Ф. Брукс описал основные ошибки создания информационных систем. Эта работа актуальна и сегодня. Выписал для себя основные тезисы книги.


Основные тезисы книги

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

Программные проекты чаще проваливаются из за нехватки календарного времени, чем по всем остальным причинам, вместе взятым. Наши методы оценивания, основанные на учёте затрат, смешивают затраты с полученным результатом. Человеко месяц является ошибочным и опасным заблуждением, поскольку предполагает, что месяцы и количество людей можно менять местами. Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией. Кроме этого, далеко не все задачи можно разделить. Нужно понимать, что 9 беременных женщин за месяц ребенка не родят.

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

Команда проекта

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

Данные Портмана по ICL показывают, что занятые на полный рабочий день программисты только около 50 процентов времени занимаются программированием и отладкой, а остальное время занимают разные дополнительные задачи.

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

Самые лучшие программисты профессионалы в 10 раз продуктивнее слабых. Лучше платить в 3 раза больше лучшим программистам, чем нанимать троих среднего или слабого уровня. Данные Сакмана, Гранта и Эриксона не выявили корреляции между опытом и продуктивностью. Я думаю, что это всегда так. Лучше всего иметь маленькую активную команду.

Управление проектом

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

Менеджер проекта должен установить принципы и выделить ресурсы для разработки общих инструментов, в то же время он должен признать необходимость в персонализированных инструментах.

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

Вехи должны быть конкретными, специфическими, измеримыми событиями, определёнными с предельной точностью.

Диаграмма критических путей даёт отпор деморализующей оговорке «другая часть тоже запаздывает».

Коммуникации проекта

Проект Вавилонской башни провалился из за недостатка обмена информацией и, как следствие, организации.

Обычная древовидная организация отражает структурный принцип власти , который показывает, что нельзя одновременно служить двум хозяевам. Структура обмена информацией в организации является не деревом, а сетью, и нужно придумать различные виды специальных организационных механизмов («пунктирные линии»), чтобы преодолеть дефицит обмена информацией в древовидной организации.

Необходимо, чтобы внимание пользователя было особо привлечено к изменениям, произошедшим после его последнего прочтения, причём с пометками об их значении.

Важно, чтобы архитектор в телефонных разговорах отвечал исполнителям на их вопросы. Обязательно нужно регистрировать эти разговоры в журнале и доводить их до общего сведения. Сейчас для этого предпочтительнее электронная почта.

Нежелание программистов документировать проект происходит не столько от лени, сколько от неуверенности, стоит ли связывать себя отстаиванием решений, которые, как знает проектировщик, являются «предварительными».

Архитектура информационной системы

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

Концептуальная целостность является наиболее важным соображением при проектировании систем. Для достижения концептуальной целостности проект должен создаваться одним человеком или группой единомышленников.

Отделение разработки архитектуры от реализации является эффективным способом достижения концептуальной целостности при работе над очень большими проектами.

Если вы хотите, чтобы система обладала концептуальной целостностью, кто то один должен взять руководство концепциями. Это аристократизм, который не нуждается в извинениях.

На всём протяжении реализации системные архитекторы должны постоянно проявлять бдительность с целью непрерывного обеспечения целостности системы.

Сопровождение информационной системы

Программному продукту грозит устаревание ещё до его завершения. Если систему не развивать, она морально устаревает.

Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Даже самое искусное сопровождение программы только отдаляет момент повержения её в состояние неисправимого хаоса, выходом из которого является повторное проектирование с самого начала.

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

Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую. (из-за того, что во время сопровождения теряется архитектура).

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