sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria.

davidProyectoImplantacionDiseñoMal

arbolNoMantenible

¿Qué?

Manifiesto Ágil

  • K. Beck (XP)

  • R. Jeffries (XP)

  • M. Fowler (XP)

  • W. Cunningham (XP)

  • S. Mellor (OMG)

  • D. Thomas (Pragmatic Programmer)

  • A. Hunt (Pragmatic Programmer)

  • M. Beedle

manifiestoAgil

  • R. C. Martin (Clean Code)

  • A. Cockburn (Arquitectura Hexagonal)

  • J. Sutherland (Scrum)

  • K. Schwaber (Scrum)

  • J. Highsmith (ASD)

  • J. Grenning

  • J. Kern

  • B. Marick

  • A. v. Bennekum
"En febrero de 2001, un grupo de 17 expertos en procesos […​] interesados en promover métodos y principios de IID modernos y simples se reunieron en Utah para discutir un terreno común
— Larman y Basili
A History of Iterative and Incremental Development IEEE Computer vol.36 nº6

Manifiesto Ágil

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad inherente

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

Principios

  • Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia

Métodos

Año Autor Publicación Referencia

2003

M. Poppendieck

Lean Software Development: An Agile Toolkit

Addison Wesley

A-gilismo: Sprint 0, ¿Fase Inception?; Job Stories Design Sprint; Hardening Sprint; …​ Epicas, ¿Estimación a largo plazo?; Planning Poker; T-Shirt Sizes; Bucket System; Dot Voting; …​

piramideAgil

paraguas1

paraguas2

paraguas3

  • ¿RUP es Agile?

  • RUP es un framework que debe configurarse ligero o pesado según el contexto:

  • Philip Krutchen, autor de 4+1 Vistas de RUP y cofundador de Agile Vancouver

  • Craig Larman, histórico y cronista del movimiento agile y autor de UML y Patrones

contexto

  • ¿UML es Agile?

  • No …​ Sí?!?!? pero lo usan todos los textos seminales de agilismo

Crítica

  • ¿Gestor o Scrum Master?

  • Scrum: Product Owner, Scrum Team, Scrum Master

  • XP: Cliente, Programadores y Gestor

Dark Agile darkagile

  • ¿Sprint 0 es Agile?

  • ¿Historias de Usuario vs Casos de Uso?

  • ¿Puntos de Historias de Usuario?

  • ¿Escuelas Clásica vs Londres en TDD?

  • ¿TDD está muerto?
Año Autor Publicación Movimiento Craftmanship

2009

M. Fowler

Flaccid Scrum

craftmanship

2014

D. Thomas

Agile is dead

2018

R. Jeffiers

Scrum is not an Agile Software Development Framework

2018

R. Jeffiers

Developers Should Abandon Agile

Itinerario

diagramaPruebas

  • Refactoring:

    • baby steps, Smell Codes, Catálogo de Refactorizaciones, Granularidad del Refactoring, …​

  • Historias de Usuario

    • Autor, Roles, Elementos, Historias técnicas, Características, Documentación, …​

  • eXtreme Programming

    • Roles, Actividades, Valores, Principios, Prácticas, Test-Driven Development, …​

  • Scrum

    • Product Owner, Equipo, Scrum Master, Product Backlog, Sprint Backlog, Sprint, Planificación, Realización, Burndown, Daily Meeting, "Demo", Restrospectiva, …​

Síntesis

sintesis

davidProyectoDisenyoTecnico

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada

  • Object Solutions. Managing the Object Oriented Project

    • Grady Booch

    • Addison-Wesley Professional (1789)

height32

  • Object Oriented Analysis and Design with Applications

    • Grady Booch

    • Imprint Addison-Wesley Educational s Inc (3 de junio de 2011)

height32

  • The Unified Modeling Language User Guide

    • Grady Booch

    • Pearson Education (US); Edición: 2 ed (28 de junio de 2005)

height32

  • The Mythical Man Month. Essays on Software Engineering

    • Frederick P. Brooks

    • Prentice Hall; Edición: Nachdr. 20th Anniversary (1 de enero de 1995)

height32

  • Extreme Programming Explained. Embrace Change. Embracing Change

    • Kent Beck, Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Refactoring. Improving the Design of Existing Code

    • Martin Fowler,Kent Beck,John Brant,William Opdyke,Don Roberts

    • Addison Wesley; Edición: 01 (1 de octubre de 1999)

height32

  • UML Distilled. A Brief Guide to the Standard Object Modeling Language

    • Martin Fowler,Kendall Scott

    • Addison-Wesley Educational Publishers Inc; Edición: 3 ed (15 de septiembre de 2003)

height32

  • Patrones de diseño

    • Erich Gamma et al

    • Grupo Anaya Publicaciones Generales; Edición: 1 (1 de noviembre de 2002)

height32

  • Clean Code. A Handbook of Agile Software Craftsmanship

    • Robert C. Martin

    • Prentice Hall; Edición: 01 (1 de agosto de 2008)

height32

  • Object-Oriented Software Construction

    • Bertrand Meyer

    • Prentice Hall; Edición: 2 ed (3 de abril de 1997)

height32

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM