Metodologas livianas una revisin crtica de las metodologas para el desarrollo de software

1
Metodologías livianas una revisión crítica de
las metodologías para el desarrollo de software
Hacer Sistemas

• VI Taller de desarrolladores de Alejandría
• Enero del 2001
• ver 1.0.0

2
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
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 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

• 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
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
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
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
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
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
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
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
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
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
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
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

• 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-bazaa
  r
• 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
XP Extreme Programming (Kent Back) (1)

• La más difundida de las metodologías livianas
• 12 prácticas enfatizadas

• 1 El proceso de planificación
• 2 Los pequeños releases
• 3 Metáfora
• 4 Diseño simple
• 5 Prueba
• 6 Refabricación

7 Programación de pares 8 Propiedad colectiva
9 Integración continua 10 40-horas semana 11
Cliente en sitio 12 Estándar de codificación
19
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
• 4 Diseño simple
• Los programas deben ser lo más simples posibles
• 5 Prueba
• 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
XP Extreme Programming (Kent Back) (3)

• 7 Programación de pares
• La programación se hace entre dos personas
• 8 Propiedad colectiva
• Todo el código pertenece al grupo
• 9 Integració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
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
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
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
Crystal Light Methods (Alistair Cockburn) (3)

• 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

25
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-baza
  ar
• Karl Franz Fogels. Open Source Development with
  CVS. Coriolis Open Press, 1999

26
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
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
Manifesto for Agile Software Developmenthttp//ww
w.agilealliance.orgFeb, 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
Manifiesto para el desarrollo ágil de
softwarehttp//www.agilealliance.orgFeb, 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 herramientasEl 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
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/s4to
  c.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
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
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
Mensaje final

• Ninguna metodología hará el trabajo por ti,
  porque ninguna metodología trabaja sola

Muchas gracias