¿Quién debería corregir errores en un entorno Scrum/Agile?

Question

En su opinión, ¿quién debería corregir un error? Un programador, ¿verdad? OK, pero en serio, quién ... déjame explicarte.

Soy un Scrum Master en una serie de proyectos de Scrum. Scrum dice "valla de cerca tus recursos siempre que sea posible", un sentimiento con el que estoy totalmente de acuerdo.

Generalmente integramos un cierto% de edad de cada sprint para corregir errores del sprint anterior, todo bien.

Después de cada Sprint hacemos una demostración y retrospectiva para nuestros clientes, y promovemos nuestro código de desarrollo a un entorno UAT (nuestro cliente generalmente no quiere que un poco de su proyecto entre en funcionamiento, pero eso depende de ellos; mantenemos nuestro lado del trato al asegurarnos de implementar código operativo y comprobable).

Una vez que se completan todos los sprints, tenemos una fase UAT donde el cliente realiza una prueba exhaustiva del software completo para encontrar los errores de último minuto. Ahora, idealmente, ya se habrían capturado, pero en realidad hay algunos que solo se descubrieron durante UAT.

Durante esta fase de UAT, no todos los desarrolladores se necesitan en el proyecto el 100% del tiempo, por lo que nos gusta reasignarlos a otros proyectos. Sin embargo, Scrum dice 'circunesteja tus recursos siempre que sea posible'.

Mi problema es que asigné desarrolladores a la fase UAT de un proyecto mientras comenzaba un proyecto de Scrum con ellos en otro lugar. No es ideal, sin embargo, esta es una realidad comercial en este momento.

que puede:

1) vivir con ella y tienen los desarrolladores fijan su propio código - y asignar un tiempo (por ejemplo, 20%) del desarrollador para UAT del proyecto anterior.

2) Asegúrese de que haya una transferencia y de que 1 o 2 desarrolladores se dediquen al código de corrección de errores el 100% del tiempo.

Me gusta 1), pero hace de los recursos un verdadero dolor en el trasero.

2) me asusta, siento que los desarrolladores no se responsabilizarán por la calidad de su propio código. Siento que hay mucho que decir para garantizar que los desarrolladores se apropien de su propio código, y pedirles que corrijan sus propios errores es una buena forma de garantizar la calidad. A nadie le gusta corregir errores, así que he encontrado que los desarrolladores generalmente intentan hacer un mejor trabajo desde el principio sabiendo que tendrán que solucionar cualquier problema que se plantee de todos modos. Sin embargo, 2) es más fácil de planificar y de recursos. Pero 2) llevará más tiempo, ya que corregir un error en el código de otra persona es costoso en términos de tiempo y recursos. Si se trata de una solución complicada, es posible que necesite la ayuda del desarrollador original de todos modos, y sin duda llevará más tiempo solucionarlo alguien que no esté tan familiarizado con esa sección de la base de códigos.

¿Qué piensa la gente?

Answer 1

Este es un tema muy interesante, la gestión de proyectos es vital y la asignación adecuada de los recursos es esencial.

Un punto que plantearía es que tener solucionadores de errores dedicados puede aumentar la calidad del código. Si estuviera desarrollando un código que tuviera mi nombre en contra del cual yo sabía que otras personas eran responsables, haría todo lo posible para asegurarme de que fuera un buen código.

Quizás se requiera un enfoque combinado. Podría tomar un par de desarrolladores en cualquier proyecto -un par diferente en cada proyecto- y hacerlos responsables de la fase de solución de errores que describe esa responsabilidad por adelantado.De esta forma, pueden garantizar que estén actualizados a medida que avanza el proyecto, así como una transferencia al final. Su asignación de recursos es más fácil y el cliente obtiene soporte de primera clase.

Solo una forma ligeramente diferente de mirarlo.

Saludos Nathan

Answer 2

La gente debe fijar su propio código. Aproveche el hecho de que a nadie le gusta volver y arreglar cosas viejas cuando podrían estar escribiendo cosas nuevas. Si se puede identificar al desarrollador responsable del error, asegúrese de que sean responsables de solucionar el problema. Esto alentará a los desarrolladores a ser más diligentes al escribir código limpio la primera vez, ya que nadie quiere ser visto como la persona que tiene que seguir arreglando cosas que han roto. Esto también es cierto durante el desarrollo cuando alguien rompe la compilación actual.

Actualización: Habiendo dicho eso, no necesariamente sería dogmático al respecto. Las necesidades del cliente son lo primero y si la persona que creó el error no puede reasignarse para realizar la reparación, es posible que deba asignar el arreglo a otra persona.

Answer 3

Creo que las personas también deberían arreglar su propio código. ¿Por qué perder todo el tiempo con los traspasos?

Puede valer la pena realizar UAT cuando se completa cada función; para que los "probadores" trabajen junto con la funcionalidad de prueba de los "desarrolladores" a medida que avanzan. Los probadores deberían poder ejecutar los criterios de UAT.

¡Si hay más problemas dentro de la UAT con los interesados, entonces son solicitudes de cambio o los criterios de aceptación son probablemente ambiguos en primer lugar!

Answer 4

Creo que los errores deben ser resueltos por el desarrollador original. Hacer que los desarrolladores arreglen errores en el código escrito por otra persona podría tomar mucho más tiempo y, además, podría desmotivarlos, ya que corregir errores no es muy emocionante.

Answer 5

Realmente no me gusta la opción 2) porque:

• Da a la gente la sensación de que el trabajo se ha hecho mientras que no tiene (no se hace, hay errores),
• Creo que las personas deberían ser responsables del código que escribieron, no de otros,
• No creo que la "corrección de errores" sea un trabajo, no se está respetando a las personas al hacer esto.

Así que la opción 1) tiene mis preferencias (pero dejen de hablar sobre recursos y recursos).

Por último, una pequeña cita:

Si usted tiene prueba independiente y solucionar los ciclos, que está probando demasiado tarde. --METRO. Poppendieck

Sí, lo sé, es más fácil de decir que de hacer ... pero, no obstante, ella tiene toda la razón.

Answer 6

Soy un desarrollador líder en un equipo impulsado por Scrum. La forma en que tendemos a trabajar en mi organización es la siguiente:

Antes del comienzo de un sprint, a cada desarrollador se le asignará un porcentaje de la productividad que creemos que tendrá durante el sprint.Por ejemplo, un desarrollador con más experiencia y más capacitado probablemente podrá ser productivo en un 70-80% de su tiempo total durante el sprint. Esto da tiempo para reuniones inesperadas, correcciones de errores. Entraré en las correcciones de errores en un momento. Obtendremos las estimaciones de todas las tareas firmadas y luego planificaremos el trabajo de los desarrolladores.

Entrando en el sprint, el desarrollador llevará a cabo su trabajo planificado y completará sus propias pruebas. Si es posible a medida que se completa cada bloque de trabajo, otra fase de prueba se llevará a cabo por el líder de Scrum o por el propietario del producto (gerente de proyecto) solo para asegurarse de que no haya nada obvio que deba examinarse. Cualquier cosa que surja en esta fase de prueba va directamente al desarrollador que la escribió para completar en el sprint. La forma en que lo vemos es que el equipo se ha comprometido efectivamente a completar las tareas que se nos han encomendado al comienzo de un sprint, por lo que debemos completarlas de una forma u otra.

Si un error urgente entra en el equipo y se tiene que hacer en este momento, yo y el líder del melé se darán cuenta de si es posible o no lograrlo sin realizar el trabajo planificado, dependiendo de que tan bien estamos haciendo ES DECIR. si estamos medio día antes de lo previsto y la estimación del error es de medio día, lo haremos sin cambiar el trabajo planificado. Si eso no es posible, volvemos al propietario del producto que decide qué es lo que se tiene que retirar del sprint.

Si un error no urgente se asigna al equipo en parte a través de un sprint, entonces el propietario del producto le da una prioridad y permanecerá en nuestro pozo. Cuando el propietario del producto luego presente nuestros próximos objetivos, dará prioridad a que los errores y el proyecto funcionen juntos y estos se convertirán en nuestros elementos planificados para el próximo sprint.

Lo que hay que tener en cuenta es que no importa de qué proyecto provenga el error. Todo tiene una prioridad y eso es lo que necesita ser administrado. Después de todo, solo tienes un cierto recurso de desarrollo. Cuando se trata de qué desarrollador lo hace, eso depende de varias cosas. no siempre se sabe exactamente de quién es el código que introdujo el error. Especialmente si es de un proyecto muy antiguo. Si el mismo desarrollador puede arreglarlo, obviamente hay un beneficio de tiempo allí, pero ese desarrollador exacto podría no estar disponible. La forma en que lo intentamos y trabajamos es que cualquier desarrollador debe poder trabajar en cualquier tarea determinada. En el mundo real, esto no siempre es posible, pero ese siempre es nuestro objetivo final.

Soy consciente de que he estado dándole vueltas al asunto aquí, sino en respuesta a su pregunta sobre quién debe hacer la corrección de errores en definitiva esto es lo que diría:

• Si se identifica el error durante la mismo sprint que el trabajo que se estaba realizando, envíelo al desarrollador original.
• Si es urgente, debe dirigirse a la persona más indicada para realizar la tarea, ya que debe realizarse lo más rápido posible. Esa podría no ser la persona que originalmente escribió el código, podría ser alguien con más experiencia.
• Si ha priorizado y planeado el error, entonces también debería tener tiempo para determinar quién es el mejor para hacer el trabajo. Esto se basaría en el otro trabajo que necesita hacer, la disponibilidad de los desarrolladores y su juicio general.

Con respecto a los traspasos, estos deberían ser bastante mínimos. Al final del día, los desarrolladores deben escribir el código de una manera que lo deje claro, limpio y obvio para cualquier desarrollador que tenga la tarea de volver a visitarlo. Es parte de mi trabajo asegurarme de que los desarrolladores del equipo estén haciendo esto básicamente.

espero que esto ayude :)

Answer 7

ScrumMasters no asignan recursos para desarrolladores.ScrumMaster es un rol cumplido por alguien en el Equipo.

Dejando eso de lado, el propietario del producto es el "administrador del proyecto del equipo", y debería luchar para asegurar los recursos que se necesitan para estabilizar el producto en producción.

Las prácticas de ingeniería deben mejorarse para que el Equipo (s) se aproxime a cero errores. Los "errores" que se producen después del final de un Sprint tienen que ir al Atrasamiento del Producto para que el Propietario del producto los priorice.

Answer 8

Yo voto por el n. ° 2. Como desarrollador, odio el cambio de contexto y eso es lo que esencialmente impone con el # 1. En cuanto a la cuestión de la propiedad del código, tener desarrolladores propios trozos de código es un antipatrón. Esforzarse por la propiedad compartida: introducir emparejamiento, rotación, etc.

Para el comentario de second @ kevindtimm, UAT es solo otro sprint. Tal vez con menos desarrolladores.

Por otro lado, el núcleo del manifiesto de Agile Software es ofrecer valor comercial incrementalmente, por lo que idealmente se supone que debes presionar a PROD al final de cada sprint. Si es así, entonces no debe UAT ser parte de cada sprint. ¿No es eso para lo que es la demostración?

Answer 9

Parte de esto recae sobre el propietario del producto para priorizar si algunos errores son más importantes que algunas tarjetas en mi mente. Si el pedido es "Solucione estos errores AHORA", entonces debería haber correcciones de errores movidas hasta la parte superior de la lista. Si hay numerosos errores de alta prioridad, entonces puede valer la pena tener un sprint de estabilización donde los errores son corregidos y no se realizan nuevas funcionalidades. Estaría tentado de preguntarle al PO cuánto tiempo quieren que se gaste en errores, aunque no estoy seguro de lo práctico que es.

La idea de tener desarrolladores de mantenimiento es agradable, pero ¿ha considerado dónde puede haber algo de dolor al fusionar los cambios de código de lo que hace el mantenimiento y lo que hacen las nuevas funcionalidades? Sí, esto es solo pisar los pies, pero he tenido algunas fusiones dolorosas donde pasé un día con 2 desarrolladores tratando de promover el código debido a tantos cambios entre un entorno de prueba y desarrollo.

¿Puedo sugerir la idea de que otro desarrollador arregle el error para que alguien más sepa cómo se codificó algo? Tener varias personas trabajando en alguna función puede ayudar a promover la propiedad colectiva en lugar de la propiedad individual del código. Otra parte es que a veces a otra persona le puede resultar más fácil tener un error porque ya corrigió ese tipo de error, aunque esto también puede llevar a una dependencia que debería verificarse regularmente.

Answer 10

En general he seguido la opción 1. A menudo porque los recursos van a otros proyectos. Si haces un análisis de causa raíz discutiendo cómo se crearon los errores, hay un pequeño efecto secundario de vergüenza pública. Si ha inculcado algún sentido de propiedad sobre un proyecto, sus desarrolladores deberían sentirse más que avergonzados si su código muestra un porcentaje mayor de errores que otros o lo que es razonable.

Normalmente encuentro que en estos casos, la mayoría de los desarrolladores se sienten realmente frustrados si están demasiado ocupados arreglando sus viejos errores. No les gusta cuando alguien más tiene que limpiar sus errores.

Inculcar un sentido de pertenencia y orgullo es fundamental. Si no lo ha hecho, siempre cuenta con la amenaza del castigo para que haga lo correcto.

Answer 11

Su equipo NO debe comenzar un nuevo proyecto hasta que se envíe el actual. Creo que la mayoría de los practicantes de scrum argumentarían que no hay lugar en el scrum para UAT (como se hizo en cascada). Lo que estás buscando se llama sprint de estabilización y es tu último sprint justo antes de la puesta en marcha. El equipo ENTERO trabaja en eso.Las cosas que se realizan durante este tiempo incluyen errores de último minuto, ajustes de embellecimiento de GUI, documentación de implementación, guías de ayuda, capacitación de operaciones y almuerzos largos. También es potencialmente un gran momento para que el equipo aprenda algo nuevo por sí mismo sin la "presión" de entregar elementos atrasados ​​o para relajarse un poco antes de comenzar algo nuevo. En función de las expectativas del marco de tiempo de UAT de sus clientes; si tiende a ser del lado más largo; también puede posponer las tareas que no son del cliente a este sprint, como la monitorización de registros, las secuencias de comandos de configuración del servidor, las pantallas de mantenimiento u otras herramientas misceláneas.

Hagas lo que hagas, no hagas ningún trabajo fuera de los límites de Sprint. Es una pendiente resbaladiza en el olvido de la programación de cascada.

Answer 12

¿Por qué no capturar un elemento atrasado llamado "deuda de error" y hacer que el equipo lo estime en cada iteración? Ese artículo se usará para mantener algún tiempo de desarrollador para arreglarlo (como en el n. ° 1).

También estoy un poco preocupado por los errores que aparecen en UAT. ¿Sería posible tener algunas de esas personas de prueba en los equipos para atraparlos antes? Este tipo de cosas es muy común en los proyectos en los que se pasa de la valla de un grupo a otro. La única forma en que he visto que funciona es integrar esos otros grupos en los equipos y repensar las estrategias de prueba. Entonces, UAT hace lo que quiere que haga ... capturar problemas y requisitos de usabilidad. Tienes razón, no desaparecerán por completo, pero se minimizarán.

Answer 13

Siempre trato de que el desarrollador original solucione sus propios errores, en mi humilde opinión. Esta parte es fácil. Si tienes algunos desarrolladores que se comportan de manera poco profesional y eluden su deber de producir software de alta calidad, enciéndelos. Si el problema es cultural, lea "Cambio sin miedo" de Linda Rising y empiece a trabajar en su rol de SM como agente de cambio. Estoy allí contigo, así que no soy yo quien te golpea en la cabeza; Estoy haciendo lo mismo en mi trabajo :)

Sin embargo, tienes problemas más grandes.

¿Eres un Scrum Master que asigna recursos? Yikes. El Scrum guide llama a la SM a

... [servir] el equipo de desarrollo de varias maneras, incluyendo:

entrenar al equipo de desarrollo de la auto-organización ...

Entiendo que no todos tenemos la organización ideal para practicar Scrum; sin embargo, esto debería roerte todos los días hasta que se mejore. El Scrum gude lo pone simplemente:

Los equipos de desarrollo están estructurados y facultados por la organización para organizar y administrar su propio trabajo.

** En segundo lugar, dejar de decir recursos. Solo deténgalo. Los recursos son carbón, madera y gas natural. Las personas no son recursos. **

En tercer lugar, este UAT es un gran impedimento para el equipo de Scrum. Si le entiendo correctamente, el cliente tiene un botón gigante y rojo que puede presionar y explotar completamente el trabajo "Hecho" al decir: "Tiene que arreglar esto antes de que se termine". Todos los equipos de Scrum sometidos a esto ya no tienen velocidad, pronósticos, etc. Todas estas cosas miden el trabajo "Hecho" y potencialmente "Hecho"; ellos dependen del software "Hecho" que es potencialmente enviable.He aquí cómo la guía Scrum describe el incremento del producto:

el incremento es la suma de todos los elementos de la Pila del producto terminado durante un Sprint y el valor de los incrementos de los Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe ser "Listo", , lo que significa que debe estar en condiciones utilizables y cumplir con la definición del Equipo Scrum. Debe estar en condición utilizable independientemente de si el Propietario del Producto decide lanzarlo realmente

Puede mejorar esta situación UAT de varias maneras:

• Convertir UAT del cliente a un simple bucle de retroalimentación es decir, las solicitudes de características salen de la UAT, no notificaciones de software incompleta.
• Consigue que los probadores de UAT trabajen junto a los Desarrolladores durante el Sprint y asegúrate de que el trabajo esté "Hecho".
• No lleve trabajo a un Sprint a menos que una persona UAT esté disponible para validar que el trabajo sea adecuado para su propósito.

Me doy cuenta de que ninguno de estos parecerá "comercialmente" plausable, pero usted es el SM. Si nadie más en toda la organización dice estas cosas, siempre debes estar dispuesto a hacerlo.

Me doy cuenta de que esto suena como una patada en el pantalón, pero necesita año de alguien. Esto es un poco como el escenario old shoe/glass bottle de (wow) hace 10 años.

Por favor, siéntase libre de contactarme si desea explorar más a fondo. Soy un compañero Scrum Master, y estaría feliz de ayudarte a trabajar en este difícil escenario.