1 FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi Sabrina Marcus

2 Í NDICE Metodología Herramientas Solución elegida Manejo de riesgos Lecciones aprendidas Demo

3 M ETODOLOGÍA

4 PMBOK utilizando conceptos básicos de LEAN Capítulo 5 - Alcance Capítulo 6 – Calendario Capítulo 7 – Estimación - EV Capítulo 9 - Equipo de trabajo Capítulo 10 - Comunicaciones Capítulo 11 - Riesgos

5 S OLUCIÓN ELEGIDA Lenguaje Base de datos Arquitectura

6 S OLUCIÓN ELEGIDA Lenguaje: ASP.NET - Framework 3.5 – C# Base de datos MS SQL Express 2005

7 L ECCIONES APRENDIDAS Selección del lenguaje Gold-Plating Calculo de EV Comunicación Cambio de roles según necesidades Unificación del criterios Seguimiento de incidentes Pruebas unitarias y separación de capa de servicios Usabilidad y gold plating. PMBOK vs SCRUM

8 Tareas sin responsable no se hacen Tareas sin responsables fueron ejecutadas pero no se realizaron en forma completa. No se testearon en su totalidad. Desorientación del equipo a la hora de asignar un responsable para su finalización.

9 Demostrar al cliente que tomamos una mala decisión pero tenemos acciones para corregir el desvío no es una muestra de debilidad sino de madurez Selección inicial del lenguaje : Python Primer entrega desarrollada en Python y sin funcionalidad completa. Cambio de tecnología ASP.NET Consecuencias Motivación para desarrollar (tecnología conocida) Retrabajo – se reescribió lo pactado para la primer entrega y se incluyó lo pactado para la segunda en una sola iteración. Reestructuración de roles. Eliminación de riesgos Se dejó de depender de la disponibilidad de una sola persona para el desarrollo, con lo cual la probabilidad de ocurrencia descendió.

10 Analizar el contexto nos permitió elegir el camino más conveniente Contexto Necesidad de desarrollo rápido La aplicación no evolucionará con el tiempo Aplicación no presenta alta complejidad Transacciones simples Solución: Arquitectura basada en Transaction Script Sin modelo de dominio Acceso a los datos desde la capa de presentación/servicios Consecuencias: Velocidad en desarrollo Dificultad de agregar pruebas automatizadas Simplicidad (aprovechamos las herramientas que nos brinda la IDE) Alcanzamos la funcionalidad acordada

11 Agregar funcionalidad no solicitada es una perdida de tiempo y dinero sin ningún agregado al proyecto. ¿Qué es Gold-Plating? Dar al cliente más funcionalidad de lo que fue solicitado No posee valor alguno En contra de los conceptos de LEAN El cliente debiera Esperar y recibir exactamente lo que se especificó, ni más ni menos En FIUBA20 Inclusión de detalles no solicitados Funcionalidad no especificada se elimino luego de mostrar los prototipos o las funcionalidades en reuniones formales Retrabajo

12 C ÁLCULO DE EV La clave de un buen control es aplicar un modelo y no entrar en detalles que requieren mucho esfuerzo. Se comenzó ponderando las horas trabajadas con el rol de cada integrante. Esto causo confusión y complicaciones a la hora de calcular en E.V. Se dejó de ponderar con el rol, y se paso a sumar las horas cargadas directamente. Como consecuencia se obtuvo un calculo mas sencillo, claro y comprensible por el cliente.

13 Al trabajar en un grupo disperso geográficamente, la comunicación, gestión y trazabilidad es la clave del éxito Grupo google y Skype. Administración del proyecto on-line. Seguimiento de los issues con comentarios al hacer commits. Reuniones de avance semanalmente con el cliente, con un entregas incrementales cada dos semanas.

14 C AMBIO DE ROLES SEGÚN NECESIDADES Adaptación de los distintos integrantes a distintos roles Con el cambio del lenguaje se readaptaron los roles Versatilidad permitió que se pudiera avanzar dependiendo de disponibilidad de tiempo de cada uno

15 UNIFICACION DE CRITERIOS Diferentes criterios en definición de bugs Qué es bug y qué no Cuándo un bug está cerrado y cuándo no Solución buscada Determinar los criterios para establecer estándar propio del grupo. Se consiguió aplicar en forma parcial. Se trató de unificar la forma de cerrar los bugs. Si lo que se declaró en el issue está completado y se encuentra un nuevo bug, cerrarlo y abrir uno nuevo. Cómo prevenirlo a futuro Preparar documentos de testing en forma conjunta y antes de iniciar el desarrollo. Asegurarse de que todos los involucrados estén de acuerdo con el documento.

16 S EGUIMIENTO DE INCIDENTES

17 P RUEBAS UNITARIAS Y SEPARACIÓN DE CAPA DE SERVICIOS Separación de capa de servicios Desde distintas clases se acceden a sus métodos. Métodos testeados con tests unitarios que garantizan correcto funcionamiento de los mismos. Puede ser utilizada en distintos proyectos de la solución Pruebas unitarias Ahorró de tiempo al probar modificaciones realizadas Se pueden generar en forma independiente de los datos que contiene la base de datos. No se aplicó TDD debido a la arquitectura utilizada. Se realizó la separación a la capa de servicios en forma posterior. Se genera retrabajo. Es conveniente realizarlos en forma temprana y de ser posible aplicar TDD

No confundir Usabilidad con Gold - Plating Detalles como indicar campos obligatorios, formato de las fechas o de las direcciones de correo electrónico no agrega funcionalidad no pedida, agrega valor al producto al evitar errores del usuario. Una aplicación menos reactiva tiene como consecuencia una mejor experiencia de usuario.

19 PMBOK vs SCRUM Realizamos una planificación al principio del proyecto. Luego de los cambios de la primera entrega, no se replanificó. En caso de haber utilizado SCRUM, se podrían haber replanificado las tareas acorde al nuevo contexto. Se marcaron tareas como terminadas, cuando en realidad, ciertas etapas no se habian ejecutado. Fueron re abiertas. En caso de utilizar SCRUM, no se hubiese entregado nada que no estuviese realmente terminado.

20

21 D EMO

22 ?

23 H ERRAMIENTAS

24 H ERRAMIENTAS Visual Studio 2008 NUnit SQL Server 2005 Assembla (Seguimiento de incidentes y SVN) Tortoise SVN Client Enterprise Architect Word / Excel – Open Office