La guía de Scrum en 1 página

He creado una guía muy resumida de Scrum, que pueda utilizarse para recordar los aspectos más importantes de Scrum al principi de su uso.

Como es una "chuleta", no esperéis un alto nivel de exactitud. Está lo más importante, pero sirve para iniciarse en Scrum. ¡ Espero que os sea útil !

scribd.com/doc/134880180/SCRUM-La-guia-de-1-pagina

La definición de hecho (2): ¿Evitemos el culto?

Discutiendo con compañeros de Agile-Spain.org sobre la Definición de hecho en Scrum (DoD para los amigos) surgieron puntos de duda y debate, como p.e.:

1. ¿Hasta que punto debe ser detallada la DoD?
2. ¿Se puede consensuar una DoD común o compatible entre varios equipos?
3. ¿Existe una variante técnica del Scrum of Scrums donde los "líderes técnicos" de los equipos puedan trabajar en consensuar DoD o intercambiar elementos de esta? ¿Se llamaría Retrospectiva de retrospectivas?
4. ¿Se puede convertir este ejercicio de consensuar DoD en una "maligna" Oficina de arquitectura, también conocida como "Torre de cristal"?

Durante esta discusión, el compañero Harald Messemer nos ha enviado un enlace muy interesante al post del The Cult of Done Manifesto. A pesar que me defino agilista pero fugitivo de las ortodoxias (aunque sean ágiles y guays) lo recomiendo. Contiene muchas verdades. :-)

SCRUM: La definición de hecho

Una visión superficial de Scrum puede dar a pensar que es una metodología sencilla y desestructurada, prácticamente lo mismo que mantener una lista de tareas en una pizarra. Es cierto que Scrum es un marco de trabajo sencillo, con 4 eventos, 3 roles y 2 artefactos estándar, pero a pesar de eso los proyectos suelen salir con un alto grado de calidad y uniformidad, tanto a nivel técnicos como de la documentación generada. ¿No parece contradictorio? Un aspecto importante a tener en cuenta es La Definición de hecho (Definition of Done).

¿Qué es la Definición de hecho?

La Definición de hecho es un acuerdo del equipo que contiene todas condiciones que deben cumplir los ítems del Product Backlog que se aceptan en el Sprint para considerarlos completados. Incluye los aspectos técnicos, de documentación, de pruebas y otros, de manera común para todo el equipo.

Cada equipo crea y mantiene su propia Definición de hecho, que suele evolucionar y refinarse conforme el equipo integra, perfecciona y automatiza sus prácticas de desarrollo. El momento habitual para revisar el cumplimiento de la Definición de hecho y refinar ésta, es la reunión de retrospectiva. Scrum no tiene auditorías, es el equipo quien autogestiona su calidad.

¿Cuál es el valor de la Definición de hecho?

El verdadero valor de la Definición de hecho es garantizar que el trabajo se realiza con un nivel de calidad uniforme, independientemente del miembro del equipo que participe. Es el equivalente al aseguramiento de la calidad en la gestión de proyectos tradicional.

La Definición de hecho aumentar su exigencia en todo momento según las posibilidades y capacidades del equipo. No tiene sentido marcar definiciones ambiciosas que no se pueden cumplir. Lo más importante es la uniformidad y la regularidad.

¿Cuál puede ser un ejemplo de Definición de hecho?

Un ejemplo sencillo e inventado de Definición de hecho es:

1. Cada historia de usuario hecha debe cumplir lo siguiente,
2. Diseño de pantallas (wireframe) actualizado en la wiki
3. Test unitario Junit integrado en montaje (Jenkins) y superado
4. Peer-review de las pruebas funcionales superado
5. Código fuente documentado
6. Wiki de diseño actualizada
7. Diseño explicado en la reunión técnica semanal

Como se puede comprobar, la sencillez de Scrum no tiene relación con la cantidad ni calidad de buenas prácticas de desarrollo que un equipo pueda realizar.

Curso Scrum Master en Barcelona: marzo y abril de 2013

Cynertia organiza periódicamente cursos de scrum master en Barcelona, en 2013 se quieren realizar cursos cada dos meses. En marzo se realizará los días 18, 20, 25 y 27 de 18h a 21h.

Se puede consultar más información sobre Scrum en www.scrum.cat.

Mobile World Congress 2013 Barcelona - Apps y tecnologías emergentes

El Mobile World Congress 2013 comenzó este lunes y, entre sus 70.000 visitantes estimados, hay un fantástico intercambio de ideas, oportunidades y colaboraciones. Esta es la parte más interesante del MWC, más allá de los nuevos terminales y las cifras de ingresos para la ciudad.

En nuestra web hemos recogido una lista de las innovaciones, tecnologías y apps emergentes más interesantes que hemos visto allí.

Editoriales y prensa: del papel al digital

Desde la aparición de Internet, el sector editorial de la prensa pasa por una crisis económica y de modelo de negocio creciente que se ha agravado de manera dramática con la situación económica actual. La brutal caída de ingresos por publicidad y el cambio de hábitos de los lectores han hecho insostenibles las finanzas de muchas empresas del sector, desde editoriales hasta la distribución y los puntos de venta (kioskos).

La evolución del sector a los soportes de Internet como la Web, las tabletas y otros dispositivos se ha hecho sin una estrategia clara y sostenible.
Cynertia ha analizado este contexto para un cliente y presenta el siguiente resumen:

1. El contexto actual: una transición de 360º
2. El Internet social y comercial: el model ZMOT
3. Estrategia empresarial, editoria y digital
4. Evolución tecnológica

Puede accederse al artículo Editoriales y prensa: del papel al digital en la web de Cynertia.

CMMI, Scrum, mitos y desinformación

Desde hace unos pocos años las metodologías ágiles han pasado a ocupar el “main stream”, probablemente aún no son mayoritarias en las empresas pero están casi omnipresentes en el “circuito blogero” de expertos y consultores.

Si tenemos en cuenta el Ciclo de Hype, que explica un patrón común al incorporar socialmente nuevas tecnologías (y metodologías) , vemos que es casi inevitable que se produzcan “burbujas” con expectativas exageradas a las que siguen desilusiones y una estabilización conseguida cuando la nueva tecnología ya no es una novedad pero la mayoría de sus usuarios obtienen de ésta una efectividad sostenible y económica. ¿Por qué se producten las burbujas? En el prólogo del excelente libro Workflow Modeling se da un conjunto de razones muy convincentes, centradas en la actividad de profesores, fabricantes y consultores que, usualmente llevados por sus propios intereses y excitación, alaban las posibilidades de las nuevas tecnologías, pero raramente hablan de las experiencias negativas.

Esto está pasando ahora mismo con Agile, especialmente con Scrum. De los muchos artículos que se publican continuamente, algunos son exageraciones alabando las maravillas de Scrum en aspectos como la menor documentación o su mayor comunicación y eficiencia. No es que Scrum no tenga muchas ventajas, pero no destacar igualmente los riesgos y malas experiencias no me parece inocente sinó tristemente interesado.

Una derivada de esta publicidad de Agile consiste en criticar las metodologías tradicionales y modelos de calidad como CMMI. Hay que uir de éstos para adoptar entusiastamente Scrum. Esto se dice sin explicar que Scrum funciona muy bien en ciertos contextos (p.e. desarrollo interno de producto) pero no se puede aplicar en otros (p.e. donde se requieren inversiones y decisiones iniciales fuertes, o existen transformaciones organizativas complejas).

Sin hacer ningún juicio de valor, un ejemplo es el artículo “Cómo pasar de CMMI y su incomunicación a la colaboración con Scrum, Agile y Lean”. Este blog me encanta, su autor es muy competente, pero en esta ocasión se debería explicar bien que se da un ejemplo de una implementación muy arriesgada de CMMI (una empresa que se certifica en nivel 3 en un plazo agresivo de 18 meses y que incorpora un outsourcing con muchas diferencias culturales). En primer lugar CMMI puede implementarse de manera ágil, como se explica en el libro Integrating CMMI and Agile Development, pero además un proyecto de outsourcing siempre tiene riesgos y desventajas que deben cuidarse mucho para que resulte compensador el menor coste de subcontratar partes de la producción en otro país. En 2010, otro estupendo blogger como Javier Garzás, hizo un muy buen artículo que analiza con detalle los conceptos y diferencias relacionados con las discusiones de la conveniencia de adoptar CMMI o Scrum.

Para finalizar, debo decir de mi experiencia de profesor en postgrados y másters, que veo como algunos alumnos más jóvenes tienen asumido que Scrum es la metodología aplicar y ni siquiera conocen lo que es el PMBOK. Es un error no conocer las diferentes opciones a la hora de solucionar un problema para aplicar la combinación de éstas adecuadas. Lo digo como consultor con experiencia aplicando diferentes metodologías en muchas empresas y estando certificado tanto en Scrum Master como PMP.