August 2009 - Posts
Me gustó el diseño simple pero funcional de este robot de la gente de takram design engineering:
Lo bueno es el diseño compacto que tiene, y la velocidad que consigue.
La página del producto es:
http://www.takram.com/html/?page_id=1951
Leo ahí:
Phasma is a hexapedal running robot that can run dynamically like a living organism. It is an attempt to depict life purely through its motion rather than its shape, by extracting the physics of running from living things and implementing that to the artifact. Phasma uses compliant components such as stainless steel springs and rubber joints to reproduce smooth and efficient locomotion seen in animals. Another interesting biomimicry applied in Phasma is the alternating tripod gait as seen in insects that provides excellent stability.
Interesante. Tiene estabilidad, trata de imitar a los insectos, y las patas son sencillas: sin necesidad de articulaciones, han conseguido algo que funciona. El tamaño elegido debe tener también su impacto: si fuera más grande, tendría problemas de locomoción, imagino. No me quedó claro el tiempo de autonomía que tiene este hexápodo.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
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
Hace unos meses, Microsoft presentó el Project Natal, para XBox. No soy un gamer, pero es muy interesante lo que lograron, porque veo que es un paso para que este tipo de interfaz aparezca en otros dispositivos:
El dispositivo usa reconocimiento de caras, de voz, y sensores de movimiento, para que se pueda conseguir el tipo de interacción que ven en el video. Vean en el video usos más allá de los juegos. Tienen importación de imágenes: podemos hacerle que agregue una imagen de un objeto que le presentamos, y usarlo en la aplicación que esté programada para aprovechar eso. Trabaja con luz normal o con poca luz. Usa “skeletal tracing”, no conozco los detalles, pero detecta el movimiento de todo el cuerpo.
Otro video:
Información más completa y más videos en el sitio oficial:
http://www.xbox.com/en-US/live/projectnatal/
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Encuentro gracias a un enlace enviado a la lista de Robots Desarrolladores, el sitio:
http://www.ideaconnection.com
Hay excelentes recursos de sobre innovación:
http://www.ideaconnection.com/innovations.html
Pueden ver videos que coleccionan ahí, en:
http://www.ideaconnection.com/innovation-videos/
El primer video que me llamó la atención, es esta tecnología de holografía tocable:
Como han ido apareciendo dispositivos que proyectan en el medio del aire, o contra cualquier superficie, se ha ido creando la impresión de imágenes “holográficas” enfrente de uno, como que están flotando ahí adelante. Pero no se pueden “tocar”, son sólo luz.
El proyecto de Airborne Ultrasound Tactile Display usa ultrasonidos para producir sensaciones táctiles sin contacto directo y sin estorbar la calidad de la imagen proyectada.
Pueden leer un PDF corto explicando más en detalle la tecnología aquí.
Quiero mi holodeck!! :-)
Post relacionados:
Holodeck a la Google
Tendremos TEDxBuenos Aires
Un touch para Rubik
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
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
de Ken Schwaber ISBN:073561993x Microsoft Press © 2004
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
Hay bastante revuelo sobre los conceptos y aplicaciones de Cloud Computing, con ofertas de prácticamente todos los grandes jugadores del software. En estos días encontré este video, corto, que sirve para que podamos transmitir, no tanto el tema técnico, sino la proposición de valor que ofrece la nube. Podemos verlo como una extensión de tercerizaciones que ya se venían haciendo (como el hosting del sitio de una compañía), pero a mayor escala (a tener en cuenta para evaluar este video: es un video comercial de SalesForce.com):
Hay muchos temas técnicos a discutir, y muy interesantes. Por ahora, vayamos viendo cómo puede influir en nuestros desarrollos y proyectos, todo esto de la nube.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
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
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
Va tomando cuerpo la propuesta lanzada por Alberto Arroyo en el grupo ALT.NET Hispano, de formar una alianza, para producir una aplicación. Algo había comentado en este post:
Proyecto, producto, empresa
Se realizó una reunión virtual el sábado pasado, pueden leer un resumen de las conclusiones, y ver el video de toda la reunión, en:
http://altnet-hispano.pbworks.com/altnetcafe-2008-08-08#
Una sugerencia: se podría armar alguna encuesta para los que no asistimos a las reuniones? No sabía que iba a haber encuesta en la misma reunión, pensé que se iba a discutir decisiones también por otros medios.
Pueden asistir a la segunda reunión, hoy sábado, a las 18hs GMT (en Argentina, que tiene huso GMT-3) son 15hs. Pueden ver más detalles en la portada de:
http://altnet-hispano.pbworks.com/
donde se describen cómo son las reuniones VAN y qué software se necesita para participar.
En la reunión pasada (a la que no pude asistir), presentó su propuesta Alberto Arroyo, basado en lo que ya ha estado armando para Codesol:
http://www.codesol.info
Hubo un momento en que los participantes se inclinaron por desarrollar un CMS (Content Management System):
Mi opinión: el mundo no necesita un CMS más. Creo que el mercado ya está saturado de ese tipo de aplicaciones.
Algo parecido planteó Daniel (perdón, no tengo el nombre completo): de esos proyectos hay un montón.
Lo que puede servir es como proyecto de entrenamiento del grupo. Yo ahí disiento: prefiero que si el proyecto final será un CRM, entonces, hay que comenzar con algo chico, pero relacionado con CRM. Si se comienza con un CMS como entrenamiento, veo mejor que el primer proyecto, sea ya orientado al proyecto final.
Es interesante que Alberto Arroyo mencionó el caso del framework CSLA como ejemplo de proyecto colaborativo pero que ha generado un “mundillo” alrededor, de desarrollo, de empresas que lo usan. Alberto dejó en claro que quiere plantear un producto X que genere dinero. Tal vez, lo que veo que enturbia un poco esa visión, es que también Alberto menciona un asociación para “validar” el software de código abierto. Creo que ese es un proyecto interesante, pero no sé si necesario, y que dejaría de lado en esta discusión.
En otro momento, se discutió cómo generar ingresos desde un proyecto open source que, por ejemplo, implemente un CRM. Creo que fue Alberto Arroyo @beyondnet el que comentó el tener un núcleo open source y que luego se puede extender y adaptar a cada país, y ahí vendría la ganancia: cada empresa que lo extienda para su mercado, tendría ingresos del proyecto original.
Lo que yo veo de inconveniente es esto: ese modelo no genera ingresos para los que participan del proyecto, pero no montan una empresa o no tienen un mercado adecuado o las inclinaciones y capacidades comerciales para llevar adelante esa extensión y conseguir ingresos. El “cada quien haga su propio negocio” no me cierra como modelo. Eso lo he visto en otros proyectos de código abierto: lo que pasa, es que sólo algunos de los participantes pueden conseguir ingresos de esa forma.
Si la idea es
contribuir a la comunidad Y ganar dinero
, eso de tener un core, y luego que cada cual consiga dinero sobre eso, se va a derivar en
contribuir a la comunidad
lo que me parece magnifíco, y
Y ALGUNOS ganaran dinero
A lo cual no veo gran problema, es lo que pasa todos los días, con muchos productos de código abierto, pero me parece que hay un camino mejor.
Mi propuesta es: hay un “core” de participantes del proyecto, dedicados ya sea a diseño, desarrollo, documentación, difusión, entrenamiento, etc… Cuando alguno de esos participantes genere ingresos con el producto/proyecto, podría aportar una parte a un fondo común del proyecto. Se puede discutir el reparto entre los participantes.
Se mencionó el problema legal (disculpen, no tengo el nombre de quien puso en la discusión el tema, creo que es de México, nombre Daniel?): no veo que haya problema. Cada uno de los participantes puede facturar desde su empresa o como individuo, pero aportar a un fondo común a repartir, con facturación entre los miembros.
Alberto mencionó que no le gustaría que alguna empresa tome el producto a desarrollar, lo nombre a su manera, y prefiere una licencia “más compacta” que la GPL. A mí tanto no me preocupa ese caso. Si el producto, y el grupo que lo forma, es fuerte, no tendría que preocuparse de los forks comerciales o no. Es parte del juego: el grupo inicial tiene que luchar siempre por la colina, y me parece bien. La fortaleza vendrá de la popularidad y reconocimiento del proyecto inicial en la comunidad y ámbito empresario, y por el soporte del grupo núcleo, más que por la licencia a usar.
No veo problema en que el proyecto a producir sea de código abierto, y se piense en un mercado comercial, con ingresos. En mi anterior post, puse como caso paradigmático a JBoss. Podría apuntar otro, que se mencionó en la reunión VAN, como el Compiere. Vean cómo el modelo de este último, permitió tener un producto con un mercado. No hizo falta una asociación aparte para validarla, Compiere es fuerte por lo que brinda. Lo mismo pasó con JBoss, MySql, Mono, etc. Y yo podría hacer un fork de Compiere, cambiarle el nombre, y eso no afecta la fortaleza del proyecto inicial.
Las debilidades, pienso, vienen por otro lado:
- La falta de objetivo claro (idea, producto, mercado, estilos de llevarlo a cabo…)
- La formación de un equipo nuevo
Me pareció interesante, lo que mencionó Jorge, creo: sobre que al principio se apuntan 15 y luego trabajan 5. Eso siempre pasa. El tema, como dice Jorge, es que el núcleo inicial perservere.
Pero independientemente de todo esto, lo interesante y bueno es ver que estando dispersos, podemos ir coordinando algo. La tierra es plana, más para nosotros, los desarrolladores de software.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
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
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
En estos días, encuentro este post (supongo que gracias a un Twitter, pero no tengo anotado el nick):
10 commandments for creating good code
Acá va la traducción, y algunos comentarios, desde una perspectiva de trabajo ágil:
1 – DRY Don’t repeat yourself – No se repita
DRY es usualmente el principio más fácil de entender, pero el más difícil de aplicar. Significa que cuando encontramos código similar en uno o más lugares, deberíamos abstraerlos en un nuevo método y cambiar los anteriores fragmentos de código para que llamen al nuevo método con los parámetros apropiados.
DRY es posiblemente el principio de codificación más universal, yo nunca he encontrado un desarrollador que argumentara que repetir código es bueno, pero, he encontrado desarrolladores que olvidan este principio cuando codifican pruebas unitarias, como ejemplo: imaginen que han cambiando la interface de una clase que tiene montones de pruebas unitarias, si no han usando DRY, tendrán que cambiar a mano las llamadas a esa interface para cada caso de prueba.
Pienso que podemos repetirnos, siempre y cuando tengamos planeado el refactoreo del código. Si siguen Test-Driven Development, no hay que hacer hincapié en este principio siempre, sino tenerlo presente en la etapa de refactoreo. A veces, no tenemos claro cuál es la implementación que necesitamos abstraer, hasta que tengamos varios casos resueltos.
2 – Write short methods – Escriba métodos cortos
Hay tres buenas razones para escribir métodos cortos:
1. El código será más fácil de leer
2. El código será más fácil de reusar (métodos cortos tienden a tener bajo acoplamiento).
3. Él código será más fácil de probar.
Sí, siempre trato de escribir código con métodos cortos. Pero, de nuevo, se puede saltear esto, siempre que luego tengamos planeado el refactoreo (y no la semana que viene, sino tenerlo con frecuencia, y temprano, ver mandamiento 7).
3. Use good names for your classes, methods and variables – Use buenos nombres para sus clases, métodos y variables
No hay nada más lindo que ver el código de otro programador y no necesitar leer la documentación porque los nombres de las clases y los métodos nos dicen todo, así, que tome este camino y haga la vida más fácil para todos, gaste siempre unos pocos segundos antes de nombrar cualquier elemento en el código.
Recuerdo cuando los linkeditores que usaba no permitian nombres públicos con más de 7 caracteres. O cuando trabajaba con un intérprete BASIC que solamente se fijaba en las dos primeras letras de cada variable, para ubicar su valor. Desde que las herramientas modernas nos han liberado de esas restricciones, no dudo en usar nombres descriptivos. Ken Thompson siempre se lamentó de haber nombrado creat() a una función del Unix/C original.
4. Assign the right responsability to each class – Asigne la responsabilidad correcta a cada clase
Una clase, una responsabilidad: esto sonará familiar a quienes conozcan los principios SOLID, pero no hay cualquier responsabilidad, sino la correcta, así que si tenemos una clase Customer, no le asignaremos a ella la responsabilidad de crear una nueva acción de ventas, apenas le asignaremos la responsabilidad de manejar todos los datos relacionados con un cliente.
Creo que esto viene aún antes de refactoreo, pero bueno, si no lo consiguen de primera, pueden solucionarlo en la etapa de revisión. Pero tanto si hace diseño antes, como si van descubriendo la funcionalidad necesaria con TDD, veamos de respetar este mandamiento.
5. Keep your code organized – Mantenga su código organizado
Esta organización está a dos niveles:
- Organización física: Cualquiera sea la estructura que esté usando, paquetes, espacios de nombres, carpetas… Organice sus clases de tal manera que sea fácil e intuitivo encontrar dónde está el código.
- Organización lógica: Cualquier cosa que se relacione lógicamente con otras, deberá acceder a los demás miembros del grupo, pero si pertenece a otro estructura lógica, tendrá que acceder a ellos usando una interface. Estos grupos lógicos son comúnmente implementados como capas, servicios…
Es necesario. Y revela una disciplina de organización, que hace más fácil nuestro trabajo y que otros trabajen con nosotros.
6.- Create lots of unit test - Cree montones de pruebas unitarias
Mayor cantidad de pruebas, mejor, ellas son su red de seguridad para todos los cambios que habrá que realizar en el código en el futuro.
Yo mencionaría pruebas funcionales, además de unitarias. Pero tiene que haber pruebas. Si no siguieron TDD, sigan TAD (Test After Development), pero no pueden ir por la vida mostrando código sin pruebas asociadas. Recuerden: código “legacy” no es código COBOL, es código en el último lenguaje inventado, pero sin pruebas.
7. Refactor often and sooner – Refactoree con frecuencia y temprano
El desarrollo de software es un continuous discovery process (proceso continuo de descubrimiento), para mantenernos al día con buen código que cubrar los nuevos o cambiantes requerimientos es esencial refactor the code as we go (refactorear el código mientras lo desarrollamos). Como esta es una tarea riesgosa hay 2 precondiciones principales para evitar introducir nuevos errores en el sistema.
1. Tener montones de pruebas unitarias
2. Hacer pequeños pasos de refactoreo por vez. En el desarrollo de software hay pocas cosas más desconcertantes que comenzar el refactoreo de 2000 líneas de código y encontrarse que después de 3 horas de trabajo es necesario volver atrás a la versión original, porque ahora nada funciona y perdimos la pista de cuál cambio está causando el problema.
Si siguieron TDD, este es un mandamiento que se cumple solo. Sería igual bueno entrenarnos para no tener que hacer mucho refactoreo, hacer las cosas bien desde el principio. Pero no siempre es posible. Veo que con entrenamiento se puede ir mejorando en esto. Es una síntoma de avace, el ir cumpliendo con los principios casi desde el principio.
8. Comments are evil – Los comentarios son malignos
Este es uno un poco controversial, a muchos de nosotros nos enseñaron que los comentarios son buenos, y actualmente es mejor tener un comentario en una pieza obscura de código que solamente el código mismo. Lo que este punto indica es que aún mejor que tener un comentario para una pieza obscura de código es no tener ese código para nada, y refactorearlo hasta que sea una bonita y leíble pieza de código. Por favor, lean este otro post para una mejor explicación de por qué “los comentarios son malignos”.
Los comentarios que deberían ser admitidos son los que ayudan a alguna herramienta de documentación. O los que tienen una explicación del uso de la función, con un ejemplo (vean código Smalltalk, como ejemplo).
9. Code to an interface, not to an implementation – Codificar contra la interface, no contra la implementación
Esta es una clásica, codificar contra la interface nos liberará de los detalles de implementación, solamente definimos un contrato y llamamos las operaciones definidas en el contrato, esperando que la implementación actual será pasada a nuestro código o se decida en ejecución.
Pienso que esto es sólo necesario, llegado el caso. Podemos codificar contra lo concreto, como primeros pasos, y luego, descubrir la interface o interfaces que estamos usando. De nuevo, si usamos TDD (Test-Driven Development), hay algunos de los mandamientos que se cumplen solos desde el principio, y otros, que se pueden relajar, porque luego viene el refactoreo. Este es uno de esos casos que pueden relajarse al principio.
10. Have code reviews – Tener revisiones de código
Todos cometemos errores, y no hay nada mejor que preguntar a otra persona para que nos ayude a tener una revisión rápida e informal de nuestro código. Para hacer estas revisiones, es mejor no esperar hasta que el código esté completo, es mejor preguntar por revisiones en cuanto alguna parte importante del código se haya completado o cuando hayas pasado unos días desde la última revisión.
Veo que es poco frecuente encontrarse con revisiones de código. Es algo que debería hacerse. Vean cómo Google implementó un sistema de revisión de código distribuido, para que no haga falta reuniones previas y coordinadas para hacer esta actividad:
Mondrian Code Review On The Web
Muy interesante post de Making good software
¿Cuántos de estos mandamientos estamos cumpliendo?
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hace unos días escribía sobre la reunión diaria de Scrum:
Tales from the Scrum: la reunión diaria de standup
describiendo cómo se desarrollaba, y cuáles eran las motivaciones para ese tipo de reunión. Quiero hoy enumerar algunos anti-patrones que deberíamos tratar de evitar:
- Llegar tarde a la reunión. Se debería planificar la reunión para que todos puedan llegar. Si no todos están a las 9hs, pueden planearla para las 10hs, pero una vez consensuado el horario, habría que exhibir puntualidad. No llegar a tiempo, no un día, sino varios, indica que no hay manejo de los tiempos por parte del miembro infractor, o que tiene otros problemas, que deberá plantear al equipo.
- Hacerla unos días y otros no. La reunión se llama “diaria” por alguna razón, capisce???
- Hay diálogos. En vez de que cada miembro conteste las tres preguntas de rigor, se producen diálogos entre los miembros, con preguntas, respuestas, aclaraciones, descripciones detalladas de algo, discusiones, etc… No, todo eso se debe tratar en otra reunión, que perfectamente pueden organizar en el momento, luego del daily scrum.
- Largas contestaciones. Las respuestas a las tres preguntas, en vez de ser concisas, terminan en largos discursos, explicando cada detalle de lo que se hizo y se piensa hacer. Hay que explicar brevemente qué se hizo, pero no cómo. Cualquier detalle importante a comunicar al resto del equipo, debería haber quedado en algún informe de estado o documento.
- Se toman tareas sin respetar prioridades del backlog. No se conoce el backlog, o se toman las tareas que más nos simpatizan, en vez de tener en cuenta la prioridad dada por el sprint backlog.
- Todos le hablan a una persona. En vez de ser una reunión de información al equipo y sincronización, todos le habla a una persona, una especie de Program Manager implícitamente nombrado.
- Una persona reparte los trabajos. Alguien va dando tareas a cada miembro, en vez de que cada uno elija alguna tarea según las prioridades del sprint backlog.
- Estar distraído. Seguir contestando emails, mensajería instantánea, o leyendo Twitter.
- Falta de time-boxing. No se plantea que la reunión tiene un tiempo acotado, y no termina en un horario determinado.
Debe haber más anti-patrones. Los mencionados atentan contra la idea de lo que debe ser una daily meeting. Recuerden que es la actividad más frecuente de Scrum, y una forma de tomar el pulso del equipo, de la salud del proceso, día a día. Es una actividad importantísima, que permite ir detectando cualquier desviación en el desarrollo de la iteración.
Otros posts a leer:
Agile anti-pattern: the Daily Pseudo-Scrum Meeting
Scrum team Anti-patterns: How to piss off your ScrumMaster
Scrum – Challenges, Risks & Anti-Pattern
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
En el movimiento ágil, se pone primero a las personas. Y en Scrum en particular, el equipo es fundamental. Lo bueno de todo lo ágil y Scrum, es que permite ir mejorando, como miembros y como equipo en conjunto, aparte de ir entregando el producto esperado que se necesita. No sólo estamos “entregando producto”, estamos “entregando” un equipo que mejora, que se integra como grupo y que va a estar mejor preparado por cada Sprint que pasa.
Pero no siempre eso es así. Es un tema importante a discutir, los problemas que pueden surgir para que no sólo mejore lo entregado sino el grupo. Daría para varios posts. Pero hoy me va a bastar una lista de preguntas, que encuentro en el libro “Go Team!: Take Your Team to the Next Level” de Ken Blanchard, Alan Randolph, Peter Grazier, que escriben sin conocer el movimiento ágil, ni Scrum, pero que tienen varios puntos de contactos con lo que estamos tratando.
Los autores preguntan:
- ¿Todo el mundo en su equipo se siente comprometido, valorado y orgulloso de ser un miembro del equipo?
- ¿Su equipo tiene autoridad y la acepta, para tomar decisiones sobre sus tareas?
- ¿Entiende usted los límites de la autoridad de su equipo y puede ampliar esa autoridad?
- ¿Su equipo sabe cómo arreglárselas solo para hacer el trabajo?
- ¿Su equipo consigue auténticos buenos resultados?
Son grandes preguntas a contestar. Los autores del libro proponen que un “equipo del próximo nivel”, deberá aprender 3 habilidades claves:
- El intercambio de información, para crear niveles de confianza y responsabilidad
- Tener claros los límites para tener libertad de tomar responsabilidades
- Cultivar las aptitudes de autogestión para tomar decisiones y conseguir grandes resultados
Justamente, tres puntos que están muy alineados con Scrum.
Lo importante es, no contestar bien todas las preguntas de arriba, sino ir viendo de avanzar hacia todo eso. No solo hay un entregable de software al final de un sprint. Aunque no nos demos cuenta, estamos “entregando” un equipo, y cada uno de sus miembros, incrementalmente mejorado.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Esta práctica me resultó muy útil, cuando la adoptamos para varios equipos, hace ya como dos años. Cada equipo tiene una lista de correo, y al final de la reunión diaria, uno informa en la lista las tareas que se tomaron. Eso permite que interesados en el proyecto, que no están en la reunión diaria, ya sea porque no son parte del equipo, o porque están físicamente alejados, vaya enterándose de lo que se toma para ese día.
Pero además, cada integrante, va enviando a la lista de correo, su estado. Este es un ejemplo, del que envíe al comienzo día el pasado lunes:ç
En el estado pongo algo más detallado en pasos las tareas que tomé en la reunión diaria de Scrum.
Luego, a medida que va avanzando el día, digamos, cada 3 horas, o cuando se termina una cantidad de tareas que puede interesar al grupo, envío un email con el estado de avance Y verificación:
Lo que está informado acá, debería estar ya disponible en el repositorio de código del proyecto. La verificación es importante: permite informar en detalle qué página web o qué programa, o que directorio, cambió, y en qué forma, y eso ayuda para que cualquier otro miembro del equipo se base en esa información, para sus propias tareas. Por ejemplo, tal vez otro miembro del equipo encuentre interesante la implementación que hicimos de algún algoritmo, al informar que ese código está listo, y en qué lugar, y ya puesto en el repositorio, esa persona puede ir a verla y aprovecharla para su propia tarea. Los “screenshots” dan información más visual de lo hecho, y sirven como una verificación de que estuvimos probando lo que hicimos (lo que no impide que haya una verificación como otra tarea, tal vez tomada más adelante por otro miembro del equipo).
Al ser informado de forma escrita y en la lista de correo del equipo, queda registrado, y se puede poner información detallada, que tal vez se pierde o se olvida si se informa oralmente. El equipo de desarrollo está físicamente en la misma sala, pero este tipo de información sirva para pasar en limpio cualquier avance o bloqueo que hagamos durante el día.
El poner la lista al principio, y exponerla en la lista, también tiene su efecto psicológico: nos pone en compromiso con el equipo, con el product owner, con otros suscriptos a la lista, y con un mismo, sobre lo que hay que hacer ese día. Es una forma de contrato, de compromiso fuerte, que cada uno se impone y publica.
Vean que en el estado, voy colocando el estado en colores. Eso también tiene un efecto, como cuando tenemos tests de TDD. Es bueno ir viendo, a lo largo del día, cómo disminuye lo rojo y pardo, pasando cada vez más al verde.
Al final del día, envío un último email de “Mi Estado”, si hubo un cambio desde el último, y así todos van viendo qué se terminó y qué quedó pendiente. Uno debe entrenarse y aprender de sus capacidades, para que cada día quede todo en verde. No ponerse compromisos y tareas que no pueda cumplir.
El título tiene su sentido: al tener siempre la frase “Mi Estado”, se puede filtrar en los clientes de correo. Si todos los miembros del equipo siguen esta práctica, pueden producirse muchos emails de este tipo. Pero si hay miembros de la lista que no están interesados en leer todos estos emails, pueden filtrarlo por título.
A veces se plantea tener una lista aparte para este tipo de comunicación. Me parece que atenta contra la comunicación del equipo y los interesados. Debe estar toda la información disponible, sobre el avance, los problemas y soluciones, y verificaciones.
La verificación está, porque no basta decir “terminé tal reporte”. Hay que poner cómo salió, especificar qué pasos y qué formularios o páginas tuvimos que usar para producirlo, que usamos la base de datos de prueba de siempre, etc… Poner todo lo necesario, como para que cualquier miembro del equipo, pueda basarse en eso y reproducir la tarea o mejorarla.
Cuando la verificación es rica en “screenshots”, se produce un interesante efecto: esas mismas pantallas e informaciones de verificación sirven para alimentar la presentación de finalización del sprint.
Hay otra herramienta, físical, visual, que podemos manejar para todo esto, pero no he podido participar aún de un equipo que la haya aceptado y mantenido de forma saludable: un tablero físico, donde se van colocando las tomas de tareas y sus cumplimientos. Creo que puede ser complementaria a la práctica que describo hoy. Ese tema, dará para otro post.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
En la lista de ALT.NET hispano, se planteó una interesante discusión:
[altnet-hispano] Re: ¿Porqué no formar una alianza, un equipo?
Partió de una propuesta de Alberto Arroyo (@BeyondNet en Twitter)
Para los que aún no he tenido la oportunidad de conocer me presento. Mi Nombre es Alberto Arroyo Raygada, soy natural de Perú, profesional
en Tecnologías de la Información y fiel seguidor de las alternativas abiertas de software. Actualmente vengo promoviendo y apoyando algunas comunidades de software como son www.cslanet.org y www.codesol.info. Mi nickname es BeyondNet.
La propuesta:
…siempre he tenido el interes y las ganas de poder desarrollar un producto de software con un esquema de licencia OSI, ¿Porqué OSI?, pues por la posibilidad de variantes que da el software abierto.
Si miramos un poco el mercado, en este momento se han marcado mucho más los diferentes perfiles comerciales de las empresas que han
madurado productos de software abiertos orientados a diferentes especialidades como por ejemplo: OpenBravo, MySQL, Mono Project, Distribuciones Linux, etc, etc. La lista es grande, pero la idea es la misma "PRODUCIR Y GENERAR INGRESOS".
Ese un tema. Yo mencioné que una cosa es hacer un proyecto de código abierto, y otra es hacerlo con la idea de producir ingresos:
a) O hacemos un proyecto de codigo abierto, como otros
b) O hacemos un proyecto de codigo abierto que, desde el vamos, apunte a formar una empresa, movimiento, lo que quieran, que beneficie a los
que participen activamente, en la actividad que sea que aporten.
En el primer caso, podemos tener como ejemplo a NHibernate, excelente proyecto de codigo abierto, vivo, que hace historia, pero en el que cada cual vive como puede.
En el segundo caso, veo como ejemplo a JBoss, que desde la vision de Marc Fleury, sobre un producto de codigo abierto, monto una empresa.
Quería explayarme un poco más, por acá. Pueden leer sobre Marc Fleury en:
http://en.wikipedia.org/wiki/Marc_Fleury
Marc's research interest focused on middleware, and he started the JBoss project in 1999. JBoss Group, LLC was incorporated in 2001 in Atlanta, Georgia. JBoss became a corporation under the name JBoss, Inc. in 2004.
Pueden leer su blog (escrito con su esposa) en:
Maison Fleury
Volviendo al tema. Una cosa es hacer un proyecto de código abierto. Tenemos varios ejemplos, y muchos de nosotros los usamos día a día. Mencionaba como caso paradigmático, el NHibernate. Podría mencionar también Hibernate (curiosamente ambos quedaron con el tiempo, bajo el paraguas de JBoss). A partir de una idea, un grupo reducido de desarrolladores crea una herramienta excelente, usando por miles de desarrolladores. Pero no se producen ingresos directos para esos desarrolladores (y otros colaboradores, no todo es codificar). Y faltan cosas para hacerlo un producto.
Un producto, me imagino, tiene documentación completa, soporte organizado, presentación para un mercado, cursos y difusión, capacitación ya empaquetada, es algo más que un proyecto.
Pero tanto proyecto como producto, no bastan para lo que yo apunto. Un producto no genera ingresos. Lo genera el mercado, un mercado de clientes, que no buscan un producto, buscan soluciones a problemas.
Veo en muchos emprendedores, que se enamoran de la “idea”, pero les falla ya ejecución: no la ponen nunca en marcha, o no logran plasmarla en producto. Luego, se puede caer en otra trampa: enamorarse del producto, y no ver que en realidad, lo que se vende, son soluciones a problemas. Y no logran llegar a identificar el mercado al que apuntan.
Pero Fleury, pienso, tuvo bastante en claro su camino desde el principio. Vió cómo el mercado iba a seguir a Sun (posiblemente, era una apuesta), en sus sugerencias de cómo implementar aplicaciones escalables, multiplataforma, y que en ese mercado iban a subirse empresas grandes. Sun armó la especificación EJB (Enterprise Java Beans), que, en mi opinión, es bastante horrible. Pero eso no importa ahora. Fleury vió que no tenía nada para ofrecer, pero tenía una idea distinta: en vez de producir un producto cerrado, iba a crear un producto de código abierto, el JBoss. Mientras que otras empresas luchaban por vender su servidor de J2EE, a miles de dólares, Fleury puso su marca en el mercado, simplemente dando a bajar al JBoss. Muchos pensaron que (como se dice acá en Argentina) “no le llegaba el agua al tanque”, o “no tenía todos los patitos en línea”, pero el que ríe último, ríe mejor, y Fleury y cía. se posicionaron como líder en un mercado difícil, y hoy es, prácticamente, el rey de la colina.
Pero desde el principio, él montó todo como una empresa. Antes de comenzar a codificarlo, visitó gente con su plan de negocios. No era un proyecto de código abierto más. JBoss, el producto, sirvió como cabeza de playa, como producto bandera, para crear y sostener la empresa. JBoss, la empresa, se posicionó como proveedora de soluciones, capacitación, asesoramiento, y otros productos.
Yo pienso que es hoy la forma de armar una empresa. Ya no está el “filón” en tener un producto cerrado, sino en abrirlo, formar comunidad, y tener claro qué problemas soluciona, y posicionarse en esa colina, como proveedor de soluciones. Si otros también usan el producto de código abierto para hacer sus ingresos, de alguna forma, eso valida nuestra posición en el mercado, y nos da más fuerza y valor.
¿Qué opinan de la propuesta de Arroyo? ¿y de la discusión que se armó? Pueden participar en la lista de correo, si quieren.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Los que manejan Scrum, saben que el trabajo se realiza de a etapas, llamadas Sprint. Cada una es una iteración de duración fija, donde se va completando lo que se llama el Sprint Backlog, la lista de tareas que se decidió encarar en esa etapa.
Una tarea pendiente puede ser tomada por uno o más miembros del equipo, al comienzo del día, en la reunión diaria de Standup:
Tales from the Scrum- la reunión diaria de standup
Pero no hay que olvidar algo: no sólo hay que hacer la tarea, sino también verificarla. Qué significa esto?
Si estamos agregando una nueva funcionalidad al sistema (supongamos que estamos trabajando en un sistema de presupuesto de seguros) por el ejemplo, el cálculo correcto del costo de un seguro para un tipo de camión, tenemos no sólo que completar la tarea, sino, en algún momento del Sprint, verificarla: ver de realizar en el sistema un pedido de presupuesto de ese tipo de camión, y ver que se calcule correctamente el importe del seguro.
En general, la verificación la hace otro miembro del equipo.
Si no se realiza la verificación, suele pasar que al final del sprint, se le entrega al cliente algo que no funciona, y vuelve como defecto.
Esto es importante: NO DEBERIAN ENTREGARSE DEFECTOS. Todo el sprint está pensando para entregar lo que estipulamos en el sprint backlog. Se debería entregar lo que está listo para usar. Por supuesto, podemos poner restricciones, como que el costo se calcula bien para tal tipo de camión, no para todos. Pero para el tipo de camión que especificamos al principio del Sprint, el cálculo debería funcionar bien.
Si algo no está verificado, no debería entregarse al final del Sprint.
La idea es: se entrega algo terminado. Habría más para comentar sobre eso de “trabajo terminado”. Por ahora, es hecho y verificado.
Las pruebas automáticas nos ayudan y soportan en el desarrollo del programa. Pero igual tenemos que verificar que lo que se hizo sea tal cual se esperaba.
Algo que ayuda, es escribir historias de uso al principio del Sprint, tipo: ingreso al sistema, cargo estos datos de este camión en particular, y el sistema me responde con tal importe. Eso sirve para quien va a verificar la tarea, sepa cómo probarla, con qué datos, de qué manera. Puede servir como criterio concreto de aceptación por parte del Product Owner y el cliente, al final del Sprint: si el sistema cumple con la historia de uso, cumple con lo pedido.
Ahora bien: el que hagamos algo y otro miembro del equipo lo verifique, no implica que descuidemos la tarea. Nosotros debemos implementarla y probarla, de tal forma que pase la verificación posterior. No debería volver la tarea a desarrollo porque se encontró problema en la verificación. El que realiza la tarea debería preocuparse de hacerla de tal forma, que esté confiado de pasar la verificación.
Esto es parte de “hacerlo bien, hacerlo una vez”. Si uno realiza una tarea con descuido, y la da por terminada, por terminarla rápido, y luego de verificar, se descubre que tiene defectos, hay que volver a trabajar en ella. Y eso ocupa tiempo del Sprint. No, hay que recordar el viejo refrán “Vísteme despacio que estoy apurado”.
Cuando el equipo va madurando, va haciendo carne todo esto. Es común encontrar, en las primeras iteraciones, saltos en el proceso, como el olvido de una verificación. Pero con el tiempo, se va transformando en un “rito”, una de las cosas que se hacen en el Sprint. Y el equipo aprende que esa actividad no está por que sí, porque vino en un libro o curso de Scrum: ven que actuando así, se ahorran problemas, y van sintiéndose más seguros en lo que van armando.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez