Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Lista de verificación. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Lista de verificación. Mostrar todas las entradas

martes, mayo 21, 2013

Scrum – Lo Fundamental


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

domingo, mayo 12, 2013

Lista de Chequeo Scrum

Lista de Chequeo Scrum
[Descargar] Lista de Chequeo Scrum

De las muchas listas de verificación que encontré en los últimos meses, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.
Esta es la traducción al español.
¿Qué es esto? ¿Para quién es?
La lista de chequeo Scrum es una herramienta simple para ayudarlo a empezar con Scrum, o para evaluar su actual implementación de Scrum.
Note que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum pero se aseguraron de que el propósito de la práctica Scrum ha sido cumplido de otra forma. ¡Esto es lo que cuenta!
Si usted está haciendo Scrum, podría ser interesante hacer que su equipo tenga esta lista en la retrospectiva. Como una herramienta de discusión, no como una herramienta de evaluación.
¿Cómo la uso?
  • Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”
  • Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad.”
  • Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.
  • Lisa: “Mira, también nos hace falta ‘Entregar software funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque mercadeo siempre se está quejando de eso!”
  • Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos  a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido”
  • Lisa: “Buena idea, intentémoslo.”
¿Cómo NO la uso?
  • Gran Jefe: "Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”
  • Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”
  • Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del  sprint! ¡Las quiero ver"
  • Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario.”
  • Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”
¿Es esta una lista de chequeo oficial?
No. La lista de chequeo refleja mi opinión personal* y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.
Descargar la lista de chequeo Scrum
Pueden descargar la lista en formato PDF haciendo clic aquí.
https://drive.google.com/open?id=0B5SNac-eZKMMYmYzTWVMRmp2VEk

* Y la del traductor.



Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puede leer este artículo:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html