Nuestro equipo tiene 1 BA, 3 desarrolladores y 1 QA. Estamos tratando de seguir SCRUMtanto como sea posible y, desde hace poco, el término Risk managementno formaba parte de nuestro diccionario.
Sin embargo, en los últimos meses, nuestro equipo tuvo que trabajar en una parte de nuestro producto que es muy antigua, la mayoría de las personas que lo implementaron ya no forman parte de la empresa y el dominio en sí es bastante frágil y, al mismo tiempo, complejo. , por lo que terminamos entregando continuamente código incorrecto en todos los sentidos de la palabra. Las pruebas también empeoran ya que el evaluador (teníamos 2, ahora es solo 1) aún no estaba familiarizado con esta parte de la aplicación y, junto con la gran cantidad de código incorrecto y la falta de experiencia, el resultado final fue un rendimiento deficiente. carrera tras carrera. A veces, terminamos las historias pero introducimos errores en el sistema, otras veces, no podemos terminar lo que nos hemos comprometido y, a veces, una combinación de ambos.
Como resultado, hubo una propuesta de nuestro gerente para tratar de adoptar la gestión de riesgos como parte de nuestro proceso de trabajo. Tal como está ahora, la idea es que no haya nadie personalmente responsable de los asuntos relacionados con la gestión de riesgos. Decidimos que por ahora esto debería ser obligación de cada miembro de nuestro equipo.
Lo que hicimos fue hacer una especie de lluvia de ideas e intentar encontrar tantos riesgos como podamos identificar y luego tratar de investigar cada riesgo individual y encontrar una solución para cada uno.
Aunque el enfoque anterior parece lo suficientemente bueno para algunos de los miembros de nuestro equipo (por ahora), personalmente no lo encuentro muy constructivo. Las últimas semanas o dos he leído muchos artículos sobre este tema. Sé que no puedo convertirme en un administrador de riesgos por 2 semanas y tomará mucho más que varios artículos obtener el conocimiento necesario, pero lo que veo es que hay personas que han llegado a las mismas conclusiones que yo y ahora yo Me gustaría profundizar aún más en los temas que me parecen más candentes para mi caso particular.
Así que directo al grano. Durante la lluvia de ideas pudimos identificar muchos "riesgos", pero al analizar los resultados llegué a la conclusión de que no son la causa principal del problema, sino solo indicadores de que algo anda mal. Hemos identificado muchos riesgos como "Implementar código con errores en vivo", "saltar pruebas", "Realizar pruebas que no cubren la funcionalidad completa", "Implementar funcionalidad parcialmente implementada", etc., pero para esos no son los riesgos reales, esos son solo los indicadores/síntomas de algo más general. Y no sé si en términos de gestión de riesgos es buena idea generalizar tanto las cosas, pero para mí existe un riesgo básico que es: "Entrega de un producto defectuoso" y muchos de los llamadosevent treespara darse cuenta de ese riesgo, donde la mayoría de los eventos se desencadenan por lo mismo: una falta de conocimiento en el equipo sobre esta parte del producto, y tal vez simplemente no hay suficiente experiencia en el desarrollo de software.
La razón para escribir esta pregunta es porque no sé hasta qué punto la gestión de riesgos debe lidiar con estos problemas y qué es solo, cómo decirlo... solo un problema de equipo. Desde mi perspectiva, es inútil centrarse en un riesgo como "Implementar un código con errores en vivo" si es obvio que el equipo todavía está luchando por familiarizarse con toda la complejidad del proyecto y todas las interacciones ocultas.
Lo que sucede es que cada vez que trato de exprimir más tiempo para cierta tarea porque sé por experiencia que ciertos tipos de tareas son históricamente difíciles y potencialmente esconden muchas complicaciones una vez que empiezas a trabajar en ellas, obtengo la respuesta de que Estoy basando mi solicitud en los temores y todo lo contrario: si hay algo que ya hemos hecho (aunque no es 1 a 1 lo mismo) y ya tuvimos que lidiar con parte del problema, entonces ahora deberíamos necesitar menos tiempo , y debería ser más fácil para el equipo esta vez. Debo admitir que esto suena bastante lógico y es difícil encontrar argumentos en contra, excepto la realidad de que, a pesar de toda lógica, la mayoría de las veces, aunque parezca que estamos chocando contra la misma pared, en realidad es almostla misma pared y estoalmostsuele llevar a que tengamos que invertir la misma cantidad de tiempo que la vez anterior y peor aún parece que no hemos aprendido la lección y repetimos viejos errores.
Bueno, es difícil para mí decidir cuánto se debe al hecho de que el equipo no puede aprender lo suficientemente rápido y cuánto del problema se debe al hecho de que dejamos lo mismo para golpearnos dos veces de la misma manera. .
He leído que la mejor manera de identificar los riesgos es la experiencia y los problemas que usted o el equipo tuvieron en el pasado. Esta frase me hace pensar que este caso no está completamente fuera del alcance de la teoría de la gestión de riesgos. Sin embargo, debo admitir que tener problemas no iguales, pero similares, más de una vez y no poder tratarlos de manera rápida y limpia también es un problema de experiencia, habilidades del equipo mismo. Pero en un sprint de 2 semanas es difícil encontrar un problema, aprender de él y en la tercera semana ser capaz de resolver rápidamente un problema similar. Es cuestión de aprender y aprender lleva tiempo.
Una cosa que encuentro casi inútil es perder el tiempo tratando de resolver los síntomas cuando, al menos para mí, la causa raíz es clara pero solo requiere más tiempo para superarla, como el problema de aprender y mejorar. Para mí es un riesgo tomar una historia en la que sabes por experiencia previa que puede haber complicaciones ocultas, pero no puedo encontrar muchos argumentos de por qué esto es un riesgo y no solo decir... incompetencia.
Lo que realmente me gustaría dejar claro para mí es qué parte de lo anterior puede considerarse como riesgo. Qué se debe tratar con las herramientas de gestión de riesgos (y cómo) y qué opina sobre las cosas que quedan fuera del alcance de la gestión de riesgos. Sé que este equipo es capaz, sé que a este equipo le falta experiencia y creo que será una gran pérdida de tiempo y esfuerzo si decidimos y vamos a resolver problemas que se parecen mucho más a síntomas que a una causa raíz y cómo lo hace. ¿Crees que tal problema debería ser manejado?
Uno de los beneficios de usar el marco Scrum es que reduce el riesgo .
¿Cómo lo hace? Bueno, el riesgo tiene que ver con las sorpresas. A menudo, eso significa pensar que harás X cantidad de trabajo, pero descubrirás que solo has hecho Y cantidad de trabajo.
Con Scrum, en lugar de adivinar lo que haremos, medimos el progreso real. Eso no es solo un progreso en la realización de tareas de desarrollo, sino un verdadero progreso en términos de completar la funcionalidad según un estándar establecido (una definición de hecho ).
Tomemos el ejemplo de su pregunta. El equipo está trabajando en un área del código con la que no están familiarizados y que no está bien construida. Esto claramente va a tener un impacto en la tasa de progreso del equipo.
El enfoque de Scrum sería acordar primero la definición de hecho. ¿Quizás el equipo buscará refactorizar cada componente con el que trabajan para lograr un estándar de calidad mínimo? ¿Quizás documentarán cualquier código no documentado? ¿Quizás harán más revisiones de código ya que el código es tan problemático?
Una vez que el equipo ha acordado la definición de hecho, comienzan a trabajar. En el primer sprint cronometrado , ven cuánto pueden hacer . Eso no incluye el trabajo que aún está en progreso o las tareas técnicas que por sí solas no generan ningún valor comercial. No, el verdadero progreso es cuánta funcionalidad es potencialmente entregable .
Al final del primer sprint, el equipo se sienta y calcula cuánto completó. Luego lo usan como guía para futuros sprints. Después de algunos sprints, el equipo tiene una idea realista de su capacidad. Esto les permite hacer una prueba de cuánto tiempo llevará hacer el trabajo en el futuro. Ahora bien, esto bien puede venir como un poco de un shock. A menudo, el uso de este enfoque revela que la capacidad del equipo no es tan grande como se imaginaba. Pero al menos el equipo ahora está siendo realista y, por lo tanto, ha reducido mucho el riesgo de sorpresas.
Scrum no se detiene ahí. No solo anima al equipo a ser realista al medir su capacidad, sino que también anima al equipo a pensar en formas de mejorar ("inspeccionar y adaptar"). Al revisar continuamente cómo van las cosas, es posible que el equipo pueda encontrar formas de mejorar su efectividad y, por lo tanto, mejorar su capacidad para trabajar.
Doing the right things is doing the things right. Sí, tienes 100% razón. Realmente aprecio tu respuesta.La mayor parte de lo que está buscando como riesgo, parece ser deficiencias en el proceso. (Un proceso deficiente es un riesgo y debe mitigarse). Identificar el riesgo y el costo de los diversos resultados del proceso deficiente puede ayudarlo a enfocar sus esfuerzos de mejora de procesos. Parece que el principal riesgo es la introducción de errores en la producción, y tiene una alta probabilidad.
Acciones como "saltar pruebas", "realizar pruebas que no cubren la funcionalidad completa", "implementar funcionalidad parcialmente implementada", etc., son factores que pueden o no conducir a "implementar código con errores en vivo". Revise cuáles de estos contribuyen o podrían mitigar los errores introducidos.
Dado que el código es antiguo, complejo y frágil, hay varios problemas de proceso que esperaría.
Es probable que el código no tenga pruebas unitarias automatizadas. Estos pueden contribuir en gran medida a mitigar los riesgos. Antes de modificar el código, los desarrolladores deben crear un conjunto razonable de pruebas unitarias para asegurarse de que sus cambios no rompan la funcionalidad existente. Los cambios también deben tener pruebas unitarias, para que el cambio pueda ser verificado.
Hacer que los desarrolladores revisen el código de los demás es otra técnica que a menudo descubre problemas. Es posible que desee probar otras técnicas, como la programación en pareja.
A menudo he trabajado en muchos sistemas en los que se lanzó una funcionalidad incompleta. Hay varios mecanismos para controlar si el código está activo. La nueva funcionalidad que depende de un nuevo valor de código a menudo se puede mantener inactiva al no introducir ese valor de código en producción. Otro código puede necesitar un mecanismo de cambio, para lo cual prefiero un indicador de desactivación. Los indicadores pueden agregar complejidad adicional, por lo que es posible que desee eliminarlos cuando el código esté completo.
"la teoría de la gestión de riesgos" - No existe una única teoría de gestión de riesgos. No estamos tan mal como algunas otras disciplinas donde parece haber más teorías que analistas, pero no es una sola teoría homogénea.
Dicho esto, tengo un par de observaciones que espero puedan ser útiles.
Observación general: la mayor parte del valor en la gestión de riesgos son las discusiones; si está analizando y discutiendo el riesgo, debería mejorar la comprensión y la capacidad de su equipo para gestionar el riesgo. Alguien bromeó una vez, "el objetivo de la planificación es la planificación, no el plan"; lo mismo es válido para la gestión de riesgos.
Parece que está avanzando por el camino hacia una gestión de riesgos más madura, pero insto a un cambio:
Lo que hicimos fue hacer una especie de lluvia de ideas e intentar encontrar tantos riesgos como podamos identificar y luego tratar de investigar cada riesgo individual y encontrar una solución para cada uno.
Le insto a que inserte un paso entre la lluvia de ideas y la búsqueda de soluciones. Sugeriría (a) agrupar los riesgos en categorías similares (lo que tiene el efecto secundario de mejorar la comprensión colectiva y calibrar el equipo) y/o (b) priorizar los riesgos. Esta puede ser una priorización "suave" con análisis cualitativo, o una priorización "dura" con calibración y cuantificación. Muchos equipos hacen ambas cosas; un primer paso en la priorización cualitativa y luego un paso más detallado en la priorización cuantitativa. (Hay amplios recursos en línea para discutir esto).
El punto es reservar el 90% de su tiempo y esfuerzo para la investigación del 10% de los riesgos.
Obtengo la respuesta de que estoy basando mi solicitud en los miedos y que todo lo contrario: si hay algo que ya hemos hecho (aunque no es 1 a 1 lo mismo) y ya tuvimos que lidiar con algunos de los problemas entonces ahora deberíamos necesitar menos tiempo, y esta vez debería ser más fácil para el equipo.
"basando mi solicitud en los miedos"... ¿Quizás algunos miembros del equipo no han aceptado la noción de gestión de riesgos? La gestión de riesgos es una gestión que tiene en cuenta la incertidumbre ("miedo" como palabra de una sílaba carece de la dignidad y seriedad de "incertidumbre"). Quienquiera que esté haciendo esta queja me recuerda la broma francesa: "Todo eso está muy bien en la práctica, pero ¿cómo funciona en la teoría?" Su análisis de riesgo ha generado datos que indican que esto está sucediendo. Ese "debería necesitar menos tiempo" no se traduce en "necesita menos tiempo". Te recomiendo que le des la vuelta al guión sobre quien haya pronunciado esta cita. Tiene evidencia de que las tareas repetidas no conducen a la eficiencia (yo d en realidad buscar formas de cuantificar esto y potencialmente desarrollarlo como un disparador de riesgo/métrica clave). Trabaje a partir de sus datos; haga que su adversario respalde sus afirmaciones con datos.
Mientras lo hace, tenga una discusión franca con esta persona sobre otra cita en su pregunta, "en gran parte se debe al hecho de que el equipo no puede aprender lo suficientemente rápido, y en qué parte del problema se debe al hecho que dejemos lo mismo para que nos golpee dos veces de la misma manera". Su equipo no está aprendiendo lo suficientemente rápido; están siendo golpeados por lo mismo repetidamente. Sospecho que cuando aprenda a manejar ese problema (un cierto riesgo es un problema), entonces resolverá un gran grupo de su riesgo asociado/consecuente. Comprender por qué ocurre este problema es la verdadera razón para practicar la gestión de riesgos: adelantarse a la curva y responder a esto mientras todavía es un riesgo y antes de que se convierta en un problema. (que también es la respuesta al desafío del "miedo").
Hemos identificado muchos riesgos como "Implementar código con errores en vivo", "saltar pruebas", "Realizar pruebas que no cubren la funcionalidad completa", "Implementar funcionalidad parcialmente implementada"
Estos son buenos; podrían ser mejores. Personalmente, encuentro que expreso los riesgos más claramente si los enuncio de manera consistente. "Dada la condición previa si el evento entonces la consecuencia ": no tengo una idea completa de los ejemplos que cita, pero podrían ser:
Dada la presión para entregar a tiempo, si desplegamos código con errores activos , entonces . . . "(No estoy del todo seguro de cuáles son las consecuencias del código con errores, pero probablemente sean un aumento en la deuda técnica/trabajo adicional a la cartera de pedidos, pérdida de clientes, etc. Las consecuencias generalmente deberían ser algo que se pueda expresar a una abuela /accionista en 30 palabras o menos
" Dado ??? Si las pruebas no cubren la funcionalidad completa, entonces ??? No estoy seguro de por qué ocurriría esto: ¿cuál es la consecuencia para el cliente/usuario final/negocio de las pruebas parciales? (Estoy completa y vehementemente de acuerdo en que las pruebas parciales son menos que ideales, pero ¿cuál es el impacto en su sprint, su capacidad para entregar valor? Como mínimo, diría que es más una deuda técnica, pero creo que cuanto más exactamente pueda expresar esto, más fácil será. será decidir cuánto esfuerzo dedicar a resolverlo .puede no ser importante aquí, o puede ser la parte crítica. Si el problema fundamental es que su equipo de scrum carece de profundidad en los procedimientos de control de calidad, que los desarrolladores no están escribiendo pruebas exhaustivas (o peor aún, están escribiendo pruebas que no prueban los comportamientos esenciales), entonces sabe cómo mitigar este riesgo: y sabe cómo medir su éxito en la mitigación del riesgo, y sabe cómo presentar un caso convincente a la gerencia. "Si podemos capacitar a dos desarrolladores en control de calidad mejorado, nuestra cobertura de prueba aumentará del X %, lo que reducirá la cantidad de errores en el código implementado en un Y %, lo que nos permitirá transferir recursos de la deuda técnica al nuevo desarrollo. será como contratar a un nuevo desarrollador ". (los dos desarrolladores son desarrolladores de scrum, por lo que se espera que entrenen al equipo).
Resumen: creo que lo acertó con: "Creo que será una gran pérdida de tiempo y esfuerzo si decidimos y vamos a resolver problemas que se parecen mucho más a síntomas que a una causa raíz y cómo cree que debería ser ese problema ¿manejado?" - ¡Correcto! Espero que las sugerencias anteriores lo ayuden a llegar desde donde está hasta esa oración final bien redactada.
yegor256