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.

Introducción a DevOps - ¿El siguiente paso a Scrum?

El desarrollo de software con Scrum, que comenzó con algunos equipos pioneros hace unos pocos años, se ha convertido en una tendencia creciente sinó ya del "mainstream". Es actualmente el modelo de desarrollo más extendido, aunque dista aún bastante de ser mayoritario y que se realice de manera madura allá donde se introduce.

"Cada empresa es un mundo", pero de la misma manera que Scrum se ha hecho enormemente popular, en general aún no ha alcanzado una integración suficientemente buena con las operaciones (explotación, producción...) fuera de las start-ups y los equipos muy pequeños.

Por otra parte, durante la década del 2000 se expandieron movimientos y frameworks como Enterprise Systems Management (ESM) e ITIL v2. Estos movimientos, que han aportado notables mejoras a la estabilidad de producción, han estado centrados principalmente en organizaciones grandes y proveedores IT como IBM, HP o CA.

Una visión alternativa, originada en la "pesadez" y la pobre adaptación a las empresas más pequeñas de estas aproximaciones, tomo forma en el concepto de DevOps, acuñado por Patrick Debois en 2009. Desde entonces se han ido sucediendo eventos (como los DevOpsDays) y webs dedicadas a la materia.

En resumen, actualmente la visión generalizada de los departamentos de IT según los grupos de desarrollo de software y de explotación/sistemas puede ser:

• Desarrollo: quiero construir y publicar lo que me pide el negocio con agilidad.
• Explotación: me miden por el coste y disponibilidad. No quiero riesgos.

El resultado muchas veces consiste en despliegues grandes y espaciados en el tiempo, con una pobre comunicación conjunta, que suele producir errores, retrabajo y más coste que haberlo hecho de manera conjunta desde el principio.

DevOps.org

El enfoque de DevOps comparte la agilidad de Scrum para mejorar la comunicación entre cliente (el negocio) y el proveedor (desarrolladores), fomentando la confianza, la compartición del plan y del avance en el trabajo, y tomando un feedback frecuente. Al igual que el Scrum Master y el Product Owner actúan como los responsables de la coordinación entre negocio y desarrollo, el DevOps engineer se encarga de planificar y seguir la coordinación entre desarrollo y operaciones, aunque sin tener necesariamente mando sobre éstos.

LMC Software

El rol principal en DevOps es Ingeniero de operaciones, similar al Chief Engineer el Toyota Production System. Consiste en coordinar a los equipos de desarrollo y a los administradores, aunque no tiene autoridad final sobre los equipos.

Attunity.com

Aunque DevOps tiene una fuerte relación con las herramientas que automatizan las operaciones (p.e. Jenkins, BuildForge, Puppet Labs, etc.) el aspecto fundamental son los procesos integrados entre desarollo y producción. No se trata de "hacerlo igual de mal, pero más rápido".

En España todavía no han habido eventos importantes sobre DevOps, si bien en Madrid hay un grupo de interés con bastante actividad. 

En próximos posts seguiré escribiendo sobre DevOps, y ¡estaré encantado de contactar con otras personas que estén interesadas sobre esta materia!

Chrome va lento con Flash

Un post off-topic sobre Google Chrome.

Desde las últimas semanas (agosto 2012) vi que Chrome va muy lento en aplicaciones con Flash (p.e. Gmail), convirtiéndose en una tortura.

El problema es uno de los plugins de Flash (PepperFlash) que falla. Para desactivarlo, 

1. Pegad en la URL:  chrome://plugins/
2. Localizar el plugin de flash (suele ser el 1º)
3. Click en "+ Details"
4. Desactivar PepperFlash y reiniar.
5. Voilà!

http://www.monkeycoder.co.nz/Community/posts.php?topic=3384