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.