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
 

Prácticas ágiles vs. Métodos ágiles


Por Nader K. Rad [acerca del autor]



Usted puede beneficiarse del uso de las prácticas ágiles, tanto en ambientes predictivos y ágiles, pero eso no necesariamente lo hará ágil. Es necesario utilizar métodos ágiles/Frameworks para ese propósito.

Esto es importante, porque algunas empresas creen equivocadamente que el uso de prácticas ágiles es suficiente.

Prácticas Ágiles vs. Métodos y Frameworks

¿Qué es una Práctica Agile?

Los siguientes son ejemplos de prácticas ágiles:

La propiedad colectiva del código
Programación a la par
Juntas stand-up diarias
Radiadores de Información
Refactorización continua
La auto-organización

¿Por qué se les llama prácticas "Agile"? Es solo porque son más comunes en entornos ágiles, y mayormente, inventadas o promovidas por profesionales en Agile. Sin embargo, la mayoría de ellas han estado en uso por mucho tiempo, de una forma u otra.

Puede ser que algunas personas no se sientan cómodas al referirse a algunas de ellas como "prácticas", ya que tienen otras cosas en mente. No hay una definición clara sobre las prácticas, que yo sepa.

¿Qué es un método Agile/Framework?

Por ejemplo:

Scrum
Método de Desarrollo Kanban
Atern
ADD

Esas son las herramientas que necesita para convertirse en Agile.

¿Por qué el uso de las prácticas por sí solas no me hacen Agile?

Utilizar las prácticas pueden beneficiarlo en cualquier entorno, siempre y cuando no haya conflictos entre ellos y el resto del sistema. Por ejemplo, la auto-organización podría no ser aplicable en todos los ambientes, mientras que los radiadores de información son simples, y siempre es posible utilizarlos.

Usted puede estar utilizando un sistema de cascada, junto con emisores de información y standups diarios para mejorar las comunicaciones. Eso está bien; eso es bueno; pero eso no convierte su sistema de Cascada en Agile.

¿Qué cosas extra proporciona un Método/Framework?

Un Método/Framework no es un conjunto de prácticas. De hecho, muchos de ellos no insisten mucho en las prácticas, y es cuestión de usted agregar las adecuadas.

Así que, ¿qué ofrece un Método/Framework que no podamos obtener con sólo un conjunto de prácticas?

Es muy sencillo: Un Ciclo de Vida de desarrollo.

El Ciclo de Vida le indica los pasos a seguir. Para ser prácticos, los roles y responsabilidades son requeridos, así como algunos productos de gestión (artefactos).

¿Por qué es importante?

Si nunca se ha tenido un sistema adecuado (por ejemplo, la cascada), y trata de convertirse en Agile simplemente mediante la incorporación de algunas prácticas ágiles, el resultado sería simplemente un sistema caótico que puede o no funcionar.

¡Pero la gente lo está haciendo y tienen éxito!

Las posibilidades de éxito son mucho más bajas cuando no se está utilizando un Método/Framework, y depende solo de la incorporación de algunas prácticas. Esto no significa que definitivamente vaya a fallar; después de todo, muchos proyectos no han sido manejados de manera sistemática, y algunos de ellos han logrado tener éxito, debido a que tuvieron un equipo fuera de lo común, buen ambiente, y suerte.

Además de eso, tenga cuidado con juzgar los sistemas de los demás; usted ve las prácticas cuando mira a los demás, pero es más difícil visualizar el framework que forma su desarrollo. Usted puede dejar de ver que parte es esencial, y creer que todo lo que están haciendo es seguir algunas prácticas.

¿Estás diciendo que no debemos usar prácticas ágiles?

Es una muy buena idea utilizarlas, siempre y cuando se asegure de que no están en conflicto con algo más en el proyecto. Mi punto es que usted debe saber qué esperar de ellas: ya que no van a crear un sistema completo para usted.

Son útiles, pero no lo suficiente.

 




Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
¿Qué estructura organizacional se recomienda para proyectos?


+





Cómo estimar correctamente un proyecto y llevarlo a cabo en tiempo y forma (Nahun Enrique Montoya-Iribe)
+
.
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.