Software development is not a Six Sigma activity: you’re discovering, not producing widgets!
Eduardo García
09/12/2011 
4 comentarios
Esta fue la frase de presentación con la nos sorprendió uno de los ponentes en unas charlas sobre técnicas de desarrollo de software Ágil a las que asistí hace un tiempo. La idea que el ponente quería destacar era el factor “emocional” inherente a cualquier proceso creativo por encima de cualquier técnica (como SCRUM) o método de gestión de proyectos (como PRINCE2 o PMP) que aplicásemos.
Mike Cohn escribe en el prólogo del libro Scrum y XP desde las trincheras: “El enfoque en entregar código funcional cada poco tiempo significa que los equipos Scrum y XP no tienen tiempo para teorías. No persiguen dibujar el modelo UML perfecto en una herramienta CASE, escribir el documento de requisitos perfecto o escribir código que se adapte a todos los cambios futuros imaginables. En vez de eso, los equipos Scrum y XP se enfocan en que las cosas se hagan. Estos equipos aceptan que puede que se equivoquen por el camino, pero también son conscientes de que la mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel teórico de análisis y diseño y sumergirse en él, ensuciarse las manos y comenzar a construir el producto.” Es decir, invita a enfocar el desarrollo de software como sucesivos microbucles PDCA.
Yo, en mi calidad de desarrollador y analista de software, siempre he sido consciente que mi estado de ánimo personal influye sobre los programas que estaba desarrollando o analizando en ese momento. En múltiples ocasiones he estado durante días atascado desarrollando un algoritmo de 15 ó 20 que no conseguía que funcionara y otras en cambio era capaz de escribir centenares de líneas de código o complejas estructuras de ORACLE en minutos. No hablo tan sólo del hecho de que ese día “tuviera más sueño” o “estuviera más estresado”, hablo de emociones mucho más internas, como el hecho de que un día estuviera preocupado porque mi padre fuera a terminar una obra y se iba a quedar en paro o que hubiera tenido una discusión con mi pareja el día anterior y que son inherentes al hecho de ser una persona. Esos días en los que me no traía nada “acuestas” al trabajo siempre los llamé para mí mismo como los 8 días de oro, en alusión a las ventajas o rebajas que un conocido distribuidor ofrece a sus clientes durante 8 días y porque es extraño que duren mucho más de 8 días seguidos.
El desarrollo de software es una actividad creativa, el programador esta creando una actividad nueva a cada línea de código que implementa o en cada interfaz gráfica que diseña, en definitiva está creando un “nuevo ser” y como todo creador su trabajo está muy afectado por su componente emocional en ese momento.
Como jefe de proyecto utilizo la metodología PRINCE2, de tal manera que procuro que coincidan los productos entregables de cada etapa del proyecto con los sprint definidos en SCRUM, es decir, identifico los paquete de trabajo de PRINCE2 con los Sprint de SCRUM. Con esta unión de SCRUM y PRICE2 aplicada al diseño y desarrollo de software somos capaces de minimizar el impacto “emocional” en los planning de desarrollo al realizar multitud de ciclos cortos bien documentados en su inicio en la pila de producto / Work package consiguiendo alisar la carga de trabajo. Aunque también he aprendido que no debemos desaprovechar los días de oro cuando aparecen…
Hace un año estuve trabajando como project owner en metodología Scrum para un cliente.
Después de esa experiencia creo que lo verdaderamente importante en un desarrollo de software es poder aplicar el concepto pdca en ciclos cortos aportando de manera continua las expectativas del cliente.
También me pareció muy practico aunque muy mejorable la forma de asignar el peso de la carga de trabajo a los workpackages. ¿Has usado las cartas con las puntuaciones al mas puro estilo de Scrum?
Hola Manuel, muchas gracias por tu comentario,
Yo cambiaría la palabra “aportando” por la palabra “validando” o mi experiencia me ha demostrado que aparecen los tan temidos “Isi” y “Jack” (Y si cambiamos… Ya que estamos porque no…)
Como jefes de proyecto debemos vigilar que en ningún momento cambie el alcance del proyecto validado en la fase de inicio, si cambia el alcance no estamos entregando el producto inicialmente requerido, estamos entregando otra cosa diferente.
Los incrementos de funcionalidad deben ser considerados para versiones 2 y analizadas en conjunto una vez hayamos testado, validado y entregado la versión 1 ó corremos el riesgo de que el software no sea desplegado nunca porque está en permanente evolución o se encuentre parcialmente desplegado con el consiguiente riesgo de bugs nos deseados.
En cuanto a lo que me preguntas, yo soy más partidario de adaptar las metologías y las técnicas que de seguirlas a pies juntillas o se convierten en un corsé que limita la capacidad de poder responder adecuadamente a cada proyecto. El cómo hago la asignación de cargas de trabajo depende básicamente del tamaño del proyecto y de la disponibilidad del recurso humano para el proyecto, ya sabes que el jefe de proyecto debe “hacer magia” siempre al respecto
Lo que está más de moda hoy en la gestión de proyectos es la unificación de los conceptos Lean y Agile, es decir, la eliminación del desperdicio y el incremento de la automatización allá donde sea posible.
Mi experiencia de una larga trayectoria profesional como desarrollador (trabajo que me encanta, que me sigue apasionando a mis casi 60 años, y campo en el que sigo aprendiendo – hoy lenguajes como R, Ruby, netlogo, …. ) junto a mi también larga etapa como six sigma master balck belt, me ha permitido ver que en todas las profesiones abundan las personas “complacientes”.
Eso lo notas con expresiones como “nuestro trabajo es muy diferente, no manejamos una ciencia exacta, si funciona no lo toques, no podemos hacer más, …”
Y lo ves en TODAS las profesiones. A los complacientes les vienen muy bien las excusas.
Comparto SCRUM y el pensamiento Agile SOLO en la medida en que se alinean con la filosofia “LEAN”. Hay creatividad en todos los trabajos, incluído el de un albañil si estamos realmente delante de un profesional. Y hay estandares potentes siempre que estamos delante de equipos serios y profesionales.
Necesitamos y queremos creatividad en todos los proyectos de software para el trabajo de “modelar”. Necesitamos estandarización para tener repositorios de alto y creciente valor, que nos permiten ser cada día más eficientes. Y para adoptar las mejores prácticas demostradas y contagiarlas al grupo.
No! Discrepo profundamente de los evangelistas de la “excusa” para entregar mal y tarde. De la excusa para no comprometerse en calidades y plazos.
Ya lo creo que se puede – y se DEBE – hacer six sigma en la ingeniería de software. Pero, sobretodo, se debe hacer “LEAN” en todas sus dimensiones. No en un “subset” escogido para defender los intereses de un “gremio”.
El cliente es lo UNICO sagrado. Y satisfacer sus necesidades NO tiene ningún mérito. Es INSUFICIENTE! Estamos obligados a diseñar nuestro sistema productivo para EXCEDER sus continuamente crecientes expectativas. Y estamos obligados a hacerlo con el nivel de menor desperdicio total de la cadena de valor. Y mañana mejor que hoy.
Hola José, muchas gracias por tu comentario.
Totalmente de acuerdo contigo en que el cliente es lo más importante y que hacer simplemente bien nuestro trabajo es insuficiente: trabajar de manera profesional es la curva de requisitos básicos del diagrama de Kano, entregar en coste y plazo lo solicitado sólo es la curva de requerimiento, debemos ver más allá de los requerimientos del cliente para poder llegar a la curva de deleite y de esta manera hacer que el cliente sienta que somos tan importantes para él como el mismo lo es para nosotros.
Curiosamente ayer, en el programa “Redes” de Eduard Punset, se hablaba de la manera de promover y potenciar la creatividad (http://www.rtve.es/television/20110327/todos-tenemos-capacidad-ser-creativos/420223.shtml). El Dr. Ken Robinson decía que él definía la creatividad “como el proceso de tener ideas originales que aporten valor”. Qué duda cabe que la complacencia mata el proceso creativo en sí mismo ya que desaparece la motivación de “aportación de valor”. También se comenta que la creatividad hay que fomentarla desde dentro de uno mismo, con la pasión por nuestro trabajo, y desde fuera promoviendo un entorno que incite al “creador” a realizar y desarrollar su trabajo de manera productiva. Ese era el fin que quería destacar el ponente de la charla con su frase; que nosotros como jefes de proyecto somos responsables últimos de que los equipos se conviertan en complacientes / en no creativos / en no productivos si nosotros mismos tendemos a la complacencia / la no creatividad / la no productividad; que tenemos que entender que trabajamos con personas, que como nos diría el profesor Ortega y Gasset “son ellos y sus circunstancias”, y que por tanto una de nuestras labores en el proyecto consiste en gestionar la creatividad de los operacionales del mismo sabiendo que trabajamos siempre para el CLIENTE.
En cuanto a lo del enfoque lean aplicado a la gestión de proyectos estoy totalmente de acuerdo en que no es recomendable sino necesario empezar a aplicarlo para conseguir satisfacer plenamente a nuestro cliente, es decir, para alcanzar la curva de deleite de Kano que la que hablábamos. Como información te comento que el Dr. Masa K. Maeda dará unos cursos en Madrid y Bacelona en febrero precisamente sobre como implantar el Lean Agile Project Management en empresas.