La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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

Presentaciones similares


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

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

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

3 3 M ETODOLOGÍA

4 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

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

6 EVOLUCION DEL PROYECTO EV CPI (Trabajo completado por cada peso gastado): 0,91 SPI (Trabajo completado por peso planificado a completar): 1 CPI: 0,70 SPI: 0,95 SPI (Trabajo completado por peso planificado a completar): 0,70 CPI: 0,84 6

7 INDICADORES DE CONTROL EP CP 7

8 8 D ESVÍOS Análisis de un desvío ocurrido

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

10 10 S OLUCIÓN ELEGIDA

11 11 SOLUCION ELEGIDA Lenguaje: ASP.NET - Framework 3.5 – C# Base de datos MS SQL Express 2005

12 12 L ECCIONES APRENDIDAS

13 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 14 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ó.

15 15 ANALIZAR EL CONTEXTO NOS PERMITIO TOMAR EL CAMINO CORRECTO 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 ( 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

16 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

17 17 L A 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.

18 18 E L 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.

19 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 20 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

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

24 24 H ERRAMIENTAS

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

26 26 D EMO

27 27 ?


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

Presentaciones similares


Anuncios Google