¿Cuál es la diferencia entre un error y una solicitud de cambio en MSF para CMMI?

Question

Actualmente estoy evaluando el MSF for CMMI plantilla de proceso en TFS para usar en mi equipo de desarrollo, y tengo problemas para comprender la necesidad de tipos de elementos de trabajo de solicitud de cambio y error separados.

Entiendo que es beneficioso poder diferenciar entre errores (errores) y solicitudes de cambio (requisitos de cambio) al generar informes.

Sin embargo, en nuestro sistema actual, solo tenemos un único tipo de solicitud de cambio y solo usamos un campo para indicar si se trata de un error, un cambio de requisito, etc. (este campo se puede usar para crear consultas de informes).

¿Cuáles son los beneficios de tener un flujo de trabajo separado para errores?

También me confunde el hecho de que los desarrolladores puedan enviar trabajos contra un error. o una solicitud de cambio, pensé que el flujo de trabajo previsto era que los errores generaran solicitudes de cambio, que es a lo que el desarrollador hace referencia al realizar cambios.

Answer 1

@Lucas

No estoy en desacuerdo con usted, pero esta diferencia suele ser la explicación que se da de por qué hay dos procesos diferentes disponibles para manejar los dos tipos de problemas.

Yo diría que si el color de la página de inicio se diseñó originalmente para ser rojo y, por alguna razón, es azul, es una solución rápida y no necesita involucrar a muchas personas ni horas de trabajo para realizar el cambio.Simplemente revise el archivo, cambie el color, vuelva a registrarlo y actualice el error.

Sin embargo, si el color de la página de inicio fue diseñado para ser rojo, y es rojo, pero alguien piensa que necesita ser azul, eso es, para mí de todos modos, un tipo diferente de cambio.Por ejemplo, ¿alguien ha pensado en el impacto que esto podría tener en otras partes de la página, como imágenes y logotipos superpuestos al fondo azul?¿Podría haber límites para las cosas que se ven mal?El enlace subrayado es azul, ¿aparecerá?

Por ejemplo, soy daltónico rojo/verde, cambiar el color de algo no es, para mí, algo que me tome a la ligera.Hay suficientes páginas web en la web que me dan problemas.Sólo para dejar claro que incluso el cambio más trivial puede no serlo si se considera todo.

El cambio de implementación final real probablemente sea muy parecido, pero para mí es una solicitud de cambio. es una bestia diferente, precisamente porque hay que pensar más en ella para asegurarse de que funcionará como se espera.

Un error, sin embargo, es que alguien dijo así es como lo vamos a hacer y luego alguien lo hizo diferente.

Una solicitud de cambio es más como pero también debemos considerar esta otra cosa...Mmm....

Por supuesto, hay excepciones, pero déjame analizar tus ejemplos.

Si el servidor fuera diseñado para manejar más de 300.000.000.000 páginas vistas, entonces sí, es un error que no lo haga.Pero diseñar un servidor para manejar tantas páginas vistas es más que simplemente decir nuestro servidor debería manejar 300.000.000.000 páginas vistas, debe contener un muy especificaciones detalladas sobre cómo puede hacer eso, hasta las garantías de tiempo de procesamiento y los tiempos promedio de acceso al disco.Si el código se implementa exactamente como se diseñó y no puede funcionar como se esperaba, entonces la pregunta es: ¿Lo diseñamos incorrectamente o lo implementamos incorrectamente?.

Estoy de acuerdo en que en este caso, si se debe considerar un defecto de diseño o un defecto de implementación depende de la razón real por la que no está a la altura de las expectativas.Por ejemplo, si alguien supusiera que los discos son 100 veces más rápidos de lo que realmente son, y se considera que esta es la razón por la cual el servidor no funciona como se esperaba, diría que se trata de un error de diseño y que alguien necesita rediseñarlo. .Si aún no se cumple el requisito original de tantas páginas vistas, es posible que deba realizarse un rediseño importante con más datos en memoria y similares.

Sin embargo, si alguien simplemente no ha tenido en cuenta cómo funcionan los discos raid y cómo beneficiarse correctamente de los medios seccionados, eso es un error y es posible que no necesite un cambio tan grande para solucionarlo.

Una vez más, por supuesto habrá excepciones.

En cualquier caso, la diferencia original que mencioné es la que he encontrado cierta en la mayoría de los casos.

Answer 2

Tenga en cuenta que una parte de la definición de tipo de elemento de trabajo para TFS es la definición de su "flujo de trabajo", es decir, los estados que puede tener el elemento de trabajo y las transiciones entre los estados.Esto se puede garantizar mediante una función de seguridad.

Entonces, en términos generales, una "Solicitud de cambio" sería iniciada y aprobada por alguien relativamente alto en una organización (alguien con derechos de "Patrocinio" relacionados con el gasto de los recursos para realizar un cambio (posiblemente muy grande) en el sistema.En última instancia, esta persona sería la que aprobaría que el cambio se haya realizado correctamente.

Sin embargo, para un "Error", CUALQUIER usuario de la aplicación debería poder iniciar un Error.

En una organización en la que implementé TFS, solo los jefes de departamento pueden ser los originadores de una "solicitud de cambio", pero los "errores" se crearon a partir de tickets de la "mesa de ayuda" (no automatizados, solo a través del proceso...)

Answer 3

En general, aunque no puedo hablar en nombre de CMM, las solicitudes de cambio y los errores se manejan y consideran de manera diferente porque normalmente se refieren a diferentes partes del ciclo de vida de su aplicación.

Un error es un defecto en la implementación de su programa.Por ejemplo, si diseña su programa para poder sumar dos números y darle la suma al usuario, un defecto sería que no maneja correctamente los números negativos y, por lo tanto, un error.

Una solicitud de cambio es cuando tienes un defecto de diseño.Por ejemplo, es posible que haya dicho específicamente que su programa no debe manejar números negativos.Luego se presenta una solicitud de cambio para rediseñar y así reimplementar esa parte.Es posible que el defecto de diseño no sea intencional, pero podría deberse fácilmente a que simplemente no consideró esa parte cuando diseñó originalmente su programa, o a que se inventaron o descubrieron nuevos casos que no existían en el momento en que se creó el diseño original. desde.

En otras palabras, un programa puede funcionar exactamente como se diseñó, pero es necesario cambiarlo.Esta es una solicitud de cambio.

---

Normalmente, corregir un error se considera una acción mucho más económica que ejecutar una solicitud de cambio, ya que el error nunca fue pensado para ser parte de su programa.El diseño, sin embargo, sí lo fue.

Y, por lo tanto, podría ser necesario un flujo de trabajo diferente para manejar los dos escenarios diferentes.Por ejemplo, es posible que tenga una forma diferente de confirmar y presentar errores que la que tiene para las solicitudes de cambio, lo que podría requerir más trabajo para establecer las consecuencias del cambio.

Answer 4

Un error es algo que no se cumple en un requisito que ya ha sido aprobado para su implementación.

Una solicitud de cambio debe pasar por un ciclo en el que se debe estimar el impacto y el esfuerzo para ese cambio, y luego debe aprobarse para su implementación antes de que pueda comenzar a trabajar en él.

Los dos son fundamentalmente diferentes bajo CMM.

Answer 5

¿Es incorrecta mi suposición entonces de que las solicitudes de cambio deberían generarse a partir de errores?Estoy confundido porque no creo que todos los errores deban aprobarse automáticamente para su implementación; pueden ser triviales y al menos en nuestro caso pasarán por el mismo proceso de revisión que una solicitud de cambio antes de asignarlos a un desarrollador.