Este correo es una síntesis y la continuación de algunas ideas que han sido cubiertas en otros puestos en este blog: Por qué las inversiones volátiles chupan, la regla 85/95 de la gestión de proyectos, y cartas de Gantt contra la base de datos PR. Si usted ha leído todos aquellos puestos, entonces lo que sigue podría tener sentido a usted. Si no, entonces adivino que veremos sólo que bueno un escritor soy. If you have read all of those posts, then what follows might make sense to you. If not, then I guess we'll see just how good a writer I am.

Al mudo esto abajo algo, usaré uno de mis dispositivos literarios favoritos: La parábola. Aquí está la historia de Ploddin' Paul el director de proyecto que es enfrentante con una decisión de gestión muy difícil. Él tiene un equipo de 5 reveladores, de los cuales tres son reveladores mayores y son capaces de manejar miniproyectos solos. Sus nombres son Genius Gary, el Ingeniero Eric, y Liason Larry. Here is the story of Ploddin' Paul the project manager who is faced with a very difficult management decision. He has a team of 5 developers, of which three are senior developers and are capable of handling mini-projects on their own. Their names are Genius Gary, Engineer Eric, and Liason Larry.

El proyecto es uno algo arriesgado, pero no demasiado tan. El objetivo es construir un interfaz archivador a varios modelos diferentes del paseo de cinta de modo que los clientes que registran en una base de datos tengan la opción de dejar sus datos en línea, salvándolo a un paseo de cinta, o restaurar los datos de la cinta. Por supuesto, hay número de otros rasgos y diseña requisitos. El proyecto es ser entregado en 6 meses. Of course, there are number of other features and design requirements. The project is to be delivered in 6 months.

El equipo tiene tres opciones: 1) Escriba que el código desde el principio 2) Refunde algún código existente que fue producido interior o 3) Trabajo con un tercero API que promete entregar la mayor parte de la funcionalidad (publicado por un vendedor llamado Babooza).

"Los APIs de Babooza chupan de alto nivel, vaya a hacerlo el derecho. Escriba el código de la tierra en C #," dice Genius Gary, que es el mejor programador de la parte, pero tiene la actitud para ir con ello.

"El camino menos arriesgado es refundir nuestra base de código existente," dice el Ingeniero Eric. "Ya sabemos como difícil esto debe trabajar con los conductores para los dispositivos de cinta. Sí, hay pelo en la vieja base de código pero esto es el diablo que conocemos." Yeah, there's hair in the old code base but that's the devil we know."

"En seis semanas, Babooza dice que ellos entregarán un API que tiene cuidado de la mayor parte de esto." dice Liason Larry. "¿Por qué hacen alguno de esto si aquellos tipos lo harán para nosotros?" "Why do any of this if those guys will do it for us?"

"¿Babooza de confianza? Usted es chiflado. Y nuestra vieja base de código chupa. Cada uno sabe esto. Vaya nuevo." And our old code base sucks. Everybody knows that. Go new."
"Estuve de acuerdo con usted sobre Babooza. Pero usted quiere saltar lejos en el agua profunda sin el chaleco salvavidas. Vaya viejo." Go old."
"¿Pero y si Babooza entregue algo funcional? La voluntad podría hacer nuestros reveladores añadir más rasgos y GUI realmente bueno en vez de meter la pata alrededor de la tentativa conseguimos que los paseos de cinta archiven.""

A este punto en la conversación, aproximadamente cuando los reveladores están a punto de correr a su escritorio y colocar el asunto jugando un deathmatch en "el Torneo Irreal," Ploddin' Paul habla:

"¿Larry, qué piensa usted las probabilidades es de Babooza entregando el API a tiempo y esto siendo usuable?"

"Ah, yo dunno, tal vez el 50 %"

Tanto Eric como Gary hacen ruidos y señales de Paul que abajo al 25 % en su cabeza.

"¿Gary, si y otro revelador trabajan en la construcción qué necesitamos desde el principio, cree usted que podemos transportar a tiempo?" pregunta Paul.

"Naw, demasiado trabajo, yo necesitaría a al menos otro tipo."

"¿Y si yo le diera a un tipo tres meses en? Tal vez dos.""

"Bien, posibilidad del 80 % de ser hecho a tiempo."

Ahora es Eric y la vuelta de Larry a hacer rodar sus ojos. Entonces Paul marca abajo las probabilidades al 40 % en su cabeza.

"¿Eric?"

"C'mon Paul, déme el equipo entero y el noventa por ciento seguro que esto va a ser entregado."

"Más peludo que la espalda de un gorila," dice Gary en un susurro fuerte a Larry. "Piense espagueti.""

"¿Eric, si usted refunde sólo el código, cómo es que usted necesita el recuento de cinco?"

"Venga a, el más el más alegre. Va a haber mucha depuración.""

"Usted consigue a un tipo por el momento, con tal vez más en tres meses. ¿Entonces son usted por ciento todavía del 90 % seguro?""

"Ah, ningunas promesas," dice Eric

Paul mentalmente marca las probabilidades abajo a 50-50. Él ha echado un vistazo al código. ¡Suena horrible. It's terrible.

Paul toma su decisión. "Cada uno se marcha y hace su propia cosa. Volveremos en tres meses y revisión." Cada uno saluda con la cabeza su cabeza y se va. Esto siempre pareció a esto, con Paul que nunca toma una decisión en el camino final tomar hasta el último momento posible. Esto volvió a algunos reveladores completamente locos a veces, con la queja rara que parece que el grupo siempre está al borde de la anarquía completa. Pero Paul REALMENTE dejó a cada uno intentar su propio camino la mayor parte del tiempo, entonces la gente era la más feliz. Sólo pareció tan ineficaz... We'll come back in three months and review." Everybody nods their head and walks off. It was always like that, with Paul never making a decision on the final path to take until the very last possible moment. It drove some of the developers completely nuts sometimes, with the odd grumble that the group always seem to be on the verge of complete anarchy. But Paul DID let everybody try their own way most of the time, so people were most happy. It just seemed so inefficient...

***************************************************************************

De este modo, en el primer leído, esto parece que Paul viola una de las reglas de oro de gestión de proyectos que siempre es trabajan mucho para cambiar sus 85 a 95 (o sea, siempre intente a su raro del éxito, no importa que incremental puede ser). Paul abandona algunos caminos que prometen una posibilidad de por ciento del 90 % de éxito y piso de alquiler de reveladores perseguir algunos enfoques de riesgo elevado. También, tengo que decir que este enfoque parecería a la mierda si usted lo lanzara en una carta de Gantt: En vez de la pequeña barra limpia mostrando a cinco reveladores que trabajan juntos como un equipo hacia un objetivo común, usted tiene tres barras que trabajan en la paralela hacia el mismo objetivo. A algún punto en la carta, usted tiene que terminar dos de aquellas tareas, con toda la basura de recursos que implica (En el caso de Paul, el punto de decisión es intermedio en el proyecto o tres meses). Also, I have to say that this approach would look like crap if you threw it up on a Gantt chart: Instead of clean little bar showing five developers working together as a team towards a common objective, you've got three bars working in parallel towards the same goal. At some point in the chart, you've got to end two of those tasks, with all the waste of resources that implies (In Paul's case, the decision point is halfway into the project or three months).

Resumir: Los reveladores no creen que Paul sea un director de proyecto decisivo, y definitivamente, si el jefe de Paul viviera y muriera por la carta de Gantt, él se preguntaría por qué Paul gastaba recursos con todo el redundacy.

Pero otra vez, las matemáticas trabajan para Paul, porque en el desarrollo de software, los caminos paralelos con una posibilidad razonable del éxito son un mejor que un camino con una posibilidad alta del éxito. Note que el camino de paralelas significa que usted añade los porcentajes juntos, no se multiplican como en una secuencia:

Un camino: el 90 % de éxito.
Tres caminos: ¡el 25 % + el 40 % + el 50 % = el 115 % de éxito!!

Por supuesto el 115 % no significa que el proyecto está absolutamente seguro de ser completado con éxito y a tiempo. Estos porcentajes son los porcentajes del jugador, significando que la suma es la adición de una serie de apuestas para una rentabilidad dada. Una historia metafórica podría hacer cosas más claras. A metaphorical story might make things clearer.

Vaya a fingir que estamos en el casino, más bien que en un ambiente de desarrollo de software. Usted tiene 500$ en su bolsillo y el premio es... Ah, yo dunno... Ipod flamante (La mejor versión, el que con 40 calesas. El que mi esposa no me dejará comprar 'la causa no tengo un trabajo, aunque esto me hiciera realmente, realmente feliz si yo pudiera).Oh, I dunno... an brand new Ipod (The best version, the one with 40 gigs. The one my wife won't let me buy 'cause I don't have a job, even though it would make me really, really happy if I could).

Usted puede colocar todo su dinero en una apuesta y tener una posibilidad del noventa por ciento de la ganancia. O usted puede hacer una serie más complicada de apuestas como Paul hizo: Usted deja 100$ y tiene una posibilidad del 25 % de la ganancia. Usted también simultáneamente deja 200$ y tiene la posibilidad del 50 % de la ganancia y deja más 200$ para tener una posibilidad del 40 % de la ganancia. You put down $100 and have a 25% chance of winning. You also simultaneously put $200 down and have 50% chance of winning and put down another $200 to have a 40% chance of winning.

Y aquí está donde la diversión entra: Con la primera apuesta, hay una vuelta de la rueda y usted sabe si usted es un ganador o un perdedor. Si la estimación del desarrollo es correcta, usted es un ganador nueve veces de diez. If the estimate of the development is correct, you are a winner nine times out of ten.

Pero con el tres guión de apuesta, usted tiene tres vueltas de la rueda, y si una de las vueltas sube a un ganador, usted consigue la mitad de su dinero atrás de las otras dos apuestas. Por ejemplo, si una de las apuestas de 200$ sube a un ganador, usted recuperaría 150$ (el 50 % de 100$ y 200$). O sea, si el enfoque de Gary espera ser un ganador después de tres meses en el proyecto, entonces usted puede abandonar el enfoque de Eric y Larry.

¿Pero qué pasa si ninguna de las apuestas sube a un ganador? Ajá, bien si esto pasa, el casino permitirá que usted doble su apuesta y vuelta otra vez, tomando la mitad de la suma total de sus apuestas (250$) y permitiéndole girar otra vez (Con las posibilidades de éxito no saben hasta que las 3 primeras vueltas sean completadas). O sea, si después de tres meses, el API de Babooza totalmente chupa, y el equipo de Gary no puede hacer hasta un diario construye sin el compilador que entra en la histeria, entonces Paul puede tomar la decisión de lanzar a cada uno en el proyecto de Eric de refundir la vieja base de código. That is to say, if after three months, the API from Babooza totally sucks, and Gary's team can't even do a daily build without the compiler going into hysterics, then Paul can make the decision to throw everybody on Eric's project to rework the old code base.

En el corto el complejo, la asignación casi caótica de recursos en un ambiente de desarrollo de software tiene una mejor posibilidad en cuenta de un proyecto completado, y para un uso más efectivo de recursos de revelador. Tropecé a través de este descubrimiento generalmente por casualidad, cuando yo me quejaba de la insuficiencia de cartas gantt para describir exactamente lo que realmente entra en un entorno de desarrollo verdadero. Seguro, no esperé encontrar una prueba matemática para el comportamiento que vi en el PWS (software) la división de Creo. For sure, I didn't expect to find a mathematical proof for the behavior that I saw in the PWS (software) division of Creo.

Anyways, para mí esto es un descubrimiento realmente chulo, porque valida cada uno corren alrededor y hacen su propia cosa y vaya a tomar una decisión más tarde se acercan. Bien, supongo que las matemáticas validan la teoría. Hmmm, no sé si yo iba para tratar de "vender" este enfoque en una entrevista de trabajo o algo así. Hmmm, I don't know if I would to try to "sell" this approach in a job interview or something like that.

Aclamaciones, Pinchadiscos

P.S. Si, en la literatura de desarrollo de software, alguien se ha encontrado con ideas similiar a estos presentados encima, por favor déjeme caer un correo electrónico entonces puedo conectar con ella. Es completamente posible (tal vez hasta probable) que esta "Anarquía es la" teoría Buena ha sido descubierto ya y soy ignorante sólo de ello. Thx. It's quite possible (maybe even probable) that this "Anarchy is Good" theory has already been discovered and I am just ignorant of it. Thx.

El contenido para este sitio web es proporcionado por www.bluebutterfly