domingo, febrero 15, 2015

¿Cuántas historias por Sprint?

Hola a todos

Obvio en esto no hay reglas,  pero si recomendaciones. 

He  notado que por Sprint es bueno tener entre 6 y 10 historias de usuario,  ojalá todas de tamaño similar, parecido o entre el mismo rango.


Esto permitirá un flujo regular del equipo a lo largo del Sprint.


Pocas historias muy grandes hará  que cueste mucho lograr el ¡DONE!  Y posiblemente hayan historias que no se logren.  RECOMENDACIÓN: realizar división de historias.


Muchas historias muy pequeñas dan la sensación de demasiado trabajo a realizar en el Sprint, un tablero atiburrado de tareas por hacer. RECOMENDACIÓN: fusionar historias.


Atento a sus comentarios y experiencias


Saludos ágiles
Jorge Abad

sábado, febrero 14, 2015

Leído y Recomendado: Buenas retrospectivas = equipos en mejoramiento constante

Excelente post de un gran amigo y agilista : Leonardo Agudelo (@sweepnoise)

http://agilescolombia.org/2015/02/12/buenas-retrospectivas-equipos-en-mejoramiento-constante/

La copio pues la considero de colección.

---------------------

Desde hace algunos días he tenido la oportunidad de facilitar retrospectivas de varios equipos y la experiencia obtenida merece ser compartida.
Los equipos a los que facilité la retrospectiva no necesariamente tenían como costumbre hacerlas con una frecuencia definida, otros tenían bastantes problemas cuando las realizaban y otros ya no las hacían… en fin… había necesidad de cambiar la estrategia.
Me basé en la estructura recomendada en el libro “Agile Retrospectives: Making good teams great” para planear las retrospectivas, la cual cuenta con los siguientes puntos:
  1. Preparar el escenario: lograr que las personas se focalicen en los objetivos de la reunión, en el tiempo estipulado y con una dinámica productiva.
  2. Conseguir datos: lograr una visión común de la situación a analizar, tanto con datos objetivos como subjetivos. Es la base común de hechos, eventos, sentimientos que permitirá tener una comunicación efectiva el resto de la reunión.
  3. Generar entendimiento profundo: entender el por qué, tanto de lo que anduvo mal como de lo que anduvo bien. Ir más allá de la primera apariencia, para encontrar las causas profundas que hay que sostener y mejorar o cambiar.
  4. Decidir qué hacer: teniendo una lista de posibles experimentos que el equipo puede realizar para mejorar, es el momento de elegir, ya que no todo se puede hacer para el siguiente sprint.
  5. Cierre: finalizar claramente la retrospectiva, con una nota positiva y ganas de realizar los experimentos que se encontraron.
Complementé estos pasos con otros dos que me recomendó un entrenador muy reconocido en el continente (Alan Cyment):
1.1 Revisar los compromisos adquiridos en la retrospectiva pasada
2.1. Priorizar los datos
Estos dos puntos adicionales me parecen vitales, ya que por un lado es una mala práctica (o antipatrón) de retrospectiva no revisar los compromisos adquiridos en retros anteriores, y tratar de cubrir todos los temas que afloran en medio de la retrospectiva es ineficiente.
Usé en cada una de las etapas de la retrospectiva actividades o dinámicas que facilitan e incentivan la participación de los miembros del equipo. Me parece que se pueden recomendar las siguientes:
Para preparar el escenario: la actividad “Histograma de satisfacción” . Cada participante selecciona el nivel de satisfacción en el sprint que termina desde un punto de vista general y lo explica al resto del equipo. Los niveles son:
  • 5-  Somos los mejores del mundo! Qué gran equipo que somos!
  • 4- Estoy orgulloso de ser parte del equipo y de cómo trabajamos.
  • 3- Bastante satisfecho, trabajamos bien juntos la mayoría de las veces.
  • 2- A veces estoy satisfecho, pero pocas.
  • 1- Estoy disconforme y poco satisfecho con el nivel de trabajo en equipo.
Se debe revisar el avance 2 o 3 iteraciones después
Nota: para esta actividad es importante tener un timebox de 2 minutos para que cada explique lo que lo llevó a elegir su nivel, de lo contrario se convierte en el paso 2 de la estructura de retros, que es conseguir datos.
Para Conseguir los datos: me pareció muy buena la actividad Mad, Sad, Glad (Enojado, Triste, Alegre), en esta actividad cada participante identifica en 7 minutos todos los momentos que le causaron esas sensaciones y los escribe en postit, (uno por postit), luego los expone al grupo. Esta actividad promueve el uso de frases “Yo”, ya que pone de antemano el sentimiento que le generaron al participante diferentes situaciones o momentos durante el sprint y evita el señalamiento y atribución de culpas.
Nota: los mensajes “YO” son así:
Cuanto tu (establezca el comportamiento)
Me siento (establezca el sentimiento)
Entiendo lo que sientes (empatice con el otro)
Porque (establezca consecuencia)
Te pido el favor de (establezca la petición, negocie el cambio)
Para generar entendimiento profundo: ensayé dos formas, la técnica de 5 por qué’s, la cual facilita la búsqueda de las causas reales de un problema al preguntarle al grupo ¿Por qué? reiterativamente, se supone que tras 5 respuestas ya hay un entendimiento más profundo. Esta técnica es buena, pero me pareció mejor la espina de pescado (diagrama de Ishikawa), esta permite hacer un análisis causal sin perder de vista algunos aspectos de la discusión que se pierden fácilmente con la técnica de los 5 por qué’s. Es muy importante que el equipo ponga los porcentajes de aporte al problema de cada rama del diagrama.
Para decidir qué hacer: la mejor forma que he visto es una lluvia de ideas en parejas. En un timebox (pueden ser 7 minutos) se proponen actividades concretas, que se puedan asignar a alguien en el siguiente sprint. Luego de los 7 minutos cada pareja explica las propuestas y se van agrupando si se refieren a lo mismo que las propuestas de otras parejas. Finalmente se permite que cada persona vote por las ideas que más le gustan. A cada participante se le dan 5 puntos, los cuales pueden ser distribuidos como quiera entre las propuestas. Las 3 o 4 propuestas que tengan más votos serán las que el equipo se asigne.
Es muy importante que las actividades ganadoras tengan un doliente que se encargue de que sucedan (no necesariamente son quienes las ejecutan).
Para el cierre: ha funcionado bien una sesión de agradecimientos, donde cada persona le expresa al resto del equipo a quién le agradece y por qué.
Estas actividades han dado muy buenos resultados, pero es muy importante variarlas, en la siguiente dirección se pueden obtener cerca de 2 millones de retrospectivas diferentes: http://www.plans-for-retrospectives.com/index_es.html , esto es, contando las posibles combinaciones de diferentes actividades para cada etapa. Así que no hay excusas para no variar las retros.
Una ventaja para resaltar al usar la estructura propuesta es que con ciertas actividades hay mayor participación de personas que nunca participaban en las retros con otra estructura, alguna vez alguien me dijo “… este nunca hablaba…”, lo cual es bastante gratificante.
Otra cosa que me parece muy buena es que el mismo equipo es el que logra identificar sus problemas y proponer las soluciones, como facilitador solo aporto cuando veo que hay un concepto de agilismo que no está totalmente claro, y así yo crea que tengo la solución para un problema que viven ellos, me lo guardo y espero que encuentren sus propias soluciones. La tentación es grande, porque solemos creer que tenemos la respuesta para todo, pero los mismos equipos son los que sufren los problemas y ellos deben encontrar sus salidas, creo que esto fortalece la noción de autogestión y de compromiso del equipo, parte esencial de los equipos de alto desempeño.
Me parece que hay un riesgo que se debe manejar y es que las actividades que se eligen y para las cuales queda alguien responsable no se lleven a cabo. Cuando esto sucede la sensación en la siguiente retrospectiva puede ser que no sirve para nada hacer la retro. Para mitigar esto es bueno poner las tareas en el tablero Kanban, tal como las actividades de desarrollo y no perderlas de vista durante el sprint.
Como siempre digo en los entrenamientos, si un equipo no hace retrospectivas es como si dijera: “Somos perfectos, ya no hay nada que podamos hacer para mejorar”, lo cual es una mentira. Siempre hay forma de mejorar, de buscar la excelencia, de permanecer en el camino de la mejora continua.

lunes, febrero 09, 2015

Testing Agile Manifesto


Creo que necesitábamos algo así.

No son dos equipos (desarrollo y pruebas), son un equipo enfocado en generar las mejores soluciones posibles para el cliente


Saludos ágiles

Jorge Abad

miércoles, febrero 04, 2015

¿Qué motiva a las personas? \ ¿Qué motiva a los equipos?

Hola a todos

Hace poco en Ágiles 2014, Ángel Medinilla  en su presentación “Unicornios, Krakens, Equipos Auto-Organizados y otras bestias mitológicas”.  explicaba que la motivación tenía la siguiente fórmula


MAESTRÍA +
AUTONOMÍA+
     PROPÓSITO+    
MOTIVACIÓN

(En palabras, la motivación tiene como fuente la maestría, la autonomía y el propósito) 


De igual forma, en dos post publicados (1 y 2)  recientemente por Javier Garzas, se argumenta que la motivación de las personas y de los equipos tiene como fuente 10 factores:


La Curiosidad +
El Honor y la Lealtad+
La Aceptación y la asociación al éxito+
El conocimiento+
Poder e Influencia+
Libertad, Independencia y Autonomía+
Relaciones+
Claridad y sinceridad+
Tener un objetivo y un propósito+
                  Estatus+                
MOTIVACIÓN




No voy a entrar en discusiones si es cierto o falso o si faltaron factores o no, he aprendido y experimentado hasta ahora* varias cosas respecto a la motivación:
  • nadie puede motivar a nadie a menos que este lo permita.
  • nadie puede hacer cambiar a otra persona a menos que esta lo permita (parecida a la anterior)
  • las personas solo cambian por dos razones
    • inspiración 
    • o desesperación
  • Nuestro trabajo como Scrum Master:
    • es estar censando la motivación de las personas y del equipo.
    • trabajar para que el equipo y las personas tengan lo suficiente para trabajar motivados, desde el punto de vista del entorno y las personas.
    • si se identifican falencias en la motivación (ya sea en las personas o en los equipos) :
      • hacer preguntas abiertas
      • escuchar
      • aprender
      • ayudar
      • volver a hacer preguntas abiertas
      • encontrar causas
      • identificar si se pueden cambiar las causas para lograr consecuencias diferentes
      • acompañar hasta que la situación es sorteada
      • apoyar / acompañar en caso de que se requiera una posible transición


Saludos Ágiles

Jorge Abad




Notas:

(*) Aclaro el "hasta ahora" pues he aprendido que la única constante existente es el cambio y lo único inevitable es la muerte.


Fuentes :




sábado, enero 31, 2015

El éxito del Agile Coach (Scrum Master)

Esta frase me pareció genial.

La  leí en el libro de Lyssa Adkins "Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition" (super recomendado luego de haber avanzado un poco en biografía ágil)

"El éxito del Gerente de Proyecto (PMP) es cumplir el plan, para el Agile Coach es la mejora continua de su equipo y la búsqueda de su alto desempeño" @LyssaAdkins


martes, enero 27, 2015

Leído y Recomendado: Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)


Este es el link: http://www.javiergarzas.com/2012/12/google-pruebas.html


Saludos ágiles

Jorge Abad

[Scrum] Antipatrones del Daily Meeting / Reunión diaria / Scrum Diario y Posibles Soluciones

Faltaba yo...

Me he encontrado esta semana muchos post de antipatrones en los dailys (*)  (unos de Javier Garzas a quien sigo frecuentemente en su blog y otros de otras fuentes), y bueno la verdad falto yo, pues a mi he identificado otros mas a añadir a la lista - según mi experiencia - :


Los antipatrones encontrados y los propios son los siguentes:



Fuentes Antipatrón Posible(s) Solución(es)
(1)(2)(3) Reuniones de informar al líder o al jefe
  • Intervención del scrum master explicando que el daily es para el equipo y sincronizar al equipo, no para el scrum master, líder, product owner o cualquier otro rol dominante.
  • Poner al líder detrás del equipo (Por lo general el daily se hace al frente del tablero kanban y todos mirando el tablero )
(1)(2)(3) Se llega tarde
  • Acordar con el equipo una multa en dinero para quien llega tarde (ojo, solo si el equipo todo esta de acuerdo), y enfatizar que el objetivo no es conseguir plata para desayunos o invitaciones en la tarde sino para promover la asistencia puntual con este "leve castigo"
  • Retroalimentar en la retrospectiva y a lo largo del sprint a quien sea reincidente, haciendo énfasis en lo necesario y útil que es este momento para el equipo
(1)(2) No lo puedo recordar
  • El Scrum Master invita a los participantes a preparar la conversación del daily minutos antes.
(1)(3) Ponerse a contar la historia de tu vida
  • El Scrum master, prepara al equipo antes del daily diciendo que hará una señal para que cualquiera que se esté extendiendo comprenda que debe cortar rápido.
(1)(2)(3) Resolver problemas
  • El Scrum Master interrumpe respetuosamente al equipo y les dice que luego del daily se resuelven estos aspectos
(1)(2) Se van de tiempo
  • El Scrum Master interrumpe respetuosamente la sesión, corta a los 15 minútos . Luego en un espacio y tiempo aparte revisa con el equipo que sucedió para que este tiempo no se cumpliera (igual se puede revisar en la retrospectiva)
  • Una posible opción es que tienes en tu equipo más de 9 team members, que es lo máximo que tiene un equipo scrum.
(1) Reunión caótica
  • El Scrum Master entrega un token y solo tiene la palabra quien lo posee
(1) La gente se corta y no habla o habla poco
  • Coach del Scrum Master con esta persona
(2) Hacerla unos días y otros no
  • Responsabilidad del Scrum Master
(2) Estar distraído
  • Una opción: Un simple llamado de atención del Scrum Master corrige esto. 
  • Luego indagar por que se esta distraid@ en el daily, pueden haber razones para mejorarlo o corregirlo
PropiaContestar las tres preguntas abstractamente, ejemplo, señalando el tablero:

  • ayer hice esto
  • hoy esto
  • y no tengo impedimientos
  • Ayer hice la parte 1 de la historia 2
  • y hoy continúo con la parte 3
  • y no tengo impedimientos



  • Inivitar a que se digan los nombres de las funcionalidades, para lograr la atención de todos los del equipo.
Propia Los dailys cada día a diferente hora para el mismo equipo, de manera que puedan asistir todos o alguien en especial
  • Esto se vuelve una locura, y uno termina no sabiendo que día de la semana es el daily. Recomentación: EL DAILY SIEMPRE A LA MISMA HORA
Propia No empezar por que falta...


  • El daily es del equipo debe comenzar con los que estén del equipo, es un ritual a cumplir y es de los aspectos sicorígidos de scrum - recordemos que es un marco donde nos movemos con liberdad -. Se comienzan  con los que estén y aclaro "no es necesario que este el Scrum Master", si por alguna razón este falta en otro momento se enterará de los impedimentos y del avance del equipo - seguro en el tablero Kanban queda esto reflejado - 
(3) Baja Energía
  • El Scrum Master debe indagar esta situación y tomar acciónes. (ojalá no estén trasnochando)
Propia Daily avanzado el día.

Por lo general esto desconcentra a los equipos, parar para hacer un daily tipo 11am o 3pm.


  •  Tratar de hacer el daily comenzando el día de trabajo
(3) Impedimentos no son identificados.

Por lo general los team members no identifican que tienen un impedimento y no no cuentan

(3) Los impedimentos no son removidos
  • El equipo debe en este caso llamarle la atención al Scrum Master. Identificar causas en la retrospectiva.
(3) Los obstáculos solos son removidos en el daily
  • El Scrum Master debe informar tan pronto se remueva un impedimento al equipo para mejorar la agilidad y no esperara al daily
Propia Permitir que el product owner indague al equipo.
  • Recordar el daily es del equipo, ni el product owner, ni el scrum master tienen voz y voto en el. Después del daily estos pueden hablar con el equipo
(2) Se toman tareas sin respetar prioridades del backlog

Explico: como los team members comparten la respuesta a la pregunta ¿que voy a hacer hoy? es probable que elijan algo que no esta en la prioridad.

  • El Scrum Master o cualquier team member llamar la atención sobre esta situación e invitar a que se respete la priorización.

--

Nota: Si tienen más antipatrones no duden en compartirlos





Saludos ágiles

Jorge Abad





_______

Definiciones

(*) Daily (Reunión Diaria / Daily Meeting / Scrum Diario ): La reunión diaria propiedad del equipo de desarrollo - facilitada por el Scrum Master - que dura máximo 15 minutos y se hace de pie, donde cada miembro cuenta:
  • que hizo ayer
  • que se va a hacer hoy
  • y que impedimentos se tienen
____


Referencias

(1) Reuniones Diarias (Daily meetings): anti-patrones - Blog Javier Garzas -  Clic Aquí
(2) Tales from the Scrum: Anti-patterns de la reunión diaria - Blog Ángel "Java" Lopez -  Clic Aquí
(3) It's Not Just Standing Up: Patterns for Daily Standup Meetings -  Blog Martin Fowler - Clic Aquí (este post es de estudio)
(4) Stand-up Meeting Antipatterns - Clic Aquí

_

lunes, enero 26, 2015

Scrum Hit list - 10 good reasons for Scrum

Tomado de: http://www.agile42.com/en/blog/2009/06/16/Scrum-risks/



  1. There are many good reasons to work with Scrum. The 10 most important include: Competitiveness - In many markets, the competitive environment is changing faster and faster. Only companies that are flexible and agile have a fast enough time-to-market to stay competitive and create a competitive advantage for themselves.
  2. Develop what is needed - Scrum allows the incremental development of features. The customer receives the first working versions early and as well as seeing progress can, if necessary, add new ideas.
  3. Confidence through transparency - Transparency plays a critical role at various levels in Scrum and is one of the primary drivers which makes Scrum so efficient. Because of transparency all the stakeholders are informed where the project is at any given time. This helps in discovering weaknesses and it makes effective teamwork possible.
  4. Build quality in - Testing is an integral component of Scrum in every sprint. Only if the software is tested and documented is it ‚”ready‚”. Methods such as continuous integration are very applicable for increasing the quality of every object from the beginning.
  5. Recognize risks in time - systematic risk management - Regular releases establish the conditions in which to recognize problems in time and to react promptly. Long-term statements about time to completion and product delivery roadmaps are possible because of factors like the team velocity (a measure of how much a Team can do per Sprint).
  6. To have the costs under control - The duration of a project is usually fixed, but the effort and the complexity of the work is usually only roughly estimated. Scrum allows changes to feature specifications, in collaboration with the customer, creating transparency and allowing definitive cost accounting.
  7. Changes are welcome - The Scrum framework is not afraid of changes. On the contrary, changes can be shown to the Product Owner at any time and can be realized in the following sprint without generating conflict. That way the customer gets the product he or she desires.
  8. Efficient collaboration and customer satisfaction - Scrum involves regular communication between all the participants of the project. Communication, collaboration, respect and understanding what the customer requires or what the team develops is the basis for delivering successful projects.
  9. Scrum is perfect for system development as well - As opposed to the widely-held view, that Scrum is only good for small products, Scrum is very good for the development of complex systems and extended projects. The exact planning and practices such as the continuous integration of new functionalities provide visibility of progress, and ensure that there won’t be a big surprise at the end of the project. Many large systems are developed with the same agile principles behind Scrum.
  10. Last but not least - Scrum is fun - Not task selection necessarily, but collaborative working and decision-making as a team is an important part of Scrum. Software development is seen for what it is: A creative and multi-dimensional activity that only can work properly when everyone takes responsibility.

domingo, enero 25, 2015

Leído y Recomendado: “Vamos a automatizar pruebas”. ¿Qué significa esto? ¿Realmente por dónde deberíamos empezar a automatizar?

Tomado de: http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html

Excelente post de la página de Javier Garzas

Lo copio, pues lo considero de colección

--------
Hoy en día muchas empresas software, por su negocio quieren ser ágiles. Quieren sacar productos más rápido al mercado y adelantarse a la competencia, mejorando para ello la calidad de su proceso, producto y equipos software.
Una de las claves para agilizar ese proceso, detectar errores antes, en puntos del desarrollo en los que nos cueste menos solucionarlos y así desarrollar con más seguridad, es la optimización y automatización de ciertos procesos y pruebas (muy relacionado con Integración Continua).
Sé que no es un cambio sencillo y que automatizar pruebas tiene un coste (lo vivo en el día a día, ya que Integración Continua, testing ágil, automatización de pruebas, son campos en los que trabajo en dentro 233 Grados de TI.).
No obstante, creo que con recursos limitados, sin automatizar ciertas pruebas es complicado llegar al testing ágil.
Dentro de este día a día, me da cada vez más la impresión, de que al igual que ocurre con la calidad de software en general, en ciertas ocasiones no se tiene muy claro qué implica la automatización de pruebas. Ni qué implica el testing ágil.
De ahí que escuche cosas como:
– “Para el mes que viene estará todo automatizado, ¿no?”
– ¡Ah, genial! Si automatizamos las pruebas…¡Nos ahorraremos a los testers manuales!
– ¡Sí, automaticemos pruebas! Tú enséñanos a automatizar pruebas con eso de Selenium, que le das al botoncito, tocas cuatro cosas y vas grabando lo que haces.
Pero la automatización de pruebas implica más que eso. Ahora verás por qué.

¿Automatizaremos todo? ¡Así nos ahorraremos el testing manual! ¿No?

Como comenté en ¿Cómo enfoco el testing de forma ágil?, el objetivo de la automatización de pruebas no es eliminar por completo el testing manual, ni suplantar a los testers manuales.
Lo que automatizamos son chequeos, comprobaciones que los testers manuales previamente han detectado antes: ciertas pruebas de regresiónsmoke test etc.
En este enfoque de testing, durante la evolución de un sistema, un caso de prueba comienza siendo manual, para luego ser automatizado.
Así los testers manuales pueden dedicarse a buscar otros bugs más complejos o testear nuevas funcionalidades.
Incluso puede haber ocasiones en las que automatizar alguna prueba o generar las condiciones necesarias para ello sea tan costoso, que sea más rentable mantenerla manual.

¿Y por dónde empezamos a automatizar?

Por otra parte, la calidad del software tiene muchos ámbitos (Calidad del software es mucho más que el testing).
Y dentro de lo que es el testing, existen distintos tipos de pruebas, cada una orientada a detectar y prevenir ciertos tipos de errores en el software.
Probablemente lo que primero suele venirnos a la cabeza cuando oímos hablar de automatización de pruebas son automaciones de “record & play”, por ejemplo con herramientas tipo Selenium IDE, que te permiten simular y grabar tus interacciones con la interfaz de la plataforma, con el navegador web etc.
Depende de qué plataforma, a primera vista pueden resultar las más sencillas de automatizar.
Es cierto que son automatizaciones necesarias, pero no son las que más retorno de inversión aportan, ni las que deberían automatizarse en mayor cantidad.
Principalmente, porque la interfaz de usuario es la parte más propensa a cambios de toda la aplicación, y para automatizar pruebas y tener fiabilidad sobre lo que estamos ejecutando necesitamos cierta estabilidad: un cambio en la interfaz podría hacer fallar la prueba automática, y en ese caso, tendríamos que readaptarla para que volviera a funcionar.
Por eso este tipo de pruebas suelen tener un coste de mantenimiento mayor que el resto.
Sí que tenemos que automatizar las pruebas de interfaz, pero mi consejo es que lo hagas después de haber automatizado otras partes más estables de la aplicación, el núcleo en sí, que aporta más retorno de inversión.
Por ejemplo, un buen primer paso es automatizar los test de API (funciones, elementos que ofrecemos desde nuestro software para que otro software, u otras partes del nuestro, puedan interactuar con él).
Hay varios niveles a la hora de automatizar pruebas. El secreto está en automatizar en el grado adecuado y en los niveles adecuados para nuestra aplicación.

Pirámide de Cohn.

La pirámide de pruebas de Mike Cohn, descrita en su libro Succeeding with Agile, ha sido un referente en este campo durante mucho tiempo.
idealautomatedtestingpyramid
En ella Cohn establece que hay varios niveles de pruebas, y señala el grado en el que deberíamos automatizarlas. Lo ideal sería:
– Muchos tests unitarios automáticos, porque un primer punto primordial para detectar fallos es a nivel de desarrollador. Si una funcionalidad en este punto falla, podrían fallar pruebas de los siguientes niveles: integración, API etc.
– Bastantes tests a nivel de API, integración de componentes, servicios, que son los más estables y candidatos a automatizar.
– Menos tests de interfaz gráfica automatizados. Ya que estos tests son variables, lentos en su ejecución y con muchas dependencias con otros componentes.
Aún así, en este punto, no suelo utilizar esas herramientas de record & play para automatizar pruebas de interfaz de usuario, ya que el código autogenerado por algunas de ellas no es muy mantenible (existen alternativas como Selenium WebDriver, que hace lo mismo pero programando tu el código).
– Un nivel estable de pruebas automáticas, que vayan detectando los testers manuales y se vayan automatizando paulatinamente, para que llegue un momento en el que invirtiendo los mismos recursos logremos cada vez una cobertura mayor de pruebas.

Mala estrategia de automatización: el patrón del “cono de helado”

En la automatización de pruebas hay que tener cuidado, ya que en ciertas ocasiones se tiende a perder el foco y a invertir en automatización en el nivel y grado no adecuado.
Una mala estrategia en estos casos, es lo que llamamos el patrón “del cono de helado”.
softwaretestingicecreamconeantipattern
Como ves es lo contrario a la pirámide de Cohn: centramos el foco en muchas pruebas manuales y en automatizar pruebas de interfaz de usuario, y nada de pruebas unitarias. Con todos los problemas que acarrea no detectar errores en los otros niveles y dejarlo todo para la parte más visible de la aplicación.
Además ten en cuenta, que una buena estrategia de automatización de pruebas conlleva más cosas que solo automatizar las pruebas en sí: crear un buen framework de automatización, parametrizar los tests, las ejecuciones para los distintos entornos, lanzar los test con distintos datos de prueba y gestionar dichos datos, sistemas de logs, buenos reportes con información que sirvan para obtener conclusiones, montar una buena infraestructura contra la que lanzar esos tests, paralelizarlos etc.

miércoles, enero 21, 2015

[scrum] Tareas de un Product Owner

Por definición tenemos que las principales tareas de un Product Owner en un proyecto ágil son:

  • Mantener el Product Backlog refinado y priorizado
  • Velar por el Retorno de la Inversión, logrando que salgan a producción lo más pronto posible las funcionalidades que más retorno le generan al negocio.
Pero miremos al detalle en que trabaja un Product Owner durante un sprint y un proyecto ágil.


Antes de Iniciar el proyecto:
  • Construir con todo el equipo Scrum la Definition of Done
  • Construir un product backlog priorizado y refinado
  • Tener un release plan del producto
  • Construir el presupuesto del proyecto
  • Participar activamente en el Sprint Cero
  • Construir artefactos que sirvan para direccionar y definir el producto, tales como:
    • Impact Map
    • Product Vision Board
    • Product Backlog Board
    • User Story Map
  • Comunicar al equipo la visión del producto, propósito y releases a realizar

Para el Planning

Para la ejecución del Sprint
  • Resolver los impedimientos asignados por el Scrum Master y el Equipo.
  • Resolver dudas durante la construcción del Sprint
  • Realizar reuniones de refinamiento presentando al equipo lo que vendrá para el siguiente sprint
Para el Review
  • Asistir a los review 
  • Aceptar o rechazar las historias de usuario construidas según los criterios de aceptación y Defnition of Done.
  • Presentar los resultados incrementales a los Stakeholders
  • Velar por que se cumpla la Definition of Done
Para la Retrospectiva
  • Participar activamente en las retrospectivas
  • Dar y recibir feedback sobre las mejoras requeridas para cada vez ser un mejor equipo y construir un mejor producto.
En General:
  • Lograr que se obtenga lo antes posible el MVP (Minimo producto viable)
  • (acorde con la anterior) Velar por que se construya primero lo que más retorno le proporcione al proyecto
  • Levantar y especificar historias de usuario con los Stakeholders de forma que se tengan al menos 3 sprints adelantados claros y refinados
  • Mantener actualizado el Release Plan
  • Realizar seguimiento del producto con el Release Burn Up y otras gráficas de seguimiento del producto
  • Vigilar e informar la ejecución presupuestal del proyecto y producto
  • Tener claro, "lo que no se va a construir"

Saludos Ágiles


Jorge Abad

domingo, enero 18, 2015

[scrum] Un buen Team Member

Existen muchos post sobre Product Owner  y el Scrum Master, y es bueno reflexionar sobre ellos pues son roles que estamos comprendiendo y haciendo parte de nuestra cultura TI que tanto tiempo ha estado  RUP-pizada o Waterfall-izada.

Pero sobre los Team Member en scrum, solo sabemos dos elementos claves, el equipo debe ser:
  • multidisciplinario
  • autoorganizado o autogestionado
De igual forma sabemos que los valores del Equipo Scrum ( Team Developer, Scrum Master, Product Owner (1) ) son:
  • Enfoque
  • Coraje
  • Apertura
  • Compromiso
  • Respeto (ver más valores en este post anterior sobre valores ágiles (2)  )
Yo he notado que en la medida que el equipo comienza a tomar vida (pues no es un acto mágico que se convierta en autoorganizado) comienzan a emerger reglas éxplicitas e implícitas sobre los team members que son quienes perciben el latir y son el propósito de scrum (darles el entorno para que ellos produzcan el mejor producto)

Entre esas reglas, he observado varias:
  • En el Planning
    • Hacer preguntas para entender lo que se va a construir
    • No permitir que el equipo se comprometa con cosas que no conoce
    • Poner a disposición de todos mi experiencia para construir correctamente lo que se esta comprometiendo
    • Dar mi estimación responsable.
  • En la Ejecución del Sprint
    • Llegar puntual al daily
    • No dejar tirado a mi equipo con el compromiso (pues estuve en el Planning y junto con todos acepte el sprint backlog)
    • No tener tiempos de ocio "irresponsables*" cuando todo mi equipo esta trabajando por bajar puntos
    • Ayudar a mis compañeros
    • Escribir buen código
    • Realizar buenas pruebas
    • Construir el producto con la calidad inmersa (no postergar la calidad esperando que otros encuentren defectos)
    • Trabajar empleando la mayor cantidad de prácticas ágiles de desarrollo posibles (TDD, ATDD, Integración Continua, etc)
    • Si se identifica algún sobreesfuerzo oculto, levantar la mano y dar visiblidad al equipo y al Scrum Master
    • Preguntar dudas sobre el producto al Product Owner
    • Dar visibilidad y alerta sobre los Impedimentos al equipo y al Scrum Master
    • Dar feedback asertivo a compañeros que perdieron el "foco" y andan muy ocupados en no apoyar al equipo o haciendo nada.
    • Reconocer cuando se esta fallando y corregir camino
    • Ser honesto con el equipo y consigo mismo
    • Mostrar el coraje y foco durante el sprint.
    • Dar visibilidad de la deuda técnica
    • Trabajar por reducir al  máximo la deuda técnica
    • Mejorar las habilidades en el área de fortaleza técnica y trabajar con otros para aprender nuevas tecnologías de manera que se elimine en lo posible el riesgo de dependencias de compañeros de trabajo.
    • Continuar la autoformación técnica
    • Trabajar con coraje para lograr el DONE lo antes posible de cada funcionalidad comprometida
    • Trabajar en lo que está priorizado y no en lo que "me parece"
  • En el Review
    • Tener el review preparado 
    • Dar respuesta asertivas a lo que se requiera
    • Apoyar a que el equipo se luzca en la sesión
  • En la Retrrospectiva
    • Dar y recibir retroalimentación
    • Usar comunicación asertiva con todos los miembros del equipo
    • Reconocer cuando se falla
    • Aportar evidencias para la retrospectiva
    • Decir todo aquello que sienta que debe ser compartido y aporta a la sesión (tanto del punto de vista técnico como humano)
    • Ser honesto con el equipo y con sigo mismo.



Nota:
Este post seguirá en construcción pues este aprendizaje no termina.

---
* Ocio irresponsable (vale la pena aclararlo): no me refiero a los tintos o momentos de pausa que requerimos para seguir avanzando, me refiero - y creo que todos entendemos - a laaaargas y descaradas sesiones en cualquier cosa que no sea una pausa sincera.


Referencias 

Valores Ágiles - Charla de Ágiles 2014 (Parte 2)

Diagrama de Espina de Pescado -  Problemas de Equipos Ágiles


Técnicas para minimizar los problemas: cómo lograr el equilibrio entre los valores ágiles para minimizar los problemas 

Manifiesto ágil: 
  • Individuos e interacciones sobre procesos y herramientas 
    • Entrene en coaching a los gerentes
    • Genere un ambiente agradable para el trabajo
      • Defina políticas de horarios flexibles
      • Establezca programas en los que se tenga en cuenta las ideas de las personas para mejorar el ambiente laboral 
    • Capacitaciones en comunicación asertiva para todos los empleados
  • Software funcionando sobre documentación extensiva:
    • Pídale al cliente que le ponga un “peso” de valor generado a los artefactos
    • Ayúdele al cliente a que priorice por valor
  • Colaboración con el cliente sobre negociación contractual  
    • Permitir escenarios de contratación donde prime la confianza 
  • Respuesta ante el cambio sobre seguir un plan 
    • Trabaje con su equipo en la importancia del cliente y su negocio, de manera que  no vean el cambio como algo que ARRUINA  el entregable hecho, sino que le permite al cliente generar valor y obtener una ventaja competitiva 
Pilares scrum: 

  • Transparencia
    • gestión visual ­ tableros Kanban, Burndown chart  
    • comunicación clara y asertiva
  • Inspección ­ Adaptación 
    • Daily 
    • Review 
    • Retrospectiva 

Valores scrum

  • Compromiso
    • Planning y el review (ver la cara del Cliente)  
    • Defina métricas grupales, no individuales 
    • Permita que las personas elijan en qué van a trabajar  
    • No cree recompensas por desempeños individuales, sino por  
    • desempeños grupales 
    • Logre la verbalización de las metas (decir a que se comprometen)
  • Enfoque
    • Una cosa a la vez 
    • Primero lo más importante y priorizado 
    • Procure que se incluya pago de deuda técnica en cada ciclo de desarrollo 
    • Evite al máximo el sobre esfuerzo
  • Respeto
    • Dar ejemplo 
    • Coach del scrum master al equipo 
    • Comunicación asertiva  y correcta retroalimentación 
    • Comunicación verbal y no verbal  
    • Establezca un proceso de selección con ponderación alta para 
    • las competencias humanas
  • Coraje 
    • Rete al equipo, pídales ir un poco más allá 
    • Cree conexiones entre los diferentes equipos con el fin de que se apoyen técnicamente 
    • Invierta en un sistema de gestión del conocimiento 
    • Conforme los equipos con todas las competencias que requieren para llevar a cabo el trabajo 
  • Apertura
    • Promueva, capacite y habilite la comunicación asertiva 
    • Incentive la comunicación directa para decir las cosas que están pasando, basándose en hechos y conservando el respeto 
    • Permitir las opiniones de todos 
    • Promueva que incluyan propuestas ante los problemas encontrados 
    • Dirija las retroalimentaciones hacia el trabajo en equipo y no al nivel personal 

Un mejor Scrum
  • Confianza
    • Entregue el mando y el control al equipo 
    • Permita que el equipo resuelva sus problemas por sí mismo. 
    • Permita que el equipo se equivoque, aprenderá a conocerse y a tenerse más confianza 
    • Las estimaciones y compromisos los debe realizar el equipo 



Extremme Programming
  • Simplicidad 
    • Fomente el uso de TDD, refactorización y documentación del  código 
  • Comunicación 
    • Procure que los equipos estén ubicados cerca 
    • Enseñe la ccomunicación asertiva (basada en hecho
    • Enseñe los cuatro acuerdos 
      • Sea impecable en sus palabras 
      • No tome nada en forma personal  
      • No adivine ni suponga 
      • Haga siempre lo máximo y lo mejor que pueda 
    • Cambiar los mensajes TU.. por los mensajes YO:
      • Sugerencia para mensajes Yo:  
        • Cuanto tu      (establezca el comportamiento)    
        • Me siento        (establezca el sentimiento)   
        • Entiendo lo que sientes    (empatice con el otro) 
        • Porque     (establezca consecuencia) 
        • Te pido el favor de     (establezca la petición, negocie el cambio)
  • Retroalimentación
    • Retrospectivas 
    • Review







---

Saludos ágiles

Jorge Abad



Valores Ágiles - Charla de Ágiles 2014 (Parte 1)

En el pasado ágiles 2014, tuve la oportunidad de facilitar junto con Leonardo Agudelo - @sweepnoise la sesión de Valores Ágiles - Engranaje clave para equipos autogestionados. Comparto los conceptos tratados en la sesión.


-----------
Definición de valores

Los valores son todas aquellas cosas que creemos importantes para nuestras vidas, en el momento de compartir, trabajar,  estudiar, convivir, etc. Estos valores determinan nuestras prioridades y en el fondo son, probablemente, las medidas que se usan para conocer si nuestra vida está en camino que deseamos.
Fuente;http://www.valoresmorales.net/


----------
Valores del manifiesto por el desarrollo ágil de software 

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Fuente: http://agilemanifesto.org/iso/es/

------------
Pilares que soportan toda la implementación del control de procesos empírico

Transparencia 
Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar común, de tal modo que los observadores compartan un  entendimiento común de lo que se está viendo.

Inspección 
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el mismo lugar de trabajo.

Adaptación 
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.

Fuente: Scrum Guide -http://www.scrumguides.org/

----------
Valores de Scrum por Scrum Alliance

Enfoque. Porque nos enfocamos en sólo unas pocas cosas a la vez, trabajamos bien juntos y producimos un resultado                                    
excelente. De este modo logramos entregar ítems valiosos antes.

Coraje. Porque no estamos solos, nos sentimos apoyados y tenemos más recursos a nuestra disposición. Esto nos da el coraje                                      
para enfrentar desafíos más grandes.

Apertura. Durante el trabajo en conjunto expresamos cotidianamente cómo nos va y qué problemas encontramos. Aprendemos                              
que es bueno manifestar las preocupaciones, para que éstas puedan ser tomadas en cuenta.

Compromiso. Porque tenemos gran control sobre nuestro destino, nos comprometemos más al éxito.

Respeto. A medida que trabajamos juntos, compartiendo éxitos y fracasos, llegamos a respetarnos los unos a los otros y a ayudarnos mutuamente a convertirnos en merecedores de respeto


Fuente: Scrum Alliance - Core Scrum


----------
Valores según el libro: UN MEJOR SCRUM


  • Respeto 
    • por uno mismo
    • por los otros
  • Coraje
  • Confianza : Base fundamental para el trabajo en Scrum. Un alto grado de confianza y compromiso es un resultado que se obtiene siempre que se forme un equipo verdaderamente auto­organizado.




Fuente: Un Mejor Scrum


---------

Valores de eXtreme Programming (XP) 

Simplicidad. Hacemos lo que se requiere y es solicitado, pero no más. Esto maximizará el valor creado para la inversión realizada. Daremos pequeños y simples pasos hacia nuestra meta y se mitigarán las fallas a medida que ocurran. Crearemos algo de lo que estaremos orgullosos y lo mantendremos a largo plazo por costos razonables.

Comunicación. Todos somos parte del equipo y nos comunicamos cara a cara diariamente. Trabajaremos juntos en todo, desde los requerimientos hasta la codificación. Crearemos unidos la mejor solución que podamos para nuestro problema.

Retroalimentación. Tomaremos cada compromiso de iteración seriamente entregando software funcional. Demostramos nuestro software de manera temprana y seguida, luego escuchamos atentamente y hacemos los cambios requeridos.Hablaremos acerca del proyecto y adaptaremos nuestro proceso al mismo y no de otras maneras.

Respeto: Todos dan y sienten el respeto que se merecen como un miembros valiosos del equipo. Todos aportan valor, incluso si es simplemente con entusiasmo. Los desarrolladores respetan la experticia de los clientes y viceversa. La gerencia respeta nuestro derecho de aceptar la responsabilidad y de dirigir nuestro propio trabajo.

Coraje. Diremos la verdad acerca de nuestro progreso y estimaciones. No documentamos excusas para el fracaso porque tenemos la intención de tener éxito. No le tememos a nada porque nadie está trabajando solo. Nos adaptaremos a los cambios cuando sea que ocurran.


Fuente: http://www.extremeprogramming.org/values.html

-------

Relación entre los valores:

Mapa Conceptual: Relación entre valores ágiles (elaboración propia - Jorge Abad y Leonardo Agudelo)



Ver parte 2: Valores Ágiles - Charla de Ágiles 2014 (Parte 2)








martes, enero 13, 2015

Leído y Recomendado: La Definición de “Ready” es tan importante como la Definición de “Done”

Excelente artículo de Johnny Ordoñez




De colección, super-recomendado

Lo copio para tener registro...

_____




La Definición de “Ready” es tan importante como la Definición de “Done”


Ready
Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie
Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.
Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.
Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.

La Definición de “Ready” o DoR

Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.
Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):
  • Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
  • Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
  • Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
  • De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
  • Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
  • Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
  • Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
  • Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.
Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):
  • Sprint plannings más rápidos;
  • Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente;
  • Gestión colaborativa del backlog;
  • Feedback temprano;
  • Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
  • Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
  • Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
  • Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.
Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.
Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.
Gracias, y que la agilidad esté con Ustedes.
Johnny