Metodologia
sejoan5 de Diciembre de 2011
10.257 Palabras (42 Páginas)562 Visitas
La Nueva Metodología
Martin Fowler
Chief Scientist, ThoughtWorks
Texto original: The New Methodology
Traducción: Alejandro Sierra, marzo/abril de 2003.
Ultima actualización significativa: Abril 2003.
Desde hace unos pocos años ha habido un interés creciente en las metodologías ágiles (léase "livianas"). Caracterizadas alternativamente como antídoto a la burocracia o licencia para hackear han suscitado interés en el panorama del software. En este ensayo exploro las razones de los métodos ágiles, enfatizando no tanto su peso sino su naturaleza adaptativa y su orientación a la gente. También doy un resumen y referencias a los procesos en esta escuela y considero los factores que deberían influir en su decisión de seguir o no por esta nueva ruta.
• De Nada a Monumental a Agil
• Predictivo contra Adaptable
o Separación de Diseño y Construcción
o La Impredecibilidad de los Requisitos
o ¿Es Imposible la Previsibilidad?
o Controlando un Proceso Imprevisible
o El Cliente Adaptable
• Poniendo a la Gente Primero
o Juntar Unidades de Programación Compatibles
o Los Programadores son Profesionales Responsables
o Manejando un Proceso Orientado a la Gente
o La Dificultad de Medir
o El Papel del Liderazgo de Negocio
• El Proceso Auto-Adaptable
Las Metodologías
o XP (la Programación Extrema)
o La Familia de Cristal de Cockburn
o Código Abierto
o El Desarrollo de Software Adaptable de Highsmith
o Scrum
o Desarrollo Manejado por Rasgos
o DSDM (Método de Desarrollo de Sistema Dinámico)
o Manifiesto para el Desarrollo de Software Ágil
o Comprobación Dirigida por el Contexto
o Es RUP un método ágil?
o Otras Fuentes
• ¿Debe usted irse a lo ágil?
La Nueva Metodología
Martin Fowler
Chief Scientist, ThoughtWorks
Texto original: The New Methodology
Traducción: Alejandro Sierra, marzo/abril de 2003.
Ultima actualización significativa: Abril 2003.
Desde hace unos pocos años ha habido un interés creciente en las metodologías ágiles (léase "livianas"). Caracterizadas alternativamente como antídoto a la burocracia o licencia para hackear han suscitado interés en el panorama del software. En este ensayo exploro las razones de los métodos ágiles, enfatizando no tanto su peso sino su naturaleza adaptativa y su orientación a la gente. También doy un resumen y referencias a los procesos en esta escuela y considero los factores que deberían influir en su decisión de seguir o no por esta nueva ruta.
• De Nada a Monumental a Agil
• Predictivo contra Adaptable
o Separación de Diseño y Construcción
o La Impredecibilidad de los Requisitos
o ¿Es Imposible la Previsibilidad?
o Controlando un Proceso Imprevisible
o El Cliente Adaptable
• Poniendo a la Gente Primero
o Juntar Unidades de Programación Compatibles
o Los Programadores son Profesionales Responsables
o Manejando un Proceso Orientado a la Gente
o La Dificultad de Medir
o El Papel del Liderazgo de Negocio
• El Proceso Auto-Adaptable
Las Metodologías
o XP (la Programación Extrema)
o La Familia de Cristal de Cockburn
o Código Abierto
o El Desarrollo de Software Adaptable de Highsmith
o Scrum
o Desarrollo Manejado por Rasgos
o DSDM (Método de Desarrollo de Sistema Dinámico)
o Manifiesto para el Desarrollo de Software Ágil
o Comprobación Dirigida por el Contexto
o Es RUP un método ágil?
o Otras Fuentes
• ¿Debe usted irse a lo ágil?
• Reconocimientos
De Nada a Monumental a Agil
Con mucho el desarrollo de software es una actividad caótica, frecuentemente caracterizada por la frase "codifica y corrige". El software se escribe con un mínimo un plan subyacente, y el diseño del sistema se adoquina con muchas decisiones a corto plazo. Esto realmente funciona muy bien si el sistema es pequeño, pero conforme el sistema crece llega a ser cada vez más difícil agregar nuevos aspectos al mismo. Además los bugs llegan a ser cada vez más frecuentes y más difíciles de corregir. La seña típica de tal sistema es una larga fase de pruebas después de que el sistema ha sido "completado". Tal fase larga de pruebas hace estragos con los planes de pruebas y depurado llegando a ser imposible de poner en el programa de trabajo.
Hemos vivido con este estilo de desarrollo por mucho tiempo, pero también hemos tenido una alternativa desde hace mucho: Metodología. Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.
Las metodologías ingenieriles han estado presentes durante mucho tiempo. No se han distinguido precisamente por ser muy exitosas. Aún menos por su popularidad. La crítica más frecuente a estas metodologías es que son burocráticas. Hay tanto que hacer para seguir la metodología que el ritmo entero del desarrollo se retarda.
Como una reacción a estas metodologías, un nuevo grupo de metodologías ha surgido en los últimos años. Durante algún tiempo se conocían como las metodologías ligeras, pero el término aceptado ahora es metodologías ágiles. Para mucha gente el encanto de estas metodologías ágiles es su reacción a la burocracia de las metodologías monumentales. Estos nuevos métodos buscan un justo medio entre ningún proceso y demasiado proceso, proporcionando simplemente suficiente proceso para que el esfuerzo valga la pena.
El resultado de todos esto es que los métodos ágiles cambian significativamente algunos de los énfasis de los métodos ingenieriles. La diferencia inmediata es que son menos orientados al documento, exigiendo una cantidad más pequeña de documentación para una tarea dada. En muchas maneras son más bien orientados al código: siguiendo un camino que dice que la parte importante de la documentación es el código fuente.
Sin embargo yo no creo que éste sea el punto importante sobre los métodos ágiles. La falta de documentación es un síntoma de diferencias mucho más profundas:
• Los métodos ágiles son adaptables en lugar de predictivos. Los métodos ingenieriles tienden a intentar planear una parte grande del proceso del software en gran detalle para un plazo grande de tiempo, esto funciona bien hasta que las cosas cambian. Así que su naturaleza es resistirse al cambio. Para los métodos ágiles, no obstante, el cambio es bienvenido. Intentan ser procesos que se adaptan y crecen en el cambio, incluso al punto de cambiarse ellos mismos.
• Los métodos ágiles son orientados a la gente y no orientados al proceso. La meta de los métodos ingenieriles es definir un proceso que funcionará bien con cualquiera que lo use. Los métodos ágiles afirman que ningún proceso podrá nunca maquillar las habilidades del equipo de desarrollo, de modo que el papel del proceso es apoyar al equipo de desarrollo en su trabajo. Explícitamente puntualizan el trabajar a favor de la naturaleza humana en lugar de en su contra y enfatizan que el desarrollo de software debe ser una actividad agradable.
En las secciones siguientes exploraré estas diferencias más a detalle, para que usted pueda entender lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y si es algo que debería usar: sea como desarrollador o como cliente de software.
Predictivo contra Adaptable
Separación de Diseño y Construcción
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que construir y como deben juntarse estas cosas. Muchas decisiones de diseño, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compañía diferente, para ser construidos. Se supone que el proceso de la construcción seguirá los dibujos. En la práctica los constructores se encuentran con algunos problemas, pero éstos son normalmente poco importantes.
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los fundamentos de un plan de construcción detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construcción razonablemente predecibles. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, qué es difícil de predecir y requiere personal caro y creativo, y la construcción que es más fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una manera más predecible. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación.
Así
...