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

Scrum: Un flujo de trabajo "TENSIONADITO BACANO"

Bacano (según la RAE): adj. Chile, Col. y Cuba. En lenguaje juvenil, muy bueno, estupendo, excelente.
--

Tensionadito bacano*, expresión de Hernán Darío –Bolillo- Gómez (extécnico de la selección Colombia), empleado por René Higuita (exarquero también de la selección Colombia) y muy usado por el gremio futbolero en mi país (obvio: Colombia), cuando quieren hablar de ese pequeño vértigo que se siente ante del partido, luego de haber estado entrenando y estar concentrados con la estrategia para enfrentar al rival

Entre otros significados de este adjetivo compuesto por dos palabras, es un estado de:


  • Estrés con emoción positiva
  • Estrés chévere
  • Presionado por la situación, pero manejable
  • Con cierta presión, pero con una pequeña dosis de adrenalina que hace sentir energizado.


La idea es que en scrum he notado que el equipo vive en esa emoción, no vive estresado, ni angustiado como al final de la entrega de un proyecto donde la energía del equipo se desgasta y muchas veces las relaciones entre todos se desgastan.

En Scrum como dice uno de los principios ágiles (http://agilemanifesto.org/iso/es/principles.html):

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida”

Es cierto, en Scrum no gusta de trabajar jornadas extenuantes por muchas y muchas semanas, como cuando se hace la entrega de un proyecto (o fase) en un proyecto cascada (y/o WaterRUP) donde muchas veces nos demoramos el 90% del tiempo tratando de cerrar el “supuesto” 10% que nos faltaba.

Es mejor estar con un compromiso constante, con un “tensionadito bacano” generado por los:


  • Planning
  • Dailys
  • Reviews
  • Retrospectivas
  • La posibilidad de salir en cualquier momento a producción con nuestros incrementos que cumplen la DoD - Definition of Done.
  • La autogestión y autocrítica del equipo
  • El Product Owner con su continua entrega de historias tanto en los planning como en los refinamientos.
  • La entrega continua de historias de usuario con valor 
  • El Scrum Master ayudando a que funcione scrum y funcione el equipo y los miembros del equipo correctamente en sus roles.
  • entre otros


Esto es mejor que estar relajado al inicio en las fases en que se levantan requerimientos y arquitectura, y estar sufriendo al final estresados por algo que todos intuyen (o saben) que con seguridad no se entregará a tiempo..

Saludos Ágiles

Jorge Abad.


(*) Esta expresión se la escuche inicialmente al CEO de Pragma (www.pragma.com.co) : Marcos Vélez en mi paso por esa organización en el 2011



lunes, enero 12, 2015

Leído y Recomendado: Transitioning from a Traditional Tester to an Agile Tester



http://www.techwell.com/2015/01/transitioning-traditional-tester-agile-tester


lo copiaré por acá por miedo a que se pierda..

excelente post ( de colección)


_________

Transitioning from a Traditional Tester to an Agile Tester


One of the most challenging changes any organization can make is moving from a traditional lifecycle development approach to an agile one. As such, there are many books, articles, blogs, and consulting firms that aim to assist with this transition.
One question I'm often asked is "What's the difference between a tester's role in a traditional lifecycle model versus in an agile methodology?” The answer is not an easy one. There are many factors to consider, and any individual tester's or test team's experience will vary based on the organizational environment, culture, and the technology being tested.
There is a spectrum of differences, ranging from redefining the testing role and responsibilities completely to making only minor changes in context and accountability. Some individual testers and test teams will find this transition easy because it's very close to the way they are already working; other individuals and teams will find the transition much more difficult, to the extent that they may need to reinvent themselves.
At the risk of oversimplifying, here are a few key differences in the context, responsibilities, behaviors, and expectations of an agile tester versus a traditional tester.
As an Agile Tester
As a Traditional Tester
Testing is conducted immediately and continually as soon as possible, with the smallest feature(s) available. Test-driven development is employed.
Testers usually wait on a specific build or release and then begin testing once most features are implemented.
Testing is planned as part of the sprint and the release. Developers automate unit tests. Functional and nonfunctional testing is conducted iteratively within the team and in collaboration with the product owner.
One phase of testing usually builds on the next—unit, then integration, then system, then acceptance.
Bug identification and repair is in hours rather than days or weeks.
There is significant wait time between bugs being identified and bugs getting fixed.
Developers and testers operate as one team and interact continuously and collaboratively. The testing voice is equally represented.
Testers are less a part of the development team. Testers may be more distant in interaction and communication with developers and may have less of a voice.
Testers and developers are part of a homogeneous team accountable for quality delivery of the system under test.
Testers are accountable for testing. Developers are accountable for developing.
Testing is continuous and all quality steps are planned and executed iteratively by the agile team.
While the goal is always to have quality built in at every step in the lifecycle, in practice, much of the checking (quality steps) occurs during the backend testing cycle.
Automation is a must have, particularly for unit tests, as it supports continuous integration.
Automation is not a necessity because most testing of new development is done manually.
What are other key differences between the traditional testing role and the role of a tester in an agile environment?