Metodologas y Procesos giles

Ms. Ing Carlos Castillo Diestra, Dr(c)

Introduccin
Usualmente, al escuchar la palabra "metodologa" suena al ya tan famoso concepto de "procesos de desarrollo de software", lo primero que se nos viene a la mente son 3 preguntas fundamentales:
qu es? Para que sirve? debo tomarlo en cuenta?

Qu es?
Es el conjunto de tcnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software; en palabras sencillas es la base para la edificacin de un proyecto de software, la etapa fundamental para lograr los objetivos buscados con dicho proyecto.

Para que sirve?

Bsicamente, sirve para subir la "calidad" del software, ese es nuestro objetivo controlar de manera transparente todo el proceso de desarrollo, fundamentalmente nos permite producir lo esperado en el tiempo esperado y con el costo esperado, esto es bsico pues muchas veces planeamos hacer algo que finalmente nos toma mas tiempo de lo planeado, por tanto nos produce mas costos y por ellos no logramos completar el proyecto segn lo esperado.

Debemos tomarlo en cuenta?

A decir verdad muchos quisiramos no tomarlo en cuenta, pero se han puesto a pensar si un proyecto rindiera los resultados esperados en el tiempo esperado y con los costos estimados y adems de eso pudiramos controlarlo de manera clara pensando siempre en la escalabilidad o en los nuevos requerimientos que el negocio pueda necesitar? Pues bien, si queremos que un proyecto sea escalable y flexible a los cambios es lgico pensar que para lograr eso necesitamos tomar en cuenta una de las muchas metodologas para el proceso de desarrollo de software.

Debemos tomarlo en cuenta?

Teniendo la idea, un poco ms clara, la duda que se nos presenta de inmediato es: y cual es la mejor metodologa, cual debo de utilizar y porque?, bien tal vez podamos resolver esa duda si conocemos que tipos de metodologas existen y cuales son sus principales caractersticas, ventajas y desventajas y as podamos inclinarnos por alguna de ellas.

Aclaracin
Antes de ir a los conceptos, vale la pena aclarar que implantar un proceso de desarrollo es una labor de mediano a largo plazo, que cuesta tiempo hacer que el equipo involucrado se adapte al proceso pero que es compensado con los resultados obtenidos, es por ello que no tiene sentido ajustarse a un proceso al pie de la letra, sino que hay que adecuarlo a las necesidades de cada empresa.

Cundo un mtodo es gil?

El desarrollo de software es
Incremental
liberaciones pequeas y ciclos rpidos.

Cooperativo
clientes y desarrolladores trabajando juntos.

Simple y Directo
el mtodo es fcil de aprender y modificar.

Adaptativo
es posible realizar cambios de ltimo momento.

Cundo un mtodo es gil?

Ligero A medio camino entre el desarrollo y la organizacin (entre el XP y RUP) Existe un jerarqua dentro del equipo El cdigo fuente tiene propietario Los equipos varan en funcin de la funcionalidad a implementar El conocimiento de la aplicacin se reparte a travs de trabajo en equipo y revisiones Documentacin aceptable

Scrum
Orgenes:
Jeff Sutherland
Scrums iniciales en Easel Corp en 1993 IDX 500 personas haciendo Scrum

Ken Schwaber
ADM Se presenta Scrum en OOPSLA 96 con Sutherland Autor de tres libros sobre Scrum

Mike Beedle
Patrones Scrum en PLOPD4

Ken Schwaber and Mike Cohn

Fundaron conjuntamente la Scrum Alliance en 2002, inicialmente dentro de la Agile Alliance

Scrum ha sido utilizado por:

Microsoft Yahoo Google Electronic Arts High Moon Studios Lockheed Martin Philips Siemens Nokia Capital One BBC Intuit Intuit Nielsen Media First American Real Estate BMC Software Ipswitch John Deere Lexis Nexis Sabre Salesforce.com Time Warner Turner Broadcasting Oce

Scrum ha sido utilizado para:

Software comercial Desarrollos internos Desarrollos bajo Contrato Proyectos Fixed-price Aplicaciones Financieras Aplicaciones certificadas ISO 9001 Sistemas Embebidos Sistemas con requisitos 7x24 y 99.999% de disponibilidad Joint Strike Fighter

Desarrollo de video juegos Sistemas crticos de soporte

vital, aprobados por laFDA Software de control satelital Sitios Web Software para Handheld Telfonos porttiles Aplicaciones de Network switching Aplicaciones de ISV Algunas de las ms grandes aplicaciones en uso

Caractersticas
Equipos auto-organizados El producto avanza en una serie de Sprints" (sprint=carrera corta) de dos semanas a un mes de duracin Los requisitos son capturados como elementos de una lista de Product Backlog" No hay prcticas de ingeniera prescritas Utiliza normas generativas para crear un entorno gil para la entrega de proyectos Uno de los procesos giles

Sprints
En Scrum los proyectos avanzan en una serie de Sprints Anlogo a las iteraciones en XP La duracin tpica es 24 semanas o alo sumo un mes calendario La duracin constante conduce a un mejor ritmo El product es diseado, codificado y testeado durante el Sprint

Scrum Framework
Roles

Product owner ScrumMaster Team

Reuniones

Sprint planning Sprint review Sprint retrospective Daily scrum meeting

Artefactos

Product backlog Sprint backlog Burndown charts

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 iteracin si es necesario Acepta o rechaza los resultados del trabajo del equipo

El ScrumMaster
Representa a la gestin del proyecto Responsable de promover los valores y prcticas de Scrum Remueve impedimentos Se asegura de que el equipo es completamente funcional y productivo Permite la estrecha cooperacin en todos los roles y funciones Escudo del equipo de interferencias externas

El Team
Tpicamente de 5 a 9 personas Multi-funcional: Programadores, testers, analistas, diseadores, etc.

Los miembros deben ser full-time Puede haber excepciones (Ej.: Infraestructura, SCM, etc.) Los equipos son auto-organizativos Idealmente, no existen ttulos pero a veces se utilizan de acuerdo a la organizacin Solo puede haber cambio de miembros entre los sprints

Sprint Planning Meeting

Capacidad Capacidad del del Equipo Equipo Product Product Backlog Backlog Condicione Condicione s s del del Negocio Negocio Producto Producto Actual Actual

Sprint Planning meeting

Priorizacin

Analizar y evaluar el Product Backlog Seleccionar el objetivo del Sprint

Objetivo Objetivo del del Sprint Sprint

Planificacin

Tecnologa Tecnologa

Decidir como alcanzar el objetivo del Sprint (diseo) Crear el Sprint Backlog (tareas) en base a los temas del Product Backlog (user stories / features) Estimar Sprint Backlog en horas

Sprint Sprint Backlog Backlog

Planificacin del Sprint

El equipo selecciona los temas a partir del Product Backlog que pueden comprometerse a completar Se crea el Sprint Backlog
Se identifican tareas y cada una es estimada (1-16 horas) Realizado colaborativamente, no solo por el ScrumMaster

El diseo de Alto Nivel es considerado

Codificar la capa intermedia (8 hs) Codificar la interfaz de usuario (4) Escribir los test fixtures (4) Codificar la clase foo (6) Actualizar test de performance (4)

COMO COMO planificador planificador de de vacaciones, vacaciones, YO YO QUIERO QUIERO ver ver fotos fotos de de los los hoteles. hoteles.

Daily Scrum
Parmetros Diaria Dura 15 minutos Parados No para la solucin de problemas Todo el mundo est invitado Slo los miembros del equipo, ScrumMaster y Product Owner, pueden hablar Ayuda a evitar otras reuniones innecesarias

Sprint review
El equipo presenta lo realizado durante el sprint Normalmente adopta la forma de una demo de las nuevas caractersticas o la arquitectura subyacente Informal Regla de 2 hs preparacin No usar diapositivas Todo el equipo participa Se invita a todo el mundo

Sprint retrospective
Peridicamente, se echa un vistazo a lo que funciona y lo que no Normalmente 15 a 30 minutos Se realiza luego de cada sprint Todo el equipo participa ScrumMaster Product owner Equipo Posiblemente clientes y otros

Product Backlog
Los requisitos Una lista de todos los trabajos deseados en el proyecto Idealmente cada tema tiene valor para el usuarios o el cliente Priorizada por el Product Owner Repriorizada al comienzo de cada Sprint

Este Este es es el el product product backlog backlog

El objetivo del Sprint

Una breve declaracin de cual ser el foco del trabajo durante el sprint
Ciencias Biolgicas Funciones de apoyo tcnico necesarios para estudios de gentica de poblaciones.

Aplicacin con B.Datos

Hacer que la aplicacin se ejecute en SQL Server, adems de Oracle. Servicios Financieros
Soportar ms indicadores tcnicos que la empresa ABC en tiempo real y streaming de datos.

Gestin del Sprint Backlog

Los individuos eligen las tareas El trabajo nunca es asignado La estimacin del trabajo restante es actualizada diariamente Cualquier miembro del equipo puede aadir, borrar o cambiar el Sprint Backlog El trabajo para el Sprint emerge Si el trabajo no est claro, definir un tema del Sprint Backlog con una mayor cantidad de tiempo y subdividirla luego. Actualizar el trabajo restante a medida de que ms se conoce

Feature Driven Development (FDD)

Feature Driven Developmente = Desarrollo guiado por caractersticas Es un proceso gil diseado por Peter Coad, Eric Lefebvre y Jeff DeLuca. Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a caractersticas o funcionalidades, que son pequeas partes del software con significado para el cliente.

Feature Driven Development (FDD)

A diferencia de otros procesos giles no cubre todo el ciclo de vida sino slo las fases de diseo y construccin. No requiere un modelo especfico de proceso y se complementa con otras metodologas. Enfatiza cuestiones de calidad y define claramente entregas tangibles y formas de evaluacin del progreso.

Feature Driven Development (FDD)

No hace nfasis en la obtencin de los requerimientos sino en como se realizan las fases de diseo y construccin. Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto. 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 peridicos y tangibles. Define claramente entregas tangibles y formas de evaluacin del progreso del proyecto.

Roles
FDD define tres categoras de roles: Roles claves - Gerente del proyecto - Arquitecto jefe - Gerente de desarrollo - Programador jefe - Propietarios de clases - Experto de dominio

Roles de soporte - Administrador de entrega - Guru de lenguaje - Herramientista (toolsmith) - Administrador del sistema Roles Adicionales - Tester - Escritores de documentos tcnicos

Proceso
FDD consiste en cinco procesos secuenciales durante los cuales se disea y construye el sistema. La parte iterativa soporta desarrollo gil con rpidas adaptaciones a cambios en requerimientos y necesidades del negocio. Cada fase del proceso tiene un criterio de entrada, tareas, pruebas y un criterio de salida.

Proceso

Proceso
Desarrollo de un modelo general: Cuando comienza el desarrollo, los expertos de dominio estn al tanto de la visn, el contexto y los requerimientos del sistema a construir. A esta altura se espera que existan requerimientos tales como casos de uso o especificaciones funcionales. Construccin de la lista de rasgos: Los ensayos, modelos de objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de rasgos. Estos rasgos son pequeos tems tiles a los ojos del cliente. La lista de rasgos es revisada por los usuarios y patrocinadores para asegurar su validez y exhaustividad, los rasgos que requieran de ms de diez das se descomponen en otros ms pequeos.

Proceso
Planeamiento por rasgos: Incluye la creacin de un plan de alto nivel, en el que los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Diseo por rasgos y Construccin por rasgos: Se selecciona un pequeo conjunto de rasgos del conjunto, y los propietarios de clases seleccionan los correspondientes equipos dispuestos por rasgos. Se procede luego iterativamente hasta que se producen los rasgos seleccionados. Una iteracin puede tomar de unos pocos das un mximo de dos semanas. El proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo.

Conclusin
Qu debemos esperar entonces de un proceso de desarrollo? Qu criterios debe cumplir para que aporte algo a la empresa?

Conclusin
Bsicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el xito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados. Esto no nos lo va a ofrecer ningn proceso estndar, de forma que es tarea de cada empresa ( eleccin de acuerdo al proyecto), decidir cual es el mejor modo de llegar a nuestra meta.

Tarea de investigacin y autoestudio Metodologas giles de desarrollo de software Metodologas Crystal Desarrollo de software adaptativo Metodologa de desarrollo de sistemas dinmicos (DSDM)