Autor: NicoPaez

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:

Me aceptaron un trabajo y no me avisaron

Esto es algo que nunca me habia pasado, mmm, en realidad puede que me haya pasado anteriormente y no me haya enterado, ja!

Resulta que a comienzos de abril me llegó un anuncio del VII Congreso de Tecnología en Educación y Educación en Tecnología. Cuando entré al ver sitio y ví las áreas de interés decidí enviar un trabajo. Tomé un trabajo que habia realizado el año anterior anterior para la materia Psicología Cognitiva, lo ajusté al formato solicitado y luego de validarlo con el compañero con quien hice el trabajo, lo envíe. El tiempo pasó y nunca tuve noticias.

Pero el sábado anterior al congreso,  me llamó mi compañero y tuvimos una charla que más o menos fué:

– El: ¿vas al congreso?

– Yo: no, ¿por?

– El: porque el trabajo fue aceptado y figuras en el programa del congreso

– Yo: no puede ser, nadie me notificó y solo restan dos dias para el congreso. ¿A vos te avisaron algo?

– El: no, yo me enteré cuando entre a ver el horario de presentación de otro trabajo que envié y del que sí me notificaron, si queres me encargo de presentar este trabajo también.

Y así era, el trabajo había sido aceptado y nunca que llegó notificación alguna. Inmediatamente escribí a los organizadores para pedirles confirmación, pero la respuesta llegó 3 días después de finalizado el congreso. El trabajo fue presentando por mi compañero. La respuesta de la organzación (como ya dije: 3 dias luego del evento) fue que habian notificado a mi compañero.

Desafio de diseño: objetos inteligentes (resolución)

(continuación de Desafio de diseño: objetos inteligentes)

Hay varias formas de atacar este problema de la “testeabilidad”.

La primera opción que muchas veces viene a la mente, es hacer públicos los métodos privados y testearlos unitariamente. Si desde el punto de vista práctico esta opción puede parecer viable, cuando la miramos desde el punto de vista conceptual resulta incorrecta, pues dichos métodos son conceptualmente privados y no seria correcto cambiar su visibilidad para solo probar la clase. Si estuvieramos trabajando con C# Visual Studio nos ofrece una alternativa basada en reflexion para acceder a miembros privados de la clase, pero conceptualmente esto sigue siendo incorrecto.

Si pensamos el problema un poco más, nos daremos cuenta que puede que la clase tenga algunos problemillas de responsabilidades. Para ser más explícitos, tiene demasiadas responsabilidades: decidir si moverse y en caso positivo hacerlo, decidir si disparar y en caso positivo hacerlo, etc, etc. Bueno, si asumimos este diagnostico entonces hemos dado el primero paso: identificar el problema.

Repensemos la cuestión una vez más. Una clase que toma muchas decisiones (si X, si Y, si X, etc) y hace muchas cosas (X, Y, Z, etc). Cada una de esas cuetiones las hemos encapsulado en un método privado de cara a tener un código más legible. ¿y si fueramos un paso más allá? ¿Que tal si convertimos cada uno de ese métodos privados en una clase? De esta forma tenenemos una clase con la lógica de movimiento, otra clase con la lógica de disparo y asi sucesivamente. Así nuestro objeto inteligente tiene mucho menos código y su responsabilidad está limitada a coordinar “las estrategias” de movimiento, disparo, etc, etc. Al mismo tiempo cada estrategia puede ser testeada independientemente.

Bueno, este ha sido el primer desafio, próximamente vendrán algunos más.

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.

Primeros pasos con Windows 8 y Visual Studio 2012

Apenas apereció el primer el preview de Windows 8 hace ya un par de meses, lo instalé en una máquina virtual, le di una mirada muy superficial y nunca más lo usé.

Hace un par de semanas comencé a trabajar en un nuevo proyecto en Southworks y tuve que volver a instalarlo. En esta ocasión no utilicé una máquina virtual tradicional, sino que seguí un procedimiento mixto que consiste en crear un disco virtual (vhd), bootear la maquína con un pendrive con Windows 8 es hacer la instalación en el disco virtual. El proceso de instalación se encarga de setear un nuevo bootloader que permite elegir qué sistema iniciar cuando bootea la máquina: Windows8 (instalado dentro del vhd) u otro sistema instalado en el disco fisico. El detalle del procedimiento que utilicé, está documento en este post de Scott Hanselman. Una vez completa la instalación de Windows 8, procedí a la instalación de Visual Studio 2012, la cual resultó muy más rápida de lo que esperaba.

Sinceramente no estaba al tanto de las novedades de ninguno de los dos productos, con lo cual todo me está resultando nuevo. Respecto a Windows8 destaco:

  • Un cambio importante en la interface de usuario, da la impresión que ha sido diseñada para ser utilizada con dispositivos táctiles.
  • Viene con soporte nativo para montar imágenes ISO.

Respecto de Visual Studio 2012 destaco:

  • Importantes cambios a nivel visual: renovación total de íconos y nueva estética
  • Nuevos tipos de proyectos y nuevas funcionalidades acordes a la evolución del .Net Frameworks
  • Mejoras en el soporte de refactoring

Taller sobre motivación: saliendo de la zona de confort

Ayer fui facilitador de una taller de actualización pedagógica sobre motivación realizado en el contexto de la iniciativa «El aula y el trabajo«, un proyecto de extensión de la Universidad Nacional de Quilmes. Llegué por invitación de Mara Dalponte y Daniel Palazzo.

El taller se llevó acabo en la EEST N° 4 de Berazategui y contó con 25 asistentes entre los que habia docentes de docentes nivel medio, docentes de TPI y algunos otros referentes sociales de la zona.

La actividad comenzó con una bienvenida a cargo de Mara, quien repasó brevemente el objetivo del proyecto y del  taller en particular. Luego llegó mi turno. Me presenté brevemente y propuse una actividad para romper el hielo (al mejor estilo agiles@baires). Una vez entrados en confianza utilicé la ideas de Dan Pink sobre motivación como disparadores del debate y les sumé algunas ideas/técnicas surgidas de mi propia experiencia.

Facilitar esta actividad fue un gran desafio para mi, pues el cambio de audiencia me obligó a salir de mi zona de confort. Sinceramente disfruté la actividad y quedé muy conforme con como se desarrolló. Es más, creo que en un punto es más lo que me llevé yo que lo que les dejé a los asistentes, ja!

Bueno, esto es todo por ahora, me despido no sin antes darle las gracias a Daniel y Mara por haberme dado la oportunidad de participar.

Nueva carrera de informática

Ayer el Consejo Superior de la Universidad Nacional de Quilmes, el pleno, por unanimidad aprobó la propuesta de creación de la carrera y el plan de estudios propuesto para la Licenciatura en Desarrollo de Software.
Personalmente participé de algunas de las discusiones de plan de estudios de esta carrera y puedo decir que el plan está muy bien (al menos para mi gusto). Un detalle a destacar es el nombre de la carrera, el cual refleja claramente el foco: Desarrollo de Software. Esto marca un diferencia respecto de la mayoria de las carreras de informática que suelen hacer referencia a Análisis de Sistemas, Sistemas de información, Informática, Computación, etc,. etc.
Esta licenciatura comprende 10 semestres, con un total de 41 materias semestrales (de distintas cargas horarias), los primeros 4 semestres serán de materias comunes a la TPI (16 en total). En los siguientes 6 semestres, hay 4 materias obligatorias y 3 optativas que sirven tanto para la licenciatura como para TPI, 2 materias que se cursan con la Diplomatura en CyT, y 16 materias nuevas, exclusivas de la Licenciatura.
¡Mis felicitaciones a Fidel a todo el equipo de TPI por este gran hito!

Build Servers Initiative

A couple of weeks ago I started helping some teams to set up their continuous integration servers. There are several tools and strategies you can use to accomplish this task. In our case, we decided to use MSBuild as the automation tool and TeamCity as the continuous integration server. Team City provides several features to automate the build process, but we preferred to minimize the dependencies with Team City for 2 main reasons:
  • We want to be able to run the automated build process in the devs machines.
  • We want to be able to use another build server.
For us, the standard build process includes:
  • Running source analysis (StyleCop)
  • Running code analysis (FxCop)
  • Compiling (CS compiler)
  • Running tests (MSTest)
  • Running coverage (VS build-it coverage feature)
MSBuild only provides built-in support to compile, so for the rest of these tasks we had to do some research. A couple of weeks ago Gabi Iglesias posted about some of the spikes we did.
After research and spiking, this is the approach we finally took:
  • To run StyleCop and FxCop we are using MSBuild Extension Pack, an open source project published at CodePlex
  • To run MSTest and coverage we are using home made MSBuild tasks developed by our Engineering Excellence team (these tasks were developed back in 2008, so for our new initiative we had to update them)
In upcoming posts we will provide more details on this topic.