Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías “livianas” una revisión crítica de las metodologías para el desarrollo.

Presentación del tema: "Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías “livianas” una revisión crítica de las metodologías para el desarrollo."— Transcripción de la presentación:

1 Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías “livianas” una revisión crítica de las metodologías para el desarrollo de software VI Taller de desarrolladores de Alejandría Enero del 2001 ver 1.0.0 Hacer Sistemas

2 Metodologías “livianas” para el desarrollo de software, una revisión crítica Fábula de cazador de dragones...Se cuenta de un joven chino que dedicó toda su vida a aprender el arte de cazar dragones, hasta que estuvo seguro que ya dominaba todas las técnicas de cómo cazar dragones. En ese momento se dio cuenta que no habían en el mundo dragones que pudieran ser cazados y el joven se dedicó a enseñar cómo cazar dragones...

3 Metodologías “livianas” para el desarrollo de software, una revisión crítica Crystal Light Methods (Alistair Cockburn) (1) En los inicios de 1990, en un estudio realizado en IBM: –los equipos exitosos enfatizaban que no habían seguido métodos formales ni herramientas CASE y que habían estimulado la comunicación y los test –los equipos con problemas no entendían sus fallas si había cumplido con los métodos formales La experiencia se repitió por toda la década, por todo el mundo y con todas las herramientas La conclusión: menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Lo primero son promesas. Lo segundo hechos.

4 Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías para el desarrollo de software (*) Las metodologías tradicionales para el desarrollo de software imponen un proceso disciplinado con el objetivo de hacer el trabajo más predecible, eficiente y planificado. Pero no se han destacado por ser exitosas, sino por ser burocráticas y “orientadas por documentos” (*) Gran parte de este resumen está basado en el trabajo “Ponga su proceso a dieta” de Martin Fowler, ThoughtWorks, Inc.

5 Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías livianas Como una reacción a las fallas de las metodologías tradicionales han surgido las metodologías livianas Estas son basadas en la adaptabilidad, más que en el carácter predictivo Son más orientadas a las personas que a los procesos Para entender mejor los fundamentos de las metodologías livianas para el desarrollo de software es conveniente revisar un poco la naturaleza de esta actividad

6 Metodologías “livianas” para el desarrollo de software, una revisión crítica Diseño y construcción en Ingeniería El diseño especifica las piezas y como ellas se relacionan. El diseño es la base del plan de construcción. El plan define tareas y dependencia entre tareas. Permite definir la agenda y el presupuesto de construcción. El diseño requiere de gente más preparada, creativa y costosa. La construcción de gente menos preparada y costosa. Un buen diseño establece una forma directa y planificada de construir la aplicación.

7 Metodologías “livianas” para el desarrollo de software, una revisión crítica UML (1) En teoría: Si podemos hacer todas las decisiones importantes de diseño en UML… podemos desarrollar un plan de construcción directo, seguro, planificado. La codificación no es más que una actividad de construcción cuando el diseño es bueno. En la práctica: Los diseños UML no suelen ser suficientes para su manipulación por programadores. Pueden verse muy buenos en papel y mostrar sus debilidades cuando hay que programarlos.

8 Metodologías “livianas” para el desarrollo de software, una revisión crítica UML (2) Los modelos que realizan los ingenieros civiles están basados en años de práctica y los factores claves son verificables matemáticamente. Los diseños UML sólo son verificables por revisión entre pares. Son útiles, pero muchos errores se descubren sólo en la codificación y prueba. Una diferencia fundamental entre la ingeniería civil y el software es que en la ingeniería civil el diseño es sólo cerca del 10% del trabajo, en el software no.

9 Metodologías “livianas” para el desarrollo de software, una revisión crítica En el desarrollo de software El diseño es la actividad predominante. La construcción es tan barata, que puede ser gratis. La construcción es básicamente el proceso de compilación y encadenamiento. Como proceso creativo, la predictibilidad no siempre es alcanzable. Si se trata de un diferente tipo de actividad, se requiere de procesos de desarrollo diferentes.

10 Metodologías “livianas” para el desarrollo de software, una revisión crítica Requerimientos (1) El un lugar común la queja de que el cambio de los requerimientos retrasa el proyecto Una alternativa: –considerar esto un problema de una pobre ingeniería de requerimientos –se deben firmar una especificación definitiva de requerimientos antes del desarrollo –se deben prohibir los cambios una vez iniciado el desarrollo Problema: –Normalmente no hay conciencia de los costos implicados en los requerimientos

11 Metodologías “livianas” para el desarrollo de software, una revisión crítica Requerimientos (2) Estimar los costos asociados a los requerimientos del software es difícil por: –El software es esencialmente una actividad de diseño –Los costos dependen fuertemente de los individuos –El software es intangible, el valor de una característica en un sistema no es fácil de evaluar –La tecnología cambia y el valor de las características de software también cambian con la tecnología

12 Metodologías “livianas” para el desarrollo de software, una revisión crítica Requerimientos (3) Los clientes esperan que el software sea modificable –Es muy difícil que fijen los requerimientos –Simplemente esperan que sea modificable, independientemente de que el desarrollo sea contratado o hecho en casa Si no se puede obtener un conjunto estable de requerimientos, no se puede obtener un plan predecible

13 Metodologías “livianas” para el desarrollo de software, una revisión crítica Predictibilidad Hay lugares donde la predictibilidad es posible –Se requiere tiempo, equipos grandes y requerimientos estables –La mayoría de las actividades de desarrollo de software no caen en esta categoría No se debe pretender seguir una metodología basada en la predictibilidad cuando este no sea el caso La predictibilidad es deseable, pero no siempre posible No predictibilidad no significa caos incontrolable, sino necesidad de una metodología con capacidad de adaptarse a los cambios.

14 Metodologías “livianas” para el desarrollo de software, una revisión crítica Control de procesos impredecibles Desarrollos iterativos: Primero: ¿dónde estamos? Producción frecuente de versiones de trabajo que tienen un subconjunto de las características requeridas –integradas y probadas como entregas finales –expresan las debilidades (fallas y falta de características), mientras que muchos documentos y el código sin prueba las oculta Los planes a largo plazo son muy flexibles, los de cada iteración son muy estables Las iteraciones deben ser cortas (de 1 semana a 1 mes) para que la realimentación sea frecuente Lo ideal es que la relación con el cliente también sea adaptable

15 Metodologías “livianas” para el desarrollo de software, una revisión crítica Ideas sobre las personas en las metodologías livianas Las personas son claves en los procesos de desarrollo de software Los programadores son profesionales responsables, no requieren de supervisión Los procesos se aceptan y acuerdan, no se imponen Desarrolladores y gerentes comparten el liderazgo del proyecto El trabajo de los desarrolladores con las personas que tienen la experiencia en el negocio es regular, no eventual.

16 Metodologías “livianas” para el desarrollo de software, una revisión crítica El proceso autoadaptable en las metodologías livianas Revisiones regulares del proceso (*) : –¿Qué hicimos bien? –¿Qué aprendimos? –¿Qué podemos hacer mejor? –¿Qué nos rompió la cabeza? Con las respuestas, se producen las ideas para la siguiente iteración (*) Norm Kerth Cada cierto tiempo se hacen revisiones retrospectivas que pueden involucrar cambios organizacionales

17 Metodologías “livianas” para el desarrollo de software, una revisión crítica Metodologías livianas para el desarrollo de software XP: Extreme Programming (Kent Back) –http://www.xprogramming.com –http://www.extremeprogramming.org –Extreme Programming Explained: Embrace Change, KentBeck, Addison Wesley, 1999 Crystal Family (Alistair Cockburn) –http://members.aol.com/humansandt/crystal/clear –http://members.aol.com/acockburn –CockBurn, Alistair. Surviving Object-Oriented Projects. Addison Wesley, 1998 Open Source –http://www.tuxedo.org/~esr/writing/cathedral-bazaar SCRUM –http://www.controlchaos.com –http://jeffsutherland.com/scrum Feature Driven Develoment (Peter Coad) –Peter Coad y Otros, Java Modeling in Color with UML. Prentice Hall, 1999 Agile Alliance –http://www.agilealliance.org

18 Metodologías “livianas” para el desarrollo de software, una revisión crítica XP: Extreme Programming (Kent Back) (1) 1El proceso de planificación 2Los pequeños “releases” 3Metáfora 4Diseño simple 5Prueba 6Refabricación La más difundida de las metodologías livianas 12 “prácticas” enfatizadas: 7Programación de pares 8Propiedad colectiva 9Integración continua 10 40-horas semana 11 Cliente en sitio 12 Estándar de codificación

19 Metodologías “livianas” para el desarrollo de software, una revisión crítica XP: Extreme Programming (Kent Back) (2) 1 El proceso de planificación Define características que se incluirán, estima costos, hace explícitas las necesidades diferidas 2 Los pequeños “releases” Un sistema simple en producción temprana, se actualiza frecuentemente en un ciclo corto 3 Metáfora Un sistema de nombres común y una descripción común 4Diseño simple Los programas deben ser lo más simples posibles 5Prueba El equipo valida el software permanentemente. Las pruebas se hacen antes, durante y después que el código se escribe. 6 Refabricación El diseño se mejora en todo el ciclo, manteniendo el software limpio, sin duplicación, simple y completo

20 Metodologías “livianas” para el desarrollo de software, una revisión crítica XP: Extreme Programming (Kent Back) (3) 7Programación de pares La programación se hace entre dos personas 8Propiedad colectiva Todo el código pertenece al grupo 9Integración continua El software se integra múltiples veces al día 10 40-horas semana Se evitan los sobretiempos excesivos y los equipos cansados 11 Cliente en sitio Acceso directo a usuarios finales (requerimientos, prioridades, respuestas a preguntas) 12 Estándar de codificación Para compartir el código la codificación debe ser similar

21 Metodologías “livianas” para el desarrollo de software, una revisión crítica XP: Extreme Programming (Kent Back) (4) Recursos de información: –KentBeck. Extreme Programming Explained: Embrace Change. Addison Wesley, 1999 –Ron Jeffrey, Ann Anderson, Chet Hendrickson. Extreme Programming Installed. Addison Wesley, 2001 –Kent Beck, Martin Fowler. Planning Extreme Programming, Addison Wesley, 2001 –http://www.xprogramming.com –http://www.extremeprogramming.org –http://www.egroups.com/group/extremeprogramming –http://www.cutter.com/ead/ead00002.html

22 Metodologías “livianas” para el desarrollo de software, una revisión crítica Crystal Light Methods (Alistair Cockburn) (1) En los inicios de 1990, en un estudio realizado en IBM: –los equipos exitosos enfatizaban que no habían seguido métodos formales ni herramientas CASE y que habían estimulado la comunicación y los test –los equipos con problemas no entendían sus fallas si habían cumplido con los métodos formales La experiencia se repitió por toda la década, por todo el mundo y con todas las herramientas La conclusión: menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan ser probadas. Lo primero son promesas. Lo segundo hechos.

23 Metodologías “livianas” para el desarrollo de software, una revisión crítica Crystal Light Methods (Alistair Cockburn) (2) Otra conclusión: Cada proyecto necesita sus propios métodos –Cuando el número de personas aumenta, también la necesidad de coordinar –Cuando el potencial de daños se incrementa, la tolerancia a variaciones se ve afectada –La sensibilidad del tiempo en que se debe estar en el mercado varía: a veces este tiempo debe acortarse al máximo y se toleran defectos, otras se enfatiza la auditoría, confiabilidad, protección legal, etc.

24 Metodologías “livianas” para el desarrollo de software, una revisión crítica Recursos de información: –CockBurn, Alistair. Surviving Object-Oriented Projects. Addison Wesley, 1998 –http://www.crystalmethodologies.org –http://members.aol.com/humansandt/crystal/clear –http://members.aol.com/acockburn –http://www.cutter.com/ead/ead00002.html Crystal Light Methods (Alistair Cockburn) (3)

25 Metodologías “livianas” para el desarrollo de software, una revisión crítica Open Source Muchos de los procesos realizados por la comunidad de código abierto son aplicables también en proyectos de código cerrado –El código fuente es compartido, pero sólo los mantenedores pueden hacer cambios –La depuración es paralela por los no mantenedores –Está pendiente la formalización de las metodologías “livianas” de esta comunidad Recursos de información: –Eric Raimond. The Cathedral and the Bazaar, http://www.tuxedo.org/~esr/writings/cathedral-bazaar –Karl Franz Fogel’s. Open Source Development with CVS. Coriolis Open Press, 1999

26 Metodologías “livianas” para el desarrollo de software, una revisión crítica SCRUM Los proyectos se dividen en iteraciones de 30 días (llamados carreras “sprints”) El equipo se reune todos los días, unos 15’, 30 max (“scrums”) La planificación es iterativa y se hace énfasis en el seguimiento de procesos Recursos de información: –No hay libros pero hay abundantes recursos Web –http://www.controlchaos.com –http://jeffsutherland.com/scrum

27 Metodologías “livianas” para el desarrollo de software, una revisión crítica Feature Driven Develoment (Peter Coad) Desarrollo dirigido por características Iteraciones cortas (2 sem.) de funcionalidad tangible Cinco procesos: –Desarrollar un modelo completo –Construir una lista de características –Realizar un plan por características –Diseñar por características –Construir por características El diseño y la construcción se hacen en cada iteración Organización: Programador jefe y propietarios de clases Recursos de información: –Peter Coad y Otros, Java Modeling in Color with UML. Prentice Hall, 1999

28 Metodologías “livianas” para el desarrollo de software, una revisión crítica Manifesto for Agile Software Development http://www.agilealliance.org Feb, 2001 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

29 Metodologías “livianas” para el desarrollo de software, una revisión crítica Manifiesto para el desarrollo ágil de software http://www.agilealliance.org Feb, 2001 Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a otros a hacerlo A través de este trabajo hemos aprendido a valorar: Los individuos y sus interacciones, sobre los procesos y las herramientas El software que trabaja, sobre la documentación exhaustiva La colaboración con los clientes, sobre la negociación de contratos La respuesta al cambio, sobre el seguimiento de un plan Esto significa que mientras valoramos los items a la derecha, valoramos más aún los de la izquierda

30 Metodologías “livianas” para el desarrollo de software, una revisión crítica Agile Software Development Recursos de información: James Highsmith. Adaptive Software Development. Dorset House, Jan 2000 http://www.agilealliance.org Jim Highsmith. http://www.adaptivesd.com IEEE Software, Vol. 17, No. 4. Jul/Aug 2000. http://www.computer.org/software/so2000/s4toc.htm Martin Fowler. Put your process on a Diet. http://www.sdmagazine.com/articles/2000/0012/0012a/0012a.htm Larry Constantine. Methodological Agility. http://www.sdmagazine.com/articles/2001/0106/0106f/0106f.htm

31 Metodologías “livianas” para el desarrollo de software, una revisión crítica ¿Cuándo aplicar estas metodologías? Procesos más simples son más fáciles cuando no se usa ningún proceso Las metodologías livianas trabajan –en equipos de menos de 50 personas –cuando no hay requerimientos estables –cuando los desarrolladores son buenos, responsables y altamente motivados –clientes se involucran en el desarrollo Las metodologías predictivas trabajan –en equipos grandes –alcance fijado por contrato

32 Metodologías “livianas” para el desarrollo de software, una revisión crítica Desarrollo de software en Alejandría Se enfatizan la mayoría de las prácticas de Extreme Programming Se estimula la comunicación, como en los Crystal Light Methods Se usan parte de los procesos y la organización de la comunidad Open Source Se estimulan los intercambios diarios, como los que se realizan en SCRUM Se diseña, se construye el software y se organiza el equipo de trabajo por características, como en Feature Driven Development Se valora a las personas, el software que trabaja, la colaboración con los clientes y la respuesta al cambio, como en la Agile Alliance Se realizan iteraciones de una semana de duración Se hacen registros diarios de actividades y semanales de características Se usa el software desarrollado semanalmente para registrar y diseminar los informes, las tareas, los planes y el conocimiento desarrollado Se coordinan semanalmente las actividades entre los distintos equipos en ambientes virtuales de teletrabajo transdisciplinario, se precisan los requerimientos Se revisa semestralmente el desarrollo de los planes de largo plazo Se realiza un taller anual para revisar la visión, misión, objetivos estratégicos, metodologías, organización, prácticas y valores.

33 Metodologías “livianas” para el desarrollo de software, una revisión crítica Mensaje final Ninguna metodología hará el trabajo por ti, porque ninguna metodología trabaja sola Muchas gracias