Programación Avanzada

Ciclos de vida ágiles

Ciclos de vida ágiles•XP•FDD•SCRUM•DSDM•Crystal

Agenda

Ciclo de Vida:eXtreme

Programming (XP)

• Programación extrema (XP) es un enfoque de la ingeniería del software formulado por Kent Beck.

• Pone más énfasis en la adaptabilidad que en la previsibilidad (Que el software pueda adaptarse a nuevos requerimientos en vez de buscar contemplarlos todos previo a su construcción) .

• Está centrado en potenciar las relaciones interpersonales como clave para el éxito en el desarrollo de software.

• Se basa en la realimentación continua entre el cliente y el equipo de desarrollo (Comunicación fluida entre todos los participantes).

• XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes.

• Para especificar los requisitos del software usa tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer (historias de usuario).

Ciclo de Vida: XP

•Simplicidad: Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento.

•Comunicación:o El código autodocumentado es más

fiable que los comentarios.o Se debe comentar sólo lo que NO va a

variar.o Comunicación con el cliente es fluida.

Ciclo de Vida: XP - Principios Básicos

Retroalimentación(feedback): Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.

Coraje o valentía: Aceptar que la programación en parejas beneficiará la calidad del código.

Ciclo de Vida: XP - Principios Básicos

•Refactoring:o Reescribir el código fuente de un módulo sin afectar su

funcionalidad con la finalidad de hacerlo más preciso, conciso y entendible.

•Spike: o Pequeños programas para probar o evaluar una

solución.o Usados ante problemas técnicos o dificultad en la

estimación de tiempo para implementar la historia de usuario.

o Una vez utilizados son desechados.

Ciclo de Vida: XP – Conceptos

• Programador: Recibe pruebas unitarias y genera el código del sistema.

• Cliente: Escribe las historias de usuario, las pruebas funcionales para validar la implementación y decide el orden para su implementación.

• Encargado de pruebas: Ayuda al cliente a escribir pruebas funcionales, ejecuta las pruebas, difunde los resultados.

• Encargado de seguimiento: Retroalimenta al equipo,verifica el grado de acierto entre las estimaciones y el tiempo real (para mejora de estimaciones), realiza el seguimiento del proceso en cada iteración.

Ciclo de Vida: XP - Roles

•Entrenador: es el responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

•Consultor: es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas (Experto).

•Gestor (big boss): es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

Ciclo de Vida: XP - Roles

El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

1. El cliente define el valor de negocio a implementar

2. El programador estima el esfuerzo necesario para su implementación

3. El programador construye ese valor

4. Vuelve al paso 1

Ciclo de Vida: XP - Funcionamiento

Ciclo de Vida: XP - Funcionamiento

• En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden.

• No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos.

• De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse de que el sistema tenga el mayor valor de negocio posible.

Ciclo de Vida: XP - Funcionamiento

• La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del coste del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione.

• El juego de la planificación. Hay una comunicación frecuente entre el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.

• Entregas pequeñas. Producir rápidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versión ya constituye un resultado de valor para el negocio. Una entrega no debería tardar más de 3 meses.

Ciclo de Vida: XP - Prácticas

‐ Diseño simple. Se debe diseñar la solución más simple que pueda funcionar y ser implementada en un momento determinado del proyecto.

‐ Pruebas. La producción de código está dirigida por las pruebas unitarias. Éstas son establecidas por el cliente antes de escribirse el código y son ejecutadas constantemente ante cada modificación del sistema.

‐ Programación en parejas. Toda la producción de código debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implícitas (menor tasa de errores, mejor diseño, mayor satisfacción de los programadores…).

Ciclo de Vida: XP - Prácticas

Ciclo de vida:FDD

• Feature Driven Development (Desarrollo Basado en Funcionalidades).

• Proceso ágil para el desarrollo de sistemas.

• Diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca.

• No se hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de diseño y construcción.

• Incluye un monitoreo constante del proyecto.

Ciclo de Vida: FDD

• Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado.

• Propone tener etapas de cierre cada dos semanas.

• Se obtienen resultado periódicos y tangibles.

Ciclo de Vida: FDD

• Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorear.

• Define claramente entregas tangibles y formas de evaluación del progreso del proyecto

Ciclo de Vida: FDD

FDD - Proceso

1 2 3

4 5

•Expertos del dominio están al tanto del ámbito, alcance y requerimientos del sistema a construir.

•División del dominio en áreas que son analizadas detalladamente.

•Los desarrolladores construyen diagramas de clases o de objetos por cada área.

•Se construye un modelo general del software.

FDD – Proceso(1) Desarrollar modelo general

•Un rasgo es una característica a los ojos del cliente.o Elaborar lista de rasgos que resuman al

sistema general.o La lista es elaborada por los

desarrolladores y es evaluada por el cliente.

o Se divide en subconjunto según afinidad y la dependencia entre rasgos.

o Lista es revisada por los usuarios y los responsables para su validación y aprobación.

FDD – Proceso(2) Construir lista de rasgos

•Ordenar los conjuntos de rasgos conforme a su prioridad y dependencia.

•Asignación a los programadores jefes.

FDD – Proceso(3) Planeación por rasgo

•Selección de un conjuntos de rasgos de la lista.

•Se diseña y construye rasgo mediante un proceso iterativo.

•Una iteración puede tomar desde unos pocos días a un máximo de dos semanas.

•Cada iteración incluye: inspección de diseño, codificación, pruebas e inspección de código.

FDD – Proceso(4) y (5) Diseñar y construir por rasgo.

FDD - RolesExisten 3 categorías de roles para FDD:

•Key Roles / roles claves

•Supporting Roles / Roles de Soporte.

•Additional Roles / Roles Adicionales.

•Gerente de proyecto (Project Manager)o Líder administrativo y financiero del proyecto.

•Arquitecto jefe (Chief Architect)o Diseño global del sistema.

o Ejecución de todas las etapas.

•Gerente de desarrollo (Development Manager)o Lleva diariamente las actividades de

desarrollo.

o Resuelve conflictos en el equipo.

o Resuelve problemas referentes a recursos.

FDD – Roles Key Roles

•Programador Jefe(Chief Programmer)o Analiza los requerimientos.

o Diseña el proyecto.

o Selecciona rasgos a desarrolla.•Propietario de clases (Class Owner)

o Responsable del desarrollo de las clases que se le asignaron como propias.

o Participa en la decisión de que clase será incluida en la lista de rasgos para la próxima iteración.

FDD – Roles Key Roles

•Experto del dominioo Puede ser un usuario, un cliente,

analista o una mezcla de estos.

o Poseen el conocimiento de los requerimientos del sistema.

o Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

FDD – Roles Key Roles

•Gerente del dominio (Domain Manager)o Lidera al grupo de expertos del dominio.

o Resuelve sus diferencias de opinión respecto a requerimientos.

•Administrador de release (Release Manager)o Controla el avance del proceso mediante

la revisión de los reportes del Chief Programmer.

o Reporta resultados obtenidos semanalmente al gerente, al cliente donde incluye el porcentaje de avance de cada feature.

FDD – Roles Supporting Roles

•Guru del Language(Language Lawyer)o Responsable de poseer un vasto

conocimiento en, por ejemplo, el lenguaje de programación.

o Importante cuando se trabaja en nuevas tecnologías.

•Ingeniero de construcción (Build Engineer)o Responsable de preparar, mantener y

correr el proceso de construcción.

o Realiza el mantenimiento de las versiones y la publicación de la documentación.

FDD – Roles Supporting Roles

•Administrador del sistema (System Administrator)o Configura, administra y repara los

servidores, estaciones de trabajo y equios de desarrollo y testeo utilizados por el equipo.

•Herramentista (toolsmith)o Rol para la construcción de herramientas

específicas para el desarrollo, conversion de datos y testeo.

o Puede trabajar en la preparación y mantenimiento tanto de bases de datos o sitios web destinados el proyecto.

FDD – Roles Supporting Roles

•Testero Verifica que el sistema recién creado cumpla

con los requerimientos del cliente.

o Puede llegar a ser una persona independiente del equipo de proyecto.

•Deployero Encargado de convertir la información

existente requerida por el nuevo sistema.•Escritor Técnico (Technical Writer)

o Prepara la documentación para los usuarios, que pueden formar parte o no del equipo del proyecto.

FDD – Roles Additional Roles

Tamaños de equipo: Ambos se implementan mejor para proyectos cortos y equipos más pequeños, siendo quizás FDD más escalable que XP.

Evaluación estado del proyecto: FDD es posiblemente el proceso más adecuado para establecer métricas que definen el estado del proyecto, puesto que al dividirlos en unidades pequeñas es bastante sencillo un seguimiento de las mismas, xp también define componentes pequeños aunque con menos orden porque se van evaluando en el momento.

XP VS FDD

Carga de trabajo: XP es un proceso ligero, esto es, que los creadores del proceso han tenido cuidado de no poner demasiadas tareas organizativas sobre los programadores, por tu parte FDD genera más documentación que XP.Relación con el cliente: XP y FDD se basan en formalismos en la documentación, si no en los controles propios y una comunicación fluida con el cliente.

XP VS FDD

Conocimiento de la arquitectura: En XP se intentará reducir la complejidad del software a través de la programación a pares, ya que en la creación de código se pueden evitar errores y malos diseños. En FDD sin embargo, se usan las sesiones de trabajo conjuntas en fase de diseño para conseguir una arquitectura sencilla y sin errores.

Puntos débiles: FDD tiene la necesidad de tener en el equipo miembros con experiencia que marquen el camino a seguir desde el inicio, con la elaboración del modelo global, puesto que no es tan ágil como podria serlo XP.

XP VS FDD

Ciclo de vida:SCRUM

• Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

• Define un sprint como el período en el cual se lleva a cabo el trabajo en sí y cuya magnitud la define el equipo en base a su experiencia.

• En cada sprint el equipo crea un incremento de software potencialmente entregable al cliente (utilizable).

• Puede ser usado también para la ejecución de equipos de mantenimiento de software.

SCRUM

Scrum es una metodología ágil, y como tal:

• Es un modo de desarrollo de carácter adaptable más que predictivo.

• Orientado a las personas más que a los procesos.

• Emplea la estructura de desarrollo ágil:incremental basada en iteraciones y revisiones.

SCRUM

Se comienza con la visión general del producto,especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días).

Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto.

Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente.

SCRUM - Proceso

Control de la evolución del proyecto:Scrum controla de forma empírica y adaptable la

evolución del proyecto, empleando las siguientes prácticas de la gestión ágil:

• Revisión de las Iteraciones.• Desarrollo incremental.• Desarrollo evolutivo.• Auto-organización.• Colaboración.

SCRUM

Revisión de las Iteraciones: Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto.

Desarrollo incremental: Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones.

(El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar.)

SCRUM - Control de evolución

• Desarrollo evolutivo: Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos.

• Intentar predecir en las fases iniciales cómo será el producto final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto.(No así las finales, por el constante cambio)

• En Scrum se toma a la inestabilidad como una

premisa, y se adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la arquitectura que se irá generando durante el desarrollo.

SCRUM - Control de evolución

• Desarrollo evolutivo: El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto.

• Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements churn), y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada.

SCRUM - Control de evolución

•Scrum denomina “sprint” a cada iteración de desarrollo y recomienda realizarlas con duraciones de 30 días.

•El sprint es por tanto el núcleo central que proporciona la base de desarrollo iterativo e incremental.

SCRUM - Sprint

• Planificación de sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben cumplir en esa iteración.

• Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la previsión para el día siguiente.

• Revisión de sprint: Análisis y revisión del incremento generado.

SCRUM – Reuniones

• Product Owner: Mantiene los procesos y trabaja junto con el jefe de proyecto (voz del cliente para el equipo).

• ScrumMaster (o Facilitador): Elimina los obstáculos que impiden que el equipo alcance el objetivo del sprint, protege al equipo de distracciones.

Scrum - Roles

• Equipo de Desarrollo: Son los responsables de entregar el producto, lo componen un grupo de entre 3 a 9 personas.

• Stakeholders (Clientes, Proveedores, etc): Es para quienes el software producirá beneficios que justifican el desarrollo. (grupo de interesados)

• Administradores: Los que establecen el ambiente de desarrollo.

Scrum - Roles

• Product Backlog: o Documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.

o Priorizadas según su retorno sobre la inversión. o Es el "qué" va a ser construido. Es abierto y cualquiera puede

modificarlo.

• Sprint backlog: o Documento detallado donde se describe el cómo el

equipo va a implementar los requisitos durante el siguiente sprint.

• Burn Down Chart: o Gráfica mostrada públicamente que mide la cantidad de

requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.

Scrum - Documentación

Comparación entre SCRUM y XPDiferencias

Scrum eXtreme Programming

Es una metodología de desarrollo ágil basada en la administración del proyecto.

Es una metodología de desarrollo ágil que está más centrada en la programación o creación del producto

Cada integrante del equipo trabaja de forma individual

Programación en parejas.

Las iteraciones tienen una duración entre 1 y 4 semanas

Las iteraciones de entrega duran entre 1 y 3 semanas.

Al finalizar un Sprint, las tareas del Sprint Backlog que se hayan realizado y que el Product Owner (propietario del producto) haya mostrado su conformidad ya no se retoca.

Las tareas se van terminando aunque son susceptibles de ser modificadas durante el transcurso de proyecto, incluso, después de que funcionen correctamente.

Comparación entre SCRUM y XPDiferencias

Scrum eXtreme Programming

Trata de seguir el orden de prioridades que marca el Product Owner en el Sprint Backlog pero puede variar según la necesidad del desarrollo de tareas

El equipo de desarrollo sigue estrictamente el orden de prioridad de las tareas definido por el cliente.

Ciclo de Vida: DSDM

• Dynamic systems development method

• Está basada en la metodología RAD (Rapid application development).

• Posee un enfoque iterativo e incremental que enfatiza la participación continua del usuario.

• Su objetivo es entregar sistemas de software en tiempo y presupuesto ajustándose a los cambios de requisitos durante el proceso de desarrollo

Ciclo de Vida: DSDM

Ciclo de Vida: DSDM

•Se centra en proyectos de sistemas de información que se caracterizan por planificaciones y presupuestos estrictos.

•Consiste en 3 fases:o Fase pre-proyecto.o Fase de ciclo de vida del proyecto.o Fase post-proyecto.

DSDM - Características

La fase de ciclo de vida del proyecto está subdividida en 5 etapas:

• Estudio de viabilidad.• Estudio de negocio• Iteración de modelo funcional • Iteración de diseño• Construcción e implementación.

Es posible integrar otras metodologías tales como: RUP, XP Y PRINCE2.

DSDM - Características

Hay nueve procesos subyacentes que consisten en cuatro fundamentos y cinco puntos de partida.

•Participación del usuario es clave.•Se le deben otorgar poderes al

equipo del proyecto para tomar decisiones y no esperar aprobaciones de más alto nivel.

•Poner foco en la entrega frecuente de productos.

DSDM - Enfoque

•Principal criterio de aceptación de un entregable es que sea un sistema que trate las necesidades del negocio actuales.

•El desarrollo es iterativo e incremental y conducido por la retroalimentación del usuario para converger en una solución efectiva.

•Todos los cambios son reversibles.

•Establecer una línea base de alcance y los requisitos de alto nivel (mayor prioridad)

DSDM - Enfoque

•Las pruebas se efectúan a lo largo de todo el ciclo de vida del proyecto.

•Necesidad de cooperación y comunicación entre todas las personas en el negocio.

DSDM - Enfoque

•Aceptación de DSDM por parte de la gerencia y otros empleados.(Genera compromiso por parte de los involucrados)

•El compromiso de la gestión de asegurar la participación de usuario final.

•El equipo ha de estar formado miembros habilidosos que formen una unión estable.

DSDM - FACTORES CRÍTICOS DE ÉXITO

Metodología:Crystal

• Desarrollada por el investigador de IBM el Dr. Alistair Cockburn

• No es una metodología en si misma sino una familia de metodologías con un “código genético” común.

• Identifica con colores diferentes cada método, y su elección debe ser consecuencia del tamaño y criticidad del proyecto.

• Factor más significativo es la comunicación.o Aconseja que el tamaño del equipo sea reducido.

• Aumento en el número de personas deriva en un aumento en la necesidad de coordinación.

Crystal - Características

• Clear es para equipos de hasta 8 personas o menos.• Amarillo es para equipos entre 10 a 20 personas.• Naranja es para equipos entre 20 a 50 personas.• Roja es para equipos entre 50 a 100 personas.• Azul es para equipos entre 100 a 200 personas

Crystal - Políticas de equipo

• Executive Sponsor (Patrocinador Ejecutivo)o Produce la Declaración de Misión con Prioridades

de Compromiso• Project Manager (Jefe de Proyecto)

• Domain Expert (Experto en el Dominio)• Usage Expert (Experto de uso)• Designer-Programmer (Programador Diseñador)• UI Designer (UI Diseñador)• Tester (Realizador de Pruebas)• Technical (Programador Técnico)

Crystal - Roles

• Es una metodología centrada en el factor humano• El diseñador líder y de dos a siete desarrolladores

más se encuentran juntos en un local grande o en locales adyacentes.

• Compartan fuente de información (pizarras, diagramas) visibles para todos.

• Acceso a usuarios claves del sistema; • Entrega de código funcional, testeado y utilizable.• Proyectos de pequeña duración.

Crystal Clear

• Entrega frecuente: Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el código.

• Comunicación: entre todos los integrantes del equipo de desarrollo.

• Mejora reflexiva: Tiempos para compartir reflexiones, discuciones o entregar opiniones a los demás integrantes.

Crystal Clear - Características

• Seguridad personal: Entregar sus juicios respecto a lo realizado por los demás integrantes.

• Foco: Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo (dirección y prioridad)

• Fácil acceso a usuarios expertos: Importancia del contacto directo con expertos en el desarrollo de un proyecto.

Crystal Clear - Características

• XP es un miembro válido de la familia Crystal Clear.• Ambos tienen:

–Entregas frecuentes–Foco en comunicación–Compromiso del usuario/cliente–Test de regresión automático–Preocupación por la motivación

Crystal Clear y XP

• Diferencia: disciplina y tolerancia.

• XP:- Pocos entregables y estándares rigurosos:– Estándares de diseño y codificación.– Pair programming.– 100% unit test pass.– El coach es necesario para mantener la disciplina.

• Crystal es más tolerante y más fácil de seguir.

Crystal Clear y XP