Что такое человек месяц
Значение слова «человеко-месяц»
человеко-месяц
1. спец. условный отработанный месяц для расчёта затрат, зарплаты и т. п.
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я стал чуточку лучше понимать мир эмоций.
Вопрос: иск — это что-то нейтральное, положительное или отрицательное?
Предложения со словом «человеко-месяц»
Отправить комментарий
Предложения со словом «человеко-месяц»
На старте у них было чуть больше отчётов, чем у конкурента, но любой скептик бы справедливо сказал: «Это же копируется за человеко-месяц, а авторитет вы не догоните никогда».
Карта слов и выражений русского языка
Онлайн-тезаурус с возможностью поиска ассоциаций, синонимов, контекстных связей и примеров предложений к словам и выражениям русского языка.
Справочная информация по склонению имён существительных и прилагательных, спряжению глаголов, а также морфемному строению слов.
Сайт оснащён мощной системой поиска с поддержкой русской морфологии.
человеко-месяц
Смотреть что такое «человеко-месяц» в других словарях:
человеко-месяц — (2 м); мн. челове/ко ме/сяцы, Р. челове/ко ме/сяцев … Орфографический словарь русского языка
Мифический человеко-месяц — The Mythical Man Month Автор: Фредерик Брукс Язык оригинала: английский … Википедия
Мифический Человеко-месяц — The Mythical Man Month Автор: Фредерик Брукс Язык оригинала: английский Оригинал издан: 1975 Издательство: Addison–Wesley … Википедия
Человеко-час — Человеко час единица учёта рабочего времени количество часов, фактически отработанных человеком урочно и сверхурочно за оговоренный период или в процессе выполнения отдельного задания (проекта). Отработанные человеко часы являются… … Википедия
ЧЕЛОВЕКО-ЧАС — единица учета рабочего времени. В человеко часах учитываются как фактически отработанное всеми рабочими время за день, месяц, квартал, год, так и простои … Большой Энциклопедический словарь
ЧЕЛОВЕКО-ЧАС — англ. man hour; нем. Menschen Stunde. Единица учета рабочего времени; использованные Ч. ч. определяют суммированием часов, фактически отработанных трудящимися урочно и сверхурочно за день, месяц, квартал, год. Antinazi. Энциклопедия социологии,… … Энциклопедия социологии
ЧЕЛОВЕКО-ЧАС — единица учета рабочего времени. В Ч. ч. учитываются как фактически отработанное всеми работниками время (за день, месяц, квартал, год), так и простои работников … Российская энциклопедия по охране труда
человеко-час — а; м. Единица учёта рабочего времени, исчисляемая количеством работы, выполняемой одним человеком за час (за вычетом времени простоев). Исчислять работу в человеко часах. Для изготовления детали требуется пять человеко часов. * * * человеко час… … Энциклопедический словарь
Человеко-час — [man hour] единица учета рабочего времени. Использование человеко часов определяется суммированием часов, фактически отработанных работником урочно и сверхурочно за день, месяц, квартал, год … Энциклопедический словарь по металлургии
Человеко-час — единица учёта рабочего времени. Использованные Ч. ч. определяются суммированием часов, фактически отработанных трудящимися урочно и сверхурочно за день, месяц, квартал, год (см. также Отработанное время) … Большая советская энциклопедия
Мифический человеко-час
Что такое человеко-час, человеко-месяц и человеко-год? Как правильно ими пользоваться при планировании и выполнении программных проектов? Какие типичные ошибки допускают проектные менеджеры и руководители групп программистов?
Меня зовут Гелий Шаров, и я работаю тим-лидом в Orion Innovation. Проработав 24 года в IT-компании на разных должностях, включая менеджерские, я понял, что существует путаница в понятии человеко-час и в том, как им можно манипулировать в IT-проектах. Эта статья поможет развеять мифы и подскажет как правильно планировать работы в проектах. От правильной оценки проекта зависит очень многое. И то, согласится ли с ней ваш клиент и даст ли проекту старт. И то, насколько сложно вам будет делать коррекцию этой оценки в процессе, что неизбежно, и сможете ли вы эту коррекцию обосновать, и то, как вы будете выстраивать бизнес-процессы в управлении проектом. Поэтому в оценке IT-проекта задействована масса факторов, шкал и расчетов. Тем не менее, основная масса клиентов ориентируется на очень понятную и четкую единицу измерения – человеко-час.
И разумеется, это палка о двух концах. С одной стороны – это предельна простая базовая единица. С другой стороны, нередко задача по адекватной оценке сложного проекта в столь простых единицах похожа на попытку измерить расстояния в нелинейной системе в попугаях.
Человеко-час — это единица измерения, которой пользуются в проектах для двух разных целей:
Оценки объёма/сложности разработки программного продукта/компонента – то есть оценки необходимых усилий на его создание и тестирование.
Подсчёта стоимости работ по проекту.
Например, если пять человек выполняют работу в течение рабочей недели, то это составляет 5 * 40 = 200 человеко-часов. Человеко-часы — это удобный инструмент, который широко используется в аутсорсинговых организациях по разработке ПО.
Если сравнить человеко-месяц и человеко-час, то в разных проектах ситуация может отличаться. Чаще всего человеко-месяц это 20 рабочих дней * 8 часов = 160 человеко-часов, но в некоторых проектах может быть 21 рабочий день. Если работы по проекту начались 1 февраля и закончились в конце месяца, то это не то же самое, что с 1 марта до конца марта, так как количество рабочих дней разное. Поэтому термин человеко-месяц нужно употреблять аккуратно при оценке и планировании работ, лучше использовать человеко-часы. Более того в разных странах отличается длительность рабочей недели. Например, во Франции она составляет 35 часов, то есть во Франции термин человеко-месяц может содержать меньшее количество человеко-часов, чем в России.
Ещё больше сложностей в определении термина человеко-год. Для подсчёта суммарного количества человеко-часов в одном человеко-годе необходимо взять количество календарных дней – 365 для невисокосного года и 366 для високосного, вычесть из него количество выходных дней в этом году и количество праздничных нерабочих дней. Также стоит вычесть длительность отпуска, что составляет в России 28 календарных дней или 20 рабочих.
Очевидно, что в разные календарные года объём человеко-года будет разный. Это зависит от страны, в которой выполняются работы по проекту, от количества выходных дней, попавших в календарный год и других условий.
Дополнительным преимуществом человеко-часа перед человеко-месяцем и человеко-годом является его точность. Так если программист работает параллельно в двух проектах, его отработанные часы легко поделить между проектами пропорционально отработанному времени.
Планирование и учёт человеко-часов
Теперь давайте рассмотрим человеко-час как инструмент оценки объёма работ по будущему проекту. В первую очередь работы разбиваются до уровня задач, каждую из которых может выполнить один инженер в ограниченное количество времени. Выполнение этих задач оценивается в человеко-часах, они суммируются, добавляются административные задачи, оцениваются риски и усилия по их минимизации, после чего всё суммируется для оценки будущей стоимости всего проекта. Также составляется календарный график работ по проекту, в котором наибольшее внимание следует уделить задачам на критическом пути.
Но оценки объёма работ могут оказаться неточными и Вам могут потребоваться дополнительные усилия для завершения задач по проекту. Предположим, до финальной отсылки кода осталось два месяца. У Вас в проекте работают два инженера, а оставшаяся работа оценена в 14 человеко-месяцев. Тогда напрашивается решение о добавлении в проект ещё пяти инженеров на два месяца, чтобы успеть в срок. Сработает ли такое решение на практике? Да или нет – это зависит от многих условий. Во-первых, оставшиеся в проекте задачи должны быть разбиваемыми на подзадачи, чтобы их можно было выполнять параллельно. Во-вторых, новые инженеры должны иметь достаточно времени, чтобы вникнуть в проект и свои задачи. В-третьих, необходимо заложить время на коммуникации между семью инженерами, а также на интеграцию их кода в единый продукт. Если хотя бы одно из этих условий не выполнено, то проект не будет завершён в срок. Добавление же ещё большего числа инженеров может даже привести к увеличению сроков, а не к уменьшению.
Фредерик Брукс в своей книге «Мифический человеко-месяц» писал:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше. Это развенчивает миф о человеко-месяце. Продолжительность осуществления проекта зависит от ограничений, накладываемых последовательностью работ. Максимальное количество разработчиков зависит от числа независимых подзадач. Эти две величины позволяют получить график работ, в котором будет меньше занятых разработчиков и больше месяцев.
Производительность программистов
Термин человеко-час удобен для планирования работ, но важно понимать, что разные инженеры работают с разной производительностью.
В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1. Это означает, что какие-то задачи в проекте будут выполнены быстрее чем ранее сделанные оценки по объёму работ, а другие наоборот будут задержаны. Поэтому самых опытных программистов нужно планировать на выполнение задач на критическом пути проекта, от выполнения которого зависят сроки отсылки кода и продукта заказчику. Самый ценный ресурс в любом проекте – это календарное время. Если оно упущено, обратно его уже не вернуть, в то время как другие ресурсы проекта восполнимы в течение жизненного цикла проекта.
Тестирование продукта
Для разработки конечного программного продукта требуется оценить и запланировать человеко-часы на тестирование, что является одной из важнейших задач в практически любом проекте. В каждой компании по разработке ПО желательно иметь независимую команду инженеров по тестированию, которая верифицирует выполнение всех проектных требований в программном продукте. Планирование тестов должно учитывать возможные дефекты в продукте, которые необходимо устранить в коде продукта и перевыполнить соответствующие тесты – на что начинающие менеджеры иногда забывают запланировать соответствующие человеко-часы. Существует такой подход к тестированию, когда объём часов на эти задачи выделяется как некий фиксированный процент от объёма часов на разработку продукта. Такой подход излишне упрощает проблему планирования, ведь разные программные продукты отличаются по сложности выполнения функциональных и регрессионных тестов.
К счастью, процесс тестирования в IT проектах довольно стандартизирован и подсчитать трудозатраты QA немного проще. Обычно при таких расчётах учитываются требования заказчика к видам тестирования, которые довольно несложно собрать уже перед началом проекта. Есть мнение, что в среднем трудозатраты в человеко-часах на тестирование в среднем составляют 0.7 от трудозатрат на разработку. Можно сказать, что если расчеты очень сильно отклоняются от этого показателя, то это как минимум повод провести их еще раз.
Выполнение крупных проектов
Существует мнение что объём потраченных человеко-часов в ИТ-проектах линейно зависит от объёма написанного кода. График ниже демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr) в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5. На графике по горизонтали указан объём написанного кода, по вертикали – объём потраченных человеко-месяцев, в виде жирных точек приведена статистика из реальных проектов. Пунктиром изображена линейная зависимость. Сплошной кривой изображена степенная зависимость.
Объем работы = (константа) × (количество команд) 1,5
То есть в проектах по разработке сложных объёмных продуктов средняя производительность инженеров в машинных командах в единицу времени ниже, чем в небольших проектах, что необходимо учитывать при планировании таких проектов.
Fixed cost vs T&M
Планирование работ в человеко-часах зависит от используемой бизнес-модели. Существуют две основные бизнес-модели оплаты услуг аутсорсинговых организаций Fixed Cost и Time&Material. Давайте их рассмотрим поподробнее:
В модели Fixed Cost оценивается стоимость всех работ по проекту, которую указывают в контракте вместе со списком основных требований к программному продукту. Заказчик оплачивает работу после получения предварительных версий продукта и финальной версии. В случае изменений требований к продукту пересматривается контракт для согласования новой стоимости. В этой модели для заказчика не важно, сколько инженеров и на какой срок привлечено в реализацию проекта. Для компании-исполнителя важно построить такую команду, чтобы выполнить обязательства в полном объёме и не превысить планируемые расходы на проект. В этом случае от грамотного расчёта исполнителя будет зависеть то, реализует ли он проект в срок и заранее рассчитанным количеством человек, или, если расчет окажется неверным, будет ли работать себе в убыток, превысив бюджет и/или выйдя за дедлайн.
В модели Time&Material также оценивается объём работ по проекту в человеко-часах, но в контракте указывается стоимость одного человеко-часа и базовые принципы по их планированию, отчётности и оплате. После привлечения сотрудников в проект в конце каждого месяца отсылается отчёт по проделанной работе и затраченным человеко-часам. Оплата происходит ежемесячно при условии, что исполнитель не превышает заранее установленных планов и критериев по суммарным человеко-часам. В этой модели заказчик видит часы каждого сотрудника, вовлечённого в проект. В случае изменения проектных требований они оцениваются и бюджет может быть увеличен для вовлечения дополнительных сотрудников.
В проектах, где есть устойчивые требования к разрабатываемому программному продукту, модель Fixed Cost обладает преимуществами как для заказчика, так и для исполнителя. В других проектах, включая Agile, T&M модель более предпочтительна так как эта модель не требует пересматривать контракт при изменении требований.
Заключение
Инструмент планирования «человеко-час» удобен для сложения, деления, переноса и других математических операций, в то время как в реальных проектах перепланирование работ требует более глубокого анализа планируемых работ по проекту и учёта многих факторов. Я имел опыт работы с проектами размером более 30000 человеко-часов и могу сказать, что собственный опыт является ключевым фактором в правильном планировании и выполнении IT-проектов. А что говорит Ваш опыт? – жду Ваших комментариев к этой статье.
В заключение я бы хотел процитировать слова Фредерика Брукса:
Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым.
Книга «Мифический человеко-месяц, или Как создаются программные системы »
Отрывок. Аристократия, демократия и системный дизайн
Эта величественная церковь является выдающимся произведением искусства. В тех догматах, которые она проявляет, нет ни сухости, ни путаницы…
Это зенит стиля, труд художников, которые поняли и усвоили все успехи своих предшественников, в совершенстве владеющих техникой своего времени, но использующих ее без нескромной демонстрации или нелепого проявления умений.
Несомненно, замысел общего плана сооружения принадлежит Жану д’Орбе, который был уважаем, по крайней мере в его существенных элементах, его преемниками. Это одна из причин чрезвычайной согласованности и единства здания.
Путеводитель по Реймскому собору
Концептуальная целостность
Большинство европейских соборов возводились постепенно, и части, построенные строителями разных поколений, различаются в плане архитектурного стиля. Последующие строители испытывали соблазн «совершенствовать» дизайн более ранних, ориентируясь на изменения в архитектурной «моде» и на личный вкус. Поэтому мирный нормандский трансепт* упирается и противоречит парящему готическому нефу, и результат столь же служит восхвалению славы Господней, сколь и гордыни строителей.
На их фоне великолепно контрастирует архитектурное единство Реймса. Восторг, который будоражит зрителя, исходит как от целостности дизайна, так и от любых отдельно взятых достоинств. Как сказано в путеводителе, эта целостность была достигнута самоотречением восьми поколений строителей, каждый из которых пожертвовал некоторыми своими идеями ради чистоты общего замысла. Результат провозглашает не только славу Господню, но и Его могущество, способное спасти грешных людей от их гордыни.
Несмотря на то что для сборки большинства систем программирования не требовались столетия, они демонстрируют гораздо худшую концептуальную разобщенность, чем соборы. Обычно это происходит не из-за смены проектировщиков, а из-за разделения проекта на многочисленные задачи, выполняемые многими людьми.
Я настаиваю на том, что концептуальная целостность является наиболее важным соображением в системном проекте. Лучше иметь систему, в которой отсутствуют некоторые особенности и улучшения, но отражается один набор идей дизайна, чем иметь систему, содержащую много хороших, но независимых и несогласованных идей. В этой главе и в следующих двух мы рассмотрим последствия этой темы для дизайна систем программирования:
— Как достичь концептуальной целостности?
— Не является ли этот аргумент оправданием для элитарности или аристократизма архитекторов перед ордой плебеев имплементаторов, чьи творческие таланты и идеи подавляются?
— Как удержать архитекторов от дрейфа в голубую даль с неимплементируемыми или дорогостоящими спецификациями?
— Как обеспечить, чтобы каждая незначительная деталь архитектурной спецификации была доведена до сведения имплементатора, правильно им понята и точно встроена в продукт?
Достижение концептуальной целостности
Цель системы программирования — сделать компьютер простым в использовании. Для этого он поставляет языки и различные средства обеспечения, которые на самом деле являются программами, вызываемыми и управляемыми языковыми возможностями. Но эти средства обеспечения имеют свою цену: внешнее описание системы программирования в 10–20 раз больше, чем внешнее описание самой компьютерной системы. Пользователю гораздо проще задать любую отдельно взятую функцию, но их выбор обширен, и еще гораздо больше вариантов и форматов, о которых нужно помнить.
Использование упрощается только в том случае, если время, выигранное в функциональной спецификации, превышает время, теряемое при усвоении, запоминании и поиске в справочном руководстве. В современных системах программирования этот выигрыш действительно превышает стоимость, но в последние годы отношение выигрыша к стоимости, по-видимому, падало по мере добавления все более и более сложных функций. Меня преследует воспоминание о простоте использования IBM 650, даже без ассемблера или любого другого программного обеспечения вообще.
Поскольку простота использования является целью, это отношение функциональности к концептуальной целостности является конечной проверкой дизайна системы. Ни функциональность, ни простота сами по себе не определяют хороший дизайн.
Этот тезис широко понимается неправильно. Операционная система OS/360 превозносится ее создателями как самая прекрасная из когда-либо спроектированных, потому что она, бесспорно, имеет самую большую функциональность. Именно функциональность, а не простота всегда была мерой совершенства для ее дизайнеров. С другой стороны, система совместного использования времени для PDP-10 превозносится ее создателями как самая лучшая из-за простоты и сдержанности концепций. Однако по любым меркам ее функциональность даже не относится к тому же классу, что и у OS/360. Как только в качестве критерия принимается простота использования, каждый из этих подходов оказывается несбалансированным, пройдя лишь половину пути до цели.
Однако для заданного уровня функциональности лучше всего подходит та система, в которой можно специфицировать вещи с наибольшей простотой и прямолинейностью. Одной простоты недостаточно. Языки TRAC Муерса (Mooers) и Algol 68 достигают простоты, измеряемой числом отдельных элементарных понятий. Непосредственность, однако, не характерна для них. Чтобы выразить свои намерения, часто требуется сочетать базовые средства сложным и неожиданным образом. Недостаточно изучить элементы и правила их сочетания; нужно также изучить идиоматическое употребление, усвоить целый свод знаний о том, как элементы сочетаются в реальности. Простота и прямолинейность проистекают из концептуальной целостности. Каждая часть должна отражать одну и ту же философию и одно и то же уравновешивание пожеланий. Каждая часть должна использовать даже одну и ту же методику в синтаксисе и аналогичные понятия в семантике. Таким образом, простота использования диктует единство дизайна, концептуальную целостность.
Аристократия и демократия
Концептуальная целостность, в свою очередь, требует, чтобы проект исходил от одного разработчика или их небольшого числа, действующих согласованно и в унисон.
Давление графика, в свою очередь, требует привлечения большего числа работников. Для решения этой проблемы есть два метода. Первый — это тщательное разделение труда между архитектурой и имплементацией. Второй — это новый способ структурирования команд по имплементации программирования, рассмотренный в предыдущей главе.
Отделение архитектурных усилий от имплементации является мощным способом получения концептуальной целостности в крупных проектах. Я сам видел, как он с большим успехом используется на продуктовой линейке компьютеров IBM Stretch и System/360. И я был свидетелем, как он не сработал при разработке Operating System/360, поскольку недостаточно применялся.
Под архитектурой системы я имею в виду полную и детальную спецификацию пользовательского интерфейса. Для компьютера она воплощена в справочном руководстве по программированию. Для компилятора — в справочном руководстве по языку. Для управляющей программы — в справочном руководстве по языку или языкам, используемым для вызова ее функций. Для всей системы она является объединением справочных руководств, помогающих пользователю достичь своей цели.
Архитектор системы, как и архитектор здания, является агентом пользователя. В его обязанности входит использование профессиональных и технических знаний в интересах потребителя, а не в интересах продавца, изготовителя и т. д.
Архитектура должна четко отличаться от имплементации. Как отметил Блааув (Blaauw): «Там, где архитектура говорит о том, что происходит, имплементация говорит о том, как это сделано, чтобы оно произошло». В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и головки. Когда ребенок усвоит эту архитектуру, он с одинаковой легкостью сможет определять время как по наручным часам, так и по часам на церковной башне. Имплементация же и его реализация описывают, что происходит внутри: передача усилий и управление точностью каждым из многих механизмов.
Например, в System/360 отдельная компьютерная архитектура имплементирована совершенно по-разному в каждой из девяти моделей. В свою очередь, отдельная имплементация, поток данных, память и микрокод системы Model 30 в разное время служит для четырех разных архитектур: компьютера System/360, мультиплексного канала с 224 логически независимыми подканалами, селекторного канала и компьютера 1401.
То же самое различие в равной степени применимо и к системам программирования. В США принят стандарт Fortran IV. Он является архитектурой для многих компиляторов. В рамках этой архитектуры возможны разные реализации: текст в оперативной памяти или компилятор, быстрая или оптимизирующая, синтаксическая или ситуативная (ad hoc). Точно так же любой ассемблерный язык или язык управления заданиями допускает многие имплементации ассемблера или планировщика. Теперь мы можем заняться глубоко эмоциональным вопросом аристократии и демократии. Не являются ли архитекторы новой аристократией, интеллектуальной элитой, поставленной для того, чтобы указывать бедным безмозглым имплементаторам, что им делать? Не захватила ли эта элита всю творческую деятельность, сделав исполнителей лишь винтиками в механизме? Разве нельзя получить более качественный продукт, внедряя хорошие идеи от всей команды, следуя демократической философии, вместо того чтобы ограничивать разработку спецификаций несколькими избранными?
Что касается последнего вопроса, то он — самый простой. Я не утверждаю, что только у архитекторов возникают хорошие архитектурные идеи. Часто новая концепция исходит от имплементатора или от пользователя. Однако весь мой опыт убеждает меня, и я пытался это показать, что концептуальная целостность системы определяет ее простоту использования. Хорошие функции и идеи, которые не интегрируются с базовыми концепциями системы, лучше оставить в стороне. Если таких важных, но несовместимых идей появляется много, то отбрасывается вся система целиком и снова начинается работа над интегрированной системой с другими базовыми концепциями.
Что касается обвинения в аристократизме, то ответ должен быть и «да», и «нет». Да в том смысле, что архитекторов должно быть немного, их продукт должен выстоять дольше, чем продукт имплементатора, и архитектор находится в центре сил, которые он должен, в конечном счете, направить в интересах пользователя. Если система должна обладать концептуальной целостностью, то руководство концепциями должен взять кто-то один. Это аристократизм, который не нуждается в извинениях.
Разработка внешних спецификаций — такая же творческая работа, как и дизайн имплементаций. Это творчество, просто другого рода. Дизайн имплементации с учетом архитектуры требует и допускает столько же дизайнерского творчества, столько же новых идей и столько же технического блеска, сколько дизайн внешних спецификаций. Действительно, соотношение стоимости к производительности продукта в наибольшей степени будет зависеть от имплементатора, так же как простота использования в наибольшей степени зависит от архитектора.
Существует много примеров из области искусств и ремесел, которые заставляют верить, что дисциплина совершенствует мастерство. И действительно, в афоризме художника утверждается: «форма освобождает». Худшие сооружения — это те, чей бюджет был слишком велик для обслуживаемых целей. Творческая деятельность Баха едва ли подавлялась необходимостью еженедельно выпускать ограниченную по форме кантату. Уверен, что компьютер Stretch имел бы более оптимальную архитектуру, если бы он был жестче ограничен; ограничения, налагаемые бюджетом машины System/360 Model 30, по моему мнению, были во всем благотворны для архитектуры Model 75.
Точно так же я замечаю, что внешнее обеспечение архитектуры усиливает, а не сводит на нет творческий стиль группы по имплементированию. Они сразу сосредоточиваются на той части поставленной задачи, которую никто не решал, и изобретения начинают течь рекой. В неограниченной группе по имплементированию большинство мыслей и дискуссий уходит в архитектурные решения, а на имплементацию отводят короткие сроки.
Этот эффект, который я видел много раз, подтверждается Р. В. Конвеем (R. W. Conway), чья группа в Корнелле построила компилятор PL/C для языка PL/1. Он отмечает следующее: «В итоге мы решили реализовать язык без изменений и усовершенствований, поскольку обсуждение языка отняло бы у нас все силы».
Чем заняться имплементатору во время ожидания?
Унизительно совершить ошибку стоимостью в миллион долларов, однако так она надолго запоминается. Я отчетливо помню ту ночь, когда мы решили, как организовать фактическое написание внешних спецификаций для OS/360. Мы с менеджером по архитектуре и менеджером по реализации управляющей программы отрабатывали план, график работ и распределение обязанностей.
У менеджера по архитектуре было 10 талантливых людей. Он утверждал, что они могут написать спецификации и сделать это правильно. Это займет 10 месяцев, на три больше, чем позволяет график.
У менеджера по реализации управляющей программы было 150 человек. Он утверждал, что они могли бы подготовить спецификации при координации с архитектурной командой; это было бы сделано хорошо и практично, и он вписался бы в график. Кроме того, если бы этим занялась команда по архитектуре, то его 150 человек сидели бы сложа руки в течение 10 месяцев.
На это менеджер по архитектуре ответил, что если я передам ответственность команде по управляющей программе, то на самом деле результат будет получен на 3 месяца позже и гораздо более низкого качества. Я передал ответственность команде по имплементации управляющей программы, и вышло так, как он сказал. Он оказался прав в обоих случаях. Более того, отсутствие концептуальной целостности сделало систему гораздо более дорогостоящей при сборке и изменении, и, по моим оценкам, это на год задержало отладку.
Разумеется, на это ошибочное решение повлияли многие факторы; но подавляющими из них были временные ограничения графика и апелляция к привлечению всех этих 150 имплементаторов к работе. Именно это пение сирен, таящих смертельные опасности, я и сделаю сейчас видимым.
На предложение, что небольшая команда по архитектуре фактически напишет все внешние спецификации для компьютера или системы программирования, имплементаторы выдвигают три возражения:
Последнее возражение касается сроков и фаз. Быстрый ответ — не нанимать имплементаторов до тех пор, пока спецификации не будут завершены. В строительстве действуют по тому же принципу.
В бизнесе компьютерных систем, однако, темпы оказываются быстрее, и каждый хочет сжать график как можно больше. В какой степени спецификация и разработка могут накладываться друг на друга?
Как указывает Блааув, общее творческое усилие включает в себя три разные фазы: архитектуру, имплементацию и реализацию. Оказывается, что они действительно могут быть начаты параллельно и продолжаться одновременно.
Например, в дизайне компьютеров имплементатор может начать работу, как только у него появятся относительно расплывчатые допущения о справочном руководстве, более-менее четкие идеи о технологии и четко определенные целевые критерии по стоимости и производительности. Он может заняться дизайном потоков данных, управляющих последовательностей, грубых концепций упаковки и т. д. Он разрабатывает или адаптирует инструменты, которые ему понадобятся, в особенности систему учета, включая систему автоматизации дизайна.
В то же время на уровне реализации должен быть составлен, усовершенствован и задокументирован дизайн схем, карт, кабелей, рамок, источников питания и памяти. Эта работа идет параллельно с архитектурой и имплементацией.
То же верно и для дизайна систем программирования. Задолго до того, как внешние спецификации будут завершены, у имплементатора есть много дел. С учетом некоторых грубых упрощений касательно функциональности системы, которая в конечном счете будет воплощена во внешних спецификациях, он может продолжить работу. У него должны быть четко определенные пространственные и временные целевые критерии. Он должен знать конфигурацию системы, на которой должен работать его продукт. Затем он может приступить к дизайну границ модулей, структур таблиц, разбиений на проходы и фазы, алгоритмов и всевозможных инструментов. Некоторое время также должно быть потрачено на коммуникацию с архитектором.
На уровне реализации еще много работы. Программирование тоже имеет технологию. Если машина — новая, предстоит сделать многое относительно соглашений о вызове подпрограмм, технологии работы с супервизором, алгоритмов поиска и сортировки.
Концептуальная целостность требует, чтобы система отражала единую философию и чтобы видимую пользователю спецификацию писали несколько человек. Однако вследствие реального разделения труда на архитектуру, имплементацию и реализацию из этого вовсе не следует, что сборка спланированной таким образом системы займет больше времени. Опыт показывает обратное: что целостная система сходится все быстрее и быстрее и требует меньше времени на тестирование. По сути дела, широко распространенное горизонтальное разделение труда было резко сокращено вертикальным разделением труда, и результатом этого стало радикальное упрощение коммуникаций и улучшение концептуальной целостности.
Для Хаброжителей скидка 25% по купону — Брукс
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.