Comparación de TenStep con el Método Ágil de Desarrollo de Sistemas
Copyright© 2007-2011 TenStep Latinoamérica S.A. de C.V. Todos los derechos reservados
En años recientes, diversas ideas han sido publicadas en cuanto a formas de hacer el proceso de desarrollo de software más simple, fácil de implementar y con mejor respuesta a las necesidades de los clientes. Dos ejemplos de ello son Extrema e Scrum y Crystal. 17 personas que estaban a la vanguardia de este pensamiento se reunieron en Utah en febrero 11, 12 y 13 de 2001 para encontrar ideas comunes alrededor del desarrollo de software. El resultado fue un manifiesto para establecer un conjunto de principios de desarrollo y filosofías que se mencionan más adelante.
Mientras que la mayoría de la filosofía está relacionada con el proceso real de desarrollo de software, algunos puntos tocan la Dirección de Proyectos. En general, el Proceso TenStep complementa este proceso de desarrollo muy bien en la mayoría de las áreas. En otras áreas, hay una divergencia de opinión. Se puede leer el Manifiesto Ágil[1] a continuación, así como los comentarios del autor en cuanto a cómo se relaciona con el Proceso TenStep.
| El manifiesto para el método Ágil de Desarrollo de Sistemas
17 anarquistras acuerdan: Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valer: |
Proceso de Dirección de Proyectos TenStep |
| Individuos e interacciones sobre los procesos y herramientas.
Software funcionando sobre documentación extensa. Colaboración del cliente sobre la negociación contractual. Respondiendo al cambio sobre el seguimiento del plan. |
La experiencia del autor es que múltiples proyectos en ejecución dentro de una organización tienen muchas más posibilidades de éxito con un conjunto consistemte, flexible y escalable de procesos. Si estos procesos procesos se han usado con éxito en el pasado, hay una mayor probabilidad de que los de otra organización sean exitosos también. |
| Esto es, mientras apreciamos los elementos de la columna derecha, valoramos más los elementos de la izquierda. Seguimos los siguientes principios: | |
| Nuestra prioridad más alta es la satisfacción del cliente a través de la entrega anticipada y continua de software valioso. | La filosofía Ágil promueve el desarrollo iterativo, con la recopilación anticipada de requerimientos seguida por el trabajo en la codificación, seguida por más requerimientos y más código. Esto está bien, pero el desarrollo iterativo no es el mejor enfoque para todos los proyectos de software. Sin embargo, en donde pueda implementarse, debe intentarse. |
| Bienvenidos los requerimientos de cambio, aun tarde en el proceso de desarrollo. Los procesos Ágil toleran el cambio en aras de la ventaja competitiva del cliente. | Bajo el desarrollo iterativo, los requerimientos no necesitan ser “congelados” en etapas tempranas. Sin embargo, aun con el desarrollo iterativo tradicional, en algún punto, los requerimientos necesitan ser congelados en aras de poder entregar algo. En ese punto, el proceso de gestión de cambios de alcance entra en vigor.
En el desarrollo Ágil, los requerimientos pueden cambiar en cualquier punto. La idea es que el cliente puede continuar haciendo cambios en tanto que estén priorizados en la iteración apropiada. Por ejemplo, si el cliente solicitó tres reportes y después desea uno más, el cuarto reporte puede ser agregado a la lista de requerimientos sin problema. En algún punto, el cliente va a necesitar priorizar este nuevo reporte y cuando lo haga dicho reporte se escribirá. Si el presupuesto del cliente está abiertamente concluido, entonces no habrá un proceso formal de cambio de alcance. Se entregará lo que desee y priorice. Si el cliente tiene un presupuesto fijo, priorizar un cambio para completarlo va a significar en esencia que alguna otra pieza de trabajo no va a ser concluida. En este escenario, el cliente está haciendo cumplir la gestión del cambio de alcance al asegurarse que solo los cambios que tienen la más alta prioridad son priorizados mientras que otros no lo son.
El enfoque TenStep señala que cuando los cambios de negocio suceden, el equipo de proyecto debe estar preparando para responder. Sin embargo, los cambios a los requerimientos tienen consecuencias en términos de presupuesto y fechas de entrega y estos deben ser aprobados por el patrocinador. Si el equipo de proyecto hace esto, están practicando la gestión de cambios de alcance. |
| La entrega de software funcional frecuentemente, de un par de semanas a un par de meses, con preferencia a escalas de tiempo más cortas | El Proceso TenStep recomienda que proyectos largos sean divididos en una serie de proyectos menores, cada uno de ellos puede ser entregado más rápido y de manera repetitiva. No todos los proyectos tienen esta flexibilidad, pero la preferencia es hacia proyectos menores siempre que sea posible.
Los procesos Ágil pueden tomar el corto ciclo de entrega a un extremo. Algunos proyectos de programación extrema entregan en periodos realmente cortos, aun cada semana. Aunque esto pueda ser duro de gestionar, no hay nada inherentemente equivocado con esto. |
| La gente de negocio y los desarrolladores trabajan juntos diariamente a lo largo del proyecto. | Este es el mejor enfoque para mantenerse en contacto con las necesidades del cliente. |
| Construir proyectos alrededor de individuos motivados. Se les propicia el ambiente y soporte que necesitan, y se confía en que ellos harán de trabajo. | Algunas veces, gente muy motivada tiene problemas para entregar proyectos a tiempo. (lo que fue reconocido hace medio siglo). Pueden enfocarse mucho en detalles del desarrollo y no mucho en la gestión del presupuesto y el calendario. Si la gente motivada siempre entregara sus proyectos a tiempo, habría un porcentaje mayor de proyectos exitosos. Algunas veces es necesario colocar al personal motivado en ambientes más estructurados en donde puedan ser más exitosos. El autor considera que el mejor enfoque es integrar proyectos alrededor de gente motivada y después asegurar que cuenten con las herramientas, los procesos y habilidades apropiados para llevar a cabo el trabajo. |
| El método más efectivo y eficiente para transmitir información hacia y entre el equipo de desarrollo, es la conversación cara a cara. | No hay duda de que la comunicación personal es mejor en cualquier circunstancia. Sin embargo, hay ocasiones en que otros medios de comunicación son efectivos, enviar correos electrónicos puede estar bien por ejemplo, cuando se envía un informe de estado del proyecto a 20 individuos. Alguna información relevante también tiene que ser escrita, si la información se necesita cuando todos los desarrolladores originales se hayan ido. Esta documentación debe ser sólo para información importante. La documentación rara vez es actualizada por el equipo de soporte, por lo que puede volverse menos valiosa con el tiempo. |
| El que el software esté funcionando es la medida primaria del progreso | En el proceso de desarrollo iterativo, el contar con software funcionando al final de cada iteración es una buena medida del progreso. Sin embargo, no todos los proyectos pueden ser realizados a través del desarrollo iterativo; por ejemplo, la implantación de paquetes. Así que en la mayoría de los proyectos, es necesario continuar monitoreando los hitos mayores del plan, para asegurar que el cronograma se cumpla. |
| Los procesos Ágil promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante indefinidamente. | El método de desarrollo Ágil enfatiza una semana de 40 horas y un ritmo de trabajo que puede ser sostenido indefinidamente. Por supuesto, con la planificación y gestión adecuadas, éste es el mejor enfoque. |
| La atención continua a la excelencia técnica y el buen diseño, mejora la agilidad. | La excelencia técnica y el buen diseño son decisiones esenciales para hacer que los procesos Ágil funcionen. |
| Simplicidad – el arte de maximizar la cantidad de trabajo no realizado – es esencial. | De acuerdo. Los desarrolladores de software y clientes deben enfocarse en cumplir con los requerimientos principales en primer término. Esto “maximiza el trabajo no realizado”. También permite que el software sea entregado más rápidamente. |
| Las mejores arquitecturas, requerimientos y diseños emergen de los equipos auto-organizados. | Si cada equipo fuera de alto desempeño y técnicamente superior, sería más fácil estar de acuerdo con este punto. Sin embargo, la mayoría de los equipos de proyecto no son lo suficientemente maduros ni poseen las habilidades adecuadas para desarrollar los mejores diseños y arquitecturas. Particularmente, las arquitecturas deben ser diseñadas a nivel organizacional. Si ese trabajo se dejara a equipos individuales, el resultado sería tecnología duplicadas y caos. |
| A intervalos regulares, el equipo reflexiona acerca de cómo ser más efectivo, entonces realiza los ajustes y modifica su comportamiento en consecuencia. | De acuerdo. Los equipos constantemente deberían esforzarse por entender sus fortalezas y debilidades y la forma en que los procesos de Dirección de Proyectos pueden ser mejorados. El Proceso TenStep también cree que los cambios recomendados debiesen elevarse a nivel organización de modo que las ideas de mejora puedan apalancarse por todo el personal. |
Reproducido y adaptado con autorización del autor.
TenStep Project Management Process
Copyright © 2000 – 2012 by Tom Mochal, TenStep, Inc.
Mochal, Tom, 1957–
TenStep Project Management Process / Tom Mochal.
ISBN 0-9763147-0-3
Proceso de Dirección de Proyectos TenStep v9.0
Derechos reservados © 2006–2011 por Jorge Valdés Garciatorres, para la edición en Español
Valdés Jorge, 1965 –
Proceso de Dirección de Proyectos TenStep / Tom Mochal
Traducido y adaptado por Jorge Valdés Garciatorres, BA, PMP, ITIL, CC
Traducción y Adaptación para la v6.0 por David Suro, Traductor Profesional
Traducción y Adaptación para la v7.0 por José Luis Flores Pérez, BA, MOD
Traducción y Adaptación para la v8.0 por José Luis Flores Pérez, BA, MOD
Traducción y Adaptación para la v9.0 por José Luis Flores Pérez, BA, MOD
Esta Edición en Español, Diciembre de 2010
© Todos los derechos reservados, TenStep Latinoamérica S.A. de C.V.
[1] Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.AgilAlliance.org
