Главная - Литература

0 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

Brooks, Frederick Р., Jr. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2d ed.). Reading, MA: Addison-Wesley, 1995. Брукс работал в IBM менеджером разработки OS/360 - гигантского проекта, занявшего 5000 человеко-лет. В своем очаровательном эссе он обсуждает вопросы управления, свойственные маленьким и большим командам, и высказывает исключительно яркое мнение о командах главных программистов.

DeGrace, Peter, и Leslie Stahl. Wicked Problems, Righteous Solutions: Л Catalogue of Modem Software Engineering Paradigms. Englewood Cliffs, NJ: Yourdon Press, 1990. Как следует из названия, книга классифицирует подходы к разработке ПО. Как упоминалось на протяжении всей этой главы, подход должен изменяться при изменении размера проекта, и Дегрейс и Стал делают эту точку зрения очевидной. В разделе «Attenuating and Truncating» главы 5 обсуждается настройка процессов разработки ПО в соответствии с размером проекта и другими формальностями. Книга содержит описания моделей из НАСА и Минобороны, а также большое количество поучительных иллюстраций.

Jones, Т. Capers. «Program Quality and Programmer Productivity». IBM Technical Report TR 02.764 Q2in\x2ivy 1977): 42-78. Статья также доступна в книге Джонса Tutorial: Programming Productivity: Issues for the Eighties, 2d ed. Los Angeles, CA: IEEE Computer Society Press, 1986. Эта статья содержит первый глубокий анализ причин, по которым распределение расходов в больших проектах отлично от маленьких. Это исчерпывающее обсуждение различий между большими и маленькими проектами, включающее требования и меры по обеспечению качества. Статья старая, но все еще интересная.

Ключевые моменты

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

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

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

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

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



ГЛАВА 28

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

Содержание

Ш 28.1. Поощрение хорошего кодирования

28.2. Управление конфигурацией

28.3. Оценка графика конструирования

28.4. Измерения

28.5. гуманное обращение с программистами

28.6. Управление менеджером

Связанные темы

Предварительные требования к конструированию: глава 3

Определение вида ПО, над которым вы работаете: раздел 32

Размер программы: глава 27

Качество ПО: глава 20

На протяжении нескольких последних десятилетий управление разработкой ПО является задачей повышенной сложности. Обсуждение общих вопросов управления программными проектами выходит за рамки данной книги, но в этой главе рассматриваются некоторые специальные темы управления, напрямую связанные с конструированием (рис. 28-1). Если вы разработчик, эта глава поможет вам понять те вопросы, которые менеджеры должны принимать во внимание; если же менеджер - понять, как менеджеры рассматривают разработчиков, а также как эффективно управлять конструированием. Поскольку глава охватывает широкий спектр вопросов, то в некоторых разделах также приведены источники дополнительной информации.




Управление ПО

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

Рис. 28-1. Эта глава охватывает вопросы управления ПО, относящиеся к конструированию

Если вы интересуетесь управлением разработкой ПО, прочитайте раздел 32, чтобы понять различие между традиционными последовательными подходами к разработке и современными итеративными подходами. Не забудьте также прочесть главы 20 и 27, поскольку и требования к качеству, и размеры проекта влияют на то, как должно осуществляться управление данным конкретным проектом.

28.1. Поощрение хорошего кодирования

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

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

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

Вопросы внедрения стандартов

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



0 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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.1486