¿Cuántos programadores se necesitan para cambiar un foco?

Recientemente, durante el SpringIO, estaba ayudando a montar algunos carteles para el evento; mientras veía la agilidad (o falta de la misma) que tenemos los programadores para armar un simple cartel, me vino a la mente ese viejo chiste de cuántos programadores se necesitan para cambiar un foco. La respuesta original es ninguno, es problema de hardware  . Pero ese día empezamos a proponer variantes a la respuesta, enfocándonos en las distintas metodologías de desarrollo, y quisiera explayarme en algunas de ellas. Así pues:

¿Cuántos programadores se necesitan para cambiar un foco?

Sin metodología: Sólo uno, pero quién sabe con qué foco va a reemplazar el que se fundió. Normalito? Ahorrador? softone? de cuántos watts? No lo sabemos, porque ni se fijó en el foco que hay que cambiar.

PSP (Personal Software Process): Sólo uno, pero tienes una certeza del 98.5% de que el nuevo foco sea del mismo wattage, marca y modelo que el anterior, y el tiempo que le tome cambiar el foco estará dentro de una desviación menor al 5% del tiempo que te dijo que se iba a tardar, con una densidad de defectos de 0.5 por cada mil vueltas que le da al foco. El problema es todo el tiempo que tuviste que esperar a que te dijera eso en lo que hacía sus cálculos, estimaciones, predicciones, etc.

XP (eXtreme Programming): Dos, obvio... Uno que lo cambia mientras explica cada paso que realiza mientras el otro escucha las explicaciones de qué es un socket.

Scrum: Dos, y un scrum master. Porque un scrum master sólo para un programador sería demasiado... el scrum master convoca a junta rápida cada 3 vueltas que le da el programador al foco viejo para quitarlo, y cada 3 vueltas que le da al foco nuevo para ponerlo. Eso es un problema para el otro programador que le toca ir a la tienda por el foco nuevo...

MSF (Microsoft Solutions Framework): Dos programadores, un líder de proyecto, un arquitecto y un project manager. El líder de proyecto le dice a uno de los programadores que es una buena oportunidad para poner un foco ahorrador y de un color más cálido, mientras el project manager le dice al otro programador que mientras se evalúan las implicaciones de tener un foco distinto, lo mejor será poner un foco igual (shared vision? ja!); el arquitecto por supuesto está de acuerdo con ambos planes. Los programadores no saben qué hacer con las órdenes contradictorias... por su parte, el líder de proyecto, el arquitecto y el project manager tienen varias juntas con el cliente y demás stakeholders; mientras tanto, los programadores toman la iniciativa y ponen un foco similar al anterior pero de más watts, lo cual resulta en que los regañen por haber empezado con una fase que todavía no estaba aprobada porque no se había aún definido claramente la responsabilidad compartida ni el enfoque a entregar valor de negocio.

TSP (Team Software Process): Dos programadores y un coach de TSP. Durante el primer día de lanzamiento (el lanzamiento de cualquier proyecto TSP dura 4 días), un programador toma los roles de customer interface manager, design manager, implementation manager y test manager, mientras que el otro toma los roles de planning manager, process manager, support manager y quality manager. En el tercer día, durante la junta de evaluación de riesgos (y después de consultarlo con la almohada), ambos se dan cuenta de que es demasiado y no van a tener tiempo de hacer nada más, por lo que se requieren dos programadores más, para que al final cada uno quede con dos roles. Después de los 4 días ya saben por las estadísticas de cada uno, quién de los 4 programadores es el mejor candidato para ir a comprar el nuevo foco, quién va a quitar el foco actual, quién va a poner el foco nuevo y quién va a probar que la nueva instalación funcione correctamente. Así que cada uno pone manos a la obra mientras el coach los guía para que sigan el proceso al pie de la letra y no dejen de dimensionar ninguna de sus tareas. Al final el cliente tiene un foco que funciona y un documento de 800 páginas que contiene más de 40 gráficas detallando las tareas realizadas, el tiempo que tomó cada una, el estimado inicial, el trabajo realizado por cada programador, sus estadísticas personales, las estadísticas del equipo, y el resultado final, demostrando que hicieron el trabajo con una desviación en tiempo del 0.5% del estimado original (lo hicieron más rápido, de hecho, y el foco nuevo estaba de oferta así que están debajo del presupuesto). El cliente revisa los tiempos y efectivamente, dijeron que el proyecto iba a concluir en 27.4 minutos y solamente les tomó 27.26 minutos (sin contar los 4 días de lanzamiento y las 7 horas que se toman después ahí mismo para hacer sus juntas de postmortem).

RUP (Rational Unified Process): Llega un consultor a revisar el foco actual y recabar información de las condiciones del mismo, abriendo con un cortador de vidrio un pequeño orificio para comprobar que efectivamente el filamento interno del foco ya se rompió. Se realiza una cotización con la propuesta de reparar el foco actual (reparar el filamento, restablecer el vacío, sellar el orificio) mientras se tiene el nuevo foco que lo reemplace, con fines de minimizar el tiempo que el cuarto pase a oscuras mientras hay un foco nuevo. Mientras se realiza esta reparación (que por supuesto no es nada barata), el consultar prepara la propuesta y cotización para el proyecto integral de actualización de dispositivos iluminadores, el cual consiste en cambiar la mitad de los focos del lugar, distribuyendo de manera uniforme los focos actuales con los nuevos, lo cual permitirá un mantenimiento preventivo (cambiar los focos que van a poner ahora) dentro de un par de años (se va a determinar la fecha del mantenimiento preventivo cuando se tenga la especificación de los nuevos focos) e implementar un plan a corto y mediano plazo de mantenimientos correctivos (cambiar los focos que se vayan fundiendo), documentando cada incidencia para poder tener finalmente un calendario completo de los cambios de focos y que nunca se vuelva a tener que cambiar un foco porque ya se fundió sino que se cambian justo antes de que se van a fundir. De este modo la fase de transición puede durar años. Internamente por supuesto el consultor subcontrata una empresa que tiene nivel CMMI 5 para que le digan cuál debe ser el nuevo foco.

CMM (Capability Maturity Model): Primero que nada, se necesita un equipo especializado (un PAT o Process Action Team, guiado por EPG o Engineering Process Group) que determine las condiciones del foco que hay que cambiar, documentando no sólo sus especificaciones sino las especificaciones de toda la instalación eléctrica (SCAMPI C). Posteriormente otro PAT analiza la información recabada y se procede a diseñar la especificación del foco nuevo. Como no existen focos de 137w que funcionen con 113.24v (y que además de todo sean CMMI-compliant), hay que mandar hacer uno a la India, donde un equipo especializado de 45 personas creará un prototipo funcional de dicho foco en tan sólo 3 meses; después de que pase las pruebas de stress (1 mes) se puede enviar de vuelta al cliente para que un equipo especializado realice las pruebas de regresión (otro mes) y finalmente se haga el deployment (quitar el foco viejo, poner el foco nuevo, encenderlo, monitorear su funcionamiento durante 6 horas, apagarlo, esperar 5 minutos, encenderlo nuevamente, ver que prenda y esperar nuevamente 6 horas). Por supuesto la especificación del foco y el contacto con el fabricante en la India no se le puede dar al cliente; si en el futuro necesita otro foco, tendrá que llamar al consultor.

Pues bueno, esas son por el momento las maneras en que un programador puede cambiar un foco. Si saben de alguna otra por favor agréguenla a los comentarios. Moprosoft, alguien?