sábado, 26 de diciembre de 2009

Calendario de Sprint

Uno de los mayores problemas que se pueden dar en una implantación de Scrum es el empezar con la idea preconcebida de que es una metodología que no requiere "mucho esfuerzo". Esto le sucede a mucha gente que ha oído hablar de Scrum o metodologías ágiles en general y que únicamente se han quedado con la idea de que Scrum es "no documentar" o barbaridades similares. Pero la realidad es que implantar Scrum en una empresa o departamento requiere de mucho esfuerzo y ganas por parte de todos los implicados. En este post voy a tratar de explicar una manera de enfocar Scrum que creo que puede ser muy útil, sobretodo al inicio de una implantación. Para ello lo único que se necesita es crear un Calendario de Sprint.

Aunque parezca algo trivial, hacer un calendario nos puede ayudar sobretodo en las primeras etapas de la implementación de la metodología, cuando aún no están claras las diferentes prácticas y artefactos que intervienen en Scrum. El calendario de Sprint que os propongo está basado mas o menos en cómo funcionamos en nuestra empresa (Sprints de dos semanas y de miércoles a miércoles) pero obviamente se puede adaptar a lo que mas convenga a cada equipo y/o empresa.

El calendario propuesto es el siguiente:




Ahora vamos a detallar que significa cada uno de los diferentes puntos del calendario:

Project Review

Descripción: Revisión del estado de los proyectos. Comunicación de cambios de requisitos, modificaciones, problemas, riesgos,impedimentos, etc...
Duración:
1h
Asistentes:
Responsables de proyectos y personas implicadas (clientes, gestores, gerentes, etc.)
Documentación:
Acta de reunión documentando todos los cambios y las decisiones tomadas.

Project Planning

Descripción: Adición, eliminación o división de historias de usuario de cada proyecto (en base a lo detectado en la reunión de Project Review). Priorización y estimación de las nuevas historias de usuario y preselección de aquellas a desarrollar en el nuevo Sprint.

Duración: 1h

Asistentes: Responsables de proyectos y miembros del equipo de desarrollo (no tienen porque ser todos)

Documentación: ProductBacklog y documentos de diseño si son necesarios.


Sprint Planning

Descripción: Decidir los puntos a hacer durante el Sprint (basado en los días laborables, recursos disponibles y proyectos en curso). División en tareas de las historias escogidas y estimación (en horas ideales o puntos de historia). Escoger nuevas historias si caben en el Sprint. Preparación del Task Board

Duración: 2h

Asistentes: Equipo de desarrollo

Documentación: SprintBacklog y toda la información adicional necesaria(decisiones de diseño, dudas, comentarios...).


Daily Scrum

Descripción: Sincronización de las tareas diarias hechas y actualización del Task Board.

Duración: 10 mins.

Asistentes: Equipo de desarrollo.

Documentación: Actualización del estado del Sprint Backlog.


Sprint Review

Descripción: Demostración funcional de las historias desarrolladas durante el Sprint.

Duración: 1h

Asistentes: Equipo de desarrollo, cualquier persona interesada en el proyecto

Documentación: Acta de la reunión con el feedback proporcionado, y con posibles errores y bugs encontrados durante la demo (Esta información se utilizará en la siguiente reunión de Project Review)


Sprint Retrospective

Descripción: Valoración del sprint (objetivos, gestión, resolución de impedimentos, etc.)

Duración: 1h

Asistentes: Equipo de desarrollo

Documentación: Acta de la reunión con las conclusiones y los objetivos para el siguiente sprint.


Lab

Descripción: Tiempo dedicado a investigación/pruebas sobre temas interesantes para cada persona

Duración: 1h

Asistentes: Equipo de desarrollo


Cómo se puede ver el calendario es simplemente una guía o base para seguir durante los Sprints, y no se tienen en cuenta todos los aspectos que pueden ir apareciendo durante el mismo (reuniones con clientes, sesiones de diseño, etc...), pero a pesar de todo creo que puede ser una buena práctica para aquellos equipos u organizaciones que están empezando con la implantación de Scrum.



jueves, 5 de noviembre de 2009

Scrum y la motivación

Uno de los handicaps mas importantes de cualquier proyecto de software suele ser la motivación de los integrantes del equipo. Es muy dificil llevar a buen puerto un proyecto si el equipo no está lo suficientemente motivado e identificado con el mismo, por eso mismo creo que uno de los objetivos y de las prioridades de cualquier jefe o responsable de proyecto debería ser siempre intentar mantener un alto grado de motivación y compromiso por parte del equipo.
Sin entrar a juzgar los diferentes tipos de "técnicas" o estrategias de motivación que suelen usar en la mayoria de proyectos de software los gerentes, gestores o responsables de proyecto que corren por el mundo, voy a intentar mostrar cómo Scrum puede ayudarnos un poco a la hora de mejorar la motivación y el compromiso buscados. Para ello vamos a repasar algunos de los conceptos y de puntos que forman o que persigue la metodología y ver cómo nos pueden ayudar:


  • Reunión planificación de proyecto/sprint: Estas reuniones aumentan la visibilidad del equipo respecto a los diferentes proyectos en los que tienen que participar,y además, al participar plenamente en la toma de decisiones (a nivel de diseño, arquitectura, desarrollo...) los miembros del equipo suelen considerar el proyecto cómo algo propio, aumentado de esta manera la motivación, y probablemente con ello la velocidad y calidad de los desarrollos.
  • Seguimiento diario: Con las reuniones de seguimiento diario se consigue que las personas mantengan un grado de concentración mayor, y una responsabilidad para con los otros miembros del equipo (al tener que responder de los avances delante de ellos) con lo que de nuevo aumenta la motivación de cara al proyecto.
  • Demostraciones: Las demostraciones al final de la iteración consiguen que el equipo observe su trabajo, lo muestre y vea las reacciones de otra gente de la compañia. Es cómo un reconocimiento (siempre que la demo vaya bien ;) ) al trabajo hecho, cosa que ayuda de nuevo a que el equipo siga motivado para la siguiente iteración.
  • Retrospectivas: El hacer que el equipo pueda opinar sobre como ha ido la iteración fomenta de nuevo el sentimiento de equipo y de propiedad de los proyectos, que cómo pasa en los puntos anteriores ayudan a que las personas sigan motivadas.

Con los puntos vistos anteriormente, vemos que aplicando Scrum , de manera implicita, se fomenta la motivación del equipo, sin necesidad de técnicas de presión, amenazas, etc. a las que tanto se recurre habitualmente.

Un saludo!

viernes, 21 de agosto de 2009

Primeros pasos debugando de verdad

El otro dia nos encontramos con un problema en el trabajo. Teniamos una aplicación que cascaba aleatoriamente y no sabíamos por que. Teníamos que encontrar el problema y solucionarlo de manera urgente o algún cliente estaria muy pero que muy enfadado.

Como profanos en la materia empezamos nuestro estudio con nuestro amigo el Administrador de Tareas de windows. Un vistazo a la memória del proceso y al máximo de memória nos hacía pensar que alguna acción de nuestra aplicación hacia que la memória tubiera picos que después se recuperaban. En uno de estos picos, la aplicación acababa diciendo basta y empezaba a funcionar muy mal, llegando a cerrarse. Como primer paso no estaba mal, pero no teniamos ni idea de cómo solucionarlo.

Después de un rato navegando por internet buscando información sobre profilers nos decidimos a probar el windbg. Algunos artículos de los grandes Rodrigo Corral, Pablo Doval y David Salgado nos ayudaron a hacer nuestros primeros pinitos con la herramienta, pero todavía no eramos lo suficientemente hombres cómo para utilizarla correctamente, así que buscamos alguna otra manera de hacerlo.

Llegamos a este artículo de Rodrigo donde se comenta cómo determinar que tipo de problema de memoria tiene una aplicación. Pusimos los tres contadores en la máquina de preproducción ( bytes privados del proceso, bytes en todos los montones y colecciones de generación 2 ) y lo que parecía indicar el gráfico resultate ( ver imágen ) es que no teniamos una fuga de memoria ( o por lo menos no era nuestro mayor problema ) sinó que teniamos un incremento escandaloso de memoria manejada. Esto nos llevó directos a la segunda parte del artículo de Rodrigo, donde se habla de la herramienta CLRProfiler. Con esta herramienta pudimos ver que función era la que creaba el problema.



Lo que hacía la función era cargar un archivo en memoria para calcularle un MD5. Cómo esta operación se podia realizar a la vez en unos 50 ficheros que podian llegar a los 5MB, el incremento de memoria que tenia el sistema era preocupante. Modificamos esta función para no cargar todo el archivo y hacerla más liviana y el problema se vió reducido a la nada.

Esto es sólo el principio de lo que esperamos sea un aprendizaje de todas estas herramientas y de las entrañas del CLR. Intentaremos ir posteando nuestras experiéncias y las cosas que vayamos aprendiendo.

Saludos!

lunes, 11 de mayo de 2009

El tablón como herramienta de gestión

Uno de las prácticas de más importancia cuando se habla de Scrum son las reuniones diarias delante del tablón. A pesar de ello son pocos los equipos que utilizan un tablón cómo herramienta de gestión (al menos que yo conozca), o si lo utilizan normalmente no se le extrae todo el provecho posible ¿Que ventajas puede aportar el utilizar un tablón donde se registran las tareas, su estado, el trabajo que nos queda...? ¿No es posible realizar esto mismo con una herramienta informática evitando así perder un tiempo valiosísimo cada día delante del tablón?

Desde mi punto de vista, y basándome en mi (todavía poca) experiencia, la utilización correcta del tablón de Scrum en las reuniones diarias es una de las prácticas indispensables de la metodología, y aunque cada organización que implante Scrum puede y debe adaptarla a sus necesidades, estas reuniones no deberían faltar, ya que muchas de las ventajas que aporta la metodología se consigue a través de esta práctica (comunicación, colaboración...)

Obviamente es básica la utilización de alguna herramienta de software adicional (por ejemplo Hojas Excel, Jira, Trac, Team Foundation Server o cualquier otra que se adecue a nuestras necesidades) ya sea para tener trazabilidad e información del estado de las diferentes tareas de un proyecto, por temas legales (auditorías, certificados de calidad, ...) o por cualquier otra necesidad, pero combinándolo con la gestión día a día delante del tablón es cuando vamos a conseguir explotar mucho mas las ventajas de Scrum (algunas explícitas otras más implícitas):

-Sensación real y inmediata de progreso (o de no progreso)
-Visibilidad a terceros del estado del proyecto
-Mayor sensación de equipo
-Mayor motivación entre los miembros del equipo
-Identificación con los proyectos y responsabilidad para con ellos

Sin la utilización de un tablón los programadores y otros componentes del equipo no van a tener una visión global y fácilmente accesible del avance del proyecto, ni tampoco otros roles interesados en el estado (comerciales, directivos, analistas de negocio...), lo que puede generar en desconfianzas, desmotivaciones, etc...

Si por el contrario mantenemos el tablón actualizado y bien visible vamos a conseguir que, además de las ventajas listadas antes , los roles interesados en el avance del proyecto conozcan la velocidad y la capacidad de generar software de cada equipo, lo que debería desembocar en un mayor entendimiento entre los diferentes departamentos de la organización implicados o interesados en el desarrollo de una determinada pieza de software evitando en la medida de lo posible las interferencias en medio de iteraciones, etc.

¿Que opináis vosotros sobre la gestión con el tablón? ¿Que ventajas o inconvenientes encontráis?

jueves, 26 de marzo de 2009

Programando con estilo

Antecedentes

Tradicionalmente el desarrollo de software ha sido una actividad individual. Muchos proyectos se llevaban a cabo con la participación de un único programador, o dos a lo sumo, que se encargaban de todas y cada una de las fases del proyecto. A medida que las necesidades de los usuarios han ido aumentado y la tecnología avanzando, el ámbito de los proyectos ha crecido, y con ello la necesidad de añadir más participantes (no sólo programadores sino también otros roles) al proceso de desarrollo de software. Este cambio, el paso de trabajar individualmente a trabajar en equipo, requiere un esfuerzo por parte de las personas involucradas, pero es especialmente importante el impacto que tiene en los programadores (se pasa de un programador que controla todas y cada una de las partes del código a un mismo código que puede ser modificado por varios individuos a la vez) Para solucionar este problema se empezaron a utilizar herramientas cómo el control de versiones, pero no basta con esto. Problemas cómo la poca documentación en el código, la poca estructuración, nomenclaturas extrañas... dificultan la legibilidad del código cuando un programador tiene que modificar código realizado por otro (o incluso cuando se tiene que tocar código realizado por uno mismo tiempo atrás) Esto acaba repercutiendo en una menor productividad de los desarrolladores hace los códigos poco reusables,escalables, etc.
Para solucionar esto se necesita organización y disciplina por parte de los implicados y es aquí donde puede entrar en juego la Guía de estilo.


¿Qué es?

Una guía de estilo no es mas que la definición de una serie de pautas que han de seguir los programadores cuando estén creando o modificando código. Una guia de estilo hace incidencia en cómo debe presentarse el código, o sea en la forma y no en el fondo del mismo. Pero cómo ahora veremos, esto tiene un importante impacto en cómo va a funcionar el mismo.


Las pautas que puede dictar una guía de estilo son muchas, desde cómo debe indentarse el código, a cómo se deben nombrar las variables, funciones, métodos, clases u objetos que aparecen en el código. También son muy importantes los comentarios realizados en él, y más si estamos trabajando en el ámbito de una metodología ágil donde el código se considera parte esencial de la documentación del proyecto.

¿Que nos aporta?

A priori se puede pensar que aplicar una guia de estilo al código de nuestros proyectos es simplemente una herramienta de “burocratización” que lo único que hará será más lenta y tediosa la tarea de programar (muchos programadores son reacios a ello, sobretodo los que estan acostumbrados a trabajar de manera individual), pero la realidad es bien distinta. La principal aportación de “estandarizar” el código es el incremento de la legibilidad por parte de todos los desarrolladores, haciendo que disminuya el tiempo que una persona necesita para entender el código, ganando tiempo al codificar (al asimilar las reglas de nombrado de clases, variables, etc, se pierde menos tiempo), facilitando la refactorización, lo que puede llevar a incrementar la escalabilidad del código, la reusabilidad, la modularidad, la facilidad para la generación de testos unitarios,etc.


Toda esta serie de mejoras que se pueden conseguir acaban impactando en dos factores clave para cualquier proyecto de software:
● La calidad del código
● La productividad de los programadores


Ejemplos

Algunos ejemplos de Guias de Estilo que podems encontrar en Internet pueden ser los siguientes:

Guia de estilo para el diseño de aplicaciones .NET - http://msdn.microsoft.com/es-es/library/czefa0ke(VS.71).aspx
Guía de estilo Philips Medical Systems(C#) -http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf
Guía de estilo programación en Java - http://java.sun.com/docs/codeconv/
Guía de estilo Mono: http://www.mono-project.com/Coding_Guidelines
Guía de estilo para el nucleo de Linux: http://lxr.linux.no/linux/Documentation/CodingStyle


Para empezar no se debe intentar implantar una guia de las dimensiones y el alcanze de las aquí mostradas. Es mucho mejor empezar con pocas reglas y irla adaptando y ampliando a medida que sea posible y/o necesario.

Conclusiones

Cómo se puede ver una guia de estilo es una excelente manera de “estandarizar” el código de los proyectos de desarrollo de software, estandarización que puede impactar muy positivamente en la productividad y la calidad de los desarrollos siempre y cuando realmente se aplique a la hora de las implementaciones.
La poca predisposición por parte de muchos desarrolladores a que “les digan” cómo deben hacer su código, y la dificultad para realizar un control de manera eficiente (puede ser peor el remedio que la enfermedad) hacen que la implantación de una guia de estilo de manera que tenga un impacto real sea dificil. Si por el contrario los desarrolladores ponen de su parte y se puede llevar a cabo un control que imponga burocracia 0 (hay herramientas que permiten este control de manera sencilla) para hacer que el código cumpla con la guía los beneficios que aportará al proyecto serán muchos e importantes
.

domingo, 15 de marzo de 2009

Agile Open Buenos Aires


El pasado 6 y 7 de Marzo tuve el placer de asistir al Agile Open Buenos Aires. Este evento, organizado por la comunidad latinoamericana de metodologías ágiles, se desarrolló en formato Open Space y fue sumamente interesante.

El evento se dividió en dos sesiones. El primer día se dedicó a planear los temas de las charlas y el horario de las mismas y el segundo se dedicó a las charlas en sí.

Lo primero que me gustaría destacar es la afluencia de público a estas sesiones. Debíamos ser unas cien personas hablando de metodologías ágiles! Sinceramente, a día de hoy no me imagino un evento de esta magnitud aquí en España. Espero que muy pronto, con el impulso que le estamos dando desde la comunidad española, esto sea posible.

Así pues nos encontramos cien personas el viernes por la tarde para hablar sobre metodologías ágiles. Nuestro facilitador fue Alan Cyment, ayudado en todo momento de su inseparable campana.

Lo primero que hicimos fue proponer el tema de las charlas. Cada persona que quería que al día siguiente se hablara sobre algún tema, se levantaba, se ponía en el centro de la sala y exponía brevemente el tema. A mi, un poco acongojado por el nivelazo de la gente, me costó un poco decidirme, pero al final decidí alzarme y proponer la deuda tecnológica como tema a debatir. Es importante recalcar que la persona que propone la charla no tiene que ser un experto en el tema, simplemente tiene que tener ganas de debatir con otras personas sobre el mismo. Es más, hubo gente que propuso temas sobre los que no tenía ninguna idea ni experiencia y que querían hablar de ellos precisamente por esto, para empezar a conocerlos.

Una vez hubimos propuesto todos los temas que consideramos interesantes empezamos con las votaciones. Cada uno de nosotros tenia cinco votos a repartir entre las propuestas que quisiera, pudiendo repetir votos si lo consideraba necesario. Mi propuesta tubo unos muy honrosos cinco votos :D

Después de votar armamos la grilla ( como decían por Argentina ), es decir, establecimos el horario de cada una de las charlas. Es importante recalcar que todo esto lo hicimos los participantes, en ningún momento Alan o cualquier otro miembro de la organización participó activamente en esta organización. Así pues el resultado fue el que el público consideró más oportuno, tanto en temas a tratar, como en horarios. Se puede ser más ágil?

Cómo podéis ver mi charla quedó emplazada para las 9 de la mañana del día siguiente.

Y al día siguiente, después de un buen desayuno, empezaron las charlas. La charla empezaba con una breve intervención de la persona que la había propuesto explicando las razones por las cuales lo había hecho. Y después empezaba un diálogo entre todos los asistentes donde cada uno daba su punto de vista, explicaba su experiencia, donde estaba fallando, donde lo hacía bien, etc. Aquí os pongo un breve resumen de las charlas a las que yo fui.

Deuda Tecnológica

En esta charla discutimos por lo que entendíamos por deuda tecnológica. Llegamos a la conclusión que deuda tecnológica eran aquella deuda que se contrae cuando se decide hacer las cosas rápido para, por ejemplo, llegar a una entrega y que no cumplen con los estándares de calidad de nuestra organización, siendo susceptibles de impedir el futuro desarrollo de nuestro software. Ante esto se llegó a la conclusión de atacarla por distintos frentes:
  • Intentar evitarla.
  • Reportar al cliente cuando se contrae la deuda para que esté informado que algún día se tendrá que arreglar el estropicio.
  • Se hizo incapié en que ser ágil es un ejercicio de honestidad.
  • Capacitar al equipo para minimizar la deuda que se contrae por culpa de malas implementaciones.
  • Mostrar al cliente el valor de no tener deuda técnica.
Cómo evangelizar a mi equipo

Esta charla fue propuesta por Nico para tratar el tema de aquellos miembros del equipo que no quieren seguir algún paso de la metodología porque no lo consideran oportuno. Aquí cada uno explicó sus batallitas sobre el tema y propuso algunas soluciones, o acciones que quizá pudieran servir. Aquí van algunas:
  • Que el Scrum Master haga aquello que estos miembros no quieren hacer para que se den cuenta que es importante.
  • Cuando se detecta alguna barbaridad en el código, enviar un screenshot a todo el equipo.
  • Rotar los roles para que la gente vea que cuando no hace una cosa está molestando a un compañero.
  • Implementar un sistema de premios para cuando el equipo trabaja correctamente.
Trabajo ágil en entornos no ágiles

En esta charla se habló de cómo trabajar de una manera ágil en empresas que no lo son, ya sea porque tienen una forma caótica de trabajar o porque tienen una forma demasiado rígida de hacerlo. Ante esta dificultad se propusieron diferentes soluciones:
  • Internamente trabajar de forma ágil para cumplir los requerimientos no ágiles.
  • Adaptar el rol de Product Owner para que sea una especie de proxy entre la parte no ágil de la empresa y nuestro grupo de desarrollo.
  • Hablar con la gente no ágil con vocabulario no ágil ( fases, hitos, reunión de avance semanal, etc ).
Product Backlog

En esta charla hablamos de la creación y mantenimiento del Product Backlog. Aquí cada uno explicó cómo lo hacia él y qué problemas le surgían. Había desde la gente que hacía una mezcla de Scrum con Lean o con Kanban, a la que no mantenía un burndown chart ni estimaba las tareas, etc. Esta charla fue interesante porque tubo la participación de Xavier Quesada que aprovechó la ocasión para introducir temas de otra charla sobre visual management que al final no pudo dar.

Scrum distribuido

Y para finalizar estuvo esta charla, en que la gente que tenia experiencia implantando Scrum en grupos distribuidos nos contó sus experiencias. Aquí la tecnología tiene un papel importante a la hora de guardar y mostrar la información del avance del proyecto. Desde softwares comerciales, a hojas de excel compartidas, videoconferencias, llamadas telefónicas a altas horas de la madrugada, etc.

En definitiva fue una experiencia muy interesante. Cómo se comentó en la retrospectiva del evento, si alguna mente privilegiada del agilismo se hubiera puesto a pensar temas para una conferencia, seguramente no hubiera llegado al nivel que se llegó en este evento.

Una vez más, agradecer a la comunidad argentina el buen trato recibido y aprovecho para mandar un saludo a todos ellos. Un placer!

martes, 10 de marzo de 2009

Definiendo historias de usuario en Scrum

Uno de los puntos que más interrogantes provocan en la gente que se acerca a Scrum es cómo dividir el desarrollo de un proyecto en historias de usuario, es decir en tareas lo más pequeñas posibles que aporten valor funcional al cliente.

En este artículo voy a tratar de explicar el enfoque que yo adopto cuando trato de describir un requisito funcional cómo historia de usuario. Obviamente no es la única opción, ni la mejor, de echo es probable que esté pasando un montón de cosas por alto y que muchos se lleven las manos a la cabeza, pero creo que puede ser útil cómo primera aproximación para aquellas personas que no tengan del todo claro un procedimiento a seguir.

Vamos a tomar cómo ejemplo un problema de la asignatura de Especificación de Software de la Facultad de Informática de Barcelona (Enginyeria del Software: Especificació. Especificació de sistemes orientats a objectes amb la notació UML. EDICIONS UPC), que presenta el siguiente enunciado:

Se quiere desarrollar un sistema sencillo de control de préstamos en un a biblioteca. El sistema debe admitir el alta y la baja de socios y de libros. Los socios pueden pedir libros en préstamo, pero no se pueden tener más de tres libros en préstamo en un momento determinado. Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente. Cuando llega a cero el socio se de de baja automáticamente.


Ahora supongamos que este problema nos lo ha planteado nuestro cliente, que quiere que le construyamos exactamente el sistema descrito en el enunciado ¿Cómo llegamos desde el mismo, a la lista de tareas del backlog? Por el momento vamos a obviar aquellas tareas que a simple vista no aportan valor al cliente pero que son del todo necesarias para el proyecto (definir e implementar la arquitectura del sistema por ejemplo) y vamos a centrarnos únicamente en los objetivos funcionales.

Lo que vamos a hacer va a ser un “clásico” análisis de requerimientos, intentando extraer del texto (lo que nos dice el cliente) las diferentes funcionalidades que debe tener el sistema. Para ello analizamos los párrafos del texto. A simple vista podemos extraer las siguientes funcionalidades:

De la siguiente frase: El sistema debe admitir el alta y la baja de socios y de libros extraemos las siguientes posibles historias de usuario:
  • Alta Libro
  • Baja Libro
  • Alta Socio
  • Baja Socio
Del párrafo siguiente: Los socios pueden pedir libros en préstamo, pero no se pueden tener mas de tres libros en préstamo en un momento determinado obtenemos una única funcionalidad o historia
  • Préstamo libro
En este párrafo: Los libros se han de devolver antes de un mes de la fecha del préstamo. Cada vez que un socio devuelve un libro después de la fecha de la devolución, se penaliza reduciendo en una unidad el número de libros que puede tener simultáneamente creo que podrían identificarse dos historias (es mi opinión, quizás otra gente opine que sólo hay una posible historia)
  • Devolver libro
  • Penalizar socio
En el último párrafo obtenemos otra posible historia: Cuando llega a cero el socio se de de baja automáticamente. Aunque pueda parecer que es una historia repetida, yo considero que a nivel de valor al cliente es una funcionalidad diferente.
  • Baja automática de socio
Aparte de las historias que aparecen más o menos explícitas en el código, quizás podrían deducirse otras historias cómo:
  • Iniciar sesión en el sistema
  • Cerrar sesión
  • Alta usuario
  • Baja usuario
La lista completa de historias que tendríamos sería la siguiente:
  • Alta libro
  • Baja libro
  • Alta socio
  • Baja socio
  • Préstamo de libro
  • Devolver libro
  • Penalizar socio
  • Baja automática de socio
  • Iniciar sesión en el sistema
  • Cerrar sesión
  • Alta usuario
  • Baja usuario

Si estuviéramos en una metodología clásica de desarrollo, en este punto deberíamos hacer los casos de uso para los requerimientos identificados, sus diagramas de secuencia, etc. En una metodología cómo Scrum, por definición, no es necesaria esta documentación (queda a elección de cada uno decidir que documentación necesita su proyecto) y lo que nos quedaría por hacer es definir e introducir las historias en el backlog. ¿Y cómo se define una funcionalidad en forma de historia de usuario? Pues la idea es expresarla desde el punto de vista del cliente, o del usuario que va a usar el sistema, con un lenguaje que pueda ser entendido perfectamente por ellos (nada de UML, OCL o demás lenguajes de especificación) y que no cree ambigüedades. Por ejemplo:

Historia: Préstamo de libro
ID: 5
Descripción: Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento.
Importancia: 300
Cómo probarlo:
  • Introducir un número de socio incorrecto y comprobar que se indica error
  • Introducir un socio que ya tiene 3 libros en préstamo y comprobar que se indica error
  • Introducir un libro del que no hay ejemplares y comprobar que se indica un error
  • Introducir todos los datos correctos y comprobar que el número de ejemplares disponibles del libro disminuye y el número de préstamos del socio aumenta en uno.
Cómo vemos, en Scrum se detalla de manera poco explícita la funcionalidad, únicamente se explica a nivel de cliente. La ventaja es que no se fijan los detalles de la implementación hasta el momento en que se va a realizar (en la descomposición en tareas) con lo que se puede reaccionar más ágilmente ante los cambios de los requisitos o de las necesidades del cliente.

Haciendo lo mismo con las demás funcionalidades, nos quedaría un product backlog similar al siguiente (se ha obviado la parte de test de las historias):


Historia

Importancia

Descripción

Alta libros

600

Dar de alta un libro en el sistema

Baja libros

250

Dar de baja un libro del sistema

Alta socio

500

Dar de alta un socio en el sistema

Baja socio

300

Dar de baja un socio del sistema

Pedir libro

350

Pedir prestado un libro

Devolver libro

340

Devolver un libro

Penalización socio

330

Penalizar al socio por retrasarse en la devolución

Baja automática

320

Dar de baja automáticamente de socio

Iniciar sesión en el sistema

550

Iniciar una sesión de usuario en el sistema

Cerrar sesión

500

Terminar sesión con el sistema

Alta usuario

450

Dar de alta un nuevo usuario en el sistema

Baja usuario

400

Dar de baja un usuario del sistema




En este punto tenemos identificadas todas las tareas funcionales del proyecto, y se ha descrito cada una de ellas cómo una historia de usuario.

Aunque ya tenemos completa la lista de funcionalidades, es obvio que el product backlog tal y como está no es suficiente para poder avanzar en el proyecto, ya que no aparecen todas aquellas tareas que no son funcionales (historias técnicas, requisitos no funcionales o como se le quieran llamar) pero que son necesarias para el desarrollo del proyecto. Pero la mayoría de estas tareas no aportan valor al cliente, entonces ¿Se deben incluir estas tareas en el backlog? ¿Y de que manera? No vamos a discutir en este artículo el tema, ya que daría para muchos posts, pero a modo de apunte se podría gestionar de la siguiente forma:

En proyectos que se están iniciando, es fácilmente justificable introducir tareas técnicas o no funcionales, ya que sin ellas el proyecto no existe. Así bajo la forma de Epics (o super historias de usuario) se podrían englobar tareas tales cómo Implementar la capa de datos, implementar la capa de comunicaciones, etc. Estas tareas se llevarían a cabo en las primeras iteraciones, o incluso en una primera iteración mayor que las otras.

En fases más avanzadas del proyecto, es difícil justificar tareas no funcionales, cómo la refactorización de módulos, instalación de servidores de pruebas, etc. Ya que el cliente querrá priorizar aquellas historias que le aporten valor. En este caso lo ideal es intentar que el cliente comprenda la importancia de las tareas a realizar, o si eso no es posible utilizar otras técnicas, cómo introducirlas dentro de alguna de las historias de usuario, o mantener una lista separada de historias técnicas con un porcentaje de tiempo no negociable con el dueño de producto.

Cómo hemos visto el proceso de definir historias de usuario es tan simple (o tan complicado) cómo realizar un análisis de requerimientos, proceso para el cual no hay ningún truco infalible y dependerá en gran medida de la experiencia y pericia del analista o analistas que se encarguen de él, y expresar las funcionalidades resultantes del análisis en un lenguaje que pueda ser fácilmente entendido por el cliente de nuestro proyecto.

Por si queréis ampliar información os dejo algunos links interesantes sobre Historias de Usuario i Scrum (o Agile en general). Esperamos vuestros comentarios!

http://en.wikipedia.org/wiki/User_story
http://www.userstories.com/
http://www.joelonsoftware.com/articles/fog0000000036.html
http://ezinearticles.com/?Scrum-User-Stories&id=1605892
http://scrummethodology.com/scrum-user-stories/
http://kanemar.com/2006/09/09/writing-user-stories/

jueves, 12 de febrero de 2009

Experiéncias implantando SCRUM

En este artículo vamos a tratar de explicar nuestra experiéncia implantando Scrum y prácticas ágiles en general en nuestro proceso de desarrollo de software. Hemos divido el artículo en diferentes capítulos que explican cada una de las fases por las que hemos pasado. Esperemos que nuestra experiéncia os ayude de alguna manera. Nos gustaría remarcar que hablamos en nombre de todo el grupo de trabajo, que ha sido el que, trabajando todos unidos en una misma dirección, ha tirado adelante esta história.


ANÁLISIS

Después de un par de años trabajando en nuestra empresa, vimos que necesitábamos una manera mejor de trabajar. El equipo era demasiado especializado, cada persona tenía conocimiento sobre áreas muy concretas del sistema y esto penalizaba mucho las ausencias de algunas personas. Además a pesar de que al principio se trabajaba de manera relativamente tranquila poco a poco, a medida que los clientes aumentaban, la dinámica fue degenerando hasta convertir el trabajo diario en un “apaga fuegos”, solucionando bugs de anteriores versiones, dando asistencia, y intentado desarrollar nuevas funcionalidades en tiempo récord. Además existía una paralelización excesiva de las tareas (se empezaban muchas de golpe y pocas se acababan en un tiempo razonable ), los requisitos cambiaban con facilidad al igual que las prioridades y había poca comunicación entre el equipo, tanto de las tareas que realizaba cada uno cómo del conocimiento. Algo que si que teníamos era un seguimiento del trabajo exhaustivo por parte de nuestra responsable, que también estaba preocupada por mejorar nuestra manera de trabajar.


DESCUBRIMIENTO

Una vez que vimos que teníamos que buscar otra manera de trabajar, fuimos investigando por foros de internet, páginas web, experiéncias de conocidos hasta encontrar un documento que cambió completamente nuestra visión del desarrollo. El documento es el conocido “Scrum y XP desde las trincheras” y en él descubrimos conceptos tan importántes como Scrum, Integración Contínua o testeo unitário. Algunos de estos conceptos era nuevos para nosotros, otros ya los conocíamos pero no eramos conscientes del impacto que podían tener en nuestro día a día. El echo de conocer la experiéncia de gente que trabajaba en proyectos grandes e importantes y que consideraban esto vital, nos dio el empujón definitivo para emprender esta aventura.


PRIMEROS PASOS

Cuando tuvimos claro por donde tirar empezamos ha hacer una prueba piloto con un grupo reducido de personal, en concreto tres personas. Lo primero que hicimos fue montar un repositorio de código (con Subversion) y empezar a utilizar Scrum para nuestra organización interna, todo esto a espaldas de nuestros jefes. Antes de llenarle la cabeza con ideas “extrañas y novedosas” que pudieran provocar su rechazo creímos conveniente experimentar por nuestra cuenta un tiempo, para intentar mostrarles algo sólido, con técnicas ya probadas y con resultados que respaldaran nuestra idea.

Nuestros primeros pasos con Scrum consisitieron básicamente en aglutinar una serie de tareas (o historias) que teniamos en cola (¿product backlog?) , priorizarlas , realizar la división en subtareas , hacer una estimación (utilizando planning poker) y la realización de las reuniones diarias.

Aunque era todo muy “precario”, nuestra primera impresión con Scrum fue muy positiva. De tener a un equipo al que tan sólo se le controlaba la faena a intervalos relativamente grandes de tiempo, con la consiguiente tardanza en aplicar cambios de diseño o requerimientos y la lentitud en detectar errores, pasamos a tener un equipo que cada día compartía la información del trabajo realizado y al que era muy fácil orientar a resultados. Por otra parte, la utilización de un repositorio de código hacía que se eliminaran las tediosas sesiones de juntar versiones de diferentes programadores, ejercicio que era un generador de bugs terrible.


EXPANDIENDO LA SEMILLA

Una vez vimos que ibamos por la senda correcta, y que Scrum podia ayudarnos a mejorar nuestro trabajo, nos dispusimos a introducir el gusanillo de las metodologías ágiles al resto del grupo de desarrolladores, todavía a espaldas de nuestros responsables. No queríamos decirles nada hasta ver que esta técnica era válida para un grupo grande de personas, aunque nuestra responsable directa ya supiera algo de todo esto, pués es complicado esconder ciertas cosas. Cómo queríamos que el grupo se sintiera implicado en la toma de la decisión y no queríamos imponer nada, hicimos una presentación al grupo mostrándoles la manera de trabajar que teníamos ahora con nuestros diferentes gestores y a la vez explicando cómo contrapunto la gestión que se podría llevar a cabo con una metodología ágil (en concreto Scrum). Una vez acabada la presentación les preguntamos si creían que la manera actual de trabajar era una buena manera y, obviamente, la respuesta fue negativa; todo el mundo creía que se podían hacer las cosas mejor, que nuestra gestión del tiempo era deficitária y que el hecho que la toma de decisiones se centrara en nuestra responsable, que por su parte tenía un exceso de trabajo, hacía que el desarrollo se viera penalizado. Por suerte nuestra, esto coincidió con la decisión de nuestra responsable de delegar todo el trabajo que tenía que ver con desarrollo en nuestras manos, decisión que vino apoyada por el hecho que viera que teníamos capacidad para autoorganizarnos. Así que decidimos proponer al grupo un cambio en la manera de trabajar, básicamente centrandonos en dos aspectos:

  • Desarrollo: Les propusimos empezar a utilizar buenas prácticas de programación de manera conjunta y coordinada -> Instauranado el repositorio de código y enseñando cómo utilizarlo, creando una guía de estilo para homegenizar el código de todo el departamento, instaurando el testeo unitario, configurando un servidor de integración contínua, etc.
  • Gestión: Les propusimos instaurar Scrum como nuestra metodología de trabajo.

De esta manera empezamos nuestros primeros sprints. Al principio nos centramos en las reuniones de inicio de sprint, en los seguimientos diários y en pequeñas retrospectivas muy básicas. La reacción del grupo fue muy positiva y poco a poco empezamos con las demostraciones internas, aunque esto todavía tenemos que mejorarlo.



IMPULSO DEFINITIVO

El impulso definitivo ha sido la participación de nuestra jefa en todo el proceso de Scrum, principalmente en la reunión de inicio de sprint y en las demostraciones y retrospectivas. Esto ha sido muy importante para poder definir de manera más detallada las tareas a realizar, para la decisión de que entra y que no entra en cada sprint y, sobretodo, en que viera que somos un grupo que trabaja unido para obtener resultados. Ha sido también vital hacerle ver que la parelización de tareas es contraproducente y tan sólo lleva a tener muchas tareas sin acabar al final del sprint ( que es lo que nos pasaba en los primeros sprints ). Ahora todo el equipo se centra en una historia de usuario ( a lo sumo dos ) y a final de sprint siempre podemos mostrar un producto con incremento de valor sobre la iteración anterior.


IMPEDIMENTOS

Son muchos los impedimentos que nos hemos ido encontrado a lo largo de nuestra aventura, y seguramente nos encontraremos muchos más. Vamos a intentar exponer en forma de lista los que consideramos más importantes:

  • Dificultad a la hora de estimar: Aunque cada dia afinamos más, todavía nos falta un buen trecho para llegar a hacer buenas estimaciones de las histórias de usuario. Esto normalmente se vé reflejado en que conseguimos realizar menos histórias de las previstas. Afortunadamente, el hecho de que ultimamente el equipo se centre en menos histórias a la vez ha hecho que se minimice el impacto de este impedimento.
  • El equipo no sólo se dedica a programar. Nuestro equipo no es un equipo de desarrollo al 100%. También hace testeo, instalación en el cliente, resolución de incidencias, etc. Esto hace que nuestras estimaciones se vean penalizadas por una carga de trabajo no previsto que retrasa el desarrollo.
  • Incompresión por parte de otros gestores. La respuesta de nuestra jefa a nuestra propuesta ha sido espléndida, nos apoya al 100% e intenta colaborar en todo lo posible, pero no sólo trabajamos con ella. El hecho que haya en nuestra empresa gente con mentalidad tradicional respecto al desarrollo de software (o incluso sin ninguna mentalidad), hace que a veces choquemos frontalmente con su forma de dirigir los proyectos y que sea complicado realizar nuestro proceso productivo tal cómo nos gustaría.
  • Respeto a las iteraciones: En ocasiones no hemos podido llevar a cabo sprints completos, debido a “grandes marrones” que llevaban tiempo aparcados y que de golpe se deben solucionar, cambiando de un día para otro (a veces justo al dia siguiente de la reunión de inicio) todas las tareas programadas.
  • Grandes aprendizajes. Todos nosotros somos nuevos en el mundo de la gestión de proyectos informáticos y, aunque intentamos aplicar todas las técnicas de manera razonable y a pasos pequeños, hay muchas cosas que aprender, tanto técnicas ( a configurar un servidor de integración continua, a programar con testeo unitario, a relizar testeo funcional, etc ) como metodológicas. Por suerte, cada vez tenemos más experiéncia y vamos dando pasos más grandes y seguros.
  • Reticencia de algunos desarrolladores. Algunos desarrolladores veían algunas de estas técnicas como algo que disminuía su velocidad de trabajo, cosa que se veía reforzada por el hecho de trabajar con los gestores tradicionales que antes comentábamos. Aquí nuestra tarea “evangelizadora” ha sido importante, haciendo charlas, propiendo lecturas, analizando artículos, etc. Al final, hemos podido convencer a todo el mundo y esto se ha notado en el dia a dia.
  • Dificultad para realizar algunas prácticas: Aunque parezca increíble, practicas básicas de Scrum cómo poder estar sentado todo el equipo junto, o tener una sala con el panel de scrum donde poder realizar las reuniones diarias son “difíciles” de llevar a cabo en algunas empresas.


EL FUTURO

Creemos que el futuro que nos espera va a ser mucho mejor. Todavía tenemos muchas cosas que mejorar: demostraciones, retrospectivas, reuniones de incio… La preparación de las demostraciones nos llevan mucho tiempo (ganar experiéncia con nuestra herramienta de ALM nos ayudará mucho ) y tenemos poco tiempo para hacer buenas retrospectivas.

Esperamos también aumentar la visibilidad de nuestro proceso y hacerlo extensivo a toda nuestra sección, hacer más públicas nuestras demostraciones ( por ahora internas ), dar permiso a todo el mundo para que vean el avance de nuestro proyecto via web con los diferentes reportes ( tablero de scrum, burndown, tasa de resolución de bugs, etc ) e intentar impregnar al resto del departamento o incluso de la empresa de nuestra filosofía de trabajo.

También esperamos que nuestros desarrollos sean cada vez más estables gracias a la incorporación masiva del testeo unitario, la integración contínua, mejora en los procesos de testeo, etc. Esto hará que las interrupciones en el desarrollo por la irrupción de bugs también sea menor. El hecho de tener sistemas más estable también hará que podamos delegar trabajo de instalación y mantenimiento a otras secciones de nuestra empresa, ganando así tiempo para desarrollar más y mejor.


CONCLUSIONES

Cómo conclusión podemos decir que nuestra experiencia con las metodologías ágiles en general y con Scrum en particular está siendo muy positiva, tanto en el ámbito personal cómo en el profesional (mejora en el trabajo diario al disminuir los impedimentos, alineación con el cliente para alcanzar objetivos, focalización en incremento de valor…). También es importante tener claro que Scrum y las metodologías ágiles en general no son una bala de plata. Son metodologías que requieren de un esfuerzo “extra” a corto plazo por parte de todos los roles implicados en el desarrollo del proyecto (esfuerzo que es posible que algunas personas no estén dispuestas a pagar) y que requieren de un contexto apropiado para su buen funcionamiento (hay tipos de proyectos que difícilmente encajarían en Scrum). Cómo dice Rodrigo Corral en este artículo “nadie dijo que no exigiera un esfuerzo”.

Por nuestra parte os animamos de manera entusiasta a que hagáis el esfuerzo de conocer Scrum porque el esfuerzo vale realmente la pena.