Nuevos libros en camino

En el último tiempo he estado bastante ausente en este espacio. Eso de debe a que comencé a trabajar en dos nuevos libros. En realidad para ser más preciso debería decir un libro y un apunte. Hago esta diferencia en base a nivel de formalidad que voy a poner en cada uno.

Por un lado estoy trabajando con Carlos Fontela en un libro de Programación Orientada a Objetos que nos sirva como soporte para materia que dictamos en UBA (algo3). Por otro lado estoy escribiendo un apunte sobre Automatizacón de Pruebas para utilizar como soporte en mis cursos sobre esta temática.

En ambos casos la herramienta de escritura/publicación elegida ha sido GitBook la cual está basada en Git y Markdown.

Combinando métodos de estimación

Quiero compartir un método de estimación que suelo utilizar buenos resultados (buen resultado = estimación muy cercana al resultado real).

Este método es un mezcla de PERT y Wideband Delphi, por ello voy a describir en forma resumida las partes que uso de cada uno de los estos métodos y luego voy a explicar cómo las combino.

Program Evaluation and Review Technique (PERT)

Este método fue desarrollado por la Armada de EEUU durante la década de 1950. El mismo asume que la duración de una tarea obedece a una distribución probabilística Beta y en base a ello propone que cada tarea sea estimada a partir de tres escenarios: optimista, normal y pesimista. En base a esto el tiempo esperado para completar una tarea puede calcularse como:

Tiempo esperado = (optimista + (4*normal) + pesimista) / 6

Si bien el método PERT dice muchas más cosas, esta premisa es la que puntualmente nos interesa.

Wideband Delphi

Este método fue desarrollado por Boehm y Farquhar en la década de 1970. Es un método de estimación grupal basado en la opinión de expertos. Propone que la estimación sea realizada por un grupo de al menos 3 expertos. Se toma como entrada la lista de ítems a estimar, se establecen algunas premisas (como ser unidad de estimación y generalidades relacionadas al contexto como podría ser la arquitectura de base sobre la que se trabajará) y  se procede de la siguiente manera:

  1. Se discute el alcance de cada ítem para despejar dudas y ambigüedades de manera de asegurar que todos los estimadores esten estimando lo mismo.
  2. Cada estimador estima en forma privada.
  3. Se comparten las estimaciones y se analiza la convergencia/divergencia de los resultados. En caso de divergencia, los estimadores explican como fue que llegaron a los valores dados. Para realizar este análisis es común volcar los número en una hoja de cálculo y ver la media y la desviación de los mismos.
  4. Se repiten los pasos 2 y 3 hasta lograr convergencia.

Mi propuesta

Conceptualmente la propuesta es simple, básicamente consiste en aplicar la dinámica de Wideband Delphi pero asumiendo la premisa de PERT y pidiendo por ello que cada estimador brinde 3 valores para cada item. Adicionalmente agrego algunas pequeñas variantes a la dinámica de Wideband Delphi como por ejemplo la participación explícita de un moderador. Esto resulta en el siguiente procedimiento:

  1. Los ítems a estimar se cargan en la planilla del moderador y se le reparte un planilla impresa a cada estimador.
  2. Se discuten alguna generalidades de la estimación (alcance de los ítems, arquitectura de base, unidad de estimación, etc) y el moderador toma nota de todas ellas.
  3. Se discute el alcance de cada ítem para despejar dudas y ambigüedades de manera de asegurar que todos los estimadores esten estimando lo mismo. El moderador también toma nota de esto
  4. Cada estimador estima en forma privada y al finalizar entrega su planilla al estimador.
  5. El moderador carga la información provista por cada estimador y al finalizar comparte con los estimadores la media y el desvío obtenido para cada ítem.
  6. Mientras que haya ítems con un desvío mayor al buscado (este es un parámetro que debe definirse de antemano), los estimadores explican cómo fue que llegaron a los valores dados y se repiten los pasos 4 y 5.

Algunas consideraciones adicionales de mi gusto:

  • Generalmente propongo estimar la construcción y luego en base a ello derivar la estimación de otras actividades asumiendo un % particular para cada una de ellas  (10 % control de la configuración, 10% prueba exploratoria, 15% gestión, etc)
  • Siempre estimo esfuerzo, no tiempo ya que el tiempo depende de cómo se planifique el proyecto y la cantidad de gente que participe del mismo.
  • Suelo buscar que el desvió en cada ítem no supere el 20%
  • Me gusta utilizar este método principalmente al comienzo de los proyectos (etapa de preventa) para obtener un estimación de orden de magnitud y poder jugar con los intervalos de confianza y generar distintos escenarios para la propuesta formal al cliente.

Aquí les comparto la hoja de cálculo que suelo utilizar para aplicar este método.

Alfred en un click

Hace un par de semanas cree un módulo Puppet para automatizar el provisión de instancias de Alfred.
Este módulo al ser aplicado generar una instancia 100% funcional de Alfred. Usado en conjunto con Vagrant puede resultar muy útil para generar entornos de desarrollo. Los pasos para ello son:

  1. Instalar Vagrant
  2. Clonar el repositorio https://github.com/fiuba/alfred-vagrant
  3. Dirigirse al directorio del repositorio clonado y ejecutar vagrant up.
  4. Navegar http://localhost:8080

Tener presente que el paso (3) puede llevar una buen rato, ya que implica las siguientes tareas:

  • Descargar la imagen base (ubuntu 14.04)
  • Instalar PostgreSQL, Ruby, Nginx y un conjunto de librerías
  • Descargar Alfred, instalar sus dependencias y configurarlo

Versionado de base de datos

Este es un tema que curiosamente para mi muchos equipos no tienen incorporado como práctica. A mi parecer en la actualidad la estrategia más común para esto es lo que desde hace años comenzó a hacer Ruby on Rails:

  • escribir los scripts incrementales de actualización de la base siguiendo una convención de naming incremental (números secuenciales o timestamp invertidos). Estos scripts al ser texto plano se pueden almacenar naturalmente en el repositorio de código junto al código de la aplicación
  • por otro lado se agrega una tabla en la propia base de datos para llevar registro de los scripts aplicados lo cual determina la versión de la base de datos.

En el caso de Ruby on Rails, uno debe encargarse de escribir los scripts (para escribir los puede usar un DSL en lugar de sql) y luego el propio framework brinda funcionalidades para crear la tabla de versión, ejecutar los scripts y llevar control de su ejecución. No estoy seguro si Rails fue el primer framework en implementar esta estrategia pero en la actualidad existen diversas herramientas en distintos lenguajes que la implementan como ser: FluentMigrator (con foco en C#), LiquidBase (con foco en Java/Grails).

Una herramienta que implementa esta estrategia y con la que he estado trabajando este último tiempo es Flyway, les comparto un video que muestra su uso y explica algunos detalles.

Cierre de cuatrimestre en UNQ (2015-1)

Terminó el cuatrimestre y hemos marcado un record en la materia: 16 inscriptos y 16 aprobados. Si bien ya habíamos alcanzado esa cantidad de inscriptos, algunos habían abandonado la materia en el camino.

Este cuatrimestre tuvimos un cambio en el equipo, por motivos personales Ingrid no pudo estar este cuatrimestre pero tuvimos la incorporación Damián Cravacuore.

En lo referente al trabajo práctico final, este cuatrimestre todos los equipos trabajaron sobre aplicaciones existentes lo cual permitió que se pudieran enfocar en cuestiones de gestión y prácticas técnicas como especificación con ejemplos, TDD e integración continua.

Mantuvimos la dinámica de katas pero como hicimos algunos ajustes de último momento surgieron algunos issues técnicos. Una innovación que agregamos en relación a este punto fue el uso de integración continua desde el comienzo.

La encuesta anónima de fin de curso nos arrojó una evaluación general de la materia de 8.6/10 y un nivel de conformidad con la nota final de 4.66/5. La nota promedio de aprobación fue 8.

Entre los puntos destacados de la retrospectiva de fin de curso surgieron:

  • Mejorar la publicación de las consignas de los trabajos prácticos
  • Ser más explícitos respecto de los plazos de entrega
  • Cuidar más la forma de dar feedback  sobre los trabajos
  • Mantener la dinámica de katas
  • Mantener las clases interactivas
  • Mantener las tecnologías y herramientas utilizadas
  • Intentar sacar mayor provecho del campus

Comparto aquí algunas fotos de la retrospectiva y un par de videos de los trabajos finales realizados:

 

unq_retro_2015-1a unq_retro_2015-1b

Cierre de cuatrimestre Algo3 (2015-1)

El pasado miércoles hicimos la retrospectiva de cierre del cuatrimestre en Algo3. Estos son los puntos destacados:

  • (+) Videos explicativos de las herramientas
  • (+) Uso del sistema de gestión de TPs (alfred)
  • (+) Clases entretenidas
  • (-) Falta de explicaciones/poco soporte para el desarrollo de las vistas en el TP final.
    En línea con la buena llegada de los videos, creemos que generar un video sobre este tema podría resultar positivo.
  • (-) Escritura de código en papel durante los parciales.
    Este un tema que venimos hablando internamente en la cátedra y si bien tenemos intenciones de cambiarlo, aún no encontramos un mecanismo que nos sirva para manejar la gran cantidad de alumnos que tenemos.
  • (-) Falta de publicación de materiales de clase.
    Mala nuestra, en muchas ocasiones utilizamos materiales en clase que luego no compartimos (por olvido) con los alumnos.

Además de los puntos positivos y negativos también surgieron algunas cosas para experimentar:

  • Incluir mocking y metaprogramación en el programa de la materia
  • Reemplazar el uso de Swing por JavaFX para la construcción de interfaces de usuario

cierre_algo3_2015-1

 

Premisas para reuniones de revisión

Quiero compartir algunos premisas básicas que utilizo intento utilizar en mis reuniones de revisión (iteration review).

Todo el equipo

En la review está presente todo el equipo, ya sea para llevarse halagos o críticas.

Ambiente limpio

La revisión no se realiza en un ambiente desarrollo sino en un ambiente de review/demo, el cual es un ambiente “limpio” y donde el producto queda disponible incluso después de finalizada la reunión para que el responsable de producto y los stakeholders puedan acceder a su gusto en cualquier momento ya sea para realizar demostraciones a terceros, pruebas exploratorias o simplemente para consulta.

La review no se mueve

La reunión de revisión se agenda al comienzo de la iteración y no se posterga por retrasos de parte del equipo de desarrollo. La reunión se realiza y se muestra lo que se tiene, si parte del compromiso no llegó a completarse, no importa, hay que dar la cara y decir que no se llegó. La reunión puede moverse si el responsable de producto o los stakeholders tienen un imprevisto, pero NO puede moverse por funcionalidades incompletas.

Dos tipos de Review

Continuando con la cuestión de la reunión de revisión, ayer hablaba con Charly Paez sobre dos tipos bastante distintos de reuniones de revisión las cuales a mi entender son consecuencia del nivel de participación del responsable de producto a lo largo de la iteración.

Caso de poca participación

En estos casos el contacto entre el equipo de desarrollo y el responsable de producto ocurre en (unos pocos) momentos muy puntuales a lo largo de la iteración: la reunión de planificación, algún mail de validación, alguna reunión de refinamiento y la reunión de revisión. El equipo de desarrollo trabaja en las funcionalidades y consulta  al responsable de producto pero recién presenta la funcionalidades terminadas en la reunión de revisión. Esto hace que la reunión de revisión sea una presentación del equipo de desarrollo hacia el responsable de producto. A veces esta reunión de revisión trae sorpresas y se extiende más de una hora.

Caso de mucha participación

En estos casos la interacción entre el responsable de producto y el equipo de desarrollo es mucho más frecuente y fluida. Al mismo tiempo el equipo desarrollo no espera al final de la iteración para mostrar/validar las funcionalidades desarrolladas. Sino que a medida que las funcionalidades van siendo desarrolladas/completadas el equipo las va validando con el responsable de producto. Más aún, el responsable de producto tiene una participación muy activa en las pruebas de aceptación. Esto que hace que el responsable de producto llegue a la reunión de revisión sabiendo de antemano con qué se va a encontrar y habiendo ya usado las funcionalidad que se va a presentar. En estos casos la reunión de revisión tiene un sentido distinto. Ya no tenemos al equipo presentando el producto al responsable de producto (pues este ya lo vio) sino que tenemos al responsable de producto presentando el producto al resto de los stakeholders.

Personalmente cuando puedo elegir, elijo sin dudas este segundo tipo de revisiones ya que cuando pude utilizarlo el resultado de nuestro trabajo tuvo muchísimo más impacto en la organización. En realidad no creo que el impacto sea consecuencia del tipo de revisión sino al contrario: el proyecto era de alto impacto, eso hizo que el responsable de producto tuviera un gran involucramiento en el proyecto y eso derivó una excelente interacción con el equipo de desarrollo y en reviews del segundo tipo.

Continuará…

(no me gustan los nombres que le puse a cada tipo de review, si alguien mejores propuestas, son bienvenidas)

La reunión olvidada: Iteration Review

En el desarrollo (ágil) de software actual hay 3 reuniones bien establecidas: iteration planning, iteration review y retrospectiva. (nota: si bien esta es la terminología propuesta por Scrum no estoy hablando particularmente de Scrum sino de desarrollo ágil en general)

Hay libros enteros dedicados a planning y también los hay dedicados a retrospectivas, pero no ocurre lo mismo con reviews. Al mismo tiempo he visto consultores/facilitadores colaborando en reuniones de planning y retrospectiva (retrospectivas sobre todo) pero no ocurre lo mismo con las reviews.

Curioso ¿no?. ¿Simple casualidad? Mmm, no creo.¿Será que la review es menos importante? No ¿será que la review es más fácil? Mmmmm, no creo. @egutter me dice que es porque la review es anterior al desarrollo ágil y al mismo tiempo la agilidad no ha introducido grandes cambios en esta reunión, como si lo ha hecho en la planning. Esta justificación me resulta bastante convincente.

Mientras escribo estas líneas caigo en la cuenta que en mi propio libro hay capítulos dedicados a planning y retrospectivas pero no dedicado a reviews, ¡Ja!

Personalmente la mayoría de las veces que he asistido a reviews ajenas (o sea de proyectos/equipos en los que no estaba involucrado) me fui decepcionado. Reuniones empezando tarde, demostraciones inentendibles (o directamente fallidas), usuarios/stakeholders ausentes, incluso miembros del equipo ausentes, pérdida del foco de la reunión, horario de finalización incierto, entre otras cuestiones.

Para mi la review es una reunión clave. O tal vez LA REUNION CLAVE. En la planning el equipo asume un compromiso pero es en la review donde se ve el resultado de ese compromiso. Es en la review donde tenemos la posibilidad de deleitar a nuestros stakeholders. Es en la review donde se juega la continuidad del proyecto.

Es por esto que en mi materia de ingeniería de software dedico una clase para que mis alumnos entiendan la importancia de esta reunión y sepan como prepararla y guiarla apropiadamente. Al mismo tiempo como parte de la materia lo alumnos tienen que realizar al menos 4 reviews y su desempeño en esas reviews tiene impacto directo en la aprobación de la materia.

Continuará…

Sobre el TP final de algo3 (2015-1)

A fines de mayo lanzamos el TP final de Algo3. En el curso de los miércoles tenemos poco más de 30 alumnos repartidos en equipos de 3 integrantes, cada equipo con un docente tutor. En mi caso soy tutor de 4 equipos.

Este cuatrimestre el trabajo prácticos se llama AlgoCraft y como su nombre lo sugiere es una variante del clásico juego StarCraft.

Como de costumbre desde el comienzo del trabajo práctico configuré un Jenkins para que los alumnos pudieran hacer integración continua. Esto también me permite tener métricas de su trabajo. Este cuatrimestre incorporé PMD al conjunto de tareas ejecutadas en el proceso de integración continua. PMD es un herramienta que entra en la categoría de “Linter” y como tal, lo que hace es analizar el código fuente realizando un conjunto de verificaciones relacionadas al cumplimiento de estándares y buenas prácticas de programación del lenguaje en cuestión.

algo3_20151