style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

¿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 /* Bazzinga */. 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?

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de fcodiaz

setFoco()

yo le creaba este metodo :
[code]
public void ChageFoco(Socket s){
Foco focoFundido=s.getFoco();
if( focoFundido.isFundido() ){
s.setFoco( new Foco(focoFundido.getType() , focoFundido.getWatts() ) )
}
}
[/code]
xP

Imagen de Shadonwk

Thansk

inche foco, pues que hace, o que pex? jajaja XD

Imagen de bimboso_d

Muy bueno

Jajajajajaja excelente jajajajaja pero pensandolo bien, no se tendria que poner un

public  void ChageFoco(Socket s){
Foco focoFundido=s.getFoco();
try{
   if( focoFundido.isFundido() ){
      s.setFoco( new Foco(focoFundido.getType() , focoFundido.getWatts() ) )
    }
}catch(InstalacionException e){
   System.out.println("No puedes instalarlo, llama a mantenimiento")
}

por si en dado caso no se pueda setear el foco? jajajaja ho ¿no habra ya un jar que tenga un metodo parecido? para que nos lo pasen jajajajaja

Imagen de ezamudio

Transacción

O puedes anotar el método con @Transactional para que en caso que algo pase a la mitad del cambio de foco, se hace rollback. Pero no importa mucho; si estás cambiando el foco, es porque ya no prende, y por lo tanto si te quedas sin foco para el caso es lo mismo que quedarte con el foco fundido puesto...

Y luego con AOP podrías meter unas precondiciones de checar si realmente el foco está fundido... o si realmente el problema es que no hay luz... o que el switch está en la posición de apagado...

Arquitectos

Un "arquitecto de focos" generaria los diagramas de caso de uso, diagramas de actividades y entidad-relacion necesarios para cambiar el foco y luego le delegaria el trabajo a un cambia-focos junior con la promesa de que en el futuro podra cambiar fusibles y bujias.

Imagen de Shadonwk

que tal la iniciativa "Java

que tal la iniciativa "Java Mexico Consultoria - Expertos en cambio de focos" ??
Con todo el personal altamente calificado. y no calificado tambien!

Otra solución


UsuarioNo sirve el @#$% foco....¿qué hago ?

Consultor:¿Ya probo encender y apagar?

Bien... un buen chiste
SALUDOS :)

Imagen de zynay

Olvidaron sistema de respaldo.

Se olvidaron de la seguridad y continuidad de la operación, para ello hay que poner un foco espejo el cual si se funde el primero, se prenda el segundo para que no se vea interrumpida la operación, así mismo, hace falta un método de encriptación que forme una cuerda del foco diferente y que no puedan quitar el foco fácilmente evitando que sea robado.
Recuerden que la seguridad es muy importante.
Saludos.

Imagen de josuemb

Simplemente: ¡Genial! Está

Simplemente: ¡Genial!

Está bastante chistoso pero muy interesante por los distintos puntos de vista:

Creó que falto algo importante:

Utilizar puntos de función para hacer el estimado de Function Points de acuerdo con IFPUG como promedio de la industria para cambiar un foco dependiendo de sus características y el lenguaje en el que se desee programar al cambio. Además: ¿Deberá el foco reportar las horas de uso? ¿Deberá llevar un estimado de su tiempo de vida últil? ¿Tiene interfaz de entrada/salida con la red eléctrica? ¿Deberá reportar por SMTP u otro protocolo su estado para monitorearlo?

En cuanto a la usabilidad:

¿Deberá tener un panel o indicador visual de tiempo de uso, consumo eléctrico y tiempo de vida útil restante?

En fin, hay todavía muchas consideración por hacer.

:)

Imagen de ezamudio

SMTP?

Un foco que manda mail? Si reporta su status por SNMP sería más práctico para que monitorees los focos con Cacti o alguna herramienta similar. Por lo demás, pues sí, serían medidas útiles... un foco con indicador visual de tiempo de uso y tiempo de vida útil restante sería muy práctico. Algunos lo tienen... empiezan a iluminar de manera estroboscópica, hacen ruido...

Imagen de ingscjoshua

jajajjajajjajaja jajajajaj

jajajjajajjajaja jajajajaj Que Gracioso PEro muy Cierto Rayos Creo que yo entro en este esqeuma sigo esperando la promesa de poder cambiar uan bujia.........

Imagen de ezamudio

Microsoft

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">