Fundamentos de SCRUM
Fundamentos de SCRUM
Es importante que domines los fundamentos de SCRUM si quieres implementar con éxito esta metodología.
Seguramente ya has leído libros y blogs que explican los diferentes procesos de SCRUM. El desarrollo en sucesivas iteraciones o sprints, el daily, el Sprint Planning, la retrospective, etc.
Si no conoces los fundamentos de SCRUM, lo mas probable es que cometas los mismos errores que la mayor parte de las organizaciones. Acabarás por implementar SCRUM como si fuera una religión y apenas conseguirás mejorar la productividad.
En novanotio defendemos que hay cuatro sencillas reglas que ayudan a gestionar con éxito los proyectos tecnológicos. Es una buena idea que revises nuestro artículo sobre las cuatro leyes antes de continuar con esta lectura.
En esta entrada vamos a analizar las relaciones entre las cuatro reglas básicas y los procesos de la metodología. Una vez que comprendas los fundamentos de SCRUM, estarás mejor preparado para implementarla en tu organización.
Relación entre SCRUM y la 1ª ley.
Las especificaciones son inciertas, imprecisas e infinitas.
La primera ley nos advierte tres cosas:
– Que el cliente no puede saber lo que quiere. El tiempo invertido en especificar suele ser tiempo perdido.
– Que una especificación redactada en lenguaje natural (castellano, inglés, alemán, etc.) es interpretable.
– Que no es posible finalizar los trabajos. Siempre queda algo por hacer.
¿Cómo responde Scrum a estos tres desafíos?
– El diseño es muy liviano; los requisitos se capturan en Epics, Features e Historias de Usuario, cuya extensión es de un párrafo.
– Para interpretar la especificación, se incorpora al squad un representante del cliente, el Product Owner,
– El Product Owner prioriza los trabajos para que el Retorno de Inversión sea el mayor posible, dentro del presupuesto.
Relación entre SCRUM y la 2ª ley.
One Project, One Team, One Site.
La segunda ley dice que para mejorar la productividad, todo el equipo de trabajo, incluido el cliente, debe estar en una única oficina y dedicarse en exclusiva al proyecto. La convivencia construye vínculos emocionales y relaciones de confianza que son imprescindibles.
¿Cómo construye Scrum los equipos?
En Scrum, los squads de desarrollo están formados por entre cinco y nueve consultores, cuyos puestos de trabajo están próximos entre sí. El Product Owner, que es el representante del cliente, es un miembro más del equipo.
Relación entre SCRUM y la 3ª ley.
Presión x Talento = Constante.
Talento y presión son antagónicos. Cuando uno crece, el otro disminuye.
La tercera ley nos recuerda que en el desarrollo de software debemos priorizar el talento sobre la presión. La velocidad de desarrollo depende del número de buenas ideas, no del número de horas de la jornada.
¿Cómo fomenta Scrum el talento?
Para eliminar la presión, en Scrum no es obligatorio completar todas las Historias planificadas para el sprint. Algunos desarrollos no superan los test y vuelven al backlog.
Relación entre SCRUM y la 4º ley.
El triángulo de Acero.
La cuarta ley nos enseña que Alcance, Plazo y Calidad están relacionados de tal forma que, si fijas dos de ellos, el tercero se degrada.
Tradicionalmente un contrato fija el alcance y el plazo. ¿El resultado? El 80% de los grandes proyectos son un fiasco.
Así que, como cliente, debes elegir entre:
– Sacrificar el Alcance. Ciertas funcionalidades no se construirán.
– Sacrificar el Plazo (y multiplicar el coste). El sistema se entregará muuucho mas tarde de lo planificado.
– Sacrificar la Calidad. El sistema tendrá errores en producción y será complejo de operar.
¿Qué variable sacrificamos en SCRUM?
La metodología SCRUM determina que la variable sacrificada es el Alcance.
La gran aportación de SCRUM es modificar la definición de éxito de un proyecto. Ya no tenemos que cumplir un alcance dentro de un plazo y con una buena calidad. Cosa que, por cierto, es imposible.
Éxito es conseguir el mayor retorno de inversión posible, dentro del presupuesto y en un plazo acotado.
¿Puedo mejorar la eficiencia sin usar Scrum?
Si conoces los fundamentos de Scrum, puedes utilizar los principios básicos de gestión de proyectos y mejorar el rendimiento de tus proyectos sin necesidad de implementar la metodología.
Pero SCRUM es la palabra de moda. ¡Aprende a implementar esta metodología y tu valor para el mercado se multiplicará!
Scrum no es una religión
Scrum no es una religión
SCRUM no es una religión. SCRUM es una forma de aplicar las Cuatro Leyes Básicas de la gestión de proyectos. El proceso de desarrollo Scrum es eficiente porque cumple estas cuatro reglas.
Si entiendes los fundamentos de la gestión de proyectos informáticos, puedes adaptar SCRUM, o cualquier otra metodología, a tu empresa.
Pero si no conoces estos fundamentos, corres el riesgo de implantar SCRUM en tu organización como si fuera una poderosa religión.
Y no encontrarás la tierra prometida.
Si adoptas SCRUM como si fuera una religión…
SCRUM es la religión de los elegidos
Scrum es todopoderoso porque es la religión de los elegidos. Si quieres llegar a la tierra prometida de la tecnología, ese lugar idílico donde todos los proyectos finalizan en plazo, debes seguir puntualmente cada uno de sus ritos.
Ya en los tiempos olvidados de las tarjetas perforadas, los profetas Brooks y DeMarco nos advirtieron que los proyectos son tan complejos que podemos trabajar en ellos por los siglos de los siglos. Imbuidos por el espíritu, propusieron abordar la solución en sucesivas iteraciones, meditando junto al cliente tras cada una de ellas qué se ha conseguido y qué se debe hacer a continuación.
El ritual SCRUM que inspiraron es como sigue:
La Sagrada Firma
El Sumo Account Manager descubre una necesidad del cliente y prepara una oferta que tiene plazo y presupuesto definidos pero cuyo alcance queda indeterminado. Realiza sacrificios a Poseidón y ofrendas a Baco para que el cliente realice la Sagrada Firma.
La Sagrada Firma es el ritual más complejo y al que menos atención se presta en los Textos Sagrados. Los clientes no iniciados se resisten a comprometer presupuestos determinados a cambio de servicios indeterminados. No intentes explicarles que en los proyectos realizados según los heréticos ritos de Waterfall, donde el alcance si estaba definido, en media sólo se entregaba el 50% de lo especificado.
El Product Backlog y el Team Backlog
Tras la Sagrada Firma, el cliente unge a uno de sus acólitos con la pesada responsabilidad del éxito de la empresa. A partir de ahora todos le conocerán como el venerable Product Owner.
En un concilio entre cliente, Account Manager y Product Owner, describen el sistema en una docena de tarjetas sagradas de una extensión de algunos párrafos llamadas Epics y Features. Las sagradas tarjetas se exponen a los acólitos en un altar de corcho llamado Product Backlog para que sean para ellos fuente de inspiración.
En sucesivos aquelarres, el Product Owner y los programadores, descomponen Epics y Features en nuevas tarjetas llamadas Historias de Usuario, que tienen la forma ‘Como usuario <perfil de usuario> soy capaz de hacer <tarea> y así consigo <valor para el negocio> ’. Exponen su trabajo en un nuevo altar de corcho, el Team Backlog.
La implementación
Es el momento de comenzar los ritos de implementación.
El primero es formar la escuadra de desarrollo, con el Product Owner, un Scrum Master y entre cinco y siete consultores. Sus puestos de trabajo deben estar próximos entre sí y se encargarán de implementar de extremo a extremo las Historias de Usuario. Su sagrado apostolado incluye definir la arquitectura, hacer el diseño, codificar, probar, integrar y documentar.
Cada iteración comienzan con la ceremonia del Sprint Planning. El squad se reúne para decidir qué Historias de Usuario intentarán implementar durante el Sprint, que durará entre tres y cuatro semanas. El Product Owner sabe qué historias de usuario son prioritarias. La escuadra intuye su velocidad de ejecución.
Cada mañana, antes de la salida del sol, la escuadra se reúne para maitines, rito también conocido como daily. Durante el resto del día, diseñan las Historias de Usuario, las codifican, desarrollan las pruebas unitarias y prueban el software construido. Sólo si el código supera las pruebas se considera apto para depositar a los pies del cliente e implorar su aceptación.
El Product Owner ayuda a los programadores a interpretar las sagradas Historias de Usuario. El Scrum Master vela por la pureza de los rituales.
El Sprint Review
Finalizado el Sprint, el squad celebra el Sprint Review, ceremonia en la que el código desarrollado se ofrece al cliente y las Historias de Usuario que no se han completado se devuelven al team backlog.
El Sprint Retrospective
El acto final es el Sprint Retrospective. Aquí Product Owner, programadores y testers reconocen sus faltas y hacen propósito de enmienda, con el fin de ser más productivos en próximas iteraciones.
Que los Dioses te sean propicios
Sigue religiosamente este ritual y alcanzarás la tierra prometida con la bendición de los Dioses.
Los peligros de imponer SCRUM a tu organización como si fuera una religión
Los ritos de SCRUM son folclore, comportamientos llamativos que emplean otras organizaciones. Desconocemos su significado, pero hay cientos de artículos describiendo su éxito y son tentadores de imitar.
Un ejemplo de imitación del folclore. Una organización que compró una mesa de billar, pero despidió a un consultor por ir al médico. ¿Veis a lo que me refiero? Si te despiden porque estás enfermo y vas al centro de salud, ¿cuál será el castigo si estás sano y dejas de trabajar para hacer carambolas?
Si no conoces las reglas básicas de la gestión de proyectos, corres el riesgo de implantar SCRUM como si fuera una religión, y cometer los mismos errores que buena parte de las organizaciones.
Y entonces no llegarás a la tierra prometida.