El Chaos Report. Hacia los lotes pequeños... y los métodos ágiles.

"Lesser fiery copper Lycaena thersamon (female)" by Charlesjsharp - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

Antecedentes del reporte

Leí el reporte recomendado por Alejandro García el Viejo hace un par de semanas. Tal vez estoy demasiado influenciado por los métodos ágiles, pero creo que si mapeamos cada uno de los reportes tanto en los errores comúnmente cometidos, como en las mejores prácticas es muy probable que el uso de estos métodos este muy relacionado con la mayor parte de las razones de la mejora de la tasa de éxito en proyectos. Lo cual es una buena noticia.

• El Chaos Report tien una base de datos casi de 50,000 proyectos. 60% de estos proyectos provienen de USA, 25% de Europa y el 15% de proyectos del resto del mundo.Un poco más del 50% de estos proyectos son de las top 1000, 30 por ciento de medianas empresas y 20% de PYMES. 39% de los proyectos tuvieron éxito, 43% no cumplieron con la meta inicial y 18% fallaron. Sin embargo la tasa es mayor que en 2009, ya que este año 29% de los proyectos fueron exitosos.
• El incremento en la tasa de éxito se debe a varios factores, pero el principal es “el incremento en número de proyectos ágiles y pequeños”. Varias buenas prácticas están siendo utilizadas, como el hacer un análisis postmorten, más de 90% de organizaciones realizan esta práctica.
• El punto de apalancamiento más importante para la mejora de la tasa de éxito es el “incremento de la competencia· del patrocinador ejecutivo o product owner, haciendo referencia a Scrum. Este rol se convierte en el “Chief enabling officer”. Siendo el principal catalizador del proyecto dentro de la compañía.
• Más compañías enfocan en actividades que generan más valor, en lugar de enfocarse en la totalidad de los requerimientos.
• El análisis del presente año sugiero que existe funcionalidad que no se utiliza que va desde el 20% del proyecto hasta el 50%!!!!! Aquí aplica la ley de Paretto. El 20% de la funcionalidad aporta el 80% del valor de producto. Reducir el alcance pues, según el reporte, no solo es una estrategia valida, sino “LA MÁS PRUDENTE”. Menos es más dirían nuestros amigos finlandeses.
• Los proyectos ENORMES no son necesarios. La premisa es romper estos proyectos en mini proyectos. La propia portada del Chaos Manifest es una mafiosa, haciendo referencia al “efecto mariposa” que tiene un impacto...
• PIENSA EN GRANDE, ACTUA EN PEQUEÑO.
• La recomendación del Standish Group es “limitar el tamaño y la complejidad de un proyecto”, lo más que se pueda. La solución rápida podría ser no aceptar proyectos grandes, pero una más sensata es adoptar una serie de proyectos pequeños que contribuyan a una meta grande. Los proyectos frecuentemente son demasiados grandes para tener éxito.

Factores de éxito y su ponderación para proyectos pequeños

A continuación un análisis a detalle de cada uno de los factores que influyen en el éxito de los proyectos pequeños.

1. Soporte ejecutivo (20 puntos). En proyectos pequeños el patrocinador puede ser un administrador de nivel medio o un producto owner haciendo referencia a SSCRUM. NO SE REQUIERE UN PLAN DETALLADO por ser un proyecto pequeño. La negociación es mínima. Un VISION STATEMENT de una o dos páginas es suficiente para que un proyecto sea aprobado o rechazado rápidamente. La habilidad que más impacta y que debe ser altamente dominada es IDENTIFICAR que motiva al equipo. FACTOR CRÍTICO: El 78% de los proyectos pequeños que están alineados con la estrategia de negocio, TIENEN ÉXITO.
2. Participación del cliente (15 puntos). Los proyectos tienen el fin de construir un proceso, producto o servicio que la gente utilizará. Una pregunta importante sería, se ha identificado el valor que aportará este producto o servicio para ellos? El patrocinador debería ser un usuario primario que comprendiera perfectamente lo que el usuario final necesitará o sea un product owner. Los proyectos pequeños no rehuyeren un alto expertise por parte de los product owners debido al alcance y tamaño del proyecto. La falta de comunicación en un proyecto grande es mayor, un proyecto pequeño permite manejar esto de una manera más cómoda. FACTOR CRÍTICO: el identificar el expertise real en un usuario.
3. Optimización (15 puntos). "Less is more". La esencia de un proyecto pequeño es un alcance pequeño, el tamaño hace realmente una diferencia en la tasa del éxito del proyecto. Como dice la ley de Paretto el 20% de la funcionalidad aporta el 80% del valor, por tal razón esta debe ser construida así. FACTOR CRÍTICO: contar con una lista de entregables determinados por el propio alcance del proyecto.
4. Mano de obra calificada (13 puntos). Tener mano de obra calificada no solo permite una mayor probabilidad de éxito, sino que conduce a mejores costos. Cuando se agrega personal a un proyecto este tiende a retrasarse, descrito por la Ley de Brooks. FACTOR CRÍTICO: la mayor parte de los miembros del equipo de los proyectos analizados tienen un nivel que va de competente a talentoso o virtuoso. Solo un 10% de los participantes fueron evaluados como no competentes.
5. Experiencia en gestión de proyectos (12 puntos). Debido a que los proyectos son pequeños, un administrador de proyectos puede administrar varios proyectos a la vez. FACTOR CRÍTICO: simplificar el procesos de gestión del proyecto para que pueda ejecutarse.
6. Métodos ágiles (10 puntos). La solución universal para el fallo en proyectos de desarrollo de sw son los métodos ágiles que manejan naturalmente proyectos pequeños. Y que utilizan el desarrollo iterativo. LOS PROYECTOS QUE SON RIGIDOS TIENEN UNA ALTA PROBABILIDAD DE CANCELARSE. FACTOR CRITICO: El Product Owner es el rol responsable de la ejecución del proyecto.
7. Objetivos claros (6 puntos). La claridad y el enfoque son esenciales para proyectos exitosos. Las standup meetings actúan como una junta de status del proyecto. Un enfoque ligero se centra en artículos de alto valor que mantienen la innovación sin sobrecargar administrativamente a la organización. FACTOR CRITICO: La comprensión de la visión de los stakeholders.
8. Madurez emocional (5 puntos). La madurez emocional se relaciona con el autoconocimiento tanto personal como social, la auto administración y el manejo de relaciones. “Confía en tu equipo, pero revisa los resultados. -Ronald Reagan”. FACTOR CRITICO: En su mayoría, la gente percibe como no sinceras a las personas. Solo el 4% las considera sinceras.
9. Ejecución (3 puntos). La ejecución es el arte de completar las actividades en función de un plan. Los proyectos pequeños dan la oportunidad al equipo de salirse de su zona de confort y tomar más riesgos. Los proyectos pequeños te permiten. Aun los proyectos pequeños tienen que terminarse en tiempo y medirse de manera adecuada.
10. Herramientas e infraestructura (1 punto). Cuando se trata de infraestructura menos es más. Menos herramientas ayudan a los pequeños proyectos a terminarse más rápido. La cuestión más critica de este aspecto es la infraestructura y procesos estándar para proyectos pequeños. La filosofía de buscar siempre tener menos herramientas y utilizar servicios de nube. NOTA . El pasar de pocos proyectos de muchos millones a pocos proyectos puede incrementar el número de proyectos de manera exponencial. Hay un límite en la capacidad de gestión de proyectos de los equipos,

En resumen

En resumen, muy pocos proyectos grandes son exitosos. En cambio los proyectos pequeños tienen más del 70% de probabilidades de terminar en tiempo, con el presupuesto establecido y que cuentan con los requerimientos de más valor implementados. No es fácil pasar de macro proyectos a pequeños proyectos, de soluciones complejas a soluciones sencillas.

Porque es útil este reporte para el anteproyecto de tesis

• Existe una gran cantidad de información sobre buenas prácticas y sobre proyectos fallidos. El Chaos Report es una de las fuentes más citadas en cuanto al éxito y fracaso de proyectos de software se refiere. Es un reporte fundamental que debe ser considerado en este tipo de proyectos.
• SCRUM mapa una buena parte de los 10 factores de éxito de una manera sencilla.
• Si lo analizáramos con PSP es probable que también manejara ciertos aspectos.
• Less is more, pero solo para los demás. En ocasiones reiteradas en el reporte se menciona el principio de “Less is more”. Sin embargo, cada uno de los factores de éxito mencionados en el reporte tiene otros 10 puntos críticos para el manejo de ese aspecto en particular. Al contrario que técnicas como Kanban con tres principios solamente, al final terminan siendo 100 principios que deben “gestionares” para incrementar la tasa de éxito de proyectos pequeños.
• El Standish Group tiene una serie de herramientas y software para gestionar los factores de éxito detectados. Por lo cual dentro de varios de los puntos se menciona y se dan ejemplos de la interfaz del software sugerido para festinar el factor.

Referencias

• The Chaos Manifesto 2013. (2013). Boston, Massachusetts. Retrieved from http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf

¿Cómo mejorar la industria del Sw de manera sencilla?

De acuerdo al CHAOS Report 2012 el 43% de los proyectos son “Challenged” (fuera de tiempo, presupuesto, o alcance) y el 18% son cancelados. Y casi ninguno de estos fracasos es analizado. El no analizar estos errores impide que aprendamos, para no volver a cometerlos.

El transporte aéreo tiene una tasa de 0.05 muertes por cada mil millones de kilómetros recorridos. Es una industria que ha mejorado continuamente en la seguridad. El día de hoy es más segura que hace 20 años. Y la razón principal es que el 100% de los accidentes o averías importantes son analizados y convertidos a estándares de seguridad obligatorios. No sucede así en la industria del software. 

En su blog, Bertrand Meyer hace reflexiones contundentes sobre la diferencia entre las dos industrias. A pesar de que existen foros y sitios web que recopilan errores existen muy pocos analizados a profundidad, ejemplo de estos son: el caso de estudio de  Nancy Leveson sobre la Therac-25 y el análisis de Gilles Kahn sobre el accidente del Arian 5. Estos análisis son la excepción. Ambos casos han contribuido a un mejor entendimiento de la industria del software.

No existe una receta única para el éxito en los proyectos de software, generalizando, no existe una receta única para el éxito, como menciona Kough (2011),  “después de una vida en los negocios no puedo dar una receta del éxito, Lo que puedo hacer es hablar acerca de cómo perder. Y garantizo que cualquiera que siga esta fórmula será un perdedor seguro“. El detectar las causas de los fallos y evitarlas asegura en consecuencia mejores resultados. 

Patrick Eha (2012)  hace referencia a la pérdida de 440 millones de dólares por un error en un sistema automático de trading en Nueva York. Pero en ningún lugar se menciona cuales fueron las causas. El análisis sistemático de estos errores podría detectar causas clave: capacidad de los desarrolladores, métodos de calidad poco estrictos, procesos de seguridad deficientes. 

Existen muchas maneras de contribuir a la mejora de la industria del software, la investigación sobre temas de avanzada es una de ellas; Meyer(2009) enfatiza que la manera práctica, de baja tecnología es “ aprobar una ley que obligue a analizar de manera profesional cualquier fallo en un proyecto de software”. 

De inicio hay varias restricciones que deben ser consideradas: la iniciativa privada es renuente a hacer públicas sus fallas, por cuidar el prestigio de su empresa. La hipótesis es que una ley general a nivel nacional o estatal que requiera que analicen los proyectos de software implica cabildeo legislativo y una gran cantidad de recursos. Pero de inicio, los proyectos finalizados que tengan como fuente de financiamiento en México son públicos por la propia Ley Federal de Transparencia o sus equivalentes en los estados de la República. Estos proyectos pueden ser un inicio. Este sería el enfoque top down.

Planeamos hacerlo de otra manera. El desarrollo de casos de negocio basado en proyectos reales de software, así como la recopilación de artículos y bibliografía existentes sobre proyectos fallidos de software y la construcción de un observatorio de estos proyectos fallidos pueden contribuir para el conocimiento real. 

Casi cuarenta años después de la publicación del Mythical Man Month de Frederick Brooks seguimos fallando de la misma manera. Existen varias fuentes de información relacionadas con proyectos fallidos de software: libros, artículos, algunos análisis profundos de fallos en la industria del software en proyectos costosos o críticos a nivel mundial. Pero está información no está disponible para la industria del software de manera directa. Ello hace necesaria un mecanismo para la promoción de los aprendizajes obtenidos del análisis de proyectos fallidos. 

Un mecanismo para ello, puede ser la Gestión del Conocimiento puede proveer la base para que está información esté consolidada en un solo lugar y la creación de un Observatorio de Proyectos de Software Fallidos. Siendo una buena idea en el contexto Mundial, el propio contexto de México y Latino América, donde existe una gran cantidad de PYMES que desarrollan software y que cometen errores en su propio contexto requiere un análisis profundo de fallos de software en este nivel. Así pues el alcance se reduce y es más real. 

Referencias:

• Meyer, Bertrand (2009, Agosto). The one sure way to advance software engineering. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2009/08/21/the-one-sure-way-to-advance-software-engineering/
• Meyer, Bertand (2010, Mayo).  Analyzing Software Failure. Blog post consultado el 30 de julio de 2014 de http://bertrandmeyer.com/2010/05/24/analyzing-a-software-failur
• Patrick Eha, Bryan (2012, Agosto). Los errores informáticos más costosos. Artículo electrónico consultado el 30 de julio de 2014 de http://www.cnnexpansion.com/economia/2012/08/10/los-errores-informaticos-mas-costosos

Conversaciones con El Viejo: Liderazgo educativo y buenos maestros

El día de hoy, fuimos por un café a Azul Maya. Un café gourmet que se encuentra cerca de Santo Domingo. El tráfico fue ligero, ya los niños salieron de vacaciones. En el transcurso del camino platicamos sobre los siguientes temas: 

1) Los maestros debemos enseñar lo correcto. Un estudiante ganador de la medalla de bronce en la olimpiada mundial de matemáticas se sintió defraudado de su educación por que no pudo contestar ninguno de los 13 problemas de matemáticas que los rusos propusieron en un examen para entrar a prepa (medalla de bronce en la olimpiada internacional). 

2) No estamos en la punta de la tecnología. En Morelia enseñan Scratch en secundaria. 

3) Toda la naturaleza trabaja en base a fractales. 

Debemos reflexionar como podemos incluir esto en la materia de programación de prepa, como alternativa para los fractales que desarrollan utilizando arte generativo.

4)  Lo barato de los cafés zacatecanos vs Starbucks

Acropolis: 2 chocolates y dos vasos de agua : $55 pesos

Nápoles en Jardín de Guadalupe: 4 cafés: $75 pesos

Debería ser más caro un café en una galería de artes como el Acropolis a un café comercial como Starbucks. El café azula maya es de altísima calidad y cuesta $20 pesos un capuchino grande. 

5) Tienen derecho a quejarse. Lo que buscan los trabajadores de conocimiento es control. Muchas veces no están satisfechos con su trabajo por el poco control. Sin embargo yo pienso que una actitud proactiva puede generar control sobre lo que haces.

6) Los líderes tecnológicos son Harvard, MIT, Monash. En el TEC la currícula va a incluir cuatro materias de computación. La computación es una manera diferente de aprender matemáticas.

7) Porque está bien valorada la clase de Computación del TEC. 1) Aspecto es el re diseño de la clase. Desde hace un parte años. Yo he pensado de manera personal que la orientación a competencias es necesaria. El ver que es lo que deben de aprender a resolver los alumnos es algo importante. 

8) Hablamos también de como los maestros, como el maestro de gimnasia de Mariano, que les enseñaba mostrandoles con el ejemplo lo que deberían de hacer, haciendo maromas, entre otras cosas. Es una buena técnica pedagógica. Ahora en el taller de Cynthia Valdez, campeona panamericana en gimnasia artística, en el taller impartido en Zacatecas, en diciembre del presente año, les decía a sus niños. Veanme y luego lo hacen Uds. Pensé en regalarles a los maestros el libro "The Inner Game of Tennis". Pues habla de como una maestro de tenis enseñaba a sus alumnos simplemente la técnica golpeando la pelota. Y de la efectividad de esta técnica.

9) La responsabilidad civil. En EU cuando sucede un accidente y una persona se acerca a ayudar, tiene la responsabilidad de hacerlo hasta que lo deje en el hospital. Si no es así, y se acerca y luego se aleja, está impidiendo que alguien más ayude al afectado. Igual que ocurre con los proyectos.

10) Inteligencia emocional interpersonal. En ocasiones oyes, pero no escuchas. Luego llegamos con: ah, se me acaba de ocurrir algo: los métodos ágiles es lo que funciona. Cuando el Viejo lo ha mencionado, casi en cualquier conversación de la que hablamos. 

Preparando presentación "Perspectivas de un Ingeniero en Sistemas Computacionales en el mundo laboral actual"

Gracias a la invitación ahora de la Universidad Politécnica de Zacatecas, con sede en Fresnillo a hablar sobre el tema de "Perspectivas de un Ingeniero en Sistemas Computacionales en el mundo laboral actual".

Este es mi guión... El cual fui construyendo siguiendo la guía del libro de Cal Newport "So Good They Can't Ignore You", además del post del mismo nombre de Derek Sivers... Al final, el guión quedó como sigue...

0) Las perspectivas vistas hacia el momento son:

Jobs in Stanford:

3) So good they can't ignore you... -Steve Martin. Del libro del mismo nombre de Cal Newport...

1.3.2 Demostrar iniciativa al hacer algo interesante.

1.3.3 Hablar inglés.

2.1) El clúster de TI de Zacatecas y otras empresas

3) Academia

"El mundo es suyo, pero tienen que ganárselo"... Ok... Pero como empezar: "con pequeñas apuestas"... 

0.1) Experiencia de trabajo en el extranjero (Alejandro)

0.2) Desarrollo de su propia empresa (Alejandro)

0.3) Trabajo en una empresa

0.4) Continuar en la academia

1) Frase de seguir tu pasión...

2) Video, para que lo vean luego en la presentación...

1.1) El jubilarse en un trabajo ya no es una opción... La gente promedio cambia de trabajo de 5 a 6 veces de trabajo...

1.2) Impacto, control y creatividad son los grandes componentes de un trabajo.

Pero para obtenerlo tenemos que cambiar nuestro enfoque: If you want to love what you do, abandon the passion mindset ("what can the world offer me?") and instead adopt the craftsman mindset ("what can I offer the world?").

1.3 Cómo obtener un trabajo? Desarrollar capital...

"you need to be good at something before you can expect a good job"... Derek Sivers.

1.3.1 Proyectos open source.

1.4 Ello implica que cualquier lugar es bueno para desarrollarnos. Siempre y cuando...

1. The job presents few opportunities to distinguish yourself by developing relevant skills that are rare and valuable.

2. The job focuses on something you think is useless or perhaps even actively bad for the world.

3. The job forces you to work with people you really dislike.

2.1.1) Software... Softlogik (PHP-Yii), Zacsoft(Apps, JAVA) y Quarksoft (CMMi, PSP)

2.1.2) Marketing Digital... Zacateks y WSI - Community Manager

2.1.3) Servicios de TI... Lasec (Redes) y Compulogic (Redes, Telefonía IP, Monitoreo, Videoconferencia, etc.)

2.2) Sector público. Lo bueno de trabajar en Gobierno es que para donde quiera que voltees es un área de oportunidad. 

2.4) Otros sectores como Minería y Turismo

A nivel nacional...

GRANDES Softek, Hildebrando... - Fábricas de software

PEQUEÑAS Y ÁGILES... Crowd Interactive... - 

3.1) Maestría en Ingeniería de Software (CIMAT)

3.2) Veranos científicos (BECA CONACYT) 

3.2.1) Interés de algún investigador.

Ejemplo:

1) Invertir 3 meses en un proyecto para ver si funciona.

2) Invertir x cantidad de dinero en la inversión de un proyecto.

Y el Prezi quedó así...

Preguntas rápida: si quiero aprender sobre diseño de software que debo hacer?

Viejo, si quiero saber sobre diseño de Sw. Que sería lo mejor.

mira los diseños modernos de software se hacen con este libro:

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?ie=UTF8&qid=1373048630&sr=8-1&keywords=domain+driven+design

infoq tiene este resumen:
http://www.infoq.com/minibooks/domain-driven-design-quickly

Primero hay que leer el de InfoQ, que son 100 páginas.

#VíaElViejo.

Lo que todos los Ingenieros de Sw deben leer acerca de requerimientos...

Pepe: Alex, ¿tendrás alguna recomendación sobre artículos del tema de requerimientos?

(Dos horas después)

El Viejo:

Estos son artículos de Requerimientos de Software de algunos de mis clásicos

Erik Sink
http://www.ericsink.com/articles/Requirements.html

Joel (de Joel On Software y Stack Overflow)
http://www.joelonsoftware.com/articles/fog0000000033.html
OK, we've talked about  why you need a spec, what a spec has in it,
and who should write them. In this fourth and final part of the series
I'll share some of my advice for writing good specs.

esa es una serie de 4 artículos chiquitos sobre documentos de
especificación de requerimientos. que hizo en el año 2000

Aunque en el 2008 cuando crearon StackOverflow... el escribió algo así
como: Todo lo que creía sobre desarrollo de software estaba un poco
mal... incluyendo documentos de requerimientos.

http://www.inc.com/magazine/20081101/how-hard-could-it-be-the-unproven-path.html
The Unproven Path
I have some ironclad rules for starting a technology venture. I broke
a bunch of them when I started my latest technology venture.

Gracias nuevamente...

Como se enseña ingeniería de Sw en el MIT. Mmmm... Interesante...

"This is a report on what we've learned during the first four semesters of teaching a new subject at MIT: Software Engineering of Innovative Internet Applications. We present new ideas in teaching computer science students to build the kinds of applications demanded by society. We discuss methods for involving alumni as teaching assistants and coaches. We argue for the method of helping students achieve fluency by assigning five complete applications for construction in a semester rather than the traditional single problem in a software engineering semester".

Teaching Software Engineering - MIT

Habrá que echarle un vistazo... ¿Comments?

Libro recomendado para casos de uso...

El viejo me recomendó este libro para quienes estén interesados en escribir casos de uso...

Writing Effective Use Cases
Alistair Cockburn
Humans and Technology

Link

Lo padre del formato que propone Alistar son los tipos de casos de uso:
1) A bussiness use case
2) A use case recommended
3) A fully dressed use case

Además cada caso de uso puede estar a diferentes niveles, un nivel estratégico (nubesita), un nivel usuario (usuario con computadora) o a más detalle (representado por un rastrillo para hierba)....

RECURSOS DE UML

Lo que me encontré en TEMOA (Open Educational Resources). 

1. Automating Component Based Testing from UML Models. Primero se debe de modelar la solución en UML, después software de manera automática genera scripts de prueba para los componentes. La herramienta se llama EJBTest y puede verificar funcionalidad de un sistema así como la Base de Datos originada. Link: http://dspace.mit.edu/bitstream/handle/1721.1/16741/46316154.pdf?sequence=1

2. StarUML es una herramienta desarrollada en Delphi por un grupo de estudiantes koreanos que permite diseñar practicamente todos los tipos de diagramas UML. A favor: Maneja la metodología de UML, traduce los diagramas a EJB,directamente.  Componentes con uno de sus plug-ins. Además cuenta con OCL para la clase. Link: http://staruml.sourceforge.net/en/

3. Tutorial de UML. The Unified Modeling Language (UML) has quickly become the de-facto standard for building Object-Oriented software. This tutorial provides a technical overview of the 13 UML diagrams supported by Enterprise Architect. UML 2 semantics are explained in detail in the new UML 2.0 tutorial. Link: http://www.sparxsystems.com/uml-tutorial.html

De la experiencia de los alumnos: 

3. BOUML tiene un benchmarking de varias herramientas para hacer diagramas UML, entre ellas StarUML. A favor: se ve que BOUML es muy eficiente respecto a las demás herramientas. En contra: su página no parece tener un buen diseño y ser usable, por lo que desconfiería un poco. Link: http://bouml.free.fr/benchmark.html

En resumen, estas son recomendaciones de herramientas gratuitas y tutoriales de UML. Ambas les pueden servir...

Los 10 pecados de la estimación...

El Viejo me paso dos presentaciones relacionadas a la clase de hoy de estimación. Que por cierto fue un buen ejercicio. Me quedo con las recomendaciones de Kemerer:
1) Recolecta datos, hazlos accesibles para la estimación.
2) Desarrolla tu modelo de costeo y calíbrarlo.
3) Evalúa nuevas tecnologías
4) Entrega a tus estimadores y apoyalos.
5) Construye código reutilizable.
6) La medición mejora la productividad, la calidad y la confiabilidad de software.

Los 10 pecados mortales de la estimación...
http://www.galorath.com/wp/10-deadly-sins-of-software-estimation.php

Y también la presentación de los 10 potenciales + los 10 pecados mortales...

10 Deadly Sins of Software Estimation

¿¿Que opinan?? Como me dijo un alumno de la Maestría. Soy un pecador en esto del software...