Defectos de Scrum (II)

En un reciente post hablaba de defectos de Scrum. Con este título, yo pretendía destacar los riesgos habituales en proyectos que por el motivo que sean, no encajan con las premisas de estas metodologías.

Vamos a ver a continuación una segunda parte con nuevos supuestos o problemas que presenta la implantación de una metodología como SCRUM, y que tendremos que considerar a la hora de implantarla.

1. En estas metodologías hay entregas frecuentes y estables, lo que supone probar y estabilizar un producto con un número mínimo de funcionalidades. Por desgracia, a pesar de que las metodologías ágiles se presentan como preparadas para el cambio, tienen el mismo problema que las metodologías tradicionales: las funcionalidades de una iteración pueden cambiar en la siguiente. Al final, una iteración es como un mini proyecto: tiene desarrollo, pruebas, un esfuerzo de integración con la funcionalidad existente, y despliegue. Por mucha involucración que queramos tener del usuario, nada impide que las funcionalidades cambien. Si pensáramos eso, entonces ¿porqué cambian en las metodologías tradicionales? ¿Es que allí el usuario nos ignora, no se involucra, va en contra de sí mismo? ¿Es que los analistas de las metodologías tradicionales son unos inútiles, y los de las ágiles unos hachas?
2. Presupone que no es necesaria la férrea gestión de recursos de otras metodologías “clásicas”. El problema está en cómo coordinar pues los desarrollos con la presencia de personal de sistemas, DBA’s, disponibilidad de recursos hardware, etc… El problema es que estas metodologías ágiles se venden desde el punto de vista del programador. Es el cliente el que debe sopesar si necesita o no un manual, una documentación exhaustiva, un seguimiento del proyecto, un control de costes y gastos...no el equipo.
3. Esta metodología no parece estar pensada para equipos de desarrollo dispersos en el espacio o en el tiempo. SCRUM presupone reuniones diarias cortas y presenciales. Presupone una colaboración de los equipos muy integrada. Eso no quiere decir que no se pueda trabajar en remoto. Simplemente, que en el segundo caso, puede haber dificultades adicionales que en pequeños equipos cercanos, no existen.
4. Se habla de que existe incompatibilidad o contradicción entre el uso de metodologías ágiles y que la empresa esté certificada CMMi. (Actualmente, con CMMi en su versión 1.3, esto ya no es cierto). Por desgracia, existen muchas administraciones públicas nacionales e internacionales que exigen a sus proveedores la certificación CMMi (entre otras). El Manifiesto Ágil en que se basan estas metodologías ágiles, habla de valorar más el individuo y el código frente a documentación (por ejemplo). Pero esto no quiere decir, que haya que hacerse lo que quiera el equipo, sino que ante la falta de otras directrices (es decir, si nadie pide documentación), se de mas importancia al código.
5. Los concursos públicos y muchos clientes privados exigen la certificación CMMi de la empresa, pero es raro que un cliente exija una certificación en metodologías ágiles (que por otro lado no existe tal, sino que es la persona quien se certifica ScrumMaster o equivalente). Esto es un problema para las metodologías ágiles, que chocan ante la falta de un auténtico certificado de empresa. La gente va y viene, pero es la empresa la que necesita ganar proyectos.
6. La falta de documentación detallada es un grave problemas en clientes de sectores legal, financiero, público,… y en general en proyectos grandes que requieran posterior mantenimiento, o en los que simplemente el cliente exige la documentación como parte del contrato.
7. En general, los métodos ágiles promueven la iniciativa e independencia del desarrollador (propietario del bloque funcional que está desarrollando), lo que puede derivar en que se implementen funcionalidades asociadas o paralelas NO SOLICITADAS, que terminen retrasando y complicando el desarrollo.
8. También existen problemas en la implantación de grandes clientes en los que varios proveedores interactúen. En estos casos, es muy importante definir documentación que permita la integración entre proveedores, tema que las metodologías ágiles (puras) suelen dificultar.

Con las que ya había en el anterior post, parece que hay muchas, y así es. ¿Estoy queriendo decir que SCRUM y en general las metodologías ágiles son problemáticas o difíciles de implantar? ¿O ineficaces? Pues no. Problemas hay en todas partes. Lo que no puede ser es que como veo constantemente en la red, vanagloriemos a las metodologías ágiles como el mantra que nos va a salvar del desastre en que nos han dejado las metodologías tradicionales. Hay que tener en cuenta las limitaciones de dichas metodologías, y saber adaptarlas a los proyectos. Si caemos en el purismo  y tratamos de implantar las metodologías por ellas mismas, estaremos perdiendo de vista los objetivos de los proyectos.

Este post no deja de ser una visión general de riesgos como en cualquier otro proyecto, pero esta vez desde el punto de vista de la metodología.