Результаты поиска

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

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

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

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

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

В моей организации люди считают, что легковес CMMI-это миф, несмотря на доказательства обратного . Каковы ваши впечатления от lightweight CMMI? Вы сделали это, и это хорошо работает для вас?