Mejora de procesos en tiempo real con SCRUM

Esta noche, voy a dar una presentación sobre SCRUM en la Red de Mejora de Procesos de Software de Boston reunión mensual en MITRE Corp. en Bedford, MA. Se trata de una variante de la parte de teoría y práctica de SCRUM del taller de OTUG que impartí en Minneapolis el año pasado.

Sutherland, Jeff. Scrum: Teoría y práctica. Conferencia distinguida del Object Technology User Group: Agile Software Development with SCRUM with Application to Healthcare Mobile Platform Development. University of St Thomas, St Paul, MN, 18 de marzo de 2003.

Una parte esencial de esta presentación es una revisión del desarrollo iterativo e incremental, una estrategia básica para todos los procesos ágiles. Es importante señalar que los principales expertos en la materia estaban convencidos, incluso en 1957, de que el método de cascada no describía lo que ocurría realmente en el desarrollo de software. Sin embargo, el método de la cascada se ha convertido en un mito urbano persistente, a pesar de haber causado cientos de miles de millones de dólares en fracasos de proyectos. Es esencial recordar constantemente a la gente que el método de la cascada es fundamentalmente erróneo en su concepto y ha condenado al fracaso a muchos de los proyectos de software mejor financiados.

El artículo de Larman y Basili sobre este tema es de lectura obligatoria para los interesados. Envíame una nota si no puedes conseguir un ejemplar.

Larman, Craig y Basili, VictorDesarrollo iterativo e incremental: Breve historia. IEEE Computer 36:6:47-56, junio de 2003.

"Ya hacíamos desarrollo incremental en 1957, en Los Ángeles, bajo la dirección de Bernie Dimsdale [en la Service Bureau Corporation de IBM]. Era colega de John von Neumann, así que quizá lo aprendió allí o lo asumió como algo totalmente natural. Recuerdo a Herb Jacobs (principalmente, aunque todos participamos) desarrollando una gran simulación para Motorola, donde la técnica utilizada era, por lo que puedo decir, indistinguible de XP.

"Cuando gran parte del mismo equipo volvió a reunirse en Washington DC en 1958 para desarrollar el Proyecto Mercury, disponíamos de nuestra propia máquina y del nuevo Sistema Operativo Share, cuya modificación y ensamblaje simbólicos nos permitieron construir el sistema de forma incremental, cosa que hicimos, con gran éxito. El Proyecto Mercury fue el semillero del que surgió la División de Sistemas Federales de IBM. Así pues, esa división comenzó con una historia y una tradición de desarrollo incremental.

"Todos nosotros, que yo recuerde, pensábamos que la cascada de un proyecto enorme era bastante estúpida, o al menos ignorante de las realidades. Creo que lo que la descripción de la cascada hizo por nosotros fue hacernos ver que estábamos haciendo otra cosa, algo sin nombre excepto "desarrollo de software". Gerald Weinberg