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
 

Enumera tu ABC: Aprende administración de proyectos ágiles

Por Mary Ann Crow [ Acerca de la autora]

La mayoría de los proyectos se manejan actualmente utilizando una metodología de proceso tipo cascada, la cual es lógica y está ordenada por un conjunto de pasos con roles establecidos y responsabilidades para que el equipo de proyecto pueda generar resultados que se reflejen en la calidad de los proyectos entregados a tiempo y en presupuesto. Pero de acuerdo con el Desarrollo Ágil e Iterativo, el uso de la metodología de cascada se ha convertido en poco atractiva desde que:

  1. Los usuarios no siempre están seguros de lo que ellos quieren, y una vez que ven el trabajo, ellos van a solicitar cambios
  2. Los suficientes detalles de trabajo generalmente llevan a la necesidad de un sofisticado sistema integrado de la administración del cambio antes de que el nuevo detalle de trabajo pueda avanzar
  3. Hay un gran impacto de riesgos en este método ya que el trabajo se retrasa dentro del ciclo del proyecto lo que a menudo puede conducir a sobrepasar los costos y el tiempo

Otros de los factores que también son importantes para la administración de proyectos a pesar de la metodología de procesos que pueden llevar al proyecto al fracaso, son:

  1. Grandes proyectos (por ejemplo más de 10 millones de dólares y un equipo de más de 100 personas) no tienen mejor oportunidad para lograr el éxito que un proyecto de menor tamaño (por ejemplo menos de un millón de dólares y menos de 20 individuos en el equipo del proyecto)
  2. El cambio de los requerimientos abarca alrededor del 25% del tiempo
  3. Más del 50% de las solicitudes no son usadas

La administración de proyectos de forma ágil es una de varios esquemas iterativos y adaptivos de proyectos, enfoques diseñados para entregar el máximo valor de negocios a los clientes dentro de los límites de las restricciones de tiempo y costo. En cada iteración, el alcance es ajustado en función de los requerimientos de valor de negocio del dueño del producto.

Dentro de la enseñanza tradicional del PMBOK® la relación de la triple restricción del alcance, tiempo y costo está conectada por liberaciones basadas en la función. Cuando una variable de las restricciones cambia, las otras dos también deben ser revisadas determinando su impacto en el acuerdo de liberación de las entregables prometidos. Pero con el método ágil, la triple restricción es al revés ya que el ámbito de aplicación (un conjunto de características) se acuerda firmemente, antes de que comience el trabajo, por un presupuesto preestablecido (costo) y el calendario (tiempo). Si lo acordado se expande en un conjunto de características, entonces los costos y el tiempo harán lo propio. Este método reduce el riesgo y mejora de forma predecible. Cuando otra variable se introduce, generar una modificación en los costos y el tiempo, ampliando así los factores de cambio dentr del proyecto.

Esto significa que las fechas de entrega pueden ser recortadas al igual que la reducción de costos para la optimización del valor del proyecto: entregar el valor más alto incrementa la funcionalidad, primeramente. Además de, dejar de entregar incrementos cuando el valor de la oportunidad en menor que el costo y dejar de entregar incrementos cuando el valor de la oportunidad es mayor que el valor marginal del siguiente incremento.

El pensamiento ágil fue inspirado por W. Edwards Deming quien debe de sonar familiar si se conoce de la técnica de desarrollo del PMBOK® de los ciclos Planear-Hacer-Revisar-Actuar (PDCA, por sus siglas en inglés). Agile, fue primeramente estructurado en 1986 por las compañías Fuji y Honda de Japón cuando sus altos directivos decidieron construir productos de manera diferente con el fin de:

  • Utilizar pequeños equipos multi-funcionales (personas y su rango interacciones sobre los procesos y herramientas)
  • Utilizar pequeñas (generalmente 30 días) restricciones del tiempo máximo para trabajar todos los desarrollo (trabajar rangos de software sobre una completa y rápida documentación fuera de fecha)
  • Utilizar una mejor filosofía de dirección que cambia a lo largo del camino (La colaboración de los clientes en la negociación del contrato)

Metodología Scrum

Así que, ¿qué es Scrum?. Proviene de un término utilizado en el rugby donde una “scrum” una táctica con ese nombre es usada para reiniciar el juego después que un evento generó su paralización. Cada equipo oponente se forma en un muro humano de tres jugadores de profundidad, empujando el uno contra el otro para patear el balón fuera de su lado. En este contexto, cobra mayor valor el trabajo en equipo y de fortaleza. Si hacemos la analogía con el desarrollo de software, Scrum está basada en múltiples equipos pequeños trabajando de una forma intensa e interdependiente para entregar un software. El flujo de procesos de Scrum está estructurado en ciclos de trabajo llamados “Sprints” y generalmente duran de dos a cuatro semanas. Al inicio de cada Sprint, los equipos seleccionan las características de una cartera de productos priorizados con la intención de desarrollar el primero y más importante (de acuerdo a su valor para el negocio). Un equipo de Scrum pleno tiene más o menos siete miembros, incluyendo al dueño del producto, el ScrumMaster y al equipo de desarrollo.

Si eres un project manager tradicional, ¿dónde colocas tu función en el flujo de procesos de Scrum?. Esto te asigna en el papel de ScrumMaster pero hay algunas diferencias claves en las responsabilidades de un jefe de proyectos tradicional. La responsabilidad del ScrumMaster es en gran parte indirecta, ya que facilita la probabilidad del éxito ayudando al dueño del producto a seleccionar los requerimientos más valiosos que ayuden al equipo a convertir esos requisitos en una funcionalidad valiosa para el producto.

El ScrumMaster es el responsable de enseñar el proceso de Scrum a todos los involucrados al proyecto y debe asegurar que cada uno siga las prácticas y las reglas del Scrum. El equipo de desarrollo central de Scrum es un grupo enfocado al flujo de procesos y sabe lo que se necesita hacer, y no se les dice lo que está hecho por una planificación extensiva y los requerimientos del alcance dentro de una metodología de cascada. El equipo es autogestionado, auto organizado y transversal, también es responsable de determinar cómo convertir los requerimientos en un incremento de funcionalidad con el Sprint. El ScrumMaster es un papel clave para facilitar las reuniones de planificación Scrum, las reuniones diarias de Scrum, Sprint y la reunión de revisión.

Curso SCRUM


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

Temas relacionados:
Curso de Scrum: Administración ágil de proyectos
Certificación PMP® en Administración de Proyectos
Curso breve intensivo de certificación en administración de proyectos para principiantes (CAPM®)

+



Roberto Romero dijo el 11 Enero de 2011:
Aunque pareciera que la metodología está más orientada al desarrollo de software, debo también decir que la aplicación del mismo en el desarrollo de un software puede implicar la no culminación y entrega en los tiempos establecidos, por lo que en el desarrollo de software es mejor implementar la entrega por versiones, ya que cuando un componente se ha desarrollado con ciertas características y especificaciones, la modificación de éste implica la revisión y ejecución nuevamente de la pruebas unitarias y de certificación de todos aquellos otros componentes que lo incluyen, lo cual representa un gran riesgo en el software, al cliente y al proveedor del servicio, y lo que se llega a modificar es el presupuesto del proyecto pero no el tiempo de entrega, lo que implica incorporar más actividades dentro de una unidad de tiempo, que en cierta forma ya está ajustada, aunque se prevenga una holgura.

Juan Sabas dijo el 07 Enero de 2011:
Hola Ruben participe en una conferencia del PMI Mexico el año pasado y si efectivamente ellos comentaron que la metodologia agil de Scrum es para software porque un proyecto por ejemplo de producir un puente requiere de un cuidado muy preciso a los que de repente no le entraría aplicar agilidad.

Editor dijo el 05 Enero de 2011:
Estimados lectores de LiderDeProyecto.com

Sus comentarios fueron recibidos y en consecuencia se procedió a realizar la revisión del artículo, por lo que los errores en la claridad del mismo ya fueron corregidos.

A todos a quienes les hayamos podido causar molestias les pedimos nuestras y a su vez les damos nuestras más profundas palabras de agradecimiento por interesarse en los contenidos de LiderDeProyecto.com, pues ustedes son nuestro mayor estímulo para continuar mejorando. Así que muchas gracias por estar al pendiente de cada detalle en lo que a LiderDeProyecto.com respecta, porque de esta manera continuaremos difundiendo contenido de mejor calidad.

Saludos

Guillermo dijo el 05 Enero de 2011:
Concuerdo con Rubén, esta metodología es más orientada al desarrollo de sistemas, ya que busca principalmente bajar la alta incertidumbre existente en ese tipo de proyectos (con etapas cortas, bien definidas y luego volver a realizar análisis de los objetivos o requerimientos del proyecto). No me queda claro la aplicación en otras áreas, donde el producto a conseguir sea más claro, como por ejemplo la construcción de un edificio.

jaime echeverri dijo el 04 Enero de 2011:
"Pero otra variable clave es también introducirla expande acordado conjunto de características, el coste y el tiempo se ampliará, que es la calidad de la funcionalidad"

En general, el articulo no es claro.

Ruben Davila dijo el 04 Enero de 2011:
Pareciera que esta metodología es mas orientada a desarrollo de sistemas que a proyectos de ingeniería y construcción. Es poco clara su aplicación en esto ultimo.
Creo que el manejo de los "change orders" se complicaría aun más de lo que regularmente es; sobre todo con el cliente.

Luz dijo el 04 Enero de 2011:
Esta frase:

"Pero otra variable clave es también introducirla expande acordado conjunto de características, el coste y el tiempo se ampliará, que es la calidad de la funcionalidad"

no es clara.



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.