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

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

Систематическая ошибка SCM заключается в избыточном контроле. Абсолютно надежный способ прекратить автомобильные аварии - это запретить всем водить машину, а абсолютно надежный способ предотвратить проблемы с разработкой ПО - прекратить всю разработку. Хотя это и один из вариантов контроля изменений, это неудачный способ разрабатывать ПО. Необходимо тщательно планировать SCM, чтобы оно давало преимущества, а не было камнем на шее.

п«* * *п маленьком проекте, разрабатываемом в одиночку, вы,

116рШфвСТ112Я СИЯЫЛХа U ВЛИЯНИИ

размера Проекта на конструирО вполне возможно, обойдетесь без всякого SCM, исключая вание см. niaey 27. планирование периодического нерегулярного создания ре-

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

Изменения в требованиях и проекте

Перекршнай ешш Одни под- время разработки вас переполняют идеи о том, как улуч-ходы к разработке лунше под- ить систему Если вы будете реализовывать каждое изме-держивают изменения, другие нение, вы скоро почувствуете, что бежите на месте: хотя - хуже (см, раздел 3.2). система будет постоянно меняться, она не будет приближать-

ся к завершению. Вот некоторые советы по контролю изменений в проекте.

Следуйте систематической процедуре контроля изменений Систематическая процедура контроля изменений - это настоящая находка в случае, когда у вас большое количество запросов на изменение (см. раздел 34). Установив систематическую процедуру, вы даете понять, что изменения будут рассмотрены в контексте наибольшей пользы для проекта в целом.

Обрабатывайте запросы на изменения группами Реализация простых изменений по мере возникновения идей выглядит заманчиво. Проблема такого подхода в том, что хорошие изменения могут затеряться. Если вы задумали простое изменение при 25%-й готовности проекта и сроки это позволяют, вы внесете это изменение. Если вы придумали еще одно простое изменение, когда готово 50% проекта, но вы уже опаздываете, вы не будете его вносить. Когда сроки начинают поджимать в конце проекта, уже не имеет значения, что второе изменение в 10 раз лучше, чем первое: вы не в том положении, чтобы делать несущественные исправления. Часть самых лучших изменений может уйти сквозь пальцы просто потому, что подумали о них слишком поздно.

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



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

Независимо от того, как оптимистично вы оцениваете предложенное изменение, воздержитесь от немедленной оценки. Такие оценки обычно ошибочны в два и более раз.

Относитесь с подозрением к изменениям большого „„3 у друУ объема Некоторое количество изменений неизбежно, но у работу с изме-

большой объем запросов на изменение сигнализирует о том, нениями можно найти в оодраз-что требования, архитектура или высокоуровневое проек- деле «Что депать при изменении тирование не были выполнены достаточно качественно, требований во время конструи-чтобы способствовать эффективному конструированию. JTJoLT? Возврат к работе над требованиями или архитектурой мо- менениям в коде см. в гла&е 24. жет показаться накладным, но он гораздо дешевле, чем конструирование ПО более одного раза или выбрасывание кода тех функций системы, которые, как выяснилось, вам не нужны.

Учредите комитет контроля изменений Работа комитета контроля изменений состоит в отделении зерен от плевел в запросах на изменение. Любой, кто хочет предложить изменение, отправляет запрос этому комитету. Термин «запрос на изменение» относится к любому запросу который приводит к изменению ПО: идея новой функции, изменение в существующей функциональности, «отчет об ошибке», который сигнализирует о действительной или мнимой ошибке, и т. д. Комитет периодически собирается и рассматривает предложенные изменения. Он одобряет, отвергает или откладывает каждое изменение. Комитеты контроля изменений считаются лучшим решением для расстановки приоритетов и контроля изменений в требованиях, но они еще довольно редко встречаются в коммерческих структурах Gones, 1998; Jones, 2000).

Соблюдайте бюрократические процедуры, но не позволяйте страху перед бюрократией препятствовать эффективному контролю изменений

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

Контроль изменений имеет тенденцию к бюрократизации, поэтому важно искать способы по рационализации этого процесса. Если вы предпочитаете не исполь-



зовать традиционные запросы на изменения, заведите почтовый адрес «Change-Board» и обяжите сотрудников посылать на него запросы на изменение. Или попросите высказывать предложения по изменениям интерактивно на заседаниях комитета контроля. Особенно действенная мера - запись запросов на изменения в качестве дефектов в систему отслеживания дефектов. Ревнители порядка могут классифицировать такие изменения как «дефекты требований», или их можно считать изменениями, а не дефектами.

Вы можете создать официальный Комитет контроля изменений, или Группу планирования продукта или Военный совет, которые будут выполнять традиционные обязанности комитета контроля изменений. Или вы можете выбрать отдельного человека в качестве Царя изменений. Но как бы вы это ни назвали, сделайте это!

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

Изменения в коде программного обеспечения

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

Программы управления версиями С хорошим ПО для управления версиями работать так легко, что вы едва замечаете его существование. Оно особенно полезно в групповых проектах. Один вариант управления версиями блокирует исходные файлы так, что только один человек может модифицировать файл в некоторый момент времени. Обычно, когда вам нужно поработать с каким-то исходным кодом, вы должны снять этот файл с учета (check out) в системе управления версиями. Если кто-то уже проделал эту процедуру, вы получите сообщение, что этого сделать нельзя. Когда вы извлечете этот файл, вы сможете с ним работать так же, как и без использования системы управления версиями до тех пор, пока не будете готовы снова зарегистрировать его (check in). Другой вариант управления версиями позволяет нескольким людям работать с файлами одновременно и следит за необходимостью слияния изменений во время регистрации файлов. В обоих случаях, когда вы регистрируете файл, система спрашивает вас, почему вы его изменили, и вы указываете причину.

При таких скромных усилиях вы получаете несколько больших преимуществ:

вы не наступаете никому на ноги, работая с файлом в тот момент, когда с ним работает кто-то другой (или хотя бы вы знаете об этом);

вы легко можете обновить свои копии всех файлов проекта, чтобы они соответствовали текущим версиям, обычно одной командой;



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.0021