Angel "Java" Lopez : Scrum, Desarrollo de Software

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

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

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: 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

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

Scrum práctico en Santa Fé

lopez — Sat, 22 Aug 2009 14:29:19 GMT

Gracias al MUG de Argentina, y a Software Santa Fé, ayer viernes estuve dando un curso práctico de todo un día, sobre Scrum, en la ciudad de Santa Fé, acá en Argentina. Más de 30 personas asistieron, se dividieron en 6 grupos y llevaron a cabo dos sprints simulados, practicando lo que es el product backlog, el sprint backlog, las reuniones de sprint planning, sprint review, y daily scrum. Creo que fue un curso muy interesante, en el que los asistentes participaron activamente, haciendo el trabajo encargado, y preguntando todo sobre el marco de trabajo Scrum y metodologías ágiles en general.

Si quieren saber cómo es Scrum, pueden leer la introducción (en inglés y español):

Scrum Primer

Hay un artículo corto en inglés: What is Scrum?

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

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

Algunos enlaces adicionales:

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

http://agilemanifesto.org/ Manifesto for Agile Software Development

http://softwareagil.blogspot.com El blog de Juan Gabardini, dedicado a Software Agil, en especial Scrum

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

http://groups.yahoo.com/group/foro-agiles Foro de prácticas ágiles, en español, muy interesante de seguir.

La presentación que usé está en mi Skydrive:

Scrum200802-2003.ppt (formato PowerPoint 2003, 7Megas)

Scrum200802.pptx (7Megas)

Scrum200801.ppt (Presentación original, más liviana, con menos gráficos, 1.2M)

Agradezco a Diego Poza, por haber mejorado y ampliado la presentación original.

Para preparar gran parte de la presentación, usé:

El libro que me sirvió de base para esta presentación

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.

Process Dynamics, Modeling, and Control, Babatunde A. Ogunnaike and W. Harmon Ray (Oxford University Press, 1994)

La teoría que subyace a Scrum.

The Alphabet Versus the Goddess, Leonard Shlain (Viking Penguin, 1998)

El conflicto entre las palabras y la imagen.

Wicked Problems, Righteous Solutions, Peter Degrace and Leslie Hulet Stahl (Yourdon Press, 1990)

A Universe of Consciousness, Gerald Edelman (Basic Books, 2000)

Por qué es tan difícil pasar de requerimientos a código.

Managing the Unknowable, Ralph D. Stacey (Josey-Bass, 1992)

Explicando las dificultades del manejo de la complejidad.

Complexity and Emergence in Organisations, Ralph D. Stacey (Routledge, 2000)

Una crítica de cómo la teoría de la complejidad ha sido aplicada para entender organizaciones y marcar nuevas direcciones. Este libro promueve un reexamen radical del pensamiento gerencial.

Artful Making, Rob Austin and Lee Devin (Prentice Hall, 2003)

Como manejar el trabajo creativo, adaptado del teatro.

Nos leemos!

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

Tales from the Scrum: Cómo transferir conocimiento en un proyecto ágil

lopez — Thu, 20 Aug 2009 10:33:13 GMT

Ayer conocí, gracias a un mensaje del bueno de Jonathan Cisneros, autor del AjGenesis Studio, de este interesante experimento:

How to transfer knowledge in an Agile Project

(Ciertamente, es un único experimento que habrá que refrendar con otros experimentos). Pero he asistido a situaciones similares y puedo decir que es una forma válida de transferencia de conocimiento en un proyecto ágil, Scrum en particular.

¿En qué consistió el experimento? Steve Bockman trataba de saber cuál es la mejor forma de transferir conocimiento. En un proyecto ágil, Scrum en particular, es frecuente trabajar en un equipo con distintas habilidades y conocimientos, y es importantes que lo que un miembro del equipo conoce y sabe hacer, sea en algún momento asimilado por los otros miembros del equipo. Steve explica su experimento en:

Avoiding the knowledge transfer bottleneck

En el experimento, Steve trató de transferir conocimiento sobre un producto no usual: cómo construir un aeroplano de papel. Lo intentó de tres formas:

- Documentación: a los participantes se les dio instrucciones escritas (22 pasos) para armar el aeroplano.

- Ingeniería Inversa: a los participantes se les dio un aeroplano completo que podían estudiar para reproducir los pasos para armarlo.

- Mentoring: el “diseñador en jefe” arma el aeroplano paso por paso, y los participantes replican cada paso a medida que lo ven realizado.

El experimento fue realizado con 8 participantes, con una duración total de 5 minutos para cada escenario. Los resultados fueron:

Sólo 12.5% de las personas pudieron completar el trabajo usando la estrategia de leer la documentación. Usando ingeniería inversa, el 25% de las personas pudieron armar el aeroplano. Mientras que usando mentoring, el 100% de los participantes completó el trabajo.

Yo pienso que esto es otra forma de demostrar que no somos Vulcanos: un vulcano escribiría la documentación, de tal forma, que cualquier otro vulcano podría entenderla de primera vez, para realizar el trabajo. Y entendería casi inmediatamente el por qué de los pasos.

Tal vez, el mentoring, no transfiere tan rápidamente el “por qué” de alguna práctica. O eso lo van descubriendo los participantes con el tiempo, o por contraste con otra práctica. Ejemplo: podemos aprender pair programming, usando mentoring, pero por qué preferimos esa práctica de programación a pares, será cuestión de verlo por contraste con no hacerla.

En un anterior post:

Tales from the Scrum- cualidades de los miembros del equipo

sugería que se puede hacer pair programming en una tarea, donde uno de los participantes está más capacitado que otro. Esto tiene también la consecuencia de transferir las habilidades y conocimientos de un miembro del equipo al otro. Vean que hablo no sólo de conocimientos: también de habilidades. Yo puedo conocer todo sobre armonía musical pero no tener la habilidad de tocar el piano.

Esa forma de pair programming, viene descripto por Young Ye y Royce Fay en un paper (pdf)

Knowledge transfer using Asymmetric pair Programming

Este método lo aplican no sólo a trabajo de a pares con desarrolladores, sino también entre desarrolladores y usuarios del dominio. Pone énfasis, entonces, en la comunicación humana más que en la documentación.

Alan Skorking escribió también sobre el tema en:

Effective vs Ineffective Pair Programming

Escribe: “En mi opinión, el beneficio más importante es el hecho que trabajar de a pares es altamente favorable a la transferencia orgánica de conocimiento…. Creo que es la clave porque en un sistema grande prácticamente no hay otra forma de hacerlo bien”.

Justamente, ahora estoy envuelto en el desarrollo en equipo de un sistema con un dominio grande, y complejo. Sería interesante comenzar a aplicar este tipo de transferencia, no sólo dentro del equipo, sino también con los expertos del dominio. Esto no quita la existencia de documentación, pero es difícil de escribir en dominios complejos.

Imagen tomada de http://www.kegoodpractice.org/

Nos leemos!

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

Tales from the Scrum: El corazón de Scrum

lopez — Tue, 18 Aug 2009 09:20:58 GMT

Al final de un anterior post:

Tales from the Scrum: Informando el estado

comentaba que había otra herramienta para ir coordinando y viendo el avance del equipo en el proyecto. El bueno de Tobias Meyer, quien fue mi instructor de Scrum Master en el 2006, escribe en estos días un post más poético, pero que apunta al corazón del tema. Pueden leer el original en:

The heart of Scrum

Hoy les deje una traducción libre:

Cuanto más enseño y hago coaching de Scrum, más me convenzo que el tablero de tareas es el corazón del Scrum. Sin el tablero de tareas no hay centro, no hay foco. El tablero de tareas, cuando es realmente comprendido, se transforma en el hogar espiritual del equipo, en la iglesia, si quieren llamarlo así. Los miembros del equipo arguyen,discuten, innovan, alrededor del tablero de tarea, se alinean unos con otros, para corregir el rumbo, para aprender, para celebrar.

El tablero de tareas genera colaboración. Es visual, es táctil, es más grande que la vida (es más grande que la pantalla de una computadora). Se yergue como un gran y visible marcador de nuestro de progreso y de nuestro carácter. Proclama quienes somos como equipo. Es nuestra identidad. El tablero de tareas nos dice la verdad, y difunde el mensaje: no tenemos miedo.

El tablero de tareas es frecuentemente descripto como el “water cooler” (enfriador de agua) del nuevo paradigma. El paralelo, aunque tiene buen sentido, está haciendo al tablero de tarea un daño. Sí, es el lugar para interactuar. No, no es un lugar para quejarse, para esparcir rumores, o desgarrar el equipo. El tablero de tareas es el lugar para regenerarse a uno mismo, para reconectarse, para tomar respiro. Representa una carrera hacia, no un escape, una carrera de huida de.

Scrum es la antítesis del cubículo corporativo de la mentalidad de divide-y-vencerás. No necesitamos mesa de tenis o metegol para calmarnos, para crear un balance artificial de trabajo y vida. No necesitamos divertirnos como algo más allá del trabajo. El trabajo es divertido. No necesitamos momentos de “water cooler” o cortes para fumar para ejercitar nuestras profundas necesidades humanas de conversación, de interacción. En Scrum, nosotros vivimos de esta manera. Todo el día, todos los días.

Scrum es todo sobre la gente, no sobre competencias o capacidades. Scrum no es “yo” sino “nosotros”. Es acerca de compartir, aprender, mejora continua, interacción vibrante, colaboración apasionada y crecimiento personal. Scrum es sobre tribus, sobre construir comunidad. Cada miembro de la tribo necesita un sentido de pertenencia, de búsqueda personal. Tribus enteras necesitan lugares de interacción, necesitan objetos sagrados, necesitan foco y necesitan pulso. Scrum soporta esa forma de ser. El tablero de control, y el ambiente que emerge de él, provee esa fuerza central de vida, donde este tipo de cosas nacen.

Para vivir, para realmente vivir, Scrum necesita un corazón. Y ese corazón es el tablero de control. Sin él, Scrum nos parece y se siente insípido. Es débil, y delgado. Pierde su foco, y sin un controlador externo (por ejemplo, un coach, o un campeón del producto) para continuamente insuflar vida en él, el esfuerzo pronto se disolverá de nuevo en el proceso disfuncional al que quería reemplazar. Sin ese corazón, Scrum no tiene poder.

Uno de los servicios más importantes que un Scrum Master puede hacer por su equipo y por la organización en conjunto, es crear transparencia. La transparencia nos permite ver las fallas, y cuando vemos las fallas, podemos elegir hacer algo con ellas. Podemos parar de ser víctmas del proceso y comenzar a ser guerreros del cambio.

En el blog de Xavier Quesada Allue Visual Management encontraremos muchas sugerencias sobre cómo usar el tablero de tareas para alcanza el objetivo de la transparencia. El trabajo de Xavier en esta área toma el tablero de tareas y lo transforma de un objeto útil en un objeto de belleza e inspiración. Y de la manera en que lo veo yo, éste es el lugar correcto del tablero. El corazón se nutre de amor.

Les recomiendo la visita al blog de Xavier, y el de Tobias, Agile Anarchy (el actual) y Agile Thoughts (el anterior). Vean de visitar y soportar su iniciativa Welfare SCM:

Statement of Intent

WelfareCSM is a program designed by Tobias Mayer to embrace the change we are currently experiencing in the world. The aim of WelfareCSM is two-fold:

1. To offer low-cost or no-cost Scrum training, including Certified Scrum Master training to individuals in low-paid jobs, the unemployed, students and anyone working for a company that has cut its training budget in this time of crisis.

2. To spread the principles, practices and values of Scrum beyond the software world, by training people from other industries, and those involved in other kinds of work or community activities.

He tenido poca experiencia con un tablero físico, en muchos equipos se tiende a tener una herramienta electrónica. Pero cada tanto trato de armar un tipo de tablero así. Cuando existe, la reunión diaria de Scrum se realiza ENFRENTE del tablero, es el lugar donde el equipo se reencuentra con sí mismo y con el proyecto.

Nos leemos!

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

Tales from the Scrum: Armando un equipo automanejado

lopez — Wed, 12 Aug 2009 11:15:56 GMT

Ya sabemos que Scrum es un trabajo de equipo. Pero una cosa que diferencia a Scrum, es que el equipo es automanejado. ¿A qué apunta esto? A que el equipo toma decisiones y se mantiene y mejora como equipo, por sí mismo. Por supuesto, con ayuda, de quien quiera ayudar: desde el Scrum Master, hasta mentores, otros equipos e interesados. Pero el equipo toma decisiones en varios puntos del proceso, el principal es el planeamiento del próximo sprint, iteración.

Ya escribí que me parece importante el desarrollo del equipo; es parte del entregable, aunque no lo parezca:

Tales from the Scrum- su equipo, el próximo nivel

Pero muchas veces, el equipo no tiene toda “la salud” para auto manejarse, o sus miembros vienen de otros ámbitos donde no se fomentó esta actitud. Veamos algunos puntos a revisar, para mejorar en estos puntos.

Primero:

Deje de hacer esto

- No dejar que los participantes del equipo participen en todas las etapas del ciclo de desarrollo. Cuanto más se involucren en todas las actividades, como reuniones con los clientes, planeamiento, toma de requirimientos, diseño, mejor. No todos tienen que estar en una reunión de diseño. Pero hay que ir viendo de que todos los miembros, en algún momento, hayan tomado parte de alguna de las actividades. Un anti-pattern: sólo “los principales” miembro del equipo asisten a al reunión de cierre de Sprint. Si cada miembro del equipo participa de cada actividad, en algún momento del proyecto, verán de embeberse más del proyecto y del proceso, en vez de encerrarse en su zona de confort o “expertise”.

- Asignar tareas a los miembros: es común que alguien vaya asignando tareas a algunos miembros. Hay que dejar de hacer eso. Hay que fomentar que los miembros del equipo vayan tomando tareas, por propia cuenta. Y promover que cada miembro de equipo no se centre sólo en lo que sabe. El especialista en base de datos puede participar de una tarea de diseño de interfaz de usuario, tal vez ayudado por “pair programming” con otro miembro que conozca del tema. Esto permite que los miembros vayan interactuando, conociendo las debilidades y fortalezas de cada uno, y ayudándose y aprendiendo unos de otros al mismo tiempo.

- Decir para cuándo tiene que estar tal tarea lista: hay que recordar que esa es una decisión del equipo, en Scrum. Claro que se espera que el equipo vaya mejorando en la estimación de los tiempos y en la velocidad de avance. Pero es una decisión de los miembros del equipo cuánto tiempo necesitan para terminar con una tarea. Se podrá discutir qué hace falta para avanzar más rápido, qué cambios hacer para mejorar en eso, pero la decisión del tiempo es del equipo. Si Ud. no deja esta decisión en el equipo, no logrará que avance en las cualidades de autogestión.

- En la reunión de planeación de sprint, las tareas propuestas por el producto owner, son aceptadas sin mayor discusión, o sin evaluar si se pueden conseguir en tiempo en forma. Esta es una variante del anti-pattern “asignar tareas”. Una de las funciones principales de la reunión de planeamiento, es que el equipo (no uno, o dos miembros), discuta y tenga en claro los pasos y esfuerzos estimados para cumplir con lo que el product owner pide. Es común (y no debería serlo) que se tome eso tal cual, sin discusión, y sin haber pasado en limpio lo que implica comprometerse a realizar esas tareas.

- Saltearse las retrospectivas: no hay tiempo, siempre se posponen. No: pare de olvidarse de esta reunión. La retrospectiva es una actividad, yo diría fundamental, para que el equipo madure y mejore. Es un “parar la pelota”, ver para atrás, y señalar qué se hizo bien, regular, o simplemente mal. Y, aun más importante: en la reunión se decide qué hacer para mejorar.

Segundo:

Comience a hacer esto

- Limpie el camino para el avance. Haga que el equipo pueda avanzar, y quite los bloqueos que encuentre. Puede ser desde falta de hardware, hasta temas políticos de relación con otros departamentos. Eso permitirá que el equipo se concentre en lo que tiene que hacer, más que luchar con la fricción y los impedimentos. Cuando el equipo esté más maduro, podrán los propios miembros del equipo ocuparse de esto, tal vez rotando en la tarea por Sprint, pero al principio, habrá que permitir que el equipo crezca, sin tener que lidiar tan directamente con estos problemas.

- Sea un facilitador y mentor. Como facilitador, vaya por el anterior punto. Como mentor, observe, comente, señale la actividad y actitud del equipo, proponga mejoras (no las imponga), sea un entrenador de cada persona, reconozca en qué son buenos, en qué son regulares, y trabaje con ellos para ir mejorando.

- Mida el avance. El equipo se auto organiza, pero comience a medir el avance, y difundiendo esa medición. Esto hará que el equipo tenga una imagen de cuán bien o mal están yendo. Cualquier desviación del plan de trabajo, debe surgir lo más pronto posible, para que el equipo autoorganizado pueda detectar el problema, la causa, tomar una acción correctiva, y aprender a no caer de nuevo en ese paso.

En un equipo maduro, cada miembro se ocupará, casi automáticamente, de estos puntos. Pero al principio, habrá que cultivarlos activamente. Con el tiempo, llega el momento en que el equipo “cuaja”: comienzan a entrar en pista, a ganar confianza, a ver que la forma de trabajo que eligieron funciona, y entran “en flujo”: una forma continua, rítmica, de avance, hacia el objetivo final.

Varios de estos puntos los tomé, e interpreté y comenté a mi manera, del post:

How to Build Self-Managed Teams

Imagen tomada de: http://www.skyjump.com/Pages/SkydivingPhotosVideos.html Photo by Phil Robertson

Nos leemos!

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

Tales from the Scrum: Ser easy to work with

lopez — Tue, 11 Aug 2009 11:12:52 GMT

Ya sabemos que el avance en Scrum es un trabajo de equipo. Como miembro del equipo, uno tiene que colaborar con los otros miembros para conseguir que el trabajo avance. Una de las cualidades que deberíamos perseguir, para cada uno de nosotros y para el equipo, es lo que en inglés se escribe “easy to work with”: que los demás perciban que es fácil trabajar con nosotros.

Como otros conceptos, puede ser más fácil describirlo con algunos ejemplos negativos:

Si uno llega tarde a las reuniones diarias, reiteradamente y sin buenas razones y no avisa, eso no es ser “easy to work with”.

Si uno hace una tarea y no informa que la terminó, o en qué estado la dejó, el resto del equipo no podrá aprovecharse de ese resultado, y Ud. no será “easy to work with".

Si Ud. codifica algo, y lo envía al repositorio de código, y está mal escrito, de forma que cualquiera que tome la última versión, encuentre una solución que no compila, eso es no ser “easy to work with”.

Si cada tarea que Ud. termina, al revisarse para verificarla, se encuentra que tiene muchas correcciones a hacer, y esta situación se repite, entonces, Ud. no será “easy to work with”.

Si lo que escribimos produce un aumento en las infracciones de Code Analysis, y otro tienen que pasarse un tiempo corrigiéndolas, y eso se repite, entonces no seremos “easy to work with”.

En definitiva, si alguien, con su trabajo, produce un montón de trabajo EVITABLE en los demás, ese alguien no será “easy to work with”.

Si alguien es así, a la larga pasará que nadie va a querer trabajar con él, y no confiarán en lo que produzca.

Lo mismo puede pasar a nivel de equipo. Si como equipo entregamos la nueva versión del software al final del Sprint, y el cliente no tiene instrucciones para instalarlo, o tiene que armar una máquina virtual durante dos semanas para poder ejecutar lo que entregamos, no seremos “easy to work with”. La solución: ir mejorando en cada Sprint, para que lo entregable sea fácilmente consumible, por ejemplo, dándole una máquina virtual ya armada, y el software e instrucciones para correrla.

Pero aparte de estos temas técnicos, hay temas de cualidades de relación con los demás, de los “soft skills” tan importantes en todo grupo. Veamos algunas cualidades para ser “easy to work with”:

- Sea flexible. Si Ud. no es ágil para actuar en un ambiente cambiante, con requerimientos que se van modificando, tendrá problemas. Si Ud. es un cabezón que siempre cree tener la razón, y si no se la dan, se empaca, también tendrá problemas. A veces, hay que ser flexible, entender a los demás, y ver que no siempre se puede seguir el camino que a uno le parece mejor. Explore nuevas formas de hacer las cosas, no rechace algo de antemano solamente por que sí.

- Sea un buen comunicador: no es indispensable, pero es bueno tener buenos comunicadores en el equipo. He visto buenos miembros de equipo, callados, pero que compensan esa escasa comunicación, siendo un “tanque Sherman”: gente que toma una tarea, y la termina, sí o sí y con calidad. Pero volvamos a la comunicación: es importante, porque no todo es código. Recordemos que lo que hacemos lo tenemos que mostrar, tenemos que informarlo, tenemos que interactuar con los clientes. Si todo lo que hacemos es maravilloso, pero no lo comunicamos, es como si no lo hubiéramos hecho. A veces, uno piensa que armar una presentación es una pérdida de tiempo, pero no: puede ser la pieza clave que falta para conseguir apoyo de los interesados en el proyecto. Si Ud. es un buen comunicador, otras partes (otros equipos, product owner, stakeholders, clientes, usuarios) querrán interactuar con Ud. Y será alguien “easy to work with”, no un erizo a evitar.

- Esté disponible. No hace falta estar disponible 24 horas, 7 días. Si el equipo se organiza, se debería organizar todo para cinco días a la semana, y 10 a 18hs. Pero en ese tiempo, si alguien necesita su ayuda, tenga planeado tiempo libre para poder ayudarlo. En la reunión diaria no tiene que comprometer las 8hs de trabajo: es de profesional, reconocer que hay tareas que pueden surgir, y reservar entonces tiempo para esos casos que pueden aparecer en el transcurso del día. Cuando alguien vaya a preguntarle algo o a pedirle ayuda, irá con la expectativa “Fulano me va a ayudar”. Otra forma, indirecta, de estar disponible, es haber escrito instrucciones de cómo usar algo, o dejado información sobre lo que uno hizo. Por ejemplo, si Ud. diseñó un parte del sistema, si alguien quiere preguntarle sobre una decisión de diseño, puede hacerlo, pero si no está disponible (está enfermo, de vacaciones), que por lo menos pueda encontrar fácilmente un documento (no tiene que ser extenso ni “fancy”) que explique lo que hizo.

- Sea positivo: Si cada vez que abra la boca, es para tirar abajo algo, pasarán dos cosas: la gente lo evitará, o dejarán de tomarlo en cuenta. “Ahí viene el tiramerdis” pensarán cuando lo vean venir. No confundir una actitud positiva con un “está todo bien” a ultranza. Hay que reconocer los problemas. Solamente hay que ser también, parte de la solución, o por lo menos, ayudar a que en equipo consigamos la solución. A quién quiere tener al lado al naufragar en una isla desierta? Alguien que diga: “Viste, yo te dije que no teníamos que venir, ahora está todo mal, no me hicieron caso…”, y se pase todo el día lamentándose así, o a alguien que diga: “Tenemos un problema, veamos como lo podemos solucionar”.

- Sea honesto: si Ud. ve un problema, o tiene un bloqueo, o no sabe como encarar una tarea, dígalo. En el equipo tiene que reinar la honestidad y la comunicación. Acá no se busca castigar al que no sabe o no tiene tal capacidad. Si hay un problema en ciernes, lo mejor es comunicarlo. Si ve que hay algo mal en el equipo, dígalo. Pero también combine esto con todo lo de arriba: comuníquelo bien, sea positivo, no señale con el dedo a personas sino a problemas, vaya con algún atisvo de solución.

- Diviértase: nadie quiere a un “caracúlico” al lado todo el día… :-)

Habría tanto para comentar. Pienso que en todas las relaciones, más allá de un equipo de Scrum, tenemos que ir cultivando el ser alguien “easy to work with”. Ud. puede ser el gran gurú en un tema, pero estará solo y no conseguirá nada, si los otros no ven en Ud. alguien en quien pueden confiar, alguien con quien sea fácil trabajar.

Para las últimas cualidades, consulté y expuse a mi manera, lo del post:

Be easy to work with

Nos leemos!

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