Metodologías de Desarrollo de Software Ágiles



Descargar 159.18 Kb.
Página1/3
Fecha de conversión14.02.2017
Tamaño159.18 Kb.
  1   2   3
Metodologías de Desarrollo de Software Ágiles

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 plan subyacente mínimo, 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 incluir 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 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 ante 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 todo 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. De 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, éste no es 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 largo 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 se verán estas diferencias más en detalle, para discernir lo que es un proceso adaptable y centrado en la gente, sus beneficios y desventajas, y qué se debería usar: sea como desarrollador o como cliente de software.

¿Qué es una Metodología Ágil?
Las Metodologías Ágiles o “ligeras” constituyen un nuevo enfoque en el desarrollo de software, mejor aceptado por los desarrolladores de e-projects que las metodologías convencionales (ISO-9000, CMM, etc) debido a la simplicidad de sus reglas y prácticas, su orientación a equipos de desarrollo de pequeño tamaño, su flexibilidad ante los cambios y su ideología de colaboración [1].
Predictivo versus 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í el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.

¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción.

Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la construcción suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?

Todos esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es conseguir un diseño UML en un estado que pueda entregarse a los programadores. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, son dóciles al análisis matemático. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Incluso los diseñadores experimentados, se sorprenden a menudo cuando convierten dichos diseños en software.

Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Steve McConnell [2] sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería.

Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado. De hecho cualquier cosa que pueda tratarse como construcción puede y debe automatizarse.

Estas ideas llevan a algunas conclusiones importantes:


  • En software la construcción es tan barata que es casi gratis.

  • En software todo el esfuerzo está en el diseño, de modo que requiere de personas creativas y talentosas.

  • Los procesos creativos no se planean fácilmente, de modo que la previsibilidad bien puede ser una meta imposible.

  • Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.


La Impredecibilidad de los Requisitos

Hay un dicho que se oye en cada proyecto problemático. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo sorprendente de esta situación es que sorprenda a cualquiera. En el negocio de construcción de software los cambios en los requisitos son la norma, la pregunta es qué hacemos al respecto.

Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingeniería de requisitos. La idea detrás de la ingeniería de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software, conseguir la firma del cliente sobre estos requisitos, y entonces preparar procedimientos que limiten los cambios de requisitos después de la firma.

Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun más duro porque la organización del desarrollo normalmente no proporciona la información del costo en los requisitos. El cliente termina solicitando algo que el vendedor no puede cotizar con exactitud. Sin una buena idea del costo, ¿cómo puede el cliente decidir si quiere pagar por ese pedido?

La estimación es difícil por muchas razones. En parte porque el desarrollo de software es una actividad de diseño, difícil de planear y costear. En parte porque los materiales básicos cambian rápidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son difíciles de predecir y cuantificar.

La naturaleza intangible del software también afecta. Es muy difícil saber qué valor aporta un rasgo de software hasta que se usa en realidad. Sólo cuando se usa realmente una versión temprana de algún software se empieza a entender cuáles rasgos son valiosos y cuáles no.

Esto lleva al punto irónico de que es de esperarse que los requisitos sean cambiables. Después de todo se supone que el software es "suave". Así no sólo son cambiables los requisitos, sino que deben de serlo. Toma mucha energía conseguir que los clientes de software corrijan los requisitos. Es aun peor si ellos han estado alguna vez en desarrollo de software, porque entonces "saben" que el software es fácil de cambiar.

Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente aún no estamos a salvo. En la economía de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado rápidamente. El que podría ser un buen conjunto de requisitos ahora, no será tan bueno en seis meses. Aún cuando el cliente pueda corregir sus requisitos, el mundo de negocios no va a detenerse por él. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa está mintiendo, o ya ha hecho mil millones en la bolsa de valores.

Casi todo en el desarrollo de software depende de los requisitos. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible.

¿Es Imposible la Previsibilidad?

En general, no. Hay algunos desarrollos de software dónde la previsibilidad es posible. Organizaciones como el grupo de software del trasbordador espacial de la NASA son un ejemplo selecto donde el desarrollo de software puede ser predecible. Requiere mucha ceremonia, mucho tiempo, un equipo grande y requisitos estables. Hay proyectos por ahí que son transbordadores espaciales. Sin embargo no creo que el software comercial encaje en esa categoría. Para éste se necesita un tipo diferente de proceso.

Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. La gente que trabaja en metodologías no es buena en identificar condiciones límite: los lugares donde la metodología pasa de apropiada en inapropiada. La mayoría de los metodologistas quieren que sus metodologías sean usadas por todos, de modo que no entienden ni publican sus condiciones límite. Esto lleva a la gente a usar una metodología en malas circunstancias, como usar una metodología predictiva en una situación imprevisible.

Hay una tentación fuerte para hacer eso. La previsibilidad es una propiedad muy deseable. No obstante creer que se puede ser predecible cuando no se puede, lleva a situaciones en donde las personas construyen un plan temprano, y entonces no pueden manejar la situación cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante algún tiempo usted podrá pretender que el plan es válido. Pero en algún punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la caída es dolorosa.

Así si usted está en una situación impredecible no puede usar una metodología predictiva. Ése es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relación con el cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes, que es difícil dejarlos ir. Como en tantos problemas la parte más difícil está simplemente en comprender que el problema existe.

De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. Más bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.


Controlando un Proceso Imprevisible – Iteraciones

¿Así que cómo nos controlamos en un mundo imprevisible? La parte más importante y difícil, es saber con precisión dónde estamos. Necesitamos un mecanismo honesto de retroalimentación que pueda decirnos con precisión cuál es la situación a intervalos frecuentes.

La llave para obtener esta retroalimentación es el desarrollo iterativo. Esta no es una idea nueva. El desarrollo iterativo ha estado durante algún tiempo bajo muchos nombres: incremental, evolutivo, escenificado, espiral... muchos nombres. La clave del desarrollo iterativo es producir frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de los rasgos requeridos. Éstos sistemas son cortos en funcionalidad, pero por otra parte deben ser fieles a las demandas del sistema final. Deben ser totalmente integrados y tan cuidadosamente probados como una entrega final.

El punto es que no hay nada como un sistema probado, integrado para traer una dosis poderosa de realidad en cualquier proyecto. Los documentos pueden esconder toda clase de fallas. El código no probado puede esconder bastantes defectos. Pero cuando las personas realmente se sientan delante de un sistema y trabajan con él, entonces las fallas se vuelven aparentes: tanto las relativas a defectos como las relativas a los requisitos mal entendidos.

El desarrollo iterativo también tiene sentido en los procesos predictivos. Pero es esencial en los procesos adaptables porque un proceso adaptable necesita poder tratar con los cambios en los rasgos requeridos. Esto lleva a un estilo de planear donde los planes a largo plazo son muy fluidos, y los únicos planes estables son a corto plazo hechos para una sola iteración. El desarrollo iterativo da un fundamento firme en cada iteración que puede usarse para basar los planes posteriores.

Una pregunta importante es cuánto debe durar una iteración. Diferentes personas dan respuestas diferentes. XP sugiere iteraciones de entre una y tres semanas. SCRUM sugiere un mes. Crystal estira aun más. La tendencia, de cualquier modo, es hacer cada iteración tan corta como se pueda manejar. Esto proporciona la retroalimentación más frecuente, así que usted sabe más a menudo donde se encuentra.


El Cliente Adaptable

Este tipo de proceso adaptable requiere un tipo diferente de relación con el cliente que las que se consideran a menudo, particularmente cuando el desarrollo es hecho por otra empresa. Cuando contrate una empresa separada para hacer el desarrollo del software, la mayoría de los clientes preferirán un contrato a precio fijo. Dígale a los desarrolladores lo que quieren, negocie, acepte una oferta, y entonces la carga queda en la empresa de desarrollo para construir el software.

Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la noción usual de precio fijo. Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosión muy dolorosa. La parte sucia de esta explosión es que el cliente queda herido tanto como la compañía de desarrollo de software. Después de todo el cliente no querría un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre. Así aun cuando no pague nada a la compañía de desarrollo, todavía pierde. De hecho pierde más de lo que pagaría por el software (¿por qué habría de pagar el software si el valor comercial de ese software fuera menor?).

De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones donde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.

Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que no se puede fijar el tiempo, precio y alcance. La manera ágil usual es fijar tiempo y precio y permitir que el alcance varíe de manera controlada.

En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteración puede tanto verificar el progreso como alterar la dirección del desarrollo de software. Esto lleva a una relación mucho más íntima con los desarrolladores de software, una verdadera sociedad de trabajo. Este nivel de compromiso no es para cualquier organización cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.

El beneficio importante para el cliente es un desarrollo de software mucho más sensible. Un sistema usable, aunque mínimo, puede entrar en producción pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y también aprender cómo se usa el sistema en realidad.

Una pieza tan importante como ésta es una visibilidad mayor sobre el verdadero estado del proyecto. El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente señalar cuándo la realidad y el plan divergen. El resultado común es un gran resbalón más tarde en el calendario del proyecto. En un proyecto ágil hay un constante rehacer del plan con cada iteración. Si las malas noticias están al acecho, tienden a aparecer más temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los métodos ágiles van más allá manteniendo corta la duración de la iteración, pero también viendo estas variaciones como oportunidades.

Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que está a tiempo y en costo es un éxito. Esta medida no tiene sentido en un ambiente ágil. Para el agilista la cuestión es el valor de negocio (beneficio) que el cliente consiga, es decir, un software más valioso que el costo que puso en él. Un buen proyecto predictivo irá de acuerdo al plan, un buen proyecto ágil construirá algo diferente y mejor que lo que se esperaba en el plan original.

Poniendo a la Gente Primero
No es fácil ejecutar un proceso adaptable. En particular requiere un equipo muy eficaz de desarrolladores. El equipo necesita ser eficaz tanto en la calidad de los individuos como en la manera en que funcionan juntos en equipo. Hay también una sinergia interesante: no sólo la adaptabilidad requiere un equipo fuerte, la mayoría de los buenos desarrolladores prefieren un proceso adaptable.

Juntar Unidades de Programación Compatibles

Uno de los objetivos de las metodologías tradicionales es desarrollar un proceso donde las personas involucradas sean partes reemplazables. Con tal proceso se puede tratar a las personas como recursos que están disponibles en varios tipos. Se tienen un analista, algunos programadores, algunos verificadores, un gerente. Los individuos no son tan importantes, sólo los roles lo son. De esa manera si usted planea un proyecto no importa qué analista y qué verificadores consiga, sólo hay que saber cuántos son para saber cómo afecta su plan el número de recursos.

Pero esto plantea una pregunta clave: ¿son las personas involucradas en el desarrollo de software partes reemplazables? Uno de los rasgos importantes de los métodos ágiles es el rechazo a esta afirmación.

Quizás el rechazo más explícito a las personas como recursos lo hace Alistair Cockburn. En su artículo “Caracterización de las Personas como Componentes No Lineales de Primer Orden en el Desarrollo de Software” [3], apunta a que los procesos predecibles requieren componentes que se comporten de manera predecible. Sin embargo las personas no son componentes predecibles. Además sus estudios de proyectos de software lo han llevado a concluir que la gente es el factor más importante en el desarrollo de software.

En el título de su artículo se refiere a las personas como "componentes". Así es como se trata a la gente en la literatura de diseño de procesos / metodologías. El error de este enfoque es que las "personas" son altamente inconstantes y no lineales, con modos únicos de éxito y fracaso. Esos factores son de primer orden, factores no despreciables. El fracaso de los diseñadores de procesos y metodologías para responder a esto contribuye a la clase de trayectorias de proyectos no planeados que vemos a menudo.
Uno se pregunta si la naturaleza del desarrollo de software funciona contra uno aquí. Cuando programamos una computadora, controlamos un dispositivo inherentemente predecible. Como estamos en este negocio porque somos buenos en hacerlo, estamos idealmente hechos para perturbarnos cuando nos enfrentamos con seres humanos.

Aunque Alistair Cockburn es el más explícito en su visión centrada en la gente del desarrollo de software, la noción de que la gente es primero es un tema común para muchos pensadores del software. El problema, demasiado a menudo, es que la metodología se ha opuesto a la noción de las personas como el factor de primer orden en el éxito del proyecto.

Esto crea un fuerte efecto de retroalimentación positiva. Si usted espera que todos sus desarrolladores se junten en unidades de programación compatibles, no intentará tratarlos como individuos. Esto baja la moral (y la productividad). Las personas capaces se buscarán un lugar mejor donde estar, y usted acabará con lo que usted deseaba: unidades de programación compatibles.

Decidir que las personas son primero es una gran decisión, que requiere mucha determinación. La noción de la gente como recursos es profundamente inculcado en el pensamiento de negocios, teniendo sus raíces en el impacto del enfoque de La Dirección Científica de Frederick Taylor. En la administración de una fábrica, este enfoque Taylorista tiene sentido. Pero para un trabajo altamente creativo y profesional, como creo es el desarrollo de software, esto no se sostiene. (Y de hecho la fabricación moderna también se está saliendo del modelo Taylorista).


Los Programadores son Profesionales Responsables

Una parte clave de la noción Taylorista es que la gente que hace el trabajo no es la mejor gente para entender la mejor manera de hacer el trabajo. En una fábrica esto puede ser verdad por varias razones. En parte porque la mayoría de los obreros no son las personas más inteligentes o creativas, en parte porque hay una tensión entre la gerencia y los obreros en que la gerencia gana más dinero y los obreros menos.

La historia reciente nos demuestra cada vez más lo falso que es esto en el desarrollo de software. A las personas brillantes y capaces les atrae cada vez más el desarrollo de software, tanto por su ostentación como por ganancias potencialmente mayores. (Ambas razones me tentaron a salir de la ingeniería electrónica). Cosas tales como opciones accionarias afirman el interés de los programadores en la compañía.

Aquí bien puede haber un efecto generacional. Una evidencia anecdótica me hace preguntarme si más gente brillante se han aventurado en el desarrollo de software en los últimos diez años. En ese caso ésta sería una razón para ese culto a la juventud en el negocio de la computación, como en la mayoría de los cultos se necesita un grano de verdad en él.

Cuando se quiere contratar y retener a gente capaz, hay que reconocer que son profesionales competentes. Como tales son los mejores para decidir cómo dirigir su trabajo técnico. La noción Taylorista de un departamento de planificación separado que decide cómo hacer las cosas sólo funciona si los planificadores entienden mejor cómo hacer bien el trabajo que aquellos que lo hacen. Si usted tiene personas brillantes, motivadas que hacen bien el trabajo entonces eso no se sostiene.

Manejando un Proceso Orientado a la Gente

La orientación a la gente se manifiesta de varias maneras diferentes en los procesos ágiles, lo que lleva a efectos diferentes, no todos consistentes.

Uno de los elementos clave es la aceptación de un proceso en lugar de la imposición de un proceso. A menudo los procesos de software se imponen desde la gerencia. Como tales se les resiste a menudo, particularmente cuando la gerencia ha estado fuera del desarrollo activo un buen tiempo. Aceptar un proceso requiere compromiso, y como tal se necesita el involucramiento activo de todo el equipo.

Esto termina con el resultado interesante de que sólo los desarrolladores pueden escoger seguir un proceso adaptable. Esto es particularmente cierto para la XP, que requiere mucha disciplina para ejecutarse. Aquí es donde Crystal es un complemento efectivo ya que apunta a una disciplina mínima.

Otro punto es que los desarrolladores deben poder tomar todas las decisiones técnicas. XP llega al corazón de esto cuando en su proceso de planeación establece que sólo los desarrolladores pueden estimar cuánto tiempo tomará hacer un trabajo.

Tal liderazgo técnico es un gran cambio para muchas personas en posiciones gerenciales. Tal acercamiento requiere compartir una responsabilidad donde desarrolladores y gerencia tienen un mismo lugar en la dirección del proyecto. Nótese que dije igual. La gerencia aun juega un papel, pero reconoce la pericia de los desarrolladores.

Una razón importante para esto es el ritmo del cambio de tecnología en nuestra industria. Después de unos años el conocimiento técnico se vuelve obsoleto. Esta vida media de habilidades técnicas no tiene parangón en cualquier otra industria. Incluso los técnicos tienen que reconocer que entrar a la gerencia significa que sus habilidades técnicas se marchitarán rápidamente. Los exdesarrolladores necesitan reconocer que sus habilidades técnicas desaparecerán rápidamente y necesitan confiar y depender en los desarrolladores actuales.

La Dificultad de Medir

Si usted tiene un proceso donde las personas que dicen cómo hacer el trabajo son distintas de las personas que realmente lo hacen, los líderes necesitan alguna manera de medir cuán eficaces son los que lo hacen. En la Dirección Científica había un impulso fuerte a desarrollar formas objetivas de medir el rendimiento de las personas.

Esto es particularmente pertinente al software debido a la dificultad de aplicar medidas al software. A pesar de nuestros mejores esfuerzos somos incapaces de medir las cosas más simples sobre el software, como la productividad. Sin buenas medidas para estas cosas, cualquier clase de control externo está condenado.

La introducción de gestión medida sin buenas medidas tiene sus propios problemas. Robert Austin [4] hizo una discusión excelente sobre esto. Él señala que cuando se mide el rendimiento usted tienen que conseguir todos los factores importantes bajo medida. Cualquier cosa que se olvide tiene el resultado inevitable que los hacedores alterarán lo que hacen para producir las mejores medidas, incluso si eso claramente reduce la verdadera efectividad de lo que hacen. Este trastorno de la medida es el talón de Aquiles de la gestión basada en medidas.

La conclusión de Robert Austin es que usted tiene que escoger entre la gestión basada en métricas y la gestión delegatoria (donde los hacedores deciden cómo hacer el trabajo). La gestión basada en métricas es más adecuada para el trabajo simple repetitivo, con bajos requisitos de conocimiento y rendimientos fácilmente medibles - exactamente lo contrario al desarrollo de software.

El punto de todo esto es que los métodos tradicionales han operado bajo la asunción de que la gestión basada en métricas es la manera más eficaz de administrar. La comunidad ágil reconoce que las características del desarrollo de software son tales que la gestión basada en métricas lleva el trastorno de la medida a niveles muy altos. Es realmente más eficaz usar un estilo delegatorio de administración, que es el tipo de acercamiento central del punto de vista agilista.


El Papel del Liderazgo de Negocio

Pero los técnicos no pueden hacer el proceso entero ellos solos. Necesitan una guía en las necesidades del negocio. Esto lleva a otro aspecto importante de los procesos adaptables: necesitan un contacto muy íntimo con los expertos del negocio.

Esto va más allá del compromiso de negocios en la mayoría de los proyectos. Los equipos ágiles no pueden existir con una comunicación ocasional. Necesitan un acceso continuo a los expertos del negocio. Además este acceso no es algo que se maneje a nivel gerencial, es algo que está presente para cada desarrollador. Como los desarrolladores son profesionales capaces en su propia disciplina, pueden trabajar como iguales con otros profesionales de otras disciplinas.

Gran parte de esto, claro está, se debe a la naturaleza del desarrollo adaptable. Como la premisa entera del desarrollo adaptable es que las cosas cambian rápidamente, se necesita un contacto constante para avisar a todos de los cambios.

No hay nada más frustrante para un desarrollador que ver desperdiciarse su duro trabajo. Así que es importante asegurar que hay pericia de negocios de buena calidad que está disponible al desarrollador y de calidad suficiente para que el desarrollador pueda confiar en ella.

El Proceso Auto-Adaptable
Hasta ahora he hablado sobre la adaptabilidad en el contexto de un proyecto adaptando frecuentemente su software para enfrentarse a los requisitos cambiantes de sus clientes. No obstante hay otro ángulo de la adaptabilidad: el del proceso que cambia con el tiempo. Un proyecto que empieza usando un proceso adaptable no tendrá el mismo proceso un año después. Con el tiempo, el equipo encontrará lo que funciona mejor para ellos, y alterará el proceso a su medida.

La primera parte de la auto adaptabilidad son las revisiones regulares del proceso. Normalmente se hacen con cada iteración. Al final de cada iteración, haga una reunión corta y hágase las siguientes preguntas (escogidas de Norm Kerth [5])



  • ¿Qué hicimos bien?

  • ¿Qué hemos aprendido?

  • ¿Qué podemos hacer mejor?

  • ¿Qué es lo que nos confunde?

Estas preguntas traerán ideas para cambiar el proceso en la siguiente iteración. De esta manera un proceso que empieza con problemas puede mejorar conforme el proyecto avanza, adaptándose mejor al equipo que lo usa.

Si la auto adaptabilidad ocurre dentro de un proyecto, es aun más marcada en una organización. Para ahondar el proceso de la auto adaptabilidad sugiero que los equipos hagan una revisión más formal e hitos del proyecto mayores siguiendo las sesiones retrospectivas del proyecto esbozadas por Norm Kerth. Estas retrospectivas involucran reuniones de 2-3 días y un facilitador entrenado. Ellas no solo dan aprendizaje al equipo, también dan aprendizaje a la organización entera.

Una consecuencia de la auto adaptabilidad es que nunca se debe esperar encontrar una metodología corporativa única. En cambio cada equipo debe no simplemente escoger su propio proceso, debe también afinar activamente su proceso conforme avanza el proyecto. Mientras que tanto los procesos publicados como la experiencia de otros proyectos pueden actuar como una inspiración y una línea de fondo, la responsabilidad profesional de los desarrolladores es adaptar el proceso a la tarea en mano.

Esta auto adaptabilidad es muy marcada en ASD y Crystal. Las reglas rígidas de la XP parecen desaprobarla, pero ésa es sólo una impresión superficial ya que la XP anima a la gente a afinar el proceso. La diferencia principal de la XP es que sus promotores sugieren hacer XP al pie de la letra por varias iteraciones antes de adaptarlo. Además las revisiones no son enfatizadas, ni parte del proceso, aunque hay sugerencias de que las revisiones deberían ser una de las prácticas de la XP.



Las Metodologías Ágiles valoran:
En la Alianza Ágil [6] establecen como valores de los MA:

  1. Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas.

  2. Desarrollar software que funciona más que conseguir una buena documentación, implica minimalismo respecto del modelado y la documentación del sistema.

  3. La colaboración con el cliente más que la negociación de un contrato.

  4. Responder a los cambios más que seguir estrictamente una planificación.

¿Por qué surgen las Metodologías Ágiles?
En [7] se destacan los siguientes puntos como los principales motivos de surgimiento de los MA:

  1. Dificultad para implantar metodologías tradicionales. Sofisticadas herramientas CASE y notaciones (UML)

  2. Una solución a medida para un segmento importante de proyectos de desarrollo de software

  3. Pugna entre comunidades / gurúes

  4. Aceptar el cambio

Costo de los Cambios en la Construcción de SW
D
e [7] se pudo extraer la Figura 1 que se muestra a continuación. En la misma se muestra el costo de producir cambios en el software que se desarrolla mediante una metodología tradicional versus el costo de producir cambios en el software que se desarrolla mediante alguna de las metodologías ágiles. Como se puede apreciar, a medida que avanza el tiempo, el costo es exponencial en el caso de la construcción mediante una metodología tradicional.
Figura 1: Función de costos de cambio en el software desarrollado

Manifiesto de las Metodologías Ágiles
En un taller de dos días en Snowbird, Utah, en febrero de 2001 se reunieron los representantes de cada una de las metodologías ágiles. Había mucho en común, y este reconocimiento era mucho mayor que las diferencias entre los procesos.

Además de un contacto útil entre los líderes de procesos, existía también la idea de emitir una declaración conjunta en favor de procesos de desarrollo de software ágiles.

El resultado es un Manifiesto para el Desarrollo de Software Ágil [8], una declaración de los principios y valores comunes de los procesos ágiles.

Hay también un deseo de colaborar más en el futuro, para animar más tanto a tecnólogos como a gente de negocios para usar y requerir acercamientos ágiles al desarrollo de software.

El manifiesto fue sólo eso, una publicación que actuó como un punto de partida para aquellos que compartían estas ideas básicas. Uno de los frutos del esfuerzo fue la creación de un cuerpo más longevo, la Alianza Ágil [6]. La Alianza Ágil es una organización sin fines de lucro que busca promover el conocimiento y la discusión de todos los métodos ágiles. Muchos de los líderes de metodologías de desarrollo de software ágiles son miembros y líderes de la Alianza Ágil.

Los principios que se establecieron en el manifiesto son:



  1. La prioridad principal es satisfacer al cliente mediante tempranas y continuas entregas de software que le reporte un valor.

  2. Dar la bienvenida a los cambios. Los MA capturan los cambios para que el cliente tenga una ventaja competitiva.

  3. Entregar frecuentemente software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre una entrega y la siguiente.

  4. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

  5. Construir el proyecto entorno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir el trabajo.

  6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

  7. El software que funciona es la medida principal de progreso.

  8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

  9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

  10. La simplicidad es esencial.

  11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

  12. En intervalos regulares, el equipo reflexiona respecto de cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

Comparación Ágil - ¬Ágil

Metodología Ágil

Metodología No Ágil (Tradicional)


Pocos artefactos

Más artefactos

Pocos roles

Más roles

No existe un contrato tradicional o al menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo (además in-situ)

El cliente interactúa con el equipo de desarrollo mediante reuniones

Grupos pequeños (< 10 integrantes) y trabajando en el mismo sitio

Grupos grandes

Menos énfasis en la arquitectura

La arquitectura es esencial
  1   2   3


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal