Algunas frases y reflexiones de cómo fallar en Scrum y Agile

Una de las frases que más me ha dado vueltas desde que comencé con Scrum es:

Scrum "es" simple "pero" difícil - Alan Cyment [6]

o la misma que encontré en los libros de Kleer (Introducción a la Agilidad y Scrum)

“Scrum is simple, doing Scrum is hard” - Jim York, CST.

Esto me ha llevado a mucho auto-estudio, a recibir, aprender y comprender el coaching que me dan en mi organización, a trabajar mucho en la mejora continua propia, del equipo y del proceso que tengo a cargo como Scrum Master. Con base en esto he recogido algunas de las frases, interpretaciones, síntesis de varios artículos y de la experiencia propia, que invitan o evitan fallar con Scrum.

Es importante anotar que una de las muchas causas por las cuales se falla en Scrum es porque el Framework no es prescriptivo, Scrum te da unos límites entre los cuales te puedes mover libremente, y en ese movernos libremente podemos caer vicios que atentan contra el mismo marco de trabajo y sus resultados.

Cada cual seleccione y use las reflexione sobre lo que más le sirva.

Y si tiene más frases, tips y desea compartirlos, bienvenidos sean, acá se publicarán y referenciarán.

Respecto a la organización

• [Falla / Fail] Falta de transparencia - 1: cuando no somos capaces de decir, lo siento no podré ejecutar este proyecto ágil a falta de:
• prácticas de ingeniería
• comunicación con un gran ancho de banda
• un cliente completamente involucrado y comprometido [1]. 
• [Falla / Fail] Falta de transparencia - 2: Cuando no somos capaces de decir, lo siento este proyecto por sus características es mejor que no se realice con Scrum [7]. 
• [Falla / Fail] Imposición del modelo: cuando es un modelo impuesto [2] y no acordado, divulgado y acompañado (correcto coaching) a la organización y al equipo que lo va a ejecutar.[7].
• [Falla / Fail] Grandes proyectos, grandes equipos: cree equipos grandes (olvídese de lo sugerido de 7 + /-  2 ) e invítelos a todos a todas las reuniones en especial al daily [2] de forma que todos hablen y estos se extiendan innecesariamente y nadie le ponga atención a nadie y el daily no les para sirva para sincronizarse. [7]
• [Falla / Fail] Cree incentivos individuales en vez de estímulos para el equipo [2]

Respecto a la proceso 

• [Falla / Fail] Crea en al softwarepredicación y olvide que hacer software es complejo, lo ha sido y lo será[3]
• [Falla / Fail] Creer en Scrum como en "LA FUERZA" [3]
• [Éxito / Sucess] Comprender de que depende el éxito de ser Ágil: Ser ágil depende de:
• Darle importancia a las personas
• tener equipos multifuncionales
• comunicación
• entregar valor
• cambio de planes para aprovechar oportunidades
• equipos en el mismo espacio entre otros.[1].
• inspección y adaptación [7]
• [Falla / Fail] Microseguimiento: Ejemplo digale a su equipo que hacer durante el daily [2] y durante todo el sprint de forma que no permita el empoderamiento y el éxito o fracaso sea completamente suyo como Scrum Master [7].
• [Falla / Fail] Síndrome de la bala de plata: cuando se cree que Scrum es una bala de plata que resolverá todos los problemas. Comprenda los equipos son autogestionados, pero necesitan de un liderazgo al servicio de la mejora del equipo y de un Product Owner que tenga una visión clara que guíe e inspire al equipo[2]
• [Falla / Fail] Mala interpretación de la autogestión Cuando deje al equipo solo sin coach, sin Scrum Master[2]
• [Falla / Fail] No se cumple lo comprometido en el Sprint (sprint tras sprint)[2].: que pase una sola vez, vaya y vuelva, dos, bueno es comprensible, pero que pase sprint tras sprint y nadie tome medidas para lograr cumplir lo comprometido, esto hará fracasar scrum Unas recomendaciones en este caso son:
• comprométase con menos, o
• evalúe cual es el impedimento técnico que tiene al equipo fallando continuamente, o 
• evalúe cual es el impedimento de relaciones interpersonales que los tiene fallando y trabaje en removerlo. 
• busque si la falla está en las historias de usuario con criterios de aceptación ambiguos o cambiantes, 
• o se están permitiendo cambiando las historias durante el sprint
• busque, busque, indague, escuche al PO, escuche al equipo y halle la causa.[7]
• [Falla / Fail] No se identifican mejoras en el proceso cada sprint: El equipo scrum ( PO, SM y Team Developer) siempre tendrán algo que intentar o mejorar al siguiente sprint, ya sea desde el punto de vista humano o técnico. No mejorar, cada sprint, o incumplir en la implementación de las mejoras ayudarán a socavar el proyecto ejecutado bajo scrum [7].[2]
• [Falla / Fail] Altere frecuente y caballerosamente el sprint backlog comprometido de forma que el P.O. no sepa nunca que le será entregado. [2]
• [Falla / Fail] No cree equipos multifuncionales: Cree varios equipos por capas o por funciones de forma que cada equipo tenga que comunicarse ardua e innecesariamente con el otro. Ej: un equipo scrum de analistas, otro equipo de testers, otro equpo scrum de desarrollo, otro para la capa de presentación, etc, etc. y etc.[2]
• [Falla / Fail] Adaptación temprana de Scrum : Ojo. no adapte scrum a la primera, siga las reglas de Scrum al menos 5 ó 6 sprints y luego de aprender y fallar siguiendo las reglas, aventúrese muy conscientemente a modificarlo.[7] [2]. 
• [Falla / Fail] Personalice y adopte prácticas sin tener el completo entendimiento de su porqué y para qué.[2] 
• [Falla / Fail] Adopte scrum sin entender el por qué y el para qué de cada elemento del framework.[7] 
• [Falla / Fail] Extienda el sprint hasta que cumpla lo pactado. Esto hace que usted no se comprometa con mejorar pues siempre esta cumpliendo y nunca falla y busca las razones que están haciendo que sus sprints se alarguen.[7] 
• [Éxito / Sucess] Guiar al PO de forma que siempre se cumpla el pareto ( se implemente el 20% de funcionalidad que da 80% de valor al negocio). Un buen SM y Team Developer ayudará al PO a tener un backlog priorizado impidiendo que el equipo "invierta/gaste" tiempo en funcionalidades innecesarias o no críticas para el negocio. Es de aclarar que esta responsabilidad del Backlog priorizado es del PO, pero el SM y el Equipo ayudan a que no se pierda el foco. Esto se logra con una buena visión compartida y a medida que el Equipo se siente en confianza con el PO.[7]
• [Falla / Fail] Sprints de más de 1 mes: Es casi un estándar trabajar sprint de 2 a lo máximo 3 semanas, pensar en un mes es demasiado tiempo y va en contravía del lema "si hemos de fallar que sea rápido". Un mes es mucho tiempo, pasan muchas cosas y la capacidad de inspección y adaptación es más baja[7]

Respecto a los roles

• [Falla / Fail] Creer que la Certificación de Scrum Master (SM) resuelve todos los problemas: Scrum no se domina con dos días de curso y el examen de certificación de Scrum Master.[1]. Es necesario estudiar, fallar rápido, adaptarse, y reconocer que estamos en continuo aprendizaje y mejora. Siga las reglas al pie de la letra de las biblias de Scrum y luego adapte, antes no.[7]
• [Falla / Fail] Desconfíe del equipo[2], no le permita sentirse responsable del producto a entregar.[7]
• [Falla / Fail] El PO (Product Owner) no comunica la visión al equipo [2].
• [Falla / Fail] El PO no presta atención al progreso en cada iteración y no evalúa objetivamente el valor alcanzado [2].
• [Falla / Fail] El PO no tiene un documento donde esta planeado el producto y lo reemplaza por algo que tan solo esta en la cabeza de él [2]. Es necesario un plan de releases, saber hacia donde van las siguientes versiones del producto, para esto sirve mucho el user story mapping.[7].
• [Falla / Fail] El rol de PO y el SM son ejecutados por la misma persona[2].
• [Falla / Fail] Una persona tiene más de dos roles. Esto a lo sumo debe ocurrir que el rol de SM lo asuma un desarrollador, y esto es cuando un equipo es demasiado maduro y realmente es autogestionado [7].
• [Falla / Fail] El SM no frena al PO, y permite que desenfoque a cualquier miembro del equipo deliberadamente y constantemente.[7].
• [Falla / Fail] El PO no este disponible para resolver las dudas del equipo.[7].
• [Falla / Fail] El equipo se "jure" autogestionado sin serlo. He visto equipos que juran y perjuran que por el hecho de entender scrum, no necesitan de SM. Esto es una falla en un inicio de adopción de Scrum, el Scrum Master no es un rol que se puede desechar, ni esta inventado para dar trabajo a los que no encajan en el equipo. Un equipo será autogestionado cuando este inspirado en la mejora continua, su liderazgo técnico y calidad humana de forma que  logre niveles altos de competitividad y rentabilidad. Estos altos estándares con seguridad eso no se logran en las primeras ejecuciones del framework. [7].
• [Falla / Fail] Creer que el equipo de Scrum solo es el SM y el Team Developer.  Falso, el equipo de Scrum es el PO, el SM y el Team developer, todos ellos son conocidos como roles cerdo, o comprometidos con el producto y proyecto.[7]

Respecto a la ingeniería

• [Falla / Fail] Tener deuda técnica: La deuda técnica hace que las pruebas se demoren demasiado tiempo y no se cumplan los compromisos.[1].
• [Falla / Fail] Tener deuda técnica: La deuda técnica disminuirá la velocidad en el mediano plazo y afectará el soporte y mantenimiento del producto (además que hablará muy mal del equipo que implemento el producto inicial).[7].
• [Falla / Fail] No tener prácticas técnicas: Sin prácticas técnicas de ingeniería la calidad disminuye asintóticamente con el tiempo. [1]
• [Éxito / Sucess] Tener prácticas técnicas: Las prácticas técnicas se pagan a si mismas.[1]
• [Falla / Fail] Crea que lo más importante es la cantidad de funcionalidades y de trabajo realizado, dejando de lado el valor de negocio, el riesgo y la creación de conocimiento [2]
• [Éxito / Sucess]  "Pero si trabajas en un proyecto medio o grande, si quieres asegurarte el terminar vivo, necesitas (entre otros muchos, la siguiente es solo un ejemplo): 
• Control de versiones y gestión de la configuración.
• Gestión de riesgos.
• Asegurar la calidad del producto software.
• Pruebas: carga, unitarias, integración, etc. Que no te van a funcionar si no tienes…
• Una buena arquitectura y un buen diseño.
• Trazabilidad, control de incidencias y problemas, etc."[3]

Es posible encontrar más fallas en las ceremonias de scrum, los roles y los artefactos, pero estos son los que más he encontrado en la literatura hasta ahora leída y los que he vivido como Scrum Master y como Coach de equipos de Scrum.

Queda abierto el debate, como siempre....

Bienvenida la retroalimentación

-------------------------------------
JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática - Universidad Eafit

ScrumAlliance Certified Scrum Master member 000260715

Fuentes:

• [1] Shore, James. The Decline and Fall of Agile. http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html
• [2] Conh, Mike. How To Fail With Agile: Twenty Tips to Help You Avoid Success. http://www.mountaingoatsoftware.com/articles/how-to-fail-with-agile 
• [3] Garzas, Javer. Lo siento mucho, pero sólo con Scrum… no vas a terminar un desarrollo software con éxito. http://www.javiergarzas.com/2012/07/scrum-solo.html 
• [4]Brad, Dave and Swanson,Sharrock. Agile Transformation Failure Modes and Success Modes. http://www.agile42.com/en/blog/2013/06/06/agile-transformation-failure-success/ 
• [5] Gärtner, Markus. Scrum Norris. http://www.shino.de/2010/02/20/scrum-norris/ | http://www.genbetadev.com/metodologias-de-programacion/scrum-norris-es-scrummaster-sin-haber-sido-certificado
• [6] Cyment, Alan. El espíritu de Scrum,  El arte de amar los lunes. V0.2 - http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum
• [7] Mi opinión y experiencia personal.

Características de una buena historia de usuario

Nivel del post: Básico

Este es mi lista de verificación al momento de revisar una historia de usuario.

Luego de hacer la CCC (Card, Confirmation, Conversation), definitivamente el criterio más importante que uso es cumplir INVEST:

• Independiente: No requiere de otra
• Negociable: Se puede reemplazar por otra de diferentes prioridad
• Valor: Que sea necesaria y de valor para el proyecto
• Estimable: Que el equipo se sienta tranquilo y seguro estimandola.
• Small (pequeñas): que no sean grande, funcionalidades pequeñas
• Testeable (verificable): que se le puedan realizar pruebas.

Yo añadiría, aclararía y uso los siguientes:

• que su tamaño no supere los 3 a 4 días de una persona enfocada desarrollándola. (Asociado al criterio de Small). Obvio hay excepciones pero al máximo trato que durante un planning no se supere este criterio.
• Razón: He observado que historias mas grandes quedan mal estimadas por mas buena intención que tenga el equipo de desarrollo, el equipo se siente seguro con este tamaño de historia. Determine cual es el rango para su equipo.
• que su implementación toque todas las capas o que el resultado de su implementación tenga sentido para el Product Owner o al Cliente. Me explico, en caso de hacer desarrollos asociados exclusivamente a la Base de Datos o a temas complejos por ejemplo que no logran verse reflejados facilmente por el product owner, sugiero crear historias técnicas en las cuales se le explique al Product Owner el valor asociado a las mismas en el proyecto. (Asociado al criterio de Valor).
• Razón: Evito al máximo historias técnicas pues son de difícil justificación - aunque no imposible, pues si son necesarias se hacen -, pero la razón principal es que este tipo de historias habilita el crecimiento orgánico.
• que tenga a lo sumo entre 3 y 7 criterios de aceptación.(Asociado a los criterios de Small, Testeable y Estimable).
• Razón: Más de 7 criterios, se puede  dividir la historia, menos de 3 se puede agrupar con otra.
• que se pueda dividir cuando sea muy grande (Asociado a los criterios de Small, Testeable y Estimable).
• Razón: La gran mayoría de las historias grandes se pueden dividir, esto permite más maniobrabilidad al equipo al momento de implementación.
• preguntar lo más que se pueda sobre la necesidad de la historia de usuario  (Asociado al criterio de Valor). 
• Razón: Después de varios sprints y coach que me han hecho, he aprendido a preguntar para ciertas historias que percibo innecesarias (validaciones de negocio excesivas, autocompletar recargados, etc):
•  ¿ok es de valor, pero es necesaria?
• ¿cuántas personas la usarán?
• ¿cuántas veces la usarán en el año?
• ¿es realmente útil? 
• ¿prefieres al equipo trabajando en esa "validación xxxx "-por poner un ejemplo-  que en esta otra historia de usuario que agrega más valor al negocio?
• ¿podemos postergar esto para el final y hacer otra cosa más urgente sobre la que tenemos clara la necesidad de implementación? (principio de LEAN - aplazar las decisiones, ver más aquí)

Respecto al Sprint

• Busco siempre trabajar con  al menos hayan 6 historias de usuario por sprint. 
• Razón: De esta forma el equipo tiene en que trabajar, con pocas historias de usuario se estarán obstaculizando entre sí.
• Trabajo junto con el Product Owner para que existan al menos otras 6 historias adicionales 
• Razón: Tener backlog para posibles reemplazos y/o negociaciones.
• Trabajo junto con el Product Owner para que se tengan definidos al menos historias de usuario al detalle para los próximos 2 Sprints (completamente elaboradas, cumpliendo INVEST) y un 3er sprint con Historias de Usuario  sin mucho detalle.
• Razón: Tener claro hacia donde va el producto.
• La evolución del producto esta guiada por el User Story Mapping (ver más aquí)el cual tiene los objetivos de cada Release y las historias épicas que contendrá.
• Razón: Tener claro hacia donde va el producto y saber cuan cerca estamos de hacer una liberación o release.

Si estás interesado en ver  recomendaciones para el Product Backlog ver - http://www.pmoinformatica.com/2013/07/11-reglas-product-backlog-scrum.html



-------------------------------------
JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática - Universidad Eafit

ScrumAlliance Certified Scrum Master member 000260715

Jorge Valderrama -Ingeniero Senior de DDB Tribal Londres - Hablando de Metodologías Ágiles

Les recomiendo esta excelente entrevista realizada por César Torres Gerente Comercial de Ceiba Software - www.ceiba.co a Jorge Valderrama ( @jvalde ) , Ingeniero Senior de DDB Tribal Londres desde hace 5 años. Entrevista en la que cuenta su experiencia en Prácticas Ágiles, las prácticas que no pueden faltar en un equipo, las prácticas más complejas de adoptar y la Madurez de la industria inglesa en términos de contratar con alcance abierto.

La Magia de las Historias de Usuario / Desarrollo Conducido por Historias de Usuario

Nivel del post: Intermedio.


Cuando uno lee sobre RUP (Rational Unified Process), en una de sus definiciones dice que es un desarrollo conducido por Casos de Uso, y hoy quiero después de convivir por más de 6 meses con las Historias de Usuario, contar cómo realmente conducen el desarrollo del software mucho mejor que los casos de uso.

Introduciéndonos: El Formato

Las HU (Historias de Usuario) de usuario tienen un formato libre, y podrían expresarse como una necesidad funcional, por ejemplo:

• consultar las películas de cine disponibles en un teatro cerca a mi casa

 O como ya es popular se pueden escribir con el siguiente formato (template):

• yo como <rol> quiero/deseo/necesito  <funcionalidad> para <beneficio de negocio>

De esta forma nuestro ejemplo quedaría:

• yo como cliente deseo saber cuales son las películas disponibles en un teatro cerca a mí casa para poder elegir que película ir a ver el día de hoy

Este formato tiene las consabidas ventajas de:

• saber quien va a usar la funcionalidad y
• comprender el beneficio del negocio de forma que el equipo pueda llegar a ese beneficio por distintos caminos

Y dónde esta la magia...

Aunque el objetivo de las historias es habilitar la comunicación entre el Cliente y Equipo (para el caso de Scrum:  Product Owner PO / Dueño del Producto y el Equipo de Desarrollo), dando cumplimiento al principios del manifiesto ágil:

• Personas e interacciones sobre procesos y herramientas (ver más sobre el manifiesto ágil)

Una definición tan simple obliga al equipo a estar en comunicación con el Product Owner (PO), de la siguiente manera:

• En el Planning (ver más sobre scrum), el equipo pregunta al PO el detalle de lo que quiere y lo que espera.
• En el Planning, el equipo con base en lo conversado estima lo que va a construir en presencia del PO.
• Durante el Sprint, el equipo clarifica con el PO detalles menores olvidados.

Pero de todo esto lo que me tiene maravillado el día radica en los criterios de aceptación.

Los criterios de aceptación nos permiten reconocer cuando la historia esta HECHA / TERMINADA / REALIZADA (o criterio de DONE de Scrum), de esta forma el equipo de desarrollo no tiene pierde, pues todo su desarrollo esta orientado al resultado esperado, o mejor, orientado a los casos de prueba que a la especificación.

Esto es una ganancia enorme!!! (para quienes hemos padecido el desarrollo en cascada o RUP basado en casos de uso) la marcha de la muerte - o Desarrollo Orientado a la Frustración DOF - es la siguiente:

• Analista: El casos de uso es especificado con sus  escenarios de uso (flujo básico, alternos y de excepción) -que a ratos solo los entiende el analista/desarrollador que los escribió -
•  Desarrollador: Para cumplir con el caso de uso el desarrollador construye lo especificado en los escenarios de uso,  y valida contra unos escenarios de prueba que "el cree" necesarios para cumplir la funcionalidad.
• Tester:  luego el tester mucho mas hábil en encontrar los errores (o enfocado en esa única tarea) construye n-mil casos de prueba a un solo escenario de uso (ejemplo flujo alterno 3 )  hasta que por fin le encontraba la caída al escenario del caso de uso y lo devolvía a desarrollo con un incidente o hallazgo (forma diplomática y "very polite" de decir bug), 
• Desarrollador:  el desarrollador dice  "#$%#"% ese escenario YO NO lo considere, no estaba escrito en ninguna parte,  me demoraré un poco más en completar este caso de uso y entregarlo para pruebas"
• Tester :  a lo que el tester responde "yo te entiendo, pero caso de prueba fallido es una forma de confirmar esa funcionalidad" 
• Desarrollador : remata contestando el desarrollador  "tienes razón, nos vemos en X días cuando termine el desarrollo y marque como cerrada tu anotación en el Bugtracker"..

 y todos seguiremos tratando de dar lo mejor en un contexto que no lo permite, y que por lo general termina en una serie de enemistades:

• Desarrolladores - Testers: - pues los desarrolladores comienzan a ver con malos ojos a los testers, por más claro que tengan el proceso de pruebas como una actividad de desarrollo.
• Gerente de proyectos - Equipo: pues piensa "como es que se continúan atrasando en el cronograma, como es que no identificaron ese escenario, pensé que tenía un equipo profesional"
• Cliente - Proveedor de desarrollo: pues el cliente piensa "como es que no son capaces de cumplir con lo especificado, casi que no completan esos casos de uso y miren todos los errores que tienen"

En cambio, en las historias de usuario ya sabemos como nos van a probar la historia y como se considerara TERMINADA.

Entonces para la historia de usuario que escribimos, los criterios de aceptación serán:

• que me liste de a 10,20, ó 50 películas con su respectiva imagen y una corta descripción
• que aparezca la calificación del público a la película
• que aparezca la crítica a la película
• que aparezca la distancia del cine a mi ubicación actual (tal vez esta pueda ser otra HU)

Aunque estos criterios de aceptación  son mejor expresados en el formato / template  BDD, de la siguiente manera:

En inglés, 

• GIVEN 
• WHEN
• THEN 

o en español

• DADO
• CUANDO
• ENTONCES

(ver más  de BDD en:

• http://adrianmoya.com/2012/08/que-hay-en-una-historia/ ( o su original en inglés http://dannorth.net/whats-in-a-story/ .
• http://dannorth.net/introducing-bdd/  )

Este template permite la automatización de pruebas funcionales y obvio la mejor escritura de criterios de aceptación, veamos:

• Escenario 1: listar de a 10 películas
• DADO que me encuentro en cualquier sección de la aplicación
• CUANDO selecciono ver listado de películas
• -- Y antes no se ha seleccionado una cantidad de lista diferente 
• ENTONCES el sistema me listará las 10 películas 
• -- Y estás aparecerán en orden de estreno con su respectiva imagen y una descripción corta 

Y de esta misma forma se seguirían escribiendo los otros criterios / escenarios de aceptación...

Aun así ustedes me dirán, pero JORGEEEEE y 

¿la interfaz gráfica y la arquitectura?

R/ Pues tanto para la interfaz como para la arquitectura se definen unos lineamientos básicos para la aplicación antes de comenzar y estos irán evolucionando conforme pasa el tiempo. Si hay que definir algo de la interfaz gráfica se hará un boceto y se validará con el Product Owner durante el Sprint.

¿ y si queda faltando algo?
R/ Fácil, estamos bajo el principio de transparencia,

•  el equipo en el Planning preguntó y
• el Product Owner contestó, y 
• con base en esto se estimaron unos PUNTOS DE HISTORIA (USER STORY POINTS ), 
• se realizó el tasking de lo que se iba a construir (identificación de las tareas para construir las historias de usuario), y
• se estableció el compromiso de las historias a construir en el Sprint.

Por lo tanto, si quedó faltando algún escenario por contemplar,  SIMPLE:

 "ENTRA COMO UNA HISTORIA DE USUARIO NUEVA PARA EL PRODUCT BACKLOG"

(no les parece esto una maravilla, a mí sí)

Esta historia debe ser priorizada, además sino se identificó y es muy importante, podemos contestar: "tranquilo Product Owner en el próximo Sprint lo incluimos que máximo lo comenzamos en 2 semanas".

Y dónde quedan los bugs / incidencias / hallazgos o como le queramos decir...

Wow, este tema con la pregunta anterior era uno de los objetivos a los que tenia con este post, la respuesta es otro abracadaba, "DESAPARECEN o TIENDEN A CERO" (nada por aquí, nada por acá como diría Harry Houdini).

La razón es muy simple, si desarrollamos orientados a casos de prueba una historia de usuario no estará finalizada hasta que cumpla todos sus escenarios y cumpla todos los criterios de DONE,estos son;

• cumplir los aspectos funcionales, 
• cumplir con los criterios de aceptación y de pruebas (ya sean estas manuales o automatizadas).
• encontrarse desplegado y funcionando en un ambiente determinado, llámese ambiente de pruebas, pre-producción, laboratorio, producción -en algunos casos , etc.

Por lo tanto, si una historia de usuario esta DONE significa que:

• fue probada y certificada por el equipo
• fue aceptada por el Producto Owner

Si llegase a existir un "BUG", con plena seguridad afirmo que fue un escenario no identificado, y por lo tanto una historia nueva debe implementarse.

De esta forma las historias de usuario REALMENTE SI CONDUCEN Y DELIMITAN EL DESARROLLO, y see convierten en un punto de encuentro y de sincronización de imagen mental (entre Product Owner y Equipo) de  lo que se desea construir (ni una linea de código adicional más - pues no es necesaria - , ni una menos - pues no cumpliríamos el criterio de DONE - )  y de lo que no se desea construir, pues respecto a esto último, no hay lío, pues nadie lo identificó, o no era necesario en el momento.

Adicionalmente, los costos por garantía  también desaparecen o tienden a cero pues no habrán sorpresas de escenarios no cubiertos en producción.

En Resumen

Las grandes ventajas que he visto son:

• Estamos orientados al resultado y no a la especificación
• No quedan escenarios sin probar, pues estos son explicitados en los criterios de aceptación, situación que si sucede con los casos de uso..
• Lo que esta por fuera de los criterios de aceptación simplemente se convierte en una nueva historia de usuario y se le asignara prioridad
• Cuando una historia de usuario esta DONE!! (CRITERIO DE HECHO, o REALIZADO) y con sus pruebas funcionales automatizadas, se puede dar por olvidada la historia de usuario, en el sentido que no nos tenemos que volver a preocupar de ella pues el desarrollo orientado a casos de prueba garantizará que no quedaron escenarios por cubrir. 

Puedo afirmar con tranquilidad

MIS DÍAS DE DEFENDER LOS CASOS DE USO HAN TERMINADO.

LARGA VIDA A LAS HISTORIAS DE USUARIO

--
Hasta acá mi reflexión,
quedo atento a sus observaciones y comentarios

JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática

ScrumAlliance Certified Scrum Master member 000260715

User Story Dojo - ( User Story Map y User Stories)

Nivel del post: Medio

Lugar: www.ceiba.co - Ceiba Softaware House. (Empresa donde trabajo y me desempeño como Scrum Master y Scrum Coach)
Ciudad: Medellín, Colombia


Temas trabajados en el dojo.

• Desarrollo Orgánico
• Cómo construir un User Story Mapping * (técnica de Jeff Patton - http://www.agileproductdesign.com/presentations/user_story_mapping/index.html o en español en  http://www.caminoagil.com/2013/02/visual-story-mapping-aplicado.html)
• Cómo elaborar Historias de Usuario - User Stories (taller. Criterio CCC e INVEST)

-
-

o acceder a directamente a  youtube

-
-

*El nombre correcto es User Story Mapping dado por Jeff Patton (en algunos medios se emplea Visual Story Mapping / Visual Story Map)

Por dónde comenzar a leer y a estudiar de Scrum

Nivel del post: Básico.



Hola a todos:

A continuación presento el listado, y en orden de lo que considero deben ser las lecturas sobre Scrum para entender más evolutivamente el framework.

1. Scrum Guide. Por Ken Schwaber y Jeff Sutherland (creadores de scrum). http://scrumguides.org/
2. El espíritu de Scrum. Por Alan Cyment -http://es.scribd.com/doc/84799747/El-espiritu-de-Scrum 
3. Un mejor Scrum. Escrito por el Coach y Entrenador Certificado de Scrum Peter Hundermark.Traducción por Alan Cyment, Entrenador Certificado de Scrum https://www.agile42.com/documents/25/Un-mejor-Scrum-2.pdf
4. Scrum y XP desde las trincheras. Por Henrik Kniberg. http://www.proyectalis.com/wp-content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
5. [!Nuevo!] Kanban y Scrum – obteniendo lo mejor de ambos. Por Henrik Kniberg & Mattias Skarin. http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf

En otro post http://ing-sw.blogspot.com/2013/02/por-donde-empezar-leer-de-scrum-y-de.html , comparto donde seguir trabajando y leyendo sobre agilismo.

Saludos y espero les sirva este camino de inicio en el entendimiento de SCRUM.

Jorge Abad

Nota: Si cambia algún link les pido me lo hagan saber.

---

Mi evolución sobre las retrospectivas en Scrum

Desde hace un tiempo he venido actualizándome sobre las retrospectivas en Scrum (la verdad no he leído y estudiado todo lo que he querido) pero he realizado varias con mi equipo, y he particpado en otras como coach de la organización en la que estoy.

Al inicio, comencé con el típico (propuesto en http://www.mountaingoatsoftware.com en su introducción a Scrum):

• Qué hicimos bien
• Qué hicimos mal
• Y qué debemos mejorar

Pero note que nos estábamos quedando quietos, las tres preguntas anteriores solo son un diagnóstico y te proporcionan una foto de como te fue el el Sprint que acabas de terminar pero no te lleva a la acción.

Luego entonces decidi madurarla un poco y agregar

• Qué se debe mantener
• Cómo hacerlo mejor

(esta versión es mas coherente con un ciclo de mejora PHVA de mejora continua)

Pensando en:

•  una retroalimentación al proceso 
• y una mejora del mismo, 
• manteniendo aquello que nos había generado valor.

Luego, al leer a Alan Cyment me animé a cambiar las preguntas, adicionando los aspectos de Productividad, Calidad y Felicidad, generando una matriz que involucraba los aspectos anteriores

Que como pueden deducir me llevaba de nuevo a un diagnóstico pero me permitía ver aspectos interesantes del equipo.

Luego la maduré a la versión que utilizo actualmente, que presento a continuación: 

(esta actividad toma aproximadamente 40 a 50 minuntos)

Aclaro, que sigo visionando en la parte superior los aspectos de productividad, calidad y en especial felicidad para comprender como mis equipos quieren cambiar y mejorar, y en especial ser más felices, para estar acordes con el principio del manifiesto "Los proyectos se desarrollan en torno a individuos motivados..." Y si mi equipo esta motivado y feliz pues al proyecto, y a todos nos irá mejor y será más fácil y natural la mejora.

Pronto intentaré otras técnicas:

• Dinámica de Retrospectiva: 3 caras y 4 capas (mad/glad/sad/  vs Filosofía, metodología, técnicas y ecosistema - http://thomaswallet.blogspot.com/2011/12/dinamica-de-retrospectiva-3-caras-y-4.html#.UXYWoqLEK3H
• Mad/Sad/Glad vs Keep/Fix/Try
• Estrella de mar - star fish - http://www.proyectosagiles.org/retrospectiva-estrella-mar-starfish-retrospective-scrum
• Start doing: comenzar a hacer
• More of: mas de lo anterior
• Keep doing - Seguir haciendo /mantener
• Less of: menos de
• Stop doing: dejar de hacer

Y les contaré como me fue.

Seguiremos avanzando en este aspecto de las retrospectivas, pero lo que si tengo claro es:

• De una retrospectiva se debe avanzar del diagnóstico (del qué) a la acción (al cómo vamos a mejorar).
• El equipo guiado por el Scrum Master debe mirar como avanzar y mejorar su proceso
• Las mejoras identificadas deben ser igualmente priorizadas e identificadas a realzar al corto, mediano y largo plazo. (muchas veces no podemos mejorar todo de una vez, sino orgánicamente de la misma hacemos con el producto) .

Hasta la próxima.

Quedo atento a sus comentarios, observaciones, mejoras y/o sugerencias.