¿Quién define los procesos de software?

No es fácil encontrar procesos de desarrollo de software que parezcan ser diseñados por personas que desarrollen software, al menos en mi experiencia personal. Sin embargo, me he cruzado con el caso prácticamente inverso: procesos diseñados por personas que no les atraía en lo más mínimo desarrollar software o aprender algo sobre el tema.

En estos casos, la línea de pensamiento parece ser la siguiente: "Aquellas personas a las que nos les atrae desarrollar software (diseñar una solución, escribir código, testearlo) pueden dedicarse a otra área, como la definición de procesos". De esa manera, se puede evitar la necesidad de conocer y dominar aspectos que hacen posible la construcción de software, porque se puede cubrir el vacío con conceptos abstractos o genéricos como variación, estabilidad de proceso, causas especiales y causas comunes de variación, entradas, herramientas o salidas.

Para hablar sobre estos temas no hace falta conocer de software. De hecho podríamos hablar de manufactura de tornillos y aplicar estos mismos conceptos. Por esta razón, considero que la aplicación directa de estos conocimientos generales carecen de gran valor si no tienen detrás un análisis que busque mejorar una realidad en un ámbito definido. Muchas veces este análisis no es realizado, o las personas que lo hacen no tienen los conocimientos necesarios para hacerlo adecuadamente. Esa situación indefectiblemente conlleva inconvenientes.

Philip Armour analiza este y otros problemas relacionados a los procesos de desarrollo de software en The Laws of Software Process: A New Model for the Production and Management of Software. Tiene varias ideas interesantes para tener en cuenta:

En muchos casos, los procesos [de desarrollo de software] son ideados por ingenieros de proceso, pero frecuentemente ellos no son las personas que están creando el sistema. Estos ingenieros incluso son separados para definir estrictamente el proceso. Los desarrolladores están demasiado ocupados haciendo el trabajo y, a veces, evitando aplicar el proceso. Cuando un proceso es desarrollado por personas que de hecho no lo utilizan, pasan varias cosas:

• Los ingenieros de proceso pierden de vista la aplicación detallada que hacen un proceso valioso.
  
• Sin tener acceso al detalle, ellos están forzados a trabajar mas a un nivel meta, que es fácil para ellos porque no tienen que desarrollar real conocimiento del dominio dentro del proceso.
  
• Como ellos usualmente no aplican el proceso que están ideando, pueden perder la habilidad de validar si el proceso es realmente útil.
• Casi inevitablemente, crece la mentalidad de que si el proceso es bueno, entonces mas proceso debe ser mejor.
• El proceso toma importancia para estas personas, no por el valor que trae, sino porque es la razón por la cual tienen trabajo.
• La definición del proceso es dejada a un nivel descriptivo, en forma de libro, no de manera ejecutable... Esto deja el trabajo real de hacerlo funcionar a los desarrolladores usando el proceso. Este es un lugar muy seguro para estar - para los ingenieros de proceso. Si el proceso funciona, el grupo de proceso puede reclamar el crédito; si no funciona, la culpa puede ponerse sobre los desarrolladores por no aplicarlo apropiadamente.

El arquitecto tambien implementa

Varias veces escuche la intención de algunos desarrolladores de focalizarse o crecer en su carrera profesional hacia una posición de Arquitecto, porque escribir código no era de su interes o no les parecia una tarea muy desafiante.
Ese pensamiento me resulta extraño, porque no creo que un arquitecto puede cumplir bien su rol si no escribe código.

Jim Coplien y Neil Harrison escriben en su libro Organizational Patterns of Agile Software Development el patrón que llaman "El arquitecto tambien implementa":

Demasiados arquitectos de software limitan su pensamiento y dirección a abstrascciones, y una abstracción es una forma disciplinada de ignorancia. Demasiados proyectos fallan por “detalles” de performance, sutilezas de APIs,e interconexión de componentes – o, a lo sumo, descubren este tipo de problemas tarde.
...Mas alla de aconsejar y comunicarse con los desarrolladores, los arquitectos deben participar tambien en la implementación.
El Arquitecto debe estar unido organizacionalmente con los desarrolladores y debe escribir codigo él mismo.

Concuerdo cien por ciento. La mejor forma de orientarse hacia una posición de liderazgo técnico es dominar los aspectos de implementación y no sólo focalizarse en grandes abstracciones.

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.