Мифический человеко-месяц или как создаются программные системы
Добавить в закладки К обложке
- Посвящение издания 1975 года - Страница 1
- Предисловие к изданию 1995 года - Страница 2
- Предисловие к первому изданию - Страница 4
- Глава 1 Смоляная яма - Страница 6
- Глава 2 Этот мифический «человеко-месяц» - Страница 9
- Глава 3 Операционная бригада - Страница 13
- Глава 4 Аристократия, демократия и системное проектирование - Страница 17
- Глава 5 Эффект второй системы - Страница 21
- Глава 6 Донести слово - Страница 24
- Глава 7 Почему не удалось построить Вавилонскую башню? - Страница 28
- Глава 8 Объявляя удар - Страница 33
- Глава 9 Два в одном - Страница 36
- Глава 10 Документарная гипотеза - Страница 39
- Глава 11 Планируйте на выброс - Страница 41
- Глава 12 Острый инструмент - Страница 45
- Глава 13 Целое и части - Страница 50
- Глава 14 Назревание катастрофы - Страница 55
- Глава 15 Обратная сторона - Страница 58
- Глава 16 Серебряной пули нет — сущность и акциденция в программной инженерии - Страница 62
- Глава 17 Новый выстрел «Серебряной пули нет» - Страница 73
- Глава 18 Заявления «Мифического человеко-месяца»: правда или ложь? - Страница 82
- Глава 19 «Мифический человеко-месяц» двадцать лет - Страница 91
- Эпилог Пятьдесят лет удивления, восхищения и радости - Страница 106
- Примечания и ссылки - Страница 107
В больших проектах можно ощутить такие же выгоды, как и в моих маленьких. [12]
Выдающиеся проектировщики. Главная проблема совершенствования искусства программирования заключена, как всегда, в людях.
Мы можем добиваться хороших проектов, следуя хорошим, а не плохим практическим приемам. Хорошим приемам можно обучать. Программисты принадлежат к наиболее интеллектуальной части общества, следовательно, они в состоянии изучать хорошие приемы. Поэтому важнейшим направлением в Соединенных Штатах является распространение хороших современных приемов. Новые курсы, новые издания, новые организации, такие как Институт инженеров-программистов (Software Engineering Institute) — все это вызвано к жизни стремлением повысить уровень наших практических приемов. Это совершенно правильно.
Тем не менее, я считаю, что мы не сможем подняться еще на одну ступеньку выше, действуя в этом направлении. Выбор правильного метода проектирования определяет различия между плохим и хорошим концептуальным проектом, но не между хорошим и выдающимся. Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой.
И разница немалая — это как Сальери и Моцарт. Одно исследование за другим показывают, что лучшие проектировщики создают структуры, которые быстрее, меньше по размеру, проще, понятнее и разработаны меньшими усилиями. Различия между выдающимся и средним достигают порядка величины.
Нетрудно проследить, что ряд хороших и полезных программных систем проектировался комиссиями и создавался с помощью проектов, состоявших из многих частей. Но программные системы, вызвавшие восхищение страстных поклонников, являются продуктом одного или небольшого числа выдающихся проектировщиков. Посмотрите на Unix, APL, Pascal, интерфейс Smalltalk и даже Fortran — с одной стороны, и Cobol, PL/I, Algol, MVS/370 и MS-DOS — с другой (рис. 16.1).
Рис. 16.1 Имеются ли у этих продуктов страстные поклонники?
Поэтому, высоко ценя нынешние программы передачи технологий и развития обучения, я считаю, что наиболее важной программой, которую мы можем предпринять, является развитие способов воспитания выдающихся проектировщиков.
Ни одна занятая в программировании организация не может игнорировать эту проблему. Хороших менеджеров, как бы мало их ни было, не меньше, чем хороших проектировщиков. Как выдающиеся проектировщики, так и выдающиеся менеджеры встречаются редко. В большинстве организаций значительные усилия тратятся на поиска и выращивание подающих надежды менеджеров. Я не слышал, чтобы кто-либо тратил такие же усилия на поиски и развитие выдающихся проектировщиков, от которых, в конечном счете, зависит техническое превосходство продуктов.
Первое мое предложение состоит в том, чтобы каждая занятая в программировании организация определила для себя и провозгласила, что выдающиеся проектировщики имеют для ее успеха такое же большое значение, как и выдающиеся менеджеры, и что они могут рассчитывать на такие же заботу и вознаграждение. Не только зарплата, но и атрибуты положения — размеры офиса, мебель, техническое оборудование, командировочные фонды, обеспеченность сотрудниками — должны быть полностью равнозначны.
Как растить выдающихся проектировщиков? Место не позволяет обсуждать это пространно, но вот некоторые очевидные шаги:
• Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие — не всегда самые опытные.
• Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.
• Разработать и осуществлять план служебного роста для каждого перспективного проектировщика, включающий тщательно продуманное обучение у передовых проектировщиков, периоды дополнительного формального обучения, краткосрочные курсы, перемежающиеся с самостоятельным проектированием и назначением на руководящие технические должности.
• Обеспечить возможности для взаимодействия и взаимного стимулирования растущих проектировщиков.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112