Categorías
Desarrollo Metodologias

Haciendo Software – Metodologías – 2 de 3

Vale, continuando la estela del post anterior y dando un enfoque totalmente pragmático, voy a describir un poco algunas de las metodología mas populares, todas iterativas e incrementales, agiles en concepción. Veremos como se comportan antes los problemas antes mencionados.

  • ¿Cómo de buenas son en la gestión?
  • ¿En la definición de objetivos y tratamiento de los requisitos?
  • ¿Garantizan una buena arquitectura y diseño del Software? ¿El código tendrá una calidad alta?

Aportando para cada una de ellas los puntos fuertes, menos fuertes y no muy fuertes ¡Ahora en positivo! ?

Anteriormente en el contador de bytes…

SCRUM

Aquí tienes una definición, aunque seguro que ya has estado en algún proyecto SCRUM.

https://es.wikipedia.org/wiki/Scrum_%28desarrollo_de_software%29

Y un dibujo que ayuda a repasarlo más rápidamente

Gestión: Esta metodología se centra en que el equipo trabaje lo más unido posible, es su punto fuerte. La distintas reuniones de las que consta, facilitan la sincronización y la comunicación del equipo. Las reuniones diarias y las de lecciones aprendidas aportan mucho valor.

Los equipos son pequeños, autónomos y auto organizados. Así pues, se espera de ellos habilidades transversales, entre el equipo desarrollador se debe contar con experiencia en el análisis, diseño, etc.

La prioridad de las tareas la marca el valor que aporta para el cliente.

Se adapta bien al cambio de requerimientos

El código es la documentación, aunque también se suelen apoyar en repositorios tipo Wiki para temas recurrentes.

Se estima a corto plazo, en cado inicio de spring se estima la tarea,

Objetivos / Requisitos: Los requisitos se llaman historias de usuario, se debe trabajar mano a mano con el cliente, se espera una implicación muy alta del cliente, y se van acumulando en el Product backlog. La estimación y visión final es a corto plazo, se calculas solo para las tareas de un spring.

Elaboración: No se especifica una metodología para que el software tenga calidad, queda en mano de los componentes del equipo y a su criterio.

PUNTOS FUERTES

  • Potencia al equipo e involucra a todas las partes. Facilita la comunicación y la motivación. Define roles y dispone de mecanismos para estimar y medir
  • Acepta los cambios de requisitos muy bien y define la estrecha colaboración con el cliente.
  • Se centra en entregar valor al cliente lo antes posible.
  • Fácil de aprender.

PUNTOS MENOS FUERTES

  • Las historias de usuario se definen ligeramente y se estiman cuando se abordan.
  • La evolución de las historias de usuarios son complicadas de trazar en el código.
  • No se necesita una visión final del proyecto. Por lo tanto es posible que no se pueda estimar ni el tiempo ni el coste del proyecto

Y NO MUY FUERTES

  • La elaboración y la calidad del software no esta contemplada en la metodología. Si el código es malo, la documentación es mala.
  • No tiene en cuanta desde el principio los riesgos más grandes del proyecto. Ya que empieza por lo que más valor aporta.
  • Si los equipos son grandes, tiene dificultades para escalar. Si un miembro del equipo es reemplazado, puede ser muy tedioso de sustituir.
  • Todos los miembros del equipos están presentes desde el principio, incluso cuando el número de tareas es baja y muy concretas.

KANBAN

¿Pero esto no se invento para hacer coches?

https://es.wikipedia.org/wiki/Kanban

Pues sí, es la más ligera de todas, se trata de una metodología muy visual. Se preparara un tablero, sobre el se definen unos estados de la actividad y se interactúa con él mediante unas fichas (normalmente post-it) que reflejan una tarea o historia. De esta manera se tiene un control sobre su situación y se puede terminar rápidamente la atención que puede requerir.

Gestión: Todo muy visual, ayuda a la motivación del equipo ver correr las tareas por el tablero. Existe varias métricas, WIP ayuda a limitar el numero de tareas concurrente y descubrir cuellos de botella.

No se define el tiempo de duración de una iteración.

Objetivos / Requisitos: Se definen con las tarjetas y se apilan hasta que se abordan. Es muy flexible en la entrada de requisitos y sus modificaciones.

Elaboración: No describe método para la realización de Software de calidad.

PUNTOS FUERTES

  • Muy fácil de aprender y utilizar.
  • Se adapta muy bien a los cambios.
  • Motiva al equipo y da una foto de la situación actual muy buena.

PUNTOS MENOS FUERTES

Y NO MUY FUERTES

  • No define roles
  • No se define el seguimiento, ni la colaboración con el cliente. Difícil de estimar costes y tiempos.
  • No es necesaria una foto final
  • No define método para desarrollar Software de calidad.

Extreme Programming

La definición detallada:

https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema

Se tratan de hacer iteraciones con un incremento, en las que los desarrolladores, normalmente en equipos de dos,

  1. Hacen un requisitado y un análisis del problema.
  2. Escriben los test unitarios buscando un buen diseño (TDD)
  3. Programan y validan los test
  4. Despliegan
  5. Vuelven a empezar, a veces refactorizando lo escrito anteriormente y buscando siempre la mejor arquitectura y el diseño.

Y todo esto con simplicidad, comunicación, retroalimentación (feedback), coraje y respeto. Eso dicen…

Gestión: Se confía en la experiencia del equipo para la gestión del proyecto, siguiendo siempre los pasos del método.

Involucra a todas las partes y define unos roles.

Aunque pone énfasis en las personas, la metodología no aporta método.

Se planifica a corto plazo.

Objetivos / Requisitos: Se debe trabajar mano a mano con el cliente, los requisitos se definen y planifican en cada iteración. Es posible no tener muy clara la visión final.

Elaboración: Toda la calidad del software depende de los integrantes del equipo, en cada iteración buscan la mejor arquitectura refactorizando si es necesario. La arquitectura va emergiendo en tiempo de desarrollo.

PUNTOS FUERTES

  • Si el equipo está compuesto por auténticos fuera de serie, el desarrollo es muy rápido. Ya que la arquitectura va emergiendo sobre la marcha.
  • Hacer tests es una parte importante del método.

PUNTOS MENOS FUERTES

  • Se aprende rápido, aunque desarrollar empezado por los test unitarios suele olvidarse pronto.

Y NO MUY FUERTES

  • Complicado estimar
  • Poca documentación.
  • Si los desarrolladores no son dioses, el diseño final puede tener una calidad muy baja.

Rational Unified Process (RUP)

Aquí tienes una definición completa, está metodología aborda toda fases del desarrollo del Software.

https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational

Todo proyecto consta de cuarto fases, como si fuera una cascada, pero en cada una de ellas se itera sobre unas disciplinas con mayor o menor profundidad según en la fase en la que nos encontremos. Por ejemplo, en la fase inicial se le da mucho peso a la toma de requisitos y se elabora muy poco, en en la fase de construcción ya se definen pocos requisitos o los cambios surgidos y se elabora software como principal meta.

Gestión: La estructura del equipo está jerarquizada, y los fases están claramente descritas. Su gestión y la definición artefactos de salida (código y documentación) es sólida.

Lo anterior ayuda a que sea más útil en equipo grandes o de grandes colaboraciones (intra empresariales) o de una complejidad alta. La documentación esta diseñada para facilitarlo.

Se planifica a largo plazo, siendo las tareas de mayor riesgo técnico, económico, politico... las primeras que se deberán abordar, se le da más prioridad.

Objetivos / Requisitos:

Marca las directrices para definir el modelo del problema y la toma de requisitos. Los casos de uso tienen una trazabilidad con el código y su evolución se simplifica.

Se fuerza a que el cliente piense en la visión final.

Elaboración:

Esta metodología se centra en la arquitectura y vela por que el análisis y diseño sea de la mayor calidad.

PUNTOS FUERTES

  • Es una metodología que contempla todo el ciclo de vida. Define roles y métricas.
  • Pone el foco en definir la arquitectura y abordar los principales riesgos desde fases muy tempranas.
  • Un nuevo miembro o empresa que se incorporé al desarrollo tiene siempre una documentación disponible. Escala bien.
  • El lenguaje UML es parte de este método, si no se abusa, aporta mucho valor.
  • Si el cliente es poco colaborativo, se saca mas provecho de su tiempo.
  • Resuelve la toma de requisitos de manera profunda. Es posible estimar tiempos y costes.
  • Al contemplar distintas fases, es posible que el equipo crezca según la necesidad del momento.

PUNTOS MENOS FUERTES

  • Es menos flexible a los cambios en los requisitos pero los aguanta al ser iterativa e incremental.

Y NO MUY FUERTES

  • Esta más orientada al éxito de proyecto y los procesos que a las personas.
  • Compleja de aprender y aplicarla correctamente requiere de mucha experiencia.
  • Es más costosa y lenta en su aplicación que el resto.

Combinaciones

Todos estos método tienen sus ventajas y desventajas, así que su aplicación dependerá de muchos factores.

Hacer Software de cierta complejidad utilizando solo scrum o Kanban… y esperar que tras meses de desarrollo este tenga una calidad aceptable… ¡Es difícil!. ¡Sin embargo, se vende bastante bien! ¡Ya somos agiles! ¡Cómo molamos! ?

LA UNIÓN HACE LA FUERZA

Por eso se suelen combinar, la que he visto más veces es la de SCRUM+XP. Pero XP requiere de programadores senior++ para que la arquitectura resultante llegue a algo bueno tras muchas iteraciones tanteando.

A veces se ven cosas como SCRUM+KANBAN, donde las distintas historias de usuario de SCRUM corren por un tablero. Es un poco raro, ya que no se suele aplicar la métricas Kanban, pero es ideal para los seguimiento ejecutivos.

A mi particularmente, me gusta más RUP, quizás por ser la que pone el peso en la definición de la arquitectura, la cual es normalmente más complicada de cambiar y requiere una buena pensada antes de ponerse con ella. Además, permite muchas adaptaciones para simplificar la metodología.

Existe un metodología scRUmUP que combina SCRUM con RUP, ya que este último se centra en los procesos y enfatiza menos a las personas. Esta última carencia, SCRUM la resuelve muy bien ¡y es clave!.

En el próximo post resumo, hago una tabla comparativa dando mi opinión de cuando usar una y otra.

¡A darle caña!?

Deja una respuesta

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