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

Presentación del tema: "FIUBA 2.0 Grupo 3 Orlando Gerbolés Tomas Niño Kehoe Gustavo Narcisi"— Transcripción de la presentación:

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

2 Índice Metodología Métricas Desvíos Solución elegida
Lecciones aprendidas Herramientas Demo

3 Metodología

4 METODOLOGIA Utilizamos de guía los lineamientos de PMBOK en conjunto con conceptos básicos de LEAN Capítulo 5, 6, 7, 9, 10, 11 Alcance – Calendario – Estimación – EV – EP – CP Equipo de trabajo – Comunicaciones – Riesgos Lean es básicamente todo lo concerniente a obtener las cosas correctas en el lugar correcto, en el momento correcto, en la cantidad correcta, minimizando el desperdicio, siendo flexible y estando abierto al cambio. Haciendo foco en lo más importante para el cliente De lean lo que usamos es la priorización de lo importante para el cliente en cada iteración nos enfocábamos en lo que iba esa entrega, nada mas. 1 Principio:“Reaccionar tan rápido como sea posible.” Cuanto antes el producto final se entrega sin defectos considerables, más pronto se pueden recibir comentarios, y se incorporan en la siguiente iteración. Cuanto más cortas sean las iteraciones, mejor es el aprendizaje y la comunicación dentro del equipo. Sin velocidad, las decisiones no pueden ser postergadas. desperdicio es : código y funcionalidad innecesaria retraso en el proceso de desarrollo de software requisitos poco claros burocracia comunicación interna lenta “Reaccionar tan rapido como sea posible" "Vision de conjunto¨ y unn principio de LEAN que no nos sirvio fue "Priorizar el aprendizaje“ “Decida lo mas tarde posible”

5 Métricas Análisis de las métricas utilizadas

6 EVOLUCION DEL PROYECTO
CPI (Trabajo completado por cada peso gastado): 0,91 SPI (Trabajo completado por peso planificado a completar): 1 CPI: 0,84 CPI: 0,70 EV SPI: 0,95 SPI (Trabajo completado por peso planificado a completar): 0,70 Se puede observar que en las primeras semanas el proyecto sufrió un gran atraso en cuanto a tareas completadas y a costo y calendario (cpi y spi 0.70), luego el grupo se organizó, comenzamos a reutilizar código y hubo un mejor manejo de las herramientas con lo cual se corrigió un poco el desfasaje en calendario, pero los costos seguían siendo elevados. Hacia el final del proyecto el proyecto pudo mejorar bastante la performance logrando entregar toda la funcionalidad en tiempo y forma pero con la contra de pagar un exceso en costos. La semana 6 19/10, el AC esta formado por el esfuerzo insumido en el desarrollo con el lenguaje viejo y el nuevo que se eligió.

7 INDICADORES DE CONTROL
EP CP Se puede observar, comparando las semanas indicadas que los índices variaron principalmente por el hecho de cerrar defectos, bajando la cantidad de pendientes y aumentando a la vez la cantidad de test ejecutados y ejecutados correctamente (ejecutados ok). Semana 7 CPI= SPI=0.70 Semana 8 CPI= SPI=0.95 Hacia el final, quedaron algunas modificaciones suspendidas acordadas con el cliente.

8 Desvíos Análisis de un desvío ocurrido

9 Cambio de lenguaje y herramientas de desarrollo
Se detecta un riesgo con alto impacto. R1 – Técnico - Los desarrolladores no conocen el lenguaje de programación. (Documento de análisis de riesgos) El riesgo se materializa al cabo de 4 semanas del inicio del proyecto. Se informa al cliente la situación y el plan de contingencia y se toma la decisión en conjunto de aplicarla. Se aplica el plan de contingencia cambiando de lenguaje y tecnología de desarrollo. Las métricas se deben rehacer, se re-planifica el proyecto en cuanto a calendario, desarrollo, testing, etc. 1) Se detecta un riesgo con alto impacto. R1 – Técnico - Los desarrolladores no conocen el lenguaje de programación. 2) El riesgo se materializa al cabo de 4 semanas del inicio del proyecto. 3) Se informa al cliente la situación y el plan de contingencia y se toma la decisión en conjunto de aplicarla. 4) Se aplica el plan de contingencia cambiando de lenguaje y tecnología de desarrollo . (Contingencia: Cambiar el lenguaje de programación por uno conocido.) (28/10/09 CERRADO) (Se cambió a .Net con el fin de maximizar la cantidad de desarrolladores) 5) Las métricas se deben rehacer porque fue como empezar nuevamente con el desarrollo, testing, etc (porque CU no hizo falta cambiarlos x ej.)

10 Solución elegida

11 SOLUCION ELEGIDA Lenguaje: Base de datos ASP.NET - Framework 3.5 – C#
MS SQL Express 2005 Organización de la solución 5 Proyectos FIUBA20 (parte central de la aplicación) FIUBA20.DA (mapeo de esquema de base de datos) FIUBA20BACKEND (Administrador de la aplicación) FIUBA20Servicio (capa de servicios) FIUBA20Test (test unitarios de la capa de servicios)

12 Lecciones aprendidas

13 SIN RESPONSABLES ASIGNADOS NO HAY COMPROMISO Y CALIDAD EN LAS TAREAS.
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. Asignar responsables nos ayudo a dividir las tareas y organizar mejor el trabajo.

14 Cambio de tecnología Selección inicial del lenguaje:
DEMOSTRAR AL CLIENTE QUE TOMAMOS UNA MALA DECISION PERO TENEMOS ACCIONES PARA CORREGIR EL DESVIO 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ó. Python : Intención de aprender el lenguaje por parte de uno de los miembros. El resto aceptó sin considerar las complicaciones y cantidad de trabajo a realizar Primer entrega: Un sólo desarrollador El resto del grupo no tuvo intención de aprender Python ASP.NET Fricciones dentro del grupo: Descontento por el cambio. Reestructuración de roles: Se pasó a 3 desarrolladores disponibles

15 ANALIZAR EL CONTEXTO NOS PERMITIO TOMAR EL CAMINO CORRECTO
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 (Fowler - Patterns of Enterprise Application Architecture ) 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 Necesidad de desarrollo rápido (arrancamos de cero a una semana de la segunda entrega) “Transaction Script” (Fowler - Patterns of Enterprise Application Architecture )

16 AGREGAR FUNCIONALIDAD NO SOLICITADA ES UNA PERDIDA DE TIEMPO Y DINERO SIN NUNGUN AGREGADO AL PROYECTO ¿Qué es Gold-Plating? Implementar más funcionalidad o incluir requerimientos adicionales desde el principio del proyecto resultando en una extensión del calendario, y generando valor artificial. El cliente debiera en el tiempo pactado esperar y recibir exactamente lo que se especificó, ni más ni menos En FIUBA20 Inclusión de funcionalidad no relevada: Solicitud de alta y baja de grupo Funcionalidad no especificada se elimino luego de mostrar los prototipos o las funcionalidades en reuniones formales Retrabajo Gold Plating: De requerimientos: El exceso de requerimientos no necesarios puede extener el calendario. Las funcionalidades complejas alargan el calendario. De desarrollo: El esfuerzo en diseñar implementar y probar funcionalidades no requeridas alarga el calendario

17 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 AC 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. Explicar los porcentajes que se usaban ¿Cuál era el mas pesado?¿Cual el menos?

18 El proyecto avanza si queda constancia de ello
Se tomó conciencia de que se necesitaba la registración por parte del cliente de los distintos artefactos del proyecto. Se firmaron pruebas de aceptación de usuario. La práctica de aceptación por parte del cliente es algo que se tiene que trabajar para que se logre la constancia. Al no firmar los CU, el cliente podía llegar a rechazar el UAT sin siquiera ejecutarlo. Explicar los porcentajes que se usaban ¿Cuál era el mas pesado?¿Cual el menos?

19 AL TRABAJAR EN UN GRUPO DISPERSO GEOGRAFICAMENTE, LA COMUNICACIÓN, GESTION Y TRAZABILIDAD ES LA CLAVE DEL EXITO 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.

20 Cambio 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 En el comienzo, había solo 1 desarrollador, el cual con el cambio de lenguaje utilizado tomó el rol de líder del proyecto. Quedaron disponibles 3 desarrolladores, los cuales dependiendo de los tiempos podian cumplir roles de analistas, testers. Siempre teniendo en cuenta no caer en incompatibilidades por ejemplo prueba de codigo cruzado para q un desarrollador no pruebe su mismo código.

21 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.

22 Pruebas unitarias y separación de capa de servicios
Desde distintas clases se acceden a sus métodos. Métodos probados 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

23 Mantener un estándar en toda la aplicación.
NO MANTENER LA UNIFORMIDAD EN LA USABILIDAD DEL DESARROLLO IMPACTA NEGATIVAMENTE EN EL PROYECTO Y EN EL CLIENTE 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. Mantener un estándar en toda la aplicación. Quitar controles innecesario, confunden al usuario. No confundir Usabilidad con Gold – Plating. Las versiones anteriores del producto no indicaban campos obligatorios (*), formatos de fechas o . Para descubrir estas cosas, el usuario debía causar un error y luego leer el mensaje generado. No mantener un estándar en los mensajes de la aplicación, confundiendo al usuario (Ej aceptar/rechazar). Dejar controles que confunden al usuario, Agregar cuando no hay usuarios para agregar. Botones en ingles. Esto tiene como consecuencia una mala experiencia de usuario. Fastidio si tiene una conexión lenta a Internet. (ESTO ES MUY EXTREMO) Incluso, si usa un browser que no muestre los mensajes de error, nunca se enteraría ---- las pantallas no tienen todas el mismo flujo algunas terminan con el boton arriba, otras abajo

24 Herramientas

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

26 Demo

27 ?