you´re ready for the daily meeting but you…

you´re ready for the daily meeting, but you find that the team says, “The Project Leader will not come to work today, so today we do not meet …”
WHAAAAAT? really believe that this meeting has to do with a report to a boss?
You do not agree that this meeting serves to synchronize our activities and know where we stand?
what if one of us faces a risk and do not even recognize? Others may discover it before you do at that meeting.
And if what you’re doing is not right for the objectives? could avoid working on things that do not add value to the project, if you talk between partners

Advertisements

The meaning of “DONE”

These are the words of somebody trying to explain what it mean “DONE” in his team context:

When you have completed work on your currently assigned Sprint Backlog Item, you must ensure that “it is done” before assigning it to the Tester. The definition of a Sprint Backlog Item being done is:

* All facets of the Sprint Backlog Item are satisfied (including creative content such as images / general design)

* Test cases have been updated – or if it’s a new feature – created.

* The code is fully commented – not just method headers – write “the whys” behind your reasoning.

* You have created a unit test where possible – this can either be a normal unit test or a WATIR script

* You have run a Dev Build and it has completed successfully

* If you’ve worked on a new feature or a complex bug fix – you’ve done a buddy build and got your buddy to do a code review.

* You have linked the Source Control ChangeSet to the Sprint Backlog Item

* Once your Sprint Backlog Item has fulfilled these criteria – ensure that the state field of the Sprint Backlog item is “In Progress” and change the “Owned By” field to the user id of the Tester. Once the Sprint Backlog Item has been tested and passed it will be marked as “Done”.

If a bug is discovered a new Sprint Backlog Item (with Sprint Backlog Type set to “Bug”) will be created, linked to the original Sprint Backlog Task and then assigned to the developer who created the feature. This cycle should be repeated until all Sprint Backlog Items are marked as “Done” and are ready to be deployed in the next release.

Ok, but all of us could complain telling “hey this is a kind of mini-waterfall” embedding in Scrum framework, and all of us would be right, but it’s not prohibited to do it in the explained way.
However my intention was also try to explain that done means those things that the team decided and conceptually this meaning will help to the team to generate the best work team process.

vía Testing – Scrum for Team System.

QA-Testing en SCRUM

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3), o dos (1), serán mitad de desarrollo y mitad de testing? ¿como se gestionan los defectos en tiempos tan acotados? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuar codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

 

 

 

 

 

 

 

 

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros en tantos años de vida de Agile. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y te aseguro que en SCRUM no está estipulado como es el proceso de testing y calidad. Pero eso está bien por cuanto Scrum no es prescriptivo hasta el punto de definir “cómo hacer el trabajo” del equipo.

Leí varios libros sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas por adelantado. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos (la cual es mayormente deseada en los negocios actuales), como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos (inclusive dentro del Sprint en curso).
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando la historia del usuario es expuesta al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible, pero es mejor dejar de pensar en fases tan marcadas. Que opinas de colaborar todo el tiempo con lo que sabes, con lo que entiendes? Seguramente será más beneficioso para todos en términos de “descubrimiento de la feature” y/o “descubrimiento del product”, si te involucras y con tus opiniones generas mínimamente dudas.
    No considerarías a esto mismo TESTING?
  • ¿Tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional. Lo que puedes hacer sabiendo que cuentas con los recursos necesarios y adecuados (interación plena, coordinación y colaboración, pero principalmente la involucración), es gestionar de un modo colaborativo, es decir con la opinión de todos a tus sugerencias y propuestas de planificación, así probablemente ya no existirán más los clásicos problemas de “responsabilidad de un rol”, porque el resultado será algo funcional a todos y generado por todos.
  • Mientras se hace testing los desarrolladores codifican y mientras reportas fallos, ellos corrigen, al rato lo verificas. Para eso está el trabajo en equipo, solo hay que consensuarlo y organizarlo.
    Aunque está mal visto en los paradígmas tradicionales, los desarrolladores serán eventualmente los mejores testers; puedo asegurar que visto que es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo en general, no solo a QAs.
    En el mismo iterín, los desarrolladores también adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
  • La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos.
  • Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento, va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Para que esto no quede con un amargo sabor, te paso este enlace que podrá al menos darte una idea de como iniciar, pero te repito, aprende por tu cuenta pues no hay recetas.

¿Por que participar del Córdoba Agile Open 2010?

El día 8 de mayo de 2010 desde las 9 am y hasta las 5pm, se llevará a cabo el evento conocido como Agile Open Córdoba 2010, con la temática AGILES EN LA PRÁCTICA.

1. Nos reuniremos 100 o más personas con intereses similares basados en el desarrollo del software
(gerentes, analistas de negocios, líderes (proyectos, testing), desarrolladores y testers, etc.)
2. El evento se realizará un día sábado (8 de mayo) para que todos podamos asistir libremente, fuera de nuestros horarios laborales.
3. Será una excelente oportunidad para realizar Networking, por lo que les recomiendo hacer sus tarjetas de presentaciones, pero sobre todo ir dispuestos a conversar con la gente y aprender de otras experiencias
4. Podremos seleccionar una variedad de sesiones a las que nos interese asistir, de una grilla temática propuesta y rankeada por los mismos asistentes al evento. Cada sesión debe cobrar vida por si misma y allí podrán, o bien guiarla (si son los proponentes de la sesión) o bien alimentarla con sus
propias experiencias y/o conocimientos. No están obligados a quedarse en las sesiones que no son de su interés, ni forzar a que la misma tenga
un resultado distinto al que tenga lógicamente.
5. Utilizaremos el formato OpenSpace (http://www.openspaceworld.org/cgi/iberia.cgi?SobreelEspacioAbierto) el cual nos orienta desde el inicio de la sesión a resolver situaciones de caos de forma creativa e inspiradora, aún con una enorme diversidad de personas e intereses, siempre siguiendo un formato plano (sin jerarquías).
6. Impulsaremos la creación de comunidad activa, lo cual significa que es una oportunidad para el nacimiento de grupos de personas (más allá de Agile), para reunirse con cierta frecuencia a tratar los asuntos que interesen, practicando, promoviendo y/o proponiendo.

Visiten la página oficial del evento y regístrense. Este es un paso muy importante para los organizadores.
http://www.agiles.org/agile-open-cordoba-2010/

Los espero a todos 🙂

¿CMMI o AGILE? ¿Juntos es posible?

CMMI tiene una carga y una exigencia que equipos conformados AGILE (típicamente pequeños) no pueden soportar, simplemente por que no tienen la estructura de personal. Al menos eso sucede con equipos para SCRUM.

Ejemplos sencillos son las exigencias de CMMI-2 sobre las Áreas de Proceso “Planificación de Proyectos” y “Aseguramiento de Calidad”, donde están vigentes los “Procedimientos de Planificación de Proyectos” y “Procedimientos de Estimación y Presupuestación”, como los “Procedimientos de Planificación de Calidad” y “Procedimientos de Auditoria y Revisiones”.

Estas solas áreas de procesos exigidas por CMMI-2 y sus correspondientes procedimientos pueden poner "en jacke" a quienes sostienen que con un equipo pequeño es posible certificar CMMI-2 o 3, dado que para solo cumplimentar las prácticas específicas para esos dos procedimientos que mencionas, necesitas de un equipo QA completo y al menos dos niveles de gerencia para escalar las aprobaciones.
La Planificación de Proyectos para CMMI es lo que me parece crítico y no es fácilmente adaptable a equipos SCRUM, por que es necesario formar y tener aprobado el Cronograma del Proyecto, lo cual por si mismo significa haber confeccionado un Plan de Iteraciones, Plan de Participación de los Interesados y un Plan de Integración, más un Plan de Riesgos, un Plan de Decisiones Técnicas y un Plan de Capacitaciones o certificar en una matriz de capacitaciones organizacionales, que para iniciar el proyecto el equipo del proyecto tiene las habilidades requeridas.
En lo que a calidad se refiere, debe existir documentación objetiva y sólida confeccionada por el Líder de Proyecto (no Gerente de Calidad ni Líder de Testing) sobre los Objetivos de Calidad y Performance y eventualmente utilizar procedimientos de Gestión de Cambios para modificar requerimientos u objetivos de calidad cuando existen contraposiciones y Procedimientos de Análisis y Toma de Decisiones para establecer esos cambios. Finalmente se debe registrar cuales objetivos se gestionarán estadísticamente.
Si quieres podemos hablar de las revisiones por pares, las cuales no están referidas a (pair programing) sino que son prácticas específicas para un muy alto porcentaje de los productos de software generados.
Todas estas decisiones, principalmente Gestión de Cambio y Toma de Decisiones, se realizan por comité organizacional.
Si considero interesante y posible que la agilidad se puede insertar en toda la organización con prácticas como SCRUM (…muchas otras…según), pero debemos conseguir de una vez por todas que nuestras soluciones de consultoría Agile trasciendan el ámbito del área de desarrollo, por que lamentablemente hasta el día de hoy son pocas las organizaciones que lograron traspasar esa barrera en las organizaciones de envergadura mediana o grande.
Un simple ejemplo es que ni a duras penas logran unificar un criterio para establecer prácticas en Testing o sostener un circuito de auditorías de calidad, sin pretender absorber este departamento QA hasta hacerlo desaparecer para conformarse en el equipo de desarrollo.
Para acercarme a una conclusión, estoy seguro que la simplificación de los procesos debe hacerse concienzudamente, sin ofrecer a las organizaciones "recetas de menudencias" que en un principio parecen ser buenas, pero a la larga podrían dejar el sabor insípido de la pérdida de prácticas que alimentan la base del conocimiento organizacional.

CMMI/Agile. Un híbrido que se viene – III

Si estamos de acuerdo, podremos admitir que la agilidad es buscada por cientos de industrias hace varias décadas y la industria del software es nada más que un aprendiz de otras mucho más desarrolladas.

El concepto de agilidad está trascendiendo las fronteras de los modelos desarrollados hasta el día de hoy, tanto es así que cada una de las organizaciones que deciden adaptar su modelo de producción, no lo hacen bajo una modalidad pura y prefiere hacerlo bajo un contexto de hibridez.

"Ambos mundos" (Waterfall – Agile), si es que se les quiere diferenciar, aportan herramientas valiosísimas al desarrollo del software.

Según comentarios, empresas puramente CMMI5 decidieron hacer pruebas pilotos con gestión SCRUM y desarrollo XP.

Los informes internos indicaron la detección de prácticas comunes con variaciones o simplificaciones por parte de SCRUM principalmente, pero también en XP. Es decir que con un espíritu diferente quizás, CMMI ya contaba con ciertas prácticas que “debieron recortar” para hacer las adaptaciones. El pasaje fue prácticamente limpio.

Los informes indicaron que con una concepción diferente, es posible que el modelo Agile en piloto, sea más adecuado para el objetivo de velocidad y respuesta a los cambios, pero no para el objetivo de repetitividad, métricas y mejora continua, mucho menos para la  transmisión de la ingeniería del producto y servicios, a otros equipos diseminados por el mundo.

Estas conclusiones restringidas a un ámbito privado de la organización, permitieron a los evaluadores realizar recomendaciones para adaptar las prácticas del modelo CMMI, tomando como referencias algunas buenas prácticas de XP para desarrollo y SCRUM para gestión, considerándolos en su modo puro, inconveniente para la organización.

Claro que el equipo piloto adoptó las prácticas Agiles guiados por la "documentación estrictamente necesaria" y focalizándose en la codificación, eliminando mucha información que la organización estaba acostumbrada a llevar, no solo para conocer el estado del proyecto, sino también para conocer el estado de la organización, donde los proyectos activos superan el número de cien (100).

Mi apreciación personal es que las metodologías puras no van a subsistir modificándose para dar surgimiento a lo que se conoce como metodologías híbridas y necesariamente, solo por lógica, serán la conjunción de las mejores prácticas de "ambos mundos" (Waterfall .  Agile).

Inicialmente Agile pareciera haber reaccionado a lo estructurado y predictivo de Waterfall, pero actualmente veo como Agile tiene adeptos rígidos a quienes les cuesta hasta interiorizarse de otras metodologías con más estructuración. También observo axiomas puristas en los que imparten ideas, descartando de llano la conjunción, las mixturas, lo adecuado a cada organización y en sus funciones de facilitadores podrían quitar de raíz prácticas avaladas con éxito en las organizaciones.

En contrapartida veo a gente del mundo Waterfall adaptando las propuestas del mundo agilista, sin dejar de lado el espíritu de la mejora continua basada en procesos.  

La evolución no se detiene, pero no vaya a ser que los que verdaderamente revolucionen la industria del software, sean los ágiles nacidos de las metodologías Waterfall.

Sea como sea nos conviene a todos.

Open Agile Córdoba 2009 finalizó exitosamente

Reunirse es el principio; continuar juntos es el progreso; trabajar juntos es el éxito.

Henry Ford –

El viernes 17 de abril finalizó el evento Open Agile Córdoba con una interesante concurrencia, principalmente de la provincia de Córdoba, Argentina, pero con algunos adeptos de Bolivia y Chile, como así también los coorganizadores de Buenos Aires que dieron apoyo logístico durante todo el evento.

Como ya lo he mencionado en otros artículos, el formato de presentación fue simil Open Space, donde el predominio fue la modalidad debate para distintas temáticas como Introducción a Scrum, Planificación y Estimación Agile, Testing Agile, Entorno Agiles, Contratos Agiles, Híbridos, Distribuidos, Pain Driver Facilitation, ¿Por que Agile?, Técnicas Agile (XP), Comunicación y Roles Agile, entre otros.

El evento en si mismo fue exitoso por su buena organización, donde se destaca la participación y guía de los organizadores tanto de Córdoba como de Buenos Aires y el prestigioso marco que le dio la institución IES21.

Lo realmente bueno del evento, es que allí concurrieron por iniciativa propia, representantes de diferentes organizaciones de renombre como, Motorola, INTEL, INTI y por supuesto muchas otras organizaciones de menor porte. Todos interesados en comprender que es todo esto de las ”metodologías Agiles”.

Algunos puntos débiles podrían ser considerados para mitigarlos en eventos futuros de esta misma naturaleza. Por ejemplo al inicio del evento se podría haber incluido una introducción a las metodologías Agiles, quizás mencionando los postulados del Manifiesto Agile y explicando que significa y como se contrapone a lo que la mayoría de nosotros conocemos por herencia de nuestros trabajos y educación.

Este momento tan importante debería haber sido utilizado mejor, aprovechando la presencia de todos en un único lugar, para darle un “marco desmitificado” para todos. Note un gran estrabismo inicial formando parte del caos propuesto (cosa necesaria) donde las personas se acoplaron a las temáticas, muchas veces sin saber por que o por que “algo les suena”.

Otro aspecto que me hubiera gustado es que lográramos discutir de modo masivo y de manera resumida, por que nos interesa un cambio en nuestra organización, y si es que realmente lo consideramos necesario, cuanto sabemos de la metodología que utilizamos actualmente, que apertura hay para un cambio en nuestros líderes y pares, etc.

Me hubiera gustado que quede claro al inicio mismo, cual es el modo de trabajo predominante en la actualidad, para todos los presentes.
¿Por que? simplemente por que marca el precedente cultural y el esquema existente a respetar al hacer “propuestas Agiles”, sin atinar al facilismo de decir cosas como “Testing y Desarrollo deben ser uno solo sin divisiones”, o cosas por el estilo que demuestran rigidez mental.

Hubiera sido bueno que OpenSpace no dejara temas sin concluir. Para esto es necesaria la participación de un moderador con la experiencia en el tópico que se discute (asistí a sesiones muy bien moderadas) y la posibilidad de extensiones de tiempo para las sesiones donde sus participantes hayan encontrado “el clic de la cuestión” y desean finalizar con una conclusión.
Creo que todas las sesiones en mayor o menor medida, tuvieron ese sabor amargo de la insatisfacción, algunas por no haber logrado un desarrollo óptimo (me pasó con las sesiones de Testing Agile y Pain Driven Facilitation) y otros por no haber tenido más tiempo para llegar al desenlace (me pasó con las sesiones de Planificación/Estimación y Contratos Agiles).

Tuve la suerte de participar en sesiones que moderó Fabio Grigorjev (Planificación/Estimación y Contratos Agiles) quien supo salir al cruce de todas las preguntas y/o planteos con respuestas bien enfocadas a un sentido práctico y aplicable. Fue notable su capacidad de expresión práctica y sintética, muy lejos de toda filosofía y bien cerca del “aplicable cotidiano”. 
Los participantes también mostraron su habilidad en el contexto de las estimaciones y planificaciones y ayudaron a una sesión bien discutida pero encarrilada.

No disfruté de la sesión PDF donde se hizo una suerte de “ensayo del pragmatismo del dolor” con los participantes, quienes al final tuvieron que tratar de darle un sentido a la temática general.
En si mismo el concepto planteado me pareció bueno, pues pretendió indicar cual es la actitud del consultor Agile en una organización que lo requiera. Pero tales conceptos basados en detección de elementos nocivos del proceso de trabajo y preguntas orientativas, no son innovadores dado a que que sale de las prácticas del Coaching.
La actitud del moderador fue la de una propuesta ingenua para la cual cada quien debía encontrar un sentido. Creo que esto le fue más útil al moderador que al publico en general.

No disfruté de la sesión Testing Agile pues no logramos hacer un planteo concreto o hacer una marca que logre diferenciar el Testing tradicional del Agile. Allí estábamos personas que en distintos grados teníamos experiencias concretas con las actividades de Testing tanto en metodologías Waterfall como Agiles o sus adaptaciones. También estuvieron quienes conocían de métricas y aseguramiento de calidad.
Demasiado pronto hablaron quienes piensan que por que no siguen una metodología estructurada de Testing hacen Testing Agile. Pronto surgieron las opiniones ligeras proponiendo que Testing Agile no se puede hacer desde un ámbito independiente al de desarrollo.
Se expuso a la automatización como guía fundamental para la agilidad del Testing, Pronto surgió mi oposición a tal precepto, pero no lo debatimos por que lamentablemente, dos o tres se apoderaron de la sesión discutiendo sobre un asunto de concurrencia en un caso de prueba particular y la reunión se desvirtuó.
Me consta que quien estuvo allí y en su organización hace Testing Waterfall, lo seguirá haciendo por que no vio nada que le pueda ser útil y aplicable en su organización.

Creo también que algunas sesiones quedaron desperdigadas en varias salas, siendo de la misma naturaleza y lamentablemente por haberse desarrollado por separado, no aportaron a una construcción heterogénea.

Finalmente, todo lo que empieza termina y ahora nos queda a todos, decidir en que momento nos encontramos. Si ya nos reunimos por primera vez tal vez estamos en un principio, si nos juntamos nuevamente, como comunidad local, regional, latinoamericana e internacional, tal vez progresemos y si logramos trabajar juntos, más allá de los actuales laburantes de los Open Agile, es posible que el éxito nos devenga.