contacto@liderdeproyecto.com
Teléfono en Ciudad de México:
+52 (55) 2652 4590
Aviso de privacidad
Conoce a los colaboradores de LiderDeProyecto.com. Tú puedes ser uno de ellos.
 |
| Entrevista a Capers Jones: “El control de la calidad es la clave del éxito en los proyectos de software” Por Luis Ernesto Matos
En un encuentro exclusivo para LiderDeProyecto.com, el reconocido gurú del software, Capers Jones, platica acerca de su trayectoria en la administración de proyectos de software y su actual etapa como conferencista destacado en temas de software. A través de sus más de 35 años de trayectoria como experto en la administración de proyectos de software, Jones se ha ganado un lugar en la historia, sobre todo porque toda su experiencia ha sido plasmada en una infinidad de publicaciones y aplicaciones dentro del mundo del Software Project Management. ¿Cómo fueron sus inicios en Administración de Proyectos de Software? Primeramente fui promovido como administrador de proyectos en IBM a comienzos de la década de los 70s. Aquí tuve la oportunidad de diseñar la primera herramienta de estimación de costos de software automatizada en 1973, la cual estimó el software del sistema escrito en Asembly o PLS. En 1979, aproximadamente 40 de nosotros fuimos colocados desde IBM a ITT para iniciar un gran laboratorio de investigación de ingeniería de software en Stratford, CT, EE.UU., bajo la tutela de Jim Frame, quien fue el primer vicepresidente de programación de ITT. Trabajábamos aproximadamente 150 personas en el laboratorio de ITT. Allí fui designado como Subdirector de Medidas y administré un programa de medición global para ITT Corporation. Después que ITT vendió su negocio de telecomunicaciones a Alcatel en 1982, todos los laboratorios de ITT en los Estados Unidos fueron cerrados. En 1983 fundé Software Productivity Research (SPR), la cual estuvo ubicada en Cambridge, MA, EE.UU., por varios años, pero fue reubicada a Burlington, MA cuando nos expandimos. En 1998 SPR fue vendida a Artemis Management Systems y tenía alrededor de 35 empleados en el momento de la transacción. Esta empresa se encarga de construir herramientas de estimación de costos de software comerciales y además posee un ala consultora que recopila datos de referencia de unos cientos de empresas y miles de proyectos. Tras cinco años, los empleados de SPR compraron de regreso la compañía a Artemis. Actualmente he estado retirado de SPR pero estoy muy contento al ver que todavía continúan creciendo y que recientemente abrieron un centro de desarrollo en Beijing, China. En IBM diseñé la primera herramienta de estimación de costos de software automatizada en 1973. Éste estimó el software del sistema escrito en Asembly o PLS. Pero ITT fue un conglomerado que poseyó más de 200 compañías diferentes y utilizó más de 50 lenguajes de programación. En ITT diseñé varias herramientas de estimación que soportaron software de sistemas, sistemas embebidos, aplicaciones IT y software de defensa. ¿En cuántos proyectos de software ha participado? He administrado o tomado parte directa en aproximadamente 25 proyectos durante toda mi trayectoria, pero he recopilado datos de miles de proyectos. Me retiré del trabajo de tiempo completo en el 2000, no obstante, desde entonces continúo escribiendo libros, doy discursos y consultoría a un número determinado de clientes. ¿Cuál ha sido su mayor aprendizaje en administración de proyectos de software? Diseñar y construir herramientas de estimación de calidad y de costos de software han sido las principales actividades de mi carrera desde los 70s. Incluyendo software de estimación propietarios diseñados y construidos en IBM e ITT, una herramienta diseñada conforme a contrato para AT&T, asi como herramientas de estimación comerciales de SPR (SPQR/20TM, CHECKPOINT™ y KnowledgePlan®). También he diseñado y trabajado en 10 diferentes herramientas de estimación y costos de software. En este 2009, estoy trabajando en un nuevo tipo de herramienta de administración del riesgo. La primera lección importante que aprendí allá en 1973 fue que las “líneas de código” no son una buena opción para realizar estimaciones. Hay dos razones por las que digo esto: La primera es que hay más de 700 lenguajes de programación de varios niveles. La segunda razón es que la programación por sí misma es menos del 30% del total del costo del software. Las métricas de puntos de función son mejores para los requerimientos de estimación, diseño, documentación, administración de proyectos y otros trabajos de no codificación. La segunda cosa que aprendí es que las dos actividades más caras en el desarrollo de software son: 1) encontrar y reparar defectos; 2) escribir documentos como requerimientos y especificaciones. Es por esto que la calidad y los papeles de trabajo tienen que ser considerados cuidadosamente para que todas las estimaciones globales sean exactas. La tercera cosa que aprendí es que los requerimientos cambian en un rango del 2% aproximadamente por calendario mes, así que las herramientas de estimación necesitan manejar el crecimiento y cambio de los requerimientos para transmitir exactitud. ¿Cuál ha sido el proyecto más ambicioso de su carrera? Yo considero que los proyectos más ambiciosos en mi carrera fueron las herramientas de estimación de software CHECKPOINT™ y KnowledgePlan®. Éstas iban más allá de la estimación de niveles de fase e intentaban estimar cada actividad y entregable asociado con grandes proyectos de software. Por ejemplo, ambos instrumentos podían dimensionar y estimar más de 50 clases de documentación, más de 20 tipos de pruebas y actividades de remoción de defectos y soporte de estimaciones para las aplicaciones que usaban hasta 15 lenguajes de programación diferentes al mismo tiempo. El reto fue construir herramientas que podían estimar sistemas muy grandes y complejos con exactitud, pero también que fuesen fáciles de utilizar. ¿Cuál es el logro más importante en su carrera? Hay tantos fracasos en el software que es agradable ser parte de las aplicaciones que terminan a tiempo y con un trabajo bien hecho cuando es entregado y recibido por el cliente. Por ejemplo Watts Humphrey Team Software Process (TSP) es ampliamente utilizado en México y frecuentemente conduce a resultados muy exitosos. ¿Cuáles han sido sus contribuciones a la Administración de Proyectos de Software? Probablemente mi aporte principal ha sido coleccionar datos que proporcionan los proyectos de software con excelente control de calidad que tienen calendarios cortos, bajos costos y clientes felices. Alcanzar una buena calidad requiere tanto de excelencia en la prevención de defectos como también un espectro lleno de remoción de defectos, inspecciones, análisis estadísticos y las pruebas que son todas necesarias. Las pruebas solas no son adecuadas. ¿De acuerdo a su experiencia, cuáles son las causas por las que la mayoría de los proyectos fallan? Yo he trabajado como un testigo experto en 15 juicios, también tengo mucha información detallada sobre por qué fallan los proyectos de software. Las cuatro razones principales por la que fracasan los proyectos son: 1) Estimaciones tempranas son inexactas y rechazadas por los clientes; 2) El control de calidad no es muy bueno; 3) El control de cambio no es muy bueno; 4) El rastreo del progreso es sumamente malo. ¿Considera que los mismos problemas que generan fracasos están mejorando o empeorando? Hasta la recesión del 2008, los proyectos que usaron Agile, TSP, RUP o habían encabezado el nivel 3 en CMM fueron hechos bastante bien. Ahora que la recesión es mundial y el crecimiento desacelerado, habrá tantos fracasos de negocios y despidos que el futuro ya no es previsible. Lo que me preocupa es que las empresas y los proyectos intentarán y escatimarán en el control de calidad, y naturalmente esta acción incrementará la probabilidad de fracasos. ¿Cómo espera ser recordado en el mundo de la Administración de Proyectos de Software? No sé si lleguen a recordarme. Algunos de mis libros como Medición de Software Aplicado y Estimación de Costos de Software han sido revisados en varias ediciones durante los últimos 10 años más o menos. Tal vez se continúen utilizando y por eso seré recordado. Sabemos que actualmente se dedica a impartir tópicos relacionados con la Administración de Software, ¿qué tipo de temas trata en sus conferencias? Tengo un total de aproximadamente 17 discursos sobre asuntos de software. Los temas que trabajo con mayor frecuencia son: 1) Último modelo de calidad de software; 2) Último modelo de medición de software; 3) Último modelo de estimación de software; 4) Mejores practicas en software; 5) Mantenimiento, Mejoramiento y Renovación de Software. Actualmente me encuentro preparando otros nuevos temas para incluirlos en este 2009, los cuales son: 1) Seguridad de Software; 2) Métodos de aprendizaje y educación de software; 3) Reutilización de software. La seguridad se hace muy importante a medida en que la recesión se hace más profunda. Los ingenieros de software también necesitan mejores métodos de aprendizaje que libros ordinarios. Algunos nuevos métodos basados en avatares y ambientes interactivos probablemente se están haciendo muy importantes. La reutilización de software tiene la S del potencial económico, pero la reutilización en gran escala como SOA tiene que ser mucho mejor que el promedio para tener una calidad verdaderamente efectiva. Desde el 2006 he comenzado a hacer seminarios Web así como discursos regulares. Muchos de estos son a través del Instituto de Productividad y Métricas de Tecnologías de Información (ITMPI, por sus siglas en inglés). En el 2008 hablé en el Simposio Japonés sobre Evaluación de Software (JaSST), en el Congreso de Calidad Mundial y también en la Conferencia Internacional de Usuarios de Puntos de Función. ¿Cuál es su consejo para los administradores de proyectos de software que nos leen? La recomendación principal es que el control de la calidad es la clave para el éxito en el software. Los proyectos que son exitosos en el control de calidad a través de inspecciones, análisis estadísticos y evaluación, repercutirán inevitablemente en el triunfo de los clientes. Asimismo, garantizarán proyectos. La mayoría de los proyectos que fracasan, lo hacen durante la evaluación, debido al exceso de defectos. Es muy interesante que México, India, Japón y otros países hayan hecho de la calidad del software temas nacionales. China también es otro ejemplo importante e interesante en la calidad del software.
Temas relacionados: |
