let alone deliver releasable software: El avance de los proyectos se mide por producto terminado.
Y reflexiono que, si en los dos proyectos (implantaciones de ERP) en los que estoy implicado ahora , midiéramos su grado de avance por ese criterio, sería para echarse a llorar.
En la metodología dominante de implantación de ERPs, o cualquier variante, es prácticamente imposible seguir ese criterio. En una implantación de un ERP pasan muchos meses hasta que el cliente ve algo útil... y eso es muy peligroso y frustrante, fuente de muchos fracasos.
Este es un tema que me gustaría desarrollar: cómo aplicar enfoques ágiles en los proyectos de implantaciones de ERP's.
¿Alguna idea?
PD. Por cierto, este es un ejemplo de libro de generación cruzada de ideas. Yo recojo una frase de un libro en mi blog que sugiere una reflexión a Joserra que a su vez me sugiere a mi otra. Y todo en horas. ¡Que grande que es Internet!
11 comentarios:
Bueno, no veo por qué no se puede...
Si bien es cierto que en una implantación de ERPs puede ser más defendible el hacer un análisis inicial en plan "tocho", por que una primera fase es analizar los procesos de negocio actuales, el desarrollo posterior puede ser ágil.
Precisamente, en el grupo de lean-agile-scrum, en el mismo mensaje que comentaba en mi post, Mary Popendick dice lo siguiente:
Lean software development certainly works in this environment [la pregunta es si conocen usos de Scrum/Agil en ERPs] – I have seen several examples. But lean is all about applying principles to your world in a way that makes sense. Scrum probably won't work that well, if you take Scrum as a recipe that has to be followed. In particular, you have to make sure that the development team and business process team are - how can I put this - one team. Software should not be separated from the business process in this case, it should serve it. Thus the iteration approach should occur at the business process level, not the software level.
Hola Joserra, no si no digo que no se pueda pero es complicado si no rompemos algún esquema que otro.
Lo de "the iteration approach should occur at the business process level, not the software level" da una pista.
A ver si me pongo y desarrollo el tema. Otra cosa es ver como lo "vendo"
Venderlo es más sencillo que implementarlo :)
¿por qué no ofrecer una parte del sistema cada mes, en vez de todo al completo dentro de seis? Pero atención, ojo al factor "incremental"... no se trata de ahcer una parte, luego otra, y otra,... si no de construir el sistema entero incrementalmente, que crezca de manera conjunta todas las partes.
Ese es el gran problema Joserra. Es muy complicado hacer ese particionamiento para que la entrega sea gradual. Un ERP parta de la base de que todo está integrado por lo que "todo" tiene que llevar un grado de avance homogéneo.
Para mi la clave está en la refactorización y el testeo automático. En cada iteración forzosamente modifico código y estructuras de iteraciones anteriores. El diseño y el código deben estar preparados para resistir eso, sino el spagetti resultante es terrible.
Y segundo, cada refactorización me lleva a un testeo de regresión para ver que no he roto nada. Si ese testeo no está automatizado mi productividad tiende a cero.
Disclaimer: Nunca he usado este método para un ERP, sólo para sistemas embebidos. Os leo con interés para aprender si el método es aplicable a este campo.
Es una asunto complicado, pero necesario sobre todo cuando el cobro del proyecto está diseñado por hitos a los que hay que dar un peso.
Creo que una buena técnica puede ser hacer el WBS http://en.wikipedia.org/wiki/Work_breakdown_structure antes de arrancar el proyecto y compartirlo e incluso mejorarlo con las aportaciones del cliente.
El ejercicio anterior también puede contribuir a la hora de valorar el impacto sobre el total del proyecto de las funcionalidades que puedan dejar de hacerse y las que puedan incluirse. Por lo tanto puede ser una buena herramienta de comunincación con el cliente.
Pero seguro que hay otras técnicas más próximas a metodologías ágiles que pueden ser interesants.
El grado de avance homogeneo es casi un prerrequisito de hacer desarrollo incremental. Por que hacer incremental no significa hacer por fases, si no ir haciendo el "todo" dándole cada vez más funcional.
La verdad que a veces es dificil ciertamente... pero si lo consigues, creo que aportas un valor al cliente realmente importante.
Hay consenso:
1. Sería cojonudo
2. Compaginar incremental y homogéneo es la clave
pero...¿CÓMO? ;-)
¿cómo?
* Priorizando las funcionalidades en su globalidad dentro del proyecto
* Suele ser util el concepto de "Minium Marketable Feature".
* Hay que romper el esquema de partes de una aplicación, ver las relaciones entre ellas, y observar cuales son las que realmente no se pueden separar.
En fin, supongo que eso es como no decir nada, pero por filosofar un poco ;)
@joserra
bueno, bueno es un buen principio. Solo una matización general: habría que hablar de procesos más que de aplicaciones
Ya habéis llegado, pero refuerzo la idea de que lo que se puede modular son los procesos.
Esto permite,además de tener resultados parciales elegir los procesos más críticos o más ineficientes...
El problema es que hay un precio el modular: el coste de las interfaces con procesos relacionados con el que se implanta con el nuevo sistema.
Hay que decidir entonces entre modularidad y coste?
Publicar un comentario