Algunos links interesantes

En las ultimas semanas he leído algunos artículos y presentaciones que capturaron mi atención, los cuales coinciden en un aspecto: se animan a criticar prácticas o modelos muy aceptados.

Estos son los links:

• Are We There Yet? de Johana Rothman. Desaconseja el uso de la técnica de valor ganado en proyectos de software.
  

"No he trabajado en ningún proyecto donde fuese posible calcular el valor ganado (earned value). En mi experiencia, el valor ganado es demasiado frecuentemente una medida difusa para proyectos de software."

• Questioning Earned Value Management (EVM) on IT projects de Scott Ambler. Desaconseja el uso de EVM en proyectos de IT.
  
  "En teoría, EVM suena como una gran cosa. Estas ganando valor de todos modos, y ¿quién puede discutir eso? Sin embargo, en la práctica en el mejor de los casos es un eufemismo para controlar los costos presupuestados gastados y en el peor de los casos es simplemente una justificación para buracracia."
  
  
• Could the Software Engineering Institute be Wrong About Statistical Process Control? de Bob Raczynski. Presentación realizada en Systems & Software Technology Conference (SSTC) 2007.
  
  En este caso el título es muy descriptivo. El autor se pregunta si el control estadístico de procesos (CEP) es apropiado para organizaciones de desarrollo de software. Su respuesta es no.
  El CEP tiene gran importancia en el modelo CMMI y es algo que personalmente me intriga. Hace mas de dos años gestiono proyectos en una organización CMM (y luego CMMI) nivel 5, y debo ser sincero. No veo el valor de aplicar CEP en nuestros proyectos. Puede ser que aún no lo comprenda, pero si mañana debo dejar de aplicarlo, no lo voy a extrañar.
  
  "Bueno, si usted aplica CEP a procesos de desarrollo de software, puede que ocasionalmente tenga suerte e identifique una variación con causa asignable a pesar de los amplios limites de sus gráficos de control, areas desiguales de oportunidades, y procesos constantemente cambiantes.
  De las variaciones de causas asignables que logre detectar, ocasionalmente puede tener suerte y realmente peda identificar una de las causas de esa variación.
  De las muy pocas causas de variación que usted pueda identificar, una de ellas podría ocasionalmente ser de una naturaleza que puede realmente ser removida con cierta persistencia.
  Aún así, su sistema en general difícilmente será más predecible.
  ¿Es ese el mejor uso de sus recursos limitados?"
  
  
• Software Data Violate SPC’s Underlying Assumptions de Bob Raczynski and Bill Curtis. (requiere subscripción de IEEE). Aquí los autores cuestionan el uso de gráficos de control para realizar control estadístico sobre procesos de software.
  
  "Nosotros pensamos que los supuestos detrás de los gráficos de control son tan fuertemente violados en los datos de software que su valor para entender y gestionar la variación es severamente disminuida...
  Desafortunadamente, el foco desproporcionado para controlar estadisticamente procesos y calidad de software ha desviado la atención de otros métodos estadísticos que podrían proveer mucho mejor entendimiento y predecibilidad de las causas de variación afectando al proceso de software."
  
  
• Can a Manufacturing Quality Model Work for Software? de Shari Lawrence Pfleeger (requiere subscripción de IEEE).
  

  "¿Debe ser el modelo de manufactura Six Sigma aplicado al software? En una palabra, no. Aunque el software de alta calidad es algo bueno, hay al menos tres razones por las cuales el modelo Six Sigma no tiene sentido para el software."

Como cierre, incluyo unas palabras de Alistair Cockburn en el grupo de Yahoo scrumdevelopment:

"En mis 30 años en el negocio, industria, investigación y algo de gobierno, nunca vi una matriz de trazabilidad redituable."


Cuando algo es generalmente aceptado, el camino más fácil es tomar por sentado sus beneficios y defender sus aspectos positivos.

En lo personal no me agrada ese camino.

Valoro cuestionar y escrudiñar cada práctica, analizar y entender cada concepto, pensar y aprender, no simplemente repetir.

Cambiando de perspectiva (3): Libro recomendado

Hay muchos libros de gestión de proyectos que pueden ser útiles para aquellas personas con roles técnicos que quieren comenzar a tomar responsabilidades de gestión.
Uno que puedo recomendar especialmente es Manage It: Your Guide to Modern, Pragmatic Project Management de Johanna Rothman.
La particularidad de este libro es que no intenta difundir un enfoque de gestión de proyectos determinado. Presenta técnicas, conceptos y prácticas de gestión de proyectos siempre como opciones posibles que pueden ser aplicadas con mayor o menor exito en distintos contextos.
Por ejemplo, al discutir sobre maneras de obtener información de progreso del equipo propone:

• reuniones diarias al estilo Scrum (daily standup meetings),
• reuniones one-on-one,
• emails de reporte semanal,

listando ventajas y desventajas de cada técnica en equipo grandes o pequeños, y según el ciclo de vida utilizado.
Al explicar un ciclo de vida secuencial o en cascada dice:

"...si estas haciendo un proyecto, de pocas personas donde los requerimientos son claros (como la corrección de un release previo), este ciclo de vida puede ser todo lo que necesitas."

Siempre están presentes las aclaraciones sobre la aplicabilidad de cada concepto planteado en distintos entornos.
Otra característica del libro es la presencia de consejos y tips basados en la experiencia.
Personalmente he caído en varios de los errores que estos consejos tratan de prevenir.
Este aspecto es especialmente evidente en el capitulo 6, "Recognizing and Avoiding Schedule Games". Aquí presenta varios juegos (peligrosos) que se presentan durante la planificación y ejecución de un proyecto.

Por ejemplo, "Schedule Chicken":

"Schedule chicken ocurre más frecuentemente en reuniones de estado circulares. El project manager le pregunta a cada persona como va con su trabajo. Todos dicen que están avanzando según lo planificado. En realidad, nadie lo está haciendo. Todos están esperando que otro parpadee y admita que él o ella está atrasado. Y raramente alguien admite que él o ella está atrasado hasta que es muy tarde."

Luego presenta opciones para evitar esta situación o como salir de ella.

Es tragicómico ver los errores propios tan bien reflejados en un libro y es de gran utilidad poder leer sobre algunos nuevos antes de cometerlos.

En fin, 350 páginas de lectura amena recomendables para agregar a la biblioteca.

Cambiando de perspetiva (2) - Retroalimentación

Continuo con la serie de artículos referidos a facilitar la transición de un puesto técnico a uno de gestión de proyectos.


Una de las grandes diferencias que involucra pasar de un rol técnico sin mayores responsabilidades de coordinación a uno de gestión de proyectos es el tipo de actividades que uno debe realizar para agregar valor. Cuando uno gestiona proyectos o coordina equipos, el aporte y los logros dejan de depender mayoritariamente del resultado directo de las acciones personales.

Uno debe ser el facilitador que permita a un equipo funcionar mejor, producir más, ser mas efectivo. Y para lograr esto uno depende, bueno, de ese equipo.
Si se esta a cargo de un equipo de 10 personas de las cuales 8 de ellas no rinden lo esperado, no servira de mucho que uno como lider de proyecto se quede un par de horas más para avanzar el trabajo.

En estas posiciones toma mayor relevancia la comunicación con el equipo, la influencia sobre los otros, la definición clara de objetivos y la retroalimentación brindada a otros sobre su trabajo.
Ya he hecho referencia a este tema en el pasado pero creo que tiene suficiente relevancia para repetirlo e incluirlo en esta serie.

Dar retroalimentación es esencial y hacerlo bien no es una habilidad natural e innata. Hay muchas maneras de hacerlo mal.

Esther Derby dice que la retroalimentación “es información que le damos a otra persona cuando queremos que comience, termine, continué, o cambie algún comportamiento.”

How to Talk About Work Performance: A Feedback Primer, Esther Derby

Es así como se logra conducir e impulsar un equipo hacia su objetivo y ayudar a cada integrante a brindar el mejor aporte para alcanzarlo, dando retroalimentación. Segun Esther Derby se debe:

• Hablar del tema tan rápido como sea posible


• Proveer ejemplos específicos


• No depender de la telepatía:
  


• Verificar que existe acuerdo en los datos


• Solicitar un cambio

Pueden encontrar más en el artículo de Esther. Vale la pena leerlo. Describe una actividad basica para una persona que coordina un equipo.

Cockburn y la analogía de la fabrica

Es muy común ver el uso de analogías entre el desarrollo de software y la fabricación de productos. Por ejemplo, cuando se considera que se puede tener una línea de producción de software con trabajadores haciendo actividades acotadas y simples. Un analista escribe un requerimiento, un arquitecto lo diseña, un desarrollador edita un archivo XML que es luego interpretado por un framework mágico que le da forma a una aplicación empresarial. Por último un testeador sigue mecánicamente los pasos detallados de un caso de prueba para comprobar que no entiende cual es el resultado esperado. Desarrollo de software a la "Henry Ford".

Por suerte, últimamente también es frecuente escuchar hablar de las diferencias entre el desarrollo de software y la manufactura, y como estas diferencias invalidan cualquier aplicación de conocimientos de un ámbito hacia el otro.

Pero es posible que ninguna de estas posturas sea tan acertada. Lo más lógico es analizar las diferencias, identificar que cosas se pueden trasladar de la manufactura de productos al software y aprovechar los años de conocimiento que esta industria le lleva de ventaja al software.

Alistair Cockburn escribe What engineering has in common with manufacturing and why it matters tomando esa perspectiva con interesantes conclusiones.

Tambien vale la pena chequear los autores que lista al final del articulo, David Anderson y Tom & Mary Poppendieck.

Iterativo vs. Incremental

Los términos iterativo e incremental son actualmente muy utilizados a la hora de describir procesos de desarrollo de software. Pienso que existe cierto consenso generalizado con respecto a las virtudes de desarrollar software de manera incremental e iterativa. Sin embargo, no es tan claro cuál es el definición de cada uno y cuales las diferencias entre desarrollo iterativo y desarrollo incremental. Esto es claro cuando se considera la cantidad de veces que algunas personas tratan de explicarlo.
Alistair Cockburn ha hecho varios intentos y ahora agrega un nuevo artículo con este objetivo, además de agregar un resumen con varias referencias hablando sobre desarrollo iterativo, incremental y sus diferencias:

Incremental means adding, iterative means reworking
de Alistair Cockburn

Artículo recomendado para entender la diferencia entre desarrollo iterativo e incremental. No dejen de revisar las referencias del final del artículo.

Cambiando de perspectiva (1)

Es mi intención incluir material que pueda resultar interesante para otros en este espacio. Que es lo que puede ser interesante no me queda muy claro muchas veces y es así que pasa el tiempo sin nuevos contenidos. Sin embargo, ahora pienso que hay algo de mi experiencia que podría tener valor para otros.

Dejenme escribir algunas palabras sobre mi experiencia para poner todo lo que sigue en perspectica. Hace varios años me dedico al desarrollo de software. Más allá que siempre me gusto programar, desde el inicio de mi actividad profesional tuve un interés por el desarrollo de software desde una visión global, considerando ciclos de vida, fases, practicas diversas, relaciones humanas y varias cosas más. Debido a esto, o a pesar de ello, he ocupado roles de liderazgo y mis actividades se han ido formalizando en este sentido en el último tiempo. Es así que mi rol principal en los proyectos ya hace más de dos años es el de lider de proyectos.

Esta transición no se ha dado de manera planificada y preparada, más bien fui realizando nuevas tareas y adquiriendo los conocimientos a medida que los necesitaba. Es claro que las habilidades y conocimientos requeridos para gestionar un proyecto no son los mismos que para diseñar un framework o implementar un elegante algoritmo.

Este cambio de responsabilidades, de técnicas a de gestión, es algo que se repite en muchos colegas. Por eso pienso en contar sobre algunos articulos, libros, experiencias que me han ayudado en esta transición, y que pienso pueden ser útiles a quienes estén es situación similar.

¿Con que puedo empezar? La gestión de proyectos es muy amplia y es eso algo que la hace muy interesante.
Creo que un buen punto de partida es comenzar a entender que puede salir mal en un proyecto. Cuando uno gestiona un proyecto hay aspectos a considerar que van más allá de los tópicos técnicos en los que uno podría enfocarse en un rol más técnico.
Cuando el enfoque técnico era lo central de mi trabajo, me preocupaba por la factibilidad de un diseño, en que sea mantenible, en la complejidad o en analizar el balance entre costo y valor de cada alternativa técnica.
Desde la perspectiva de gestión los frentes se multiplican. Steve McConnell escribe sobre esto en Rapid Development, donde lista los errores clásicos categorizados en personas, proceso, producto y tecnología. Un capitulo del libro está disponible en internet:

Classic Mistakes Enumerated
http://www.stevemcconnell.com/rdenum.htm

Es una lista exhaustiva y muy útil.

Como ven en el título, esta es la primera entrega de una serie de artículos relacionados a este cambio de perspectiva. Más artículos en breve.

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