Published 17 years ago
(updated 13 years ago)
El Poker de la Planeación
En la actualidad la teoría y la práctica del diseño de software es todavía una mezcla sui géneris entre arte-artesanía y ciencia-ingeniería donde la precisión matemática es tan relevante como el atractivo emocional. El lado técnico del diseño de software se asimila mejor familiarizándose con el proceso creativo de obras que provienen exclusivamente de la lógica y cuyas propiedades por ende no están definidas en el campo de la física (con excepción quizá de la medida del desorden observado en las dependencias en, desde y hacia dicho software).
El diseñador de software desarrolla y ejerce su talento desde su fuero interno en donde encuentra la materia prima del software mismo sujeto de diseño: la lógica, como los principios de la inferencia lícita y los criterios de la demostración válida que investigan y clasifican la estructura de las declaraciones y de los argumentos. Las propiedades de la materia prima de un producto cualquiera moldean las posibilidades de lo que puede llegar a convertirse y la manera en que alcanza su función. Por lo tanto, el conocimiento detallado de las propiedades de la materia prima y de los bloques prefabricados es esencial para un buen diseño; donde los bloques prefabricados aquí son el software previamente escrito y disponible para ser reutilizado.
Siendo la lógica —la lógica simbólica en particular— parte de la materia prima en diseño de software entonces para un empleo adecuado de la misma es ineludible el dominio del lenguaje, sea este natural como el español o el inglés o sea artificial como Microsoft Visual C#, para lograr consistencia, validez y completitud en el software diseñado. No es sorpresa entonces que la actividad de diseño de software ofrezca mejores resultados cuando se realiza en un ambiente cooperativo donde los diseñadores emplean todo tipo de lenguaje y sus formas de expresión hablada o escrita para crear software de calidad. La importancia de la comunicación efectiva es imponente en diseño de software tan sólo seguida de la importancia de inventiva. Sin embargo, es paradójico descubrir que existe una imposibilidad intrínseca en la comunicación humana que nos libera de intentar una comunicación perfecta. Así, el desarrollo de software se convierte en un juego cooperativo de comunicación e invención con el cual cada proyecto no intentará lograr comunicación perfecta sino administrar la falta de completez en nuestra comunicación.
Calculando un proyecto de
desarrollo de software
La responsabilidad del cálculo de las variables económicas típicas de un esfuerzo serio para llevar a cabo X está en función del conocimiento y experiencia de quienes hacen dicho cálculo. Ese conocimiento incluye no solamente las expectativas sobre X sino también sus propiedades intrínsecas, es decir su naturaleza.
Tom DeMarco y Timothy Lister nos explican cómo la actividad del desarrollo de software es inherentemente diferente a la actividad de producción o manufactura. Ellos mencionan algunos efectos fatales que causa la mentalidad de producción o manufactura cuando se aplica al desarrollo de software y, sin embargo, cuán frecuente es el caso de grupos gerenciales que permiten moldear su pensamiento por una filosofía de administración enteramente derivada de los ambientes de producción o manufactura. Por brevedad, aquí presentaré —desde la perspectiva del cálculo de proyectos de desarrollo— sólo dos de las conclusiones de DeMarco y Lister: El planteamiento en producción o manufactura tiende a evitar que los individuos se pongan a pensar en el trabajo, a su vez, se inclina por empujar el esfuerzo hacia un enfoque ciento por ciento dedicado a la ejecución y a la conclusión de tareas bajo la excusa de que hay poco tiempo, como si hubiese alguna vez trabajo por hacer sin la presión del tiempo.
Un planteamiento que considera la naturaleza del desarrollo de software incluye tiempo suficiente para pensar en, por ejemplo, ¿debiéramos siquiera realizar esta tarea? y pensarlo en repetidas ocasiones. Un proyecto o un ambiente donde la reflexión —acerca del contexto y rumbo del esfuerzo— es alentada tienen mayor oportunidad de ofrecer predicciones más confiables. Después de todo ¿qué es un estimado?. Desde un punto de vista formal un estimado es una predicción basada en una valoración probabilística siempre sujeta a ser ajustada. El proyecto de alta prioridad que debe ofrecer los mejores beneficios económicos a todas las partes es precisamente el proyecto que no puede darse el lujo de privarse de dicho ambiente donde los individuos son estimulados a realizar reflexiones frecuentes.
El trabajo intelectual es diferente al trabajo mecánico y los errores provisionales —no permanentes— son una parte natural y sana de este tipo de trabajo. Los errores de esta clase proveen más oportunidades para el aprendizaje y mantener un ambiente donde no se permiten dichos errores sólo provoca que la gente adopte una actitud defensiva y de no intentar nada nuevo que tenga una ligera probabilidad de resultar mal. Dicho ambiente se provoca cuando se pretende automatizar el proceso intelectual tal como se automatiza un proceso mecánico —al estar este completamente entendido— o cuando se imponen metodologías rígidas que impiden a los individuos tomar cualquiera de las decisiones estratégicas por miedo a que se equivoquen. Por otro lado, un planteamiento más cercano a la realidad del desarrollo de software estimularía a los individuos a cometer este tipo de errores y ser felicitados cuando los cometan pues es, en parte, por lo que reciben su sueldo. Desde esta perspectiva introduzco a continuación una estrategia que puede ser llamada estimación iterativa.
Estimación iterativa
La idea básica es que cualquiera que publique un estimado es susceptible de mejorar dicha habilidad y así publicar estimados cada vez más útiles. Dicho con otras palabras, se sabe que algunos estimados son intrínsecamente propensos a estar del todo equivocados y tienen que ser rechazados, no ajustados, pues la actividad de estimación incluye tales callejones sin salida y el esfuerzo perdido puede mantenerse pequeño y ser considerado un error provisional.
La estimación iterativa puede ser percibida por algunos como una complicación política pues les parece difícil justificar el re-trabajo y prefieren creer que les irá mejor usando el estimado equivocado aún cuando podría costar mucho más al final de cuentas. La estimación iterativa es una técnica heurística, es decir, una técnica de indagación y descubrimiento; una manera de buscar la solución a un problema mediante métodos no rigurosos, por tanteo ó reglas empíricas. La estimación iterativa considera al menos cinco causas por las que las estimaciones son deficientes:
1. Escasez de destreza para estimar
2. Predisposición o imparcialidad no considerada en la estimación
3. Poco entendimiento del significado de un estimado
4. Uso inadecuado de políticas que obstaculizan una buena estimación
5. Escasez de métricas de estimación para referencia
No debiera suceder una sola vez al inicio de un proyecto pues su mayor valor se obtiene al repetirla por cada agrupación de alcance funcional detallado en que haya sido dividido el proyecto. Una técnica para ejecutar la estimación iterativa se llama poker de planeación. La granularidad del alcance funcional determina dos niveles de planeación: de grano grueso, y de grano fino. El nivel de planeación de grano grueso abarca funciones generales de alto nivel y representa ciclos usualmente en la escala de meses. El nivel de grano fino abarca funciones detalladas que son implementables en ciclos típicamente en la escala de semanas. Los ciclos de desarrollo de grano fino inician con la ejecución del poker de planeación y terminan con una versión interina de la solución en desarrollo que incluye la implementación de las funciones estimadas en el poker de planeación inicial. Los ciclos de desarrollo de grano grueso simplemente son agrupadores de ciclos de grano fino y terminan con la liberación de una versión pública de la solución en desarrollo.
¿Cómo mejorar tus
estimaciones?
La variedad de técnicas existentes para desarrollar una estimación pueden ser de ayuda siempre y cuando se decida analizar su utilidad en el debido contexto, depende de usted estimado lector. A continuación resumo brevemente la técnica de poker de planeación para su consideración cuando le pregunten ¿cuándo... ó cuánto...?, y que también le pueden servir para valorar la calidad de la respuesta cuando sea usted quien hace la pregunta.
La técnica puede tener aplicación general, pero en realidad están orientados para proyectos de desarrollo de soluciones de software, además se asume que los puntos esenciales para mejorar el ¿qué desarrollar? ya han sido debidamente considerados en forma de una especificación funcional. El poker de planeación incluye como participantes a todo el personal técnico posible del grupo de proyecto incluyendo desarrolladores, arquitectos, testers, DBAs, etcétera. Al inicio del poker de planeación se le ofrece a cada estimador un mazo de cartas donde cada carta tiene escrito un valor estimado válido: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 16, 20, y 40. Los números deberán ser suficientemente grandes para verse desde el otro extremo de una mesa. Los números representan el tamaño funcional relativo de lo que se va a estimar y lo importante es que se mantenga consistencia entre los tamaños relativos, es decir, una función con tamaño 2 debe representar el doble de funcionalidad de una función con tamaño 1.
Los roles son el moderador, el dueño del producto y los estimadores. El dueño del producto es similar al rol gerente de producto en MSF. Por cada función, caso de uso o característica a ser estimada el moderador lee en voz alta la descripción. El dueño del producto contesta cualquier pregunta que tengan al respecto los estimadores. Después de ser contestadas todas las preguntas para esa función, cada estimador selecciona una carta en forma privada y que represente su tamaño funcional estimado.
Las cartas permanecen privadas hasta que todos los estimadores hayan hecho su elección. Entonces, todas las cartas son mostradas simultáneamente de tal forma que todos los participantes pueden verlas. Es muy probable que en este punto los estimados varíen significativamente y esto, de hecho, son buenas noticias. Si estos difieren, los estimadores con las evaluaciones más bajos y más altos proceden a explicar su estimado. Nótese que no se trata de criticar o atacar a estos estimadores en este punto, sino de escuchar y entender cuáles fueron sus criterios.
El grupo puede discutir la función bajo estimación por algunos minutos, durante los cuales se pueden tomar notas de puntos importantes para el momento de estar implementando dicha función. Después de la discusión, cada estimador revalora y realiza nuevamente un estimado seleccionando la carta correspondiente de manera privada. Las cartas permanecen privadas hasta que todos hayan evaluado y entonces todas las cartas son mostradas simultáneamente. Para la segunda vuelta es probable que los estimados hayan convergido, pero sino, será necesario repetir el proceso. El objetivo es que estos converjan en un solo estimado para la función en cuestión. No es absolutamente necesario que todos coincidan en un solo número, lo importante es que exista consenso.
Referencias
[ Agile Software Development. The
Cooperative Game by Alistair Cockburn ]
[ Peopleware. Productive Projects and
Teams by Tom DeMarco y Timothy Lister ]
[ Controlling Software Projects.
Management, Measurement and
Estimation by Tom DeMarco ]
[ Agile Estimating and Planning by Mike Cohn ]
Acerca del Autor
Marco Dorantes es consultor en el diseño y formulación de software desde 1987. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software disponibles en www.xprogramming.com Publica un diario electrónico en blogs.msdn.com/marcod]
En la actualidad la teoría y la práctica del diseño de software es todavía una mezcla sui géneris entre arte-artesanía y ciencia-ingeniería donde la precisión matemática es tan relevante como el atractivo emocional. El lado técnico del diseño de software se asimila mejor familiarizándose con el proceso creativo de obras que provienen exclusivamente de la lógica y cuyas propiedades por ende no están definidas en el campo de la física (con excepción quizá de la medida del desorden observado en las dependencias en, desde y hacia dicho software).
El diseñador de software desarrolla y ejerce su talento desde su fuero interno en donde encuentra la materia prima del software mismo sujeto de diseño: la lógica, como los principios de la inferencia lícita y los criterios de la demostración válida que investigan y clasifican la estructura de las declaraciones y de los argumentos. Las propiedades de la materia prima de un producto cualquiera moldean las posibilidades de lo que puede llegar a convertirse y la manera en que alcanza su función. Por lo tanto, el conocimiento detallado de las propiedades de la materia prima y de los bloques prefabricados es esencial para un buen diseño; donde los bloques prefabricados aquí son el software previamente escrito y disponible para ser reutilizado.
Siendo la lógica —la lógica simbólica en particular— parte de la materia prima en diseño de software entonces para un empleo adecuado de la misma es ineludible el dominio del lenguaje, sea este natural como el español o el inglés o sea artificial como Microsoft Visual C#, para lograr consistencia, validez y completitud en el software diseñado. No es sorpresa entonces que la actividad de diseño de software ofrezca mejores resultados cuando se realiza en un ambiente cooperativo donde los diseñadores emplean todo tipo de lenguaje y sus formas de expresión hablada o escrita para crear software de calidad. La importancia de la comunicación efectiva es imponente en diseño de software tan sólo seguida de la importancia de inventiva. Sin embargo, es paradójico descubrir que existe una imposibilidad intrínseca en la comunicación humana que nos libera de intentar una comunicación perfecta. Así, el desarrollo de software se convierte en un juego cooperativo de comunicación e invención con el cual cada proyecto no intentará lograr comunicación perfecta sino administrar la falta de completez en nuestra comunicación.
Calculando un proyecto de
desarrollo de software
La responsabilidad del cálculo de las variables económicas típicas de un esfuerzo serio para llevar a cabo X está en función del conocimiento y experiencia de quienes hacen dicho cálculo. Ese conocimiento incluye no solamente las expectativas sobre X sino también sus propiedades intrínsecas, es decir su naturaleza.
Tom DeMarco y Timothy Lister nos explican cómo la actividad del desarrollo de software es inherentemente diferente a la actividad de producción o manufactura. Ellos mencionan algunos efectos fatales que causa la mentalidad de producción o manufactura cuando se aplica al desarrollo de software y, sin embargo, cuán frecuente es el caso de grupos gerenciales que permiten moldear su pensamiento por una filosofía de administración enteramente derivada de los ambientes de producción o manufactura. Por brevedad, aquí presentaré —desde la perspectiva del cálculo de proyectos de desarrollo— sólo dos de las conclusiones de DeMarco y Lister: El planteamiento en producción o manufactura tiende a evitar que los individuos se pongan a pensar en el trabajo, a su vez, se inclina por empujar el esfuerzo hacia un enfoque ciento por ciento dedicado a la ejecución y a la conclusión de tareas bajo la excusa de que hay poco tiempo, como si hubiese alguna vez trabajo por hacer sin la presión del tiempo.
Un planteamiento que considera la naturaleza del desarrollo de software incluye tiempo suficiente para pensar en, por ejemplo, ¿debiéramos siquiera realizar esta tarea? y pensarlo en repetidas ocasiones. Un proyecto o un ambiente donde la reflexión —acerca del contexto y rumbo del esfuerzo— es alentada tienen mayor oportunidad de ofrecer predicciones más confiables. Después de todo ¿qué es un estimado?. Desde un punto de vista formal un estimado es una predicción basada en una valoración probabilística siempre sujeta a ser ajustada. El proyecto de alta prioridad que debe ofrecer los mejores beneficios económicos a todas las partes es precisamente el proyecto que no puede darse el lujo de privarse de dicho ambiente donde los individuos son estimulados a realizar reflexiones frecuentes.
El trabajo intelectual es diferente al trabajo mecánico y los errores provisionales —no permanentes— son una parte natural y sana de este tipo de trabajo. Los errores de esta clase proveen más oportunidades para el aprendizaje y mantener un ambiente donde no se permiten dichos errores sólo provoca que la gente adopte una actitud defensiva y de no intentar nada nuevo que tenga una ligera probabilidad de resultar mal. Dicho ambiente se provoca cuando se pretende automatizar el proceso intelectual tal como se automatiza un proceso mecánico —al estar este completamente entendido— o cuando se imponen metodologías rígidas que impiden a los individuos tomar cualquiera de las decisiones estratégicas por miedo a que se equivoquen. Por otro lado, un planteamiento más cercano a la realidad del desarrollo de software estimularía a los individuos a cometer este tipo de errores y ser felicitados cuando los cometan pues es, en parte, por lo que reciben su sueldo. Desde esta perspectiva introduzco a continuación una estrategia que puede ser llamada estimación iterativa.
Estimación iterativa
La idea básica es que cualquiera que publique un estimado es susceptible de mejorar dicha habilidad y así publicar estimados cada vez más útiles. Dicho con otras palabras, se sabe que algunos estimados son intrínsecamente propensos a estar del todo equivocados y tienen que ser rechazados, no ajustados, pues la actividad de estimación incluye tales callejones sin salida y el esfuerzo perdido puede mantenerse pequeño y ser considerado un error provisional.
La estimación iterativa puede ser percibida por algunos como una complicación política pues les parece difícil justificar el re-trabajo y prefieren creer que les irá mejor usando el estimado equivocado aún cuando podría costar mucho más al final de cuentas. La estimación iterativa es una técnica heurística, es decir, una técnica de indagación y descubrimiento; una manera de buscar la solución a un problema mediante métodos no rigurosos, por tanteo ó reglas empíricas. La estimación iterativa considera al menos cinco causas por las que las estimaciones son deficientes:
1. Escasez de destreza para estimar
2. Predisposición o imparcialidad no considerada en la estimación
3. Poco entendimiento del significado de un estimado
4. Uso inadecuado de políticas que obstaculizan una buena estimación
5. Escasez de métricas de estimación para referencia
No debiera suceder una sola vez al inicio de un proyecto pues su mayor valor se obtiene al repetirla por cada agrupación de alcance funcional detallado en que haya sido dividido el proyecto. Una técnica para ejecutar la estimación iterativa se llama poker de planeación. La granularidad del alcance funcional determina dos niveles de planeación: de grano grueso, y de grano fino. El nivel de planeación de grano grueso abarca funciones generales de alto nivel y representa ciclos usualmente en la escala de meses. El nivel de grano fino abarca funciones detalladas que son implementables en ciclos típicamente en la escala de semanas. Los ciclos de desarrollo de grano fino inician con la ejecución del poker de planeación y terminan con una versión interina de la solución en desarrollo que incluye la implementación de las funciones estimadas en el poker de planeación inicial. Los ciclos de desarrollo de grano grueso simplemente son agrupadores de ciclos de grano fino y terminan con la liberación de una versión pública de la solución en desarrollo.
¿Cómo mejorar tus
estimaciones?
La variedad de técnicas existentes para desarrollar una estimación pueden ser de ayuda siempre y cuando se decida analizar su utilidad en el debido contexto, depende de usted estimado lector. A continuación resumo brevemente la técnica de poker de planeación para su consideración cuando le pregunten ¿cuándo... ó cuánto...?, y que también le pueden servir para valorar la calidad de la respuesta cuando sea usted quien hace la pregunta.
La técnica puede tener aplicación general, pero en realidad están orientados para proyectos de desarrollo de soluciones de software, además se asume que los puntos esenciales para mejorar el ¿qué desarrollar? ya han sido debidamente considerados en forma de una especificación funcional. El poker de planeación incluye como participantes a todo el personal técnico posible del grupo de proyecto incluyendo desarrolladores, arquitectos, testers, DBAs, etcétera. Al inicio del poker de planeación se le ofrece a cada estimador un mazo de cartas donde cada carta tiene escrito un valor estimado válido: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 16, 20, y 40. Los números deberán ser suficientemente grandes para verse desde el otro extremo de una mesa. Los números representan el tamaño funcional relativo de lo que se va a estimar y lo importante es que se mantenga consistencia entre los tamaños relativos, es decir, una función con tamaño 2 debe representar el doble de funcionalidad de una función con tamaño 1.
Los roles son el moderador, el dueño del producto y los estimadores. El dueño del producto es similar al rol gerente de producto en MSF. Por cada función, caso de uso o característica a ser estimada el moderador lee en voz alta la descripción. El dueño del producto contesta cualquier pregunta que tengan al respecto los estimadores. Después de ser contestadas todas las preguntas para esa función, cada estimador selecciona una carta en forma privada y que represente su tamaño funcional estimado.
Las cartas permanecen privadas hasta que todos los estimadores hayan hecho su elección. Entonces, todas las cartas son mostradas simultáneamente de tal forma que todos los participantes pueden verlas. Es muy probable que en este punto los estimados varíen significativamente y esto, de hecho, son buenas noticias. Si estos difieren, los estimadores con las evaluaciones más bajos y más altos proceden a explicar su estimado. Nótese que no se trata de criticar o atacar a estos estimadores en este punto, sino de escuchar y entender cuáles fueron sus criterios.
El grupo puede discutir la función bajo estimación por algunos minutos, durante los cuales se pueden tomar notas de puntos importantes para el momento de estar implementando dicha función. Después de la discusión, cada estimador revalora y realiza nuevamente un estimado seleccionando la carta correspondiente de manera privada. Las cartas permanecen privadas hasta que todos hayan evaluado y entonces todas las cartas son mostradas simultáneamente. Para la segunda vuelta es probable que los estimados hayan convergido, pero sino, será necesario repetir el proceso. El objetivo es que estos converjan en un solo estimado para la función en cuestión. No es absolutamente necesario que todos coincidan en un solo número, lo importante es que exista consenso.
Referencias
[ Agile Software Development. The
Cooperative Game by Alistair Cockburn ]
[ Peopleware. Productive Projects and
Teams by Tom DeMarco y Timothy Lister ]
[ Controlling Software Projects.
Management, Measurement and
Estimation by Tom DeMarco ]
[ Agile Estimating and Planning by Mike Cohn ]
Acerca del Autor
Marco Dorantes es consultor en el diseño y formulación de software desde 1987. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software disponibles en www.xprogramming.com Publica un diario electrónico en blogs.msdn.com/marcod]
- Log in to post comments