 |
| Lista de Chequeo de Scrum |
Si logra esto puede
ignorar el resto de la lista. Su proceso está bien.
- Entregar software funcionando y probado cada 4 semanas o menos
- Entregar lo que el negocio necesita más
- El proceso está mejorándose continuamente
Hablemos un poco de cada
uno de estos criterios.
Entregar software funcionando y probado cada 4 semanas
o menos
Scrum es un método
iterativo e incremental. Pero “iterativo” e “incremental” son dos adjetivos
ampliamente usados y pocas veces entendidos correctamente. Ya sabemos que una iteración
es un proyecto, con todo lo que eso significa: es decir, si nos atenemos a
la definición del PMI®, un proyecto tiene un inicio, una planeación,
una ejecución, un seguimiento y control, y un cierre, donde se formaliza la
aceptación del producto o resultado, un producto que, en nuestro caso, es
precisamente software, desplegado en un ambiente del usuario, no necesariamente
ambiente de producción, pero del usuario al fin y al cabo, un entorno distinto
al del desarrollador.
Este “incremento” de software
funcionando es potencialmente distribuible, o sea, puede ponerse en producción
con muy pocas o ninguna modificación, preferiblemente esto último. Y si este
proyecto tarda cuatro semanas (como lo prescribe la guía orgánica de Scrum) o
menos, mucho mejor. La industria del software, la nuestra, está diciendo a
gritos que este lapso de tiempo sea de dos semanas. Así, podemos conseguir
retroalimentación más efectiva y al día de los usuarios, mucho más de lo que
hemos logrado en el pasado cuando solo entregábamos “papelware”, documentos llenos de texto (requisitos), diagramas de
UML (arquitectura, análisis y diseño), casos de prueba, etcétera.
Entregar lo que el negocio necesita más
¿Quién mejor que el
usuario conoce el verdadero valor de lo que necesita? Es el usuario, que en
Scrum se llama Dueño del Producto, el que define y prioriza sus necesidades y las
de los demás interesados, asegurándose así que los intereses de la organización
queden incluidos en el producto; también es quien sabe cómo alcanzar las metas
organizacionales y es el responsable de maximizar el valor del producto y del
trabajo del Equipo de Desarrollo, y es el encargado de no perder el foco en el
valor de negocio. Bien sabemos que, a más involucramiento del cliente en el
proyecto, este saldrá mejor y se obtendrá una mayor satisfacción al final,
tanto el usuario como el equipo que lo atiende.
Con esta premisa en mente,
en esas iteraciones o sprints de
corta duración que mencionaba en el apartado anterior, siempre estaremos
entregando el producto que todos quieren ver. Un beneficio directo de esto es
la posibilidad que tiene la organización de responder a la competencia aun
durante el propio proceso de desarrollo y no después de este, como ocurre en
los proyectos ejecutados con métodos más tradicionales. Además, este enfoque
hace que el producto vaya madurando en la medida de su exposición a los
usuarios. A medida que el producto se expone y más cambios resulten de allí,
más maduro llega a ser el producto. Y cuando esto ocurre, la probabilidad de
obtener ROI a corto o mediano plazo es mucho mayor.
El proceso está mejorándose continuamente
Empiece con Scrum “al
natural” o Scrum orgánico, o sea, el que está definido en la guía
de Ken Schwaber y Jeff Sutherland: consiga un dueño de producto (un cliente),
nombre un Scrum Master y establezca un equipo de desarrollo pequeño. Y ya está
listo para iniciar. Haga la reunión de planeación, asegúrese vía el Scrum
Master de que el equipo completo esté realizando la reunión diaria y que al
final de cada sprint de 4 semanas o menos se haga una reunión de revisión y una
de retrospectiva para conocer no solo el estado del proyecto sino del equipo en
general y para crear un plan de mejoramiento que sea ejecutado a partir del
siguiente sprint y en los demás proyectos con Scrum.
Asegúrese de que todo lo
mencionado se haga como dice la guía, por ejemplo, que las reuniones diarias
tarden 15 minutos flash. De lo
contrario, mejore primero esos aspectos que no se están haciendo bien. El Scrum
Master debería ser capaz de lograrlo. A partir de allí, vaya introduciendo
nuevas prácticas, no sin antes entrenar al equipo: refactoring, desarrollo dirigido por pruebas o TDD por sus siglas
en inglés, kanban, lean, historias de usuario, programación en pares, casos de
uso 2.0, entre otras. Adiciónelas una a una al proyecto, haga acompañar a su equipo
de expertos en cada técnica, monitoree su ejecución, mida los resultados y haga
los ajustes necesarios. Repita para cada práctica.
Conclusión
La entrega constante de software
probado y funcionando cada pocos días o semanas, que sea de valor para los
usuarios, y el mejoramiento continuo del proceso, contribuyen trascendentalmente
al éxito en los proyectos. Scrum es un marco de trabajo que hace
posible todo lo anterior. Y esta lista de verificación, la cual iremos atomizando
poco a poco en este Gazafatonario, es un instrumento productivo que se puede
usar como suplemento de primer orden a la guía de Scrum.
Lecturas adicionales:
La lista de verificación completa de Scrum la
encuentran en mi artículo:
Sobre Iteraciones pueden leer mi artículo "Gerencia
de Proyectos Iterativos" en la revista de la Asociación
Española de Profesionales en Dirección de Proyectos.
El libro de reglas de Scrum, la guía de Scrum, lo
encuentran en:
Sobre casos de uso 2.0 y métodos ágiles pueden leer mi
serie de artículos en este Gazafatonario:
Casos de Uso 2.0 y Métodos Ágiles:
Casos de Uso 2.0:
¡Quiero una Porción de Caso de Uso!
Casos de Uso 2.0 – Aplicable a todos los tipos de
sistemas y organizaciones:
Todavía Otra Lección Más Sobre Porciones de Casos de
Uso:
¿Por qué existe Casos de Uso 2.0?
Todavía Otra Lección Más Sobre Porciones de Casos de
Uso:
http://www.gazafatonarioit.com/2013/02/todavia-otra-leccion-mas-sobre.html
