Conceptos
Que debemos conocer
Conceptos básicos
Buscar información adicional
No te quedes con la duda!
Concepto
simplemente mencionar que la agilidad no es una Metodología, sino una manera de hacer distinta, un mindset o una nueva mentalidad.
La agilidad es la habilidad de adaptarse a los cambios; situación tan comun un un mundo VICA como el actual (Volatil, Incierto, Complejo y Ambiguo)
En el desarrollo de software hace mas de 20 años, surgio el concepto que los enfoques tradicionales no estaban dando respuesta a un mundo tan cambiante y con tanta incertidumbre de origen y lo largo del proyecto. Como hacer un plan y seguirlo, si las variables cambian constantemente.. Como hacer si no podemos cambiar nosotros.
La agilidad es eso. Nuestra habilidad a cambiar... Los Proyectos no son los que deben ser agiles, los agiles debemos ser nosotros.
Te recomendamos todos los articulos que subimos contantemente en nuestro sitio sobre agilidad..
Articulos sobre Agilidad
Conceptos adicionales que te sugerimos ver
Marco Cynefin.
Hay mucho en Internet... ejemplo : nuestra charla sobre incertidumbre en los proyectos: Charla sobre incertidumbre en los proyectos
VENTAJAS DE UTILIZAR EL CICLO INCREMENTAL
— Feedback. Existe una retroalimentación para mejorar el producto según los resultados que vamos obteniendo de los usuarios o clientes. Testear y modificar.
— Gestión del riesgo del proyecto. Al tratarse de metodologías ágiles, gestionamos mejor los cambios de última hora, nos adaptamos a las exigencias que conllevan aplicar soluciones al instante y ponemos a prueba la planificación del proyecto.
— Control y visión del alcance real del proyecto. Adaptaciones necesarias. Metas cortas, por bloques. Tal y como funciona la metodología Scrum.
— Orientado al cliente y sus requerimientos. Los proyectos se centran ahora en el cliente y no tanto en el producto en sí mismo.
— El aprendizaje y experiencia del equipo iteración tras iteración sobre un prototipo operativo, lo que mejora exponencialmente el trabajo, aumenta la productividad y permite optimizar el proceso en el corto plazo.
Es mu comun hablar de ciclos cortos de Feedback; este concepto es central en los marcos de trabajo agil; donde se trata de ir generando pequeños incrementos ; a veces experimentos para ir desarmando la incertidumbre; hacemos pequeños cambios, los testeamos, obtenemos feedback rapido, capitalizando tanto si anda bien, como capitalizando el error como experiencia. El Metodo adaptivo de control, basado en ciclos cortos de feedback rapido, es central dentro de los desarrollos agiles.Los ciclos incrementales son tambien conocidos como adaptativos
La idea de efectuar entregas cortitas, chiquitas en pequeños slots de tiempos (llamados sprints en scrum) podria a priori configurar la idea de que eso favorece la velocidad..
Seguimos pensando entones en esquemas tradicionales o como si nuestro problem estuviese en el terreno de las solucione faciles o sencillas (ver Cynefin); entonces si se perfectamente lo que tengo que hacer, simplemente incremento la velocidad y seria la formula perfecta.
Pero resulta que no estamos parados ahi, sino en el terreno de la complejo, donde no hay una correlacion directa entre el input y el output, entre las variables A y B, etc.. se trata entonces de hacer experimentos, hacer pequeños cambios para poder ir moviendonos de sector a otro mas amigable.
No se trata entonces de producir mas, mas rapido sino producir cosas que tengan impacto, eventualmente como ya vimos si hago cosas chicas, me equivoco en chico y el impacto es menor. Pero aprendo.
Se trata entonces de incrementar el valor; al tiempo que decremento el output; que resulta todo lo contrario de producir mas rapido.
Es decir mayor impacto, trabajando menos..
En otras palabras, se trata de hacer lo que importa, lo que tiene mayor impacto.. No necesariamente eso implica incrementar el output, sino incrementar el impacto en el valor a entregar al cliente que produce nuestro output.
Ahi llegamos a la definición.. Outcome es el impacto de valor que genera nuestro output... El "para que" estamos generando ese output..
Es fundamental que el sprint sea un periodo fijo, igual siempre.
Este concepto esta relacionado a que es necesario para calcular la capacidad del equipo; en funcion de la capacidad del equipo, se planifica el proximo incremento de producto.
1. Corta duración
Mientras menor es la duración de cada Sprint existe mayor facilidad para realizar la inspección y adaptación del desarrollo. Cuando el horizonte de un Sprint es demasiado grande la definición de lo que se está construyendo podría cambiar, la complejidad podría incrementarse y el riesgo podría aumentar.
2. Timeboxed
El Sprint posee una duración predefinida. Esto corresponde a una técnica de gestión del tiempo que ayuda a organizar, focalizar y hacer eficiente el desempeño.
Tener un tiempo predefinido y acotado obliga a desagregar o atomizar el desarrollo en pequeños ítems que deben caber dentro del timebox.
3. Inicia al finalizar el Sprint anterior
Un Sprint siempre se inicia inmediatamente después de finalizado el Sprint anterior. No existe tiempo intermedio entre uno y otro, por lo tanto, no pueden existir eventos, tareas ni actividades que se realicen entre el término de un Sprint y el inicio del siguiente.
4. Objetivo no modificable
Durante la reunión de Sprint Planning se negocia y define un objetivo para el Sprint (Sprint Goal). Una regla primordial de Scrum es que una vez que comienza la ejecución del Sprint el objetivo debe permanecer inalterable.
5. Incremento de producto entregable
Cada Sprint debe tener como resultado incrementar el producto en una pequeña funcionalidad o aspecto que esté completamente listo, es decir, que cumpla la definición de “Done” para pasar a producción.
Desagregacion
Ejemplo: al relevar las necesidades, identificamos muchas requerimientos que pueden ser agrupadas, por tema y dentro de estos temas en "subtemas" y estos desagregadas en funcionalidades necesarias para cumplir con estas y a su vez las funcionalidades pueden ser desagregadas en tareas o actividades.. etc.
Es un proceso básico de analisis y desagregación.
¿Qué son las historias, los epics y las iniciativas?
- Las historias, también llamadas "historias de usuario", son breves requisitos o solicitudes escritas desde el punto de vista del usuario final.
- Los epics son grandes cantidades de trabajo que se pueden desglosar en un número de tareas más pequeñas (llamadas "historias").
- Las iniciativas son conjuntos de epics que conducen hacia un objetivo común.
Ejemplo:
Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:
“Como [perfil], [quiero] [para].”
Desglosemos esta estructura:
- “Como [perfil]”: ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.
- “Quiere”: aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.
- “Para”: ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?
Por ejemplo, las historias de usuario pueden tener este aspecto:
- Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.
- Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.
- Como gestor, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos.
Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de "hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa. Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.
El backlog es dinamico. y es mantenido por el PO (Product Owner)
El PO, se asegura de mantener el backlog siempre:
* Actualizado con las necesidades del negocio/cliente
* Priorizado , para que el equipo pueda tomar las mas importantes.
* Refinado, para que las historias de usuario, esten completas y listas para ser tomadas por el equipo.
El backlog es un artefacto vivo, una pila que representa el trabajo pendiente.
Si se acaba el backlog, se acaba el proyecto.
El equipo trabaja sobre el backlog para estimar las tareas en el, en sucesivas reuniones de refinamiento previo a la planificación.
Una vez priorizado el backlog, refinado y estimado, en la reunión de Planning el equipo en conjunto con el PO, toman en funcion de su propia capacidad, la porción de arriba del backlog (prioritaria) y constituye el Sprint backlog, que es el compromiso de trabajo para el sprint.
El proceso de mantenimiento, refinamiento, del backlog es continuo.
Si bien el PO es el dueño, todo el equipo es responsable de mantener el backlog.
Es la visión a mediano plazo del futuro previsto para el producto. A diferencia de un plan tradicional representado por un Gantt, que por definicion del metodo debe estar "tallado en piedra"; el roadmap es un visión; un plan de alto nivel; pero nunca un compromiso cerrado.
Un antipatron o idea errada es que la agilidad no tiene planificación; por aquello del manifiesto agil que decia promover el cambio por sobre seguir un plan.
Que no haya un plan tipo predictivo; no significa que Agilidad es improvisación o falta total de idea de futuro. Todo lo contrario; hay una fuerte vision de futuro; pero tambien un fuerte compromiso en adaptarse segun las necesidades. El roadmap representa esa idea; pero esta en constante revisión y adaptación a lo largo del proyecto.
