• No se han encontrado resultados

Cibernética organizacional y metodologías ágiles de desarrollo de software

N/A
N/A
Protected

Academic year: 2020

Share "Cibernética organizacional y metodologías ágiles de desarrollo de software"

Copied!
76
0
0

Texto completo

(1)Cibernéti ca organi za cional y metodologías ágiles de desa rrollo de softwa re. LUIS ALBERTO PINEDA SOTO. Di rector Roberto Za rama. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INDUSTRIAL BOGOTA D.C. 2008. 1.

(2) Cibernéti ca organi za cional y metodologías ágiles de desa rrollo de softwa re. LUIS ALBERTO PINEDA SOTO. Tesis de Grado. Di rector Roberto Za rama. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INDUSTRIAL BOGOTA D.C. 2010 Nota de aceptaci ón.. 2.

(3) ____________________________. ____________________________. ____________________________. ____________________________ Di rector de Proyecto. ____________________________ Jurado. ____________________________ Jurado. Bogotá D.C. Di ciembre 2008. 3.

(4) Tabla de contenido. 1. Introducción.......................................................................................................................... 6 1.1 Contexto.......................................................................................................................... 6 1.2 Situación actual................................................................................................................ 7 1.3 Formulación del problema ................................................................................................ 8 2. Objetivos............................................................................................................................... 9 2.1. Objetivo General ............................................................................................................. 9 2.2. Objetivos Específicos ....................................................................................................... 9 3. Ingeniería de Software ......................................................................................................... 10 3.1 Historia.......................................................................................................................... 10 3.2 Problemas en la industria del software ............................................................................ 11 3.3 Metodologías Tradicionales ............................................................................................ 12 3.3.1 Modelo cascada....................................................................................................... 12 3.3.2 RUP......................................................................................................................... 14 3.3.3 Dificultades ............................................................................................................. 16 3.4 Metodologías Ágiles ....................................................................................................... 18 3.4.1 Definición................................................................................................................ 18 3.4.2 Características ......................................................................................................... 18 3.4.3 Historia ................................................................................................................... 19 3.4.4 Fundamentos y principios ágiles ............................................................................... 20 3.4.5 eXtreme Programming (XP) ...................................................................................... 21 3.4.6 Dificultades y limitaciones para implementar ágil ...................................................... 29 4. Evolución de las teorías de administración y del desarrollo de software.................................. 31 4.1 Teorías Clásicas de la administración............................................................................... 31 4.2 Teoría de las relaciones Humanas ................................................................................... 32 4.3 Teoría de Sistemas ......................................................................................................... 34 4.3.1 Sistemas socio‐técnicos y eXtreme Programming....................................................... 36 5. Cibernética.......................................................................................................................... 39 5.1 Historia.......................................................................................................................... 39 5.2 Definición...................................................................................................................... 39 4.

(5) 5.3 Conceptos de sistemas auto‐organizados ........................................................................ 41 5.4 El VSM (Viable System Model) ........................................................................................ 43 5.4.1 Introducción............................................................................................................ 43 5.4.2 Conceptos ............................................................................................................... 44 5.4.3 Estructura del VSM .................................................................................................. 48 6. VSM como herramienta de interpretación de las metodologías de desarrollo de software ...... 50 6.1 Comparación de metodologías RUP y eXtreme programming ........................................... 51 7. Equipos de trabajo auto‐organizados (SMWT) ....................................................................... 58 7.1 Introducción .................................................................................................................. 58 7.2 Ventajas y Desafíos de los SMWTs................................................................................... 59 7.2.1 Ventajas .................................................................................................................. 59 7.2.2 Desafíos .................................................................................................................. 60 7.2.3 Entorno cambiante vs Entorno estable...................................................................... 62 7.3 Factores determinantes para el éxito de los SMWTs......................................................... 62 7.4 Formación de SMWTs..................................................................................................... 68 7.5 SMWTs y eXtreme Programming (XP).............................................................................. 70 8. Conclusiones ....................................................................................................................... 72 9. Bibliografía .......................................................................................................................... 74. 5.

(6) 1. Introducción 1.1 Contexto La cibernética estudia el control y manejo de información en sistemas, en palabras de Weiner, su padre, es la ciencia de la comunicación y el control en los animales y las maquinas (Weiner 1948). Esta disciplina provee herramientas para un análisis estructurado y detallado del comportamiento de los sistemas. A lo largo de su historia, ha demostrado claramente su aplicación en numerosas áreas del conocimiento (por ejemplo distintas ingenierías y ciencias sociales). Dentro de las herramientas más valiosas desarrolladas por esta disciplina se encuentran las que facilitan el estudio de sistemas, analizando para estos sus límites, complejidad y estructura. La ingeniería de software es una disciplina joven, (40 a 50 años). Esta disciplina se propone modelar los procesos para la preparación, construcción y administración general de proyectos de desarrollo de software. En la actualidad existen numerosas propuestas para la administración de proyectos, las más conocidas son eXtreme programming, Scrum, y RUP (Rational Unified Process). La rápida evolución que presentan las tecnologías de información y la creciente complejidad de las necesidades relacionadas a sistemas de información en las organizaciones han dado surgimiento a proyectos de software de proporciones inmensas. Dichos proyectos se caracterizan por tener gran cantidad de requerimientos funcionales y no‐funcionales, los cuales exigen de una gran capacidad técnica y de trabajo en equipo para ser resueltos satisfactoriamente. Los equipos de desarrollo cuentan con la habilidad técnica de sus integrantes y una metodología de desarrollo (en el mejor de los casos) como principales herramientas para diseñar y construir la solución esperada por los stakeholders del proyecto. Sin embargo las herramientas mencionadas no han sido suficientes para resolver y lidiar eficientemente con las situaciones conflictivas que frecuentemente se presentan en los proyectos de software. Estos, en su gran mayoría siguen fallando considerablemente en sus restricciones más básicas: tiempo, presupuesto.. 6.

(7) 1.2 Situación actual Durante los últimos 20 años la inversión en software ha presentado un crecimiento acelerado (Cusumano, 2004), esto se debe a que las organizaciones soportan cada vez más su operación en tecnologías de información. En 1995 se reportó en los Estados Unidos una inversión de $250 billones de dólares en el desarrollo de sistemas de información (Standish Group, 1995), se estima que la cifra en la actualidad es mucho mayor. Un reflejo de lo anterior es el incremento en la demanda por profesionales en el área de la ingeniería de software, el U.S. Department of Labor estima para la década del 2006 al 2016 un incremento del 38% en la demanda de ingenieros de software (Bureau of Labor Statistics, U.S. Department of Labor, 2008), cifra bastante superior a las estimadas para las demás ocupaciones. En la industria del software es bastante conocido y discutido un estudio realizado en el año 1995 conocido como The chaos report elaborado por The Standish Group. Este estudio presenta de manera concisa cifras bastante desalentadoras referentes al desempeño de numerosos proyectos de software. Dentro de los resultados más impactantes resaltan los siguientes (Standish Group, 1995):. • • •. 31.1% de los proyectos serán cancelados antes de terminar. 52.7% de los proyectos costarán 189% de presupuesto definido inicialmente. En promedio los proyectos toman el doble del tiempo que inicialmente tenían planeado.. En la actualidad las cifras no son muy diferentes (Standish Group, 2009): • •. 44% de los proyectos finalizan con desfases significativos en presupuesto y cronograma. 24% de los proyectos son cancelados antes de terminar o son finalizados y el producto nunca usado.. Es claro entonces que el desempeño de los proyectos de software no ha cambiado sustancialmente en 15 años. La situación descrita conforma un problema de interés para numerosos actores, principalmente para las organizaciones que invierten grandes sumas en el desarrollo de IT y no obtienen los beneficios esperados en el momento esperado. Adicionalmente las organizaciones que ofrecen servicios de desarrollo de IT se ven comprometidas financieramente al perder el control de los costos y tiempos de sus proyectos.. 7.

(8) 1.3 Formulación del problema Como consecuencia de la búsqueda de nuevas y mejores formas de administrar proyectos de software, durante los últimos años ha tomado fuerza el movimiento de metodologías ágiles de desarrollo. Existen numerosas empresas que han adoptado correctamente estas nuevas metodologías y han visto como la tasa de éxito de sus proyectos ha mejorado considerablemente. Un proyecto de software involucra numerosas personas en el proceso de desarrollo del software. En dicho proceso se tiene un abundante flujo de información de diferentes ámbitos (técnica, humana, política, etc.) la cual no siempre es administrada de forma eficiente. Las metodologías de desarrollo de software tradicionales se han preocupado casi exclusivamente por la forma de especificar y diseñar de forma correcta el software (información técnica), por otro lado las metodologías ágiles se han preocupado más por el diseño de procesos o mecanismos que administren los flujos de información de otros ámbitos (humano, político, etc.). En el presente trabajo de investigación se desea estudiar bajo un marco de cibernética organizacional las metodologías ágiles de desarrollo de software. Esto con el fin de identificar la razón de su éxito, sus limitaciones y posibles mejoras.. 8.

(9) 2. Objetivos 2.1. Objetivo General. La presente investigación se propone estudiar las metodologías ágiles de desarrollo de software bajo un marco de cibernética organizacional. Para lograr este objetivo primero es necesario crear un lenguaje común y generar un conocimiento básico de las dos disciplinas que abarca la investigación, es decir, la ingeniería de software y la cibernética (principalmente organizacional). Una vez desarrollado este conocimiento general se puede entender cómo varios conceptos y principios de la cibernética organizacional son traducidos al marco de la ingeniería de software y en particular a las metodologías ágiles de desarrollo de software.. 2.2. Objetivos Específicos. 1. Introducir la disciplina de la ingeniería de software y exponer sus principales retos. 2. Introducir los principios que rigen las metodologías ágiles de desarrollo de software. 3. Describir la metodología ágil eXtreme Programming. 4. Introducir el VSM (Viable System Model) de Stafford Beer. 5. Mediante el uso del VSM (Viable System Model) identificar las fortalezas y debilidades de las metodologías RUP (Rational Unified Process) y eXtreme programming. 6. Comparar los principios de las metodologías ágiles de desarrollo de software con las ideas desarrolladas por la teoría de SMWT (Self Managed Work Teams) para encontrar posibles complementos a las metodologías ágiles.. 9.

(10) 3. Ingeniería de Software. 3.1 Historia Para entender los orígenes de la ingeniería de software resulta útil estudiar los proyectos desarrollados a lo largo de la historia de IBM (Cusumano, 2004) ya que fue esta empresa la que primero se enfrentó a los retos que supone el desarrollo de software a gran escala. Uno de los principales proyectos en la historia de IBM fue el desarrollo del sistema OS/360 llevado a cabo entre 1963 y 1966. En su momento, el proyecto fue el más grande esfuerzo que se había visto en la industria del software. En ese proyecto participaron más de mil personas, las cuales durante tres años desarrollaron alrededor de un millón de líneas de código. El proyecto costó medio millón de dólares (cuatro veces el presupuesto original) y fue terminado con un año de retraso (Cusumano, 2004), el producto fue lanzado al mercado con numerosos bugs o defectos. Uno de los gerentes del desarrollo del OS/360 se inspiró en su experiencia en el proyecto y publicó en 1975 uno de los clásicos de la ingeniería de software: The mythical Man Month. En esta obra, Frederick Brooks enuncia un descubrimiento crucial: para un proyecto de software de grandes dimensiones, el número de personas y meses de trabajo no son variables intercambiables. Brooks encontró que adicionar personas a un proyecto que se encuentra atrasado resulta en atrasos aún mayores, esto debido al crecimiento geométrico en los problemas de comunicación y coordinación que ocurren al incrementar el tamaño de los equipos de desarrollo (Cusumano, 2004). Esta conclusión es conocida en el mundo de la ingeniería de software como la ley de Brooks. Las dificultades enfrentadas por IBM en los años sesenta, crearon conciencia en cuanto a la necesidad de definir y aplicar prácticas industriales, metodologías y herramientas que hicieran del desarrollo de software una disciplina más formal, siendo esta disciplina lo que hoy se conoce como la ingeniería de software.. 10.

(11) 3.2 Problemas en la industria del software. Hacia el año de 1960 nacía la ingeniería de software, esto debido al aumento en el tamaño y la complejidad de las aplicaciones desarrolladas. La industria del software empezó a notar que en la construcción del software se debía aplicar ingeniería, no bastaba con desarrolladores talentosos, era fundamental contar con mecanismos más formales para administrar y definir un proyecto de software. En 1968 en Bruselas se dieron cita los principales protagonistas de la industria del software en la conferencia NATO de ingeniería de software, en ella se presentó el informe en el cual se describían las principales dificultades que enfrentaban las empresas de software en la época. Los principales problemas identificados por los conferencistas de NATO 1968 fueron (NATO science committee, 1969): •. Falta de entendimiento y consenso entre los clientes y los diseñadores de los requerimientos.. •. Brechas significativas en tiempos y costos planeados vs reales. Técnicas débiles de estimación de tamaño y complejidad del software. Variabilidad inmensa en la productividad de los programadores (hasta 26:1). Dificultades a la hora de dividir las labores de diseño y construcción, ya que un diseño completo de una aplicación implica un nivel de construcción considerable.. • • • •. •. • • •. Dificultad en el monitoreo del avance de los proyectos. El software no es tangible por lo tanto es difícil determinar el estado real de progreso de los proyectos. Comunicación ineficiente entre los integrantes de los grupos de desarrollo, causada por exceso de comunicación de información innecesaria, y la falta de automatización en la comunicación de la información necesaria. El desarrollo de software mezcla constantemente en los proyectos las labores de investigación, desarrollo y producción. Por el contrario en industrias más tradicionales, estas labores se encuentran claramente diferenciadas y son ejecutadas en momentos del tiempo separados. Dependencia del software con el hardware, lo que hace que la estandarización y despliegue del software constituya un proceso tedioso y costoso. Falta de mecanismos que permitan una reutilización eficiente de los componentes de software ya desarrollados que puedan ser de utilidad en diferentes proyectos. Costos del mantenimiento del software frecuentemente son superiores a los costos de desarrollo del mismo.. 11.

(12) Si se comparan los problemas mencionados por el reporte NATO en 1968 con resultados obtenidos en reportes similares realizados en las últimas décadas es alarmante encontrar que poco ha cambiado1 . La gran mayoría de estos problemas siguen presentándose frecuentemente en los proyectos de software de actualidad, esto finalmente se traduce en proyectos cuyos cronogramas y presupuestos son mucho mayores a los estimados inicialmente. Analizando el listado de problemas enunciados en la conferencia NATO cabe notar que aunque el desarrollo de software de gran escala presenta retos significativos desde el punto de vista técnico, la mayoría de los problemas descritos no podrían incluirse dentro esta categoría (problemas técnicos). Por el contrario, la mayoría de los problemas podrían incluirse en una categoría de problemas de organización y de comunicación, los cuales surgen de la interacción entre los diferentes individuos que participan en los proyectos, en especial la interacción entre el equipo de desarrollo y los clientes. En general los problemas descritos se reducen a problemas de comunicación, coordinación y planeación de esfuerzos de los individuos partícipes de un proyecto de software. En la actualidad la comunidad de ingenieros y desarrolladores de software es bastante amplia y dinámica, los foros que se pueden encontrar en internet que tratan estos temas son numerosos y cuentan con gran participación2 . Una visita a cualquiera de estos foros confirma que la mayoría de los problemas que enfrenta el desarrollo de software se encuentran relacionados con el entendimiento y comunicación entre los desarrolladores, los directores de proyecto y los clientes.. 3.3 Metodologías Tradicionales. 3.3.1 Modelo cascada. El modelo en cascada fue uno de los primeros y más difundidos esquemas de desarrollo de software. Fue desarrollado en el año de 1970 por el norteamericano Winston Royce. En este se establece una estructura secuencial de actividades a realizar a lo largo del ciclo de vida de un proyecto de software:. 1. Uno de los estudios recientes más conocido es e l Chaos Report de l Standish Group, realizado por prime ra vez en el año de 1995. 2 Algunas de las paginas que frecuentemente discuten es tos temas s on www.stackoverflow.com, www.infoq.com,. 12.

(13) El modelo en cascada especificaba el ideal de actividades a seguir, la iteración de estas actividades solo se contemplaba como una contingencia a las dificultades que se pueden presentar en el transcurso de un proyecto, es decir las iteraciones no se encontraban planeadas para el proyecto. Algo que ocurría frecuentemente al usar el modelo cascada era que sólo se detectaban los defectos más costosos del software en etapas avanzadas del proyecto (generalmente pruebas), lo cual es una consecuencia natural de la estructura secuencial del modelo, la cual solo arroja software funcional en las etapas finales del proyecto. El desarrollo de software tiene la particularidad de que se inserta una cantidad considerable de errores en la etapa de construcción (codificación), sin embargo estos errores son inherentes a la naturaleza propia del trabajo que se realiza, la corrección de los mismos en la mayoría de los casos no supone mayor esfuerzo por parte de los desarrolladores. Por otra parte, los errores que resultan letales y realmente costosos para un proyecto de software son los que ocurren en la etapa de diseño (Cusumano, 2004). El modelo en cascada pretende trazar una delimitación clara entre el diseño y la construcción del software, sin embargo esto ha probado ser casi imposible (Cusumano, 2004), ya que entre más detallado sea el proceso de diseño más se aproxima al proceso de construcción del producto. Por otra parte, uno de los elementos en los que el modelo de cascada hacía mayor énfasis era en la documentación del software. En palabras de Winston Royce: “The first rule of managing software development is ruthless enforcement of documentation requirements” (Royce, 1970). 13.

(14) Este énfasis en la documentación era entendible para el entorno de la década de los 70, donde los lenguajes de programación eran complejos, poco intuitivos y altamente acoplados al hardware donde el código se ejecutaría. Por estas razones los requerimientos, el diseño y el código debían ser meticulosamente documentados, de otra manera nadie sería capaz de realizar mantenimiento del software o si quiera saber las funcionalidades principales del mismo. El modelo cascada consideraba importante la participación del cliente para el buen desarrollo de un proyecto de software. Sin embargo, en la práctica el cliente sólo se veía involucrado en el levantamiento de requerimientos del software y en la etapa de pruebas, varios meses después de iniciado el proyecto. Esto resultaba fatal para numerosos proyectos, ya que el cliente sólo interactuaba con el software una vez terminado el proyecto, momento en el cual es muy difícil y costoso realizar ajustes o correcciones sobre el sistema.. 3.3.2 RUP. A medida que la tecnología siguió evolucionando, lo mismo hizo la ingeniería de software. El hardware, los lenguajes de programación y los sistemas operativos evolucionaron, los sistemas a desarrollar se volvieron cada vez más grandes y complejos. La evolución del modelo cascada fue el modelo RUP (Rational Unified Process), este modelo presenta una estructura más flexible y se esfuerza por especificar con mayor detalle cada una de las fases a seguir en un proyecto de software. El modelo presenta un mayor dinamismo frente al propuesto por el modelo cascada. Se motiva al director de proyecto en ajustar el modelo RUP a las necesidades particulares del proyecto a realizar, las iteraciones de las distintas etapas se planean desde el inicio del proyecto y se define una serie de artefactos de documentación escrita y visual para cada una de las fases del proyecto.. 14.

(15) Modelo RUP http://www.ibm.com/developerworks/rational/library/content/RationalEdge/may04/4763_fig2.jpg. RUP fue concebido para combatir los riesgos de naturaliza técnica asociados a cualquier proyecto de software, como lo son las tecnologías desconocidas, los requerimientos no especificados a tiempo y la complejidad en la arquitectura de los sistemas. Los principios que el proceso RUP estableció para minimizar los riesgos mencionados fueron (IBM, 2005): •. •. Desarrollo iterativo: el desarrollo de software es un proceso creativo y como tal requiere de varias iteraciones sobre las distintas etapas del proyecto para lograr un producto de calidad. Administración de requerimientos: el éxito de los proyectos de software depende de desarrollar un producto que cumpla efectivamente las necesidades del cliente. Las “necesidades del cliente” se consignan en los requerimientos, estos requieren de un proceso de administración que contemple el levantamiento y refinamiento de los mismos.. •. Arquitectura de componentes: a medida que los sistemas se hacen más complejos y de mayores proporciones se hace necesario estructurar la solución en componentes reutilizables con responsabilidades claramente diferenciadas. La utilización de componentes facilita el mantenimiento y propicia el desarrollo paralelo de distintas funcionalidades de un sistema.. •. Modelaje visual: constituye uno de los principales aportes del RUP a la ingeniería de software. RUP describe varios diagramas usados a la hora de diseñar software, estos diagramas son usados para modelar de manera gráfica la estructura, el comportamiento, y la interacción de un sistema.. 15.

(16) • •. Monitoreo continuo de la calidad: la calidad general de producto se verifica meticulosamente al final de cada iteración. Administración del cambio: Los requerimientos, la arquitectura, los escenarios de pruebas y casi todos los aspectos relacionados a un proyecto de software inevitablemente cambian con el paso del tiempo. Cada uno de los artefactos definidos para el proyecto deben administrarse a lo largo de todo el proyecto mediante una meticulosa documentación.. 3.3.3 Dificultades. Las metodologías tradicionales intentaron imponer un proceso disciplinado de desarrollo de software con el objetivo de hacer el desarrollo de software más eficiente y predecible (Fowler, 2005). Para lograrlo desarrollaron procesos detallados inspirados en otras ingenierías con un fuerte énfasis en la planeación y documentación. El resultado de estos procesos meticulosamente diseñados fue una metodología plagada de burocracia en la cual hay tantas cosas por documentar y planear que queda poco tiempo en para el desarrollo del software. En realidad las metodologías tradicionales de software pueden verse como un reflejo del anhelo por la predictibilidad. En general los humanos preferimos lo predecible, así podemos planear, controlar y asegurar un futuro deseado. RUP es una metodología predictiva, es decir pretende anticipar todas las situaciones que pueden ocurrir en un proyecto (Fowler, 2005). En RUP se busca llegar a un nivel bastante alto de especificación de arquitectura y requerimientos con el fin de minimizar los cambios que ocurran sobre cada uno de los componentes del sistema a desarrollar. En el mundo de hoy, las organizaciones modernas dependen cada vez más de los sistemas de información que sustentan su operación. Los clientes exigen cada vez más proyectos, los cuales son más complejos y para los cuales se tiene marcos de tiempo mucho más ajustados que en el pasado. Las tecnologías a usar evolucionan a un ritmo mucho más rápido del que las empresas y los desarrolladores pueden asimilar. La lucha en busca de la predictibilidad en el contexto en el que se encuentra la ingeniería de software en el presente cada vez se hace más difícil. En el último reporte del Standish Group se evidencia que: • 44% de los proyectos finalizan con desfases significativos en presupuesto y cronograma. • 24% de los proyectos fracasan (son cancelados antes de terminar o son finalizados y el producto nunca usado).. Desde hace unas dos décadas hasta el presente estas metodologías han sido las más usadas, sin embargo eso no quiere decir que son las que presenten mayor tasa de éxito de proyectos, o las que mejor acogida tengan entre los desarrolladores. De hecho la cantidad de documentación y burocracia ha hecho que para muchos desarrolladores su día a día esté lleno de tareas tediosas y repetitivas. 16.

(17) Según Fowler (1995) los aspectos en los que las metodologías tradicionales han tenido mayores dificultades son los siguientes: •. Separar el diseño de la construcción: la analogía con la ingeniería civil o mecánica no ha funcionado muy bien. En estas disciplinas la máquina o estructura se diseña meticulosamente, en esta fase es donde la mayoría del trabajo intelectual es realizado; la construcción en cambio se deja a personas menos calificadas intelectualmente. El software por el contrario a mostrado ser una disciplina en donde no se puede diferenciar claramente el diseño de la construcción (Fowler, 2005). En la ingeniería civil el 10% del costo y esfuerzo es empleado en la labor de diseño, mientras que en el software este esfuerzo haciende al 85% (Fowler, 2005). El diseño de software es una tarea creativa, y resulta casi imposible planear o predecir una actividad creativa. El software es una actividad bastante diferente por lo tanto es importante acabar con la analogía con las otras ingenierías y pretender obtener un diseño garantizado y definitivo de un sistema de software.. •. Predictibilidad de los requerimientos: las metodologías tradicionales han plasmado los requerimientos como contratos con el cliente. El objetivo es dedicar suficiente tiempo a la especificación de los mismos para evitar que estos cambien en el futuro (agregar, eliminar o modificar). Asumir que los requerimientos de software no van a cambiar en el transcurso del proyecto ha probado ser muy costoso. Pareciera más bien que es natural que los requerimientos cambien, lo que hoy es una funcionalidad indispensable del software puede ser obsoleta para la organización dentro de seis meses, lo que hoy era considerado como un requerimiento deseable puede probar ser indispensable dentro de seis meses. La naturaleza intangible del software entra a jugar un papel importante, ya que el valor real de una funcionalidad solo podrá ser apreciado una vez el producto esté finalizado y sea puesto en uso.. •. Personas como componentes: las metodologías tradicionales no tienen noción de los individuos, para el proceso las personas son vistas como componentes o recursos reemplazables, los cuales tienen roles determinados. La naturaleza predictiva de RUP va en contra de la naturaleza de los “componentes” más importantes del proceso, las personas no son predecibles ni son componentes reemplazables. En realidad las personas han probado ser el factor más importante para el éxito de los proyectos (Cockburn, Characterizing people as non‐linear, first‐order components in software development, 1999) y sin son tratadas como componentes reemplazables la moral y la productividad se verán gravemente afectadas (Fowler, 2005).. 17.

(18) 3.4 Metodologías Ágiles 3.4.1 Definición. Las metodologías ágiles consisten en el conjunto de prácticas de desarrollo de software que promueven: la entrega frecuente de piezas funcionales de software, un esquema de trabajo centrado en el trabajo en equipos auto‐organizados y auto‐gobernados, con miembros tanto del área técnica como del área de negocio. La preocupación constante de estos equipos de trabajo es responder de forma ágil y certera las necesidades reales del cliente (Beck, y otros, 2001).. 3.4.2 Características. Como respuesta a las dificultades encontradas en las metodologías tradicionales de desarrollo, la comunidad inició la búsqueda de nuevas formas de hacer su trabajo. Las nuevas metodologías se fundamentan en esquemas de trabajo mucho más ligeros y flexibles, que tienen los objetivos fundamentales de: • •. Mantener el control del presupuesto y cronograma de los proyectos. Desarrollar software de calidad que satisfaga a tiempo las necesidades de los clientes.. Hacia mediados de los años noventa la comunidad del software presenció el surgimiento nuevas metodologías que paulatinamente, al tiempo que ganaban aceptación, fueron bautizadas con el nombre de metodologías ágiles (Cusumano, 2004). Como principal contraste frente a las metodologías tradicionales, el pensamiento ágil es más adaptativo que predictivo (Fowler, 2005). La naturaleza de las metodologías tradicionales es evitar el cambio, mientras que las metodologías agiles invitan a el cambio (Fowler, 2005). Las metodologías tradicionales buscan la predictibilidad, el pensamiento ágil busca el control sobre lo impredecible, la adaptabilidad. Las metodologías ágiles están más orientadas a las personas que a los documentos y procesos (lo cual era habitual en las metodologías tradicionales). Proponen un desarrollo de software mucho más participativo, en la cual resulta fundamental un nuevo tipo de relación con los clientes. Esta nueva relación exige un cliente adaptativo, que entienda la naturaleza cambiante de los requerimientos, lo cual obliga a que las variables de presupuesto, tiempo y alcance deban ser balanceadas acorde a la realidad del proyecto. Generalmente las metodologías ágiles proponen fijar presupuesto y tiempo, dejando que el alcance varíe de manera controlada (Fowler, 2005). Adicionalmente, estas metodologías, argumentan que los ciclos de desarrollo excesivamente largos no responden de la forma más eficiente a un entorno que cambia a una velocidad cada día mayor. La única manera de mantener el control en un entorno impredecible es un mecanismo de 18.

(19) retroalimentación frecuente (Fowler, 2005), este mecanismo son las iteraciones. Al final de cada iteración se debe tener una versión del software final (prototipo), el cual cuenta con un subconjunto de las funcionalidades que tendrá el producto final. Estos prototipos son el mecanismo más eficiente para determinar el estado real de un proyecto, da la oportunidad al equipo de desarrollo detectar defectos en integración de componentes y brinda espacio a los clientes para interactuar con el producto antes de estar terminado. El proceso ágil es adaptativo en contraste con el predictivo de las metodologías tradicionales. Para lograr un proceso adaptativo ágil Finalmente, las metodologías ágiles sustentan que los más grandes problemas que enfrentan los proyectos de software se encuentran relacionados a deficiencias en la comunicación entre los individuos que hacen parte de los proyectos (gerentes de proyecto, arquitectos, desarrolladores, clientes, analistas, etc.). Por esta razón los desarrolladores son tratados como individuos y no como recursos.. 3.4.3 Historia. De acuerdo con lo presentado por (Larman & Basili, 2003), la idea de utilizar ciclos cortos para mejorar los procesos productivos, comenzó con la propuesta del ciclo de Planear‐Hacer‐Estudiar‐ Actuar (PDSA, por sus siglas en inglés), elaborada en los años treinta por Walter Shewart. Desde los años cuarenta uno de los gurús de calidad más reconocidos, W. Edwards Deming, promovió el PDSA como herramienta de mejora no solo operativa sino también administrativa. Uno de los proyectos pioneros en el uso de ciclos cortos de desarrollo, a comienzo de los años sesenta, fue el proyecto Mercury de la Nasa. En este proyecto se realizaban iteraciones de hasta medio día, al igual que se experimentó con prácticas que hoy en día se conocen como pair‐ programming3 y desarrollo dirigido por pruebas4 (TDD). Sin embargo, fue durante la década de los setentas, como lo indica Larman y Basili, que las prácticas de trabajo iterativo (hasta ese momento poco conocidas y consideradas como experimentales) fueron abandonadas por la adopción masiva de lo que se conoció como el modelo cascada, diseñado por Winston Royce en su artículo de 1970 “Managing the Development of Large Software Systems”. A inicios de los años 90 se hacía evidente que las metodologías tradicionales de desarrollo no representaban la propuesta más adecuada frente al entorno del momento. Los proyectos presentaban nuevamente desfases inmensos en cronogramas y presupuestos. Como consecuencia 3. Pair programm ing es la práctica de tener dos prog ramadores desarrollando en un solo computador TDD propone que los desa rrolladores debe n primero programar las pruebas del softwa re y luego e l software. 4. 19.

(20) se retomaron las prácticas experimentales de los años sesenta: iteraciones cortas, pair‐ programming, TDD, entre otras. Estas nuevas metodologías buscaban agilidad y flexibilidad en el desarrollo de software, ya que notaron que el entorno de un proyecto de software cambiaba a una velocidad cada vez mayor. En contraste con las metodologías tradicionales se propusieron el ser fáciles de entender y de aplicar. En el año 2001 se dieron cita representantes de las metodologías agiles más importantes de la época, eXtreme Programming, Scrum, DSDM, y reconocidas personalidades del mundo de la ingeniería de software (Martin Fowler, Kent Beck, Dave Thomas, Alistair Cockburn, entre otros). El propósito de esta reunión fue el de unificar los principios, conceptos e ideas comunes a dichas metodologías. El resultado de esta reunión se conoce como el Agile Manifesto, el cual es un documento bastante conocido y aceptado por ingenieros de software de la actualidad.. 3.4.4 Fundamentos y principios ágiles. Existen varias metodologías ágiles, las más reconocidas en la actualidad son Scrum, eXtreme Programming y DSDM. Todas las metodologías que se consideran ágiles comparten el mismo conjunto de principios o fundamentos. Los doce principios de la metodología ágil son (Agile Manifesto, 2001): 1. Nuestra prioridad es satisfacer las necesidades del cliente a través de entregas tempranas y continuas de software funcional. 2. Dar bienvenida a cambios en los requerimientos. La metodología ágil comprende que los cambios muchas veces conducen a ventajas competitivas de los clientes. 3. Hacer entrega de software funcional en intervalos de pocas semanas o meses. Siempre prefiriendo intervalos cortos si es posible. 4. El cliente debe designar expertos de negocio que trabajen diariamente de lado de los desarrolladores. 5. Los proyectos son construidos por individuos motivados. Se debe generar un ambiente de motivación en donde se confíe en la capacidad y responsabilidad de los individuos. 6. El método más eficiente y efectivo para transmitir información en un equipo de desarrollo es la comunicación cara a cara. 7. Software funcional es la principal medida del progreso de un proyecto. 8. Los procesos ágiles promueven un desarrollo sostenible. Los patrocinadores, desarrolladores, y usuarios deberían ser capaces de mantener un ritmo constante indefinidamente. 9. Atención a la excelencia técnica y un buen diseño promueven la agilidad. 10. Simplicidad –el arte de maximizar la cantidad de trabajo no realizado‐ es esencial. 11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos auto‐ organizados. 20.

(21) 12. Regularmente el equipo reflexiona sobre cómo ser más efectivos, luego se realizan los respectivos ajustes para obtener el comportamiento deseado.. 3.4.5 eXtreme Programming (XP). Con el fin de interiorizar un poco más los conceptos de la metodología ágil se describirá una de las metodologías ágiles más difundidas a nivel mundial eXtreme programming. En el año de 1990 nació XP con el libro eXtreme Programming Explained:Embrace Change del ingeniero de software norteamericano Kent Beck. Los seguidores de XP afirman que esta metodología funciona porque su enfoque es el desarrollo orientado al cliente, es decir XP está encaminado principalmente a desarrollar el producto que el cliente necesita cuando lo necesita (Extreme Programming, 1999). XP contempla el cambio de las necesidades del cliente inclusive en etapas avanzadas del proyecto, por esto en todo momento se busca desarrollar software con buenas características de mantenibiliad, es decir software que esté preparado para el cambio. XP propone que se debe motivar a los desarrolladores a constantemente pensar en el refactor (modificar el código o su estructura sin modificar su funcionalidad) buscando simplicidad y facilidad de entendimiento. Uno de los aspectos más destacados de XP frente a las metodologías tradicionales, es que en XP se enfatiza en la importancia del trabajo en equipo y se ve al equipo de una manera mucho más amplia. Es decir, en XP el equipo deja de ser exclusivamente el equipo de desarrollo, el equipo ahora incluye a los gerentes del proyecto y a los expertos de negocio del lado del cliente y a los usuarios finales.. Principios XP. •. 5. Simplicidad: Se debe motivar en todo momento a los desarrolladores a producir código simple, y sencillo. Se quiere que el código de un desarrollador pueda ser entendido, extendido y modificado por cualquier otro sin mayores dificultades. De esta manera se logra agilizar el desarrollo y evitar dependencias con desarrolladores particulares. La simplicidad promueve la mantenibilidad del software, lo cual constituye un interés creciente en los clientes, ya que se estima que del TCO5 del software el80% corresponde al mantenimiento. La simplicidad en el código no se logra en un primer intento, es por esto que el proceso de refactor debe ser realizado de manera periódica.. Total Cost of Ownership. 21.

(22) Las metodologías tradicionales impusieron una cantidad de trabajo tedioso y pesado de documentación sobre los desarrolladores. En XP se busca aligerar y simplificar la documentación del software, se busca principalmente que el código esté “autodocumentado” en su mayoría, evitando en lo posible el uso de formatos adicionales. La simplicidad en el código, apoya indirectamente la consecución de otro de los principios fundamentales de XP: la comunicación; ya que frecuentemente los desarrolladores deben integrar segmentos de código de diferentes personas, y cuando el código es fácil de entender esta labor de integración resulta más eficiente. •. Comunicación: La comunicación constituye un factor determinante en los proyectos de software. El producto final es intangible, el software es en esencia la materialización de “ideas” para la solución de las necesidades de los clientes, por esto la comunicación de ideas y necesidades entre programadores, clientes, gerentes y demás involucrados en un proyecto de software es fundamental (Cusumano, 2004). Para los programadores el código comunica mejor mientras más simple sea, adicionalmente, mediante la puesta en marcha de la práctica de programación en pares (explicada más adelante) la comunicación se ve altamente beneficiada. XP plantea que la comunicación entre los desarrolladores y los clientes debe ser constante, asegurando así, que lo que se construye cumple con las necesidades y expectativas de los clientes. La comunicación entre desarrolladores, como ya se mencionó, está altamente relacionada con la simplicidad del código que se elabora por parte de los mismos. El esquema de construcción iterativa, con prototipos de funcionalidad incremental, obliga a la constante integración y toma de decisiones por parte de los desarrolladores, esta interacción constante fortalece los medios de comunicación del grupo de desarrolladores (Extreme Programming, 1999).. •. Retroalimentación (feedback): La mayoría de los proyectos de software que fracasan, lo hacen porque solo hasta estados muy avanzados del proyecto se empieza a notar que la dirección que tomó el producto no era la adecuada para las necesidades del cliente. Los cambios en el software, cuando el proyecto se encuentra en estados avanzados implica un esfuerzo enorme por parte del grupo de desarrolladores, resultando casi en la totalidad de los casos en atrasos considerables en el proyecto y pérdidas económicas significativas del lado del cliente como del lado de la empresa desarrollando el software. La retroalimentación oportuna por parte de los clientes es una de las principales premisas de XP, en estos momentos suena evidente su importancia, pero en las metodologías tradicionales (desarrollo en cascada) este factor no era considerado. La retroalimentación también se aplica en la transición iterativa entre diseño y construcción, en XP idealmente se diseñan pequeños componentes de la aplicación y rápidamente se procede a su construcción, si se detectan problemas importantes en esta fase, se regresa al diseño y se elaboran los ajustes necesarios antes de continuar.. •. Coraje (Valentía): Todos los principios mencionados parecen razonables y provechosos para el desarrollo de un proyecto de software, sin embargo se requiere de coraje o valentía para aplicarlos. Lograr la simplicidad en el código mediante refactors requiere 22.

(23) valentía por parte de los desarrolladores, ya que se corre el riesgo de inyectar errores en componentes de la aplicación que ya funcionaban correctamente. La comunicación y retroalimentación necesaria en XP implica valentía por parte de todos los involucrados en el proyecto, ya que es necesario que todos los individuos expresen las necesidades y dificultades encontradas a lo largo del proyecto y estén en capacidad de exigir a las personas el cumplimiento de los principios que conforman XP.. Prácticas y herramientas XP. •. Planeación: o. o. o. Historias de usuario: esta herramienta sirve para que los desarrolladores puedan realizar una estimación del esfuerzo requerido para implementar cierta funcionalidad determinada por el cliente. Las historias de usuario son textos breves escritos por el cliente, en el cual en terminología propia de este, se describe una funcionalidad determinada del sistema a construir. En comparación con las metodologías tradicionales, las historias de usuario tienen un propósito similar al de los “casos o escenarios de uso” pero son mucho más ligeras evitando entrar en detalles. Cuando llegue el momento de implementar una funcionalidad dada, es responsabilidad de los desarrolladores leer la historia de usuario, entrevistarse con el cliente, y obtener todos los detalles necesarios para la construcción de la funcionalidad en cuestión. Planeación release6 : esta actividad hace referencia a la planeación general del proyecto (release plan), la cual consiste en la división del proyecto en iteraciones, cada una de las cuales marca hitos en la evolución del software a construir. La planeación debe ser elaborada por las personas que hacen parte del grupo técnico y por las personas que hacen parte del grupo de negocio y las opiniones de ambos grupos deben tenerse en cuenta. Lo que se propone en XP es tomar las historias de usuario, transcribirlas a pequeñas tarjetas y determinar el orden de implementación de las mismas, siempre teniendo en cuenta necesidades del cliente y restricciones de la tecnología, recursos y tiempo. En XP la planeación no es una actividad estática, por el contrario, según las necesidades y dificultades que enfrente el proyecto la metodología exige el refinamiento constante de la planeación. Medir velocidad del proyecto: Cada iteración se debe medir la velocidad del proyecto, la cual se define como la suma de los estimados de las historias de usuarios que fueron completadas durante la iteración. Esta medida sirve para monitorear la velocidad en que se está avanzando en el proyecto, lograr. 6. La palabra release en el conte xto de sistemas hace refe rencia tambié n al lanzamie nto de una nueva versión del software.. 23.

(24) o. o. o. o. planeaciones realistas para las iteraciones futuras y evitar la sobrecarga de trabajo sobre el grupo de desarrollo. Dividir el proyecto en iteraciones: El proyecto debe dividirse en iteraciones de una a tres semanas de duración. La duración de las iteraciones a lo largo del proyecto debe ser la misma, las iteraciones pueden verse como el latido del corazón del proyecto (Extreme Programming, 1999), y son las que les dan el ritmo al trabajo de las personas involucradas en el proyecto. Las iteraciones facilitan el monitoreo del proyecto, ya que al final de cada una de ellas, es necesario evaluar la completitud de los objetivos de la iteración y plantear los objetivos de la siguiente. Los plazos de terminación de las iteraciones son estrictos, la reunión de cierre de iteración tiene un día y una hora acordada, la cual no debe ser modificada. En las iteraciones se le pide a los desarrolladores concentrarse y terminar en lo posible las tareas identificadas como prioritarias, es decir, es más valioso tener estas tareas completadas al 100% que tener muchas al 80%. Planear al inicio de cada iteración: Cada iteración requiere una planeación más detallada que responda a las situaciones que se presentan a lo largo del proyecto. La secuencia de historias de usuario a implementar en cada iteración está dadas en principio por el release plan, sin embargo este debe revisarse al finalizar cada iteración para lograr cada vez más un plan de trabajo más realista frente a los problemas y particularidades del proyecto. En la planeación de la iteración es donde se traduce de historias de usuario a tareas de desarrollo, en este proceso participa todo el grupo de desarrollo, y generalmente la asignación de tareas se realiza de manera voluntaria. Las tareas deben agruparse o desglosarse según sea el caso para que la duración estimada de estas se encuentre ente uno y tres días de desarrollo. La medida de velocidad del proyecto se usa para asignar la cantidad adecuada de trabajo al grupo de desarrolladores y protegerlos de sobrecarga de trabajo que finalmente se traduce en menor motivación y calidad en las tareas asignadas. Mover a las personas: Muchos proyectos de software sufren más de lo que deberían por la salida del proyecto de una persona determinada, esto se debe a que normalmente se forman islas de conocimientos en los proyectos de software, ya que los desarrolladores suelen trabajar constantemente en una sola parte de la aplicación. La rotación de roles o responsabilidades minimiza las dependencias del proyecto en individuos, distribuye el conocimiento en todo el grupo de desarrollo, y disminuye la monotonía en el trabajo de los desarrolladores y aumentando la motivación de los mismos. Asignar tareas sobre diferentes partes de la aplicación a desarrollar y ejecutar sesiones de programación por pares minimiza la ocurrencia de islas de conocimiento. Reuniones de pie: La metodología propone la realización de reuniones informales, las cuales deben llevarse a cabo diariamente, en horas de la mañana. A estas reuniones debe asistir la totalidad del equipo del proyecto, el objetivo de estas breves reuniones es fortalecer la comunicación entre todos los participantes, 24.

(25) o. •. compartir problemas y soluciones, y mantener el foco en el equipo. En la reunión los asistentes se encuentran de pie, y se ubican a manera de círculo para generar un equilibrio en la forma en que se discuten los distintos temas. Resulta conveniente contar con un computador a la mano cuando alguna persona tiene un problema técnico el cual no ha podido resolver para que los demás asistentes opinen y encuentren soluciones al mismo. Arreglar XP: XP fue concebido para suplir las necesidades de flexibilidad del desarrollo de software, es por eso que una de sus reglas es la flexibilidad. Para iniciar un proyecto con XP se recomienda seguir todas las reglas definidas por la metodología, no obstante, una de las reglas de XP establece que se deben modificar o eliminar las reglas que no muestren ser beneficiosas para el proyecto el proyecto en particular.. Codificación: o. o o. El cliente siempre está disponible: Dentro de XP no se considera al cliente como una ayuda al equipo del proyecto, más bien se considera al cliente como un integrante fundamental del equipo del proyecto. Por esto mismo, es que el cliente siempre debe estar disponible en la mayoría de tareas de XP, en especial en la actividad de codificación. Si el cliente está realmente interesado en el éxito del proyecto debe asignar unos recursos con alta disponibilidad de tiempo y conocimiento profundo del problema que la organización quiere resolver. Los recursos asignados por el cliente para el proyecto son los encargados de evaluar los distintos prototipos que se construyen y de brindar retroalimentación oportuna al respecto a los desarrolladores. El código sigue estándares: La codificación sigue estándares que facilita el entendimiento del sistema por todos los desarrolladores. Se codifican primero las pruebas unitarias: Codificar las pruebas para una unidad de software antes de codificar la unidad representa grandes ventajas, porque obliga al desarrollador a especificar claramente el comportamiento esperado del fragmento de código a construir. Puede verse como un enfoque de caja negra, en el cual es desarrollador define algunas salidas (outputs) que el fragmento de código debería producir cuando se le introducen ciertas entradas (inputs), sin saber todavía los detalles de cómo elaborar dicho código. La principal ventaja de cumplir esta regla es que se asegura que el desarrollador obtenga una retroalimentación (feedback) casi instantánea de la validez del código desarrollado, y se crea la disciplina de probar todo el código desarrollado, lo cual es necesario para reducir drásticamente la aparición de bugs en el sistema. Adicionalmente esta sencilla regla contribuye fuertemente a la comunicación del grupo del desarrollo, ya que normalmente los desarrolladores no necesitan saber los detalles de implementación de cierta funcionalidad, lo cual puede requerir de 25.

(26) o. o. o. o. tiempo y esfuerzo considerables; lo que los desarrolladores necesitan comunicar normalmente es la forma de usar el código, lo cual es mucho más sencillo si se cuenta con las pruebas unitarias para cada fragmento de código. Programación en pares: la programación en pares o pair programming es una de las propuestas más controversiales de la metodología, ya que esta sugiere que la totalidad del código que va a producción7 debe ser elaborado por dos personas simultáneamente en un solo computador, las dos personas se turnan la codificación. La persona que no está codificando sirve de control de calidad instantáneo y mantiene la visión global necesaria para ver como “encaja” el código que su compañero está construyendo dentro del diseño general del sistema. Para la gerencia resulta contra‐intuitiva esta propuesta, ya que se está pagando por dos recursos, uno de los cuales está sentado observando lo que el otro hace, sin embargo numerosos estudios8 indican que la programación por pares aumenta la calidad global del sistema lo que se traduce en menores costos en etapas posteriores de desarrollo. Los desarrolladores, inicialmente muestran resistencia a la programación en pares (Cusumano, 2004), sin embargo una vez se logra una sincronización de las cabezas de los pares y estos experimentan las ventajas obtenidas por esta práctica, los desarrolladores se muestran cada vez más satisfechos y motivados en su trabajo (Cusumano, 2004). Solo una pareja integra código en un momento del tiempo: Solo una pareja de desarrolladores puede agregar nuevo código al repositorio general de código de la aplicación, inmediatamente debe proceder a ejecutar todas las pruebas unitarias y de integración de la aplicación. De esta manera se reducen los problemas de sincronización entre las parejas y se evita la introducción de bugs que ocurren normalmente cuando dos parejas trabajan simultáneamente sobre una misma fracción de código. Integrar frecuentemente: Se debe pedir a los desarrolladores que frecuentemente (idealmente diario) y de manera ordenada integren el código desarrollado a la aplicación global. De esta manera se evita fragmentación de la aplicación y se facilita la detección oportuna de bugs o problemas de integración que la aplicación pueda tener. Autoría del código colectiva: No existen dueños particulares para segmentos de código o partes de la aplicación en particular, todos los desarrolladores tiene la capacidad y el derecho de modificar cualquier línea de código si están seguros de estar reparando un bug o mejorando una funcionalidad determinada. Siguiendo esta regla se agiliza el proceso de desarrollo y la corrección de bugs se lleva a cabo mucho más eficiente comparada a un escenario en el cual sólo la persona que. 7. Por código de producción se e ntie nde todo aquel que va a hacer parte de la aplicación final que se e ntrega al cliente, el código correspondiente a las pruebas, por ejem plo, no se conside ra código de producción, aunque usua lmente es te tambié n es entregado a l cliente. 8 Uno de ellos “Costs and bene fits of pair programming” http://collaboration.csc.ncs u.edu/laurie/Papers/XPSardinia.PDF. 26.

(27) o. o. •. Diseño: o. o. o. o. 9. produjo las líneas de código con problemas tiene la obligación de hacer la corrección. Adicionalmente el cumplimiento de esta regla genera un compromiso mayor hacia el proyecto por parte de todos los integrantes del grupo de desarrollo. La optimización es para el final: Frecuentemente los desarrolladores consumen cantidades considerables de tiempo pensando la manera de obtener el mejor desempeño en sus algoritmos, XP propone que esta preocupación se deje para el final debido a que la prioridad es construir las funcionalidades deseadas de la manera más sencilla y rápida posible. Frecuentemente en sistemas si se desea obtener desempeños óptimos se debe llegar a soluciones complejas que requieren tiempos considerables de construcción, lo cual va en contra de la necesidad de entregar frecuentemente prototipos funcionales a los clientes. No horas extra: En algunas ocasiones trabajar horas extra para cumplir con algunos plazos de entrega es perfectamente entendible, sin embargo en la industria del software se encuentra que trabajar varias horas extra es algo bastante frecuente (Cusumano, 2004). La motivación de los desarrolladores se ve altamente afectada por esta situación, lo cual conlleva a disminuciones importantes en la calidad de su trabajo, por esto XP plantea que las horas extra solo se deben considerar en situaciones extremas.. Simplicidad: Un diseño simple se traduce en una construcción simple, lo cual agiliza el desarrollo y permite evaluar más fácilmente la calidad del producto final. Entre los diseñadores y desarrolladores de software esto se conoce como el principio KISS por sus siglas en ingles Keep it Simple & Stupid. Usar metáforas para diseñar y nombrar componentes del sistema: Este principio se puede lograr al aplicar patrones de diseño de sistemas, la mayoría de los patrones de diseño más usados poseen nombres que permiten un inferir su función9 . Esto permite una comunicación un poco mas estandarizada entre distintos desarrolladores respecto a la funcionalidad y estructura de los distintos componentes de la aplicación. Usar tarjetas CRC: Son una herramienta que facilita la labor de diseño de manera colaborativa. Las CRC permiten la participación de todos los integrantes del grupo de desarrollo en la toma de decisiones de diseño, así se logran incluir todas las buenas ideas que surjan del grupo para obtener el mejor diseño posible. Elaborar pruebas de concepto: Con el fin de minimizar el riesgo en el proyecto, cuando se tomen decisiones en tecnologías a usar, el grupo de desarrollo debe proceder inmediatamente a construir un pequeño componente o prototipo que sirva para evaluar el comportamiento de la tecnología. En la industria de software,. Algunos de es tos pa trones son: patrón fabrica, patrón comando, patrón cons tructor, patrón orques tador.. 27.

(28) o. •. aproximadamente un 20% de los proyectos que fracasan lo hacen por no conocer y manejar apropiadamente la tecnología elegida. Diseñar lo necesario: No pensar en extras que no han sido exigidos por los clientes, todo el esfuerzo de los desarrolladores debe estar enfocado a satisfaces las necesidades del cliente con la mejor calidad posible.. Pruebas: o. o. o. o. Todo el código debe tener pruebas unitarias: Para asegurar la calidad de los prototipos y de la aplicación en general, se debe contar con pruebas unitarias para todo el código. Adicionalmente, como ya se mencionó dichas pruebas deben ser diseñadas y construidas antes de elaborar el código. Pruebas unitarias para todo release: Antes de efectuar cualquier release10 a los clientes, la totalidad de las pruebas unitarias definidas para la aplicación deben ejecutarse exitosamente. Para mantener una buena dinámica en el proyecto es fundamental no perder credibilidad ante los clientes haciendo entrega de software que no ha sido probado exhaustivamente. XP establece que la participación de los clientes es esencial para el éxito de cualquier proyecto de software, y esta participación es más eficiente si se provee de prototipos de calidad a los clientes. Cuando se encuentra un bug se define una prueba: Normalmente cuando los desarrolladores encuentran un bug proceden a solucionarlo de inmediato, sin embargo si se hace esto, el conocimiento generado tras detectar el error y elaborar la corrección no se difunde entre el grupo de desarrolladores. Por esto, la forma de almacenar o distribuir el conocimiento de algún bug es definir una prueba y luego proceder a la corrección de este. Las pruebas de aceptación se efectúan frecuentemente: Las pruebas de aceptación hacen referencia al comportamiento esperado por el cliente de la aplicación, el cual está definido en las distintas historias de usuario, por esto, las pruebas de aceptación son conducidas por los clientes y son ejecutadas frecuentemente sobre los prototipos. XP enfatiza que se debe procurar conducir pruebas de aceptación frecuentemente, con el fin de proveer retroalimentación oportuna al grupo de desarrollo y contar con un proceso de corrección de errores mucho más eficiente. La ejecución frecuente de pruebas de aceptación asegura que el proyecto no pierda el rumbo y que el producto final cumpla perfectamente con las expectativas de los clientes.. 10. Hace refe rencia al lanzamiento de una nueva versión de la aplicación, o a una versión más com pleta de los prototipos de s oftware.. 28.

(29) 3.4.6 Dificultades y limitaciones para implementar ágil. La metodología ágil está orientada más a las personas que a los procesos, en ella se confía en la capacidad y responsabilidad de los individuos para lograr un producto de calidad en el tiempo estimado para el proyecto. Lo que es su mayor fortaleza puede ser al mismo tiempo su mayor debilidad, su dependencia en los individuos.. Diferentes autores del manifiesto ágil como Fowler, Cockburn y Beck entre otros han advertido claramente cuáles son las limitaciones que se pueden encontrar a la hora de implementar metodologías ágiles:. •. Un equipo ágil no se conforma de individuos “promedio”: dentro de los principios ágiles la capacidad de auto‐organización del equipo es fundamental, sin ella el proyecto nunca entregará valor al cliente. Para que la auto‐organización ocurra se necesita individuos altamente motivados, con capacidad de aprendizaje, liderazgo y pasión por el trabajo (Cockburn, I come to bury agile, not to praise it, 2009); Esto no siempre es fácil de conseguir. La metodología ágil no funcionará apropiadamente con un grupo de ingenieros “promedio”, se necesita de individuos talentosos (Synapsis Canada, 2009), la utilización de un esquema ágil con un equipo de trabajo donde la mayoría de individuos no cumplen las características mencionadas puede ser catastrófico.. •. El cliente debe entender y aceptar la metodología ágil: las organizaciones llevan alrededor de dos décadas trabajando con metodologías tradicionales, en especial RUP, la cual se acopla bien al esquema organizacional tradicional de numerosos clientes. Las metodologías ágiles resultan bastante difíciles de utilizar en proyectos con clientes cuya cultura organizacional está basada en una cadena de mando rígida en donde los procesos prevalecen sobre las personas (Synapsis Canada, 2009). Para un cliente con estas características resulta bastante difícil entender que los requerimientos del software van a cambiar inevitablemente, y que para que el proyecto sea exitoso no se debe exigir cantidades abrumadoras de documentación.. 29.

(30) •. Tamaño del equipo y del proyecto: todas las metodologías ágiles son claras en exponer que estas sólo deben ser aplicadas en equipos pequeños (máximo 10 personas). Esto se debe a que la auto‐organización en equipos más grandes puede ser bastante difícil de lograr. Por otra parte, las metodologías ágiles proponen que todos los miembros del equipo participen de actividades administrativas del equipo, esto puede resultar bastante difícil de coordinar y controlar para equipos de trabajo grandes. Al tener esta limitación en cuanto al tamaño del equipo inevitablemente se crea una restricción en cuanto al tamaño del proyecto en general.. •. Comunicación cara a cara: dentro de los principios ágiles se enuncia que la comunicación cara a cara es la más eficiente y por lo tanto debe ser la de mayor uso. Sin embargo, inclusive para equipos pequeños de trabajo esto puede ser difícil de lograr ya que implica que la totalidad del equipo debe estar la gran mayoría del tiempo en el mismo lugar físico. Para integrantes que se encuentren ubicados en un lugar diferente al resto del equipo resulta muy costoso perderse de toda la comunicación informal cara a cara que se da en el día a día del proyecto. La comunicación cara a cara no solo debe usarse entre desarrolladores, también debe usarse con expertos de negocio del lado del cliente, esto puede ser bastante difícil de lograr.. 30.

(31) 4. Evolución de las teorías de administración y del desarrollo de software Para entender los principios tras las metodologías tradicionales y modernas de software resulta enriquecedor estudiar la evolución de las teorías administrativas o de organización del trabajo. Estas surgieron con la revolución industrial, en particular con la única industria relevante de la época, la manufacturera. La teoría general de administración ha recorrido un largo camino de más de cien años. El software surgió hace unos cincuenta años, y su historia muestra un recorrido similar al de la teoría general de administración. Como se verá más adelante, en el modelo RUP se pueden encontrar principios similares a los de la teoría clásica de la administración de Fayol y Taylor (Fowler, 2005); mientras que en las metodologías ágiles se pueden ver principios de la teoría de las relaciones humanas y de la teoría sistémica de la organización.. 4.1 Teorías Clásicas de la administración. Hacia inicios del siglo XX la revolución industrial impulsó el desarrollo de las teorías para la organización del trabajo (Dale E. Yeatts, 1998). En esta época se desarrollaron las teorías clásicas de la administración como lo son la administración científica de Taylor cuyo propósito era encontrar maneras de obtener la mayor productividad en las organizaciones o “una mejor forma de hacer el trabajo” (Dávila Guevara, 2001) y la doctrina administrativa de Fayol cuyo propósito era el de la eficiencia de la organización (Dávila Guevara, 2001), teorías que basan la mayoría de sus principios en las relaciones de poder que deben existir entre los agentes o participantes de la organización o cuerpo social. Entre las principales características o fundamentos de las teorías clásicas de la administración se encuentran (Dávila Guevara, 2001): • • • • •. División clara del trabajo, resumido claramente por la propuesta de Taylor: trabajo intelectual “planear el trabajo” y el trabajo manual “hacer el trabajo”. Disciplina en los agentes de la organización. Subordinación de los intereses particulares al interés general de la organización. Remuneración de los agentes acorde a las funciones laborales asignadas. Centralización casi absoluta del poder y de la toma de decisiones en los agentes responsables de los cargos directivos.. Entre las numerosas críticas dirigidas el enfoque clásico de la administración existe una bastante recurrente en la literatura: no se tienen en cuenta los factores psicológicos del individuo que afectan su desempeño en el trabajo, o como los estadounidenses James March y Herbert Simon en 1958 lo expresan: las teorías clásicas ignoran el comportamiento de los individuos y en particular sus bases motivacionales. No es difícil notar que la mayoría de las críticas que se le hacen a la teoría clásica de la administración son las mismas hechas al modelo RUP.. 31.

Referencias

Documento similar

Se tuvo en cuenta además criterios importantes sobre la gestión de proyectos, para lograr una mejor organización del personal; las metodologías de desarrollo de software que jugaron

Durante el transcurso de esta investigación se ha abordado temas relacionados con el estado actual de las metodologías ágiles de desarrollo como han sido sus características

Diseño de una herramienta de Autor de Objetos de Aprendizaje 13 Por otra parte se encuentran las llamadas metodologías ágiles que se centran más en la obtención del sistema sin

XP: Extreme Programming (Programación Extrema), es la más destacada de los procesos ágiles de desarrollo de software. Utilizada para proyectos de corto

Se ha podido constatar mediante el estudio de las tesis ubicadas en la biblioteca de la UCI que ninguno de los modelos existente en el mundo pueden ser aplicados a la UCI, incluso los

Con el propósito de plantear una gestión de riesgos eficiente para compañías que utilizan una mezcla de métodos ágiles como: Scrum, RUP (Proceso Unificado del Software) y MSF

Con esta finalidad y luego de un estudio detallado de los modelos de desarrollo de software y estructuras organizativas existentes y basándose en las buenas prácticas de las

García-Holgado, "Introducción a la Ingeniería del Software," Recursos docentes de la asignatura Ingeniería de Software I. Grado en