Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Reglas del Juego Scrum. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Reglas del Juego Scrum. Mostrar todas las entradas

sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español

jueves, noviembre 27, 2014

Antipatrones Scrum: primer acercamiento


“Scrum es como el ajedrez. O lo juegas como lo dictan sus reglas, o no lo juegas. Scrum y el ajedrez no fallan ni aciertan. O los juegas, o no.” Ken Schwaber [1]
Presentación, o de la relación que tiene Bruce Lee con un arquitecto de apellido Alexander, una banda de los cuatro, Chuck Norris y Kent Beck

Las llaman ‘malas prácticas’, a mí me gusta llamarlas ‘prácticas fuera de contexto’; en el entorno ágil, algunos incluso hablan con humor de ‘Scrum Norris’, refiriéndose a aquel actor de Hollywood, Chuck Norris, quien apareciera por primera vez en 1972 en una película del legendario Bruce Lee, La Furia del Dragón, y que se hiciera popular por allá en los años 80 con películas de acción como Ojo por Ojo, Perdidos en Acción y Fuerza Delta y donde, a pesar de la incesante acción, no sufría ni un rasguño, ni siquiera se espelucaba. Los más técnicos y aventajados penetran la barrera científica y las llaman ‘Antipatrones’. Pero para usar este último término, primero definamos qué es un patrón, en nuestro contexto.

Quizás todos recordamos los súperarchipopulares ‘patrones de diseño’ [2] de los también súperarchifamosos ‘banda de los cuatro’ (Gang of Four), compuesta por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, quienes a su vez basaron su investigación en el trabajo de un Arquitecto (no de software), Christopher Alexander, quien por allá a finales de los 70, dio origen al tema como un concepto arquitectónico. Lo curioso de este asunto es que no fueron Gamma y su banda quienes primero tomaron ese concepto de Alexander: fueron los mismísimos Kent Beck y Ward Cunningham quienes en 1987 comenzaron a experimentar con la idea de aplicar patrones a la programación de computadores y presentaron sus resultados en el OOPSLA de ese año.

Toda esta historia, que siempre me ha parecido fascinante, porque es en la que se basarán los antropólogos de la TI en el futuro para descubrir al resto del universo de donde proviene la inteligencia artificial: las máquinas que piensan, los robots que hablan mejor que los humanos y los computadores ópticos, toda esta historia, simplemente para entender que un ‘patrón’ es una solución reusable a un problema común y recurrente dentro de un contexto. Pero ojo, un patrón no es una solución terminada, en cambio, es una descripción de cómo solucionar un problema.

Finalmente, hay patrones de Análisis (Fowler), patrones de diseño (Gamma et all), patrones de programación (Beck), patrones de pruebas (Binder), etcétera. Por supuesto, están los patrones en los métodos y en las prácticas y en los procesos. Pero de todo esto hablaremos en otra oportunidad. Lo que me ocupa esta vez son precisamente los Antipatrones Ágiles, en general, y los de Scrum, en particular.

Antipatrones Scrum: una primerísima aproximación pragmática

Un Antipatrón es, entonces, la antítesis de una solución a un problema recurrente. En el caso de los métodos y prácticas (ágiles), son actividades, procedimientos o rutinas, usos o hábitos, que personas dentro de una organización o entorno adquieren o ejecutan, con la idea de que son la forma ‘correcta’ de hacer las cosas. Estas malas prácticas se dan por múltiples razones. Aquí algunas de las respuestas más frecuentes que escucho en mi trasegar ágil:
  • Siempre lo hemos hecho así
  • Nuestras condiciones son únicas, entonces debemos hacerlo de esta manera (¡la madre de todas las entelequias!)
  • Hay temor al cambio (la más natural de todas estas especulaciones, el miedo es algo inherente al ser humano. Es quizás este miedo el que infunde los demás motivos expuestos aquí. No en vano León Felipe dice: “el miedo del hombre…ha inventado todos los cuentos.” [3])
  • La teoría, lo que dicen los libros y los manuales (léase Guías) no nos aplica
  • Tenemos regulaciones que nos impiden hacerlo de otra forma
  • No hemos tenido entrenamiento ni acompañamiento (de expertos en la materia)
Quizás esta última sea la razón cardinal de que las organizaciones se desvíen de las prácticas propuestas en Scrum por distintos motivos y de que las implementaciones prácticas de Scrum rara vez sigan los ideales de los libros de texto y mucho menos de sus autores. Es probable que algunos de esos porqués estén bien respaldados y sean sensatos, como lo hemos abordado en algunos ambientes, sin embargo, la gran mayoría de las veces las organizaciones no alcanzan a distinguir netamente las secuelas que se derivan de tomar esas desviaciones y se sienten tentadas a ajustar, a ‘acomodar’ Scrum y otras prácticas ágiles para ellas.

He estado allí: muy tarde se dan cuenta estas organizaciones que han caído en un sinfín de malas prácticas o en unos hábitos inadecuados para las personas, para los equipos y para la organización misma. Los resultados infaustos empiezan a aparecer cuando tratamos de ir un poco más allá: ‘bueno, ya que hacemos Scrum, agreguemos TDD y refactoring’ o ‘ya que hemos gestionado dos o tres proyectos con Scrum, llevemos esto a nivel corporativo’. Personas quemadas, clientes/usuarios que no ven la diferencia con métodos anteriores (léase Cascada, WaterRUP, etc.) o modelos de calidad como CMMI, COBIT, PMI y familiares.

Ahora bien, es cierto que en un lapso de tiempo relativamente breve, desde el ascenso de los arquetipos, poéticos por demás, del Manifiesto Ágil, muchas organizaciones se han afiliado a alguna forma de trabajo ágil. Pero lo que realmente está sucediendo cuando alguien dice “somos ágiles”, es “estamos usando algunas prácticas o ideas de Scrum y de otros métodos o prácticas ágiles”, algo que se conoce ordinariamente como ScrumBut (en español, ScrumPero –algo así como: ‘sí, usamos Scrum pero…’, donde este ‘pero’, quiere decir muchas veces: no tenemos Dueño de Producto, o no hacemos reuniones diarias, o el Scrum Master es el mismo Arquitecto de software o el gerente del proyecto, o no tenemos ‘definición de terminado’, entre muchas otras cosas y, con frecuencia, un compuesto de varias de estas).

Primera lista no exhaustiva, incompleta, de antipatrones Scrum

Hasta aquí la perorata, a manera de introducción. Lo que sigue es una lista de esas prácticas fuera de contexto, o antipatrones.
  1. “Nuestro Scrum Diario tarda 30 minutos o más, hablamos mucho de todo”, emparentado con “no hacemos Reunión Diaria porque no le vemos sentido”. Ya sé, tus tareas tardan 20, 30 o más horas y cada día que se reúnen, tus actividades siguen “en progreso”. Por eso no tiene sentido reunirse cada día.
  2. “Hablamos con el Dueño de Producto cada 2 o 3 semanas, durante la reunión de planificación”
  3. “Nuestro Sprint 0 es de nunca acabar, estamos detallando todos los requisitos”, también conocido como el ‘contraataque de la Cascada’
  4. “No sabemos donde está el Backlog del Producto”, o del ‘extraño caso del backlog de producto misterioso’
  5. “No tenemos definición de terminado”, familiar de “nuestro ‘trabajo en progreso’ es ilimitado”
  6. “No hacemos retrospectiva porque todo funciona muy bien con Scrum” o “nuestras retrospectivas son una oda a la autolaceración”. Me sé muchas otras con nuestra reunión favorita de regresión y análisis. Una, a propósito de Scrum Norris: ‘Cuck Norris no necesita Revisiones ni Retrospectivas. No hay espacio para el mejoramiento en los procesos de Chuck Norris’.
  7. “Nuestros Scrum Masters están en piloto automático”. A estos los ascendieron en esta década a zombis. ¡Estamos llenos de Scrum Masters zombis! Necesitamos un proyecto ‘Alice’ que acabe con esa disfunción.
  8. “Sí, hacemos sprints de 2 semanas, pero no entregamos valor al negocio”. Estos son los del enfoque iterativo e insustancial. El producto resultante es una colcha de retazos
  9. “Nuestros equipos son elásticos: sus miembros entran a y salen del equipo en cualquier momento del sprint y en cualquier sprint”
  10. “En la organización cambiamos el modelo de gestión del PMI por Scrum, pero el resto del proceso lo dejamos tal cual estamos certificados CMMI”
Suplemento
  1. “Nuestros Scrum Masters están asignados a 4, 9 y hasta 17 proyectos simultáneamente”, mejor conocido el Pulpo Ágil
  2. Nuestros clientes aceptan que usemos Scrum pero los proyectos son tiempo fijo-costo fijo-alcance fijo y el cronograma lo debemos entregar el primer día”
Por ahora solo la lista, pero mi análisis irá mucho más allá. Cuál es el contexto donde típicamente ocurre la mala práctica, cuál es la recomendación de Scrum/Ágil para cada eliminar el antipatrón de la faz de la tierra (bueno, al menos, del entorno donde se presenta), cuáles son las consecuencias de insistir en el mal-uso de la práctica, cuál es la solución (al menos, parcial) y, quién sabe, quizás alguna que otra excepción en la que el uso del antipatrón se justifique. ¿Es esto último posible? Yo no lo sé de cierto, lo supongo.

Colofón

Finalmente, quiero referirme a la frase inicial que usé para abrir este primer incremento sobre el tema: tiene razón Schwaber al hacer la analogía de Scrum con el Ajedrez. Las reglas de este juego son pocas y bastante simples, sin embargo, las estrategias existentes para jugarlo son diversas. Y hay un momento en el juego de la ‘Torre’ y el ‘Alfil’, llamado el ‘juego medio’ por los estudiosos, que se parece mucho a cuando los equipos de construcción de software juegan al diseño y a la programación usando las maniobras de Scrum: es cuando se requiere de creatividad, innovación, anticipación; es cuando precisamente nos damos cuenta que el desarrollo de software, como el Ajedrez, es jugado por personas, no por procesos ni herramientas.

Volveré con más antipatrones… ¡pronto! Mientras tanto, cuéntame cuáles malas prácticas o antítesis de excelencia, te has encontrado al ingresar a este apasionante pero complejo universo del desarrollo de software con métodos y prácticas ágiles.

Referencias

[1] Blog de Ken Schwaber: abril 7 de 2011:
https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/

[2] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

[3] Felipe Camino Galicia de la Rosa, conocido como León Felipe (Tábara, Zamora, 11 de abril de 1884 - Ciudad de México, 18 de septiembre de 1968), fue un poeta español. Este es su poema “Sé todos los cuentos”:
Yo no sé muchas cosas, es verdad.
Digo tan sólo lo que he visto.
Y he visto:
que la cuna del hombre la mecen con cuentos…
Que los gritos de angustia del hombre los ahogan con cuentos…
Que el llanto del hombre lo taponan con cuentos…
Que los huesos del hombre los entierran con cuentos…
Y que el miedo del hombre…
ha inventado todos los cuentos.
Yo sé muy pocas cosas, es verdad.
Pero me han dormido con todos los cuentos…
Y sé todos los cuentos.


lunes, octubre 21, 2013

¿Por qué fallan las implementaciones de Scrum?

Respuesta: porque desconocemos los valores y principios del Manifiesto Ágil punto
El Manifiesto por el Desarrollo Ágil de Software

La razón que expuse es apenas una de las muchas por las cuales podemos fracasar al intentar Scrum. Para hacerle frente, entonces es necesario conocer de qué se trata exactamente el Manifiesto Ágil. Este lo encontramos en http://www.agilemanifesto.org/iso/es/. Sin embargo, lo copiaremos aquí para explicar mejor el asunto que nos ocupa:

Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

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

Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
Estos son los valores. Le siguen una docena de principios que pueden encontrar en la página que mencioné antes. Este texto parece inofensivo pero encierra una enorme carga emocional; sin embargo, lo más importante es que nos enseña justamente cómo debemos enfrentar los proyectos de construcción de software actuales. Y como leerlo es más fácil que entenderlo, en la sección de Referencia enumero algunos de los artículos de mi Gazafatonario IT que intentan explicar de una u otra forma la razón de ser de este manifiesto.
Algunas recomendaciones para tener éxito al implementar Scrum
  • No piense en herramientas antes que en el proceso y no piense en el proceso antes que en las personas y sus interacciones. ¿Cómo va a lograr que las persones interactúen entre sí? “La gente tiene que trabajar cara a cara” dice el mismísimo Jeff Sutherland, y para todos Scrum debe ser una forma de hacer, una forma de ser, una forma de vida. Esto es, valorar el valor “Personas e interacciones sobre procesos y herramientas” del Manifiesto Ágil.
  • Necesitamos herramientas, sí, pero no permitamos que estas nos dicten el proceso e indiquen el camino a seguir, lo último que queremos son productos de software costosos antes de lograr que Scrum funcione o antes de lograr los primeros resultados exitosos con el método. Además, necesitamos un proceso para gestionar toda una operación, desde la concepción de los productos hasta la puesta en funcionamiento de los mismos a cabal satisfacción de los usuarios/clientes; y el núcleo de ese proceso debe ser precisamente Scrum, tal y como dice la Guía, no es necesario “inventar” nada más.
  • Tampoco es necesario eliminar o agregar nada más a Scrum como marco de gestión. Por ejemplo, decir que hacemos Scrum pero no tenemos Dueño de Producto o usar el patrón proxy del Dueño de Producto, es algo común en las implementaciones deslucidas de Scrum. Uno de los principios del Manifiesto Ágil lo dice claramente: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Esto apunta a resolver la mayor causa de fracaso en los proyectos tradicionales: “falta de involucramiento del usuario” [7]. 
  • No piense que Scrum le va a solucionar todos sus problemas, incluidos los personales. Scrum no es una bala de plata [4], de hecho, Scrum por sí solo no es suficiente, debe acompañarse de un conjunto de prácticas y otros métodos preferiblemente ágiles. Eso sí, no intente implementarlos todos de una sola vez y mucho menos intente hacerlo solo, hágase acompañar de expertos, de personas que hayan recorrido el camino y que quizás hayan cometido uno o dos errores críticos; con seguridad, serán ellos quienes lo sacarán del aprieto en el que posiblemente se va a encontrar más de una vez.

  • No piense en las certificaciones. Si cree que les hacen falta, estas llegarán a su debido tiempo. Cuando tenga la suficiente experiencia y madurez para darse cuenta que no las necesita. Sí, certificarse nos trae beneficios a nosotros como individuos y a las organizaciones para las que trabajamos o representamos. La certificación verifica que nuestro nivel de pericia y conocimiento es consistente con los estándares de la profesión en un área específica, pero, también a veces, las certificaciones atribuyen competencias donde usualmente no las hay, a quienes usualmente no las tienen.
  • Uno de los aspectos que hacen “mágico” a Scrum es que podemos implementarlo usando Scrum. La gran ventaja es que no tenemos que definir un proceso porque ya está definido [8]. Podemos tener una Lista de elementos a implementar (el backlog) y los separamos en sprints de 2 semanas para ir implementando gradualmente en unos pocos meses. Esto permitirá que las personas se sientan cómodas y a gusto con el cambio y se logren mejores resultados más rápidamente.

En cada Sprint de implementación de Scrum realice las ceremonias orgánicas de Scrum:
  1. Planee cada sprint de la implementación
  2. Haga reuniones diarias
  3. Al final de cada sprint revise los resultados
  4. Antes del siguiente sprint, haga una retrospectiva de lo que fue bien y lo que fue mal durante el sprint actual de implementación 

Se me ocurre que podríamos usar, para empezar, este algoritmo general de la implementación de Scrum:
Algoritmo general de la implementación de Scrum usando Scrum
Figura 1: Algoritmo general de la implementación de Scrum usando Scrum
Esta es una primerísima versión del algoritmo a “mano alzada”, escucho opiniones al respecto.
Otras Recomendaciones a tener en cuenta para asegurar el éxito en una implementación de Scrum
  • Todo el equipo debe tener un pensamiento Ágil.
  • Debe haber un alto grado de cohesión en el equipo, incluyendo a los usuarios.
  • Centrado en el usuario
  • Transparente, es decir, todos deben conocer el estado del proyecto en cualquier momento
  • Debe predominar la Cultura de la Calidad
  • Debe haber retroalimentación continua de todos los participantes
  • Manejo de riesgos conjunto
  • Se requiere disciplina
  • El equipo debe tener un experto en métodos ágiles en general y en Scrum en particular para hacer coaching y acompañamiento continuo.
  • Participe o, al menos, manténgase en contacto con otras personas que estén usando Scrum: la Comunidad Ágiles Colombia [9] es un buen ejemplo de ello; la de Ágiles Latinoamérica [10] también.

Finalmente, cuando tenga la suficiente experiencia y cuente con equipos maduros, quizás antes, atrévase a adicionar sus propios valores al Manifiesto Ágil y póngalos en práctica. Ya en la comunidad Ágiles estamos discutiendo algunos de esos nuevos valores y principios:
Experiencia efectiva sobre certificaciones retóricas
Innovación continua sobre mantenimiento de productos
Satisfacción del Cliente sobre margen de utilidad
Felicidad de las personas sobre inapetencia profesional
¿Se animan con otros? Pueden dejarme sus comentarios o ir al foro de la comunidad Ágiles Colombia y participar de la discusión. Lo encuentran en:
Referencias
Scrum – Lo Fundamental

Scrum Orgánico para Iniciantes

Vademescrum, Sección I: El Scrum Master 1

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

Planificación del Sprint: el primer paso para producir el máximo efecto

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

Chaos Report. Standish Group. www.standishgroup.com/


Ágiles Colombia. http://agilescolombia.org/

Ágiles Latinoamérica. http://www.agiles.org/

jueves, agosto 01, 2013

Nueva Versión de la Guía Oficial de Scrum (Ahora en español)

Portada de la Guía de Scrum 2013 en español
Portada de la Guía de Scrum 2013 en español
Actualización 2016/07/23. Este artículo ya está obsoleto. En julio de 2016 apareció una nueva revisión a la guía de Scrum. Todos los detalles aquí mismo en el Gazafatonario:
******************************************************************************
Actualización 20130902. Ya está disponible la versión en español de la Guía Definitiva de Scrum: las reglas del juego. La encuentran en la página oficial de la Guía (https://www.scrum.org/Scrum-Guides), en la sección correspondiente a "Spanish (July 2013)".
Cambios entre las Guías de Scrum de 2011 y 2013
La nueva versión de la guía Scrum acaba de ser publicada este 1 de agosto de2013 por sus autores. La encuentran en . Según Jeff y Ken, estos son los cambios que aparecen en la versión 2013:
1. Se adicionó una sección de Transparencia de Artefactos. Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se basan en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.
2. La planificación del Sprint es ahora un evento. Dos temas se abordan en esta: Qué puede hacerse en el Sprint y Cómo será hecho el trabajo seleccionado. Después de que el equipo de desarrollo aprovisiona los ítems del Backlog del Producto para el Sprint, el Equipo Scrum define una Meta del Sprint. La Meta del Sprint crea coherencia en el trabajo del Equipo de Desarrollo que podría no estar presente en iniciativas separadas son una meta común. Note la inclusión formal de una Meta de Sprint.
3. El Backlog del Producto es refinado en vez de preparado (groomed). Los ítems del Backlog del Producto refinado son transparentes, lo suficientemente entendidos y granulares como para servir de entrada en la Planificación del Sprint y para selección del Sprint. Los ítems del Backlog del Producto con esta transparencia se llaman “Listos”. Listo y Hecho son dos estados que refuerzan la transparencia.
4. Scrum prescribe sus eventos para crear regularidad y para minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son eventos en la forma de bloques de tiempo, de tal manera que cada evento tiene una duración máxima. Un Sprint, como evento contenedor, tiene una duración fija que no se puede acortar o alargar. Los eventos restantes pueden terminar cuando se logra el propósito del evento, asegurando que una cantidad apropiada de tiempo se consuma sin permitir desperdicios en el proceso.
5. Se refuerza la importancia del Scrum Diario como un evento de planificación. Muy a menudo se ve como un evento de estado. Cada día, el Equipo de Desarrollo debería entender cómo intenta trabajar como un equipo auto-organizado para alcanzar la Meta del Sprint y crear el Incremento previsto hacia el final del Sprint. La entrada a la reunión debería ser cómo el equipo está trabajando hacia el logro de la Meta del Sprint; la salida debería ser un plan nuevo o revisado que optimice los esfuerzos del equipo para cumplir con la Meta del Sprint. Para tal efecto, las tres preguntas se han reformulado para hacer más énfasis sobre el equipo que sobre el individuo:
   a. ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar la Meta del Sprint?
   b. ¿Qué voy a hacer hoy para ayudar al Equipo de Desarrollo a cumplir con la Meta del Sprint?
  c. ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo alcancemos la Meta del Sprint?
6. El concepto de valor se refuerza para usarse en la Revisión del Sprint. Durante la Revisión del Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que fue hecho en el Sprint. Con base en eso y en los cambios al Backlog del Producto durante el Sprint, los asistentes colaboran en las siguientes cosas que se pueden hacer para optimizar el valor.
[Hasta aquí el resumen de los cambios escrito por los autores de la guía]
Resumiendo, los cambios importantes se enfocan en 6 aspectos:
  1. Transparencia
  2. La Meta del Sprint
  3. Refinamiento y Listo
  4. Eventos en Bloques de Tiempo
  5. Reunión Diaria como evento de Planeación
  6. Valor
Algunas notas adicionales:
  • Refinement en vez Grooming,
  • Importante el énfasis de la Reunión Diaria como reunión de planeación en vez de reunión de status.
  • Las tres preguntas también superponen al equipo sobre los miembros del equipo, el todo es mayor que la suma de las partes.
  • El Valor del producto se eleva de categoría, importantísimo.
  • La Meta del Sprint, ¿cambia la definición de "hecho"? Yo creo que más bien la refuerza.
También hay un video donde los mismísimos creadores de Scrum y de la guía explican los cambios. Lo encuentran en: