desarrollando sistemas con metodologías y técnicas agiles
TRANSCRIPT
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
Objetivo
¿Por qué estamos aquí?
Software ¿Qué es el software?
Conocimiento de un Dominio de la Realidad expresado a través de un Modelo computable en un Medio determinado
RealidadDominio
Modelo
The “Prietus” Graph
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
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)
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
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?
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
Software ¿Cómo se adquiere el Conocimiento?
Según Nonaka & Takeuchi
(Socialización)ConocimientoConcordado
(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
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
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?
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
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?
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
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.
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.”
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
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
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
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
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!!
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] )
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
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
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”...
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
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
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
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
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
Agile Manifiesto ¿Cómo influye en aquellos que lo adoptan?
SatisfacciónLaboral
Calidad
Turn-Over
Mantenibilidad
Costo
Satisfacción del Cliente
Círculo Virtuoso del Desarrollo de Software(Diagrama de Influencia)
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...
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
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
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
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”
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”
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”
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”
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 deDesarrollo
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])
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!!!
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
eXtreme Programming Programación de a Pares (Pair Programming) - Ejemplo
Solo Pares ComentariosCantidad de Líneas de Cód. 1000 800Cantidad de Defectos 100 65 <-80 - 15Cantidad de Horas de Desa. 100 115 <-57,5*2Costo por Hora 30 30Horas por Defecto (QA) 10 10Costo por Defectos (QA) 30000 19500Horas por Defecto (Campo) 40 40Costo por Defectos (Campo) 120000 78000Costo de Desarrollo 3000 3450Costo Total con QA 33000 22950 30 % MenosCosto 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
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”
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”
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”
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”
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”
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”
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 23) ¿Se puede mejorar el código?
3.1) Sí -> Refactorizar. Ir a 23.2) No -> Ir a 1
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
Test Driven Development
Ejemplo
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”
Test Driven Development Herramientas:
Fundamental un ambiente dinámico! Framework de Test Unitarios (SUnit, JUnit, NUnit, etc) Herramientas de Refactoring (Refactoring Browser)
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
Test Driven Development
Stress
Ejecución de Tests
La espiral de la muerte “No hay tiempo para testear”
Presión
Errores
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
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?
Preguntas
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
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:
Links y Bibliografía Papers recomendados:
“No Silver Bullet – Essence and Accident” - Brooks “No Silver Buller Refired” - Brooks