Desarrollo de software innovador con métodos ágiles

Desarrollo de software tradicional (en cascada) Definir requerimientos de clientes, dirección y alcance del Producto Investigar, definir visión del Producto Planificación Vender el producto y darle soporte Obtener feedback de los clientes http://ww Diseño Release Diseñar del Producto Escribir especificaciones técnicas detalladas, definir fechas para las siguientes fases “Crear” el producto Programación Corregir bugs Preparar el producto para su release Implementación Estabilización Desarrollo de software tradicional (en cascada)

La mayoría de los proyectos de desarrollo de software son COMPLEJOS . . . Fuente: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Lejos de Acuerdo Anarquía Complejo Requerimientos the vertical axis traces requirements complexity, and the horizontal axis traces technology complexity. The third dimension of complexity is the people developing the software. They all have different skills, intelligence levels, experience, viewpoints, attitudes, and prejudices. I believe that the last “simple” project occurred in 1969, when one person from order processing at Sears Roebuck asked me to sort some cards and generate a report on an IBM 360/20. Since then, things have only gotten messier. Scrum addresses the complexity of software development projects by implementing the inspection, adaptation, and visibility requirements of empirical process control with a set of simple practices and rules Complicado Simple Cerca de Acuerdo Tecnología utilizada Cerca de Certeza Lejos de Certeza

. . . y las personas contribuimos a que esa complejidad aumente. Lejos de Acuerdo Requerimientos Cerca de Acuerdo Tecnología utilizada Cerca de Certeza Lejos de Certeza Seres Humanos

Experiencia, observación, experimentación Podemos adoptar con éxito un modelo pre-definido para controlar un proceso cuando entendemos bien los mecanismos subyacentes de ese proceso Pero el proceso de desarrollar software innovador es muy complejo y generalmente desconocido al comienzo de los proyectos “. . . cuando un proceso es muy complejo, la mejor elección es aplicar conceptos y controles empíricos. “ Fuente: B. A. Ogunnaike and W. H. Ray, Process Dynamics, Modeling, and Control Experiencia, observación, experimentación

Control Empírico de Procesos Visibilidad Inspección Adaptación Control Empírico de Procesos

Control Empírico de Procesos Visibilidad Inspección Adaptación Ejemplo: Code Review Se hacen ajustes según los comentarios recibidos Codificadores experimentados revisan Control Empírico de Procesos Varios programadores codifican, conociendo los estándares de la industria

Manifiesto Agil Individuos e interacción Software en funcionamiento Mas que procesos y herramientas Software en funcionamiento Mas que documentación Colaboración con y del Cliente Mas que negociación de contrato Responder al cambio Mas que seguir un plan

Scrum Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de negocio en el menor tiempo. Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de trabajo (cada dos semanas o un mes). El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la mejor manera de entregar las funcionalidades de más alta prioridad. Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y decidir si liberarlo o seguir mejorandolo en otro sprint.

Características de Scrum Equipos auto-organizados El producto avanza en una serie de “Sprints" de dos semanas a un mes de duración No hay prácticas de ingeniería prescritas Pero sí reglas (pocas y muy claras) que se aplican con férrea disciplina Existe una lista priorizada de requerimientos (“Product Backlog”) Formato de user stories Ordenados por valor de negocios El “Team” define el cómo y estima los tiempos

Roles Product Owner ScrumMaster Team

Product Owner Define las funcionalidades del producto Decide sobre las fechas y contenidos de los releases Es responsable por la rentabilidad del producto (ROI) Prioriza funcionalidades de acuerdo al valor del mercado/negocio Ajusta funcionalidades y prioridades en cada iteración si es necesario 

ScrumMaster 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 es completamente funcional y productivo Permite la estrecha cooperación en todos los roles y funciones Escudo del equipo de interferencias externas

Team Típicamente de 5 a 9 personas Multi-funcional: Programadores, testers, analistas, diseñadores, etc. Integrantes full-time Puede haber excepciones Los equipos son auto-organizativos Idealmente, no existen títulos pero a veces se utilizan de acuerdo a la organización

Reuniones Planificación del Sprint Stand-up meeting (Daily Scrum) Qué hice ayer / Qué voy a hacer hoy / Impedimentos Sprint Demo (Review) Sprint Retrospective

Fuente: www.mountaingoatsoftware.com/scrum

Principios de Lean Software Development Eliminar el derroche Ampliar el Aprendizaje Retrasar los compromisos Liberar Rápido Facultar al equipo Construir Integridad Intrínseca Pensar en el todo

Trabajo práctico de métodos ágiles a) Investigar en Internet acerca de los siguientes métodos ágiles de desarrollo de software: Peer Programming (Programación de a pares) XP – Extreme Programming TDD – Test-Driven Development BDD – Business-Driven Development Kanban b) Para cada método ágil mencionado escribir una definición breve que permita explicarlo a otra persona en 2 minutos Test del elevador c) Elegir uno de los métodos y explicarlo a través de un dibujo, diagrama, infografía, foto, collage de imágenes, o similar.