Publicado
Javier Roman
Ventajas de Scrum para gestionar proyectos web
¿Qué es Scrum?
Scrum es un marco de trabajo liviano que se utiliza para la gestión de proyectos.
Scrum no es una herramienta, ni un proceso, ni un método. Un método está pensado para algo que se hace más de una vez con cierta estabilidad y Scrum está indicado para entornos más inestables.
Scrum está basado en el empirismo y el surgimiento y emplea un enfoque iterativo e incremental. Por eso Scrum es muy adecuado para gestionar proyectos en los que se lanzan nuevos productos o servicios.
En Scrum es fundamental la transparencia que permite la inspección continua que a su vez permite la adaptabilidad.
Se realiza una inspección continua sobre el producto y también sobre el proceso mediante un enfoque empírico que permite la retroalimentación.
Historia de scrum
En el comienzo de la informática los proyectos se gestionaban con el modelo predictivo o en cascada en el que lo que había que hacer se decidía a priori antes de comenzar el desarrollo. El control estaba en un agente externo y las decisiones estaban centralizadas. Había menos errores pero los que ocurrían eran de mayor impacto. Las personas tenían una mayor especialización. Este modelo es adecuado para contextos de problemas simples o complicados.
Este modelo predictivo estaba inspirado en la arquitectura que se utiliza para construir productos físicos como por ejemplo un edificio, pero no funcionaba realmente bien para proyectos informáticos. La programación consiste en construir un producto intelectual. El software no lo hacen máquinas, lo hacen personas, la parte clave es el equipo, no funciona la idea de cadena de montaje y especialización. Por eso poco a poco se va cambiando al marco Agile.
En 1995 se funda el framework Scrum por Jeff Sutherland y Ken Schwaber que soluciona los fallos del modelo predictivo.
En 2001 nace el manifiesto Agile. Scrum como marco de trabajo se apoya en el manifiesto Agile.
En 2010 se realiza la primera publicación de la Guía Oficial de Scrum.
El framework Agile se utiliza para entornos de menor estabilidad, menor previsibilidad y menor control. Es para contextos de problemas complejos o caóticos con mayor nivel de ambigüedad. Por eso las decisiones se toman sobre la marcha según lo empírico. Las decisiones están descentralizadas. Hay más errores pero de menor impacto porque se reacciona más rápido sobre la marcha.
El conocimiento proviene de la experiencia que vamos recolectando en el camino. Las decisiones son resultado de inspeccionar y adaptar de forma permanente. Destaca la flexibilidad, la adaptabilidad.
La clave de Agile es la adaptabilidad, la capacidad para adaptarse a los cambios. El error es inevitable pero se capitaliza como una inversión porque tenemos capacidad de adaptación. Las personas están menos especializadas, son multitarea.
Indicado para entornos complejos
La masificación de la tecnología hace que todo sea más impermanente y más complejo. Agile sirve para contextos de gran volatilidad e impermanencia.
Según la teoría de la complejidad explicada por el marco Cynefin, dependiendo del nivel de conocimiento y complejidad, un proyecto o una empresa puede ser:
- Caótico
- Complejo
- Complicado
- Simple
A medida que vamos ganado conocimiento y experiencia en un proyecto éste se va moviendo de caótico a complejo, de complejo a complicado, y de complicado a simple. En ocasiones, por la inercia y falta de adaptabilidad de los entornos simples, se puede pasar de simple a caótico.
Los proyectos que tienen más requerimientos y más herramientas serían simples y complicados, mientras que los proyectos que tienen menos requerimientos y menos herramientas serían complejos y caóticos.
El marco Agile es idóneo para entornos complejos y caóticos.
Ventajas de Scrum y los entornos ágiles
Las razones para la adopción de Agile en la gestión de proyectos son las siguientes:
- Involucrar al cliente en el proceso de desarrollo
- Reducir el horizonte de planificación para hacer una entrega temprana y frecuente de valor.
- Acelerar la entrega de software
- Responder mejor a los cambios
- Capitalizar los errores puesto que representan un aprendizaje
- Controlar el proceso de manera empírica. El control no está centralizado en una persona sino en todo el equipo que negocia con el dueño del producto.
Los valores de Agile
El marco Agile tiene cuatro valores:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Los valores de Scrum
Scrum tiene cinco valores de tipo conductual:
- Coraje para resolver problemas difíciles
- Foco en el Sprint
- Compromiso con el objetivo
- Respeto
- Apertura
Incorpora elementos de otras prácticas
Scrum incorpora elementos de otras prácticas como:
- Lean
- Kanban
- EXtreme Programming (XP)
Lean
Lean es un paradigma inspirado en el sistema de producción Toyota. Se hace enfasis en la calidad y el cliente. Se busca siempre entender lo que el cliente necesita y poner al cliente en el centro.
EXtreme Programming (XP)
XP considera los cambios de requerimientos durante el ciclo de vida de un proyecto como algo natural. Se utiliza el pair programming, las historias de usuario, las pruebas unitarias y las pruebas automatizadas.
Kanban
Kanban es una herramienta de gestión visual para fomentar la transparencia. Se busca limitar el trabajo en progreso. El objetivo es comenzar algo y terminarlo y no aceptar más trabajo mientras estamos con trabajo en curso.
No empieces nada que no esté listo para ser terminado
Hay tres etapas:
- To do
- Doing
- Done
Para pasar a «To do» hay que tener todas las condiciones de inicio cumplidas (Definition of Ready, DOR).
Para pasar a «Done» hay que tener todas las condiciones de finalización cumplidas (Definition of Done, DOD).
Minimum Viable Product (MVP)
Un MVP es un producto vivo e inacabado al que se le va dando valor incremental a medida que se van lanzando prototipos al mercado de manera iterativa.
Esto es muy idóneo para lanzar nuevos productos que nunca antes se habían ofrecido en el mercado. Con un MVP, los usuarios reales lo pueden probar en cada iteración.
No estar en producción es gastar dinero sin hacer dinero.
Kent Beck (eXtreme Programming)
¿Cómo se planifica?
El proceso de crear software con valor tiene distintas etapas. La organización trabaja en una secuencia para lograr la visión, eliminar la ambigüedad y detallar el trabajo de forma que se logre un producto funcional.
Estas capas secuenciales son Estratégica, Táctica y Operativa. De esta forma vamos planificando de más general a más específico:
- Project Plan (Épicas)
- Release Plan (Temáticas)
- Sprint Plan (Historias de usuario)
- Task Board (Tareas y actividades)
Una épica es una historia de usuario que no puede ser entregada dentro de una sola iteración, o que es suficientemente grande como para ser partida en historias de usuario más pequeñas.
Es importante tener consensuada previamente una DOR (Definition of Ready) para empezar un nuevo sprint y una DOD (Definition of Done) para finalizar un sprint, y unas Condiciones de Satisfacción del Product Owner.
La Definition of Ready tiene que incluir los acuerdos con todas las dependencias:
- Acuerdos con equipos externos que tienen que hacer algo durante el sprint
- Input que necesito de otro equipo para poder comenzar con la actividad
En Scrum no es que no se planifique si no que se planifica con mayor frecuencia con un horizonte de planificación más corto. Al acortar el horizonte de planificación, el nivel de certidumbre es más alta. Se realiza una inspección diaria sobre el proceso y sobre el producto.
Se pasa por tres etapas: Product Discovery, Product Inception y finalmente Product Delivery.
Product Discovery
El Product Discovery lo hace el Product Owner con los stakeholders. Se crean las épicas que son agrupadores funcionales.
Son técnicas de ideación y convalidación de hipótesis que da lugar a una visión del producto y a un User Journey.
El User Journey son los pasos que hace el usuario desde el principio hasta el final.
Product Inception
El Product Inception se llama también Sprint 0.
El Product Owner se reune con el equipo de desarrollo y con el Scrum Master. La Épica se desagrega en Historias de Usuario y se establece el Release Plan. El Release Plan es el User Story Mapping.
Las historias de usuario son pequeños bloques funcionales más pequeños.
Un release es un conjunto de historias de usuario, priorizadas, con las que se elabora un MVP que entregue funcionalidad completa para el negocio y los usuarios, de valor incremental respecto a la versión anterior. Un release puede tener uno, dos o tres sprints. El release es un agrupador funcional de sprints.
En Product Inception se realiza también el Team Inception que son los acuerdos necesarios con otros equipos.
Product Delivery
Del Product backlog seleccionamos los elementos que van a formar parte del Sprint backlog. Finalmente concretaremos el Sprint backlog en los Backlog items que son las actividades y tareas.
Un sprint suele tener varias historias de usuario, por ejemplo entre 4 y 6.
El 10% del trabajo mensual del equipo se dedica al refinamiento en el que preguntamos dudas al Product Owner para quitar ambigüedades.
Si hemos cumplido la DOR pasamos a To Do, luego pasamos a Doing, y si hemos cumplido la DOD pasamos a Done.
Para hacer Scrum se tienen que dar todos sus elementos constitutivos
Para inspeccionar y adaptar el producto y el proceso necesitamos tener 3 roles, 5 eventos y 3 artefactos:
3 roles
Hay tres roles en Scrum:
- Product Owner
- Scrum Master
- Equipo Scrum
El Product Owner establece el qué y el equipo Scrum establece el cómo.
5 eventos
- El Sprint
- Sprint Planning
- Daily Scrum o Daily Standup
- Sprint Review
- Sprint Retrospective o Retrospectiva
3 artefactos
- Product Backlog
- Sprint Backlog
- Incremento
El Product Owner
El Product Owner define QUÉ vamos a hacer.
Es el que realiza el Product Discovery y el Product Inception.
Define el objetivo del incremento potencial del producto, así como el objetivo del Product Backlog para no perder foco y no desvirtuar el alcance.
Es el encargado de priorizar, así como de planificar junto con el equipo de desarrollo.
El Product Owner es el punto focal con el negocio y trata con los stakeholders para:
- Mantener la visión del producto maximizando la entrega de valor
- Es el dueño del Product Backlog y lo prioriza
- Controla toda la inversión relacionada con el producto
- Valida las funcionalidades
- Está disponible para el equipo Scrum que le ofrece transparencia para que pueda tomar decisiones en tiempo real
El Product Owner no es un Analista Funcional ni un Jefe de Proyecto.
El sprint 0 (Alistamiento o Product Inception) sin fechas es potestad del Product Owner y ya cuando le ponemos una linea de tiempos interviene en la decisión el equipo Scrum y DevOps. Esto es muy importante para garantizar los plazos de entrega.
El Product Owner revisa solo lo que está en Done para ver si cumple con la DOD.
El Scrum Master
El Scrum Master es el que coordina el Product Delivery.
Es el que guía la daily standup para tener foco y así inspeccionar y adaptar.
Es un facilitador imparcial que ayuda a promover discusiones para que se puedan tomar decisiones.
El Scrum Master da servicio tanto al Product Owner como al Equipo de Desarrollo y se encarga de la eliminación de impedimentos y protege al equipo de interrupciones externas.
También es un agente de cambio. Busca generar los vínculos necesarios para promover interacciones que generen valor.
El equipo Scrum
El equipo Scrum define CÓMO lo vamos a hacer.
Es el que realiza el Product Delivery.
El equipo Scrum tiene que ser autoorganizado y multifuncional.
Además de autoorganizado tiene que ir un paso más allá y ser autogestionado. Es un modelo de liderazgo distribuido en el que el responsable de la entrega es todo el equipo.
Un equipo autogestionado tiene que tener nivel de decisión, nivel de responsabilidad y nivel de autoridad. Son evaluados como un todo, como un equipo, y no como un idividuo.
Scrum busca menores depenencias (resolver lo más posible dentro del propio equipo) para así eliminar los tiempos de espera.
El Scrum Team presenta el resultado de la interacción al Product Owner. El equipo como un todo es responsable de cada entrega o release.
Es importante resaltar que el propio equipo es proactivo, autónomo y responsable.
¿Cómo se presupuesta?
En vez de presupuestar un proyecto completo, se presupuestan features con entrega de valor temprano. Se financian features y no proyectos.
¿Qué más es necesario para hacer Scrum?
La verdadera dificultad está en la integración entre lo técnico y lo social.
Además de hacer Scrum, hay que tener una mentalidad Agile que tiene que impregnar toda la complejidad social y cambiar el comportamiento social.
Qué es lo fundamental de Scrum
Lo fundamental de Scrum es gestionar todas las variables imprevistas tanto en lo técnico como en lo social.
Agilidad no significa más rápido, significa trabajar de forma más adaptable para entregar valor frecuente.
El sinónimo de Agile no es rápido, es adaptable.
No es la más fuerte de las especies la que sobrevive, tampoco es la más inteligente la que sobrevive. Es aquella que se adapta mejor al cambio.
Charles Darwin