В чем разница между ошибкой и запросом на изменение в MSF для CMMI?

В настоящее время я оцениваю MSF for CMMI шаблон процесса в TFS для использования в моей команде разработчиков, и у меня возникли проблемы с пониманием необходимости отдельных типов рабочих элементов запроса на изменение и ошибки.

Я понимаю, что при создании отчетов полезно иметь возможность различать ошибки (ошибки) и запросы на изменение (изменение требований).

Однако в нашей текущей системе у нас есть только один тип запроса на изменение и мы просто используем поле, чтобы указать, является ли это ошибкой, изменением требований и т. Д. (Это поле можно использовать для создания запросов отчетов).

Каковы преимущества отдельного рабочего процесса для ошибок?

Меня также смущает тот факт, что разработчики могут отправлять работы по устранению ошибки или запроса на изменение. Я думал, что предполагаемый рабочий процесс был для ошибок, чтобы генерировать запросы на изменение, на которые разработчик ссылается при внесении изменений.

Ответов (6)

Решение

@ Люк

Я не согласен с вами, но это различие обычно является объяснением того, почему существует два разных процесса, доступных для обработки двух типов проблем.

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

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

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

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

Ошибка, однако, заключается в том, что кто-то сказал, что мы собираемся сделать это именно так, а потом кто-то сделал это по-другому.

Запрос на изменение больше похоже , но мы должны рассмотреть эту другую вещь, а ... хм ... .

Конечно, есть исключения, но позвольте мне разобрать ваши примеры.

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

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

Однако, если кто-то просто не учел, как работают рейд-диски и как правильно использовать чередующиеся носители, это ошибка, и для ее исправления может не потребоваться такое серьезное изменение.

Опять же, конечно, будут исключения.

В любом случае, изначальное различие, которое я указал, является истинным в большинстве случаев.

Реализация всегда исходит из требований. Это может быть от менеджера по продукту, это может быть случайная мысль некоторых из вас. Это может быть задокументировано, может быть из какого-то разговора. В конце концов, даже такая простая вещь a := a + 1, как «настоящая» реализация, будет основана на компиляторе, компоновщике, процессоре и т. Д., Что зависит от физических законов реальной жизни.

Ошибка - это то, что реализовано против ОРИГИНАЛЬНОГО требования. Кроме того, это запрос на изменение.

Если требование изменилось и реализация тоже должна быть изменена, это запрос на изменение.

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

На самом деле все, что не задокументировано должным образом, следует рассматривать как запрос на изменение. Менеджер по продукту забыл что-то добавить в историю? Извините, это запрос на изменение.

Все запросы на изменение должны быть правильно оценены и обозначены. Разработчикам платят за отправку запросов на изменение, а не за исправление ошибок и исправлений.

Ошибка - это то, что нарушено в требовании, которое уже было одобрено для реализации.

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

В CMM они принципиально различаются.

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

Как правило, хотя я не могу говорить о CMM, запросы на изменение и ошибки обрабатываются и рассматриваются по-разному, потому что они обычно относятся к разным частям жизненного цикла вашего приложения.

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

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

Другими словами, программа может работать в точности так, как задумано, но ее необходимо изменить. Это запрос на изменение.


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

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

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

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

Однако для «Ошибки» ЛЮБОЙ пользователь приложения должен иметь возможность инициировать ошибку.

В организации, в которой я внедрил TFS, только руководители отделов могут быть инициаторами «Запроса на изменение», но «Ошибки» создавались из тикетов «Службы поддержки» (не автоматически, просто в процессе ...)