Joel on Software

Joel on Software   La Opinión de Joel sobre qué es Software

 

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Planificación Indolora de Proyectos de Software


Por Joel Spolsky
Traducido por Darío Vasconcelos
Editado por Jerry Elizondo
Marzo 29, 2000

En octubre pasado, el noreste de los Estados Unidos fue invadido con anuncios de una cosa llamada Acela, un nuevo tren exprés de Boston a Washington. Con comerciales de TV, carteleras y carteles por todos lados, uno pensaría que se habría creado algo de demanda para este nuevo servicio exprés de Amtrak.

Bien, sólo quizás. Amtrak no tuvo oportunidad de averiguar. Acela fue retrasado, y retrasado de nuevo, de manera que la campaña de mercadeo se desarrollaba mientras el servicio de Acela ni siquiera estaba disponible. Lo que me recordó algo que escuché decir a un administrador de mercadeo cuando su producto obtuvo una crítica delirante un mes antes de salir a la venta: "¡Excelente publicidad! Lástima que no puedas comprar el condenado producto"

Las compañías que desarrollan juegos, enloquecidas por la testosterona, gustan de jactarse en sus sitios de Internet que el próximo juego será lanzado "cuando esté listo". ¿Calendarios? ¡No necesitamos tontos calendarios! ¡Somos geniales desarrolladores de juegos! La mayoría de las compañías no pueden darse esos lujos. Pregúntenle a Lotus. Cuando lanzaron 123 versión 3.0, requería una computadora 80286 que no era muy común en ese entonces. Retrasaron el producto 16 meses mientras trabajaron para "calzarlo" dentro del límite de 640K de memoria del 8086. Para cuando terminaron, Microsoft tenía una ventaja de 16 meses desarrollando Excel, y, en lo que fue una gran broma kármica, ¡el 8086 era obsoleto de todos modos!

Mientras escribo esto, el navegador Netscape 5.0 está retrasado casi dos años. Parcialmente, porque cometieron el error suicida de desechar todo su código e iniciar de nuevo: el mismo error que sepultó a Ashton-Tate, Lotus, y el MacOS de Apple en las papeleras de reciclaje de la historia del software. Netscape ha visto su participación del mercado del navegador bajar de un 80% a un 20% durante este tiempo, y mientras tanto no podía hacer nada para resolver las preocupaciones competitivas, porque su producto estaba desmontado en 1000 piezas en el piso y no estaba en forma para ir a ningún lado. Esa sola mala decisión, más que ninguna otra cosa, fue la bomba nuclear con la que Netscape se voló a sí mismo. (La famosa explosión temperamental de Jamie Zawinski describe los detalles.)

Así que tienes que hacer un plan de trabajo. Esto es algo que casi ningún programador quiere hacer. En mi experiencia, la gran mayoría intentan simplemente salirse con la suya y no hacer ningún plan. De los pocos que hacen uno, casi todos lo hacen sólo porque sus jefes los obligan a hacerlo, a medio gas, y nadie realmente cree en el plan del proyecto excepto los altos cargos administrativos, que al mismo tiempo cree que "ningún proyecto de software termina nunca a tiempo" y en la existencia de los OVNI.

Así que ¿por qué nadie hace un plan de trabajo? Dos razones clave. Una, es una verdadera lata. Dos, nadie cree que vale la pena. ¿Por qué tomarse la molestia de trabajar en un plan de trabajo si no va a estar en lo correcto? Hay una percepción de que los planes de proyecto están errados consistentemente, y consiguen sólo estar peor mientras avanza el tiempo, así que ¿por qué sufrir por nada?

He aquí una forma simple e indolora de crear planes de trabajo que de hecho se ajustan a la realidad.

1) Usa Microsoft Excel. No uses nada sofisticado como Microsoft Project. El problema de Microsoft Project es que asume que estás dispuesto a gastar mucho tiempo preocupándote por las dependencias. Una dependencia ocurre cuando tienes dos tareas, una de las cuales debe ser terminada antes de que la otra pueda iniciar. He hallado que al desarrollar software las dependencias son tan obvias que simplemente no vale la pena el esfuerzo de llevar un registro formal de ellas.

Otro problema con Project es que asume que tú quieres poder presionar un botoncito y "re-balancear" el plan de trabajo. Inevitablemente, esto significa que va a reordenar y reasignar tareas a gente distinta. En el software, esto simplemente no tiene sentido. Los programadores no son intercambiables. Le toma siete veces más a Juan arreglar el error de programación de Rita que a Rita arreglar el error de Rita. Y si uno intenta asignar un problema de Winsocks a un programador de UIs (Interfases de Usuario), ella se atascará y perderá una semana para ponerse al corriente en programación de Winsock. El fondo es que Project está diseñado para construir edificios de oficinas, no software.

2) Mantenlo simple. El formato estándar que yo utilizo para planificar de trabajo es tan simple que cualquiera puede memorizarlo. Se inicia con sólo siete columnas:

[Image]

Si tienes varios desarrolladores, puedes mantener una hoja de trabajo por cada uno o crear una columna con el nombre del desarrollador que está trabajando en cada tarea.

3) Cada característica debe consistir en varias tareas. Una característica es, por ejemplo, añadir un corrector ortográfico al programa. Añadir un corrector ortográfico consiste en un pequeño número de tareas bien definidas que el programador debe realizar. La parte más importante de hacer un plan de trabajo es hacer esta lista de tareas. De ahí la regla cardinal:

4) Sólo el programador que va a escribir el código puede hacer su calendario. Cualquier sistema en el que el gerente crea el plan de trabajo y lo entrega a los programadores está condenado al fracaso. Sólo el programador que va a realizar el trabajo puede darse cuenta de qué pasos necesitará para implementar esa característica. Y sólo el programador puede estimar cuánto tiempo le llevará realizar cada uno.

5) Elige tareas con mucha granularidad. Esta es la parte más importante para hacer que tu plan de trabajo funcione. Las tareas deben ser medidas en horas, no días. (Cuando veo un plan de trabajo que está especificado en días o aún meses, sé que no es real.) Uno podría pensar que un plan de trabajo con tareas muy granulares es simplemente más preciso. ¡Error! ¡Gran error! Cuando uno quiere iniciar un plan de trabajo con tareas "ásperas" e intenta dividirlo en tareas más pequeñas, termina con un resultado diferente, no uno más preciso. Es un número completamente diferente. ¿Por qué ocurre esto?

Cuando tienes que definir tareas muy granulares, tienes que forzarte a realmente pensar qué pasos tendrás que tomar. Escribir la subrutina xyz. Crear el diálogo tal y tal. Leer el archivo wawa. Estos pasos son sencillos de estimar, porque has escrito subrutinas, creado diálogos y leído archivos wawa antes.

Si eres descuidado, y eliges tareas en bloques ("implementar corrección gramatical"), entonces no has pensado realmente acerca de lo que vas a hacer. Y cuando no has pensado en lo que vas a hacer, simplemente no puedes saber cuánto tiempo te va a tomar.

Como regla general, cada tarea debe tomar de 2 a 16 horas. Si tienes una tarea de 40 horas (una semana) en tu plan de trabajo, no lo estás dividiendo suficientemente.

He aquí otro motivo para escoger tareas granuladas: te fuerza a diseñar la maldita característica. Si tienes una alegre característica llamada "Integración para Internet" y planificas 3 semanas para ella, estás condenado, amigo. Si tienes que calcular qué subrutinas vas a tener que escribir, te obligas a definir la característica. Al ser forzado a planificar de antemano a este nivel, eliminas mucha de la inestabilidad en un proyecto de software.

6) No pierdas de vista la estimación original y actual. Cuando añades una tarea al plan, estimas cuánto tiempo va a tomar en horas y colocas ese valor tanto en la columna Est[imado] Orig[inal] y Est[imado] Act[ual]. Conforme el tiempo avanza, si una tarea está llevando más (o menos) de lo esperado, puedes actualizar la columna Est Act tanto como lo necesites. Esta es la mejor forma de aprender de tus errores y enseñarte a estimar correctamente las tareas. La mayoría de los programadores no tiene idea de cuánto tiempo tomarán las cosas. Está bien. Mientras estés continuamente aprendiendo y continuamente actualizando el plan de trabajo a medida que aprendes, el plan funcionará (puede ser que necesites quitar características o ajustar, pero el plan de trabajo seguirá trabajando correctamente, en el sentido de constantemente decirte cuándo tienes que quitar características o hacer ajustes.) He encontrado que la mayoría de los programadores se vuelven muy buenos planificadores con aproximadamente un año de experiencia.

Cuando la tarea es finalizada, los campos Est Act y Transc[urrido] serán iguales, y el campo Restante se recalcula a cero.

7) Actualiza la columna Trans cada día. No tienes realmente qué vigilar tu cronómetro mientras codificas. Justo antes de ir a casa, o de prepararte para dormir debajo del escritorio si eres uno de esos geeks, supón que trabajaste 8 horas (¡ja!), recuerda en qué tareas has trabajado, y rocía 8 horas en la columna de tiempo transcurrido. El campo Restante será calculado automáticamente por Excel.

Al mismo tiempo, actualiza la columna Est Act, para esas tareas para reflejar la nueva realidad. Actualizar tu plan de trabajo diariamente debería tomarte sólo unos dos minutos. Esa es la razón por la cual este es el Método Indoloro de Planificación de Proyectos -- es rápido y sencillo.

8) Toma en cuenta los tiempos por Vacaciones, Asuetos, etc. Si tu plan de trabajo va a durar cerca de un año, cada programador probablemente tomará de 10 a 15 días de vacaciones. Debes tener un rubro llamado vacaciones, uno asuetos y cualquier otra cosa que consume el tiempo de la gente. La idea es que la fecha de lanzamiento pueda ser calculada añadiendo el tiempo de la columna Restante y dividiendo por 40 -- ese es el número de semanas de trabajo que quedan, incluyendo todo.

9) ¡Incluye el tiempo de corrección de errores en el plan! La corrección de errores es el tiempo más difícil de estimar. Haz memoria del último proyecto en que participaste. Las probabilidades son que la corrección de errores tomó de 100% a 200% del tiempo que tomó escribir el código en un inicio. Esto debe ser un renglón más en el plan de trabajo, y probablemente será el más largo.

He aquí cómo funciona. Supongamos que un programador está trabajando en wawa. El Est Orig era de 16 horas, pero hasta ahora ha tomado 20 y parece que va a necesitar otras 10 más. El desarrollador introduce 30 debajo de Est Act y 20 debajo de Trans.

En el extremo final del "hito", todos estos ajustes probablemente habrán añadido un poco de tiempo. Teóricamente, para acomodar estos ajustes tendremos que quitar características para poder entregar a tiempo. Afortunadamente, la primer característica que podemos quitar es esta llamada "Compensación", que es enorme y tiene un montón de horas asignadas.

En principio, los desarrolladores deben corregir el código conforme lo escriben. Un programador nunca, jamás debería trabajar en código nuevo si pudiera estar corrigiendo errores. La cuenta de errores debe mantenerse tan baja como sea posible todo el tiempo, por dos razones:

1) Es más fácil corregir errores el mismo día que hiciste el código. Puede ser muy difícil y tardado corregir problemas un mes después cuando has olvidado exactamente cómo funciona el código.

2) Corregir errores es como la ciencia. Es imposible estimar cuándo realizarás el descubrimiento y corregirás el error. Si sólo están pendientes dos errores en cualquier momento, es fácil estimar cuándo se entregará el producto, porque no hay mucho de ciencia inestimable en el futuro. Por otro lado, si hay cientos o miles de errores pendientes, es imposible predecir cuándo serán corregidos todos.

Si los programadores corrigen errores mientras avanzan, ¿cuál es el punto en tener un renglón para corrección de errores? Bien, aún si intentas corregir todos los errores mientras avanzas, al final del proyecto hay inevitablemente una gran cantidad de corrección de errores cuando los encargados de las pruebas (internas y beta) encuentren los errores realmente difíciles.

10) Incluye el tiempo de integración en el plan de trabajo. Si tienes más de un programador, inevitablemente habrá cosas que dos de ellos hacen de forma inconsistente y tendrán que ser reconciliadas. Ambos pueden implementar ventanas de diálogo para cosas similares que son innecesariamente inconsistentes. Alguien tendrá que revisar todos los menús, teclas rápidas (Ctrl + A, Shift + C), barras de herramientas, etc., limpiando y organizando todos los nuevos elementos de menú que todos han estado añadiendo alegremente. Habrá errores de compilación que surgirán hasta que dos personas hagan "check-in" de código. Esto tiene que ser corregido, y debe ser un renglón más en el plan de trabajo.

11) Agrega tiempo de compensación en el plan. Las cosas tienden a sobrepasarse. Hay dos tipos importantes de tiempo de compensación que pueden ser consideradas. Primero: compensa para tomar en cuenta tareas que tomaron más tiempo que el estimado originalmente. Segundo: compensa para tomar en cuenta tareas que no sabías que tendrías que hacer, generalmente porque los altos mandos han decidido que implementar wawa es SUPER IMPORTANTE y no puede dejarse fuera para la próxima versión.

Puede que te sorprenda que al final las vacaciones, asuetos, corrección de errores, integración y tiempo de compensación suman más tiempo que las tareas reales. Si estás sorprendido por esto, no llevas mucho tiempo programando, ¿verdad?. Ignora estas recomendaciones bajo tu responsabilidad.

12) Nunca, nunca permitas que los administradores del proyecto pidan a los programadores reducir un tiempo estimado. Algunos administradores novatos piensan que pueden "motivar" a sus programadores a trabajar más rápido dándoles planes de trabajo bonitos, "apretadamente" (irrealmente) cortos. Pienso que este tipo de motivación es imbécil. Cuando estoy retrasado en mis tiempos, me siento condenado y deprimido y desmotivado. Cuando estoy trabajando adelantado al plan de trabajo, me siento alegre y productivo. El calendario de trabajo no es el mejor lugar para jugar juegos psicológicos.

Si tu administrador te pide que reduzcas un tiempo estimado, he aquí qué hacer. Crea una nueva columna en el plan llamada Estimado de Rick (asumiendo que tu nombre es Rick, por supuesto). Pon tu tiempo estimado ahí. Deja que tu jefe haga lo que quiera con la columna Est Act. Ignora los estimados de tu jefe. Cuando el proyecto termine, observa quién estuvo más cerca de la realidad. He hallado que tan sólo amenazar con hacer esto hace maravillas, ¡especialmente si tu jefe se da cuenta que justo han entrado a un concurso para ver qué tan lento puedes trabajar!

¿Por qué los jefes ineptos intentan hacer que los programadores reduzcan sus tiempos estimados?

Cuando el proyecto inicia, los administradores técnicos salen, hacen juntas con la gente del negocio, y regresan con una lista de características que ellos piensan debería tomar unos 3 meses, pero que en realidad tomaría 9. Cuando piensas en crear código sin pensar en todos los pasos que tienes que tomar, siempre parece que toma n tiempo, cuando en realidad probablemente tomará 3n tiempo. Cuando haces un verdadero plan de trabajo, sumas todas las tareas y te das cuenta de que el proyecto tomará mucho más que lo originalmente planificado. La realidad sale a flote.

Los administradores ineptos tratan de solucionar esto descubriendo cómo hacer que la gente trabaje más rápido. Esto no es muy realista. Probablemente puedas contratar más recursos, pero éstos necesitan ponerse al corriente y probablemente estarán trabajando con una eficiencia del 50% durante varios meses (y disminuyendo la productividad de los que tienen que hacer de mentores.) De cualquier modo, en este mercado, añadir buenos programadores toma 6 meses.

Es posible que puedas sacar un 10% de código extra de la gente, temporalmente, con el costo de "quemarlos" en un 100% durante un año. No es una gran ganancia, y es un poco como comerte la semilla de tu propio maíz.

Es posible que puedas obtener un 20% de código extra de la gente suplicándoles que trabajen súper duro, sin importarles qué tan cansados terminen. Bum, el tiempo de corrección de errores se duplica. Una decisión idiota que rebota de vuelta en una forma espléndidamente kármica.

Pero nunca puedes obtener 3n de n, nunca, y si tú piensas que puedes hacerlo, por favor envíame por e-mail la clave de la Bolsa de Valores de tu compañía para que pueda vender en corto sus acciones.

13) Un plan de trabajo es como bloques de madera. Si tienes un montón de bloques, y no puedes hacerlos entrar en una caja, tienes dos opciones: obtener una nueva caja o quitar algunos bloques. Si pensabas que podías lanzar el producto en 6 meses, pero tienes 12 meses en el plan de trabajo, vas a tener que retrasar el lanzamiento o encontrar algunas características que quitar. Simplemente no se puede encoger los bloques, y si puedes fingir que puedes, entonces estás meramente privándote de la útil oportunidad de realmente ver el futuro al mentirte a ti mismo acerca de lo que ves ahí.

Y ya se sabe, el otro gran subproducto de mantener un plan de trabajo de esta forma es que estás forzado a quitar características. ¿Por qué es bueno esto? Supón que tienes dos características: una que es realmente útil y hará tu producto realmente bueno (ejemplo: tablas en Netscape 2.0), y otra que es realmente sencilla y los programadores adorarían desarrollar (ejemplo: la etiqueta BLINK), pero que no tiene ningún propósito útil o de mercadotecnia.

Si no haces un plan de trabajo, los programadores harán primero la característica más fácil/divertida. Después empezarán a retrasarse, y no tendrás más remedio que ajustar el plan para poder realizar la característica útil/importante.

Si haces un plan de trabajo, aún antes de empezar a trabajar, notarás que hay que cortar alguna característica, así que lo harás con la fácil/divertida y no con la útil/importante. Al forzarte a escoger algunas características para quitar, terminas haciendo un mejor y más poderoso producto con una mezcla mejor de buenas características que es lanzado antes.

Recuerdo cuando trabajé en Excel 5. Nuestra lista original de características era enorme y se habría salido muchísimo del calendario planificado. ¡Oh Dios!, pensamos. ¡Esas características son todas súper importantes! ¿Cómo podemos sobrevivir sin un "wizard" de edición de macros?.

Resulta que no teníamos elección, y cortamos lo que creíamos era "lo justo" para cumplir el plan. Todo mundo se sintió muy triste por lo que removimos. Para mitigar nuestro dolor, simplemente nos dijimos a nosotros mismos que no estábamos quitando las características, simplemente estábamos difiriéndolas para Excel 6, porque eran menos importantes.

Cuando Excel 5 se acercaba a su terminación, empecé a trabajar en las especificaciones para Excel 6 con un colega, Erich Michelman. Nos sentamos a trabajar en la lista de las "características para Excel 6" que habíamos cortado del plan para Excel 5. Estábamos absolutamente pasmados al ver que la lista era la más pretenciosa lista de características que uno podría imaginar. No valía la pena realizar ninguna de ésas características. Creo que nunca se implementó alguna de ellas, ni siquiera en las siguientes tres versiones. El proceso de filtrar características para encajarlas al calendario de trabajo fue la mejor cosa que pudimos haber hecho. Si no hubiéramos hecho esto, Excel 5 se habría tomado el doble de tiempo en realizarse y hubiera incluido un 50% de características inútiles. (No tengo absolutamente ninguna duda que esto es exactamente lo que le está sucediendo a Netscape 5 / Mozilla: no tienen un calendario, no tienen una lista definitiva de características, nadie está dispuesto a cortar ninguna característica, y simplemente nunca han terminado el producto. Cuando finalmente lo terminen, tendrán montones de características tontas como clientes IRC en las que simplemente no deberían haber gastado tiempo.)

Apéndice: Cosas que debes saber de Excel

Una de las razones por las que Excel es un producto tan bueno para trabajar en planes de trabajo de software es que la única cosa para la que los programadores de Excel utilizan Excel es para dar mantenimiento ¡a sus planes de trabajo! (No muchos de ellos están corriendo escenarios hipotéticos -"what-if "-... estamos hablando de programadores, aquí)

Shared Lists (Compartir libro) Usar este comando permite a todos abrir el archivo al mismo tiempo y editar cosas al mismo tiempo. Dado que todo el equipo debería estar actualizando su plan constantemente, esto realmente ayuda.

Auto Filter (Auto Filtros) Esta es una excelente manera de filtrar el plan de forma que, por ejemplo, veas sólo las características que están asignadas a ti. Combinado con Auto Sort (Auto Ordenamiento), puedes ver todas las características asignadas a ti en orden de prioridad que es efectivamente tu lista de "por hacer". ¡Geniaaaaal!

Tablas Pivot Esta es una excelente forma de ver resúmenes y tabulaciones cruzadas. Por ejemplo, puedes hacer una gráfica mostrando las horas restantes para cada desarrollador para cada prioridad. Las Tablas Pivot son como el pan de caja y las malteadas de chocolate. Debes aprender a utilizarlas porque hacen que Excel sea millones de veces más poderoso.

La función WORKDAY (DIA.LAB en la versión en español) del "Analysis Toolpak" de Excel; es un gran método para obtener fechas de un Plan de Trabajo.



Esté articulo apareció originalmente en Inglés con el nombre Painless Software Schedules  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky