• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Desarrollo ágil de aplicaciones
 

Desarrollo ágil de aplicaciones

on

  • 1,011 views

Paradigma de construcción d

Paradigma de construcción d

Statistics

Views

Total Views
1,011
Views on SlideShare
1,009
Embed Views
2

Actions

Likes
1
Downloads
47
Comments
0

1 Embed 2

http://mania.net.pl 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Desarrollo ágil de aplicaciones Desarrollo ágil de aplicaciones Presentation Transcript

    • Curso Ambientes de Desarrollo Énfasis II en Ingeniería de Sistemas Telemáticos programa de Ingeniería Electrónica y Telecomunicaciones
    • Paradigma de construcción de soluciones basa en la construcción de códigoDesarrollo Ágil de Aplicaciones
    • ¿Qué es el desarrollo ágil de aplicaciones?•Es una iniciativa que agrupa una serie de metodologías(eXtreme Programming, SCRUM, Crystal, etc. ...)• Basadas en la adaptabilidad ante el cambio comomedio para aumentar las posibilidades de éxito de unproyecto.•En general los procesos ágiles se centran en laspersonas; en su comunicación directa y sus habilidadesen vez de procesos muy formales.
    • El Manifiesto ÁgilIndividuos e interacciones sobre Procesos y herramientasSoftware que funciona sobre Documentación exhaustivaColaboración con el cliente sobre Negociación de contratosResponder ante el cambio sobre Seguimiento de un plan Firmado en 2001 por Kent Beck, Alistair Cockburn, Ward Cunningham, Martin Fowler, Robert Martin, Ron Jeffries, otros…
    • XP: eXtreme Programming“La Programación Extrema (desarrollapor Kent Beck - DaimerChrysler) es unametodología de desarrollo de aplicacionesque se basa en la simplicidad, lacomunicación y la realimentación oreutilización del código desarrollado”.
    • Lo que dice Beck...“Todo en el software cambia. Los requisitoscambian. El diseño cambia. El negociocambia. La tecnología cambia. El equipocambia. Los miembros del equipo cambian.El problema no es el cambio en sí mismo,puesto que sabemos que el cambio va asuceder; el problema es la incapacidad deadaptarnos a dicho cambio cuando éste tienelugar.”
    • Las cuatro variables• XP hace de sus cuatro variables, elementosvisibles tanto a clientes, programadores yjefes de proyectos.• Se busca jugar con sus valores hasta que elalcance del proyecto tenga ] Costoun valor que satisfaga a todos. ] Tiempo ] Calidad ] Alcance
    • Los cinco valores• Los cinco valores de XP son esenciales paraque sus practicas tengan sentido y puedan serllevadas a cabo con éxito.• Deben ser parte integral de lafilosofía de un profesional ] Comunicacióndel desarrollo ágil. ] Coraje ] Simplicidad ] Realimentación ] Respeto
    • Roles principales en XPProgramador Director• Responsable de decisiones • Organiza y guía las técnicas reuniones• Responsable de construir el • Asegura condiciones adecuadas para el proyecto sistema• Sin distinción entre analistas, Cliente diseñadores o codificadores • Es parte del equipo • Determina qué construir y• En XP, los programadores cuándo diseñan, programan y realizan • Establece las pruebas las pruebas funcionales
    • Roles secundarios en XP Preparador - Coach • Responsable del procesoProbador - Tester • Tiende a estar en un• Ayuda al cliente con las segundo plano a medida pruebas funcionales que el equipo madura• Se asegura de que las pruebas funcionales se superan Controlador - Tracker • Métricas • Observa sin molestar • Conserva datos históricos
    • Proceso de Desarrollo
    • Proceso de Desarrollo
    • Captura de RequisitosHistorias de Usuarios: • Establecen los requisitos del cliente • Trozos de funcionalidad que aportan valor • Se les asignan tareas de programación con un número de horas de desarrollo • Las establece el cliente • Son la base para las pruebas funcionales
    • Ejemplo de historia de usuario
    • Planificación Planificación por entregas (releases) Se priorizan aquellas historias de usuario que el cliente selecciona porque son más importantes para el negocio Entregas: • Lo más pequeñas posibles • Se dividen en iteraciones de 2 o 3 semanas • Están compuestas por historias de usuario A cada programador se le asigna una tarea de la historia de usuario
    • Diseño Diseño simple La programación de tareas se realiza por parejas La pareja diseña, prueba, implementa e integra el código de la tarea Código dirigido por las pruebas Código modular, intentando refactorizar siempre que se pueda
    • Desarrollo Cliente siempre disponible Implementación Pruebas de Unidad Integración Implantación Pruebas de Aceptación
    • Principios básicosRetroalimentación a escala fina:• El principio de pruebas• Proceso de planificación• Cliente en el sitio• Programación por parejas
    • Principios básicosProceso continuo en lugar de por lotes:• Integración continua• Refactorización• Entregas pequeñas
    • Principios básicosEntendimiento compartido:• Diseño simple• Metáfora• Propiedad colectiva del código• Estándares de codificación
    • Principios básicosBienestar del programador:• La semana de 40 horas• Dedicación exclusiva
    • Mejores prácticas
    • Proceso de Desarrollo
    • Proceso de Desarrollo
    • Proceso de Desarrollo
    • Proceso de Desarrollo
    • Lectura para la casa
    • SCRUM• Es una metodología ágil de desarrollo de software. que permite centrarse en ofrecer el más alto valor de negocio en el menor tiempo.• Ken Schwaber y Jeff Sutherland fueron los precursores de este método demostrando ampliamente su uso en proyectos de gran envergadura con un alto número de personal• El negocio fija las prioridades y los equipos se auto- organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad.
    • Características• Desarrollo de software por medio de iteraciones “Sprints" de 2 semanas a un 1 de duración• Los requisitos son capturados como elementos de una lista de “Product Backlog”• No hay prácticas de ingeniería prescritas• Indicado para proyectos con un rápido cambio de requerimientos.• Gran protagonismo de reuniones a lo largo del proyecto.• Colaboración estrecha con el cliente.
    • Sprints• “Sprints”- Periodo de tiempo (2-4 semanas) donde se llevan a cabo una serie de tareas previamente establecidas. ( Análogo a las iteraciones en XP)• No hay cambios en un sprint• El producto es diseñado, codificado y testeado durante el Sprint• Al iniciar cada Sprints, el equipo revisa el trabajo pendiente y selecciona la parte que terminará como un incremento de funcionalidad incorporado al software.• Al final del Sprint el equipo presenta el incremento de funcionalidad a las partes implicadas en el proyecto.
    • Desarrollo secuencial vs. superpuestoRequisitos Diseño Código Test En lugar de hacer todo de una cosa a la vez ... ...los equipos Scrum hacen un poco de todo todo el tiempo
    • Scrum Framework Roles•Propietario del producto•SCRUM Master Reuniones•Equipo SCRUM •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
    • SCRUM Framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
    • Propietario del Producto• Representa a todos los interesados en el producto final Sus áreas de responsabilidad son: – Financiación del proyecto – Requisitos del sistema – Retorno de la inversión del proyecto – Lanzamiento del proyecto – Decide sobre las fechas y contenidos de los Releases – Prioriza funcionalidades de acuerdo al valor del mercado/negocio – Ajusta funcionalidades y prioridades en cada Sprint – Acepta o rechaza los resultados del trabajo del equipo
    • El SCRUM Master• Representa a la gestión del proyecto• Responsable de promover los valores y prácticas de Scrum• Remueve impedimentos• Se asegura de que el equipo sea completamente funcional y productivo• Permite la estrecha cooperación en todos los roles y funciones• Garantiza el cumplimiento de roles y responsabilidad
    • El Equipo S SCRUM• Los equipos son auto-organizativos• Responsable de transformar Sprint Backlog en un incremento de la funcionalidad del software. Típicamente de 5 a 9 personas• Multi-funcional y de tiempo completo: Programadores, testers, analistas, diseñadores, etc.• El equipo revisa los requisitos, considera la tecnología disponible, evalúa sus conocimientos, y de forma colectiva determina cómo implementar la funcionalidad.• Solo puede haber cambio de integrantes entre los sprints
    • SCRUM Framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
    • Capacidad Reunion de planeación Sprintdel Equipo PriorizaciónProduct • Analizar y evaluar el Product Backlog ObjetivoBacklog • Seleccionar el objetivo del Sprint del SprintCondicionesdel Negocio Planificación • Decidir como alcanzar el objetivo del Sprint (diseño)Producto • Crear el Sprint Backlog (tareas) en SprintActual base a los temas del Product Backlog Backlog • Estimar Sprint Backlog en horas (1-16 horas)Tecnología
    • Reuniones diarias• Parámetros – Diaria – Dura 15 minutos – Parados• No para la solución de problemas – Todo el mundo está invitado – Sólo los miembros del equipo, Scrum Master y Propietario del Producto, pueden hablar – Ayuda a evitar otras reuniones innecesarias
    • Todos responden 3 preguntas 1 ¿Qué hiciste ayer? 2 ¿Qué vas a hacer hoy? 3 ¿Hay obstáculos en tu camino? • No es dar un reporte de estado al SCRUM Master • Se trata de compromisos delante de pares
    • Reunión de Revisión Sprint• El equipo presenta lo realizado durante el sprint• Normalmente adopta la forma de un demo de las nuevas características o la arquitectura subyacente• Informal• Regla de 2 hs preparación• No usar diapositivas• Todo el equipo participa• Se invita a todo el mundo
    • Reunión de retrospectiva Sprint• Periódicamente, se echa un vistazo a lo que funciona y lo que no, normalmente dura de 15 a 30 minutos• Se realiza luego de cada sprint• Todo el integrantes del proyecto participa Además de Posiblemente clientes y otros• Todos discutes lo que les gustaría: – Comenzar a hacer – Dejar de hacer – Continuar haciendo – Esto es sólo una de las muchas maneras de hacer una retrospectiva.
    • SCRUM framework Roles•Propietario del producto•Scrum Master•Equipo Scrum Reuniones •Planeación Sprint •Reuniones diarias •Revisión Sprint •Retrospectiva Sprint Artefactos •Backlog del Producto •Backlog del Sprint •Grafica de progreso
    • Backlog del ProductoListado con los requisitos del sistema • Es responsabilidad del dueño del producto • Contenido • Priorizacion inicial y al comienzo de cada Sprint • Disponibilidad • Es un documento dinámico que incorpora constantemente las necesidades del sistema • Idealmente cada tema tiene valor para el usuarios o el cliente • Se mantiene durante todo el proceso.
    • Ejemplo Backlog del Producto
    • Sprint Backlog• Trabajo o tareas determinadas por el equipo para realizar en un sprint y lograr al final del mismo un incremento de la funcionalidad.• Se recomienda que las tareas tengan una duración de 4 a 16 horas de trabajo. Las de mayor duración deben dividirse en sub-tareas de ese rango de tiempo.• Los individuos eligen las tareas.• La estimación del trabajo restante es actualizada diariamente• Cualquier miembro del equipo puede añadir, borrar o cambiar el Sprint Backlog
    • Ejemplo de Sprint BacklogTareas L M M J VCodificar UI 8 4 8Codificar negocio 16 12 10 4Testear negocio 8 16 16 11 8Escribir ayuda online 12Escribir la clase foo 8 8 8 8 8Agregar error logging 8 4
    • Gráfica de progresoTareas L Ma Mi J VCodificar UI 8 4 8Codificar Negocio 16 12 10 7Testear Negocio 8 16 16 11 8Escribir ayuda online 12 50 40 30 20 10Hours 0 L Ma Mi J V
    • Resumen SCRUM
    • SCRUM y XP• SCRUM se enfoca a practicas de organización y gestión• XP se centra en practicas de programación• Tratan de áreas diferentes pero se complementan.
    • ágil contra no ágil METODOLOGÍA ÁGIL METODOLOGÍA NO ÁGILPocos Artefactos Más ArtefactosPocos Roles Más RolesNo existe un contrato tradicional o al Existe un contrato prefijadomenos es bastante flexibleCliente es parte del equipo de desarrollo El cliente interactúa con el equipo de(además in-situ) desarrollo mediante reunionesGrupos pequeños (< 10 integrantes) y Grupos grandestrabajando en el mismo sitioMenos énfasis en la arquitectura La arquitectura es esencial
    • Referencias• www.mountaingoatsoftware.com/scrum• www.scrumalliance.org• www.controlchaos.com• scrumdevelopment@yahoogroups.com
    • ¿Preguntas?¿Observaciones?
    • Elaborando un mapa conceptual…
    • http://cmap.ihmc.us