Organizando el Scrum Bolivia Day 2012

Soy parte de la organización de la primera conferencia Scrum Bolivia Day 2012, más información de la conferencia en este link http://scrumbolivia.com/?page_id=2

Después del curso de Certified Scrum Developer

La semana pasada en Cochabamba-Bolivia se llevó a cabo el primer curso de CSD impartido por Kleer, el instructor fue Martin Alaimo y a continuación muestro algunas de las fotografías que tome de los diagramas que más me gustaron.

Este por ejemplo es un diagrama que muestra como se interelaciones los conceptos y prácticas de TDD (Test Driven Delopment) y ATDD (Acceptance Test Driven Delopment):Esta fotografía corresponde al taskboard que creamos con mi equipo:

Y estos son algunos de los impedimentos que encontramos en la retrospectiva con Martin después del primer sprint:

Administración Agil de Proyectos

Resumen

Este artículo pretende atraer la mirada hacia el enfoque ágil de administración de proyectos que se ha venido utilizando con éxito desde hace más de una década en la administración de proyectos de desarrollo de software. Este enfoque se basa en la inspección y la adaptación continua de las tareas, procesos y buenas prácticas de interacción humana. La autogestión y el enfoque hacia tareas con alto valor para el cliente final son también componentes fundamentales de este paradigma.

Introducción
El campo de desarrollo de software es intrínsecamente complejo por los requerimientos cambiantes y poco tangibles, se suma a esto el alto grado de creatividad e innovación necesaria a la hora de construir software. En esencia los requerimientos son cambiantes porque los clientes en general no pueden definir por completo sus necesidades y porque estas van cambiando de acuerdo con las prioridades de la empresa y el rubro donde esta se desenvuelven.

Más aún, en este rubro alternativas como añadir más ingenieros a un proyecto o alargar la jornada laboral no garantizan en ningún caso que un proyecto pueda reencaminarse o siquiera terminarse.
Controlar los cambios a través de un proceso rígido de control de cambios tampoco es una alternativa pues genera excesiva documentación y burocracia. Así por ejemplo empresas con productos en la web no pueden darse el lujo de rechazar cambios o demorarse demasiado en implementarlos pues sus competidores podrían tomar ventaja si responden con mayor dinamismo.

De lo Predictivo a lo Adaptativo

Procesos tradicionales que tratan de estandarizar actividades que en esencia son creativas no funcionaron para este rubro particular. Enfoques como definir a máximo detalle y estandarizar procesos no tuvieron éxito porque simplemente cada proyecto es diferente en términos de tecnología, complejidad, interrelación y requerimientos. La creatividad que fluye en un equipo con ciertos individuos y en cierto proyecto particular es difícilmente medida, estudiada y replicada. Por el contrario, se buscaron alternativas como la “agilidad” que permite pasar de un enfoque predictivo a un enfoque adaptativo.

Dentro de este nuevo paradigma se reemplaza el enfoque que plantea la división del ciclo de vida del proyecto en fases bien marcadas y con actividades preestablecidas, por iteraciones cortas orientadas a tener productos tangibles al final de las mismas. Estas iteraciones cortas son precisamente micro-ciclos de vida que se desarrollan de principio a fin y que apuntan a construir un producto en incrementos finitos.

Al final de cada incremento finito se tiene una demostración para clientes reales de la funcionalidad implementada. Esta demostración es la que provee las entradas para adaptar el producto y encaminar mejor la siguiente iteración. Por su parte, el equipo de trabajo dentro de la iteración se auto-inspecciona constantemente y va adaptando sus prácticas y procesos para llegar a producir un producto con valor y calidad al final de cada iteración.

Enfoque en el Valor, no en las Tareas
Mucho del éxito del enfoque ágil de administración de proyectos proviene de minimizar la cantidad de trabajo innecesario que conduce a completar tareas que no contribuyen o contribuyen muy poco a agregarle valor al producto final. El valor es considerado no desde la perspectiva técnica de quienes construyen el producto sino desde la perspectiva de negocio de los clientes finales.

Priorizar tareas es clave dentro de este enfoque, la priorización se realiza tanto al inicio del proyecto como al final de da iteración. De hecho el proceso de control de cambios permite que nuevos requerimientos sean ingresados aún tarde en el desarrollo del proyecto pero estos no serán atendidos hasta que no se termine la iteración actual y hasta que hayan sido adecuadamente priorizados.

La forma en la cual se evita el scope creep consiste no en rechazar requerimientos sino más bien en aceptarlos pero manteniendo en todo momento una lista priorizada de requerimientos con alto valor para el cliente y que pueden ser implementados considerando la velocidad del equipo.

La documentación que acompaña a un proyecto es generada y mantenida siempre y cuando esta aporte valor al cliente final. Esta práctica permite liberar tiempo y recursos tradicionalmente destinados a estas tareas y reasignarlos a tareas que aporten mayor valor para el cliente.

El valor para el cliente es aparentemente difícil de medir en un producto intangible como el software, pero en la práctica las técnicas de análisis de negocios permiten cuantificar, medir y extrapolar no solo el valor de una característica para un cliente sino para una comunidad de clientes finales.

Los Principios Agiles
La agilidad se funda en los principios básicos planteados por el “Manifiesto Ágil” a los cuales se suman modelos de administración ágil de proyectos y marcos de trabajo para equipos multidisciplinarios.

Los principios del citado manifiesto se basan en pilares como el cambio de énfasis de los procesos y herramientas hacia los individuos y la interacción entre ellos. Esto viene de la mano de conceptos tales como empoderamiento del equipo y autogestión.

Se incorpora también el pragmatismo que apunta a tener software funcionando y de utilidad para el cliente final en lugar de documentos de diseño extensivos.

Un tercer pilar habla de la incorporación de los clientes en el proceso de construcción del producto, incorporación que es factible ya que al final de cada iteración el equipo puede tener un producto tangible (más no terminado) que puede mostrar para recolectar mejores requerimientos y retroalimentación. Este punto es de vital importancia ya que durante décadas se trató sin éxito de relevar requerimientos con diagramas y otros artefactos cuando en realidad lo más efectivo es acercar al cliente al producto que este espera tener como resultado de su inversión en el proyecto.

El cuarto y último pilar del Manifiesto Ágil tiene que ver con la adaptabilidad, es decir con la capacidad intelectual, organizativa, motivacional y creativa que debe tener un equipo para poder responder a los cambios inherentes al proyecto y reajustar su horizonte sin perder de vista que el objetivo final de sacar un producto al mercado con valor para los clientes.

Conclusiones

Los principios de la agilidad y la administración ágil pueden ser extensibles a otros campos de la ingeniería. Por ejemplo empresas como 3M o Nokia donde la innovación constante es fomentada, vienen aplicando estos principios desde hace bastante tiempo y con resultados por demás exitosos. Inclusive rubros en los cuales el trabajo repetitivo requiera poca invención pueden beneficiarse del enfoque de mejora continua (kaizen) que traen consigo las iteraciones.

Referencias
• Agile Project Management: Creating Innovative Products, Jim Highsmith, 2004
• Agile Project Management with Scrum, Ken Schwaber, 2004
• The Software Project Manager's Bridge to Agility, Michele Sliger and Stacia Broderick, 2008
• El Manifesto Ágil http://www.agilemanifesto.org/iso/es/
• International Institute of Business Analysis http://www.iiba.org/imis15/IIBA/Home/IIBA_Website/home.aspx
• Scrum Alliance http://www.scrumalliance.org

Las transaparencias que use para esta presentacion pueden encontrarse en este link http://percella.com/administracion-agil-de-proyecto/

Daily Scrum Meeting en Sensillo

¿Qué es el Daily Scrum Meeting?

Es un meeting diario de todos los miembros activos del equipo.

¿Quienes participan?

Solamente miembros del equipo. Para que la reunión sea productiva cada miembro del equipo debe participar activamente. Managers y otras personas pueden participar solamente como oyentes.

¿Cuál es el objetivo de la reunión?

El objetivo es tener un punto de inspección/comunicación/coordinación entre los miembros del equipo. El objetivo no es reportarse ante un supervisor, el objetivo es que cada miembro del equipo habla brevemente de las tareas que realizó, realiza y los problemas que encontró.

¿Cuál es el horario y duración de la reunión?

La reunión puede programarse a cualquier hora del día pero las mañanas es más recomendable. La duración de esta reunión es de máximo 15 minutos. Si hay necesidad de seguir hablando se debe programar una reunión separada solo con los miembros del equipo interesados en el tema.

¿Alguien preside o dirige la reunión? ¿Un team leader por ejemplo?

Esta reunión es participativa y no de reporte, por tanto todos los miembros del equipo deben participar dando sus opiniones. Si puede ser de ayuda que alguien ayude a mantener el orden de quien habla cuando o que verifique que la duración no exceda los 15 minutos.

¿Cómo ayudan los managers en este meeting?

De dos formas: primero, asegurándose que el equipo tenga el lugar y espacio para reunirse y segundo, ayudando a resolver las dudas, bloqueos y/o problemas que fueron expuestos en la reunión.

¿Hay algún formato a seguir para esta reunión?

La bibliografía de referencia recomienda hacer tres preguntas: ¿Qué hiciste ayer? ¿Qué harás hoy? ¿Hay algo que bloque tu trabajo? Sin embargo en la práctica cada equipo es libre de escoger las preguntas. Lo importante es que cada miembro del equipo pueda en un corto tiempo hablar de su trabajo, el estado del mismo y su impacto en el trabajo del resto de los miembros del equipo.

Proyecto casa de los Simpsons

Los estudiantes de la Maestría de Ing. de Software de la Universidad Gabriel René Moreno trabajaron el fin de semana pasado en un ejercicio grupal que consistia en realizar una réplica de la casa de los Simpsons, esta foto ejemplifica los resultados alcanzados:



Fotografias adicionales y una presentación preparada por este grupo pueden encontrarse en los siguientes links:

https://picasaweb.google.com/107712459507918881105/SETheSimpsonSHuse
http://www.slideshare.net/timoteoPonce/model-making-simpsons-house

Y este es un link a las fotos que otro de los grupos amablemente compartio en Picasa:

https://picasaweb.google.com/113911593465885757955/SCRUM?locked=true&feat=email





Y esta es su presentacion en SlideShare http://www.slideshare.net/mianmilo/casa-de-los-simpson-10027129

Luis Antonio escribió en su blog acerca de este proyecto http://ryuchananything.blogspot.com/2011/11/casa-de-los-simpson-framework-scrum.html

Estas fotografias corresponde a un tercer grupo de trabajo:





Y cuya presentación se encuentra en el siguiente link http://www.slideshare.net/ebbicita/proyecto-casa-de-los-simpsons



Este video corresponde a un cuarto grupo (el equipo de Diego porque siempre hay un Diego en cada equipo :))


https://docs.google.com/leaf?id=0B0yvfg6mi1NKMmNkMTU4MmYtNDA0NC00YjJkLWIyNDktYzY3MGY1YTljMzY1&hl=en_US&pli=1


Del grupo de Diego también están estas presentaciones http://www.slideshare.net/diegozalles/proyecto-maestria


Y finalmente este es el link a la presentación del grupo de Roberto Carlos (no el cantante sino el ingeniero :))


http://www.slideshare.net/rhunoja/proyecto-casa-de-los-simpson

Definición de Exito para un Producto

James Shore hizo una presentación excelente en Agiles 2011 en la cual puntualizo su visión de éxito para un producto software, en resumen James puntualizaba que un producto tiene exito cuando tres variables convergen: el negocio, la tecnología y la satisfacción pesonal.

El negocio se refiere concretamente a que el producto pueda sea rentable en un horizonte razonable de tiempo, es decir construir algo para un mercado que lo consuma y que además sea sostenible. Esta variable implica dinero que se invierte en un producto y que debe necesariamente retornar de alguna manera para justificar la inversion.

La segunda variable tiene que ver con que no basta con que un producto se venda bien, tiene que ser tecnologicamente sólido como para permitirle evolucionar rapidamente o adaptarse a nuevos requerimientos. Aqui la arquitectura flexible y las buenas prácticas de ingeniería (XP) son claves asi como también el fuerte compromiso del equipo con la calidad.

La tercera variable es la satisfación de la gente que trabaja haciendo el producto, esta satisfacción debe traducirse en éxito personal (no solo económico). La idea es simple, individuos satisfechos y motivados se consideran así mismos exitosos y estan dispuestos a trabajar en una versión aún mejorada del producto.

Algo que James puntualizó también es que las tres variables son de igual importancia y esa creo es la clave del asunto. No tener o tener muy poco de cualquiera de estas tres dimensiones comprometera el producto a corto o mediano plazo.

Bolivianos en Agiles 2011

Once compatriotas asistimos a Agiles 2011 en Buenos Aires, fue una asistencia record que esperemos vaya en ascenso para la siguiente version del evento.

En la foto de izquiera a derecha Gabriela Espinoza, Juan Banda, Victor Hugo Rodriguez, Patricia Calderon, Israel Antezana, Marco Alba Lopez, Pablo Azero y Gonzalo Solano. No aparecieron para la foto Steven Rojas, Juan Pablo Soliz y Hugo Siles.

Reflexiones despues de rendir el examen PMI-ACP (Agile Certified Practitioner)

Hoy por la mañana di el examen PMI-ACP y con la memoria aun fresca me animo a compartir algunas cosas que me parecieron bastante interesantes de este examen:

1. Las preguntas del examen están bien formuladas y bien redactadas, no dan mucho lugar a malas interpretaciones y son bastante objetivas.
2. Muchas de las preguntas están relacionadas con Scrum, con los roles, ceremonias y artefactos.
3. Sin embargo hay otras preguntas que hablan de aspectos más generales de Agile y del manifiesto agil.
4. Encontré muy pocas preguntas relacionadas a Lean y Kanban y solo unas cuantas que hablaban de Agile Earned Value.
5. Retrospectives es otro tópico sobre el cual tampoco encontré muchas preguntas pero las pocas que habían estaban bien relacionadas a la bibliografía recomendada por el PMI.
6. XP si estuvo presente y fuerte, varias preguntas respecto a TDD, integración continua, pair programing, collective code ownership, etc.
7. Los aspectos suaves de coaching los vi en muy pocas preguntas, lo cual es una lástima porque el libro Agile Coaching de Lyssa Atkins es un referente fundamental.

Me animo también a priorizar un poco la lista de libros de bibliografía que recomienda el PMI, desde luego esta es una opinión bien personal mía:

1. The Art of Agile Development, James Shore
2. Agile Project Management with Scrum, Ken Schwaber
3. The Software Project Manager's Bridge to Agility, Michele Sliger
4. User Stories Applied: For Agile Software Development, Mike Cohn
5. Agile Estimating and Planning, Mike Cohn
6. Coaching Agile Teams, Lyssa Adkins
7. Becoming Agile:...in an imperfect world, Greg Smith
8. Agile Retrospectives: Making Good Teams Great, Esther Derby
9. Agile Project Management: Creating Innovative Products, Jim Highsmith
10. Agile Software Development: The Cooperative Game, Alistair Cockburn
11. Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway

Finalmente un recurso que me resulto muy valioso a la hora de prepararse fueron los exámenes de prueba que AgileExam tiene en su sitio www.agileexams.com

De como introducir Scrum creando un grass root movement

La introduccion de Scrum dentro de cualquier organizacion tiene varias compliaciones iniciales y de mantenimiento que en muchas oportunidad hacen que este proceso se trunque o no se lleve a buen termino. Uno de los problemas iniciales proviene del desconocimiento que todavia existe en la comunidad acerca de lo que es agil en general. Si esta corriente de pensamiento todavia no es conocida menos aun lo son los potenciales beneficios que pueda traer.

Un primer paso es el proceso de acercamiento en que la gente dentro de una empresa comienza a enterarse de agil y en particular de Scrum. En esta etapa generalmente quien hace el rol de evangelizador menciona que Scrum aportara grandes beneficios y satisfaccion al cliente. En este momento es cuando los genrente escuchan el discurso pro Scrum, sacan la calculadora y dicen wow, "esto es una maravilla, me voy a ahorrar un monton de dinero, todos a hacer Srum ya!"

Si uno tiene la suerte (en realidad la mala suerte) de que esto pase su empresa el siguiente problema al que se enfrentara es algo a lo que yo llamo "Scrum por mandato". Scrum es en esencia una forma de pensar y de trabajar en equipo, nada de lo cual puede ser dictado, medido y exigido en su cumplimiento. Generalmente las cosas que vienen por imposicion limitan el pensamiento creativo y eventualmente se desarticulan en cuanto la presion de quien las impuso es aliviada.


Hace falta algo que se pegue mas al "suelo" y no flote en las esferas de la gerencia. Algo que venga por conocimiento y que sea colectivo y propio de la gente que efectivamente contruye a un proyecto y que ve en Scrum una oportunidad para hacer su trabajo mas ameno y productivo. Encontre una imagen (logo de una banda rockera) que ilustra el sentido de este post.







Como se ve en la imagen el pasto "grass" va creciendo pero no se desprende del suelo con el viento, puede incluso ser cortado y parcialmente arrancado pero seguir ahi y volvera a crecer. Similarmente Scrum puede ser cambiado, criticado, sacudido, podado pero eventualmente continua.

Para lo anterior es esencial tener raices "roots" que hagan que la gente cree firmemente en algo y este despuesta a seguir creyendo en que de alguna forma va hacer que funcione dentro de su entorno. Este grupo de creyentes conversos o no conversos son la clave del "grass root movement".

Cual es mi consejo final? Si Usted es un gerente, no importe creyentes, formelos y deles libertad de experimentar con Scrum, suena loco pero con un poco de suerte y honestidad los beneficios seran grandes.

Si esta del otro lado de la cerca (ingenieros y pueblo en general) piense en que hermoso seria ser parte de un movimiento que creo la diferencia en su entorno y en su profesion.

Agile Testing Cuadrants

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

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

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

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

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

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

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

Curso de Certified Scrum Master en Santa Cruz de la Sierra

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

Rigidez en Scrum?

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

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

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

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

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

LeanEssays: How Cadence Predicts Process

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

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