Entrevista: Walker Royce

Walker Royce es Chief Software Delivery Economist en IBM. Él nos comparte su visión sobre cómo podemos administrar proyectos de software de forma más efectiva.

Estamos en la transición hacia una era de cómputo pervasivo y de "sistemas de sistemas". ¿Podemos crear estos sistemas usando las mismas estrategias que antes o necesitamos pensar diferente sobre cómo desarrollamos software?
Creo que sí se requiere aplicar una estrategia diferente a la tradicional. Sin embargo, creo que ya llevamos cerca de diez años pensando diferente sobre el desarrollo de software, es solo que esto no ha permeado a lo largo de toda la industria.

¿Qué cambios debemos hacer a nuestros procesos de desarrollo de software?
Algo importante del tipo de los sistemas de software que estamos desarrollando (y desarrollaremos en el futuro) es que la mayoría de su valor no está en los componentes de software individuales, sino en su integración con otros sistemas. Si el valor está en la integración, entonces seguramente también es ahí donde están el grueso de los riesgos e incertidumbre. Nuestra estrategia para construir software debe tener en cuenta esto; si realmente creemos que la mayoría del valor está en la integración, entonces el ciclo de vida que utilicemos para crear software también debe dar un mayor énfasis a la integración. Teniendo esto en cuenta, creo que deberíamos realizar nuestras pruebas de integración ántes de las pruebas unitarias, sé que parece raro pero es posible hacerlo. Este simple cambio —pruebas de integración antes de pruebas unitarias— sirve para desencadenar muchos de los ajustes que necesitamos hacer a nuestros procesos de desarrollo de software.

¿Cómo se distingue la ingeniería de software de otros tipos de ingeniería?
Las disciplinas tradicionales de la ingeniería, como la mecánica o la civil, están basadas en leyes de física y siglos de experiencia. En el caso del software, no tenemos eso. La creación de soluciones de software no se basa en leyes inmutables, sino en la creatividad y talento del equipo de desarrollo; así que carecemos de límites bien definidos. La principal consecuencia de esto es que el desarrollo de software involucra una gran cantidad de incertidumbre. En ese sentido, el desarrollo de software se distancía del resto de las disciplinas de ingeniería y se acerca más a disciplinas creativas, como por ejemplo la producción de películas. En ésta última se ensambla un equipo con el mayor talento disponible para que colaboren y generen propiedad intelectual valiosa; no se sabe a ciencia cierta si algo le gustará a la audiencia, o como se desempeñará un actor con cierto papel, o cual será la secuencia de escenas más adecuada; hay pocas métricas de calidad que sean útiles y confiables, y no puedes saber si algo está bien o mal, hasta que lo ves filmado y editado. Los proyectos de construcción de software comparten muchos de estos elementos, así que desde una perspectiva de administración de proyectos, deberíamos aprender de ésta disciplina, donde el principal rol del gerente de proyectos es el de "navegar" los proyectos a través de la incertidumbre. Este acercamiento difiere del modelo tradicional en cascada aplicado en otras disciplinas de ingeniería, donde se define y especifica un producto con precisión, y entonces se procede a construirlo en base a un plan detallado.

El PMBoK es como la "biblia" de gestión de proyectos. ¿Consideras que incorpora este tipo de prácticas que comentas?
Creo que el PMI y el PMBoK reconocen estos principios como necesarios para administrar los proyectos de software. Sin embargo, la interpretación y ejecución típica de los gerentes de proyectos no es muy madura respecto al manejo de la incertidumbre en los proyectos de software. Esto es porque los gerentes de proyecto acostumbran tomar el camino fácil. Es mucho más sencillo administrar proyectos si asumes que los requerimientos son estables y el plan no cambiará, que si aceptas que hay mucha incertidumbre y debes manejarlos de forma dinámica. Mucho de esto también tiene que ver con los clientes, ya que muchos de ellos no permiten que los gerentes de proyectos traten el costo, alcance o tiempo como una variable. Necesitamos madurar y mejorar las prácticas de contratación de proyectos para que consideren esto, y requerimos un cambio cultural en el lado de los clientes, los gerentes de proyecto y desarrolladores.