Angel "Java" Lopez : Scrum

Aplicando Agil en el Desarrollo de la Aplicación

lopez — Sat, 18 Feb 2012 11:13:53 GMT

El mes pasado publiqué:

describiendo algo del proyecto que está desarrollando mi equipo, usando iteraciones semanales, y un Scrum-like, con iteration backlog, reuniones diarias con compromisos y avances, revisión de iteración, etc.. Como es un proyecto privado, no puedo comentar detalles de la aplicación. Pero puedo seguir escribiendo sobre algunos avances y descubrimientos de las últimas semanas.

Primero, el núcleo de lo que estamos desarrollando, lo podemos llamar X. Es un sistema a consumir, no directamente, sino por otros sistemas. En vez de desarrollarlo completamente, lo que estamos haciendo es encarar los casos de uso. Por ejemplo, en la penúltima semana construimos una aplicación A, símil de otra existente en la empresa contratante. Es una aplicación con interfaz web para usuarios, que consume los servicios básicos de X:

A –> X

Luego, en esta última semana, pusimos a prueba algunos conceptos de seguridad de X, que fueron aplicados exitosamente en la aplicación A. Además, hicimos una variante nueva de A, digamos A1, que tiene algunas características adicionales que no existen en la aplicación real en uso. Eso sirvió para que el “product owner” vea que X es lo suficientemente poderoso y flexible para lo que queremos hacer, AUN SIN ESTAR totalmente definido e implementado. Todo esto gracias a algo que comenté en el post anterior: NOS CONCENTRAMOS EN LOS CASOS DE USO, en vez de ir pensando e implementando en detalle TODO X. De hecho, el dominio de X, y los de A, siguen estando en memoria, y no hemos tenido que definir tablas, bases de datos, blob storage, todos artefactos que todavía no necesitamos (igual tenemos el código preparado para tener ese tipo de persistencia, y ya lo hemos probado en los casos simples).

En la reunión de revisión de iteración de ayer, surgieron dos temas, que me parecen que son hitos en este proyecto.

Uno, ha ido emergiendo qué es la “esencia” de X, los servicios fundamentales de este “engine” a ser consumidor por aplicaciones. Por ejemplo, visitamos aplicaciones reales de otras empresas, y VIMOS que podríamos reimplementar lo que brindan usando el “engine” X por debajo. Para eso poner a prueba eso, ya tenemos los casos A, A1, de aplicaciones reales implementadas parcialmente.

Otro, es también interesante, aunque no tan relacionado tanto con el “engine” X. El “product owner” planteó que lo que más le sumaría valor, para las próximas iteraciones, sería implementar B, una aplicación que refleje un proceso ya existente en la empresa, pero que se maneja semi-informalmente en planillas Excel (jeje… todos tenemos esto en nuestro karma ;-). Esta vez, la idea es llegar más allá de una simple implementación A. Ahora queremos armar un B que se ponga en uso real. El PO eligió este caso, guiado por el valor que gana: implementar totalmente A sobre X, no agrega tanto valor, porque YA HAY una aplicación preexistente, funcionando, del tipo A. En cambio, la aplicación B va a implementar algo que no existe todavía como aplicación en la empresa.

Pero ahí apareció algo nuevo, en la discusión: la necesidad de tener una aplicación C, que facilite el trabajo de los usuarios. Todo nació de una frase tipo “Tim necesita … “. Y ese fue el “key point”: al analizar QUE necesitaba, y POR QUE, pudimos llegar a comprender cuál es el problema a resolver, más allá del tema puntual de planillas Excel y proceso. Y ahí apareció cómo los usuarios podrían usar lo que estamos haciendo, de una forma MAS ORIENTADA a lo que necesitan. Lo que quedó claro ayer, es que podemos usar una metáfora (disculpen de nuevo, no hay mucho detalle a mostrar) que nos va a guiar en las siguientes iteraciones, al implementar la funcionalidad de B y de C. Iremos probando su efectividad, viendo qué funciona y qué no, en el uso de los usuarios.

Y quiero destacar: esto no surgió solamente de un equipo “iluminado” que dice “hay que ir por acá”, o que dijo “hay que usar la tecnología tal y cual, porque tiene las características … “. Tampoco fue “bajada de línea” del cliente. Surgió de la interacción con sinergia del PO, y del centrarse en los casos de uso y problemas a resolver.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

El Armado Agil de una Aplicación

lopez — Sat, 28 Jan 2012 17:34:09 GMT

En este nuevo año, estoy participando en la creación de una aplicación, en un equipo ágil, usando un Scrum-like (iteration reviews, planning, standups, iteration backlog, etc..). Tecnologías: .NET, C#, ASP.NET MVC, Azure, SQL Server, y más (en cualquier momento aparece JSON, REST, Javascript, jQuery, algún NoSQL, cache en memoria, etc…). Pero lo interesante de esta aplicación es que ha nacido prácticamente como “green field”. Si bien el proyecto completo tiene casi un año de existencia (y hasta tiene proyectos antecedentes que se remontan a 3 años atrás), la aplicación que le ha tocado a mi equipo es nueva: nace desde un File, New Project.

El proyecto es privado, así que no hay repositorio público para mostrar avance. Pero quería comentar en este post algunas de las estrategias que estamos usando para avanzar en el proyecto.

Primero: buscar basarnos en casos de uso. Anteriormente, el proyecto se basó demasiado (en mi parecer) en solucionar temas técnicos, sin llegar a hacer pie en lo que realmente se necesita. Entonces, desde la primera iteración (son semanales) nos concentramos en mostrar algo que funcione. Si bien hay varios riesgos técnicos a tomar en cuenta, no fueron (todavía) el centro de atención. Nos parece que para el cliente final lo mejor AHORA es mostrar algo andando, para que pueda explorar si es lo que necesita.

Veamos un ejemplo de estrategia: en vez de modelar el dominio con persistencia en la base de datos, lo principal del mismo ESTA EN MEMORIA, en objetos que solamente viven en memoria: persistencia, concurrencia, transacciones no están en la agenda actual, porque por las características del sistema (disculpen no dar más detalles, es privado) NO SON EL TEMA a tratar AHORA. Es mejor explorar una base de solución ahora, que tener todas las piezas en su lugar.

Como el cambio es constante (al aparecer nuevas historias, al reflexionar el cliente final sobre cómo quiere que quede el producto final, sus casos de uso), todo se ha ido construyendo con TDD (Test-Driven Development). El Code Coverage es > 85%, en general (incluido los controladores de vistas web, estamos usando ASP.NET MVC). Cuando hubo que cambiar algo en la segunda iteración (un refactor de los que yo llamo “quirúrgico”) todo esta en su lugar para que los tests nos ayudaran a comprobar que al cambiar la implementación interna todo siguiera funcionando como se esperaba.

Otro ejemplo: esta semana pasada, gran parte del dominio paso a estar persistida en SQL Server (y en Azure SQL Server). El lunes completamos la implementación de almacenamiento/persistencia en esa tecnología, usando TDD, luego la inyectamos en los lugares apropiados, y prácticamente no se rompió ningún test. En la entrega del viernes, tenemos parte del dominio en memoria (para hacer cambios rápidos) y parte en SQL Server (para ir explorando algo más cercano al producto final). Pero estamos preparados para cambiar esa persistencia a Azure Table Storage, si hace falta, y por qué no, al nuevo DynamoDB de Amazon. El desarrollo ágil y TDD nos da el “courage” (coraje) de abrazar el cambio.

TDD, en vez de ser un gasto de tiempo, es un gran avance: primero, nos sirve en el diseño de lo que implementamos. Luego, nos sirve en ir armando algo sin gastar tiempo en pruebas manuales o sesiones de depuración. Vamos avanzando de a “baby steps” (pasos de bebé): cada nueva característica se agrega con TDD, y la vamos integrando. Desplegamos en Azure más de una vez al día, para que el cliente final pueda ir viendo los avances. Las nuevas características se van anunciando en la lista del proyecto.

Otro ejemplo: el jueves se comenzó a implementar temas de seguridad (autorización en particular, con usuarios y grupos). ¿Acaso implementamos eso usando alguna tecnología? ¿Fuimos e instalamos Azman o cualquier otra cosa? ¿Fuimos a usar Access Control System, tokens y claims? No. Armamos los tests e implementamos la lógica (permisos, reglas) en memoria. El viernes ya estaba listo para la demostración, con distintos usuarios (de nuevo, definidos en memoria). De ahora en más, podemos tener retroalimentación del cliente y usuarios finales, sobre qué es lo que funciona o no del “approach” que adoptamos. Sabemos que alguna parte de la implementación puede sufrir en escalabilidad. Es parte de lo que tenemos en el radar. Pero, como digo, “no cruzar el puente antes de llegar al puente”. No es (en este proyecto en particular, cada uno de Uds. analizará su caso y contexto) lo PRIORITARIO ahora. En vez de estar semanas viendo cómo implementar eso con Azman, o con claims, o lo que sea, ya en dos días tenemos algo funcionando, listo para refactorizar a tecnología PORQUE TENEMOS los tests.

Claro que no todo tiene que ser un lecho de rosas. Pero, por lo menos yo, estoy muy contento y entusiasmado por este camino que tomamos. Espero que todo esto permita llevar a buen puerto un proyecto que ya lleva muchos meses dando vueltas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Comunicación en el equipo y más allá

lopez — Wed, 07 Jul 2010 13:51:42 GMT

Hace ya un tiempo que no escribo sobre Scrum: los últimos meses me los pasé ocupado en mi proyecto personal de mudanza y consolidación de libros. Tengo varios posts “in pectore” sobre el tema de Scrum y desarrollo ágil, pero hoy quisiera volver sobre un tema, que me parece importante.

Como saben, en Scrum hay un equipo, y se hacen reuniones diarias (además de las reuniones de iteraciones y de retrospectivas). Pero no sólo hay equipo en Scrum. También hay otros actores: "stakeholders”, interesados en el proyecto, gente del cliente final, gente de apoyo técnico de nuestro entorno, etc. Recordemos también al Product Owner, que es nuestro principal punto de contacto con el cliente, y que es el encargado de priorizar el Product Backlog, por valor de negocio (y no por otro criterio).

Pero una cosa que no está escrito en los rituales de Scrum, es el uso de herramientas: uno no está obligado a usar tal o tal herramienta. Podemos llevar todo Scrum con lápiz, papel y reuniones físicas. Sin embargo, en los últimos cuatro años de experiencia en proyectos ágiles, he visto una herramienta que ya a esta altura, me parece indispensable: la lista de correo.

Algo ya escribí cómo suelo usar la lista de correo del proyecto en:

Tales from the Scrum: Informando el estado

Pero he aprendido que la lista de correo permite también:

- Mantener el sincronismo con el proyecto, aunque uno como miembro, se ausente un día o dos.

- Mantener informado a otros interesados de lo que se está haciendo, de los bloqueos, de los avances, de los posibles caminos que se están explorando para resolver un tema.

- Permite que interesados que no están en el equipo, puedan mantenerse al tanto del estado. Puede que algunos estén físicamente lejos.

- Si bien todo esto se puede hacer con otras herramientas (agregando documentos a un repositorio, escribiendo en páginas de un wiki), la lista de correo tiene una forma de llevar información, digamos, “intravenosa”: me llegan los emails, sin necesidad de ir a otra herramienta.

Casos que he visto donde participar en la lista de correo fue provechosa:

- Una vez, estábamos desarrollando una aplicación web, y teníamos que implementar seguridad sobre un web service. Hicimos las reuniones de standup, teníamos las tareas, habíamos consultado algunos temas técnicos. Pero gracias a que publicamos lo que íbamos a hacer en la lista de correo, uno de los suscriptos, especialista técnico en el tema, supo darnos otra orientación que se nos había pasado por alto. Esa persona, como especialista, estaba muy ocupada usualmente, y no podía estar al tanto de todas las reuniones de varios equipos. Pero gracias a las lista de correo, podía ponerse al tanto del estado de los proyectos.

- Lo mismo pasó en un caso no de programación. Ante una dificultad en el “deployment” de una aplicación, que no sabíamos cómo solucionar, alguien interesado del cliente, en el área de infraestructura, nos supo dar, al leer de nuestro problema en la lista de correo, una recomendación que sirvió para seguir adelante.

- El propio Product Owner se mantiene al tanto de lo que va pasando por la iteración, sin necesidad de estar asistiendo a reuniones en el medio, y sin tener que esperar al fin de la iteración para tener idea del estado.

- La lista de correo permite que gente de dirección, por ejemplo, de la consultora que está llevando a cabo el proyecto, sepa si hay un bloqueo o algún problema: recordar el tema: “bad news, travel fast”. La lista de correo se transforma entonces en una especie de “instrumento de medición” de la salud del equipo.

- Una vez estuve enfermo unos días (sí, ya estoy viejito… :-) y la lista de correo permitió de alguna forma que me mantuviera al tanto, de lo que iba pasando.

- No en todas las reuniones (de diseño, relevamiento, pruebas, demostraciones, …) asiste todo el equipo. Entonces, algún asistente a la reunión, prepara una minuta y la envía a la lista de correo. Esto permite que los lectores de la lista, se informen de eventos a los que no asistieron.

También he notado que el informar los detalles por escrito, permite que quede más claro que simplemente informar rápidamente en una conversación, donde puede que no estén todos presentes, o no quede claro lo que uno dijo, o simplemente se olvide lo que se comentó. De alguna forma, lo escrito sobrevive más a lo simplemente conversado.

Nos leemos!

Angel "Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Agile/Scrum es difícil?

lopez — Wed, 20 Jan 2010 09:37:34 GMT

Hace un tiempo, seguramente via un mensaje en Twitter, me encontré con el post Agile/Pervagile on Slashdot en el blog multi-autor de Agile Advice – Working With Agile Methods (Scrum, OpenAgile, Lean). Es una lectura interesante. El autor presenta una descripción de lo que llama Pervagile, the Perverted Agile, lo ágil pervertido por malas prácticas. Muchas compañías dicen que están usando Agile, con Scrum o algo parecido, pero, en realidad, su adopción es parcial. El autor menciona otras desviaciones, que tienen nombres como: Scrumbutt, Waterscrum, Scrummerfall, pero esos temas merence un post aparte.

Pero hoy, quiero comentar sobre el párrafo (disculpen que no traduzca):

Agile is Hard

Okay, I’m actually being a little dis-honest. The real truth is that doing agile is extremely, exceptionally, agonizingly difficult (for most people in most organizations). Why? Because agile is not just another process to roll out. It is, as has been mentioned in numerous places, a deep cultural change. Agile is actually a liberation movement for people involved in software development. Like most movements, however, it has been subject to corruptive forces.

Bien, cierto, pero… Quiero moderar las afirmaciones de arriba, esta vez en el contexto de la aplicación de Scrum (no de Agil en general). Si estamos involucrados en la introducción de Scrum por primera vez en su compañía, claro que va a necesitar un cambio cultural, pero veo que no tendría que ser profundo (“deep” como dice arriba). Lo que necesitamos es un grupo de gente proactiva que componga el primer equipo, un buen ScrumMaster que maneje la introducción de Scrum, y un Product Owner que conozca su función. Y (y no es un Y pequeño) el soporte de parte de la gerencia, para protejer al equipo de intereferencias externas, Y ESPECIALMENTE el soporte al Product Owner: protejerlo/a de las presiones de otros genertes, fuerzas políticas, que podrían alterar las prioridades en el Product Backlog, o que pudieran intereferir en el medio del Sprint. El resto de la compañía pueden seguir trabajando a la vieja usanza. Pero necesitamos que nuestro primer proyecto sea protejido. Necesita protección y cuidado. No un gran cambio cultural. El cambio en el resto de la compañía podría ser progresivo. Y el cambio en el equipo (pensando en que es su primer encuentro como miembros de un Scrum) sería progresivo, ayudado por un ScrumMaster experimentado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Cursos de Scrum de Tobias Mayer en Buenos Aires

lopez — Fri, 15 Jan 2010 09:58:21 GMT

El bueno de Tobias Mayer visitará Buenos Aires en este mes de Enero. Fue Tobias mi instructor en el curso de Certified Scrum Master que tomé en el 2006. Tobias es conocido en todo el mundo ágil, habiendo trabajado en grupos de desarrollo usando Scrum, y dando cursos en varios países. Pueden ver un día de su trabajo como Scrum Master en:

Tales from the Scrum: un día en el equipo

Leo en el blog de Juan Gabardini el detalle de los cursos que dará Tobias:

Tobias Mayer ya ha venido varias veces a Argentina, y dio 6 cursos de CSM. Alan Cyment es el único CST hispanoparlante, y dio muchos cursos en Argentina. En enero Tobias nos visita en la semana del 25 al 26 y aprovechamos con varios actividades:

Enero 25: Scaling Scrum (gratuito) (x Tobias)
Enero 26: Consultas CSP (gratuito) (Alan y Tobias)
Enero 27: The Spirit of Scrum - (pago *) (x Tobias)

Enero 28: Improvisation for agile teams - (pago *) (facilitado por Alan Cyment, co-facilitado por Tobias)
(*) En ambos casos, cada día cuesta 220 usd + IVA. Tomando ambos cursos el costo es 330 usd + IVA - La facturación la realizará Agilar, que organiza estos eventos.

NOTA: inicialmente planificamos un CSM los días 25 y 26. Por el interés en los talleres avanzados, finalmente suspendimos ese CSM. Para los interesados en CSM, en marzo sr hará uno (Alan)

CSM se refiere a Certified Scrum Master. CSP es Certified Scrum Practicioner. Como se lee en http://www.agiles.org/agiles-bsas:

Luego de hacer un curso oficial de Scrum te convertis en CSM. Pero, más allá del valor de tomar el curso, todos sabemos que no es una "certificación" muy exigente. Por eso puede interesarte dar el próximo paso en las certificaciones de la Scrum Alliance: Certified Scrum Practicioner (http://www.scrumalliance.org/pages/certified_scrum_practitioner).

Les aconsejo que participen de alguno de estos cursos. Tener a Tobias es tener acceso a alguien que ha trabajado intensamente con Scrum, en distintas situaciones y proyectos.

Ya había traducido dos escritos de Tobias:

Tales from the Scrum: El corazón de Scrum
Tales from the Scrum: La esencia de Scrum

Para conocer más sobre Tobias visiten su blog Agile Thinking, y su iniciativa WelfareSCM (entramiento Scrum de bajo costo), también el video que grabó sobre el tema en InfoQ.

Y pueden seguirlo en Twitter como @tobiasmayer.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Estimación Agil por Mike Cohn

lopez — Fri, 08 Jan 2010 10:01:32 GMT

Una de las preguntas más frecuentes de los asistentes a mis charlas de Scrum, es ¿cómo se estima en un proyecto de Scrum o ágil? Hace unos meses, encontré estos videos. Quiero hoy compartirlos con Uds. Mike Cohn es un reconocido experto en el mundo Agile y Scrum. Pueden visitar su blog donde publica posts sobre temas que nos podemos encontrar en un proyecto Scrum.

En estos dos videos, él explica claramente que significa estimación en un proyecto ágil (involucrando al equipo en la estimación, haciendo iteraciones, planning poker, todas las prácticas de Scrum …):

(Please visit the site to view this media)

Alta resolución: http://www.youtube.com/watch?v=jeT0pOVg0EI

(Please visit the site to view this media)

Alta resolución: http://www.youtube.com/watch?v=jeT0pOVg0EI

Los videos fueron tomados el 20 de Marzo del 2007, en la Bay XP Meeting.

Espero ir comentando en español los principales puntos que expone Mike Cohn, en futuros posts de esta serie.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Curso de Scrum de Tobias Mayer en Buenos Aires

lopez — Mon, 14 Dec 2009 17:49:46 GMT

El bueno de Juan Gabardini anuncia en la lista Foro Agiles, un nuevo curso de Scrum de Tobias Mayer en Argentina. Copio el mensaje original:

Tobias Mayer facilitará un taller de un día en Buenos Aires, Argentina. Está orientado a Scrum Masters y agile coaches.
Para los que no lo conocen, Tobias dió el primer curso de CSM en Argentina, allá por el 2006. Luego de eso ha venido varias veces (no se cuantos, pero dió al menos 5 CSM en Bs As). ….

Se explorarán los principios y valores de Scrum. Este taller no se focaliza en las prácticas (se asume que los participantes tienen familiaridad con ellas) y explora Scrum en un nivel más profundo y humano. A través de una serie de juegos, ejercicios interactivos y conversaciones facilitadas, se adquirirá una comprensión más profunda del nuevo esquema de pensamiento requerido para hacer Scrum. Esto no es sobre metodologías o procesos, es sobre divertirse

Cuándo: 28 de enero 2010

Dónde: Perú 375, 1^er piso (Southworks)

Costo: usd 220 + IVA

Registración: http://tinyurl.com/tobiasBsAsWorkshop

Este evento es organizado por Agiles Argentina y Agilar Argentina

Este evento será dado en inglés. Aunque por el tipo de evento no es imprescindible el hablar y entender perfectamente, ya que el resto de los que asistimos podremos dar una mano. Va el detalle en inglés.

Process/Mechanics

Scrum is quickly being seen as the de facto way of starting out down an Agile pathway. People see it as a quick and easy way in. The problem is that Scrum is very easily misunderstood. There are a multitude of Scrum Facades in place around the world, companies who claim to be doing Scrum because they have people with the titles of “Scrum Master” and “Product Owner”, have daily meetings, maybe even planning meetings, reviews and retrospectives, keep a backlog of work and show some sort of burn down graph each sprint.

Underneath the facade though, the same old command and control beast lurks, the same old fear and CYA behavior. Nothing has essentially changed. So what is missing? I believe the spirit of Scrum is missing, the essence of change.

Scrum is not just a framework and a set of roles, meetings and artifacts. Scrum is a way of being that is utterly different from any previous way of working that we have encountered in the software industry. To do Scrum — to really do Scrum — requires an absolute shift in the way we think and act.

Scrum relies on some core principles:
— Empiricism
— Self-Organization
— Collaboration
— Prioritization
— Rhythm

and some essential values:
— Courage
— Trustfulness
— Transparency

This session will allow Scrum practitioners to reach the next level of Scrum by exploring some of these underlying foundations in a highly experiential way. The session will consist of a series of interactive exercises and facilitated discussion designed to help participants not just understand, but embody these principles and values at a deep level.

I create and/or adapt new games frequently, the majority require no props, and usually require the participants to be on their feet. Most have simple formats and can be easily remembered. None of them have pre-determined outcomes: they are all about self-discovery. For more detailed information on the kinds of games and interactive exercises I’ll use for this session please follow one or more of these links to descriptions of sessions I have run previously.

Agile Thinking — Agile2005 session

Great Game of Power — Scrum Exchange 2006 session

Scale Back: Small is Beautiful — Agile2008 session

Operating on the Creative Edge — Agile2008 session

This session is intended as a taster and it is hoped participants will be encouraged to explore more deeply the human interaction foundations of Scrum once they leave the conference.

Learning outcomes

Tobias Mayer has built a reputation in the Scrum world of offering highly challenging training sessions, pushing people to the edge of their comfort zone and ultimately breaking through to a new way of behaving. This session has that same outcome in mind.

Ya comenté sobre el bueno de Tobias en:

Tales from the Scrum: La esencia de Scrum
Tales from the Scrum: Un día en el equipo
Tales from the Scrum: El corazón de Scrum

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Los Rolling Stones y cómo va su proyecto

lopez — Mon, 07 Dec 2009 09:22:09 GMT

Bueno, en realidad, no los Rolling Stones. Solamente Keith Richards, y no el de los Rolling, sino Keith Richards presidente de Keith Richards Consulting. Encuentro en un post de Gojko Adzic un post que comenta una charla de KRC:

Eight interesting techniques to test how a project is going

Es un muy interesante post, déjenme escribir esas técnicas, para saber si el proyecto y el equipo están en buena forma, sea que estén siguiendo Scrum o no. Esta es mi propia traducción de ese texto:

- 1. ¿Puede cualquier miembro del equipo escribir el objetivo del proyecto en una nota post-it con marcador grueso? Si no pueden, el final del juego no está claramente definido ni entendido por todos

- 2. Acérquese a un colega en su trabajo, y pídale ayuda para algo cualquiera. Vea cómo reacciona. Si encuentra una respuesta fría, la persona no está muy contento con su trabajo. Richards aconseja armar equipos con “aquellos que respondan ‘puedo’”. Esa gente mejorará la comunicación y el espíritu de equipo en su proyecto.

- 3. Cuando una fase del proyecto está oficialmente “hecha” (done), pregúntese a sí mismo: “¿Es seguro seguir adelante?”. Si esta pregunta le provoca una mala sensación en las tripas, es que no están listos todavía para avanzar a la siguiente etapa.

- 4. ¿Cuántos de sus proyectos terminan con una seria revisión del proyecto? Esto es, según Richards, crucial para la mejora de su organización. Permite prevenir errores repetidos y compartir conocimiento entre los equipos (yo agrego que, si trabaja en una organización con varios proyectos y equipos, tendría que haber comunicación entre equipos DURANTE los proyectos, comentando bloqueos, avances, hallazgos, problemas y soluciones; unas buenas reuniones periódicas con presentaciones timeboxed pueden ser un camino a seguir).

- 5. ¿Cómo reacciona la gente de su equipo cuando el cliente dice “cambié de idea”? Si reaccionan negativamente, el sistema que están construyendo no es tan flexible como debiera.

- 6. Pregúntele a alguien que le comente el estado actual de una tarea, y luego cállese 10 segundos; no hagan nada para provocar una respuesta. Si la persona se muestra insegura o nerviosa sobre algo, seguramente comenzará a comentarlo. Si se mantiene en silencio, las cosas van bien (este punto lo discutiría: debería haber comunicación y visibilidad sin necesidad de llegar a este tipo de “trick”).

- 7. ¿Conoce cuánto tiempo se empleó en la última iteración en pruebas? Si no puede estimarlo, no está tomando buenas métricas del proyecto. Tomar métricas de este tipo, dice Richards, es crucial para hacer estimaciones realistas (nota mía: ojalá tuviera un peso por cada vez que alguien en un equipo estimó una tarea SIN tener en cuenta pruebas, verificación, etc.; pongan atención a esto).

- 8. Tome un documento de su proyecto, usado durante una presentación. Si atrás hay diagramas dibujados a mano, señal que el documento no está claro, y necesitó de esa ayuda para ser explicado.

Me quedo principalmente con los puntos 1, 2, 3, 5 en primer lugar. Luego 7, 4.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

ALT.NET Hispano VAN: Get Things Done con Jeroen Sangers

lopez — Fri, 04 Dec 2009 10:13:20 GMT

Este sábado 5 de Diciembre, 18 GMT/UTC (3 de la tarde por aquí en Buenos Aires), habrá otra des-conferencia virtual de la comunidad ALT.NET Hispano. El tema será productividad, más específicamente Get Things Done (GTD) (ver también Consigue hacer el trabajo). La presentación inicial estará a cargo de Jeroen Sangers:

http://jeroensangers.com/

@jeroensangers

Este es el temario de Jeroen:

Mi presentación va más que nada sobre Getting Things Done y consiste
de tres partes:
1. Control: un flujo de trabajo para controlar tus acciones
2. Perspectiva: dar dirección a todo lo que haces
3. Consejos prácticas para implementar un sistema de productividad

GTD se populariza con un libro de David Allen. Pueden leer la descripción de GTD en el sitio de Allen:

What is GTD?

Ahí leo:

Sophisticated without being confining, the subtle effectiveness of GTD lies in its radically common sense notion that with a complete and current inventory of all your commitments, organized and reviewed in a systematic way, you can focus clearly, view your world from optimal angles and make trusted choices about what to do (and not do) at any moment. GTD embodies an easy, step-by-step and highly efficient method for achieving this relaxed, productive state. It includes:

Capturing anything and everything that has your attention

Defining actionable things discretely into outcomes and concrete next steps

Organizing reminders and information in the most streamlined way, in appropriate categories, based on how and when you need to access them

Keeping current and "on your game" with appropriately frequent reviews of the six horizons of your commitments (purpose, vision, goals, areas of focus, projects, and actions)

Pueden encontrar una buena descripción (con diagrama incluido, como el que aparece en el libro original) de GTD y una relación con los “cuadrantes de Covey” (me gusta recordar al creador de ese concepto, que es la matriz de Eisenhower).

Mis enlaces sobre GTD, y productividad:

http://delicious.com/ajlopez/gtd
http://delicious.com/ajlopez/productivity

Bueno, ya envíe varios posts sobre las VAN de ALT.NET Hispano, pero les recuerdo:

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings. Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN. Pueden ver el historial de anteriores reuniones VAN (visiten las que dieron, por ejemplo, sobre NHibernate, WPF y demás) (yo participé en VAN sobre Scrum y en otra sobre generación de código). También pueden suscribirse para proponer nuevos temas, y colaborar con la comunidad. Si no pueden asistir a ésta VAN, seguramente quedará publicada más adelante, con video incluido.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Recursos de Scrum, del curso de Buenos Aires

lopez — Thu, 03 Dec 2009 11:50:40 GMT

Gracias a la gente del Microsoft User Group de Argentina, ayer miércoles 2 de diciembre estuve dando una jornada de Scrum teoría y práctica, de todo un día. Con unos treinta asistentes, estuvimos viendo temas como el manifiesto ágil, y las ideas que sustentan Scrum en particular. Así como también los roles, artefactos, reuniones, que se manejan en este marco de trabajo. Discutimos tópicos como contratos ágiles, relación con el cliente, la importancia del product owner, la auto-organización del equipo, el “ownership” que tienen que ganar, la idea de trabajar a un ritmo razonable, el “entrar en flujo”, Product backlog vs Sprint Backlog, y el clásico Chanchos y Gallinas.

Para mí, fue una grata experiencia: es uno de los cursos donde veo que más puedo aportar, y donde podemos practicar algo que considero muy importante conocer como es Scrum. Veo que la necesidad de tener equipos ágiles es creciente, no sólo en el desarrollo de software, sino en actividades en general. La labor en equipo permite llegar a objetivos que son más difícil de lograr individualmente o en simple grupo (vean que distingo entre equipo y grupo). Hay que estudiar más en detalle cuáles son los factores que hacen que Scrum funcione (me basé mucho en la idea de No somos vulcanos): hay un bias hacia mostrar los casos de éxito en la comunidad ágil, y no comentar los fracasos. Hay que pasar de la evidencia anecdótica a un fundamento más firme, no porque el marco de trabajo en sí lo necesite, sino para poder aplicarlo mejor, entender mejor en qué circunstancias funciona, y en cuáles se complica.

La parte teórica ocupó la mañana, pero ya después los asistentes se separaron en cuatro grupos, y comenzaron a trabajar en desarrollar un entregable, en dos sprints de 3 días de 10 minutos cada día. Fue una experiencia interesante: fuimos viendo cómo mejorar las reuniones, la precisión del backlog, los acuerdos con el product owner para los entregables de Sprint Review, el reparto de trabajo, la mejor partición de las tareas en el Product Backlog, y más.

Prometí publicar un post con los recursos que mencioné en el curso. Acá van los enlaces y bibliografía, que son similares a los que ya publiqué hace unos días para otros cursos dictados, pero para más comodidad, los concentro de nuevo en este post:

Reunión virtual de Scrum, con video (gran parte de la teoría vista en el curso está en este video) (ahí están los enlaces que presento acá).

Presentación usada en el curso ScrumSpanish.pptx

Pueden usar esta presentación compartida (en varios idiomas):

A Reusable Scrum Presentation. Introduce Scrum to your team, ScrumMaster and Product Owner.

Para leer en inglés y en español Scrum Primer

http://agilethinking.net/ El sitio de Tobias Meyer, que me inició en el ScrumMastering en el 2006.

http://www.implementingscrum.com/ Sitio donde encontraran la clásica historia: The classic story of the pig and chicken

El Manifiesto Agil mencionado en la charla

Artículo corto en inglés (pdf) What is Scrum?

Reviews of Agile Product Backlog and User Story Management Tools: http://www.userstories.com/

Presentación en español sobre Contratos Ágiles

Slides: http://www.slideshare.net/proyectalis/090603-contratos-giles
Video Parte 1: http://www.viddler.com/explore/jmbeas/videos/3/
Video Parte 2: http://www.viddler.com/explore/jmbeas/videos/4/

Foro Agiles (Grupo Yahoo en español)

Blog de Juan Gabardini Software Agil

Enlaces y recursos adicionales en Scrum Práctico

Scrum Cheat Sheet

Scrum: Ficha Sinóptica

Un libro que para preparar las primeras versiones del curso

Agile Project Management with Scrum

En ese libro, están enumerados estos recursos:

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle (Prentice Hall, 2001)

Teoría y práctica de Scrum.

www.controlchaos.com/

El sitio de Ken Schwaber sobre Scrum.

http://www.jeffsutherland.com/

Jeff Sutherland tiene contenido relacionado con desarrollo de software, programación, tecnología, objetos, componentes y Scrum.

www.mountaingoatsoftware.com/scrum/

El sitio de Mike Cohn sobre Scrum.

www.scrumalliance.org

El hogar de los ScrumMaster certificados.

www.agilealliance.org

El sitio de la AgileAlliance, con recursos sobre Agile y Scrum.

http://groups.yahoo.com/group/scrumdevelopment/

El grupo de discusión de Scrum, con años de existencia.

www.xprogramming.com

El sitio de Ron Jeffries acerca de Extreme Programming (XP). XP provee varias de las prácticas que Scrum implementa para asegurar el incremento de funcionalidad potencialmente entregable.

Otras lecturas recomendadas

Agile and Iterative Development: A Manager’s Guide by Craig Larman
Agile Estimating and Planning by Mike Cohn
Agile Retrospectives by Esther Derby and Diana Larsen
Agile Software Development Ecosystems by Jim Highsmith
Scrum and The Enterprise by Ken Schwaber
User Stories Applied for Agile Software Development by Mike Cohn
Artículos semanales en www.scrumalliance.org

Mis posts sobre Scrum (estoy ahí escribiendo una serie “Tales from the Scrum” donde trato más en detalle algunos puntos que tratamos en el curso).

Los enlaces que me interesaron los colecciono en:

http://delicious.com/ajlopez/scrum
http://delicious.com/ajlopez/agile

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: el Product Owner y el Product Backlog

lopez — Sat, 28 Nov 2009 11:01:47 GMT

Quisiera hoy detenerme en uno de los roles de Scrum: el Product Owner (podría traducirlo por “dueño del producto”, pero voy a seguir la costumbre de usar la denominación en inglés), y en particular, en una de sus actividades.

La principal actividad, que le compete completamente, es el mantenimiento de los items del Product Backlog, y sus prioridades. Recordemos que el Product Backlog es el documento que lista la funcionalidad que esperamos del producto terminado. Esta lista es evidentemente importante: mal armada, puede hacer que el producto a entregar no sea el que el cliente final necesita.

Esa lista no la decide el Equipo, y menos el Scrum Master. Lo decide el cliente, en reuniones anteriores al inicio del proceso, donde pueden intervenir distintos interesados, pero de ahí en más es el Product Owner el responsable de mantenerlo (un Product Backlog puede cambiar con el tiempo, no es un documento escrito en piedra). Este es el responsable de entender, mantener, y conocer las prioridades de esta lista, del que saldrá el producto que entregaremos al final del proceso.

Es común, si no se conoce Scrum, querer priorizar los items por su orden “lógico” de desarrollo. No: la idea es priorizar por importancia para el negocio, para lo que necesita el cliente. De ahí que las prioridades no las decide el Equipo, sino el Product Owner.

Esto implica que la persona que encarne ese rol, debe conocer del negocio del cliente. Debe tener contacto con los principales actores de la actividad del negocio, entenderlo, y debe conocer cuáles son las áreas importantes. Demos un ejemplo.

Si tenemos que desarrollar un sistema de seguros en línea, el Product Owner deberá decidir qué partes del sistema a entregar darán más valor al negocio, y por qué. Tal vez, el grueso del negocio sean los seguros de vida, o tal vez el seguro de camiones, o quizás el seguro de autos. Dependiendo de ese dato, se podrá priorizar el tener una aplicación para calcular un seguro de vida, antes que uno de autos. No se comienza por lo “más fácil”, o por “lo que nos están pidiendo ahora”, sino por lo más importante.

Si un equipo técnico tuviera que decidir sobre esos puntos, seguramente tomaría primero el tener una base de datos, o un sistema de seguridad, o cualquier otro punto. No es la idea en Scrum: la idea es entregar, al final de cada Sprint, iteración, algo que agregue valor. Por supuesto, lo entregado deberá cumplir con la calidad esperada por el cliente, pero debe estar alineado con los items del Product Backlog, armado y priorizado por el Product Owner.

Como escribía más arriba, el Product Backlog inicial no es necesariamente EL Product Backlog final. Pero los cambios, de items, de prioridades, deben ser hechos por el Product Owner. El Equipo podrá levantar la mano, sugerir cambios, pero la decisión de cualquier modificación, recae en el Product Owner. Y éste no deberá cambiar los items por cualquier causa: deberá consultar con los interesados en el proyecto, con los que conocen del negocio, y estar atento a cualquier cambio en el entorno, para poder priorizar los items que son necesarios mantener en el Product Backlog.

Vean entonces, la importancia del rol del Product Owner. De hecho, hay cursos especiales de entrenamiento de Product Owners, en el ambiente de Scrum. Muchas de las decisiones importantes pasan por él. Por supuesto, no son decisiones en solitario, consulta y recibe asesoramiento de otros interesados. Pero un Product Owner debe ser alguien que realmente se empape del negocio y del producto que queremos lograr. Puede que no sepa todo, pero debe tener el acceso a la información y al conocimiento de otras personas, y tener una mente y actitud de aprendizaje y atención al negocio.

Uno de los anti-patrones de Scrum que mencionaba en el post Anti-Patrones de Sprint era Demasiados cambios en los requerimientos, entre Sprints. Román Mussi comentaba:

Angel, sobre esto:

"Demasiados cambios en los requerimientos, entre Sprints"

Esto no estaría dependiendo del Product Owner? Y en ese caso... como puede intervenir el ScrumMaster para mitigar el problema?

Ciertamente, es un problema que puede nacer de un Product Backlog cambiante. Quisiera aclarar que los cambios pueden ser necesarios: tal vez el negocio de seguros cambión, y la plata ahora está en asegurar camiones: los seguros de vida donde poníamos nuestras fichas fueron afectados por algo, como la llegada de un competidor del extranjero, un cambio en la legislación, o lo que sea. Y esos cambios, el equipo debe enfrentarlos, sin perder impulso, sin sentir el “dolor del cambio”. Scrum, como todo lo ágil, está preparado para fomentar la aceptación del cambio, no de luchar contra él. Pero el anti-patrón aparece si los cambios no son producidos por una nueva evaluación del negocio.

Los cambios así sin sentido de negocio, pueden venir de varias causas. Por ejemplo, un Product Backlog débil inicialmente, que no estaba claro al comienzo, puede ir mejorando al ir entendiéndose mejor el producto a producir, y el negocio en el que está inserto. Igualmente, pediría tratar de evitar esta situación: antes de lanzar el proceso, debería quedar más claro el Product Backlog. No habría que escatimar esfuerzo en tener un buen Product Backlog. Insisto: puede que no sea el final, pero deberíamos haber invertido un tiempo para no desperdiciar tiempo y esfuerzo del equipo. Es claro que no esperamos un “gran diseño inicial”, no es un tema de diseño técnico: es tema de sentido común, sobre lo que queremos obtener.

Pero, por lo menos, si lo anterior tiene olor de anti-patrón inicial, por lo menos el documento evoluciona hacia algo mejor, más firme. Pero otra causa para que aparezca “mal olor” en el Product Backlog (más frecuente de lo esperado, en especial en proyectos largos), es ceder a las presiones externas: de pronto, por atender lo urgente (“tenemos que tener en línea los seguros de autos para la exposición Car2009 que comienza dentro de un mes”), o requerimientos internos de gente con poder en el cliente (“mi división necesita los seguros de camiones para ayer”), el Product Owner cede y cambia el Product Backlog. A ver, pongamos alguna aclaración y contexto: si realmente el futuro de la empresa depende del impacto que tenga en la exposición de autos que viene, entonces es válido el cambio (yo preguntaría entonces: esa exposición estaba planeada desde hace un año, por qué ese cambio de dirección no se previó antes?). Pero si solamente es un cambio promovido por urgencia, y no por importancia, estamos atacando el proceso.

De alguna forma, todo lo ágil, más allá de Scrum, nos trata de proteger del síndrome “lo urgente mata lo importante”. El Product Backlog es el documento primordial, que guía las decisiones del resto del proyecto. El tener un Product Backlog “manteca”, que cambia de forma a cada momento, o según “cómo calienta el sol”, que se modifica incluso en el medio del Sprint (los dioses de Scrum no lo permitan!!), es síntoma de estar reaccionado a lo urgente, en vez de actuando sobre lo importante. El Product Owner, ayudado por el Scrum Master, y el compromiso de la dirección, deberá encarar ese problema.

Espero que haya quedado claro la importancia del rol del Product Owner (en mi postura, el eslabón más débil en Sprint, por ser el que concentra tantas decisiones), y la salud del Product Backlog. Pienso que agregando ejemplos negativos al final, quedó mejor transmitido ese mensaje. He visto proyectos bien llevados, donde todo esto pasa desapercibido, justamente, porque es lo natural. Poner énfasis en los problemas, nos ayuda a entender por qué funciona un proyecto Scrum bien manejado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Curso de Scrum práctico en Buenos Aires

lopez — Tue, 17 Nov 2009 13:39:00 GMT

En general no anuncio los cursos que estoy por dar (la difusión queda a cargo de cada institución), pero este es un curso que quiero destacar, porque trata de un tema que pienso que todo grupo de desarrolladores por lo menos tendría que conocer y practicar en algún momento. Es un curso que hace unos meses que no estoy dando por Buenos Aires, y siempre he tenido buenas experiencias dándolo.

Gracias a la gente del Microsoft User Group de Argentina, daré un curso de Scrum con una explicación inicial, y luego todo práctica, el miércoles 2 de diciembre de 2009. Pueden ver más datos, costos, y forma de inscribirse en:

Jornada de Scrum, teoría y práctica

El contenido (lo copio de ahí):

- El Equipo de trabajo. Los Roles: ScrumMaster. Product Owner. Daily Scrum. Chickens y Pigs. ScrumMaster vs Project Manager.
- Objetivos: Control empírico del proceso de desarrollo. Dar visibilidad de lo que se está haciendo. Generar una relación de confianza y comunicación constante entre el cliente y el equipo.
- Los Conceptos: Iteraciones. Autoorganización. Descripción del método.
- La Documentación: Qué es, cómo se arman y cómo se utilizan el Product Backlog, el Sprint Backlog y Burndown Chart.
- La Práctica: Se formarán equipos de trabajo, que resolverán un caso práctico. Se asignarán los roles y se discutirá cada caso en particular, buscando arribar a la solución al final de la jornada.

Lo importante es el trabajo práctico. Iremos descubriendo juntos algunas características, prácticas, y el por qué de cada cosa, en el marco de trabajo Scrum.

Para los que no puedan asistir, recuerden que siempre escribo por acá sobre el tema en posts sobre Scrum. Ahí encontraran un varios posts, con enlaces, referencias, presentaciones, sobre el tema Scrum y ágil en general. Los posts primeros a revisar, con material relacionado, incluso un video de una charla y discusión sobre el tema, en:

Resultado de la VAN en ALT.NET Hispano sobre Scrum
Scrum Práctico
Scrum Práctico en Santa Fe
Explicando Scrum

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: La esencia de Scrum

lopez — Mon, 16 Nov 2009 09:14:45 GMT

En esta serie de post, aún falta que escriba describiendo de principio a fin lo que es Scrum. Para llegar a ese punto, primero quiero compartir con Uds. esta traducción de un post de Tobias Mayer, quien fue mi instructor de Scrum Mastering en 2006. El post original, en inglés, lo encuentran en:

Essence of Scrum

Acá va mi traducción:

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Gracias a Tobias por tan buena descripción de Scrum.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Anti-patrones de Sprint

lopez — Thu, 29 Oct 2009 11:34:52 GMT

Recordemos: el Sprint es la iteración en Scrum: puede durar una, dos semanas, o un mes. Eso se decide según el proyecto y el equipo. En los primeros tiempos de Scrum se elegía un mes, pero ahora se prefieren sprints más cortos: una de las razones es para responder a cambios más rápidos.

El Sprint se inicia con una reunión de Sprint Planning, donde se expone el estado actual del Product Backlog (la lista de requerimientos del producto que estamos armando), y se arma el Sprint Backlog (la lista de tareas que se eligen para ese Sprint). El Sprint termina con la reunión Sprint Review, donde se presenta el nuevo estado del producto. Cada día, el equipo se reúne, y realiza la reunión diaria de Scrum, para informar el estado y comprometerse a las tareas de ese día. El ScrumMaster va acompañando al equipo para que aplique Scrum de forma efectiva.

De vez en cuando, aparecen, aún equipo saludables, algunas actitudes y actividades que podemos denominar anti-patrones: no están alineadas con los principios de lo ágil y de Scrum. Veamos algunas:

- Tomar demasiadas tareas para el Sprint: el equipo, entusiasmado (o presionado), toma más tareas que las que son materialmente cumplibles. Un equipo maduro conoce su fuerza y capacidad, y sabe hasta dónde puede llegar en cada Sprint.

- No partir bien las tareas del Sprint: Relacionado con lo anterior. Una de las actividades de la Sprint Planning es enumerar las tareas que serían necesarias para avanzar con los items más prioritarios del Product Backlog (armado por el Product Owner). La lista de tareas tiene que estar bien armada (no olvidarse de ninguna). Luego se evalúa el tiempo y esfuerzo necesario para cada tarea. Y acá he visto muchas veces esto: el equipo no parte la tarea en subtareas. Si una tarea no se parte de esa manera, es más difícil evaluarla. Yo recomendaría partir cada tarea en subtareas que puedan evaluarse en tiempo de horas. Si una tarea es “armar los reportes contables”, no dejarlo así enunciada. Pasarla a la lista de subtareas, y evaluar una por una. Por ejemplo: una lista de esos reportes, y a su vez, dividir en programar el reporte, verificarlo, documentar en el manual de usuario, armar el script de instalación, e instalarlo en el servidor de pruebas. Si no se parten adecuadamente las tareas, no podemos evaluar bien el tiempo que emplearemos. No tiene que ser una partición definitiva: se puede ir refinando con el correr del Sprint. El llevar el detalle a subtareas de horas, que puedan realizarse en fracciones de días, tiene también otra ventaja: quedan disponibles para que se tomen en la reunión diaria: la tarea de cada miembro debería ser poder terminada en el mismo día. Sino, debería anunciar qué parte de la tarea toma, y a qué punto de avance se compromete a llegar en ese día.

- Una tarea para un miembro: cada día, debería cada miembro del equipo tomar una tarea, para seguir avanzando en el cumplimiento de lo que se comprometió para este Sprint. Pero puede pasar, que una tarea queda por siempre asignada a un miembro del equipo. No es la idea de Scrum: un miembro no toma esa tarea para él por todo el Sprint. La tarea es del equipo. Que haya un miembro del equipo más capacitado para llevarla a cabo, no implica que sólo él se encargue de la tarea. Debería por lo menos hacer “pair programming”, ir educando a alguien más en el equipo, para no caer en eso de “esta tarea es para Juan” y sólo para él.

- Entregar trabajo no terminado: Iba a poner “o terminado parcialmente”. Pero no debería existir ese concepto en un Sprint. La idea es entregar una tarea, bien terminada, bien hecha. Prefiero que un equipo tome una sola tarea, y la termine bien, a que encare cuatro tareas y finalmente, a cada una le falta algo para ser considerada realmente “hecha”. Muchas veces, el equipo piensa que de esta forma va avanzando: entregar 10 tareas, aunque no estén bien terminadas. Y piensa que así es mejor. Pero la experiencia muestra que el trabajo adicional de revisarlas y completarlas más adelante, no se puede soslayar. O si lo salteamos, habremos entregado producto sin una calidad y terminación adecuada. No hay que “patear para adelante” este tipo de cosas.

- No verificar el trabajo: En el trabajo de cada, se va cumpliendo con las tareas, pero no se verifican. Así, puede pasar que lo que un miembro consideró como terminado, en realidad le falta algún detalle. Hay que recordar que el trabajo debe ser entregado de forma tal, que tenga la menor cantidad de errores o problemas al usarlo. No es cuestión de “termino tal tarea, cualquier problema me lo van a informar en el próximo Sprint”. No es la idea. El espíritu es

- Tener un Sprint de “estabilización del producto”: Como las tareas se fueron entregando de forma no “totalmente hecha”, se elige un Sprint para “pulir” el producto, revisando lo entregado, para mejorarlo y corregir pequeños temas. De nuevo, no es la idea: no debería haber, en lo posible, este tipo de “estabilización”. En vez de haber entregado esas tareas de forma parcial, se deberían haber entregado menos tareas, pero bien terminadas. Como digo, el producto de cada Sprint debe venir “en paquete con moñito”: evitar la entrega parcial.

- No hacer “pair programming”: si bien Scrum no exige esto, he visto que es común que alguna disciplina ágil, como la programación de a pares, se saltea siempre. Ya sea porque el equipo es pequeño y hay muchas tareas, o por la razón que sea, todas las tareas se ejecutan individualmente. El trabajo de a pares facilita la terminación de la tarea, dos cabezas piensan más que una, hasta se verifica mejor el trabajo entregado, y tiene un beneficio adicional: la integración del equipo.

- Demasiados cambios en los requerimientos, entre Sprints: Esto va más allá del Sprint, pero puede pasar: de Sprint a Sprint, los items del Product Backlog y sus prioridades, van cambiando demasiado. Lo que era prioridad hoy, mañana ya no es. Lo que se pidió para este Sprint “porque era importante”, resulta que para el próximo sprint ya no se tiene en cuenta. Tal cantidad de cambios, es indicación de una falta de rumbo. Y puede llegar a desmotivar a un equipo: ve que cada cosa que va armando, al final, no se usa, y se tiene que dedicar a cada momento a otra cosa.

- Olvidarse de la retrospectiva: una reunión importantísima del marco de trabajo Scrum. Parece que esta reunión muchas veces queda en el camino. Con el gusto diario de hacer tareas, con la concentración que implica el Sprint Planning, con la excitación de la entrega en el Sprint Review, al final, no hay tiempo o nos olvidamos de hacer la reunión de retrospectiva. Un gran error: es la gran oportunidad del equipo para reflexionar sobre lo que está haciendo y sobre la salud del proceso.

- Saltearse algún Daily Standup Meeting (la reunión diaria): Alguna vez, por temas de tiempo, de organización de un día en particular, se saltea esta reunión. Si una parte del equipo no puede asistir (ejemplo: fue a una reunión de capacitación), se debe acordar: o la realizamos igual, aunque sea con dos miembros, y luego, si se reintegra el resto del equipo, hacemos una sincronización; o la pasamos ese día a otro horario. Pero les recomendaría no saltearse esta reunión.

El primer paso para ir corrigiendo estas situaciones, es darse cuenta: esa es la función de la retrospectiva. El segundo paso: no corregir todo de una, sino ir encarando problema por problema: comprometerse mejorar en un punto, y revisar la mejora en la próxima retrospectiva.

Post relacionado: Tales from the Scrum- Anti-patterns de la reunión diaria

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No esperemos a Superman

lopez — Sat, 24 Oct 2009 14:18:29 GMT

En estos días, buscando ejemplos de antipatrones de Scrum, me encuentro con el “Hero-Driven Development” (visiten todo el blog Scrum is Scrum). Hace poco comentaba sobre las “prima donnas” en desarrollo en Tales from the Scrum- No somos Q. El caso que quiero comentar ahora, es distinto. El desarrollador super héroe de nuestra historia, puede ser un tipo apreciado, querido por el equipo, reconocido en su campo. Es uno de esos desarrolladores que puede programar mucho más que los demás. Steve Mc Connell los llama 10X Developers. Pero puede causar problemas. Veamos (basado en el blog que mencioné):

Problema: En el medio del desarrollo, surge un problema. Puede ser una configuración de Windows Communication Foundation, un tema de mapeo de Hibernate, una instalación en JBoss. No importa. El problema es complejo, y bastante técnico. De pronto, se abre la ventana, y entra nuestro “programador héroe”, reluciente en su traje. Se sienta, mira el código, entiende el problema, y lo va solucionando. El equipo, arrobado, se queda atrás, mirando, cómo nuestro Superman del código, va resolviendo el más intricado nudo de desarrollo. El héroe, concentrado, no habla ni explica. Parece relajado, lo que hace es “pan comido” para él. Entonces, en un momento, para, el problema está solucionado, levanta la vista, mira al equipo, y sale volando por la ventana, directo hacia el atardecer. Gran música de fondo.

Contexto: El equipo no sabe cómo solucionar el problema técnico que surgió. Es algo en lo que tienen poca experiencia. Trataron de solucionarlo, pero no pudieron, y están entrando en pánico. Pasan las horas, y no avanzan. Todo está empantanado. Entonces, encienden la señal, para llamar al super héroe.

Fuerzas: Vivimos en tiempos de cumplir los compromisos que asumimos para la iteración. Queda poco tiempo para la entrega. Todo indica que necesitamos una solución rápida.

Solución: No hay que buscar solución rápida. Primero, habría que haber previsto el riesgo tecnológico, desde el propio equipo. Los miembros deberían haber anotado que en algún momento se toparían con una tecnología que no conocen, y tendrían que haber tomado la tarea asignándole más tiempo. Pero bueno, supongamos que no se pudo hacer eso. El problema de arriba, es que el equipo delega la solución FUERA del equipo. El equipo, de alguna forma, “se lava las manos”. La actitud del superhéroe también conspira para eso. No es ése el camino. El equipo no debería perder “ownership”, propiedad y responsabilidad del producto, y de cada pequeño o gran problema. El desarrollador super héroe, que los hay, debería haberse integrado al equipo, compartiendo su conocimiento. Debería actuar como consultor del resto del equipo, pero trabajando con él. Y cada cosa que haga, con el equipo, será considerada como cualquier otra tarea de otro miembro: deberá cumplir con los estilos pactados, las métricas adoptadas, la definición de “hecho”. No debe ser un miembro “distinguido”. Lo que haga, debe estar público y lo más entendible posible para el resto del equipo. Tal vez no consigamos una solución tan rápida como la de arriba. Pero seguramente, a largo plazo, estaremos construyendo un equipo más responsable.

Recuerden: uno de los grandes entregables, en Scrum, es el equipo.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: No somos Q

lopez — Thu, 22 Oct 2009 10:22:39 GMT

No se si conocen o recuerdan al personaje de Q, que apareció en el capítulo presentación de Star Trek: Next Generation. Dotado de poderes sin límites, el personaje interpretado por John de Lancie ha aparecido en varios episodios, siendo uno de los favoritos de la audiencia trekkie. En la tercer temporada de Next Generation, en el capítulo Déjà Q le quitan los poderes, y pasa a ser un simple mortal, que tiene hasta que comer para sobrevivir. Se le sugiere integrarse a la tripulación de la Enterprise, pero él responde que no está acostumbrado: “Es difícil trabajar en grupo cuando se es omnipotente”.

Q nunca podría ser un buen miembro de equipo Scrum. Recuerden: Scrum es un marco de trabajo para producir software EN EQUIPO (se puede extender para otras actividades, pero siempre en equipo). La idea de equipo en Scrum es fuerte: miembros con distintas habilidades y competencias, que trabajan coordinados para ir armando, iterativamente, el producto que el cliente necesita. En general, se usa la figura del Scrum Master para mantener el equipo dentro de las buenas prácticas, como mantener la reunión diaria, evaluar correctamente el Sprint (iteración), actualizar el backlog de sprint, ver que se arma y priorice lo mejor posible el product backlog, etc.

Pero, en el día a día, lo que cuenta es el trabajo en equipo. No hay lugar para “prima donnas” o “Qs” en un equipo Scrum. Claro que puede haber miembros con más “seniority” en un tema técnico, o en alguna habilidad (como diseño gráfico, o base de datos). Pero lo importante es que toda tarea, y su resultado, queda a cargo del equipo. No hay “me corto solo” en Scrum. No hay actitudes de “yo lo hago mejor, y hago esto, y nada más”. No hay “yo me encargo de la base de datos, lo demás no”. No hay “esto lo hago yo, porque lo hago mejor que Uds.”. Debe haber “esta tarea la tomo yo, si quieren, hago pair programming con X, y dejo claro cómo lo hice, para que mañana otro pueda seguir con esta tarea”. Si no se puede llegar a esa actitud, por lo menos, debemos luchar para conseguirla, y marcar nuestra falta en las retrospectivas (recuerden que para eso están las reuniones de retrospectivas: no para marcar errores, sino para detectar malas prácticas, o formas de trabajo no efectivas, y mejorarlas).

Cada tarea es del equipo.

Tomemos un ejemplo en concreto. Puede que haya en el equipo alguien ideal para escribir el manual de usuario de una parte del sistema que estamos armando y entregando (ciertamente, hay manuales de usuario, y es muy probable que se algo que para el cliente tiene valor de entrega y nos lo pida; sino, es, en general, un buen “over-delivery” que hace que el producto entregado tenga mejor recepción y uso). Supongamos que esa persona, llamémosla Juan, se recibió de “Technical Writer”, o que es el que mejor conoce esa parte del sistema. ¿Será él el que tome esa tarea? Un día, al comienzo, en la reunión diaria, Juan tome la tarea. Pero bien puede ser que sea una tarea que insuma varios días: hay que escribir una tabla de contenido, un glosario de los términos, una introducción, un paso a paso, sacar “screenshots” y ponerlos en el documento, escribir sobre el proceso A, el B, el C… En definitiva: la tarea puede partirse en varios pasos. Y entonces, seguramente otros miembros del equipo podrán colaborar con alguna de las subtareas. El miércoles, Juan está enfermo, y falta. Pedro, que estuvo colaborando con él, bien puede seguir con la tarea: aprendió cómo se organiza el material, cuál es el ejemplo que se estaba desarrollando en el manual, y puede seguir con el tema. Mientras tanto, el documento va quedando publicado en el repositorio de código del equipo. José “odia” hacer documentación. Pero igual revisa el documento parcial producido, y descubre que un “screenshot” no corresponde con lo el ejemplo que se explica. María detecta que se está usando mal el tiempo verbal. Francisco, que está desarrollando otra parte del sistema, y es el menos familiarizado con el tema del manual, apunta que no se entienden algunos términos, que el creador original del documento toma por sabidos por todo el mundo.

Cuando al final del Sprint, el documento es entregado, casi todos los miembros del equipo pasaron por la producción del mismo: escribiendo, revisando, juntando material, mejorando una parte, sugiriendo cambios. Y ese entregable, es responsabilidad del equipo. Si luego se detecta que hay un error tipográfico o de concepto, es el equipo el que se hace cargo de ese defecto.

Trabajando en equipo, hasta capaz le ganamos a Q y todo… :-)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: Un día en el equipo

lopez — Tue, 13 Oct 2009 09:20:03 GMT

Una de las cosas que hay que destacar de Scrum, por si es la primera vez que lo ven, es el trabajo en equipo. Los miembros del equipo realizan una reunión diaria inicial, el Standup, se reparten las tareas, y van trabajando físicamente juntos durante el día, programando, diseñando, haciendo pruebas del software, etc… Hace un tiempo, encontré este video, donde, oh! sorpresa! el ScrumMaster es el bueno de Tobías Mayer (@tobiasgmayer) (visiten su blog Agile Thinking, y su iniciativa WelfareSCM (entramiento Scrum de bajo costo), también el video que grabó sobre el tema en InfoQ).

(Please visit the site to view this media)

Vean cómo se trabaja a veces de a pares, a veces en solitario. El ScrumMaster (el que acerca la cara y hace muecas…:-), va acompañando al equipo, de forma intermitente. El lugar físico es importante: todos se ven, todos están en contacto directo. Vean cómo van organizando las tareas en papeles. A la derecha, parece que tiene el tablero de control.

Para los que no lo vivieron, es así: los miembros van avanzando en tareas, tienen reuniones de diseño, o para discutir dudas y caminos. No hace falta comer en el mismo lugar :-) pero pueden hacerlo.

Pueden leer un post de Tobías que traduje al español en Tales from the Scrum: El corazón de Scrum.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Resultado de la VAN en ALT.NET Hispano sobre Scrum

lopez — Fri, 18 Sep 2009 10:04:00 GMT

Gracias a la comunidad de Alt.NET Hispano, en especial a @jorgegamba, de Colombia, que me ayudó a tener todo preparado, pude participar en

VAN en ALT.NET Hispano sobre Scrum

Hubo varios participantes, a destacar Gustavo Quiroz y Raul Uribe de Agile Perú. También me encontré con el bueno de @fabiomaulo, que planteó lo difícil que es llevar a cabo un proyecto ágil usando Scrum, ante la falta de un dueño de producto concreto.

Pueden ver la desconferencia en video, enlaces y recursos en:

VAN Hispano - 2009-09-06

Ahí hice mi habitual presentación sobre Scrum, cambiando el orden de algunos temas, y limitándola a 45 minutos, para dar cabida a la discusión y consultas en el resto de la charla. No pude interactuar al principio, porque tenía un problema en mi audio: no podía escuchar a los demás. Luego pude solucionarlo, e integrarme al grupo en la segunda hora de la desconferencia.

Me gusta mucho que una actividad realizada deje una traza en google, de esta forma: los que no pudieron participar, igual pueden ahora consultar lo que se hizo, y aprovechar las discusiones, opiniones, enlaces y recursos que fueron apareciendo en la charla. Hemos visto la luz! :-) :-)

Y YA se viene una nueva VAN:

Invitación a VAN Hispano Sábado 19 de septiembre - ORM con Fabio Maulo

Para alquilar balcones! :-)

Tienen siempre para visitar, los videos y recursos de las anteriores reuniones:

Historial de reuniones

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

VAN en ALT.NET Hispano sobre Scrum

lopez — Fri, 04 Sep 2009 10:23:04 GMT

El domingo que viene, habrá una reunión virtual del grupo ALT.NET Hispano, sobre el tema Scrum. Yo participaré dando una introducción de algunos temas:

- Marco de Trabajo Scrum
- Roles: Team, Product Owner, Scrum Master
- Product Backlog y Sprint Backlog
- Ceremonias: Sprint Planning, Sprint Review, Daily Scrum, Sprint
Retrospective

En general, las reuniones duran 2 horas, y en las últimas, los asistentes han participado activamente, con preguntas y dudas y planteos. Así que no es una típica charla de presentación de un tema, sino que también habrá discusión. Mi idea es presentar los temas de arriba rápidamente, en 45 minutos, y dejar documentación adicional por acá.

No tengo la confirmación, pero espero que participen también Raul Uribe y Gustavo Quiroz. La hora, no la vi publicada en el sitio de ALT.NET Hispano, pero supongo que será la habitual, 18:00 GMT (15hs en Buenos Aires, Argentina). En cuanto pueda, actualizo el post, con los datos en concreto.

Si no conocen qué es una reunión VAN, pueden consultar VAN meetings

Para ver cómo se desarrolla una VAN de ALT.NET Hispano, y qué software necesitan para asistir, ver Descripcion-de-Reuniones-VAN

Pueden ver el historial de anteriores reuniones VAN

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Tales from the Scrum: TDD en todo

lopez — Wed, 26 Aug 2009 10:55:26 GMT

Hace un tiempo escribía sobre

Tales from the Scrum: Terminando la tarea

donde hace hincapié en verificar cada tarea, e introducía algo a discutir en otro post: el concepto de “hecho”, que tiene que estar claro en el equipo y en el dueño de producto.

Hoy quiero comentar sobre algo similar, que podemos hacer en cada tarea: aplicar ideas de Test-Driven Development. No hace falta que Ud. haya aplicado TDD: una disciplina que puede usarse en XP. Lo que quería adoptar de ahí, es, ante una tarea a realizar: escribir primero el test. Esto, a cualquier tarea. ¿A qué apunto?

Veámoslo con un ejemplo. Supongamos que tenemos que migrar una base de datos contable, de un tipo de base datos (digamos Oracle), a SQL Server. Una tarea delicada. No queremos que se pierdan datos. Entonces, antes de comenzar la tarea, vamos escribiendo cuál sería el test, la prueba, a pasar luego de la tarea, para considerarla bien terminada. Podría ser:

- Hacemos select count(*) de la tabla de plan de cuentas en Oracle

- Comparamos esa cantidad con el select count de plan de cuentas en SQL Server

- Hacemos un sum de debe y haber, en Oracle

- Comparamos con el sum de debe y haber en la nueva base de SQL Server

- Tomamos el mayor de la cuenta X (que tiene pocos movimientos) en Oracle y los comparamos con los movimientos del nuevo SQL Server

- Hacemos lo mismo para el mayor de la cuenta Y (la de mayor cantidad de movimientos)

- …

Hasta podemos escribir un programa que haga estas comprobaciones, aunque no siempre es necesario o posible.

La cuestión es comenzar la tarea con un fin en mente: qué tiene que pasar al final para que podamos decir la tarea está bien completa y hecha.

Y esto, hacerlo ANTES de comenzar la tarea. El tener en claro hacia dónde queremos llegar, cuál es escenario final que queremos tener al terminar la tarea.

Lo mismo hacemos con cualquier tarea, ya sea del sprint, o particular nuestra. Si una de las tareas es instalar un servidor Apache, con PHP y MySql, entonces, el test podría ser:

- Escribimos http://localhost en nuestro navegador y aparece la página inicial

- Este servidor viene con phpmyadmin instalado, vamos a ese enlace, y vemos la página de la base MySql local

- Vemos en la lista de base de datos instalada, las iniciales de MySql

- Creamos una base con tal y tal parámetro

- En esa base creamos una tabla con tales y tales características

- …

- Subimos un archivo desde nuestro disco a una aplicación de galería de fotos que ya vino instalada (acá podemos verificar permisos de escritura)

- Repetimos estas pruebas desde otra máquina, llegando al servidor via http://<nombredeservidor>

(este último punto nos servirá para comprobar los permisos y protecciones que puede tener el servidor para los usuarios finales)

Tal vez para Uds. pueda parecer trivial todo esto. Yo quisiera recibir ahora un peso, por cada vez que vi que una tarea como la de arriba, fue considerada terminada solamente con instalar el servidor. O solamente poniendo http://localhost. O por cada vez que una migración de base de datos se dio por buena con simplemente que no de error en el traspaso de datos.

El escribir el test (en un programa, en un papel, en un email) también sirve para que cualquiera en el equipo pueda encarar más fácilmente la etapa de verificación, y para cuando alguna vez haya que repetir esa tarea. Es una especie de checklist de lo que tiene que quedar bien, en “verde” para que consideremos que lo que hicimos quedó bien terminado. Hay otras cuestiones a tener en cuenta, pero el test de cada tarea debería ser lo básico a cumplir.

Como todo en el Sprint, se puede ir refinando este documento, si descubrimos que sería conveniente tener en cuenta alguna otra cosa en la verificación de una tarea. Y el test también sirve para que podamos estimar el tiempo de verificar el trabajo hecho.

Gracias a @gabrielsz que fue el primero que me hizo ver estos temas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez