Libro sobre Inspecciones de Código

SmartBeart, una empresa que desarrolla productos para realizar inspecciones de código, publica en su sitio capítulos de un libro sobre inspecciones. En el libro obviamente existen contenidos asociados a los beneficios de sus herramientas pero no por esto deja de tener algunos puntos interesantes.
Por ejemplo, se presentan algunos estudios sobre inspecciones de código donde se intenta demostrar que las reuniones para concretar las inspecciones de código son innecesarias y hasta perjudiciales para la relación costo/beneficio de la práctica.

"Las inspecciones no necesitan ser en persona

Para el lector sensible acostumbrado a inspecciones formales institucionales descendientes de la herencia de Fagan, Gilb, y Wiegers, esta afirmación es herejía. Tradicionalemente la reunión de inspección en persona dirigida por un moderador es considerada el eje de un proceso exitoso. La sinergia que surge de una reunión dirigida apropiadamente produce resultados que no pueden ser obtenidos por ningún inspector individualmente, aún con entrenamiento.
En los últimos 15 años ese efecto ha sido cuestionado en muchos estudios y desde muchas perspectivas. Multiples conclusiones sobre este punto son claras desde todos los estudios en este trabajo y en muchos otros."

Best Kept Secrets of Peer Code Review de Jason Cohen

Planificación Detallada Atractiva e Inservible

Hace ya bastante tiempo que trabajo liderando proyectos de desarrollo de software, no desde una perspectiva técnica como en el pasado. Esa es la razón por la cual el contenido de este sitio girara en torno a temas como planificación, estimaciones, pero manteniendo mi interés en la importancia de las personas en nuestra actividad.

En esta ocasión la motivación de estas lineas se relaciona con situaciones que se repiten al querer planificar y realizar el seguimiento de proyectos medianamente complejos.
Considerando que estoy en el medio de mi preparación para el examen de certificación PMP y trabajando en una organización CMMI nivel 5 es difícil evitar algunas prácticas, como la planificación detallada y el uso de herramientas como los diagramas de Gantt.

En esencia, existe una idea generalizada que la manera correcta de planificar un proyecto es identificar paquetes de trabajo, identificar actividades, identificar las dependencias entre las actividades, estimar las actividades y armar una planificación detallada donde el camino crítico se verá nítido y radiante como el sol de una mañana despejada.

Completando estos pasos, periódicamente se puede revisar el avance en cada actividad y ver si existen retrasos o no, medir el impacto de retrasos en dependencias externas y conocer las fechas de fin. Es algo que todos esperan ver, mis gerentes, mis clientes, mis compañeros. No planificar así en mi empresa es como ir con un guardapolvo rosado el primer día de clases en una escuela nueva.

Es por eso que trabajo para que mis planes se vean bien: para evitar la condena social... bueno, y por otras razones. El punto es que con dedicación y empeño logró que la planificación de mis proyectos luzca así:

Actividad A. 3 días. Pepe
Actividad B. 1 día. Paco
Actividad C. 2 días. Paco

con una precendencia

A -> C
B ->

El plan es prolijo y ordenado, la vida es bella, mis compañeritos me van a aceptar...

Pero cuando me tengo que sentar a ver el avance, mi plan se desmorona. La realidad es que al primer día se ejecutan 3 actividades en paralelo, como una dependencia externa no se cumple se decide reasignar gente a una tarea B', se crea una nueva actividad para investigar formas de resolver los problemas que surgieron (actividad D), alguien decide partir su actividad en dos (actividad A1 y A2) y la tarea B ya no tiene sentido.

Esto me intranquiliza, mi plan está desordenado e inservible. En estos casos me siento y actualizo nuevamente las actividades, dependencias, asignaciones y estimaciones en mi sofisticada herramienta de gestión de proyectos. No es algo sencillo pero después de un poco de trabajo, mi diagrama de Gantt luce muy bien nuevamente. No puedo evitar que una sonrisa se me escape en ese momento. Me gustaría imprimirlo en colores y pegarlo en mi box. Pero lo triste es que lo mismo vuelve a suceder.

Con la investigación de la actividad D se descubrió una forma de hacer todo de manera más sencilla pero todas las actividades anteriores no sirven, además hay que sumar una persona adicional que necesita dos semanas de entrenamiento y Paco se enfermo un par de días por lo que hay que quitar un requerimiento del alcance predefinido.

Entonces actualizo la planificación otra vez... y una vez más. Pero cuando lo mismo se repite por cuarta vez, un destello de lucidez cruza mi cabeza como un rayo encantado:
"¿No estaré haciendo algo mal? ¿No será que esta planificación no sirve?"

Pienso que es momento de sacar de la biblioteca algunos libros y refrescar algunos conceptos: Scrum, Agile Project Management, burn-down charts, planificación en extreme programming, lean development.

¿De qué manera se puede cambiar la manera de gestionar proyectos en una organización algo "rígida" como la mía? Bueno, definitivamente no tengo la respuesta a esa pregunta, pero buscarla puede ser entretenido.

Entrega vs. Conformidad

"Demasiados administradores de proyectos, demasiados miembros de oficinas de proyectos, demasiadas organizaciones han derivado hacia la conformidad como su, si a veces implícito, foco primario. Las actividades para la conformidad, a lo sumo, intentan mitigar el riesgo de errores, fraude, desempeño pobre, y excesos financieros. Los managers quieren reportes. Los contadores quieren números. Los auditores quieren firmas de aprobación. Las agencias gubernamentales quieren documentos. Los grupos de estándares (ISO, SEI y otros) quieren pruebas de conformidad. Los departamentos de Legales quieren todo. Fallar en diferenciar entre entrega y conformidad resulta en un trabajo de conformidad cada vez mayor - produciendo documentos para reguladores, abogados y management - mientras completar productos cae a una segunda prioridad"

"Prueba la siguiente encuesta en tu organización, pero prepárate para una sorpresa. Pregunta a todo el personal o los miembros de tu equipo de proyecto, incluyendo managers, cuánto tiempo emplean ellos haciendo tareas de desarrollo o ingeniería - cuánto tiempo emplean ellos generando valor para cliente? Cuantas de sus iniciativas de "mejora" (CMM, ISO, Six Sigma, TQM, BPR) sólo han agregado capa tras capa de formularios, procedimientos, reuniones, y aprobaciones a equipos tratando desesperadamente de producir algo útil?"

Agile Project Management de Jim Highsmith

Idea valiosa 3: Contar, Computar, Juzgar

Por lo general, los libros de Steve McConnell valen cada peso (o dólar) invertido. Software Estimation: Demystifying the Black Art no es la excepción. Si tienes la posibilidad de comprarlo, no lo dudes.

Esta idea valiosa sale de este libro y está relacionada a las estimaciones.

Permitanme tomarme la libertad de sacarlos del ámbito del software violentamente para ilustrar la idea. Cualquier argentino no vegetariano ha participado de un promedio de un asado por mes de vida aproximadamente. Organizar el asado requiere que alguien haga las compras, alguien encienda el fuego, etc. Aunque esto parezca difícil de creer para el grupo de personas que siempre llega al asado cuando todo está listo, todos estos detalles organizativos mundanos no los traen los Reyes Magos o un hada madrina, hay gente que lo hace. Pongámonos en la situación de quien hace las compras.

- Mmm, ¿cuánta carne tendré que comprar para que no sobre mucho y no falte? - se pregunta, cuidadoso del dinero ajeno. - 10 kilos es mucho y uno muy poco. Mmm, supongo que 5 kilos más o menos, aunque parece mucho. Nunca fui a un asado con tanta carne. Mejor 4 kilos que no parece tanto. Si, voy a comprar 4 kilos.

¿Es esta la mejor manera de estimar cuanta carne hace falta para el asado? ¿Cuál es el detalle que está faltando en este cálculo? ¡Por supuesto! ¡La cantidad de personas! Nunca se puede saber si la carne es mucha o poca si no sabemos cuantas personas van a comer.

Esto es realmente intuitivo para la gente de estas tierras con abundancia de vacas, y no hace falta certificación del PMI para que alguien lo haga. Puedo estar seguro que uno le pregunta a 10 personas en la calle, doctores, taxistas, albañiles, profesores de educación física, cañillitas, “¿Cuanta carne compro para el asado?” y todos responderán con el teorema cárnico elemental: “Papá, calculale medio kilo de carne por pera”.

Eso es contar, y es algo fundamental para estimar. Por alguna razón no resulta tan intuitivo a la hora de estimar cuestiones relacionadas al software. Muchos tenemos la tendencia a saltar este paso esencial, queremos comprar la carne para el asado sin saber cuanta gente va.

¿Pero qué podemos contar cuando estimamos software? Considerando que “el definidor más importante en una estimación de software es el tamaño del software siendo construido porque hay más variación en el tamaño que en cualquier otro factor.”, la respuesta a la pregunta es “encuentra algo para contar que esté fuertemente relacionado al tamaño del software que estás estimando”. Casos de uso, ventanas, clases, páginas web, puntos de función, entre otros.

Bien, ya contamos. ¿Cómo sigue la historia? Para el asado es simple, multiplico la cantidad de personas por 0.5 y obtengo la cantidad de kilogramos de carne a comprar. Cambiemos de plato para hacerlo más entretenido, quiero hacer arroz para 80 personas. ¿Cuanto arroz compro? ¡Aja!, aquí es donde tenemos que computar, para convertir la cuenta (80 personas) en estimaciones (kilos de arroz). Para ello hay que saber cuanto arroz puede comer una persona. Yo no lo sé, ¿250 gramos tal vez?

Entran en escena entonces, los datos históricos. El medio kilo de carne que se calcula por persona para un asado es un dato histórico que he podido confirmar personalmente. En el caso del software los datos históricos nos dirán, por ejemplo, que cada ventana requiere aproximadamente 300 líneas de código Java. Entonces necesitaremos otro dato histórico que nos indique el esfuerzo requerido para escribir esas líneas es de, por ejemplo, 1 staff/month para una empresa muy madura y posiblemente bastante menos para una empresa de software “artesanal”. (Desconozco otros ámbitos donde las fábricas tarden mucho más que los artesanos en completar un producto).

¿Y que pasó con juzgar? Este es el último recurso. Si tenemos que preparar sushi para 200 personas y no tenemos idea de cuanto pescado comprar, bueno, el consejo de un primo que tiene un amigo con parientes japoneses que nos dice que el pescado crudo es más llenador que el pollo puede ser útil para estimar, pero...

En definitiva para estimar hay que contar, computar y como último recurso juzgar.

Sweet and simple.

Procesos útiles

El tema de hoy tiene que ver con procesos de desarrollo de software.
En Agile Software Development, Alistair Cockburn comenta que uno de los criterios que él utiliza para considerar exitosa la aplicación de una metodología en un proyecto es que las personas del proyecto piensen que trabajarían de la misma manera otra vez. Por otro lado, Scott Berkun en The Art of Project Management lista los atributos de buenos procesos, aquellos que benefician la ejecución de un proyecto e incluye el siguiente:

“Las personas impactadas por los procesos están a favor de ellos. A las personas les gustan los procesos útiles. Un buen proceso sera visto como algo deseable por aquellos que lo necesitan. Si se está proponiendo un nuevo proceso que impacta a testers y programadores, y el proceso es valioso para el proyecto, no debería ser muy difícil convencerlos de probarlo.”

Mi experiencia en proyectos utilizando procesos definidos no cumplen esos criterios en general.
Quiero decir que las personas no trabajarían de la misma manera si pudieran elegir y en gran parte no estaban a favor de los procesos al momento de aplicarlos. Déjenme plantearlo de manera más personal: hoy estoy trabajando de una manera que en esencia no volvería a utilizar si pudiera elegir y, en muchas ocasiones, no estoy a favor de los procesos que debo aplicar.

Detallando un poco más, me refiero a procesos que no agregan valor, a la generación de documentación que nadie lee, a la producción indiscriminada de evidencia con poco sentido practico, a los pasos que pretenden brindar seguridad sobre los resultados y mas bien obstaculizan su concreción. Mi sensación es que mi experiencia no es aislada, parece ser más la regla que la excepción. Si esto es así, ¿qué es lo que está mal entonces?

Cuando se usan procesos definidos en una empresa, existen personas que se encargan de definirlo. Calidad, Proceso, Organización y Métodos son nombres usualmente asignados a este tipo de grupos. Es raro que estas personas dediquen su tiempo a crear procesos para torturar al resto de la gente. Todos apreciamos el respeto de nuestros compañeros y poseemos un sentido de logro. Por más incómodo, incoherente o inadecuado que parezca un proceso, alguien en algún momento lo creo con objetivos valorables y con buenas intenciones.

Mi impresión es que una de las razones de estos males es que la ejecución de los proyectos de creación de procesos adolecen de muchos de los problemas de los proyectos de software mal gestionados. Se define una fecha de fin para la definición del proceso, posiblemente atada a una auditoria o assesment que permita una certificación o evaluación de una norma de calidad. A las personas encargadas de llevarlo adelante les encantaría poder charlar con las personas que ejecutan proyectos para relevar necesidades, estudiar distintas herramientas o técnicas para incluir en el proceso, investigar practicas aplicadas en otros lugares, elaborar propuestas para ver como será este nuevo proceso.

Pero sucede que las personas que debían hacer todo este trabajo tienen otras asignaciones, las personas de los proyectos no tienen tiempo para discutir sobre estos temas y la fecha de entrega se acerca. Así los planes para hacer procesos útiles, valiosos y prácticos se diluyen, y se ve reemplazados por un esfuerzo para generar documentos para tapar huecos en el proceso que puedan afectar los resultados de la auditoria o assesment.

Es como esa pequeña funcionalidad implementada contra reloj que requiere que el usuario haga 3 clics adicionales en una lugar completamente inesperado, y que internamente requirió agregar el metodo CalcularInteres en la clase ConexionBaseDatos y la declaración de tres variables globales. Uno siente que un cosquilleo recorre la espina dorsal cada vez que piensa en como soluciono el problema pero es lo que se podía hacer con el tiempo disponible.

De todas maneras siempre hay tiempo para mejorar. Mientras esas mejoras llegan, uno debe lidiar con una realidad algo frustrante, muchas veces llamada madurez.

Idea valiosa 2: cuantificación de incertidubre

La gestión de riesgos es un tema que parece simple y no muy revelador a primera vista. En lo personal, debo confesar que la presentación tradicional sobre gestión de riesgos no me resulta muy interesante. Resumiendo, existe riesgo cuando existe la posibilidad de perdida o daño. Gestionar los riesgos en un proyecto significa hacer una lista de esas posibilidades, darles un valor de ocurrencia, un valor de impacto y definir planes de acción para mitigarlos. Bueno, resumiendo bastante.

Pero existe un enfoque para analizar los riesgos que me resulta muy práctico y valioso. Muchos de los riesgos de un proyecto convergen en un hecho concreto: no se finaliza el proyecto a tiempo. Puede ser que las personas no estaban capacitadas como se esperaba, que la funcionalidad a desarrollar fue más difícil de lo esperado, que componentes externos se entregaron tarde o cosas por el estilo. Pero todo termina en que el equipo de proyecto dijo que iba a tardar 3 meses, y en la noche del último día se da cuenta que no termino. Ese es el gran resumen de los riesgos de un proyecto de software.
Este concepto está muy bien presentado en el libro Waltzing with Bears: Managing Risk on Software Projects de Tom DeMarco y Timothy Lister. Es lo que ellos llaman la cuantificación de la incertidumbre. Y ponen un ejemplo muy claro. Supongan que llamamos a un consultor para que analice nuestro proyecto y nos dice:

“Escucha, simplemente no hay chance de terminar esto antes de principio de año – cero. La fecha más probable para entregar un producto aceptable es inicio de abril próximo. Aún esta fecha no es tan segura. Probablemente no quieras comunicar ninguna fecha antes del primero de mayo. Al menos con una fecha en mayo o más tarde tienes una probabilidad de cumplir mejor que cincuenta-cincuenta. Si quieres una fecha donde no tengas posibilidad de entregar tarde, vas a tener que irte hasta fines de diciembre próximo.”

Representando la situación gráficamente, obtenemos un diagrama como este:

Este es un diagrama de riesgo donde el area bajo la curva representa la probabilidad acumulada de finalizar en una fecha dada. Si un tercio del area total se acumula a la izquierda del 1 de abril, la probabilidad de terminar antes de esa fecha es 0.33. El area total bajo la curva es 1.

Este es un gráfico revelador porque asocia el riesgo a las fechas. Uno puede observar como aumenta el riesgo a medida que las fechas son mas agresivas. Esto parece muy natural pero no lo es tan comun encontrar gente que actúe en consecuencia. Siempre vemos que la persona que pide la fecha de estimación intenta obtener la fecha más cercana posible, como si esto no incrementara el riesgo o como si las consecuencias no lo afectaran. Pero esa no es la realidad. En nuestro caso, si la persona con poder de decisión sobre el proyecto define que la fecha a comunicar será el 1 de abril, entonces debe estar preparado para entregar tarde, porque existe el 66 % de probabilidad que así suceda. ¿Está realmente dispuesto a afrontar ese riesgo?
DeMarco y Lister utilizan el gráfico para explicar un aspecto repetido hasta el cansancio en los proyectos de software:

“Una queja común que managers comparten con nosotros es que 'la fecha más temprana mencionada automaticamente se transforma en la fecha de entrega'. Publicar el hallazgo del consultor que 'no hay posibilidad de entregar antes de principio de año' puede ponerte en una posición donde el 1 de enero es entonces fijada con concreto como la fecha de entrega. Pero en el diagrama de riesgo, el area bajo la curva a la izquierda del 1 de enero es esencialmente cero. Esto dice que la posibilidad de terminar antes de la fecha de entrega es nula. La patología de definir una fecha de entrega como la fecha más temprana mencionada garantiza esencialmente que la fecha no se cumplirá.”

Idea valiosa: el cono de incertidumbre

Mucho del material que leo usualmente tiene pequeñas ideas que me hacen pensar. Tal vez es una frase, un párrafo, un concepto, algo que hace que el tiempo invertido en leer valga la pena. Hay veces que la simpleza de esas ideas me entusiasma.
Me parece que es una iniciativa útil comenzar a incluirlas en el sitio. No son genialidades necesariamente, algunas tal vez ya son tan conocidas que suenan más bien a sentido comun o conocimiento general, pero en algún momento, para alguna persona, han sido de gran valor. Y tal vez lo sigan siendo para algún lector. No esperen la fórmula de la Coca-Cola, solo pequeñas ideas.
Basta de presentaciones, comencemos a revisar estas ideas valiosas. La primera: el cono de incertidumbre:

Temprano en mi carrera profesional comencé a tener contacto con las estimaciones y con peticiones completamente inesperadas relacionadas con estas:

- ¿Cuánto llevaría hacer un sistema de contabilidad típico? - me preguntó mi jefe una vez al pasar, casi como quien habla del clima.
- Ehh...¿qué?
- Si, un sistema de contabilidad sin nada extraño, lo básico. ¿Cuanto tardaríamos en hacerlo?
- Mmm, no sé... ¿Vamos a hacer uno? Digo, ¿quien va a trabajar en eso? - preguntaba yo desorientado, sin mencionar que no tenía (ni tengo) la menor idea de qué es un sistema de contabilidad típico.
- No, eso no importa. Considera que podrías contar con los recursos que hagan falta. La pregunta es ¿cuanto tiempo nos llevaría hacerlo?
- Aja... Eh, pero... eh ¿no sé?

Si, lo admito, no fue uno de los momentos de mayor lucidez en mi carrera. Sólo faltaba que se me cayera un hilo de baba por la comisura de los labios para completar la cara del perfecto bobalicón.
Esta petición me resultaba tan inesperada y desconcertante que era imposible para mí dar respuestas medianamente lógicas. Simplemente no entendía de que me estaba hablando. ¿Qué respuesta podía dar?

Steve McConnell presenta en Rapid Development, adaptado de Boehm, el cono de incertidumbre:

"Para cualquier conjunto dado de características, la precisión en la estimación puede mejorar sólo de la misma manera que el software mismo se torna más refinado."

Este gráfico es simple. Cuando estamos definiendo el producto inicialmente las estimaciones de esfuerzo y costos pueden ser ir desde 0.25x a 4x. Estas estimaciones sólo pueden ir mejorando a medida que se conoce más sobre el producto. Así, las diferencias van disminuyendo hasta converger en un punto al final del proyecto.
La calidad de las estimaciones esta atada en gran parte a la información que se tenga sobre el producto a estimar. Con poca información, las estimaciones pueden tener grandes desviaciones.
Considerando el gráfico, para un producto que requiere 10 staff/months para desarrollar, en la etapa inicial de definición, las estimaciones optimistas pueden decir 2,5 meses y las pesimistas 40 meses.
Esa era la respuesta para mi jefe: "El sistema de contabilidad típico le puede llevar a una persona entre 2 meses y 3 años. No lo digo yo, lo dice Barry Boehm."