¿Corregir errores hechos por otras personas es un buen enfoque?

Supongamos la situación en la que un equipo de cuatro desarrolladores está creando una aplicación. Durante la fase de prueba, los usuarios notifican errores. ¿Quién debería arreglarlos? ¿La persona que cometió el código erróneo o alguien que es libre?

¿Cuál es el enfoque preferido en el desarrollo ágil (scrum)?

El enfoque preferido en el desarrollo ágil sería arreglarlos lo más rápido posible, por quien esté disponible. Esto se debe simplemente a que la propiedad del código no corresponde a ninguna persona, sino a todo el grupo de desarrolladores. Si un individuo está constantemente causando errores, ese es otro problema que debe abordarse por separado.

Por defecto la persona. La razón es bastante simple: retroalimentación. Los errores brindan una gran oportunidad para comentarios personales y profesionales. Si alguien más corrigiera mis errores, volvería a cometer el mismo error, porque no aprendería de ello.

Si esa persona no está disponible, alguien más puede solucionarlo, pero la persona debe seguir el ciclo de vida de los errores.

Como primer ministro, evitaría vincular errores con desarrolladores específicos. Si es necesario hacerlo, deje que el gerente funcional / de desarrollo lo haga. Preocúpate por el equipo. Hay un error que el equipo necesita corregir.

No sé cómo scrum maneja este escenario, pero en mi equipo, tenemos algo así como una prueba cruzada / revisión de código. De esta manera, en caso de que se encuentre un error, tanto el desarrollador como el revisor discuten el mejor enfoque para solucionarlo.

Creo que, mientras la solución se ajuste, no importa si el desarrollador o el revisor la aplican. Sin embargo, es importante evitar cualquier tipo de conflicto entre el desarrollador y el probador.

Rgds

Editar: No estoy seguro si me dejé claro, pero es importante destacar que el revisor es otro desarrollador del equipo.

1. Evaluar el error
2. Si será más rápido / tiene más sentido que el desarrollador original lo arregle, déselo
3. Si alguien del equipo puede arreglarlo, deje que lo haga.

Estoy totalmente de acuerdo con Steven en que el código pertenece a todo el equipo; y hay algunas razones más por las que no deberías dar el error a sus creadores:

Como sé, en muchos casos es difícil identificar quién causó el error. Incluso si está utilizando un sistema de gestión de documentos como SVN, rastrear el código de error puede consumir mucho tiempo. Entonces, desde mi punto de vista, simplemente dele el error a cualquiera que sea libre.

Si desea realizar un seguimiento de cómo se produjo el error, en el tiempo libre puede preguntar al reparador sobre el caso (antes de todo el equipo). Como su equipo es pequeño, creo que esto compartiría la experiencia sobre posibles errores y no avergonzaría a nadie.

Solo hay tres razones para preocuparse por quién corrige un error: costo, velocidad y desarrollo profesional.

Y hay pros y contras para los tres. Por ejemplo, el desarrollo profesional, por un lado, es una oportunidad para aprender más sobre el código; por otro, es una oportunidad para reconocer los tipos de errores que comete y evitar algunos en el futuro. O tome el costo, presumiblemente el que cometió el error podría solucionarlo más rápido y probablemente más barato, por otro lado, hay un costo por el tiempo dedicado a identificar quién cometió el error y asignarlo a la persona adecuada: tiempo que en muchos casos supera el de corregir el error.

El enfoque ágil es dejar que los desarrolladores se autoasignen el problema, lo anularía solo por una buena razón.

En mi equipo, siempre decidimos según la prioridad. Si la persona que envió el código está disponible, él / ella lo arregla. Si esa persona está trabajando en una historia de mayor prioridad, cualquier persona que esté disponible y pueda arreglar el código lo antes posible lo solucionará. Si todos están ocupados trabajando en tareas de mayor prioridad en la iteración actual, la corrección se programa en la siguiente iteración de acuerdo con su prioridad en comparación con las otras historias y defectos.

Piensa en: ¿Quién tiene más información sobre el error? El equipo de desarrollo.

Así que deja que decidan qué hacer con el error. Son dueños del código, por lo que son responsables de ello.

Puede ayudarlos administrando el proyecto, asignando un tiempo en el alcance del proyecto para la corrección de errores y dejándolos solos para hacer el trabajo.

Evite tomar muchas decisiones en las que usted (como rol de PM) tenga menos información que el equipo.

Consulte la pregunta sobre: ¿Cómo evitar la microgestión de un equipo de desarrollo de software?

Digo, necesita un sistema de seguimiento de errores, para registrar los errores causados ​​por lo que informó y luego asignar los errores a diferentes personas en función de su carga de trabajo. También indicó el código de quién causó el error, y luego tengo un informe que muestra cuántos codificadores y qué aplicaciones han causado x número de errores durante la semana.

Luego puede mostrar eso a los codificadores, para mostrar cómo están causando errores.

Y la mejor manera de prevenir errores es involucrar a todos para que los solucionen. Me refiero a asignar una corrección de errores a diferentes personas, para dar una experiencia completa de lo que causa errores y lo que los corrige.

Entonces, tal vez después de un mes o dos de todos los que corrigen errores, revise o cree su directriz de estilo de codificación para ayudar a prevenir futuros errores, en todo el sistema, al tener estándares escritos / documentados sobre cómo programar.

Cuando se encuentra un error, es responsabilidad de todo el equipo de desarrollo solucionarlo.

Si la gente cree que su autor debe corregir un error, es como decir "No estoy solucionando el problema, el agujero no está en mi lado del bote". Pero el bote aún se hundirá si el hoyo no está arreglado, y usted está en ese bote con todos los demás.

Las personas deben darse cuenta de que son parte de un equipo y comprender que el código, junto con sus responsabilidades, les pertenece a todos. El éxito de un proyecto depende de todos los miembros del equipo.