metodología ágil

Introducción

Si hablas con desarrolladores o gerentes en tu red, la mayor√≠a de ellos te dir√°n que sus equipos est√°n usando la Metodolog√≠a √Āgil.¬†

La mayor√≠a de las ofertas de trabajo que ver√°s tendr√°n el t√©rmino Proceso √°gil mencionado en alguna parte de su descripci√≥n de trabajo. 

As√≠ que creo que es justo decir que el t√©rmino Proceso √°gil est√° de moda hoy en d√≠a en la industria del software, y usar Proceso √°gil en tu equipo es tan bueno como usar IA/ML en tu c√≥digo. 

Si tu respuesta es s√≠, entonces ah√≠ es donde comienza el problema. Cuando algo es genial, la gente quiere adoptarlo lo m√°s r√°pido posible. Como sabemos, muchas empresas que afirman que est√°n usando algoritmos geniales de ML/AI en su c√≥digo solo est√°n usando declaraciones if-else en segundo plano. Lo mismo est√° sucediendo con Agile tambi√©n. De todos los equipos que afirman seguir el proceso Agile est√°n lo suficientemente lejos del proceso y simplemente atrapados en un lugar donde no obtienen ninguna ventaja de Agile.

Requisito previo

Este art√≠culo es √ļtil para ti si comprendes la Metodolog√≠a √°gil y tu equipo ya est√° utilizando Procesos √°giles.

Razones por las que el proceso ágil podría no estar dándote los resultados esperados

metodología ágil

Analicemos algunos errores que cometen las empresas y los equipos al seguir la Metodolog√≠a √°gil. Si tu respuesta a cualquiera de las siguientes preguntas es s√≠, entonces es el momento en que necesitas trabajar para mejorar el proceso √°gil que se sigue en tu equipo.

¬ŅEst√°s saltando al paso de implementaci√≥n sin darle mucha importancia a las fases de SDLC antes de eso?

metodología ágil

Tener peque√Īas iteraciones y lanzar cambios a los clientes es uno de los puntos clave de Agile. Esto proporciona un gran beneficio de la retroalimentaci√≥n r√°pida de los clientes, de modo que, si hay alguna brecha entre la expectativa y el resultado, se puede identificar en una etapa temprana. 

Sin embargo, a veces los equipos malinterpretan esto y piensan que, dado que tienen la influencia para obtener comentarios r√°pidamente, deber√≠an comenzar a trabajar en la implementaci√≥n sin poner mucho esfuerzo en las fases de recopilaci√≥n, an√°lisis y dise√Īo de requisitos.

Esto resulta en un desastre cuando con el tiempo el proyecto se vuelve inmanejable y nadie tiene una idea de lo que hay que hacer, cu√°nto trabajo queda pendiente y cu√°nto se ha completado.

¬ŅQu√© puede salir mal al seguir la metodolog√≠a √°gil en 2022? 1
Descarga la Guía de Design Thinking 2022 gratis

Sugerencias para mejorar:

La regla SDLC para Agile es:

  • Una √Čpica debe tener un documento de requisitos claramente definido,
  • A excepci√≥n de Spike y POC, todas las dem√°s historias de usuario deben estar respaldadas por un documento de dise√Īo.
  • El DOD de las historias de usuarios debe lograr claramente uno u otro objetivo de un documento de dise√Īo o un documento de requisitos.

¬ŅDecide el responsable de las tareas y los puntos de la historia de esa tarea?

metodología ágil

Aunque puede parecer algo muy peque√Īo, no estandarizar los puntos de la historia puede afectar no solo los plazos de entrega de tu proyecto, sino que tambi√©n puede da√Īar la cultura de trabajo de tu equipo hasta la m√©dula.

Muchos equipos creen que el propietario de la tarea conoce los esfuerzos necesarios para completar la tarea, por lo que es la persona adecuada para asignar puntos de historia a la tarea. Aunque esto parece correcto a primera vista, tambi√©n causa problemas. Entendamos esto con algunos de ellos.

  • Como los puntos de la historia asignados por una persona no funcionar√≠an para otra, tales asignaciones crear√≠an un alto acoplamiento entre la tarea y el asignador del punto.
  • Puede haber escenarios en los que la persona A puede realizar una tarea en un d√≠a, pero la persona B necesitar√≠a 5 d√≠as para completar esa tarea. Entonces, el desempe√Īo de la persona A es 5 veces mayor que el de la persona B. Pero si ambos tienen la libertad de asignar puntos de historia para la tarea que est√°n haciendo, entonces la persona B asignar√° 5 veces m√°s puntos de historia que la persona A, y si no se realiza un escrutinio, nunca podr√° encontrar la diferencia de desempe√Īo entre la persona A y B.
  • La finalizaci√≥n del proyecto depender√≠a demasiado de qui√©n est√° manejando el proyecto que cu√°l es la complejidad del proyecto.

Sugerencias para mejorar:

  • La asignaci√≥n de puntos de historia no es una tarea individual. Es una actividad de grupo.
  • La mejor manera es involucrar a todo el equipo (o al menos a los miembros clave del equipo) y pedirles que proporcionen la estimaci√≥n puntual.
  • Despu√©s de obtener los puntos estimados, un equipo puede optar por tomar el m√°ximo, el m√≠nimo o el promedio de todas las estimaciones.

¬ŅCrees que monitorear de cerca la creaci√≥n y el cierre de historias/tareas es una p√©rdida de tiempo?

metodología ágil

Si los product owner y los gerentes de ingenier√≠a no est√°n monitoreando las nuevas tareas agregadas a √Čpicas, entonces puede conducir al caos y al progreso sin direcci√≥n de √Čpica. Si las historias no tienen una definici√≥n adecuada de hecho (DOD), entonces contribuir√°n solo a ocultar la ineficiencia del equipo. 

Comprendamos las razones por las que debe tener un seguimiento en la creación y cierre de historias.

  • No todos en el equipo tendr√≠an el mismo nivel de comprensi√≥n de √Čpica y las historias no analizadas pueden no tener el contexto correcto, la conexi√≥n con otras historias y una definici√≥n significativa de hecho. Tales historias no contribuir√≠an m√°s que a la confusi√≥n en el momento de la preparaci√≥n del retraso en la evaluaci√≥n del estado de √Čpica.
  • Si varias personas est√°n creando las historias en una epopeya sin coordinaci√≥n, existe la posibilidad de que las historias se creen con DOD duplicados o superpuestos. Esto resultar√° en esfuerzos duplicados por parte de los miembros del equipo.
  • Aunque en un mundo ideal creemos en las mejores intenciones y pensamos que todos quieren trabajar para el √©xito del equipo y del proyecto, aceptemos esto con una pizca de sal de que no todos en su equipo estar√≠an igualmente motivados. No es raro encontrar historias creadas intencionalmente que no tienen DOD claro o DOD duplicado. Tales historias se usar√≠an para marcar los esfuerzos en un sprint sin poner mucho esfuerzo en ellos.

Sugerencias para mejorar:

  • Todas las historias que se crean y cierran deben ser revisadas por el gerente de ingenier√≠a o el propietario del producto del equipo.

¬ŅCrees que las retrospectivas de Sprint son innecesarias?

metodología ágil

Las reuniones retrospectivas son importantes para el proceso Agile como lo son los chequeos de salud para nosotros. Estos son como chequeos de salud. Si va a someterse a chequeos médicos regulares, podrá identificar comportamientos anormales en el cuerpo en una etapa muy temprana y vivir una vida saludable. Del mismo modo, si su equipo se toma en serio las reuniones retrospectivas, podrá encontrar cualquier anomalía en el proceso ágil en una etapa temprana.

Recibe mi Newsletter semanal
Recibir√°s un email semanal (los domingos por la ma√Īana) con el mejor contenido que vaya encontrado por la red.


Yo también odio el spam solo contenido de valor a través de mi newsletter

Si la respuesta a cualquiera de las siguientes preguntas es afirmativa, puede considerar que no est√° utilizando estas reuniones de manera eficiente:

  • Si alguna historia no se completa en un sprint, entonces, en lugar de discutir las razones en detalle, ¬Ņsu equipo simplemente pasa eso al siguiente sprint o en la cartera de pedidos?
  • Si DOD no se completa para ninguna historia, ¬Ņsimplemente cierra esa historia para marcar los esfuerzos y abre una historia duplicada para el pr√≥ximo sprint?
  • ¬ŅNo revisa cada historia y compara los puntos asignados a las historias y el esfuerzo real invertido en las historias?

Sugerencias para mejorar:

Los siguientes puntos tienen que ser cubiertos en las reuniones retrospectivas.

  • Analice cu√°ntas historias requirieron m√°s o menos esfuerzo que el esfuerzo estimado y por qu√© sucedi√≥ eso. Esto ayuda a corregir las estimaciones de esfuerzo en futuros sprints.
  • Si hay historias incompletas, analice la raz√≥n detr√°s de eso. Por ejemplo, los retrasos debidos a otros equipos, el DOD poco claro y los cambios desconocidos surgen durante la implementaci√≥n de los cambios. Esto ayuda a identificar qu√© fase anterior (recopilaci√≥n de requisitos, dise√Īo, etc.) necesita mejoras.
  • Si hay historias en las que se ha puesto algo de esfuerzo, pero la historia a√ļn no se ha completado, cambie el DOD y cree otro ticket con un DOD incompleto. Esta acci√≥n deber√≠a haberse tomado solo despu√©s de recibir el aviso de los miembros del equipo, incluidos el Gerente de ingenier√≠a y el Propietario del producto.

Conclusión

He tratado de cubrir las razones principales por las que seguir Metodolog√≠a √Āgil resulta en una disminuci√≥n de la eficiencia del equipo y brind√© sugerencias para mejorarlas. 

Si su equipo no est√° cometiendo ninguno de estos errores, felicidades, est√° utilizando el proceso √°gil de la manera en que se espera que se utilice. Si hay alg√ļn punto que cree que su equipo no est√° siguiendo, intente seguir las sugerencias proporcionadas para mejorar en esa √°rea. Estoy seguro de que te encantar√°n los resultados.

Es cierto que¬†crear un buen¬†dise√Īo UX¬†puede ser desafiante y confuso en un principio, pero para eso estamos, para¬†ayudar. Contacta hoy para programar tu¬†sesi√≥n de estrategia¬†y dejar que comience la lluvia de ideas.

Recibe mi Newsletter semanal
Recibir√°s un email semanal (los domingos por la ma√Īana) con el mejor contenido que vaya encontrado por la red.


Yo también odio el spam solo contenido de valor a través de mi newsletter

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Descarga la Guía de Design Thinking gratis

X
Ir arriba