Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Humor del Líder

Problemas de comunicación
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 

¿Cómo sabes que Agile es más rápido?


Nader K. Rad [ acerca del autor ]


Permítanme aclarar esto desde el principio: personalmente prefiero Agile a la Cascada. Sin embargo, lo que realmente amo es la justicia.

¿Son los proyectos Agile más rápidos?

Sentimos que los proyectos Agile son más rápidos; ¿Pero lo son?

La única manera de estar seguros de ello es llevar a cabo una investigación científica y tener una comparación estadística. Bien, nos enfrentamos a algunos problemas cuando queremos hacerlo.

Problema 1: ¿cuál debe ser considerado ágil?

En primer lugar, ¿cuándo vamos a llamar al entorno ágil? Cuando las personas involucradas en el proyecto lo dicen? Pero la mayoría de los llamados proyectos Agile no son técnicamente ágiles. Son proyectos predictivos o caóticos que utilizan la terminología ágil o dividen su producto en entregas más pequeñas que se producen en diferentes etapas que llaman iteraciones.

Entonces, ¿debemos investigar los proyectos y sólo incluir aquellos que son realmente Agile? Eso sería terriblemente duro, pero necesario.

Quizás podamos incluso mejorar esto incluyendo únicamente aquellos proyectos Agile reales que se realizan en un entorno que utiliza Agile durante al menos un año; Porque está claro cuando la gente empieza a usar un nuevo marco, no podemos esperar una alta productividad, incluso si están utilizando el marco correctamente.

Problema 2: ¿Comparar con qué?

Digamos que tenemos suficientes recursos para la investigación para determinar qué proyecto es realmente ágil. Ahora se supone que los comparamos con ... ¿a qué? ¿A todos los proyectos de TI? Eso no será justo, porque muchos proyectos no son ágiles, ni cascadas, son simplemente caóticos.

Por lo tanto, también puede ser necesario investigar el resto de los proyectos y ver cuáles son realmente cascada, antes de comparar la salida de los proyectos de Agile con ellos. Wow, esto sería difícil!

Problema 3: ¿cómo comparar?

Bien, ahora, ¿cómo vamos a comparar los dos conjuntos de información? Si comparamos las duraciones por ejemplo, podría no ser justo, porque si resulta ser la norma usar Agile para proyectos más pequeños y Waterfall para los más grandes, entonces, por supuesto, el resultado mostrará que los proyectos Agile son más rápidos. ¿Entonces, qué debemos hacer?

Si calculamos la relación entre la duración real y la duración prevista de cada proyecto y comparamos la producción media de los dos conjuntos, el resultado tampoco es fiable, porque tal vez las personas en los proyectos Agile sean más realistas en sus estimaciones iniciales (o viceversa) y por lo tanto , Su resultado es mejor. Por lo tanto, esta opción también está fuera.

Tal vez usted puede pensar en otra cosa, pero la única solución fiable que puedo pensar, es investigar la salida del proyecto y determinar su tamaño. Entonces podemos dividir este tamaño o volumen de trabajo a la cantidad de recursos dedicados al proyecto y obtener una "velocidad" o métrica de productividad. Y finalmente, podemos comparar la velocidad media de los proyectos Agile con los de los proyectos Waterfall.

Esta investigación puede necesitar un presupuesto enorme como los gobiernos establecidos para proyectos nacionales. Por cierto, si eres una autoridad gubernamental dispuesta a gastar ese dinero, estaría encantado de manejarlo; Estoy bien gastando dinero. Al menos, eso es lo que mi esposa cree.

Sin embargo, ¿es perfecto el resultado de una investigación tan complicada? Bueno, todavía no. Porque la velocidad calculada no es sólo debido a nuestro método de entrega (Agile vs. Waterfall); Es una combinación de eso con la productividad más amplia de la organización que realiza. Agile se utiliza normalmente en las organizaciones más jóvenes y Waterfall en los más antiguos. Tal vez las organizaciones más jóvenes son más rápidos por naturaleza (sus propietarios y ejecutivos son casi de la misma edad que los desarrolladores y se entienden más). O tal vez, las organizaciones más antiguas son más productivas debido a todos los activos del proceso organizacional y la experiencia que han reunido a través de los años. Así que digamos que nos hemos dado cuenta de que los proyectos Agile son 35% más rápidos que los proyectos de Cascada. Ahora una experiencia del pensamiento: qué si cambiamos todos los ambientes ágiles en cascada, y cascada en ágil, y déjelos dominar el proceso. Tal vez entonces, veríamos que Waterfall es 45% más rápido que Agile!

Conclusión

Mi punto es que:

1. Debemos tener mucho cuidado con la interpretación de las estadísticas.

2. Si realmente te gusta Agile, mantente crítico; No lo conviertas en una religión.


Temas relacionados:
Curso de Administración Ágil de proyectos con SCRUM

+





Alcanzando el éxito del proyecto con los requerimientos (Jorge Victoria)
+
.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. PMBOK, PMP, Project Management Professional, Project Management Professional (PMP), PgMP, Program Management Professional (PgMP), PMI-RMP, PMI Risk Management Professional (PMI-RMP), CAPM, Certified Associate in Project Management (CAPM), PMI-SP, PMI Scheduling Professional (PMI-SP), THE PMI TALENT TRIANGLE and the PMI REP Logo are registered marks of the Project Management Institute. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.