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.
Fuentes ;http://www.valoresmorales.net/ | http://comofuncionaque.com/que-es-el-valor/


----------
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 antes del partido, luego de haber estado entrenando y estar concentrados con la estrategia clara 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 se ufana 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 visualización constante de los resultados y avance debido a la transparencia
  • 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 (con estrés negativo) por algo que todos intuyen, presienten 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?