sábado, 3 de diciembre de 2011

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.

6 comentarios:

  1. Hola Roberto,

    No coincido con su apreciación respecto al numeral 7 ya que precisamente para eso se define el sprint backlog, las historias de usuario y se hace retroalimentación temprana y directa con el usuario (sprint review), con el objetivo de no caer en lo que afirmas.

    ResponderEliminar
    Respuestas
    1. Gracias por leerme y comentar, John. Es correcto lo que comentas, pero eso no termina de evitar el riesgo que comento. He visto en demasiadas ocasiones que se cuelan funcionalidades "por probar una tecnología", o por "ver si funciona". Prueba de ello lo tienes en los huevos de pascua, funcionalidades que no suele solicitar el product owner/usuario. Y de esto no se libran los proyectos ágiles. Las técnicas ágiles que comentas, serán efectivas si el usuario se entera a tiempo de la funcionalidad "que le han colado".

      Eliminar
  2. Estimado las metodologías ágiles no pretenden ser el mantra que Ud. señala, surgen como una alternativa para desarrollar software, y como alternativa igual existen proyectos de software que se han de adaptar mejor a las metodologías tradicionales y otras a las ágiles. respecto a la documentación claro que es importante y se documenta lo preciso o necesario pero más importante es entregar módulos de software que funcione que solucione los problemas de alguien. Por otro lado nunca escuché de incompatibilidades entre SCRUM y CMMI puesto que son totalmente diferentes mientras CMMI mide la madurez de los procesos dentro de las organizaciones, SCRUM pues es un marco de trabajo para el desarrollo de proyectos de software. De ser cierto lo que UD. afirma explique por que el éxito de usar metodologías ágiles. a lo que va hoy en día el 60% de las empresas que desarrollan software han adoptado SCRUM en el desarrollo de sus proyectos(http://www.agile247.pl/wp-content/uploads/2016/04/VersionOne-10th-Annual-State-of-Agile-Report.pdf). Usar SCRUM no es desarrollar al libre alvedrio como "presupone" Ud. Las metodologías ágiles no "presuponen" nada en lo absoluto se basan sobre realidades concretas plasmadas en los requerimientos a través de las historias de usuarios y así pasaría refutando lo que en su blog comenta y veo que tiene una idea errada de lo que son las metodologías ágiles.

    ResponderEliminar
    Respuestas
    1. Hola Leotrux. Gracias por leerme y aportar. Sin ánimo de convercerte, porque no se trata de convencer a nadie te comento:
      1.Las metodologías ágiles como tales no son un mantra, pero sí lo convierten en tal los talibanes del agilismo por un lado, y los vendedores de motos que con tal de vender lo que sea, ahora se ponen a vender el agilismo porque está de moda.

      2.Sobre la documentación, es algo ya superado. Pero en sus inicios (hablo de años 1998 a 2005), nos vendían el agilismo como el fin de la documentación. Con los años, esta corriente de pensamiento parece haberse visto superada en número por los que aceptan una documentación mínima.

      3.Si no has escuchado incompatibilidades de CMMi y SCRUM...basta con que busques "CMMi vs SCRUM" en cualquier buscador, o que sigas los apasionados foros, o incluso en LinkedIn se han librado apasionadas discusiones. Efectivamente, hace ya años que se acepta su compatibilidad, hecho que ya comento en el artículo.

      4.Sobre la adopción de SCRUM...el tiempo ha demostrado que dicha adopción no ha sido suficiente para mejorar realmente la efectividad de los proyectos a nivel global. Pero eso no significa que sea un enfoque incorrecto, sino que no es una panacea (silver bullet en inglés). De hecho, hace ya tiempo que se habla de la muerte de SCRUM (SCRUM is Dead), pero ya comentaba en otro artículo que no deja de ser otra moda. Piensa que hay gente que vive de venderte su metodología, si todos la venden...ellos ya no ganan dinero.

      5. Efectivamente, SCRUM y cualquier metodología ágil, no implican necesariamente descontrol, pero simplemente tienen riesgos derivados de unos menores y menos rígidos instrumentos de control y seguimiento. Hace tiempo que se ha visto la necesidad de corregirlo y adaptarse a proyectos grandes (donde el riesgo aumenta), y se han creado variantes como SAFe (Scaled Agile Framework). Pero esto ya es otra historia.

      6. Si repasas tu última frase, es exactamente lo mismo que afirmaban los defensores de las metodologías en cascada (se basan sobre realidades concretas basadas en los requisitos), y que han demostrado ser ineficaces como solución única.

      Cada día se va más a soluciones híbridas ágiles, donde se combinan varias metodologías, pero se incorporan prácticas ágiles, y por supuesto adaptadas a cada proyecto individual, como indico en el penúltimo párrafo.

      Eliminar
  3. Buen Post y buenas observaciones, en lo personal me quedo con lo que dice Roberto, porque a final de cuentas, uno se queda como Abelardo el de Plaza Sésamo...lleno de papelitos que no llevan a ningún lado y ni las famosas "historias de usuario" que vienen a sustituir los análisis funcionales que a mi parecer son mas efectivos. una simple opinión.

    ResponderEliminar
  4. Gracias por leerme y comentar. Sobre todo, hay que tener en cuenta que papelitos o no, lo fundamental es proporcionar suficiente información funcional para a su vez elaborar una implementación. Al final basta ver a tu equipo: si con tus directrices (historias de usuario, o requisitos funcionales tradicionales), no son capaces de implementar un software a través de un diseño, es muy posible que tengas que cambiar algo en esa información funcional.

    ResponderEliminar