MOOC “Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI” de MiriadaX

Hace unos días acabé el MOOC “Agilidad y Lean. Gestionando los proyectos y negocios del s.XXI“, quería “inventariarlo” en esta entrada recogiendo también algunos, no todos, porque el MOOC es muy extenso en contenido, de los aspectos que más me han gustado.

A continuación podéis ver el certificado de participación, para descargarme el de superación hay que pagar y de momento y como he hecho con otros anteriores no lo veo necesario.

El contenido del curso me pareció muy interesante. A continuación podéis ver el temario:

Aunque tengo intención de escribir otra artículo en el cual explique con más detalle cómo he aplicado la metodología ágil a mi actividad, el desarrollo de una oferta a un cliente, y en la que he podido reconocer muchas prácticas ágiles en mi día a día sin ser consciente de ello, en esta entrada sólo pretendo dejar apuntadas algunas notas que me han parecido muy interesantes, son:

¿Qué es la gestión ágil?

  • La terminología utilizada en IT proviene de la época industrial, de ahí los nombres de Arquitecto de soluciones, Ingeniería del software, desarrollo en cascada, etc… este tipo de nomenclatura y roles, pensados para la construcción de grandes proyectos en la época industrial, no casa con el desarrollo de software, una actividad más intelectual y creativa, ni con los tiempos actuales de entregas y cambios rápidos de requerimientos.

Peopleware:

  • Para cualquier proyecto donde se hace software, la clave son las personas.
  • Cuando las cosas se atascan la solución no pasa nunca por poner más gente, poner más gente hace que el proyecto se retrase más.
  • Ciclo de vida de un proyecto tradicional: Requisitos->Diseño->Codificación->Test->Despliegue
  • Un modelo ágil requiere cambiar la cultura de la empresa. Hay varios tipos de cultura (control, colaboración, cultivar, competencia), las metodologías ágiles no se pueden poner sobre cualquier tipo de cultura, sobre la de control por ejemplo, por eso requiere un cambio cultura.
  • Shu-ha-ri (seguir norma, romperla, re-inventarla).
  • El tamaño óptimo de un equipo es de 5 a 9 miembros.
  • Trabajar en más de un proyecto genera pérdidas de tiempo por cambio de contexto, de 10 a 15 minutos.
  • Hay que limitar el WIP a no más de 3.
  • Técnica de Pomodoro.
  • Los equipos de alto rendimiento, sin los cuales no hay agilidad, son auto-organizados (se les dice el qué y ellos deciden el cómo) y multifuncionales (personas de distintas áreas dentro del mismo equipo). De esa forma reducen dependencias y bloqueos, disparan la velocidad y productividad.
  • En los equipos no debe haber superhéroes.
  • Productivad no son horas, hay que medir el Valor Aportado
  • Hay que facilitar entornos con pocas interrupciones.
  • Gantt, herramienta de destrucción masiva de proyectos.
  • “El equipo debe estar sentado con una separación no superior a la longitud de un autobús escolar”. No obstante, Agile deja abiertas las puertas al teletrabajo y en el libro “Scrum y XP desde las trincheras” hace referencia al mismo como una posibilidad muy valiosa para determinados momentos del proyecto.
  • La importancia de la motivación intrínseca y 10 factores que la generan (curiosidad, lealtad/confianza, asociación al éxito, conocimiento, poder/influencia, libertad/independencia/autonomía, relaciones, claridad/sinceridad, objetivo/propósito, status).
  • Delegar, tableros de delegación y sus 7 niveles.

Product Owner y las historias de usuario.

  • El product owner es el que divide el proyecto/producto que se quiere hacer en “trocitos” (historias de usuario), las comparte con el equipo y ayuda en su validación. Es la figura que representa a los stakeholders, el que va diciendo los requisitos. Hace parte de la gestión de proyectos clásica.
  • Las historias de usuario conforman la Pila de Producto (product backlog). El PO decide que historias de usuario entran en el product backlog y las prioriza.
  • En metodologías ágiles no hay “requerimientos”, hay “historias de usuario”, son funcionalidades:

  • Estas HU deben poder ser desarrolladas en un sprint, deben poderse escribir en un post-it para que sean fácilmente visualizadas y recordadas, dicen el qué, no el cómo, aunque de forma excepcional se puede hacer casos de uso (cómo). Tienen 3 partes (Card, Conversaton and Confirmation/Validación).

  • Método INVEST para creación de historias de usuario (Independiente, negociable, valiosa, estimable, small y testeable).
  • Método MoSCoW para priorizarlas (Must Should Could Won´t).

SCRUM.

  • Nace como un método para gestionar un proyecto ágil, no un producto.
  • Roles: Product Owner, Scrum Máster, equipo de desarrollo.
  • El Product owner es la persona responsable del gestionar las necesidades que serán satisfechas por el proyecto y asegurar el valor del trabajo que el equipo lleva a cabo. Su aportación al equipo se basa en:
    • Recolectar, gestionar y ordenar las necesidades o historias de usuario.
    • Aceptar el producto software al finalizar cada iteración.
    • Maximizar el retorno de inversión del proyecto.
  • También relativo al uso de SCRUM con equipos distribuidos, me pareció interesante este estudio:”Using Scrum in Global Software Development: A Systematic Literature Review“.
  • Una vez se seleccionan las Historias de usuario que van al sprint, en el sprint planning el equipo de desarrollo las divide en tareas según un peso dependiendo del tiempo que lleva implementarlas, se autoasignan y se suman al “sprint backlog”, que es inamovible y representa lo que se va a hacer.
  • El PO puede tocar el product backlog, pero no el sprint backlog. Para las actividades del sprint se suele utilizar un tablero Kanban.
  • En el Sprint Review el equipo de desarrollo presenta al PO lo que  ha hecho y en base a ello se pueden proponer nuevas HU que vayan al product backlog, también se definen las HU del siguiente sprint.
  • El burndown chart es una medida del progreso del sprint.
  • El lado oscuro:
    • vender un proyecto y luego asignar un equipo, mucho mejor dar a un equipo ya consolidado un nuevo proyecto.
    • Tableros Requeriments, Design, Development y Test en los equipos es lo contrario a los T Skills (profundidad y amplitud) necesarios en el equipo.
    • Workflows, te paso la pelotita.
  • El SCRUM Máster es quien identifica y elimina el desperdicio.
  • La agilidad no se escala, se desescala. Scale Agile muy cuestionado.

Planificación Ágil.

  • Gestión orientada a equipos en lugar de gestión orientada a proyectos (primero el proyecto y luego el equipo). #noprojects
  • La unidad de estimación son los puntos, lo ideal es elegir una HU básica, darle la unidad y comparar las demás con ella.
  • Yesterday´s weather, una buena predicción del futuro es fijarse en lo que hemos hecho en el pasado. Estimación predictiva vs empírica. Es mejor fijarse en lo que ha hecho el equipo antes, de ahí la importancia de los equipos estables.
  • Técnica del planning poker.
  • La velocidad es la cantidad de trabajo (puntos de historia) que un equipo puede hacer en una iteración.
  • ¿Cuanto debería durar una iteración? Hay que evitar que los requisitos cambien durante la misma, por lo que sería el tiempo en que podemos mostrar un progreso para poder luego ajustar sobre él.
  • ¿Tiene sentido estimar? Movimiento #noestimates.
  • Ágil con estimaciones->Ciclo de vida iterativo, gestión con SCRUM. Contrato basado en número de iteraciones.
  • Ágil sin estimaciones->Gestión con KANBAN. Contrato por valor generado al negocio (historia de usuario terminada).

Deuda técnica.

  • El que no controla la calidad del software va “con la muerte en los talones”. Difícil de mantener, cae la productividad y…. pastilla roja o verde (refactorizar o añadir más gente). REFACTORIZAR.
  • agilidad->ciclo de vida iterativo: incrementar y REFINAR
  • El role de Quality es ahora muy distinto a la época pre-ágil.
  • Antes se podía entregar el producto sin calidad y encima tenías al cliente cautivo. En ágil los problemas aparecen pronto, en los sprints, no al cabo de 15 meses.
  • En ágil aparece el rol de QA Tester, muy demandado.
  • Calidad del producto software no es lo mismo que testing. Con el testing se comprueba que una cosa funciona, no que esté bien hecha, para ésto hay que mirar sus fuentes, diseño, etc…
  • Certificaciones como CMMI dicen que la calidad de un producto viene dado por la calidad del proceso de su creación, lo cual no es del todo falso… pero hay que mirar dentro.
  • La mala calidad del producto siempre tiene un coste, es la llamada deuda técnica, y lo paga o la empresa de software o el cliente (cliente cautivo, sobre exceso de horas de mantenimiento, etc…).
  • Las buenas prácticas ITIL, ISO20000, no son suficientes, generan “alertas”, pero hay que abrir el motor para solucionarlo y verlo. Una certificación de calidad no siempre asegura un producto de calidad.
  • Behavior-Driven Development o BDD es un proceso de desarrollo software, si bien se relaciona principalmente con el Testing, que es de donde surge. BDD busca un lenguaje común para unir la parte técnica y la de negocio donde las pruebas de aceptación se escriben usando historias de usuario: Dado [contexto inicial], cuando [se produce el evento], entonces [resultados]
  • El ciclo básico de BDD sería el siguiente…
    1 – Escribir las historias de usuario.
    2 – Escribir los escenarios.
    3 – Automatizar las pruebas de aceptación.
  • Las historias de usuario, o features en el mundo BDD, las escribe negocio, es responsabilidad del product owner. En BDD, con el objetivo de automatizar el Testing, aparte de tener historias en pósit cada historia de usuario se escribirá usando un lenguaje “de programación” llamado Gherkin y se guardarán en un fichero de extensión .feature que posteriormente serán leídos por una herramienta que los entienda, por ejemplo, Cucumber (para Ruby), que verifica si el software se comporta como el fichero Gherkin dice.
  • Gherkin es un lenguaje entendible por el negocio, lo que se llama un DSL (Domain-Specific Language), más o menos cercano al lenguaje natural. Está pensado para que lo entienda “negocio”, los usuarios, etc. Su idea es contar como se “comporta” el software sin entrar en detalles de implementación.
  • Alguien del equipo tiene que escribir el código que transforma el texto en Gherkin en interacciones con el código a probar, pero antes necesitaremos escenarios asociados a cada historia de usuario que nos den ejemplos de cómo debe comportarse el software implementado para esa historia. Esos escenarios serán el paso intermedio entre la historia de usuario y la implementación de una prueba automatizada.

De momento nada más, creo que es una buena muestra de lo aprendido. He disfrutado mucho este curso y pretendo seguir escuchando y leyendo a Javier Garzás y 233 grados de tí, referentes muy interesantes en el mundillo Ágil.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s