Agile Testing Cuadrants

Lysa Crispin en su libro Agile Testing http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/ref=sr_1_1?ie=UTF8&qid=1317232671&sr=8-1 presenta un diagrama que me pareció interesante comentar, el diagrama es el siguiente y viene de la pagina 98

El eje horizontal va desde lo mas tecnológico hasta lo mas orientado al negocio, desde luego ambas cosas tienen valor y la segunda se funda en la primera. En el eje vertical en cambio hay dos caras, una que apunta a contribuir con tests que apoyen de alguna manera las labores de testo del equipo y la otra que se orienta a criticar el producto.

Apoyar al equipo con testeo manual no siempre es la forma mas efectiva como puede deducirse de este diagrama, el testeo tiene un gran valor pero se vuelve aun mas valioso cuando deja de ser una tarea mecánica y se convierte en una tarea exploratoria tendiente no solo a buscar defectos sino oportunidades de mejora para el software.

Esta división en cuadrantes también ayuda a identificar quien testea que o que habilidades y herramientas son requeridas para realizar cada tipo de testeo. Por el ejemplo los tipos de testeo que caen en el cuadrante Q1 son testeos realizados principalmente por los desarrolladores y requieren de un enfoque como Test Driven Development. Los unit test no son generalmente escritos por un equipo separados de testers, son los mismos desarrolladores quienes tienen que producirlos y mantenerlos. La idea aquí es simple: construir el test primero y luego recién hacer el código que pase el test. Un detalle importante es que los test generados en este cuadrante no se crean automáticamente, hay que invertir tiempo en crearlos y mantenerlos. La parte que si se automatiza es la incorporación de esos test en un proceso de generación de builds diarios.

El cuadrante Q2 es el clásico testeo de funcionalidad orientado a verificar que todas las partes encajen y estén funcionando correctamente, correctamente desde el punto de los user stories y las especificaciones que se desarrollaron en torno a los mismos. Este tipo de testeo esta orientado también a ver que todo lo que se prometió construir se haya construido, en otras palabras que el backlog se haya traducido en features incorporados a un software.

Q3 es sin duda el cuadrante que mas valor de negocio aporta al testeo, la estrella de este cuadrante para mi es el testo exploratorio que se basa en el conocimiento experto y la intuición de los testers. Este tipo de testeo no solamente se limita a mirar el producto como es hoy en día, sino explora y compara el producto con otros productos similares y aporta ideas de hacia donde podría evolucionar el software. Personalmente me gusta pensar en el testeo exploratorio desde dos ángulos: el primero orientado hacia la exploración interna del producto y el segundo hacia la exploración del ámbito de negocio donde coexiste el producto.La exploración interna esta orientada a descubrir bugs y limitaciones mientras que la exploración externa busca oportunidades y amenazas.

Finalmente el cuadrante Q4 se basa en el premisa de utilizar herramientas externas (o internas si hay los recursos para desarrollarlas) que sirvan para generar escenarios en los cuales el sistema sea probado con grandes volúmenes de datos o tenga tiempos de respuesta que no pueden pasar de ciertos umbrales. Estos tipos de testeo son igualmente valiosos y son clave a la hora de garantizar que un producto puedo escalar de muy pocos usuarios y transacciones hacia volúmenes significativos.

Curso de Certified Scrum Master en Santa Cruz de la Sierra

En el mes de noviembre de este año tendremos el primer curso de Certified Scrum Master que sera dictado por Heitor Roriz, CST. La información de este curso se encuentra en este link http://www.scrumalliance.org/courses/20112927-certified-scrummaster

Rigidez en Scrum?

Yo aporto con lo siguiente, ¿alguien podría decir que el karate es rígido? Pues al principio si lo es, rígido y repetitivo. Después de todos los movimientos del karate provienen de generaciones de practicantes que perfeccionaron cada movimiento y la forma como ensenarlo.

¿Ahora qué ocurre con los aprendices que consideran abandonar el karate porque es rígido? Pues lo abandonan con la impresión de que es un arte obsoleto e ineficiente para cualquier fin que tengan en mente.

¿Pero qué ocurre con los que perseveran y continúan practicando? Eventualmente superan la parte mecánica del aprendizaje y crean su propia visión basada en los principios recibidos. En un siguiente paso estos practicantes aprenden otros artes y los fusionan con lo que conocen y crean sus propias escuelas y llevan el arte al siguiente nivel.

Este proceso se conoce como Shu-Ha-Ri (aprender, desprenderse, trascender) y es muy similar al proceso de aprendizaje de cualquier cosa. Obviamente en la etapa de Shu todo luce rígido y de ahí la tentación es abandonar o modificar pero sin todavía tener el conocimiento suficiente como para hacer una buena adaptación. Piensen nuevamente en un karateca que en la segunda semana de práctica decide incorporar movimientos de aikido o decide "recortar" el arte eliminando ciertas patadas, ¿tendría sentido?

Para cerrar mi consejo es siempre continuar buscando que hay mas allá de la aparente rigidez, primero aplicar las reglas, luego criticarlas, luego adaptarlas y luego recién evolucionarlas. Esto es como un camino de iluminación que al igual que en las artes marciales requiere tiempo, paciencia, disciplina y algunos huesos rotos :)

LeanEssays: How Cadence Predicts Process

LeanEssays: How Cadence Predicts Process: "If you want to learn a lot about a software development organization very quickly, there are a few simple questions you might ask. You might..."

It's been really refreshing reading this post From Mary Poppendieck, I recommend it a lot.

The Mythical Scrum Master

I´m seeing many job posts requesting for Scrum Masters for all type of companies. Seems like more and more Scrum Masters are on high demand as they´re perceived as the ultimate professionals in our field. Still perceptions can be misleading, so let me take you back to the very definition of what an Scrum Master is (or should be).

• A Scrum Master is somebody from the team, not an outsider.
• A Scrum Master does engineering work; this is not a management position.
• As a result a Scrum Master is only assigned to one team. Actually is not assigned, is more like somebody from the team that bubble up as a potential Scrum Master.
• Scrum Masters are Scrum champions and enthusiasts, not “master” in the sense that they have the more in deep knowledge of Scrum. They know Scrum well enough to make it work for a team and guide others to learn and practice good Scrum.
• The Scrum Master title is nothing more like a role that an engineer in the team takes. Is not a position per se, is more like a role that can and should rotate among team members.
• Scrum Masters are not responsible for team´s success or failure; at the most they are responsible for the team making good or bad use of Scrum principles.
• Scrum Masters are not necessarily technology masters, they don´t have all the answers, but they can help their teams to find the right answers via collaborative work.
• Scrum Masters in reality are masters in finding ways for keeping their teams aligned and pushing in the same direction.
• Scrum Masters are like “buffer men”, they keep outsiders at the bay but are wise enough to allow the team to open for not becoming a silo.
• Good Scrum Masters are individuals that volunteer for taking the challenge to learn and help their teams to practice good Scrum.

A quick note here, what is good Scrum? Is short, this is a simple set of principles that works for your team but that still fall inside the Scrum framework. Scrum Master are not there for reinventing Scrum, just for digesting it and being humble enough to serve their teams in the journey of learning and practicing Scrum.

Agile 2010

The Agile Alliance has confirmed that the 2010 conference will be in Orlando-Florida the second week of August

http://agile2010.agilealliance.org/

I´ll be there and hopefully this time I´ll have some time to visit Disney World :)

Agile Estimation and Planning: Demystifying the Black Art

This article is not about how to do estimation and planning in detail for Scrum teams, no magic recipes or silver bullets, it´s not also about numerical models or techniques one hundred percent bullet proof. This is more about what I saw that it works in practice and how this correlates with Agile and Scrum values.

That been said and if still have your attention, let me start saying that I´ve borrowed the phrase "Demystifying the Black Art" from a Steve McConnell´s book. I did this for a very good reason, I´ve read that book many times and my only conclusion is that is impossible to provide accurate estimations for the simple reason that no one can predict the future. Understanding this simple fact prepare us for start doing Scrum estimations. Part of the preparation is, if you´re a manager, that you´ll need to resign to have everything accurately estimated before work even started.

But then what? Are Scrum projects totally chaotic? In a way, yes they are, the great difference though is that Scrum publicly recognizes that chaos is there, embraced it and prepares your mind set to cope with continuous change and adaptation.

Reestimate, Reestimate, ….

So, the new game becomes now not how good am I estimating, but rather how often I reestimate. Estimations in Scrum are not cemented deals, they are negotiable as work progresses through sprints, but then, how I can keep things under control without exhausting my team by adding more and more work? Answer is simple; if you add work then you move less priority work to the backlog and reestimate accordingly.

Again, is not a matter of having precise estimations, is a matter of being prepared to reestimate whenever is necessary. Further, there´s a learning curve that Scrum take full advantage of it. For instance, if you estimate a task and then keep your estimations even if you know they are not longer valid, then there´s no chance to refine them with new information and experience. Scrum on the contrary favors that you look and your estimations and make them up as many times as you feel so.

Last part sounds like nightmare for many managers, but come on, reestimating not only means that the number of hours will increase; frequently reestimations take things in the other direction. After all, everybody knows that people try to be over-conservative when providing initial estimations. So if you reestimate, there´s a fair good chance that you reduce the initial slack that you put just in case things get ugly.

No Black Art Anymore

But wait, estimation is still black art, something is missing and that is how to actually estimate. You can read many good books on the subject written by Mike Cohn, even attend to his seminars if you can afford it, but here´s is my simple and free advice: use group estimation. Estimations that are provided not only by one individual but by a group have more value and more chances to be not so much off the mark, why? Only because group estimations force the group to think it through before putting estimates.

Another piece of free advice, actually this comes from McConnell, estimate using ranges like thinking first in worst case estimates, then in best case estimates and put your more realistic estimate somewhere inside that range. Again, if you think in this as a group exercise you´d have more chances to make it successful, at least it won´t be boring :)

But what if the group can´t come to an agreement? Well you can buy the Cohn´s planning poker decks; note that you´ll need one deck per each individual in your team. I offer you a cheaper and in some cultures more fun solution: just vote using your fingers to indicate numbers, like one finger for one, two fingers for two and so on.

Team Alignment is Key

If we reach this far you’re almost ready to discover the secret behind planning: the truth is that Scrum planning is not more than a short meeting (by short I mean less than four hours) divided in two halves whereas the first half is for understanding what user stories are and the second for providing estimations. Again nothing new here, Scrum has been talking about planning meetings for quite a while now. Understanding what to do seems to be crucial, but wait we´re doing Scrum, aren’t we? Don´t fall in the trap of trying to understand what needs to be done to the last detail even before coding a single line, the only way to truly understand something is when you actually do the work.

What´s the value of having planning meetings? The answer is quiet simple: you get all your team in room and make them talk about their understanding of what needs to be done. That simple exercise will do the magic of aligning everybody´s energy and attention towards a common goal (a.k.a. Sprint goal). Like Jeff Sutherland said "Scrum is all about aligning your team in the same direction" and hence is the true value of planning meetings.