Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Desarrollando sistemas con metodologías y técnicas agiles

439 vues

Publié le

Presentación sobre Metodologías y técnicas ágiles

Publié dans : Logiciels
  • Soyez le premier à commenter

Desarrollando sistemas con metodologías y técnicas agiles

  1. 1. Desarrollando Sistemas con Metodologías y Técnicas Ágiles Lic. Hernán Wilkinson h.wilkinson@mercapsoftware.com
  2. 2. Agenda  Primera Parte  Objetivo  Software e Ingeniería de Software en retrospectiva (… o cómo explicar qué está sucediendo …)  Agile Manifiesto  Segunda Parte  eXtreme Programming  Tercera Parte  Test Driven Development (Ejemplo Práctico)  Conclusiones/Preguntas  Links y Bibliografía
  3. 3. Objetivo ¿Por qué estamos aquí?
  4. 4. Software  ¿Qué es el software?  Conocimiento de un Dominio de la Realidad expresado a través de un Modelo computable en un Medio determinado Realidad Domi nio Modelo The “Prietus” Graph
  5. 5. Software  ¿Qué es, para qué sirve un Modelo?  Sirve para simular o visualizar “lo que” representa  ¿Qué es el Conocimiento?  Concepción Clásica  Definición: Creencia justificada de la verdad (justified true belief)  Definición errónea según lo demuestra Gettier [GETTIER 1963]  El cerebro procesa símbolos independientemente del significado
  6. 6. Software  ¿Qué es el Conocimiento?  Según Polanyi [POL 1966]  Conocimiento Explícito:  Formal y sistemático  Ejemplo: Documentos, fórmulas, etc.  Conocimiento Tácito (Implícito):  Altamente personal y difícil de formalizar  Ligado a la experiencia, valores y emociones  “Sabemos más de lo que podemos decir”  Dimensión Técnica (artesanías, skills) y Dimensión Cognitiva (modelos mentales)
  7. 7. Software  ¿Qué es el Conocimiento?  Visión Japonesa (Nonaka & Takeuchi [NON 1995])  Proceso humano dinámico de justificación personal de la creencia dirigido hacia la “verdad”  Unicidad de humanidad y la naturaleza, cuerpo y mente, uno y el otro  Contradice a Descartes  Se puede ver hasta en el idioma
  8. 8. Software  ¿Por qué el software es conocimiento?  Ejemplos:  Empresas donde los sectores de Sistemas “saben” más de la empresa y el negocio que el resto  Cuando se va una persona de sistemas se pierde información, no es fácil reemplazarla  ¿Por qué cuesta arreglar un sistema después de mucho tiempo? ¿Será por qué nos olvidamos lo que sabíamos?
  9. 9. Software  ¿Cómo se adquiere el Conocimiento?  Racionalmente (Platón)  Por medio de la Deducción  Ejemplo: Matemática  Empíricamente (Aristóteles)  Por medio de la Inducción  Ejemplo: Física  División Cartesiana (Descartes) [DES 1637]  La mente separada del cuerpo  Implica la búsqueda del conocimiento aislando a uno del resto del mundo y las personas
  10. 10. Software  ¿Cómo se adquiere el Conocimiento?  Según Nonaka & Takeuchi (Socialización) Conocimiento Concordado (Externalización) Conocimiento Conceptual (Internalización) Conocimiento Operacional (Combinación) Conocimiento Sistemático Conocimiento Tácito A Conocimiento Explicito Conoci- miento Tácito Desde Conoci- miento Explicito
  11. 11. Software  ¿Cómo se adquiere el Conocimiento?  Según Nonaka & Takeuchi Socialización Externalización Internalización Combinación Dialogo Encadenamiento de Conoc. Explícito Aprender haciendo Haciendo en el Campo de Acción
  12. 12. Software  Por lo tanto desarrollar Software implica (entre otras cosas)  Determinar cómo obtenemos el conocimiento para desarrollar Software:  ¿Lo obtenemos racionalmente? ¿Es posible?  ¿Lo obtenemos empíricamente?  ¿Podemos abstraernos completamente de la realidad que estamos modelando?  ¿Debemos separar el sujeto del objeto?  ¿Se puede especificar cómo obtener ese conocimiento?
  13. 13. Software  Por lo tanto desarrollar Software implica (entre otras cosas)  Determinar en qué medio y cómo lo hacemos explícito:  ¿Documentos? ¿Diagramas?  Los documentos que piden las metodologías actuales, ¿reflejan “conocimiento” o mera información?  ¿Programas? ¿Qué pasaría si todos pudieran entender los programas?  Algo está claro, debe ser en un medio dinámico
  14. 14. Software  Por lo tanto desarrollar Software implica (entre otras cosas)  Qué herramientas usamos para hacerlo explícito  ¿Es importante la herramienta que usamos para hacerlo explícito?  ¿Cómo influye en nuestro modelo y proceso de adquisición de conocimiento?  ¿Qué similitudes debe tener con nuestra manera de organizar y adquirir conocimiento?
  15. 15. Software  Características Esenciales del Software ([BROOKS])  Complejidad  El software es inherentemente complejo por la gran cantidad de elementos que lo componen  Conformidad  Debe conformar hasta con pedidos caprichosos  Cambio  Cambia la realidad, cambia el medio (computadora, lenguaje de programación)… (cambia todo cambia…)  Invisibilidad  No se “ve” cómo interactúan sus partes para realizar una tarea
  16. 16. Ingeniería de Software  ¿Qué es la Ingeniería de Software?  Según E. Dijkstra  “La profesión condenada”  “Cómo programar cuando no se sabe cómo”  Según el SEI (una de las miles definiciones)  La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software.
  17. 17. Ingeniería de Software  ¿Cuándo surge la idea de Ingeniería?  1968, Garmisch, Alemania: Conferencia de la NATO  “La palabra ‘ingeniería’ se eligió de forma deliberada por ser provocativa, implicando la necesidad de fabricar software en base al tipo de fundamento teórico y disciplinas prácticas que son tradicionales en las ramas establecidas de la ingeniería.”
  18. 18. Ingeniería de Software  Históricamente influenciada por una visión racionalista  ¿Cuál es su objetivo?  Mejorar el desarrollo de Software  ¿Cómo medimos que algo es mejor?  Menor costo (pragmatismo norteamericano)  Mayor calidad  Producido en el tiempo esperado
  19. 19. Ingeniería de Software  ¿Cómo supone lograr estos objetivos?  Aplicando métodos racionales y bien especificados  Ejemplo: Back Propagation  Generando procesos donde los “procesadores” somos nosotros  Creando herramientas y técnicas sin importar si atacan el problema correctamente  Dejando de lado lo emocional, el aprendizaje empírico  Ignorando el conocimiento tácito
  20. 20. Ingeniería de Software  Por lo tanto …  Hay grupos que se concentran en los procesos (SEI)  Hay grupos que se concentran en las herramientas (Microsoft, Sun, etc.)  Algunas muy malas por cierto  Hay grupos que se concentran en las técnicas (Rational, etc)  Algunas muy complicadas por cierto
  21. 21. Ingeniería de Software  Consecuencias:  Las personas son intercambiables, lo que importa es el proceso (somos procesadores, no sentimos)  El producto a construir puede ser completamente especificado (aprendo por deducción)  La tecnología pasa a ocupar un lugar preponderante y produce mayor interés que el conocimiento  Es más importante Java o .Net que entender objetos  No se entiende al desarrollo de software como adquisición de conocimiento  El conocimiento ya está, solo hay que escribirlo
  22. 22. Ingeniería de Software  Cabe preguntarnos:  ¿Se agotó la visión racionalista de la Ingeniería de Software? ¿Es un “paradigma” agotado?  ¿Se pueden explicar las disciplinas ágiles desde este punto de vista?  ¿Está bien hablar de Ingeniería?  ¿Valen las comparaciones con otras ingenierías?  Arquitectura: Un arquitecto o albañil no aprende qué es una casa mientras la construye!!
  23. 23. Ingeniería de Software  Surgen movimientos “humanistas”.  Estos movimientos se concentran en:  La gente!  El aprendizaje  La Externalización del conocimiento tácito  Según DeMarco/Constantine y otros:  “Peopleware is the real issue. We are the problem and we are the solution. How convenient”. ([CONST 1995] )
  24. 24. Qué es la Ing. de Software  ¿Por qué concentrarse en la gente?  Es una Actividad Mental  Realizada de Manera Grupal  Resultado de una cultura de trabajo  Cultura: “Cómo se hacen las cosas por acá” ([WIEGERS 1996])  ¿Por qué en la Externalización?  Porque debemos aprender de los expertos para hacer un buen modelo
  25. 25. Qué es la Ing. de Software  Quieren hacer del desarrollo de Software una disciplina donde:  La función del gerente sea ayudar a que la gente trabaje y no hacer que la gente trabaje  El gerente no piense que:  “Presionando es la única manera de obtener resultados”  “Los desarrolladores son recursos descartables...”  “...hasta un mono puede programar...”  Los participantes estén motivados  Se disfrute el trabajo
  26. 26. Qué es la Ing. de Software  ¿Cuál es el objetivo de las disciplinas “ágiles”?  Definir una nueva CULTURA de Desarrollo de Software  ¿Qué implica la palabra NUEVA?  No hay que ser escéptico  No criticarla sin probarla...  Hay que tener un poco de FE  Surge el “Agile Manifiesto”...
  27. 27. Agile Manifiesto  ¿Cómo/Cuándo surge?  En Febrero de 2001, se juntaron individuos de las metodologías denominadas “livianas” (XP, Scrum, etc) hasta ese momento  Objetivo: Definir los principios básicos para producir software de una mejor manera, para delinear una nueva cultura de desarrollo de software  Integrantes: Kent Beck, Ward Cunningham, Martin Fowler, Robert Martin entre otros
  28. 28. Agile Manifiesto  Individuos e Interacciones sobre Procesos y Herramientas  Software funcionando sobre Documentación Integral  Colaboración con el Cliente sobre Negociación de Contratos  Respuestas al Cambio sobre Seguimiento de un Plan
  29. 29. Agile Manifiesto  Porque la idea clásica del conocimiento está agotada es que se valoriza  Individuos e Interacciones sobre Procesos y Herramientas  Externalización del conocimiento  No a la Dualidad Cartesiana!  Software funcionando sobre Documentación Integral  No a la mera información (documentos)  Sí a los modelos del dominio de problema
  30. 30. Agile Manifiesto  Porque se entiende al desarrollo de software como un proceso de aprendizaje se valoriza  Colaboración con el Cliente sobre Negociación de Contratos  Respuestas al Cambio sobre Seguimiento de un Plan  Asumir el flujo normal de aprendizaje  No un plan estipulado solo por recursos o necesidades
  31. 31. Agile Manifiesto  Adoptan:  Modelado de software, pero no para llenar un lindo diagrama y pegarlo en la pared  Documentación, pero no para tener miles de páginas que nadie lee y están desactualizadas  Planificación, no como fin en si mismo sino como un medio para anticipar “el futuro” (teniendo en cuenta los límites que implica en ambientes cambiantes) y permitir el aprendizaje
  32. 32. Agile Manifiesto  ¿Cómo influye en aquellos que lo adoptan? Satisfacción Laboral Calidad Turn-Over Mantenibilidad Costo Satisfacción del Cliente Círculo Virtuoso del Desarrollo de Software (Diagrama de Influencia)
  33. 33. Agile Manifiesto  Disciplinas que entran en la definición de Ágiles:  eXtreme Programming (XP)  SCRUM  Feature Driven Development  Pragmatic Programmer  Vamos a ver un poco qué es XP...
  34. 34. eXtreme Programming  ¿Qué es XP?  Es una disciplina de desarrollo de software basada en los valores de Simplicidad, Comunicación, Retroalimentación (feedback) y Coraje  Funciona juntando a todo el equipo de trabajo en la presencia de prácticas simples, con suficiente feedback para que el equipo pueda ver dónde “están parados” y pueda ajustar las prácticas a cada situación particular  Compuesto por 13 prácticas  Una sola es novedosa, las otras son prácticas ya existentes y probadas  Todas juntas son más fuertes que cada una por separado
  35. 35. eXtreme Programming  ¿Cómo surge?  Creada por Kent Beck (Smalltalker, totalmente práctico, patterns, XP, TDD)  Probada por primera vez en Chrysler Corp. (Proyecto C3)  Practicada en varios proyectos con muy buenos resultados  ¿Por qué es exitosa?  Ataca problemas esenciales del desarrollo de Software  Porque se propone hacer de la Ing. de Software una disciplina “disfrutable” y no aburrida  Porque valora el aprendizaje y el conocimiento tácito
  36. 36. eXtreme Programming  Equipo Completo (Whole Team)  Todos se sientan juntos: Programadores, analistas, usuarios, testers  Por ejemplo:  Los analistas ayudan al usuario a definir mejor sus requerimientos  Los testers a crear los casos de prueba del sistema con el usuario  Los programadores entienden mejor las necesidades del usuario  Los programadores pueden ver los errores rápidamente  Todos contribuyen, no hay especialistas  Facilita el creación y adquisición de conocimiento  Se genera un empatía muy fuerte en el grupo
  37. 37. eXtreme Programming  Juego de la Planificación (Planning Game)  Se definen los próximos pequeños pasos a realizar en base al negocio y las necesidades del cliente  Se basa en construir “de a poco” para no equivocarse mucho  La evolución es visible por lo tanto hay menos presión y stress  Ataca el problema esencial de la “visibilidad”
  38. 38. eXtreme Programming  Tests del Cliente (Customer Tests)  El Cliente (que forma parte del equipo) define los tests de aceptación, los cuales deben ser automatizados  Los test deben ser automatizados, por que si no se dejan de correr  Estos tests son acumulativos, significa que el sistema siempre mejora, nunca retrocede  Ataca el problema esencial de la “conformidad”
  39. 39. eXtreme Programming  Entregas pequeñas (Small Releases)  Cada pequeño avance se entrega al cliente para que lo pruebe (visibilidad)  También se entrega al usuario final los pequeños avances  Si se avanza de a poco, es más fácil retroceder  Permite asegurar al usuario que está yendo por el camino correcto  Ataca el problema esencial de la “visibilidad”
  40. 40. eXtreme Programming  Metáfora (Metaphor)  Es la visión unificada del sistema  Es como una descripción “poética” del sistema  “Permite expresar lo que uno sabe o quiere pero no puede decir aún” ([Non 1995])  Honda City: “Let’s gamble”, “Man-maximum, machine-minimum”, “Tall boy”  “¡El sistema buchón!”  Ataca el problema esencial de la “simplicidad” y “visibilidad”
  41. 41. eXtreme Programming  Ritmo llevadero (Sustainable Pace)  Semanas de 40 horas  Trabajar duro cuando es necesario, no siempre!  “Death march” project no son productivos y no producen software de calidad Fatiga Juicio Errores Tiempo de Desarrollo
  42. 42. eXtreme Programming  Ritmo llevadero (Sustainable Pace) “You may be able to kick people to make them active, but not to make them creative, inventive and thoughtful” T. DeMarco/T. Lister ([DEMARCO]) “People under time pressure don’t work better, they just work faster...” T. DeMarco/T. Lister ([DEMARCO])
  43. 43. eXtreme Programming  Programación de a Pares (Pair Programming)  Los errores se encuentran antes debido a una continua revisión de código (uno escribe, el otro verifica simultáneamente)  Se generan menos defectos  El código tiene menos líneas -> el diseño es más simple  Los problemas se resuelven más rápido (dos cabezas piensan mejor que una...)  Se aprende más y mejor  Hay más gente involucrada en cada pieza del sistema (reduce el riesgo de turn-over)  Mayor comunicación!!!
  44. 44. eXtreme Programming  Programación de a Pares (Pair Programming)  Es más difícil “tirar la chancleta”, alguien te está observando...  Lleva unas semanas acostumbrarse, no hay que desmoralizarse  Estadísticas:  El 90% de la gente disfruta más programando de a pares  La cantidad horas-hombre es un 15% mayor en los peores casos  Si una persona tarda 100 horas, dos personas tardan 57,5 horas  Pero produce un 15% menos de defectos  Se genera entre un 20% y un 25% menos de líneas de código
  45. 45. eXtreme Programming  Programación de a Pares (Pair Programming) - Ejemplo Solo Pares Comentarios Cantidad de Líneas de Cód. 1000 800 Cantidad de Defectos 100 65 <-80 - 15 Cantidad de Horas de Desa. 100 115 <-57,5*2 Costo por Hora 30 30 Horas por Defecto (QA) 10 10 Costo por Defectos (QA) 30000 19500 Horas por Defecto (Campo) 40 40 Costo por Defectos (Campo) 120000 78000 Costo de Desarrollo 3000 3450 Costo Total con QA 33000 22950 30 % Menos Costo Total sin QA 123000 81450 35 % Menos  Sin diferencia en Costo Total con QA -> 67 defectos  Sin diferencia en Costo Total sin QA -> 65 defectos
  46. 46. eXtreme Programming  Integración Continua (Continuous Integration)  Integración diaria o de varias veces al día!  El objetivo es evitar el “infierno de integrar”  La idea es utilizar el código integrado rápidamente y así proveer otro punto de testing  Ataca los problemas de la “visibilidad” y “cambio”
  47. 47. eXtreme Programming  Todos son dueños del Código (Collective Code Ownership)  Todos pueden modificar cualquier parte del código  El objetivo es la mejora continua y aprendizaje del código  Esto mejora el diseño y la simplicidad  Se basa en un buen conjunto de tests y en programación de a pares  Conocimiento tácito  Ataca los problemas del “cambio” y “complejidad”
  48. 48. eXtreme Programming  Estándares de Código (Coding Standard)  Todos programan usando el mismo estándar  Que todo el código luzca similar hace que sea más fácil entenderlo y modificar cualquier parte del mismo  Ataca el problema del “cambio”
  49. 49. eXtreme Programming  Diseño Simple (Simple Design)  Se diseña para lo que se necesita, no más...  El reuso se obtiene sin invertir tiempo en él (no hay design- paralysis)  No se realiza una sola vez (up-front design) sino todo el tiempo  Es esencial para facilitar la mantenibilidad y el entendimiento del sistema  Se utilizan las herramientas más rápidas: Papel y lápiz  No hay que olvidarse que estamos aprendiendo!!  Ataca el problema del “cambio” y la “complejidad”
  50. 50. eXtreme Programming  Mejora del Diseño (Design Improvement)  Se debe mejorar el diseño constantemente:  Las cosas se deben decir una sola vez  El código debe ser “lindo” (una obra de arte!)  Se utilizan herramientas de Refactoring para este fin  Se focaliza en sacar duplicados, hacer el código más legible  Debe ser soportado por un test completo para estar seguro de no “romper nada” (Customer Tests y Unit Tests)  Buscar cohesión, minimizar acoplamiento!  La dependencia es el mayor problema del software  Duplicación es un síntoma de la dependencia  Ataca el problema del “cambio” y “complejidad”
  51. 51. eXtreme Programming  Desarrollo Dirigido por el Test (TDD)  Se empieza por los tests, no por un diseño o por el código!  Los tests especifican la semántica de mi sistema!  Los tests permiten ver los casos particulares para luego generalizar  El programador se apoya en los tests, no tiene que imaginarse el impacto del cambio, los ve!  Los tests generan mayor Seguridad, por lo tanto disminuye el miedo a realizar cambios!  Ataca los problemas de “conformidad”, “complejidad” y “cambio”
  52. 52. Test Driven Development  ¿Cómo funciona? 1) Rápidamente escribir un test 2) Correr todos los tests. ¿Hay errores? 2.1) Sí -> Arreglarlos. Ir a 2 3) ¿Se puede mejorar el código? 3.1) Sí -> Refactorizar. Ir a 2 3.2) No -> Ir a 1
  53. 53. Test Driven Development  En otras palabras...  Escribir un test (una historia, un caso de uso)  Escribir el código para que corra  Escribir el código correctamente  Nunca escribir código del modelo sin que antes falle un test
  54. 54. Test Driven Development Ejemplo
  55. 55. Test Driven Development  Principios:  “Clean code that works”: Primero que funcione, después que sea lindo  Paradoja: “Por no pensar en el futuro del código, uno hace que el código sea más adaptable en el futuro”  Lo opuesto a “Code for today, Design for tomorrow”->”Code for tomorrow, Design for today”  El código nos habla! Lo leemos mil veces, lo escribimos una  El test es un medio para lograr un fin, el fin es tener código confiable y “lindo”
  56. 56. Test Driven Development  Herramientas:  Fundamental un ambiente dinámico!  Framework de Test Unitarios (SUnit, JUnit, NUnit, etc)  Herramientas de Refactoring (Refactoring Browser)
  57. 57. Test Driven Development  Estadísticas  Misma cantidad de líneas de código que las del sistema  Correr todos los tests no debe llevar mucho tiempo, si no uno los deja de correr  Mal uso:  Mucho código de preparación de test (setup)  Duplicación de código de preparación  Tests que tardan mucho  Tests frágiles
  58. 58. Test Driven Development Stress Ejecución de Tests  La espiral de la muerte “No hay tiempo para testear” Presión Errores
  59. 59. Conclusiones  Casos concretos:  Proyecto en Mercap  Chrysler C3  LifeWare (www.lifeware.ch)  4 años, 40 personas/año  250.000 líneas de código Smalltalk del modelo  250.000 líneas de código de test  4.000 tests  20 minutos en correr todos los tests
  60. 60. Conclusiones  ¿Cómo aplicarlas?  Coraje!  Paciencia  Constancia  Empezar por algunas prácticas  Recomiendo empezar con TDD  Vencer la burocracia  Hay que romper paradigmas y culturas de trabajo...  ¿Es posible aplicarlas?  ¿En grandes organizaciones (Bancos, etc.)?  ¿En organizaciones públicas?
  61. 61. Preguntas
  62. 62. Links y Bibliografía  Agile Manifiesto  http://agilealliance.org/home  XP  Extreme programming Explained - Kent Beck  http://www.xprogramming.com  Pair Programming  http://www.pairprogramming.com/  http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF  TDD  Test Driven Development, By Example - Kent Beck
  63. 63. Links y Bibliografía [GETTIER 1963] Is Justified True Beleif Knowledge? [DES 1637] Discurso del Método [BROOKS 1975] The Mythical Man-Month [NON 1995] The Knowledge-Creating Company [CONST 1995] Constantine on Peopleware [WIEGERS 1996] Creating a Software Engineering Culture [DEMARCO] Peopleware: Productive projects and teams [POL 1966] The Tacit Dimension  Bibliografía:
  64. 64. Links y Bibliografía  Papers recomendados:  “No Silver Bullet – Essence and Accident” - Brooks  “No Silver Buller Refired” - Brooks

×