project management - significado - ¿Cómo se aplica Scrum al mantenimiento y a las mejoras del código heredado?

scrum software (12)

Trate todas las "correcciones de errores" que no tienen una historia como código nuevo. Estírelos y trabaje de forma normal. Al tratarlos como nuevas historias, construirás una biblioteca de historias y pruebas. Solo entonces puede comenzar a fijar el comportamiento de la aplicación.

Eche un vistazo a Working Effectively with Legacy Code de Michael Feathers. Aquí hay un enlace a un extracto. http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

-Jason

Como sugiere el título ... ¿Cómo puedo aplicar un proceso de scrum a todo lo que no funciona en el código nuevo y se puede estimar hasta cierto punto?

¿Cómo puedo aplicar un proceso de scrum al mantenimiento y reparaciones de emergencia (que puede llevar de 5 minutos a 2 semanas para arreglar) el tipo de entorno en el que todavía me gustaría planear hacer las cosas?

Básicamente, ¿cómo supero tareas y tareas no planificadas que son muy difíciles de estimar con el proceso de scrum? o simplemente estoy aplicando el proceso incorrecto para este entorno?

Básicamente, ¿cómo supero tareas y tareas no planificadas que son muy difíciles de estimar con el proceso de scrum? o simplemente estoy aplicando el proceso incorrecto para este entorno?

Estás utilizando el proceso incorrecto para este entorno. Lo que necesita es un proceso de gestión de pila / cola que sea independiente de su proceso de desarrollo de SCRUM planificado / estimado.

La razón de esto es simple y doble:

Como mencionas en tu publicación, a menudo es muy difícil estimar las tareas de mantenimiento, especialmente cuando se trata de sistemas heredados. Las tareas de mantenimiento en general y los sistemas heredados tienen una tendencia específicamente a involucrar problemas ''rizados'', o tener una larga ''cola'', donde una solución aparentemente simple requiere un cambio un poco más difícil a otro componente, lo que a su vez requiere una revisión de la operación de algún subsistema, que a su vez ... entiendes el punto.
Con bastante frecuencia cuando se trata de tareas de mantenimiento, cuando termina de calcular, también ha terminado de resolver el problema . Esto hace que el proceso de estimación sea redundante como herramienta de planificación. Aquellos que insisten en dividir la estimación de la solución del problema para tareas de mantenimiento simplemente están agregando gastos generales innecesarios.

En pocas palabras, necesita un sistema de colas. Tendrá estos componentes:

Un ''grupo'' de tareas que se han identificado como que requieren atención. Los ítems nuevos deben ir siempre al grupo, nunca a la cola.
Un proceso de mover estas tareas fuera del grupo y hacia la cola. Usualmente se requiere una combinación de conocimiento comercial / técnico.
Una cola de tareas que están claramente ordenadas de modo que los desarrolladores responsables de dar servicio a la cola simplemente puedan elegir desde el principio.
Un método para mover elementos en la cola (volver a priorizar). Para permitir ''saltar la cola'' para artículos críticos / de emergencia.
Un método para entregar los artículos completos que no interrumpe el servicio de la cola. Esto es importante porque la sobrecarga de la entrega de artículos de mantenimiento suele ser significativamente menor que el trabajo de desarrollo. No quiere que su equipo de mantenimiento se quede esperando un día esperando que los equipos de compilación y prueba les den la autorización cada vez que entregan una corrección de errores.

Hay otros matices para la administración de colas, pero tenerlos en su lugar debería establecerlo en el camino correcto.

Como sugiere el título ... ¿Cómo puedo aplicar un proceso de scrum a todo lo que no funciona en el código nuevo y se puede estimar hasta cierto punto?

Por el contrario, escuché a los equipos que consideran que la adopción de Scrum es más fácil en la fase de mantenimiento, ya que los cambios son más pequeños (sin grandes cambios de diseño) y, por lo tanto, son más fáciles de estimar. Cualquier nueva solicitud de cambio se agrega a la acumulación de productos, la calculan los desarrolladores y el propietario del producto la prioriza.

¿Cómo puedo aplicar un proceso de scrum al mantenimiento y reparaciones de emergencia (que puede llevar de 5 minutos a 2 semanas para arreglar) el tipo de entorno en el que todavía me gustaría planear hacer las cosas?

Si insinúa actividad de lucha contra incendios, conserve una parte de la cuota de trabajo de iteración para tales actividades. Según las tendencias / actividades históricas, debería poder decir, por ejemplo, que tenemos una velocidad de 10 puntos por iteración. (4 persona-equipo 5 días-iteración). Cada uno de nosotros pasa aproximadamente un día a la semana respondiendo a emergencias. Por lo tanto, solo deberíamos elegir 8 puntos de los elementos atrasados para que la próxima iteración sea realista. Si no tenemos problemas de emergencia, seleccionaremos el siguiente ítem superior de la lista de prioridades.
CoryFoy menciona un enfoque más dinámico / en tiempo real con kanban post-its en su respuesta.

Básicamente, ¿cómo supero tareas y tareas no planificadas que son muy difíciles de estimar con el proceso de scrum? o simplemente estoy aplicando el proceso incorrecto para este entorno?

AFAIR Scrum no exige una técnica de estimación ... Utilice uno con el que el equipo se sienta más cómodo ... días hombre / puntos de historia / etc. La única manera de mejorar en la estimación es la práctica y la experiencia, creo. Cuanto más se sientan las mismas personas para estimar nuevas tareas, mejores serán sus estimaciones. En un entorno de mantenimiento, supongo que es más fácil de estimar porque el sistema es más o menos conocido por el grupo. Si no, programe / use picos para obtener más claridad.

Intuyo que estás intentando comer un elefante aquí ... Sugeriría los siguientes bocados

Esto depende mucho del ciclo de vida de la aplicación. Si esta es una aplicación ''Sunset'' que se volverá a intentar pronto, por supuesto, el foco estará solo en corregir los errores de mayor prioridad.

Si el producto es ''Maduro'' y tiene una hoja de ruta y continúa evolucionando, usted tendrá soluciones y mejoras de las que ocuparse. Hay un gran impulso para mantener el diseño limpio y evolucionar mediante la refactorización. Esto puede significar versiones periódicas menores y mayores [a excepción de eFixes - correcciones de emergencia / hotfixes]. Puedes hacer una pausa ágil para el deleite de tu corazón, ya que la mejora y las soluciones podrían incluirse en la historia y formar parte de tu backlog de Sprint. Toda la lista haría su acumulación de productos.

En pocas palabras: si quiere refactorizar y mantener limpio el diseño de su aplicación [los programadores tienden a tomar atajos si el foco está exclusivamente en la corrección de errores], solo podría suceder con una aplicación ''viva''. Uno que está evolucionado y actualizado. Y ágil es un ajuste natural.

Incluso si solo tiene correcciones (que es una aplicación Turing completa;) o Sunset), es útil si se pueden rodar en un sprint y pasar al final de producción de cada sprint. Si las correcciones deben incorporarse a la producción cuando están corregidas, es mucho más difícil aplicar Scrum.

Hemos aplicado scrum en este contexto.

Algunas de las claves del éxito.
1. Todos en la empresa compran la idea del scrum (esto es crucial para el éxito)
2. Sprint de aproximadamente 2 semanas (nuestro sprint de 2 o 3 primeros intentos fue de 1 semana para comprender el proceso)
3. Bajo ninguna circunstancia se podría agregar un punto al sprint actual 4. Si surge una emergencia real, detenga el sprint, haga una retrospectiva y comience un nuevo sprint.
5. Tómese el tiempo para la retrospección (tiempo para compartir el último sprint y analizarlo)
6. En un sprint, inserte al menos una tarea para mejorar el proceso (a menudo agregado a la acumulación en la retrospectiva); es bueno para la moral de la tropa y al final del día estarás en tu camino para tener menos emergencia.
7. TIME BOXED reunión de pie diaria

Para la estimación, generalmente cuanto más estimas, más preciso te vuelves. Lo que está bien con Scrum es que cada programador elija su tarea y pueda establecer una nueva estimación si cree que no es realista. Y si todavía tiene algún problema con la estimación, deje que su equipo encuentre una solución ... puede sorprenderse con lo que ofrecen.

Para la corrección de 2 semanas. Si es la estimación original, córtela en pedazos más pequeños. Si hiciera una estimación más optimista (digamos 2-3 días), el problema debería aumentar como bloqueador en la reunión de pie. Tal vez alguien más tenga ideas sobre cómo solucionarlo. Puede decidir hacer un par de programación para encontrar una solución. En algún momento, solo para describir el error a otro programador ayuda mucho a depurar. También puede retrasarlo después de otra tarea en el sprint. La idea es entregar tareas completamente funcionales. Si no tienes tiempo para arreglarlo por completo y demostrarlo, incluso si estás al 90% hecho (¡sí! Sabemos lo que significa), consideras que no se hizo en el sprint. En el próximo sprint podrá abordarlo con la estimación de tiempo correcta.

Finalmente, por lo que entendí, Scrum se trata más de tener "herramientas" para mejorar su proceso. Comienzas con algo simple. Usted hace iteración pequeña. En cada iteración tienes un FIX TARGET para completar en lugar de una lista de errores infinita. Debido a que elige sus tareas de la lista en la planificación (se opone a que se las asigne), se compromete más a entregarla. Con la reunión de pie, te encuentras con tu pareja todos los días con tu lista de TODO ... quieres respetar tu compromiso que hiciste el día anterior. Con la iteración, se toman el tiempo para hablar entre ellos e identificar qué está yendo bien y qué debe mejorarse. También tomas medidas para mejorarlo y continuar haciendo lo que funciona. No temas cambiar nada, incluso lo que dije;) / incluso cualquier básico del Scrum en sí ... La verdadera clave es adaptar Scrum a lo que tu equipo necesita para ser feliz y productivo. No lo verás después de una iteración, pero muchos de ellos ...

Nadie dijo que los elementos atrasados tienen que ser un código nuevo. El trabajo de mantenimiento, ya sean correcciones de fallas, mejoras o arreglos de datos, se puede poner en la cartera de pedidos del Producto, se puede estimar y priorizar. Este es en realidad uno de los mayores beneficios de usar Scrum: no hay más discusiones con los usuarios sobre si algo es una corrección de errores o una mejora.

Con Waterfall, hay una comprensión tácita de que los errores son responsabilidad de los desarrolladores. De alguna manera, están en el gancho para arreglarlos sin afectar el desarrollo de nuevos códigos y características. Entonces son "gratis" para los usuarios, pero un inconveniente masivo para los desarrolladores.

En Scrum, reconoces que todo el trabajo lleva tiempo. No hay "gratis". Por lo tanto, los desarrolladores aceptan libremente que algo es un error, pero aún se incluye en la cartera de pedidos del producto. Luego, le corresponde al Cliente decidir si corregir el error es más importante que agregar nuevas características. Hay algunos errores con los que puedes vivir.

Recomiendo encarecidamente ver qué valor le dan los sprints / iteraciones. Tiene sentido aplicarlos cuando hay suficientes tareas para hacer que necesitan ser priorizadas y cuando sus partes interesadas necesitan saber aproximadamente cuándo se hará algo.

En este caso, recomiendo combinar tres enfoques:

programe tantas tareas entrantes como sea posible para la siguiente iteración lo antes posible
utilice el clima de ayer para planificar la cantidad de memoria intermedia que necesita planificar para hacer frente a las tareas que deben abordarse de inmediato
utilice sprints muy cortos, para maximizar el número de tareas que pueden esperar hasta al menos el inicio de la siguiente iteración

De hecho, eso es cierto para todos los proyectos de Agile / Scrum, ya que están en modo de mantenimiento, agregando a un sistema existente y funcional, desde la iteración 2.

En caso de que las iteraciones no proporcionen suficiente valor, es posible que desee echar un vistazo a un sistema kanban / queuing. Básicamente, cuando haya terminado con una tarea, simplemente saque la siguiente tarea de una cola de tareas priorizada.

Si tienes tanta rotación en tu entorno, tu clave será iteraciones más cortas. He oído hablar de equipos que realizan iteraciones diarias. También puede avanzar hacia un estilo de tipo Kanban donde tiene una cola que tiene un límite fijo (por lo general muy bajo, como 2 o 3 elementos) y no se pueden agregar más elementos hasta que se completen.

Lo que haría es probar iteraciones de una semana con los resúmenes diarios, la priorización del backlog y "hecho, hecho". Luego vuelva a evaluar después de 5 o 6 semanas para ver qué podría mejorarse. No tengas miedo de probar el proceso tal como está, y no tengas miedo de modificarlo en tu entorno una vez que lo hayas probado.

También había un PDF llamado Agile for Support and Operations en 5 minutos que se publicó recientemente en la lista de desarrollo de Scrum en Yahoo!

Trate todas las correcciones y mejoras como historias individuales y estime en consecuencia. Mi opinión personal es que las cosas que tardan menos de 10-15 minutos en arreglarse deberían hacerse de inmediato. Para aquellos que toman más tiempo, se vuelven parte del ciclo de iteración actual de "arreglar y mejorar". Al igual que con la estimación de los requisitos regulares, tomas una mejor estimación como equipo. A medida que sale a la luz más información, y las estimaciones están fuera de ajuste, la iteración y los próximos sprints se ajustan.

Es difícil aplicar un ciclo de iteración a las correcciones y mejoras, ya que con más frecuencia no lo hacen, impiden que el sistema funcione como deberían y el "negocio" ejerce presión para que entren en funcionamiento lo antes posible. En este punto, puede funcionar mejor pasar a un ciclo de iteración realmente corto, como una o dos semanas.

Usted pregunta cómo usar un proceso para emergencias. Intente reservar la palabra "emergencia" para las cosas que requieren piratear el código en el entorno de producción con los usuarios conectados al mismo tiempo. De lo contrario, es probable que las partes interesadas abusen de la palabra y llamen a una emergencia sobre cualquier cosa que les gustaría tener realmente rápido. La falta de proceso no significa estar fuera de control: alguien debe ser responsable de declarar la emergencia, y alguien (la mejor práctica es otra persona) debe autorizar los cambios fuera del proceso normal y luego asumir la responsabilidad por ello.

Aparte de eso, la sugerencia de usar cada iteración para completar una serie de correcciones y mejoras es probablemente la mejor manera de hacerlo.

En mi opinión, depende de la frecuencia con la que tengas un lanzamiento "real". En nuestro caso específico, tenemos un lanzamiento importante cada año y algunos lanzamientos menores durante el año.

Esto significa que cuando se realiza un sprint, no se despliega inmediatamente en nuestro servidor de producción. La mayoría de las veces se realizarán algunos sprints antes de que finalice nuestro ''proyecto'' completo. Por supuesto, demostramos nuestros sprints y desplegamos nuestros sprints en nuestro servidor de pruebas. El ''proyecto'' en su totalidad se someterá a algunas pruebas de extremo a extremo y finalmente se implementará en nuestros servidores de producción -> esta es una versión menor. Podemos decidir que no lo implementaremos inmediatamente en nuestro servidor de producción, cuando por ejemplo depende de otros productos / proyectos que necesitan actualizarse primero. Luego implementamos esto en nuestro lanzamiento principal.

Pero cuando surgen problemas en nuestro servidor de producción, es posible que se requiera una acción inmediata. Por lo tanto, no hay tiempo para preguntarle al dueño del producto cuál es el objetivo o la importancia (si es que tenemos uno para los problemas de sunc) porque bloquea el trabajo de nuestros clientes con nuestra aplicación. En casos tan urgentes, este tipo de problemas no se incluirán en una acumulación de productos o en un sprint, sino que son tareas de mantenimiento puras que deben resolverse, probarse y desplegarse lo antes posible y como un elemento individual.

¿Cómo combinamos esto con nuestro Sprint? Para mantener a los miembros de nuestro equipo enfocados en el sprint, decidimos ''optar por no participar'' en nuestro equipo. Esto significa que una o más personas no formarán parte de un equipo para un determinado Sprint y pueden centrarse en otros trabajos como estos arreglos urgentes. El próximo Sprint, esta persona volverá a formar parte del Equipo y otra persona será responsable de las llamadas de emergencia.

Otra opción podría ser que preveamos como el 20% del tiempo en un Sprint para ''tareas no planificadas'', pero esto dará una indicación equivocada sobre la cantidad de trabajo que podemos hacer en un Sprint (no tendremos la misma cantidad de soluciones urgentes durante cada sprint). También queremos que los miembros de nuestro equipo se concentren en el Sprint y hacer estas correcciones urgentes en un Sprint distraerá a los miembros de nuestro equipo. ''cambio de contexto'' también significará pérdida de tiempo e intentaremos evitar eso.

Todo depende de su "entorno" y de cuán rápido deben solucionarse los problemas urgentes.

He tenido cierto éxito al reconocer que un porcentaje de un Sprint consiste en esos "fuegos" no planificados que deben abordarse. Incluso en un sprint corto, esto puede suceder. Si el equipo de desarrollo tiene estas responsabilidades, durante la planificación del sprint, solo se asignan historias al sprint que permiten que haya suficiente espacio libre para estas otras actividades no planificadas y que se manejen según sea necesario. Si durante el sprint, no se encienden "incendios", entonces el tam puede atraer historias desde la parte superior de la acumulación. En muchos sentidos, se convierte en una cola.

La ventaja es que existe un compromiso con el retraso acumulado. La desventaja es que existe este agujero en la capacidad que se puede comunicar como una oportunidad para arrastrar al equipo a tareas no críticas. La velocidad también puede variar ampliamente si esa brecha en la capacidad se llena con el trabajo no planificado que tampoco se rastrea.

Una forma en que he conseguido parte de esto es crear una historia de "apoyo" que llene el resto de esa capacidad con una tarea que represente las horas disponibles que el equipo puede asignar para apoyar las actividades. A medida que las situaciones de soporte ingresan al sprint que no se puede aplazar hasta el retraso acumulado, se crea una nueva historia con tareas y la historia y tareas de soporte del marcador de posición se vuelven a estimar para dar cuenta de la nueva inyección. Si los incidentes de soporte no ingresan al sprint, esta historia de soporte se reduce a medida que ingresan los elementos atrasados para llenar la capacidad no utilizada.

El resultado es que los sprints retienen parte del flujo deseado y las personas sienten que no se van a quemar cuando necesitan realizar un trabajo de apoyo. Las velocidades son más consistentes, las burndowns rastrean normalmente, pero también hay un registro de las inyecciones de soporte que ocurren en cada sprint. Luego, durante la retrospectiva de sprint, podemos evaluar el trabajo planificado y no planificado, y si es necesario actuar de forma diferente en el siguiente sprint, podemos hacerlo. Si eso significa una nueva duración del sprint o una conversación puntual con alguien de la organización, entonces tenemos datos para respaldar las nuevas decisiones.