Escenarios (sigh) de la vida real

Actualmente estoy leyendo otro libro de Ingeniería del Software; en esta ocasión trata sobre Estimaciones en los proyectos software, y se titula Software Estimation; Demystifying the Black Art, del famoso autor Steve McConnell, autor de una multitud de libros de ingeniería; entre otros es autor de  Rapid Development – Taming Wild Software Schedules y Code Complete.

Lo que a continuación transcribo, sin traducir (posiblemente lo haga en los próximos días), viene literalmente en su libro, y presenta ciertos escenarios que a más de uno le resultarán familiares en la vida de un ingeniero informático. A mí, personalmente, me recuerda mucho a las historietas publicadas en el fantástico blog Sinergia sin control.

EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3 months for a trade show. I can’t give you any more team members, so you’ll have to do the work with your current staff. Here’s a list of the features we’ll need.

PROJECT LEAD: OK, let me crunch some numbers, and get back to you.

Later

PROJECT LEAD: We’ve estimated the project will take 5 months.

EXECUTIVE: Five months!? Didn’t you hear me? I said we needed to have this software ready in 3 months for a trade show!

MANAGER: I know we had a goal of finishing this release in 12 weeks, but my estimates indicate that it will take 16 weeks. Let’s walk through the estimate using this software estimation tool. Here are the assumptions I made. First, I had to calibrate the estimation model. For the “programmer capability” factor, I assumed our programmers are 35th percentile—

EXECUTIVE: What?! No one on our staff is below average! You need to have more confidence in your staff! What kind of manager are you? Well, maybe we’ve got a few people who aren’t quite as good as the rest, but the overall team can’t be that bad. Let’s assume they’re at least average, right? Can you enter that into the software?

MANAGER: Well, OK. Now, the next factor is the capability of the requirements engineers. We’ve never focused on recruiting good requirements engineers or developing those skills in our engineers, so I assumed they were 15th percentile

EXECUTIVE: Hold on! 15th percentile? These people are very talented, even if they haven’t had formal training in requirements engineering. They’ve got to be at least average. Can we change that factor to average?

MANAGER: I can’t justify making them average. We really don’t even have any staff we can call requirements specialists.

EXECUTIVE: Fine. Let’s compromise and change the factor to 35th percentile then.

MANAGER: OK (sigh).

EXECUTIVE: We need Giga-Blat 4.0 in 6 months.

TECHNICAL LEAD: We’ve estimated the project carefully. Unfortunately, our estimates show that we can’t deliver it in less than 8 months.

EXECUTIVE: That’s not good enough. We really need it in 6 months.

TECHNICAL LEAD: Do we really need all the functionality that’s currently required? If we could cut enough functionality, we could deliver it in 6 months.

EXECUTIVE: We can’t cut functionality. We’ve already cut features to the bone on this release. We need all the features, and we need them within 6 months.

TECHNICAL LEAD: What’s the major factor that’s driving the 6-month schedule? Maybe we can find a creative solution.

EXECUTIVE: The annual trade show for our industry is in 6 months. If we miss the trade show, we’ve missed our chance to demo the software to many of our key accounts. That will effectively push back our sales cycle by a whole year.

TECHNICAL LEAD: I really can’t commit to delivering the final software in time for the trade show. But I can commit to having a beta version ready for the trade show, and I can provide a tester who knows where all the problems are and who can run the software during the show so that it doesn’t break. How does that sound?

EXECUTIVE: If you can promise the software won’t crash, that will work fine.

TECHNICAL LEAD: No problem.

TECHNICAL LEAD: Our estimate for this project is that it will take 5 to 7 months. We’re still pretty early in the Cone of Uncertainty, so we can tighten that up as we go.

EXECUTIVE: Five to 7 months is too wide a range. How about if we just use an estimate of 5 months?

TECHNICAL LEAD: We’ve found it really useful to distinguish between estimates and commitments. I can’t change the estimate, because that’s a result of a lot of computations. But I could possibly have my team commit to a delivery schedule of 5 months if we all agree that we want to take on that level of risks.

EXECUTIVE: That seems like semantics to me. What’s the difference?

TECHNICAL LEAD: Our range of 5 to 7 months includes one standard deviation of variation on each side of our 50/50 estimate of 6 months. That means we have about an 84% chance that we’ll deliver within 7 months. Our estimates suggest that we have only 16% chance of actually meeting a 5-month commitment.

EXECUTIVE: We need more than 50% confidence in the date we commit to, but 84% is more conservative than we need. What would the 75% confident date be?

TECHNICAL LEAD: According to the probabilities we estimated, that would be about 6.5 months.

EXECUTIVE: Let’s commit to that then.

TECHNICAL LEAD: That sounds good.



Fuente:

Software Estimation; Demystifying the Black Art

Steve McConnell

Microsoft Press 2006

Anuncios

Chopin fue antes músico que compositor

Frédéric ChopinMe encontraba anoche escuchando una de las obras maestras de Frédéric Chopin (1810-1849), concretamente escogí el Nocturno Nº2 en Mi bemol mayor (Op.9/2, Andante), una obra conocidísima, y durante los 4’33 minutos que dura el movimiento cerré los ojos y me sumergí en la delicadeza de las notas de piano que sonaban en el compact-disc.

Esto me transportó a un escenario de armonía, paz interior, tranquilidad. Después abrí los ojos y percibí el distinto color de las notas que sonaban, unas veces las teclas del piano eran presionadas con fuerza y energía, otras veces con delicadeza, acariciando la melodía. Pensé en la maestría del pianista, en el sentimiento que pone al sentir la música.

Pensé lo que nos dijeron una vez en clase de música: un gran compositor adquiere tal maestría en el arte de la música, y de ahí llamarles Maestros, que con sólo ver un pentagrama oye la música en su cabeza, con todo lujo de detalles. Sienten la música, ven la música, la perciben hasta un nivel en el cual el resto de los mortales jamás seremos capaces de alcanzar jamás. Del mismo modo en el que Jean-Baptiste Grenouille percibía los aromas en la genial novela El Perfume (Patrick Süskind).

Y entonces, sólo entonces comprendí que para que un compositor lograra tal soltura, tal maestría en el conocimiento de la música, primero debía haber aprendido a tocar un buen número de instrumentos. Primero debió tocar el piano como el que anoche escuchaba en el Nocturno de Chopin, el violín, y posiblemente unos cuantos más.

Enseguida encontré el paralelismo con el desarrollo de software: el maestro sería el gestor de proyectos; el aprendiz o músico sería el programador. Un ingeniero de software no puede alcanzar la maestría de un gran gestor de proyectos (y destaco lo de gran porque en el software, como en la música, hay de todo) si antes no ha adquirido la habilidad de “tocar” programas con sus dedos, sentir la magia del código. Sólo cuando ha adquirido tal habilidad, y va escalando posiciones en el desarrollo (diseñador, analista), entonces será capaz de, con sólo ver la descripción de un problema, vislumbrar los detalles de la solución, encajando piezas como en Minority Report, de Philip K. Dick. Será capaz de, viendo un código, un diagrama, una descripción funcional, montar la solución en su cabeza. Tal es la maestría del buen gestor que es capaz de alcanzar niveles cognoscitivos de entendimiento superiores a los de cualquier ser humano. Pero antes de eso, fue músico, fue programador.

Gestión de proyectos Software (I)

Desde hace unos días estoy leyendo un libro interesantísimo sobre gestión de proyectos software. Lo conocí gracias al jefe de una empresa para la cual tuve una entrevista de trabajo, y la verdad es que ha sido todo un hallazgo. El libro en cuestión se titula Peopleware, Productive projects and teams y sus autores son Tom DeMarco y Timothy Lister, dos eminencias en la consultoría de gestión y equipos software. La editorial es Dorset House Publishing Co., y tan sólo tiene unas 260 páginas que se pasan volando gracias a sus amenos ejemplos y disertaciones que hacen de su lectura pasar un rato ameno en unos casos y divertido en otros.

Este libro, de cuya primera publicación han pasado unos veinte años, está en plena vigencia aún hoy en día, pues a pesar de tratarse de un libro relacionado con la Informática trata más bien el aspecto sociológico de las relaciones humanas en el entorno de trabajo y de la productividad laboral.

Tan interesante me ha parecido este libro, cuya lectura recomiendo a todo el mundo cuya profesión exija un desempeño en equipo considerable e importante (sea en el mundo de la informática o no), que voy a colocar algunos fragmentos de entre las muchas notas que he tomado durante su lectura, añadiendo otras aclaraciones de mi propia cosecha. Mi pretensión es despertar el interés de mis lectores y que, quizá, se acerquen a esta obra:

Factores de inhibición en el crecimiento de un equipo (‘teamicides’)

No existe una fórmula mágica que nos permita hacer que un grupo funcione, alcance un estado máximo de motivación hacia su trabajo, hasta el supremo estado en el cual los proyectos se convierten en retos personales. Lo único que se puede hacer es mantener una serie de comportamientos, por parte del Gestor del grupo, que favorezcan tales situaciones, pero el éxito no está asegurado al 100%. El libro compara esta situación a aquella en la cual queremos plantar un huerto: es importante utilizar las semillas adecuadas, abonar y regar; esto es indispensable para que las plantas crezcan, y sin embargo puede que otros factores impidan el germinamiento de las semillas y que posteriormente las plantas den su fruto.

Sin embargo, a pesar de que no podemos asegurar el cómo conseguir que un equipo alcance el supremo estado de cohesión, lo que sí existe es la solución al problema inverso: qué factores “marchitarán”, “pudrirán” y “secarán” el crecimiento del grupo. Éstas son las siguientes:

Gestión defensiva

Una vez elegido el equipo, debemos confiar en él. Si crees que alguien va a cometer un error, permíteselo para que aprenda, ya lo arreglará cuando caiga en la cuenta. De otro modo inhibirás su voluntad de decisión, no le dejarás experimentar ni aprender por sí mismo, y se sentirá frustrado.

Burocracia

Hay que documentar con sentido: lo necesario, pero no más, ni menos tampoco. De otro modo convertiremos la labor de documentación en un papeleo absurdo, aburrido y poco productivo, que además llevará mucho tiempo mantener.

Separación física

Facilita la interacción, la comunicación, el crecimiento como equipo; mantenlos juntos, en un mismo despacho a ser posible. Evitarás muchas llamadas telefónicas entre ellos, que tan molestas son y tanto interrumpen los momentos de máxima concentración (lo que los autores llaman flow, porque en este estado de máxima concentración el trabajador se vuelve increíblemente productivo y las horas pasan volando).

Fragmentación del tiempo

Rompe el crecimiento del grupo, al tener que intercambiar grupos. Interrumpe la motivación y el flow. El tiempo se fragmenta entre varios proyectos, y es difícil cambiar la mente entre uno y otro. Cada trabajador, en un sólo equipo, en un sólo proyecto.

Productos de baja calidad

Si las fechas de entrega no son realistas, el producto al final tendrá mala calidad (otro día hablaré de todo esto). A los desarrolladores les partirá el alma hacer las cosas por debajo de lo que sus habilidades les permite hacer, perderán la motivación, dejarán de creer en lo que hacen y se marcharán a otro lugar.

Estimaciones temporales imposibles

Como ya he dicho, ya hablaré largo y tendido de lo nefasto de esto. El equipo tirará la toalla o se agobiará ante tales estimaciones. Se verá obligado a realizar un montón de horas extras que no serán más productivas, y ya veremos por qué. Sabrán que esas estimaciones no son factibles y no se las creerán, tomando sus propias estimaciones, y al final sintiéndose engañados porque les han dado una fecha que no era la real.

Control del equipo

Deja al equipo relacionarse e interactuar a su aire, que crezcan juntos. El gestor debe intervenir lo menos posible, y en ningún caso romper el estado libre en el que trabajan. Cuando un equipo marcha bien, la mano del gestor es invisible, el equipo siente como si nadie les ordenara. Las cosas simplemente suceden. Sin embargo el gestor está ahí, todo está previsto, marcando pequeños hitos en los pequeños logros que se van logrando.


“Peopleware, Productive projects and teams”

Tom DeMarco y Timothy Lister

Dorset House Publishing Co.,

Múltiples escritorios en Windows XP

Una de las famosas utilidades en Linux y que se hecha en falta enormemente en Windows es la posibilidad de tener varios escritorios y conmutar entre ellos, mover ventanas, redistribuir aplicaciones y así no saturar la barra de tareas y trabajar más cómodamente.

Entre las múltiples alternativas que se encuentran en la Red a este respecto, he encontrado una pequeña y graciosa aplicación, Desktops, que ocupa tan sólo 5Mb en memoria y unos 100kb el instalable. Lo único que tienes que indicar es qué atajo de teclado utilizar para conmutar entre escritorios y ya está.Tiene un selector de escritorios muy chulo para ver lo que hay en cada uno y conmutar. Como limitaciones indicaré que no permite mover ventanas entre escritorios ni seleccionar el número de escritorios: tienes 4 quieras o no. Una lástima.

Claro, a mí todo esto me escamaba mucho: ¿de dónde sale un programa con tan poca memoria y tan pequeño en disco que hace algo tan chulo? Y me puse a probar. Nada más instalarlo las primeras conmutaciones entre escritorios tardaban mucho, así que pensé que se trataba de alguna chapuza como iniciar 4 sesiones con el mismo usuario. Pues no. Algo más trivial y más simple. En tan poco espacio algún truco tenía que haber. Y efectivamente. El programa lo único que hace es… ¡abrir 4 instancias de explorer.exe! Ni más ni menos. Claro, el programa es muy ligerito, y muy simple, en una tarde también lo programo yo, y eso contando con el despliegue del selector de escritorios que es chulo… pero el explorer no es tan ligerito: añadimos 60Mb de carga a nuestra memoria. Y esto ya no es como para no tenerlo en cuenta.

Y una última prueba: abro un Firefox en un escritorio, abro otro en otro escritorio y… ¡oh, sorpresa! No se puede abrir otra instancia de Firefox porque ya hay una instancia abierta que “no responde”! Sí responde, pero el explorer.exe activo está confuso ante tal situación, pobre…

Nada más; si hacéis alguna prueba con ello y queréis añadir experiencias…