Metodología Gestión/Desarrollo ideal

No hay metodología perfecta o única ni cualquier trabajo se resuelve con la misma metodología de la misma forma. Cada vez escucho más que todo debe ser ágil, que si no trabajas con metodología ágil no realizaras nunca un proyecto de forma correcta y que lo ágil es el único camino.

Bueno, seguro que este Post llevara bastante controversia y muchos de mis compañeros, amigos me dirán que como puedo decir estas cosas, no obstante la experiencia vivida hasta el momento es lo que me dice.

Empezaré diciendo algo que sonará muy fuerte, “La metodología Ágil no sirve para todo tipo de proyectos”. Y para no quedarme con una simple frase ahí va lo que a mi entender debe hacer una empresa para saber que metodología usar.

Primero un repaso a las metodologías:

Clásica:

Ahora se llama clásica a lo que se hacía antes pero nos equivocamos en este punto ya que antes había varios tipos de metodología de desarrollo.

Métrica: Es una metodología para la realización de una planificación, desarrollo y mantenimiento, muy extendida entre los ministerios o entes públicos hasta hace poco. Básicamente requería mucha documentación y existieron hasta 3 versiones de la misma. Muchas empresas en su momento adoptaron esta metodología de desarrollo tanto para proyectos con la administración pública como para privada. Requería de personas dedicadas a cada tarea con perfiles muy definidos.

Cascada: Esta metodología se caracteriza por estar dividida en fases casi lineales en donde cuando va a terminar una fase comienza la siguiente. Es muy utilizada de forma inconsciente en las empresas que no tienen metodología definida e incluso en la que los tiene al realizar un Grant para una oferta que solicitan una planificación. En estas situaciones sin llegar a realizar las fases se suele exponer una planificación con metodología en cascada. Un ejemplo de esta metodología es:

1. Análisis Requisitos

2. Diseño sistema

3. Diseño programa

4. Codificación

5. Pruebas

6. Implantación

7. Verificación

La documentación a generar es la que uno requiera según la empresa o responsable por lo que da flexibilidad con respecto a Métrica.

CMM o CMMI: Modelo de madurez de la capacidad para desarrollo software o Integración de modelos de madurez de capacidades. Se definen ambos tipos por tener tres niveles de calidad donde prácticamente cualquier empresa puede englobarse para saber su nivel de madurez. Los procesos de desarrollo son realizados por cada empresa siendo este un método de evaluación de dichos procesos implementados. Por si solo no es una metodología pero sí que conlleva el realizar tus propios procesos o conjunto de procesos para llegar al máximo nivel 5 e implica a toda la organización de la empresa.

Prototipo: es una metodología que se basa en la generación de prototipos a los cuales posteriormente de forma iterativa se les va dando forma. También se suele utilizar esta metodología englobada en otras cuando no se sabe muy bien el producto que se quiere obtener. Su principio es el de diseño rápido, pocos Recursos, Construcción rápida, entrega rápida y retroalimentación. El mayor inconveniente es que el usuario piensa que es funcional al verlo cuando es solo una maqueta para comenzar a delimitar los requisitos mediante iteraciones. Además en el diseño y desarrollo rápido se suelen tomar decisiones de implementación poco adecuadas.

Sin Metodología: Aunque alguno os parezca mentira muchas empresas no utilizan una metodología de forma consciente o fija, es decir, no siguen un estándar o una guía en cada uno de ellos o en cada fase del proyecto. Aplican una serie de proceso que han visto, vivido o es lo que les pide el momento o cliente. En el fondo si utilizan metodología ya que asignaran tarde o temprano tareas, realizaran análisis, reuniones, planificaciones pero sin seguir un estándar de calidad un objetivo. Sus inconvenientes pueden que sean mucho pero es cierto que quedan muchas empresas que van así y les resulta rentable. La ejecución de proyecto suele definirla el director directamente así como prioridades y tiempo dedicado a cada proyecto.

Actuales:

Digamos que son las que ahora etan más en boca de todos con una clara prederterminación a la metodología Agil.

PMBOK (PMI): Es una metodología de gestión de proyecto basado también en buenas prácticas que parte de la organización Project Manager Institute. Define un conjunto de áreas y procesos en los que aplica las buenas prácticas en cada uno de ellos.

Prince2: Parte de un conjunto de buenas prácticas que propone una metodología de gestión de proyectos. Contiene 7 principios principales como Roles y responsabilidades definidos, gestión por fases, orientación a producto, adaptación y algún otro. Además la práctica de Prince2 te asegura prácticamente la ISO 21500 de gestión de proyectos.

Agiles: Aquí entras en un mundo que cuando hablas de ágil estas englobando muchas metodologías. Todas tienen varios puntos en común como son la involucración del cliente en el proceso, el equipo de proyecto es el que decide y son desarrollos iterativos o incrementales, sin roles (perfiles) con un gran componente de adaptación al cambio. No hay unos requisitos fijos sino que se van generando partiendo de uno general como alcance de alto nivel. Los más conocidos en este tipo de metodología son:

• DSDM o Metodología de desarrollo de sistemas dinámicos

• Scrum

• Programación extrema o XP

• Lea

Aunque no existen niveles de Scrum hay que diferenciar entre 3 tipos a mi entender según el nivel de implantación o madurez de los procesos agiles:

Nivel 1: Utilizan KanBan que es la herramienta minima o principal para ver las tareas, no tiene por que ser equipos fijos, tienen reglas pero no DoD y mezclan otras muchas metodologias no agiles en las gestión. No hay involucración por parte del cliente como product Owner y no se le realizan Demo en las iteraciones hasta tener el entregable practicamente finalizado. No existe feedback hasta la entrega o un poco antes donde el nivel o posibilidad de reacción en bajo.

Nivel 2: Utilizan las practicas que les conviene de Scrum, los procesos no estan definidos y se van adaptando a los cambios mezclando otras metodologias. Se realiza en equipo pero no tiene por que ser un equipo fijo por lo que no se conocen y no tienen consensuados o definidos los DoD. Por parte del cliente no existe Product Owner involucrado realizando esta labor un consultor o responsable del proyecto por loq ue no hay un feedback real del cliente hasta las entregas o demos si las hay. Ciertas partes de calidad en los entregables, principalmente, son de nivel bajo.

Nivel 3: Utilizan las practicas de Scrum principales, el contacto o participación del cliente como product Owner no es tan alta existiendo un componenete de consultor interno en el proyecto tienen alguna definición de DoD auqnue no tiene por que estar escrita y suelen ser equipos fijos que trabajan siempre juntos.

Nivel 4: Los que solo para el desarrollo utilizan este concepto para llevar el grado de avance y el estado además de una dinamica de comunicación diaria y resolución de problemas. EL product Owner por parte del cliente está involucrado. Los equipos son fijos y se trabaja con unas reglas DoD definidas por todo el equipo.

Nivel 5: Los que llevan todo el proceso scrum desde el principio realizando maquetas al cliente, reuniones aportando ideas, conceptos y luego pasa el mismo equipo involucrado al desarrollo. Estos equipos son fijos y su trabajo esta compenetrado conociendose entre todos. hay una involucración directa con el Product Owner que sabe lo que quiere y necesita

Nunca he estado en un nivel 5 auqnue conozco su funcionamiento he intentado un nivel 4 con un gran fracaso auqnue del fracaso se aprende (" El exito no es mas que ir de fracaso en fracaso sin perder el entusiasmo") y bueno para mi esto es un desglose que si nos percatemos sería muy parecido al de CMMI.

Habria que añadir mcuho más detalles a Scrum no solo es lo comentado pero nos permite tener una idea del nivel de madurez que un equipo y digo equipo no empresa puede tener en la utilización del Scrum o metodología ágil.

En Scrum el equipo es muy importante y uno de los motivos de una empresa para no llegar a un nivel de madurez 4 o 5 es el equipo y en esa parte me incluyo logicamente.

El equipo debe conocerse, saber los PH que realiza o es capaz de realizar y esto se consigue a base de trabajo. Deberían ser personas con un nivel parecido de conocimiento, motivación y ganas de mejora, existiendo confianza entre ellos para exponer los problemas y para saber escuchar y apoyarse entre todos. Creo que si en otras metodologías el equipo es importante para realizar cualquier tarea en una metodología agil de cambio constante y adaptación es imprescindible y fundamental. De ahi el concepto de equipo de alto rendimiento que exponen muchas veces. Yo quisiera trabajr con un equipo asi pero para ello o los encuentras o los crear con el tiempo y la constancia. Una vez creado un equipo de alto rendimiento para que lo siga siendo debes adaptarte también a sus cambios personales que afectarán al equipo.

Esto que se cuenta asi de facil no lo es, debido a que es necesario conseguir un equipo y no se hace de la noche a la mañana, por desgracia es lo que te pide una empresa en muchas ocasiones.

Otro factor importante es la figura del product Owner por parte del cliente. esta persona debe saber bien lo que se necesita y lo que se quiere. Es muy comun que sea una persona con un nivel alto y que realmente tenga una idea distinta a la de los propios usuarios. Esto puede hacer peligrar el proyecto y en muchos casos es lo que hace que el producto final no sea el deseado. Dependiendo de su nivel de implicación y conocimiento asi como responsabilidad dentro de su empresa el existo será mayor o no. Muchas empresas aún no tienen este concepto de persona o de trato directo con los equipos por lo que se convierte en una barrera que se termina supliendo con consultores internos elevando el riesgo final.

Las empresas IT estamos ya en constante cambio y adaptandonos, solo falta que las empresas que nos solicitan esos proyectos guados por nosotros entiendan que un proyecto debe ser un camino a recorrer juntos.

No nos engañemos entonces diciendo que en todas partes y todas las grandes empresas utilizan Scrum e indiquemos que nivel de Scrum.

El caso es que actualmente por donde vas dicen que la única vía es Scrum para llevar a buen puerto un proyecto. Hace unos años recibí una formación de Scrum por Angel de Agilar. La cual fue muy instructiva respecto a las ideas de Scrum por dos motivos. Descubrí su esencia y sus necesidades para llevarlas a cabo que las tienen y grandes y por otro que pude escuchar por un experto que en nuestro estado, empresa y tipo de proyectos, servicios no era aplicable el Scrum.

Esta respuesta que yo personalmente la había aprendido a base de fracasos (tortas) hizo que me preguntara en cuantos sitios estarán intentando scrum y quedandose a medias o a un nivel de madurez que dista de ser Scrum.

El tipo de proyecto, el tipo de empresa condiciona mucho a la hora de realizar un cambio hacia una metodología agil.

Pensemos esto bien, en los proyectos de concursos publico tanto en España como en otros sitios te comienzan a decir y preguntar sobre metodologías incluso valorando la ágil pero en los pliegos te encuentras que te exigen un precio cerrado, un tiempo limitado incluso una planificación por fases, componentes, arquitecturas, prototipos, CV y perfiles. Como véis todas estas cuestiones se salen del principio de metodología ágil. Entonces, ¿qué empresa que concursa a un proyecto Público usa ágil de verdad? Está claro que si has definido ya unos requisitos sin el cliente partiendo de sus requisitos generales y presentas unos plazos sin el cliente y sin conocer por el equipo Scrum dichos requisitos ni siquiera que equipo lo realizará es difícil que sus principios se cumplan. Podrán trabajar si lo ganan con metodología ágil de forma interna pero sus iteraciones y feedback del cliente no estarán presentes adquiriendo la gestión y desarrollo de otras metodologías.

También las empresas que ya hemos comentado en las que sigu predominando el proyecto a precio fijo y que reclamarán sino esta terminado lo que ellos quieren. Parece la pescadilla que se muerde la cola. Ellos mismos no sabe lo que quieen pero si pretenden que lo que les entregues sea lo que ellos piensan. esta claro que hay que cambiar la mentalidad no solo de las IT sino de sus clientes y proveedores. Entonces reducimos más el numero de proyectos en los que aplicar una la metodlogía Scrum para realizarlo.

Mi propuesta, es analizar cada empresa, sus clientes, sus proyectos, las personas e implantar de forma clara la metodologia a seguir en cada caso con el componenete de mejora continua de lso procesos en cada caso.

Después de terminar esta parte he decidido dedicar dos post a este tema sino son tres.

#Metdología #Scrum #Agil #PMP #Prince2 #metodologiatradicional #Equipo #Kanban #planificar