miércoles, abril 22, 2015

¿Y por qué dudamos de la auto-organización de los equipos?

Hola a todos

Hay algo que he notado que es recurrente cuando he dictado entrenamientos o charlas sobre Scrum y es en específico el rol del TEAM /DEVELOPER TEAM / EQUIPO DE DESARROLLO / EL EQUIPO, la primera pregunta que surge por alguno de los presentes es:

¿y cómo logran que se vuelvan auto-organizados?

Es como si dudáramos de nuestra capacidad de

  • jugar en equipo
  • jugar fútbol, baloncesto, rugby, voleibol
  • armar un paseo
  • realizar un asado
  • preparar entre varios una cena
  • jugar un juego de mesa
  • entre otros.


Pero para ser franco, yo siento esa pregunta hecha desde el temor, desde la desconfianza, desde un lugar de la memoria o experiencia  donde a alguien (incluso el mism@ que lanzó la pregunta) que le encomendaron algo no lo entregó a tiempo y para acabar de ajustar todos se dieron cuenta que despilfarro el tiempo en otras cosas sin importancia que no le aportaban al objetivo.

Yo comprendo esos temores - he estado allí - , y es por eso que tal vez:

  • nos aferramos al comando-control, 
  • asignamos tareas
  • asignamos filas de Gantt (hechas en ms project) a diestra y siniestra
  • ponemos "recursos" (que en realidad son personas, y trabajadores del conocimiento), 
  • les imponemos un tiempo calculado por un experto (que no fueron ellos)
  • hacemos micro-seguimiento, o micro-gestión cada ciertas hroas
  • y si se demoran más les decimos que deben pagar o/y mirar como reponer el tiempo.
La verdad tiene sentido, nos han fallado, hemos fallado y nos dominan los temores, y esos temores nos llevan al lado oscuro [1] - como diría Yoda - (al de comando-control - ver más)


Pero Scrum tiene herramientas que enganchan, empoderan y comprometen al equipo:

  • un objetivo de construir cosas listas (Done) a corto plazo.
  • Un planning que establece compromisos
  • El review que verifica si se logró el compromiso o se quedó en deuda  -(ver más en :  La cara del santo hace el milagro. Efectividad del Planning y Review - )
  • la retrospectiva que con su inspección y adaptación nos lleva hacia nuevos retos, y nos saca de zonas cómodas.
  • y el Scrum Master, que es el agente de cambio que esta cuestionando, ayudando a que el Equipo Scrum ( Product Owner, Team Members, y Scrum Master) salga de su zona de confort

Yo veo Scrum, como un buen juego de equipo, como el fútbol que establece:

  • Cancha, roles, y arbitro //unas cuantas reglas claras ( 3 roles, 4 reuniones, 3 artefactos,  ver más),
  • personas que se divierten jugando // un equipo que se trabaja motivado
  • una táctica para ganar // un tablero kanban y un burndown que muestran lo que tenemos que hacer en un ciclo corto de tiempo y si podemos o no lograr la meta.
  • el deseo de meter gol //un objetivo común y claro "generar el mayor valor en el cliente con la menor cantidad de software posible, en el periodo más corto de tiempo"

Observo en los equipos de desarrollo y en especial de scrum la capacidad innata a auto-organizarse. y dudar de eso, es dudar del niño interior que llevamos dentro, de nuestra capacidad de inventar de poco a poco, de ir mirando como dentro de las reglas establecidas todos nos vamos adaptando, de como podemos jugar mejor sin romper las reglas y meter la mayor cantidad de goles/puntos/aciertos/historias de usuario posibles en un periodo de tiempo.

Es dudar de nuestra voluntad de querer hacer un muy buen el trabajo, de querer dar resultado en equipo, es dudar de la capacidad humana y tribal de relacionarse, trabajar juntos y de querer avanzar en conjunto.

Y si alguien no quiere jugar bien

Creo que todos en diferentes circunstancias cuando alguien no juega correctamente en equipo

  • en el partido de futbol/baloncesto/voleibol el equipo llama la atención del que no está conectado
  • en el asado si alguien solo esta allí para ser servido y no colabora "ni siqueira" a recoger, le llaman la atención o no lo siguen invitando
  • la tía regañona que daña el paseo o la cena juntos deja de ser invitada.

Los equipos al verse empoderados, cuestionan a los miembros que no ayudan en el objetivo común, y poco a poco los equipos van encontrando su forma, número, miembros,  modo, identidad y estilo; y es trabajo del scrum master lanzar las preguntas para que el equipo se conecte, reflexione, inspeccione, adapte y avance.

Cerrando

A mi modo de ver dudar de la auto-organización es dudar de nuestra naturaleza humana.

Cierro con esta frase :"La auto-organización no es una opción en Scrum; es un principio básico. Sin ella  nunca tendremos equipos de alta performance [2]




¿Ustedes que piensan? Queda abierta la discusión

Saludos Ágiles

Jorge Abad


----------
Otra lectura recomendada de este blog: Cualquiera puede ser ágil / Cualquier equipo puede ser ágil


--

[1] "El miedo es el camino al Lado Oscuro.
El miedo lleva a la ira.
La ira lleva al odio.
El odio lleva al sufrimiento.
El sufrimiento al Lado Oscuro.
Cuidado con el miedo, joven padawan." - Maestro Yoda

[2] Hundermark, Peter (traducido por Cyment, Alan) . Un mejor Scrum  -  http://www.scrumsense.com/wp-content/uploads/2012/03/Un-mejor-Scrum-2.pdf

martes, abril 14, 2015

Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software

Hola a todos

Hace poco recordé una lectura que había hecho sobre los requisitos, y hablaban que la vida media de ellos se había reducido con el tiempo (olvide la referencia en foro ágiles me dieron la ayuda - clic aquí - ) y notaba que estos se había convertido en radioactivos, o sea, estaban perdiendo valor en el tiempo.

La cita corresponde al artículo "Software Development: How the Traditional Contract Model Increases the Risk of Failure" de Susan Atkinson y Gabrielle Benefield - se los recomiendo -, el texto es el siguiente:

 "Recent studies, led by Al Goerner at the University of Missouri, Kansas City, demonstrate that the inherent value in Output-Based Requirements erodes exponentially over time. This rate of decay has been likened to the half-life of an unstable radioactive atom. The 'half-life' is the measure of the period of time it takes for the substance undergoing decay to decrease by half.

According to the studies carried out by the University of Missouri, the half-life of the value of the Output-Based Requirements has been rapidly decreasing. In 1980 this was around 10-12 years, by 2000 it had fallen to 2-3 years, and it is currently running at about 6 months.7

In other words, half of the Output-Based Requirements will become obsolete by the end of month 6, half of the remaining half (i.e. 1/4) will become obsolete by the end of month 12, half of the remaining quarter (i.e. 1/8) will become obsolete by the end of month 18, and so on. Hence, by the end of month 18, according to the University of Missouri studies, only 1/8 (i.e. 12.5%) of the Output-Based Requirements will still possess any inherent value."

---Inicio traducción --

"Estudios recientes  -2013 cuando se escribió el artículo - liderados or Al Goerner de la Universidad de Missouri, Kansas City, han demostrado que el valor inherente de los (sistemas) basados en requisitos se degradan exponencialmente con el tiempo. Esta tasa de degradación se ha comparado a la vida media de un átomo radioactivo inestable. La "vida media" es la medida del periodo de tiempo que toma una una sustancia en descomponerse la mitad.

De acuerdo con los estudios realizados por la Universidad de Missouri, la vida media del valor de los requisitos ha ido disminuyendo rápidamente. En 1980 esta fue de alrededor de 10 a 12 años, en el 2000 había caído a 2 a 3 años, y actualmente está funcionando a alrededor del 6 meses.

En otras palabras, la mitad de los requisitos quedará obsoleto antes de fin del mes 6, la mitad de la mitad restante (es decir 1/4) se convertirá en obsoleto antes de fin de mes 12, la mitad de la cuarta parte restante (es decir, 1 / 8) se convertirá en obsoleto antes de fin de mes 18, y así sucesivamente. Por lo tanto, antes del fin de mes 18, de acuerdo con la Universidad de Missouri, sólo 1/8 (es decir, el 12,5%) de los requisitos aún poseerán un valor intrínseco."

--- Fin traducción ---


Acaso no hemos escuchado de nuestros clientes frases como:

  • es lo que especifique y firmé pero: 
    • lo pensé y eso no era lo que quería decir.
    • ya no lo necesito de esa forma
    • el negocio ha cambiado
O peor, 

¿a quienes no les ha pasado que levantan los requisitos de alguien y por alguna razón interrumpen el proceso y vuelven en dos meses a iniciar y estos son completamente diferentes?


Un enfoque tradicional bajo este escenario esta destinado al fracaso, si por ejemplo, levantamos especificaciones durante 6 meses al  mes 7 cuando ya comencemos a desarrollar, lo que se levantó inicialmente algunos de los requisitos comenzarán a ser obsoletos.

Es necesario :
  • un enfoque ágil,
  • de entregas frecuentes (ojalá cada dos semanas)
  • centradas en el valor de negocio
  • que habiliten el feedback del cliente
  • que apoyen los negocios cambiantes y su estrategia
Es necesario en software adoptar metodologías ágiles, muchos en la industria lo están haciendo

¿cuando te decidirás a dar el paso?

---

Una última pregunta ¿cual es la vida media de los requisitos en tu entorno de software?


Saludos ágiles

Jorge Abad

domingo, marzo 29, 2015

Trabajo sobre gestión ágil - Alumnos Pregrado Sistemas - Eafit 2015- sem 01

Hola a todos

Mis alumnos de pregrado  hhhbbbbnngrado grado do de Gestión de proyectos informáticos tienen la mitad del semestre una entrega sobre gestión ágil y otra sobre gestión tradicional.

Les comparto los dos trabajos sobre gestión ágil que resaltaron este semestre:

Los trabajos tienen:


  • Visión
  • Product Vision Board
  • Product Backlog Board
  • User Story Map
  • Plan de Releases
  • Costo del producto por releases
  • Historias de usuario
  • Simulación de Scrum empleando Mockups / Bocetos / Scketches
    • Gráficas de Velocidad, y burndown
Estos son los links



Espero los disfruten y les ayude en sus proyectos.

Saludos Ágiles

Jorge Abad

lunes, marzo 23, 2015

Cómo se ve un User Story Map (mapa de historias de usuario)

Tomado de: http://winnipegagilist.blogspot.no/2012/03/how-to-create-user-story-map.html?goback=.gde_117832_member_162001454


¿Cuáles son los vicios que los más poderosos aborrecen?

Les comparto el resultado de una investigación sobre cuales son los hábitos que no gustan entre los poderosos   en el ambiente laboral y al crecimiento profesional


Esta es:


  • Deshonestidad
    •  las personas que viven una vida honesta pueden relacionarse con los demás armónicamente y en paz
  • Desinterés
    • las personas triunfadoras viven la mayor parte del tiempo explorando, innovando y creando. La vida es muy corta para desperdiciarla en la monotonía y la simplicidad.
  • Mediocridad
    •  la característica de los emprendedores es ser capaces de superar las propias debilidades. Un líder debe desarrollar todo su potencial en momentos de adversidades.
  • Desorganización
    •  el desorden causa estrés y afecta la salud emocional de las personas. La mejor forma de optimizar recursos y tiempo es tener todas las cosas en el momento y en los lugares precisos.
  • Malos hábitos alimenticios
    • las personas que no mantienen una alimentación saludable, que tiene muchos conflictos interpersonales y que no cuidan su salud son incapaces de orientar a otras personas.
  • Irrespeto
    •  las relaciones sociales cordiales son necesarias para alcanzar el éxito. Las personas que respetan a sus semejantes reciben lo mismo y se convierten en modelos a seguir.
  • Ingratitud
    • el desagradecimiento dificulta la construcción de sólidas relaciones de amistad y compañerismo.
  • Desconfianza
    • as personas que no confían en los demás ocultan su inseguridad. La construcción de los intercambios sociales depende del desarrollo de la integridad y autovaloración de cada ser.
  • Ira (agresividad)
    • en momentos de furia y agresividad, los seres humanos bloquean su racionalidad y terminan tomando pésimas decisiones.
  • Pesimismo
    • aquellos que viven desilusionados y llenos de desesperanza ven problemas en momentos que se necesitan soluciones rápidas y efectivas.

20 grandes frases de trabajo en equipo

Tomado de: http://www.soyentrepreneur.com/27200-20-grandes-frases-de-trabajo-en-equipo.html




El trabajo en equipo es clave para que una organización tenga éxito y sobreviva con el tiempo. Por eso te compartimos 20 citas inspiradoras que te servirán para impulsar esta forma de trabajar en tu empresa:
1. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos” Michael Jordan.
2. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas” Madre Teresa de Calcuta.
3. “Trabajar en equipo divide el trabajo y multiplica los resultados” Anónimo.
4. “No preguntes qué puede hacer por ti el equipo. Pregunta qué puedes hacer tú por él” "Magic" Johnson.
5. “Son tres las cosas que le diría a un equipo para ayudarlo a mantenerse unido: Cuando algo resulta mal: yo lo hice. Cuando algo resulta más o menos bien: nosotros lo hicimos. Cuando algo resulta realmente bien: ustedes lo hicieron” Paul “Bear” Bryant.
6. “Los individuos marcan goles, pero los equipos ganan partidos” Zig Ziglar.
7. “La unidad es la variedad, y la variedad en la unidad es la ley suprema del universo” Isaac Newton.
8. “Las fortalezas están en nuestras diferencias, no en nuestras similitudes” Stephen Covey.
9. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos” Lyndon Johnson.
10. “Los logros de una organización son los resultados del esfuerzo combinado de cada individuo” Vince Lombardi.
11. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito” Henry Ford.
12. “Puedes diseñar y crear, y construir el lugar más maravilloso del mundo, pero se necesita gente para hacer el sueño realidad” Walt Disney.
13. “Ninguno de nosotros es tan bueno como todos nosotros juntos” Ray Kroc.
14. “Si quieres ir rápido, ve solo. Si quieres llegar lejos, ve acompañado” Proverbio africano.
15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará” Winston Churchill.
16. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización” James Cash Penney.
17. “Lo más hermoso del trabajo en equipo es que siempre tienes a otros de tu lado” Margaret Carty.
18. “No des a tus empleados por sentado. Si no valoras a tu equipo, ellos no valorarán a tus clientes” Richard Branson.
19. "Solos podemos hacer muy poco; unidos podemos hacer mucho" Hellen Keller.
20. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores” George Clements.

Unas gráficas interesantes de Google Trends sobre Agile

Hola a todos


Realizando una presentación sobre Metodologías Ágiles, decidí realizar unos comparativos entre varios términos en Google Trends, los resultados son interesantes.

Quedan en sus manos las conclusiones.

Saludos ágiles
Jorge Abad


---------------------------
Términos:
  • Agile Software Development
  • CMMi


URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration


URL de búsqueda : Clic aquí


---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration
  • RUP + Rational Unified Process

URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Scrum
  • CMMi + Capability Maturity Model Integration
  • waterfall model + waterfall development
  • Agile software development
  • RUP + Rational Unified Process



URL de búsqueda : Clic aquí

---------------------------
Términos:
  • Agile software development
  • PMP + Project Manager Professional + Project Management Institute
  • CMMi + Capability Maturity Model Integration
  • Scrum






URL de búsqueda : Clic aquí

---------------------------
Términos:
  • User story + user stories
  • Use cases + use cases


URL de búsqueda : Clic aquí

---------------------------
Términos:
  • casos de uso + caso de uso
  • historias de usuario + historia de usuario


URL de búsqueda : Clic aquí

Única Nota: 
Se podría concluir que los hispano-hablantes aún no nos hemos interesado mucho por las historias de usuario




domingo, marzo 22, 2015

Tres ideas cortas sobre las historias de usuario

Hola a todos

Les comparto tres cortas ideas que encontré y me quedaron sonando sobre las historias de usuario.

----

Una del post de Lucho Salazar (De historias de usuario, culturas y del arte de narrar historias)



"Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos."

----

Otra de Leonardo Agudelo





---

Análogamente he notado que cada historia de usuario se parece a un Acta de Reunión,  donde:

  • hay un tema central sobre el que se conversó (el objetivo de la historia)
  • y unos compromisos - criterios de aceptación -  que serán validados en la siguiente reunión (el review)

Saludos ágiles
Jorge Abad.

miércoles, marzo 18, 2015

Una conclusión de muchas...

Les comparto algo que concluí


La clave es ser fiel a sí mismos. El problema es que nos demoramos mucho reconociendo que nos somos infieles.




--
Saludos ágiles y reflexivos

Jorge Abad


domingo, marzo 15, 2015

Por qué los Equipos Scrum son más “rápidos” que los tradicionales. Un enfoque desde Lean Software Development

He notado que muchos profesionales de TI (o IT) el concepto de agilidad está asociado a desarrollar a la “Maldita Sea” (1), es decir,  sin cuidado alguno y sin reglas, donde:
  • no se hace documentación,
  • las pruebas son pocas o nulas
  • poco o nada de análisis
  • el ciclo de vida de desarrollo es “codificar y corregir” y así infinitamente
  • se afirma que “son ágiles” porque “comercialmente es lo que estamos diciendo, pero no sabemos que significa”
  • entre muchos otros desaciertos
Y creen que estas malas prácticas que llevan al desastre, es ser ágil.

Afirmación más falsa no puede haber ( ver Ser ágil es y no es...)


Pero también he observado que no tenemos claro por qué los equipos ágiles son más veloces (2) y productivos (3)  (ver Productividad mejor que Velocidad) que la ejecución tradicional, sabiendo que las actividades de desarrollo siguen siendo las mismas:
  • requisitos
  • análisis y diseño
  • implementación
  • pruebas 
  • despliegue
o incluso pueden ser más actividades (debido a que los equipos ágiles son más  disciplinados y orientados a prácticas técnicas(4)), como por ejemplo :
  • requisitos
  • análisis 
  • implementación empleando pruebas unitarias (TDD)
  • pruebas
  • automatización de pruebas funcionales
  • adicionar pruebas unitarias, funcionales y otras al servidor de integración continua
  • despliegue

La razón radica en que las siguientes prácticas de Scrum mitigan bastantes problemas del desarrollo tradicional y aligeran el desarrollo
  • eliminando reprocesos
  • mitigando riesgos más rápido 
  • suprimiendo el desperdicio
  • acabando burocracia y
  • Maximizando la comunicación
A continuación presento un listado prácticas que desde mi punto de vista alivianan el desarrollo y permiten ser más exitoso, Algunas de esta prácticas las etiquetaré con alguno de los principios de Lean Software Development (5):

Nota: Si aún no has leído sobre Scrum te recomiendo este post (Mi versión de : SCRUM EN POCAS PALABRAS / SCRUM RESUMIDO)


PRÁCTICA CÓMO SE LOGRA VELOCIDAD QUE INYECTA PRINCIPIO LEAN
LOS ROLES
Los roles adecuados
  • Product Owner
  • Scrum Master
  • Team Members
Los tres roles trabajan en sinergia juntos y continuamente sprint, tras sprint.
  • Están los roles requeridos para el éxito trabajando en conjunto. Evitando retrasos por burocracia y falta de disponibilidad.
  • Eliminar los desperdicios
  • Ampliar el aprendizaje
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
  • Crear la integridad
  • Véase todo el conjunto
Product Owner que resuelve dudas durante el sprint El Product Owner está disponible para responder dudas puntuales del equipo sobre las inquietudes que se presentan
  • La comunicación frecuente con el dueño del producto logra solución de dudas e inquietudes que logran que sea fluido el desarrollo
  • Está práctica mitiga el riesgo asociado a la poca comunicación del cliente con el equipo
  • Crear la integridad
Un Scrum Master  que remueve impedimentos El Scrum Master es un líder servicial enfocado en remover los impedimentos, ya sea que los resuelva el mismo o busque la colaboración de otros
  • El equipo mantiene su fluidez en el trabajo.
  • El equipo no se detiene por falta de información y trabajo
  • Se delega la responsabilidad de la fluidez en otro que está enfocado en lograrla
  • Reaccionar tan rápido como sea posible
El equipo jala trabajo (pull) en vez de que se le asigne (push)

Equipo auto organizado
Se posee un sprint backlog que generalmente se encuentra dispuesto en un tablero kanban y el equipo decide la mejor  forma de hacer el trabajo
  • No se depende de la asignación de las tareas a realizar, evitando incurrir en pérdidas de tiempo por falta de direccionamiento
  • Los directos responsables y ejecutores  (el equipo) son los  que deciden cómo reaccionar, construir, interacturar y encuentra la mejor manera de hacerlo.
  • Eliminar los desperdicios
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
LOS ARTEFACTOS
Enfoque en valor Product Backlog priorizado y enfocado en lo que más retorno proporcione al producto Se evita construir desperdicio y funcionalidades poco útiles.

  • Menos funcionalidades que construir
  • Menos funcionalidades que probar
  • Menos bugs a corregir
  • Menos despliegues a realizar
  • Menos software al realizarle mantenimiento
  • Menos problemas en producción que desenfocan al equipo

Se posterga el desarrollo de lo incierto.
  • Eliminar el desperdicio
  • Decidir lo más tarde posible
Sprint Backlog congelado durante el sprint El compromiso para el sprint es definido y congelado
  • Eliminación de reprocesos (dudas, discusiones, etc.) por requisitos inestables
  • Eliminar el desperdicio
LAS REUNIONES / CONVERSACIONES
Un Planning que compromete a los directos responsables Al principio del ciclo el equipo se reúne con el Product Owner para definir un compromiso y la forma de lograrlo.
  • El equipo selecciona el compromiso de acuerdo a su capacidad(y el compromiso no es impuesto)
  • El equipo entiende qué va a construir y como.
  • Potenciar el equipo
Scrum Diario o Daily que sincroniza al equipo Diariamente todo el equipo se reúne a la misma hora, por un máximo de 15 minutos a contarse,
  • Lo hecho ayer
  • Lo que se hará hoy
  • Y los impedimentos
  • Sincroniza al equipo
  • Evidencia los impedimentos o posibles puntos de freno del equipo, para ser gestionados por el Scrum Master
  • El equipo identifica puntos de colaboración
  • Reaccionar tan rápido como sea posible
  • Eliminar los desperdicios
Un Review que permite validar cel producto y compromete más al equipo El equipo muestra el resultado del trabajo hecho durante el Sprint al Product Owner
  • Se comprende cómo está evolucionando el producto
  • Se identifica hacia donde seguir avanzando
  • El equipo recibe feedback sobre su trabajo
  • Ampliar el aprendizaje
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
  • Crear la integridad
  • Véase todo el conjunto
La retrospectiva que busca la mejora continua Cada ciclo –corto -  de desarrollo el equipo se reúne a reflexionar como mejorar para el siguiente ciclo
  •  El equipo está en constante aprendizaje, eliminando lo que no les sirve, mejorando lo actual e experimentando prácticas que los harán más existosos
  • Eliminar los desperdicios
  • Ampliar el aprendizaje
  • Potenciar el equipo
  • Reaccionar tan rápido como sea posible
El refinamiento que da contexto y mitiga riesgos Una reunión donde se contextualiza al equipo sobre el trabajo que se va a realizar el próximo sprinr
  • El equipo se contextualiza
  • Se identifican posibles falencias sobre el próximo sprint
  • Eliminar los desperdicios
  • Ampliar el aprendizaje
  • Reaccionar tan rápido como sea posible
LAS PRÁCTICAS O FORMA DE HACERLO
Ciclos cortos de desarrollo -  Sprints - que mitigan riesgos Se trabaja en ciclos cortos de trabajo donde se construye un producto de forma incremental y completa cada ciclo
  • Se mitiga grandes ciclos de trabajo sin feedback del cliente
  • Cada ciclo busca entregar un incremente integro (no un pedazo incompleto que no puede ser usado)
  • El equipo se conoce y decide cómo trabajar mejor cada ciclo.
  • Permite reaccionar y remover malas practicas.
  • Eliminar los desperdicios
  • Ampliar el aprendizaje
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
  • Crear la integridad
  • Véase todo el conjunto
Se trabaja por incrementos Cada ciclo entrega un incremento en el producto, el cual es usable , integro y útil.

Nota: en la ejecución tradicional, hasta que no se terminan todas las fases no se posee un producto.
  • El equipo da pasos seguros 
  • Se obtiene feedback sobre el producto logrando una construcción acorde con la necesidad

  • Ampliar el aprendizaje
  • Reaccionar tan rápido como sea posible
  • Crear la integridad
  • Véase todo el conjunto
Historias de usuario en Ready para el sprint backlog
(6)(7)
Las historias de usuario deben ingresar claras y bien definidas, sin ambigüedades, ni dudas  al sprint backlog, tanto por parte del Product Owner como del Equipo El equipo navega con certidumbre en el espacio del sprint, y no se incurre en reprocesos por requisitos incompletos, o mal entendidos
  • Eliminar el desperdicio

La definition of done /  DoD/ Definición de Terminado / Realizado Existe un punto indiscutible de cómo deben hacerse las cosas para ser aceptadas.
  • Existe una visión compartida de como el trabajo debe ser realizado y todos se comprometen a lograrlo.
  • Evita ambigüedades
  • Potenciar el equipo
Un equipo multidisciplinario que logra el Done Un equipo con todos los roles requeridos para lograr el DONE!!
  • Se evitan burocracias
  • Se tiene una visión compartida sobre la cual trabajan todos
  • No hay fraccionamiento entre el equipo de proyecto cayendo en frases como “los de pruebas” o “los de desarrollo”, todos trabajan juntos con un mismo objetivo
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
Historias Just in Time – JIT - / Justo a Tiempo El equipo entrega las funcionalidades que cumplen el Done antes del review al Product Owner para su aceptación
  • Se evita que haya reprocesos por funcionalidades mal entendidas
  • Se reduce el tiempo del review
  • Si existe algún mal entendido en alguna funcionalidad, se corrige rápido evitando que se rechace la funcionalidad en el Review
  • Reaccionar tan rápido como sea posible
  • Ampliar el aprendizaje
  • Eliminar los desperdicios
Transparencia que permite a todos saber el estado de las cosas Todo el equipo scrum a su alrededor está rodeado de radiadores de información que informa el estado del producto, proyecto, metas, calidad, felicidad entre otros.
  • Todo el equipo scrum ( Product Owner, Scrum Master y Team) conocen el estado del proyecto permitiéndoles reaccionar de forma rápida.
    • El Burndown chart del sprint informa si se va a lograr el objetivo
    • El Burndow o Burn Up Release informa cuando se liberará el producto
    • Gráficas de deuda técnica, errores por sprint, errores en producción dan visibilidad de la salud técnica y de la calidad del proyecto
    • Gráficas de felicidad dan cuenta de como esta el equipo respecto a su entorno
    • entre más herramientas ideadas o identificadas por el equipo
  • Reaccionar tan rápido como sea posible
  • Ampliar el aprendizaje


Bienvenidos los comentarios y/o observaciones.


Saludos ágiles

Jorge Abad



Definiciones y aclaraciones
(1) Hacer las cosas a la maldita sea: expresión colombiana que en muchos casos significa ejecutar con poca atención, descuido, desgano – hasta con disgusto - y alta probabilidad de error,  de forma que las  cosas quedan medio hechas y requiere casi volver a hacerlas para que queden bien. 

(2) Velocidad: cantidad de software producido en una unidad de tiempo
(3) Productividad: construir el producto correcto 
(4) Las prácticas “ágiles” (o técnicas)  no son propiedad de las metodologías ágiles – o marcos ágiles –y pueden ser empleadas en contextos de gestión tradicional con igual éxito
(5) Principios de Lean Software Development (ver más acá):
  • Eliminar los desperdicios
  • Ampliar el aprendizaje
  • Decidir lo más tarde posible
  • Reaccionar tan rápido como sea posible
  • Potenciar el equipo
  • Crear la integridad
  • Véase todo el conjunto
(6) Esta práctica no pertenece a Scrum pero es muy empleada con el marco de trabajo.
(7) Aunque Scrum no habla de historia de usuario, si habla de Sprint Backlog con ítems en “ready”, estos ítems, pueden ser historias de usuario, casos de uso, requerimientos en prosa, lo que sea que el equipo determine usar, aunque si es más ampliamente recomendado emplear historias de usuario



viernes, marzo 13, 2015

Leído y Recomendado: No termines tus retrospectivas con un plan de acción

Hola a todos

Hace poco leí un excelente post de Hiroshi Hiromoto, un gran coach ágil de Perú.

En el invita a terminar las retrospectivas con propuestas de experimentos, que luego se validarán si fueron efectivos o no, (obvio orientados al a mejora continua)

Este es el post: No termines tus retrospectivas con un plan de acción

Se los recomiendo, es de colección.

Saludos ágiles

Jorge Abad

miércoles, marzo 11, 2015

Una actividad/juego de sensibilización sobre los resultados de la ejecución tradicional (cascada o RUP) en proyectos de software

El JUEGO DE LA MUESTRA ESTADÍSTICA



Hola a todos

Muchas veces antes de dictar un entrenamiento o una charla sobre metodologías ágiles realizo la siguiente actividad  (la aprendí de mi colega Leonardo Agudelo - https://twitter.com/sweepnoise )

  1. Trazo una linea divisoria imaginaria, o con cita de enmascarar 
  2. Pongo a todo el grupo a un lado de la línea
  3. Comienzo a realizar las siguientes preguntas e invito a los que las van cumpliendo pasen al otro lado de la línea
  4. y así voy avanzando hasta que veo que es suficiente

La fuerza de la actividad radica en las preguntas y en que todos perciban lo mal o bien que les esta yendo haciendo la ejecución actual de proyectos (adicionalmente que no son los únicos que padecen los problemas de su día a día)

Estas son algunas de las que uso:


Nota: Resaltaré las preguntas que más me han sorprendido.

----
  • Categoría: Roles
  • Objetivo: Saber con quienes comparto la charla o entrenamiento
  • Preguntas
    • ¿quiénes son gerentes de proyecto?
    • ¿quiénes son comerciales?
    • ¿quiénes son desarrolladores?
    • ¿quiénes son testers?
    • etc
--
  • Categoría: Tiempo
  • Objetivo: Sensibilizar que la ejecución tradicional (cascada, Rup, o cualquier variación) no es precisa en cuanto al tiempo 
  • Preguntas
    • ¿quiénes han estado en un proyecto que se ha demorado el cuadruple de lo planeado?
      • ¿quienes el triple?
      • ¿quienes el doble? 
    • ¿quienes han trabajado en un proyecto seguido sábados y domingos incansablemente por más de un año? -(lamentablemente los hay)
      • ¿8 meses?
      • ¿6 meses?
      • ¿4 meses?
      • ¿2 meses?
      • ¿1 mes?

--
  • Categoría: Costo
  • Objetivo: Sensibilizar que la ejecución tradicional los costos no son predecibles
  • Preguntas
    • ¿quiénes han estado en un proyecto que ha costado el cuadruple de lo planeado?
      • ¿quienes el triple?
      • ¿quienes el doble? 
--
  • Categoría: Alcance / Requisitos 
    • Objetivo: mostrar que las especificaciones firmadas no son garantía éxito.
    • Preguntas
      • ¿quienes han estado en un proyecto donde a pesar de haber construido lo que hay en las especificaciones, el cliente afirma "ok, es lo de las especificaciones pero eso no es lo que yo quería"?
      • ¿Quienes han estado en un proyecto donde los controles de cambio cuestan mas que el proyecto original?
      • ¿a quienes el cliente les ha dicho?
        • ¿yo se que yo firmé eso, pero eso no es lo que yo necesito?
        • ¿es que esa funcionalidad aun no esta clara y no se como va funcionar?

--


  • Categoría: Éxito de los proyectos tradicionales
  • Objetivo: Sennsibilizar sobre lo dificil que es ser éxitoso en tiempo, costo, alcance y calidad en un proyecto tradicional
  • Preguntas
    • ¿quiénes han estado en un proyecto exitoso en tiempo, costo, alcance y calidad? (se sorprenderán.. muy pocos) 
--
  • Categoría: Estimaciones
  • Objetivo: Mostrar que tan acertadas son las estimaciones en proyectos de software son imprecisas, debido a la incertidumbre.
  • Preguntas
    • ¿quienes se han equivocado en una estimación el 8 veces, ejemplo dijeron 1 día y se demoraron 8?  -(lamentablemente los hay)
      • ¿6 veces?
      • ¿4 veces?
      • ¿2 veces?
(será que no sabemos en que estamos trabajando)

--
  • Categoría: Desgaste del equipo y de la vida personal
  • Objetivo: Mostrar la forma en que hemos desgastado nuestras vidas y la de los equipos de trabajo forzando el éxito a toda costa
  • Preguntas
    • ¿a quienes su familia, novio, novia, esposo, esposa, hijos, hermanos madre, les ha dado un ultimatum...¡o renuncias o no vuelves a saber de nosotros! (aca el resultado ha sido doloroso, algunos comparten que les ha costado el divorcio, o situaciones similares)
    • ¿quienes han trabajando seguido mas de ?
      • 36 horas
      • 24 horas
      • 16 horas
--
  • Categoría: los riesgos
  • Objetivo: Evidenciar los riesgosos que son los proyectos de desarrollo de software
  • Preguntas
    • ¿ a quienes se les ha dañado una entrega teniéndola completamente lista?

--

  • Categoría: Desperdicio /se construye lo que no se usa
    • Objetivo: Mostrar cuanto software es desperdicio (la estadística muestra que del 100%, solo el 50% es usado, de ese 50%, el 20% con frecuencia y el 30 rara vez - Chaos Manifesto 2013)
      • ¿quienes consideran que el 100% del software que hacen es usado por el cliente?
        • ¿el 90?
        • ¿el 80?
        • ¿el 70?
        • ¿el 60?
        • ¿el 50?
      • ¿quienes consideran que construyen documentación que nunca será usada?
      • ¿quienes han estado en un proyecto que no salió a producción?
      • ¿quienes han estado en un proyecto que saló a producción pero nadie usa?
      • ¿quienes han estado en un proyecto donde dicen, la documentación que se hizo no sirve, volvamosla a construir?


y así.. sucesivamente

Si tienen más preguntas para la actividad, que bueno sería las compartieran...

Como se pueden dar cuenta no son los únicos que viven estos males.

Hagan la actividad y compartan la experiencia en este post, se llevarán sorpresas muy interesantes.

Saludos ágiles
Jorge Abad


domingo, marzo 08, 2015

Cualquiera puede ser ágil / Cualquier equipo puede ser ágil

Unas preguntas comunes cuando dicto un entrenamiento, es

  • ¿y un equipo de seniors puede ser ágil? -  dado sus resabios
  • ¿y un equipo de juniors puede ser ágil? -  dado su inexperiencia
Y lo que generalmente contesto es:

"si funcionamos en un esquema de gestión tradicional que es tan desgastante y orientado al fracaso, con seguridad lo haremos en ágil, se requiere de acompañamiento, pero se logra" 

Y es que pienso que  "Cualquiera puede ser ágil", o mejor "Cualquier equipo puede ser ágil", similar a la frase del Chef Gusteau en Ratatouille: "Cualquiera puede cocinar"


No lo niego, soy humanista:
  • creo en la gente, 
  • creo en que todos podemos y queremos lograr grandes cosas, 
  • creo que podemos aprender a trabajar en equipo y lograr excelentes resultados
Es cierto soy Scrum Master y mi enfoque en las personas no puedo ocultarlo, es inherente a quienes vibramos con este rol de Scrum, y quienes queremos que las cosas mejoren.

Pues como lo expresa uno de los los principios ágiles -

"Los proyectos se desarrollan en torno a individuos, motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo."

Es por tanto, necesario el entorno, apoyo y confianza para que emerja la agilidad.

Bien lo dice Lucho Salazar en su post " “No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”:  "Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas"

(Siguiendo con la reflexión) Similar a como lo expresa Anton Ego en su discurso final en Ratatouille (1) pienso que un equipo ágil puede venir de cualquier parte, un gran equipo ágil pienso que es más difícil, pero con que sean un buen equipo, con seguridad estarán darán grandes resultados (mucho mejores que los ofrecidos por el mando-control de la gestión tradicional).

Acaso
  • ¿que persona no quiere sentirse exitosa en su trabajo?
  • ¿que equipo no quiere dar resultados?
Y eso es lo que nos da un entorno ágil, un lugar para aprender, fallar, corregir camino, y lograr grandes resultados, mientras trabajamos motivados y felices.



Saludos ágiles
Jorge Abad.

Referencias
(1) Frase de Anton Ego : <<Antes de este suceso, nunca escondí mi desdén por el lema del Chef Gusteau: “cualquiera puede cocinar”. Pero, me doy cuenta, recién ahora comprendo sus palabras. No cualquiera puede convertirse en un gran artista, pero un gran artista sí puede provenir de cualquier lugar.>>


Consideraciones y Aclaraciones Importantes

 Jurgen Apelo en Management 3.0

"The Agile Blind Spot 

I believe a “weakness”of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive. The “people over process”paradigm is great, until you find out that your team consists of two trolls, a parrot, and a hairdresser, and a relatively bright project manager, who happens to be deaf, blind, and mute. No amount of coaching can help a team like that to magically self-organize and to deliver a successful product. I call this the Agile “blind spot.”Agile (as promoted by the manifesto) is great only when the team is great (or at least good enough). To be fair, the need for great teams is probably even twice as important in non-agile environments,but the Agile Manifesto too leaves competence issue unresolved."  

Ken Schwaber
“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura. ”




sábado, marzo 07, 2015

Ejemplo de historia de usuario : Ingreso al sistema

Hola a todos

A continuación presento un ejemplo de historia de usuario, bastante general (aplica para el 99.99% de los casos y sistemas) que puede ayudar a comprender mejor la escritura de las mismas:

-----------------------------------------------------------------------------------------------
HU: 20 -  Ingreso al sistema

Yo como Usuario 
Deseo ingresar al sistema
Para poder hacer uso de las funcionalidades del sistema



--- Criterios de aceptación -----

Criterios de Aceptación 1: Ingreso exitoso

Cuando el ingreso del usuario y contraseña son correctos
Entonces el sistema permitirá el ingreso al sistema

Criterios de Aceptación 2: Ingreso fallido

Cuando el ingreso del usuario y contraseña son incorrectos
Entonces el sistema NO permitirá el ingreso 
Y el sistema presentará una alerta con el siguiente mensaje:  “Usuario y/o contraseña no válido, por favor recuerde que tiene 4 intentos para ingresar al sistema, luego de esto su usuario será bloqueado.”

Criterios de Aceptación 3: Último ingreso fallido

Cuando el ingreso del usuario y contraseña son incorrectos
Entonces el sistema NO permitirá el ingreso 
Y el sistema presentará una alerta  con el siguiente mensaje: “Su usuario se encuentra bloqueado, favor contacte al administrador del sistema, o al teléfono xxxxxxxx  para que sean reestablecidos los accesos al sistema.”

Criterios de Aceptación 4: Ingreso a una url o página no autorizada

Cuando el usuario intente ingresar a una URL o pantalla en la que no tenga permiso 
Entonces el sistema no permitirá el ingreso a la dirección o pantalla solicitada
Y no permitirá ninguna operación 
Y el sistema direccionará a la pantalla de ingreso 

Criterios de Aceptación 5: Sesión expirada

Cuando la sesión haya expirado  
Entonces el sistema no permitirá ninguna operación
Y el sistema direccionará a la pantalla de login

Nota: 
Se deberá configurar en el sistema el tiempo máximo de sesión para el usuario. XXXXX


Criterios de Aceptación 6: Falta uno o más campos obligatorios

Dado que no se ingrese en el formulario alguno de los datos obligatorios. (marcados con * )
Cuando el usuario oprima el botón “Ingresar” 
Entonces el sistema no permitirá el ingreso al sistema
Y aparecerá el mensaje :“Por favor ingrese los campos obligatorios (*) faltantes :
[Presentar el listado de campos faltantes]“


----------

Este puede ser el mockup /scketch/boceto resultado de esta historia






Ejemplo: Una historia de usuario - Listado de Morosos

Hola a todos

Les comparto una historia de usuario, generalmente es una de las que uso durante los cursos de scrum


Por lo general queda puntuada en 5 puntos, tomando como pivote 1 día feliz o productivo, es decir, se toma por lo general 5 días en lograr la Definition Of Done en la tecnología que cada quien maneja.



----
La transcribo para quienes la necesiten


Historia de usuario - Listado de morosos

YO COMO gerente de sucursal
DESEO el listado de morosos
PARA saber a quien comenzar a cobrar

---Criterios de aceptación
- El listado contendrá los campos
      -  Nombres
      -  Apellidos
      -  Cédula
      -  dias de mora
      -  monto
      -  tipo de préstamo
 - El listado debe estar ordenado x días de mora descendente
 - Quienes tengan mora
      -  mayor a180 dias en color rojo
      -  60-179 color amarillo
      -  color negro
 - Exportable a Excel 2010
 - Paginado por cada 20 registros
 - Accede solo el Gerente de sucursal
 - En la parte superior de reporte debe aparecer la fecha de corte (fecha en que se genera)