20 fallos comunes en desarrollo de proyectos ágiles de DWBI


Por:

1. Implementar las historias de usuario sin criterio ni orden

Las historias de usuario (denominadas por Lawrence Corr como Data Stories) han de proporcionar el mayor valor para el cliente. Por tanto el Product Owner, en representación de los intereses de la empresa, deberá mantener la pila de trabajo (Product Backlog) ordenada según el valor para el cliente y el equipo deberá respetar este orden en la implementación.

 

2. Equipo demasiado especializado

Los equipos Scrum han de ser multifuncionales. Ya lo adelantaba Kimball, en consonancia con la filosofía de los equipos Scrum: “Los proyectos DW / BI requieren la integración de un equipo multifuncional con recursos sobre negocios e IT. Es común que la misma persona acapare múltiples roles en el equipo, la asignación de los recursos nombrados a los roles depende de la magnitud y alcance del proyecto, así como de la disponibilidad, capacidad y experiencia del individuo” (“The Data WarehouseToolkit”. Ralph Kimball)

 

3. Aplicar la metodología ágil a algunas partes o fases del proyecto

Por ejemplo, se itera solo en la parte de desarrollo, y las demás fases son realizadas conforme a la tradicional metodología en cascada (waterfall). La entrega de valor al cliente, con sus fallos y aciertos, tiene lugar al final del proyecto, eliminando las principales ventajas y mejoras del marco de trabajo ágil.

 

4. Carencias formativas en metodologías ágiles o Scrum

He observado como una práctica errónea común, equipos intentando funcionar conforme al marco ágil sin un líder convenientemente formado. Los equipos han adoptado una forma de trabajar de manera ágil, mediante la selección de uno de los miembros del equipo técnico para ejercer de líder. En lo relativo a conocimientos, el líder ágil debe estar más cerca del lado ágil que del lado técnico del proyecto.

 

5. Modelar todo el sistema a la vez

Esto no cumple con la filosofía ágil de realizar pequeñas entregas iterativas.

 

6. No disponer de un Product Owner

Sin esta figura, nadie revisa la prioridad en los desarrollos (historias de usuario), ni la utilidad de las entregas, ni aporta feedback. El PO realiza misiones cruciales para el éxito del proyecto: mantener la pila de trabajo (Product Backlog) ordenada por valor o prioridad para el cliente. De igual forma, esta figura es quien acepta las entregas conforme a los criterios de aceptación (Acceptance Criteria). La falta de este perfil provoca carencias en los proyectos ágiles: en tanto que ni se maximiza el valor entregado, que, además,  puede no responder a las necesidades del cliente, y bajo los parámetros que lo necesita.

 

7. Implantar y no adaptar

Para los proyectos o equipos en marcha, la transformación a ágil ha de ser realizada de manera paulatina, controlada y con la bienvenida del equipo. En la filosofía de trabajo ágil, cualquier forma de implantación agresiva no funciona.

 

8. No descomponer las historias de usuario en tareas

Las tareas son una unidad básica y esencial de trabajo en las metodologías ágiles. Son la herramienta de organización del equipo (mediante Tableros Kanban) y de la medida del desarrollo y éxito del proyecto.

 

9. Realizar una demo del sprint al líder ágil del proyecto

Y sin la presencia de los interesados (stakeholders) o sin el Product Owner como su representante. El líder ágil de proyecto no es jefe, es un facilitador que trabaja junto con el equipo, para aportar valor temprano al cliente que, personalmente o representado por el Product Owner, debe asistir a las demostraciones del Sprint.

 

10. No realizar las retrospectivas

He visto usar esta reunión como tiempo comodín para completar desarrollos, o bien, llevarla a cabo solo si sobra tiempo. Es un error. Las reuniones de retrospectivas conforman unas de las reuniones más importantes y son sustento de la mejora continua de los proyectos ágiles.

 

11. Reuniones de retrospectivas mal hechas

La clave de estas reuniones es la participación y colaboración de todo el equipo, disponer de herramientas de evaluación y disponer de un plan de mejora junto con un responsable de este.

 

12. Documentación incompleta

El principio “software funcionando sobre documentación exhaustiva”, no quiere decir que no exista la documentación y que esta sea liviana o incompleta. Es vital para los proyectos DWBI mantener la información de repositorio, y todos los modelos completos y perfectamente registrados.

 

13. Longitud de iteración demasiados larga

Debido a la extrema complejidad que presentan los proyectos DWBI, los equipos estiman conveniente (es una corriente frecuente) realizar iteraciones (Sprints) con longitudes demasiado largas. Lo recomendado para proyectos de desarrollo IT, es entre 2 y 4 semanas, siendo lo más extendido un plazo de 2 semanas. Para los proyectos de DWBI podría ampliarse la longitud a 3 o 4 semanas, pero no mes y medio o dos meses. ¿Por qué? Las longitudes tan largas, rompen muchos de los beneficios de los marcos de trabajo ágiles. La entrega del valor se realiza demasiado tarde, así como las revisiones de progreso,y la opinión y feedback del cliente llega demasiado tarde, y todo ello dispara los riesgos del proyecto.

14. No medir

Me he encontrado con dos casos. El que no tiene implantadas las herramientas de medición y visualización adecuadas, y las que teniéndolas, no le prestan más atención que para actualizarlas. Error. Lo que no se mide no se puede gestionar ni mejorar. Yo recomiendo ampliar las herramientas recomendadas como indispensables (tableros Kanban, Burdown Chart..) para el control por las metodologías ágiles. En mi experiencia, he configurado como herramienta de control adicional, un sistema de medición y control para proyectos ágiles y que se compone de un Cuadro de Mando Integral (CMI), además de un sistema de DWBI para procesos ágiles. Gracias a él, se logró mejorar parámetros tan importantes para el proceso ágil, como mejora de la velocidad del equipo, la satisfacción de cliente o la satisfacción del equipo,así como reducir el número de historias no aceptadas.

 

15. Historias de usuario con dependencias

Las historias de usuario han de ser SMART e INVEST. La I de INVEST quiere decir Independientes. Las dependencias entre historias producen un caos tremendo en la creación de tareas y en auto-organización del equipo entre otros. Este problema se genera en la fase de planificación de la entrega (Release Planning) debido a una mala definición y organización de las historias. La herramienta de Mapa de Proceso (Process Map), puede ayudarnos a mitigar este problema.

 

16. Trabajar sobre los Procesos de Negocio

En ese nivel de detalle trabajamos sobre modelados completos, que conllevan una entrega completa, tardía y ciega, al final del desarrollo completo.

 

17. Historias de usuario no expresadas correctamente

Si nos atenemos a la definición y esquema de las historias de usuario recomendadas por el marco ágil, estas han de recoger 3 W: quién, qué y por qué (Who, What and Why) y expresadas en el formato:

Yo como <analista en el departamento de facturación>

Quiero usar el <panel de control de ingresos para mostrar tendencias de ingresos mensuales facturados por producto, mercado geográfico y tenencia de clientes>

Para que podamos <detectar y corregir las áreas en las que nuestra aplicación de cumplimiento no transfiere las instalaciones del cliente a Nuestros sistemas de facturación, dejando sin cobrar los ingresos devengados>

(Ejemplo obtenido y traducido de “Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum”. Ralph Hughes)

 

18. Errores en la granularidad y nivel de detalle de temas, épicas o historias de usuario

Es de vital importancia que el equipo llegue a un acuerdo con respecto a este punto y lo utilice de manera homogénea y estándar a lo largo de todo el proyecto.

 

19. Ejecución de las etapas iterativas

Es lo que algunos practicantes ágiles denominamos Scrumfall (Scrum+Waterfall). Es una extraña forma de enmascarar un desarrollo en cascada, y volvemos al mismo error: no se entrega valor ni se obtiene feedback hasta el final.

 

20. Equipos no escalados, o de tamaño demasiado grande

El tamaño del equipo no es algo trivial ni fijo, y además, depende de muchos factores complejos. He visto crecer y crecer equipos hasta llegar a un volumen inmanejable. El practicante ágil debe estar alerta a este punto, y ayudar y asesorar al equipo, para determinar el tamaño adecuado del equipo así como la necesidad de escalarlo a Scrum de Scrum.

 

Conclusión:

Scrum tiene sus pros y contras, y es más adecuado para determinados proyectos, que para otros. Ahora, una vez que se opta por las metodologías ágiles, mejor lo hacemos bien, ¿no?


Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/12/d438374558/htdocs/lscrumblog/wordpress/wp-includes/class-wp-comment-query.php on line 399

Deja un comentario

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