Backlog management Tips

In this post I want to share some tips about this topic.

Backlog basics (or preliminary definitions)

Some people tend to think that a backlog is just a simple list of items. I don’t think that is true; I try to use the word backlog to refer to a list of items that are prioritized and estimated. Of course, the prioritization is done by the customer while the estimation is done by the technical team.

What are the items in the backlog? Depending on the context, the items can by user stories, use cases or simply tasks. When working on a development project I try to avoid having tasks in my backlog because in many cases tasks do not add value to the customer who prefers user stories. In most cases, what really adds value to the customer is working software and that is represented by a group of user stories.

The backlog is commonly used to organize work but is also used to provide visibility of the project’s status .

Backlog recommendations

Make the status EXPLICIT

A very common strategy to show the status in a consumable way is to use a semaphore pattern (green-yellow-red): Done, In progress, Blocked, Pending. Using this convention is very easy to detect smells. For example, if there are many yellow stories it could mean that there is too much work in progress, and you are not focused on completing specific stories.

Note: if you are using a dashboard, then the status is given by the position of the item in the dashboard.


Limit the work in progress

Completed items are the only real measure of progress, so you should focus on completing items instead of accumulating stories in progress. This leads us to the following question: How many stories can be in progress at the same time? There is no single answer; it depends on the length of time, but each person should work on ONE item at a time. In a particular situation it could be that two items are closely related, so you could decide to work on them both at the same time. But if you have 3 team members and 10 items in progress, you should look at the situation.

INVEST in SMART

When working with user stories, it is good practice to keep the INVEST acronym in mind:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable Testable

Beyond user stories, I think these considerations are very useful when creating a backlog, no matter what your items are.

Other famous acronym related to planning and very used when defining goals is SMART:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time-boxed

More information about these acronyms can be found here.

My backlog

The following picture is a screenshot of the backlog of my current project. I have highlighted some important properties:

Retrospectiva del tutorial de integración contínua

Hoy dí el tutorial de integración contínua que anuncié hace un par de dias.

Como de costumbre comencé con una dinámica para romper el hielo y conocer el perfil de los asistentes. Resulto que todos estaban familiarizados con la práctica de integración contínua pero no todos las utilizaban. De la gran mayoría de la sí la utilizaba una una interesante porción no había realizado el setup del del ambiente de integración, sino que utilizaban un ambiente que alguién más en su organización había configurado.

Luego de la apertura, la sesión transitó guiada por esta presentación que armé para la ocasión. Sinceramente la presentación no fué tan interactiva como me hubiera gustado, pero que estoy contento con el resultado: pudé contar todo lo que habia planeado (e incluso algunas cosillas más), hubo espacio que los asistentes hicieran sus aportes y también para contestar consultas. Nadie se animó a trabajar a la par mia e ir configurando su propio ambiente, pero creo que en parte fue porque mi forma de encarar la sesión no fue lo suficientemente motivadora para ello. Definitivamente este es un punto a mejorar.Adicionalmente a lo expuesto en el material de la presentación, hablamos sobre algunas cuestiones conceptuales y también sobre algunas herramientas adicionales: Sonar, Janky and CloudBees.

Finalmente para cerrar pedí feedback con la técnica de las carita:

  • 🙂  18
  • 😐  0
  • 😦  0

(hay que considerar que unas 4 personas de fueron antes de que terminara la actividad)

Evento: Tutorial de Integración Contínua

El próximo miercoles a las  18.30 hs. voy a dar un tutorial de integración contínua en el contexto de los encuentros mensuales del grupo Agiles @ Buenos Aires.
La entrada es libre y gratuita, pero requiere registración previa. Los interesados pueden registrarse via Meetp up
A grandes rasgos la idea del tutorial es repasar los fundamentos que sustentan esta práctica y analizar distintas alternativas técnológicas para su implementación en los distintos lenguajes. Al mismo tiempo pondremos manos a la obra automatizando el build de algunos proyectos y resolviendo los problemas más comunes que suelen aparecer. Aquellos participantes que lo deseen pueden traer sus propias máquinas para trabajar y automatizar sus propios proyectos.

Titiritero Reloaded

Titiritero es un mini-framework que desarrollamos para Algo3 de cara a ocultar algunas complejidades técnicas como manejo de componentes Swing, threads y otro, que los alumnos suelen enfrentar al realizar sus trabajos prácticos. De esta forma, los alumnos pueden concentrarse en el modelado de objetos que es el principal objetivo de la materia.

Este framework lo comencé yo mismo como ejemplo de implementación de un gameloop siguiendo premisas de diseño MVC. Más tarde algunos otros docentes y alumnos de materia hicieron algunos aportes. De esta forma la base de código fue creciendo de forma medio caótica.

El fin de semana pasado estaba preparando la clase de MVC e introducción a Titiritero para lo cual me puse a desarrollar un nuevo ejemplo basado en Titiritero. Me crucé con un par de comportamientos inesperados y cuando intenté arreglarlos no hice más que sumar más inestabilidad. Claro, esto no me sorprendió porque titiritero tenia una cantidad mínima de pruebas y su cobertura no superaba el 20 %.

Entonces decidí cortar por lo sano y reescribir el framework completo usando TDD y contemplando algunas mejoras que tenia en mente desde hacia ya un tiempo. Para tener un mejor control de los aportes de código realizados por terceros, decidí hostear el proyecto en GitHub para asi poder usar el modelo fork-pull request.

Ttiritero v2.0 está publicado en GitHub y tiene una cobertura superior al 90% 😉

Un ejemplo de cómo usarlo puede descargase desde aqui, para correrlo es necesario Java JDK 1.6+ y Ant.

Mi enfoque hacia la arquitectura de software

Cuando me tocó estudiar este tema formalmente como alumno, recuerdo que lo hice desde la perspectiva del proceso unificado. Luego por iniciativa propia estudié el tema desde otras perspectivas/fuentes. Pero creo que lo que realmente me hizo entender el tema fue poner manos a la obra. Con esto en mente, hace unos dias me senté a preparar mis clases sobre este tema para mi materia de UNQ. Revisé algunas fuentes tradicionales, notas personales  y algunas fuentes más recientes y pensé algunos ejercicios para hacer con lo alumnos de cara a intentar bajar a concreto algunas cosas que pueden llegar a resultar abstractas.

Como mencioné en un post anterior, decidí encarar el tema presentando un problema, el cual nos fue guiando por los atributos de calidad hacia la arquitectura como disciplina. Luego en una segunda clase, vimos algunas definiciones formales y estilos de arquitectura con algunos ejemplos concretos razonando sobre código las implicancias de cada estilo. La tercer clase la decicamos a ver algunas técnicas concretas para atacar la definición de arquitectura de una aplicación. Finalmente en una cuarta clase, los alumnos realizaron presentaciones de ciertos estilos de arquitectura utilizando el mismo enfoque que habiamos utilizando previamente para presentar otros estilos.

Como material de estudio complementario a lo visto en clase elegí:

En algunas clases posteriores volveremos sobre algunas temas de arquitectura (por ejemplo para analizarla en el contexto de distintas metodologias de desarrollo), pero ya como cuestión colateral y no como tema central de una clase.

Nueva edición del curso de Ingeniería de Software de Berkeley

Hoy comienza una nueva edición del curso  online de Berkely sobre el que estuve escribiendo tiempo atras: Software Engineering for Software as a Service. En esta ocasiónvoy a ser parte del staff del curso: puntualmente voy a estar colaborando en los foros y en el armado de los exámenes. Para esta nueva edición hay varias mejoras: nuevos videos, más ejercicios y bug fixes entre otros.
Los interesados pueden inscribirse gratuitamente en https://class.coursera.org/saas.

 

Algunas noticias de Agiles 2012

La sede es Córdoba y los chairs del evento son Emilio Gutter y Pablo Rodriguez Facal. Pero nada de esto es noticia, pues son cuestiones que fueron publicadas hace ya un par de meses.

Lo que si puede considerarse novedad es que se confirmó que Tincho Salias será Keynote speaker de este evento lo cual es una noticia doblemente buena: una vez más tendremos un keynote speaker latino y conociéndolo a Martín su keynote seguramente será sobre prácticas concretas no muy lejanas al código.

Otra novedad es que ya está abierto el call for papers con fecha límite el 16 de Junio

Architectural Kata @ Agiles BAires

Ayer tuve el gusto de participar de un architectural kata facilitado por @MartinSalias. La actividad se realizó en el contexto del encuentro mensual de la comunidad ágil de Buenos Aires y contó con más 20 asistentes.

Nos dividimos en grupos de 5 personas y usando hoja y papel cada grupo trabajó en resolver un desafio de arquitectura en un lapso de 45 minutos. Como mencionó uno de los participantes (creo que @ajlopez sino me equivoco) : «… pasamos más tiempo interpretando la consigna y debatiendo el alcance,  que en las cuestiones técnicas» y aunque parezca llamativo que creo este intercambio resultó muy enriquecedor.

Luego cada grupo cada grupo tuvo 5 minutos para exponer su solución y otros 5 minutos para responder preguntas.

Simple, concreto y enriquecedor.

Build Server Gratuito en la nube: TravisCI

Ayer descubrí TravisCI, un build server gratuito y open souce para proyectos open source. Si bien no tiene en principio todos los features de Jenkins (en cuanto a reportes, notificaciones, etc, etc) cumple bien su trabajo de build server.

Trabaja integrado con GitHub y para disparar los build utiliza un hook the Github. Ofrece soporte para los siguientes lenguajes: Clojure, Erlang, Groovy, Java, Node.js, Perl, PHP, Python, Ruby y Scala.

Lo probé con mi proyecto SWTFederation y la verdad que me sorprendió lo simple que fue la configuración.

Espero les resulte útil.

Planificando Ing. de Software 2012

En base a la experiencia del último cuatrimestre, el feedback de los alumnos y algunas ideas que vengo trabajando desde hace ya un tiempo, este primer cuatrimestre de 2012 viene con varios cambios.

En primer lugar voy a dar un enfoque más práctico, o sea, vamos a programar, aunque aún no decido si Java, Smalltalk o Ruby (creo que es algo que puedo dejar decidir a los alumnos).

En segundo lugar voy a hacer algunos cambios en la profundidad de los contenidos: más agile, más calidad/testing y menos UP. De hecho no quiero dedicar más de 3 clases a UP y posiblemente algún trabajo individual (un questionario posiblemente).

En tercer lugar, pero no por ello menos importante, voy a dictar la materia en forma iterativa. Esto es un tema que he hablado con colegas en reiteradas ocaciones: bien probado está que el desarrollo iterativo es una de las prácticas de ingeniería de software más aceptadas y utilizadas en la actualidad, pero sin embargo la ingeniería de software sigue enseñanadose en forma secuencial. Entonces mi idea es dividir la materia en iteraciones, entre 4 y 6. Cada una de ellas time-boxed, con un entregable concreto. En cada iteración veremos todas las actividades del proceso de desarrollo, profundizando un poco más en cada iteración, al final de cada iteración tendremos un entregable de valor.

La excepción será primer iteración, que será más corta y en la que nos centraremos (al igual que el cuatrimestre pasado) en entender las particularidades de la disciplina. El entregable de esta primer iteración será el setup del portfolio individual (en futuros post voy a desarrollar este punto).

Cada una de las siguientes iteraciones tendrá un ejecutable de código con sus correspondientes pruebas, algunas de las cuales serán especificadas como parte de la consigna y otras deberán ser diseñadas por los alumnos.

Adicionalmente a la entrega de final de iteración, tendremos también algunas entregas intermedias.

Otro de los cambios será la utilización de un build server para verificación de los entregables.

También tengo la intención de utilizar una plataforma virtual, la cual espero nos permita tener una mejor dinámica de intercambio en el curso. Ya realicé el pedido al departamento con lo cual solo me queda esperar que acepten la petición, pues en general la plataforma virtual está solo disponible para la materias de las carreras virtuales.

Otro agregado de color que pienso hacer el tema «ejercicio profesional». Con este nombre pretendo englobar varios consejos para el desempeño profesional como por ejemplo: como armar un CV, como prepararse para una entrevista laboral, etc, etc.

Al mismo tiempo quiero mantener varias de las prácticas del cuatrimestre anterior como por ejemplo el envio de mail de resumen después de cada clase, la planificación y estimación de las tareas por parte de los alumnos y visibilidad contínua sobre las asistencia a clase. Este última  práctica tiene que ver con que si un alumno piensa faltar a clase, debe comunicarlo previamente, el obejtivo de esto es que se acostumbren a dar visiblidad a su equipo. También voy a repetir la experiencia de invitar a profesionales de la industria a contar sus experiencias (para este cuatrimestre ya tengo el compromiso de Manuel Trejo de Kinetia)

Por último estoy evaluando distintas alternativas tecnológicas para intentar grabar las clases, pero no estoy seguro que pueda implementar esto.

Si algún futuro alumno lee esto puede que se pregunte ¿pero cuanto voy a tener que trabajar para aprobar esta materia? Recuerdo que una vez un profesor me dijo que para hacer una carrera univesitaria hay que dedicar al menos la misma cantidad de horas de estudio que la cantidad de horas de clase. Yo no creo que para esta materia sea necesario tanto. Considerando que tenemos entre aproximadamente 5 horas netas de clase, estimo que con dedicar unas 3 horas semanales extra clase, deberia ser suficiente. Pero ojo, hablo de 3 horas netas, podes parate para ir al baño, tomar un vaso de agua o preparar el mate, pero nada de mail, ni chat, ni SMS, ni facebook, son 3 horas estudio posta.

Las clases empiezan en dos semanas y tengo muchas expectativas. Ya les iré contando más a medida que avance.