В Wrike есть традиция делиться с нашей командой мыслями о прочитанных книгах.
Мы давно думали, что неплохо было бы распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулась хорошая возможность — книга Фредерика Брукса.
Книгу можно назвать скорее классикой девелоперского фольклора, чем настоящим руководством по построению рабочего процесса.
В ней отражены проблемы, с которыми Брукс столкнулся при организации работ по созданию операционной системы OS/360, и его подходы к их решению.
Результат оказался далек от идеала, как отмечает сам Брукс.
Его целью было не научить, как делать правильно, а поднять проблемы, требующие решения.
Интересно посмотреть, что изменилось в развитии с 1960-х годов.
Фото из Архив IBM
Прежде чем говорить о самой книге, нам необходимо понять контекст. Что на самом деле представлял собой проект OS/360, с какой целью он разрабатывался и при каких условиях.
История развития системы/360 В начале 1960-х годов IBM была абсолютным лидером на компьютерном рынке.
Ее доля составила 75%.
Однако перспективы становились все менее радужными.
Абсолютно все системы IBM были несовместимый между собой.
Серии 1401, 1620, 7070 и т.д. были полностью изолированы.
Если вы хотите перейти с 1401 на 1620, купите не только новый процессор, но и всю периферию.
Программное обеспечение также придется переписать.
Дорогое удовольствие для клиента, не каждый на такое решится.
Да и для самой IBM ситуация выглядела плохо.
Необходимо было поддерживать производство устаревшего оборудования, содержать штат специалистов, которые могли бы его настроить, обучать инженеров на стороне клиента устаревшим технологиям.
При этом переход с одной системы на другую требовал полной переподготовки.
Ситуацию усугубляло то, что многие системы были узкоспециализированными, например системы диспетчеризации.
И вот, в январе 1961 года 29-летний Брукс представил проект следующей 8000-й серии.
Конечно, новая система во всем лучше предыдущих, но в одном она с ними одинаковая.
Это еще один совершенно уникальный комплекс, переход на который обойдется клиентам в миллионы, как и его поддержка со стороны самой IBM. Понятно, что это тупик.
Проект закрывается, и Бруксу предлагают возглавить группу по разработке совершенно новой системы.
Но никто не знал, какой именно.
Было ясно одно — новая система должна обеспечивать дальнейшую обратную совместимость как на аппаратном, так и на программном уровне, а также быть системой общего назначения, подходящей для банков, военных и ученых.
Была сформирована группа из 25 человек во главе с Бруксом, которая приступила к разработке планов новой системы.
Процесс продвигался медленно, и чтобы ускорить его, руководство решило переместить рабочую группу в отель в пригороде Нью-Йорка с ультиматумом, что команда не уйдет, пока не придет к общему решению.
И они пришли.
И этому решению был дан зеленый свет. Весь аппаратно-программный комплекс назывался System/360, а операционная система — OS/360. Парадоксально, что проблему обратной совместимости решили решить за счет отказа от совместимости с предыдущими системами.
Разработка системы заняла значительно больше времени, чем планировалось; ее стоимость составила не $625 млн, а $5,25 млрд — чуть меньше, чем программа «Аполлон» с ее ракетами, космонавтами и высадками на Луну в том же 1965 году.
Риск банкротства для IBM был вполне реальным, но все обошлось.
Система была анонсирована 7 апреля 1964 года, и были выпущены первые продукты.
Успех был огромен.
Принцип взаимозаменяемости компонентов, заложенных в эту систему, соблюдается и по сей день.
Кстати, именно после System/360 стандартный размер байта стал 8 бит. Основные заявления Брукса Из предисловия ко второму изданию: «Эта книга — запоздалый ответ на вопросы о трудностях разработки программного обеспечения («запоздалый» в 1975 году! — прим.
автора).
В ближайшее десятилетие не будет методов программирования, использование которых позволит на порядок увеличить продуктивность разработки при прочих равных условиях».
Среди основных высказываний Брукса, ставших банальными, можно назвать следующие:
- Программный продукт рискует устареть еще до его завершения.
- Из всех проектируемых систем наибольшую опасность представляет вторая.
Обычно ей приходится редизайн снова.
- Планирую выбросить первый версию — вам все равно придется это сделать, поскольку она не будет соответствовать ожиданиям пользователей.
- Вы не можете оценивать программные проекты в человеко-месяцах.
Человеко-месяц — ложное и опасное заблуждение, поскольку оно предполагает, что месяцы и количество людей можно менять местами.
- Лучшие профессиональные программисты в 10 раз продуктивнее самых слабых.
- Закон Брукса: если проект не укладывается в срок, добавление большего количества рабочей силы еще больше задержит его выполнение.
Анализировать все 214 утверждений было бы нецелесообразно, тем более что многие из них вполне очевидны.
Например, нельзя спорить с тем, что лучше всего иметь небольшую активную команду.
Однако изменения в актуальность Эти заявления отражают изменения в индустрии программного обеспечения.
Первая и вторая системы 50 лет спустя Программный продукт устареет, не успев завершиться, архитектура второй системы будет плохой, а от первой придется отказаться, поскольку она не будет отвечать потребностям пользователей.
Получается, что-то полезное может получиться только с третьего раза? Нет. В каком-то смысле Брукс прав, но мы научились с этим справляться.
Программный продукт неизбежно устареет еще до его завершения.
, если на его разработку уйдет пять лет. Именно это и произошло с System/360. Все современные подходы к разработке подразумевают быстрый выпуск первой версии, пусть и с минимальным, но практически полезным набором функций.
Та же концепция пользовательские истории Во-первых направлена на выбор небольшой, но неотъемлемой части для реализации из всей совокупности потребностей заказчика.
Тогда продукт можно будет быстро выпустить и получить обратную связь.
Первую версию придется выбросить , если делать это вслепую.
Но если первая версия не слишком раздута, и при ее разработке учтены пожелания реальных пользователей, все может получиться вполне неплохо.
Как только вы начнете им пользоваться, комментариев неизбежно будет много, но если вы прислушаетесь к отзывам еще до первого релиза, то вероятность полного провала существенно снижается.
Исправление комментариев не проблема, если товар используется.
Архитектура второй системы будет плохой .
Брукс считает проект System/360 второй системой.
Специализированные проекты, которые ранее разработала IBM, получились вполне неплохо, но с 360 решили все сделать правильно.
Архитектурные решения не принимаются в вакууме; они являются ответами на проблемы.
Если система развивается эволюционно, то эти проблемы реальны и вполне ощутимы.
Их можно разобрать, понять и найти решение.
Начав с чистого листа, легко упустить то, что действительно важно для пользователей: никто не может спланировать все.
Однако все же опасно попасть в ловушку принятия решений.
воображаемые проблемы , которые существуют только в голове архитектора/аналитика, но не имеют никакого отношения к реальности.
Проблема второй системы в целом существует, но мы научились ее избегать, без создания второй системы .
Вместо этого первый выпущенный продукт развивается эволюционным и итеративным образом.
Иногда рефакторинг, миграция и поддержка обратной совместимости обходятся дорого, но это не такая уж большая цена за то, чтобы оставаться в контакте с реальностью.
В конечном итоге разработку ускорил не технологический прогресс, а сокращение цикла разработки и получение быстрой обратной связи.
Мифический и реальный человеко-месяц По поводу того, что при разработке программных проектов невозможно манипулировать оценками в человеко-месяцах, Брукс немного лукавит. Фактически Это невозможно сделать ни в одном проекте.
.
Планирование сроков и ресурсов проекта по сути является простым делом.
Если вы знаете все задачи, зависимости между ними, примерные сроки и необходимые ресурсы, то все довольно просто.
Только ленивый человек не сможет составить план в таких условиях.
Но даже в этом случае вы не сможете бесконечно добавлять людей, чтобы ускорить проект. Всегда существует критический путь, определяющий минимально возможные сроки, независимо от количества ресурсов.
Дополнительную информацию об этом см.
«Проектный менеджмент в СССР (1976)» И «Критическая цепь» .
К сожалению, условия, необходимые для планирования, не всегда выполняются.
В этом случае составьте правильный план невозможный .
Даже оценки сроков выполнения отдельных задач всегда получаются из практический опыт .
А что делать, если такого опыта нет? Завязать шнурки – дело минут, а точнее 5-7 секунд. Завязывая шнурки каждый день, мы можем по собственному опыту довольно точно оценить, сколько времени нам понадобится, чтобы выполнить ту же работу завтра.
Но попробуйте предсказать, сколько времени вам понадобится, чтобы завязать шнурки.
с одной стороны .
Соответствуют ли ваши оценки вашему реальному опыту? Интересный эксперимент. Подробнее - Роберт С.
Мартин «Эффективная оценка (или: Как не врать)» .
Мы очень плохо планируем то, чего никогда не делали, любые новые инициативы, не только разработку программного обеспечения.
Именно в такой ситуации оказался Брукс, когда его попросили составить план проекта и оценить время и стоимость разработки System/360. Даже если запереть всех ключевых специалистов в отеле, они все равно не смогут составить точный запланируйте большой программный проект. К сожалению, руководство IBM поставило Брукса в безвыходную ситуацию, что, вероятно, и побудило его позже написать книгу.
Однако краткосрочное планирование вполне возможно.
Если планировать итерации на 2-4 недели, это можно сделать достаточно точно.
Со временем у вас вырабатывается навык разбивать большие задачи на более мелкие, и маленькие задачи легче оценивать.
Кроме того, постоянно работая в одном направлении, человек накапливает экспертные знания.
Проблемы, которые три месяца назад казались совершенно новыми, так что оценить их можно было лишь пальцем в небо, оказываются весьма похожими на недавние.
Это означает, что оценки их сроков будут схожими.
Конечно, невозможно оценить программные проекты в человеко-месяцах, но планируйте работу на ближайший в месяц вполне возможно.
И этот план на ближайший месяц будет не мифическим, а вполне обоснованным.
действительный .
Что пропустил Брукс - Господин Брукс, вы сказали, что проект займет у вас два года и $625 миллионов, уже прошло два с половиной, вы удвоили бюджет, но результатов нет. Господин Брукс, вы понимаете, что от скорейшего завершения вашего проекта зависит успех всей компании? Мы дадим вам еще 2 миллиарда долларов и наймем еще 500 человек.
— Господин Брукс, ваша задача — завершить всю необходимую работу в течение следующего года.
Конечно, мы не знаем, сказали ли это Бруксу на самом деле, но это вполне могло произойти.
Брукс очень подробно объясняет, почему необходимо добавлять ресурсы.
по инициативе руководства не может ускорить длительный проект. Необходимо перепланировать всю работу, потратить время на ввод новых специалистов в курс дела, привитие им правил развития и так далее.
Брукс, безусловно, прав во всем этом, но дело не в этом.
Настоящая проблема Брукса не в том, что на реализацию его проекта ушло четыре года или бюджет составил 5 миллиардов долларов, а в том, что он не смог заранее точно спланировать ни сроки, ни бюджет. На самом деле он ошибся 10 раз.
Конечно, Брукс ищет способ ускорить разработку в те же 10 раз, но это не решение.
Никто на месте Брукса не смог бы дать более точную и обоснованную оценку проекта.
Конечно, кто-то другой мог бы сказать три года и два миллиарда долларов, и в этом случае ошибка была бы меньше.
Но такая «более точная оценка» будет результатом удачной догадки, а не рационального прогноза.
Главный конфликт книги заключается в том, что с точки зрения бизнеса необходимо точно знать, сколько времени займет проект и сколько ресурсов он потребует, и Брукс был вынужден ответить на эти вопросы.
На самом деле все получилось совсем не так, как планировалось, за что Брукс чувствует личную ответственность.
Обещал, сделал все, что мог, но не получилось.
Но согласитесь, не совсем справедливо требовать от человека дать обещание, которое он, скорее всего, не сможет выполнить.
Все могло бы сложиться иначе, если бы в начале проекта Брукс настаивал на том, что бюджет проекта может составлять от 1 до 6 миллиардов долларов, а продолжительность - от 3 до 7 лет, а более точные оценки дать невозможно.
А руководство IBM, в свою очередь, признало эти оценки.
Возможно, можно было бы лучше планировать бюджет компании, зная возможные риски задержки проекта и увеличения его бюджета.
Это лучше, чем столкнуться с проблемой, когда деньги уже закончились.
Возможно, мог бы быть способ изменить подход к продвижению и продажам таким образом, чтобы позволить максимально сократить масштабы проекта, сделав его менее неопределенным, а значит, и менее рискованным.
Возможно, можно было бы сделать что-то еще, выходящее за рамки инженерного отдела, что способствовало бы успеху проекта.
Но в то время столь радикальное изменение подхода к работе выходило за рамки дозволенного.
Это были совсем другие времена, 1960-е годы.
Теги: #планирование #C++ #agile #agile development #Анализ и проектирование систем #Управление проектами #agile
-
Клаузиус, Рудольф Юлиус Эмануэль
19 Oct, 24 -
Странности С Php-Модулем Memcached
19 Oct, 24 -
Iphone Не Будет Работать В России?
19 Oct, 24 -
Как Выучить Английские Слова
19 Oct, 24 -
Индикатор Выполнения В Css3
19 Oct, 24
