Agile, Scrum & extreme Progammig

Transcripción

1 Agile,, Introduction Departamento de Computación Facultad de Cs. Exactas Fco-Qcas y Naturales Universidad Nacional de Río Cuarto {fbrusatti}(at)dc.exa.unrc.edu.ar

2 Agile,, Metodologías Agiles Son metodologías de ingeniería de software que promueven iteraciones cortas a lo largo del proceso de construcción. En cada iteración los requerimientos y soluciones evolucionan, esto le da la versatilidad (agilidad) de adaptarse a cambios rápidamente y detectar y solucionar errores eficientemente. En cada ciclo se planifica, analiza, se diseña, codifica, revisa y documenta. La idea puede ser trazada hasta 1957, en 1974 aparece un paper de Edmonds donde se introduce un proceso de desarrollo de software adaptativo, en esa década se ven diferentes enfoques de esta idea. A mediados de 90 aparecen nuevamente con fuerte auge en contraposición a los métodos pesados de la epoca. Entre los métodos más destacados se pueden encontrar a (1986), Crystal Clear (1996), extreme Programmig(1996), Feature Driven Development

3 Agile,, En febrero de 2001 se firma un documento que postula los valores y principios de estos procesos ágiles. Manifesto for Agile Software Development (agile manifesto.org) 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.

4 Agile,, Es un marco de trabajo para la gestión de un proceso. Define 3 artefactos Product Backlog Sprint Backlog Burndown Chart 3 roles Product Owner Master Team 4 ceremonias Sprint Planning Daily Spring Review Sprint Retropesctiva

5 Agile,,

6 Agile,, What is XP First Definition XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.

7 Agile,, What is XP First Definition XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de buenas prácticas que propician un aumento en la productividad a la hora de generar software.

8 Agile,, What is XP First Definition XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de buenas prácticas que propician un aumento en la productividad a la hora de generar software. XP es un estilo de construcción de software que se enfoca en la aplicación de buenas técnicas de programación, clara comunicación, y trabajo en equipo.

9 Agile,, What is XP First Definition XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. La programación extrema es una metodología de desarrollo ligera basada en una serie de valores y una docena de buenas prácticas que propician un aumento en la productividad a la hora de generar software. XP es un estilo de construcción de software que se enfoca en la aplicación de buenas técnicas de programación, clara comunicación, y trabajo en equipo.

10 Agile,, What is XP Description of XP XP is lightweight. In XP you only do what you need to do to create value for the customer. XP is a methodology based on addressing constraints in software development. It does not address project portfolio management, financial justification of projects, marketing, or sales. XP has implications in all of these areas, but does not address these practices directly. Methodology is often interpreted to mean a set of rules to follow that guarantee success. Methodologies don t work like programs. People aren t computers. XP can work with teams of any size. XP adapts to vague or rapidly changing requirements.

11 Agile,, User Stories

12 Agile,, User Stories Site Together

13 Agile,, User Stories Site Together The planning game

14 Agile,, User Stories Site Together The planning game Small releases

15 Agile,, User Stories Site Together The planning game Small releases Simple design

16 Agile,, User Stories Site Together The planning game Small releases Simple design Testing

17 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring

18 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring Pair programming

19 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring Pair programming On-site costumer

20 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring Pair programming On-site costumer Continuos Integration

21 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring Pair programming On-site costumer Continuos Integration 40-hour week

22 Agile,, User Stories Site Together The planning game Small releases Simple design Testing Refactoring Pair programming On-site costumer Continuos Integration 40-hour week Coding standards

23 Agile,, User Stories Son unidades de funcionalidades visibles para el usuario final. Son frases en el lenguaje del negocio del usuario final que captura que se necesita hacer. Captura Quién, Qué y Por qué debe implementarse una funcionalidad. Testeable Se pueden escribir pruebas automáticas para detectar la presencia de la historia (acceptance test). Progress El cliente podrá aceptar la historia como un signo de progreso hacía la meta final. Bite-sized La historia debe poder completarse en la iteación. Estimable El lado técnico del equipo deberá poder estimar el costo que la historia requerirá.

27 Agile,, Planning Game Es una reunión que ocurre una vez por iteración, típicamente una vez por semana.

28 Agile,, Planning Game Es una reunión que ocurre una vez por iteración, típicamente una vez por semana. Los clientes dividen el trabajo a ser realizado en un conjunto de historias, cada una de las cuales se escriben en tarjetas de 3x5 en unas pocas frases.

29 Agile,, Planning Game Es una reunión que ocurre una vez por iteración, típicamente una vez por semana. Los clientes dividen el trabajo a ser realizado en un conjunto de historias, cada una de las cuales se escriben en tarjetas de 3x5 en unas pocas frases. Los desarrolladores estiman cuanto esfuerzo se requiere para construir cada historia.

30 Agile,, Planning Game Es una reunión que ocurre una vez por iteración, típicamente una vez por semana. Los clientes dividen el trabajo a ser realizado en un conjunto de historias, cada una de las cuales se escriben en tarjetas de 3x5 en unas pocas frases. Los desarrolladores estiman cuanto esfuerzo se requiere para construir cada historia. Los clientes eligen que historias quieren construir en el próximo ciclo, basándose en el tiempo disponible y el estimado por los desarrolladores.

31 Agile,, Small Releases Es crítico para obtener valuable feedback en tiempo para que tenga un impacto en el desarrollo del sistema. Más tiempo se espere para introducir una importante funcionalidad al sistema menos tiempo se tendrá para saber si hay que arreglarla o no.

32 Agile,, Small Releases Es crítico para obtener valuable feedback en tiempo para que tenga un impacto en el desarrollo del sistema. Más tiempo se espere para introducir una importante funcionalidad al sistema menos tiempo se tendrá para saber si hay que arreglarla o no. El equipo de desarrollo debe hacer un release del sistema lo más frecuente que se pueda. Algunos equipos hacen un deploy cada día, otros cada semana o cada dos semanas.

33 Agile,, Small Releases Es crítico para obtener valuable feedback en tiempo para que tenga un impacto en el desarrollo del sistema. Más tiempo se espere para introducir una importante funcionalidad al sistema menos tiempo se tendrá para saber si hay que arreglarla o no. El equipo de desarrollo debe hacer un release del sistema lo más frecuente que se pueda. Algunos equipos hacen un deploy cada día, otros cada semana o cada dos semanas. Al final de cada iteración se tendrá software probado, funcionando y en producción para los clientes.

34 Agile,, First Testing Escribir un test que falle primero antes de cambiar cualquier códio. Esto soluciona varios problemas al mismo tiempo: Trust It s hard to trust the author of code that doesn t work. By writing clean code that works and demonstrating your intentions with automated tests, you give your teammates a reason to trust you.

35 Agile,, Continuos Integration Los desarrolladores deben integrar y agregar códio en el repositorio cada vez que sea posible (algunas horas). No se puede mantener el códio por mucho tiempo sin integrar. Cada integración es verificada por un build automático (que incluyen tests) para detectar errores lo más rápido posible. CI evita divergir del desarrollo del proyecto y permite desarrollar código cohesivo más rápidamente.

36 Agile,, Web site: Agile manifesto Web site: Extreme Programming Explained: Embrace Change (Second Edition) By Kent Beck, Cynthia Andres