Conclusiones Ciclo 4 - Uniandes-MISO4203-backup/artwork-201620-2 GitHub Wiki
Cada integrante del grupo realizó la encuesta para evaluar a sus compañeros y autovalorarse.
[Ver Análisis de resultado de Carlos Felipe Agudelo](Ver Análisis de resultado de Carlos Felipe Agudelo)
| Req | Estado | Dueño | % |
|---|---|---|---|
| R033: Artista, registrar obras | Implementado | Adriana Marcela Osorio F. | 100% |
| R034: Ver detalle de obra | Implementado | Carlos Felipe Agudelo | 100% |
| R035: Carrito de compras, agregar obras | Implementado | Juan Beltran | 100% |
| R036: Comprar obras de arte | Implementado | Juan Beltran | 100% |
| R038: Ver nuevas adquisiciones | Implementado | Luis Florez | 100% |
-
Costo de prevención: Corresponde al costo incurrido en promover la calidad del proyecto. Se midió determinando el tiempo requerido para completar las actividades relacionadas con la construcción de las pruebas de unidad y de servicios, adicionalmente el tiempo incurrido en diseño relacionado con manejo de estándares o definición de decisiones de arquitectura se incluyeron acá. Tiempo Total en Horas: 11.5
-
Costo de detección: Corresponde al costo del proceso de pruebas de la aplicación. Este costo se determinó por el tiempo requerido en realizar las pruebas funcionales de los requerimientos desarrollados, adicionalmente el tiempo que toma la revisión de pares en la implementación de requerimientos. Tiempo Total en Horas: 6
-
Costo de fallas internas: Corresponde al costo de corrección de fallas antes de liberar la versión. El costo se determinará tomando el tiempo adicional no contemplado en la planeación requerido para solucionar los errores encontrados en la revisión final de los requerimientos durante la integración del entregable final. También se tendrán en cuenta los tiempos requeridos para solucionar los problemas de calidad reportados por la herramienta de Sonar. Tiempo Total en Horas: 7
-
Costo de fallas externas: Corresponde al costo de corrección de errores después de haber liberado la versión. Se medirá tomando el tiempo adicional requerido para corregir los errores encontrados por el usuario final. También incluimos la deuda técnica pendiente reportada por Sonar al final del ciclo. Tiempo Total en Horas: 32
La productividad del equipo durante el ciclo 4 fue:
- Cada integrante tuvo una productividad de 3.75 PF/Semana
- Todo el equipo tuvo una productividad de 15 PF/semana
####Total del ciclo (4 semanas):
- Cada integrante tuvo una productividad de 15PF/ciclo
- Todo el equipo tuvo una productividad de 60PF/ciclo
Total de puntos funcionales 60.
Mas de: Seguimiento de las tareas en TeamWork.
Menos de: Poco animo en las reuniones.
Dejar de hacer: Software con pocas pruebas.
Seguir Haciendo: Trabajo a tiempo.
Empezar a hacer: Revisión por roles del funcionamiento de la aplicación.
Mas de: Pruebas de usabilidad.
Menos de: Uso de CSS de forma inconsistente o compleja.
Dejar de hacer: Adición de librerias que generen conflictos, especialmente en el front.
Seguir Haciendo: Pruebas unitarias, reuniones pequeñas de seguimiento, uso de teamwork para seguimiento de las tareas y commits frecuentes en github.
Empezar a hacer: Verificar la consistencia de los estilos de la interfaz grafica.
Mas de: Asignación equilibrada de requerimientos entre los integrantes del equipo.
Menos de: Incluir nuevas librerías sin validar la afectación global que pueda generar en la app.
Dejar de hacer: Entregar requerimientos sin hacer las suficientes pruebas a nivel de frontend, para identificar comportamientos inesperados.
Seguir Haciendo: Verificar la afectación en sonar cada vez que se incluye un nuevo requerimiento, e implementar inmediatamente las correcciones necesarias
Empezar a hacer: Pruebas de frontend con Selenium
Mas de: Técnicas para mejorar la usabilidad y experiencia de usuario.
Menos de: Registro inexacto del tiempo de las tareas.
Dejar de hacer: Subir implementación de requerimientos sin antes probarlos.
Seguir Haciendo: Mejorar la calidad del código con pruebas unitarias y correcciones de sonar.
Empezar a hacer: Tener en cuenta en la implementación la adaptación de la interfaz de usuario a dispositivos móviles (responsive).
- La asignación de tareas es mucho más efectiva si los integrantes participan de forma voluntaria y aportando sus comentarios.
- La variedad de conocimiento entre los integrantes de un grupo debe tenerse en cuenta en la asignación de tareas, para que se aproveche al máximo el potencial del equipo.
- La comunicación continua dentro de un grupo es muy importante, no solo para coordinar sino también para generar un sentido de unidad.
- Se deben definir roles específicos dentro del equipo, para que se tengan claras las responsabilidades de cada integrante.
- La planeación de un proyecto, para ser efectiva, debe considerar todas las actividades (entregables, reuniones, etc.) no solo el desarrollo.
- La estimación del esfuerzo para terminar un ciclo es importante para una buena ejecución.
- Ciclos pequeños y milestones ayudan mucho a guiar el desarrollo.
- Hay herramientas que ayudan bastante a organizar el desarrollo como Git, GitHub y Teamwork.
- Los postmortems permiten mejorar el proceso de desarrollo y el producto.
- La calidad del software siempre acarrea costos dentro de un proyecto, ya sean costos generados por desarrollar un producto de alta calidad o los costos generados por corregir defectos de un producto de mala calidad.