Process improvement proposal

[anjelysleal]

Propuesta Manejo de Procesos COBUILDLAB.docx

Incorporate item by item in the project documentation, weekly.

Follow up at retrospective meetings.

Propuesta Manejo de Procesos ¿A dónde vamos? ¿cómo debe ser el proceso? ¿Qué rol debe encargarse de qué? Enfoquémonos en varios puntos importantes a incorporar/mejorar en el proceso actual de la empresa:

• [ ] Realizar documento de Especificaciones/documento funcional, que detalla todas las funcionalidades que debe tener el software. Este documento no es el documento de Requerimientos de usuario original que envía el cliente sino el que nace de aquel con el consentimiento del cliente y el equipo de proyecto. Debemos tener un documento en donde agreguemos las cosas extras que se hacen a las especificaciones iniciales. Al final eso nos servirá para definir qué va a recibir el cliente cuando el proyecto termine​, es decir, cómo va a funcionar esa aplicación, justificar retrasos en caso de haberlos y cobrar más.

La persona encargada de crear este documento y de pasarlo a los Desarrolladores y Testers es el Producto Owner (o Analista Funcional). ​Y algo muy, muy importante, que SIEMPRE tenemos que tener en cuenta, es que es nuestro documento de referencia​. ¿Qué significa esto? Que cada vez que desarrollamos y probamos un software, no podemos hacer lo que queramos, sino que tenemos que garantizar que el software cumpla con los puntos detallados en la Especificación. Realizar documentación referente a diseños de módulos/pantallas, flujogramas de datos y selección de tecnologías a implementar para desarrollar el proyecto. Esta información es generada por el Cliente, Producto Owner, PM en constante comunicación y es donde se establece la estructura del proyecto. Realizar documento Scope del proyecto, en donde se define la integración, alcance, tiempo, coste, calidad, recursos, comunicaciones y riesgos. Generalmente esta actividad es realizada por el Producto Owner en conjunto con el PM. Definir Milestones del proyecto apoyados con la Documentación técnica del proveedor del proyecto. En caso de que el cliente posea esta información debe ser solicitada por el Producto Owner o PM y discutida con todo el equipo. Incorporación del proceso de calidad. Definición de especificación, diseño de casos de pruebas, ejecución de pruebas, reporte de bugs, verificación de fixes (re-testing). Creación de demos. Interviene el PM y QA. Ejecución de pruebas: manuales y automatizadas, con las herramientas necesarias para cada tipo de aplicación. En nuestro caso hemos decidido iniciar con Cypress para la automatización. Actividad estrictamente de los QA.

Realizar feedback con el Cliente, mínimo semanalmente, manteniendo el documento de feedback actualizado la mayor parte del tiempo. PM y QA. Realizar documento de Cierre de Proyecto, donde se incorporen los casos de pruebas usados, cantidad de pruebas realizadas, cantidad estimada de bugs encontrados y solucionados. Conclusión de si el software está apto y aprobado para su uso. Actividad de QAs y PM, con revisión de PO.

Realizar clasificación de proyectos activos, en base a cantidad de funcionalidades, módulos y si es o no multiplataforma (web, móvil, escritorio) para la rotación del personal de QA. Así se garantiza una distribución de carga entre cada recurso y aumentar la calidad del producto. Para esto se necesita mantener toda la documentación al día, incluyendo la nombrada anteriormente y el historial de demos enviados a los clientes, de modo que puedan servir de onboarding al QA que se esté incorporando en cualquier punto del desarrollo del proyecto. Esta actividad se sugiere sea realizada entre el PO, todos los PM y QA líder.

Se requiere de parte del Cliente: Documento de Requerimientos de usuario: En estos nos vamos a basar y deben estar aprobados previamente. Documentación Técnica del Proveedor: Describe las condiciones en las que debe funcionar el sistema, ej. Manuales de configuración, de administrador, planos del sistema, flujo de datos. Apoyo para la realización del documento de Especificaciones/documento funcional. Apoyo para la realización del diseño de módulos/pantallas, flujogramas de datos y selección de tecnologías a implementar. Aprobación del Scope del proyecto. Aprobación de Milestones del proyecto. Feedback constantes de las entregas.

Se requiere por parte de la empresa: Realizar documento de Especificaciones/documento funcional. Realizar documentación referente a diseños de módulos/pantallas, flujogramas de datos y selección de tecnologías a implementar. Scope del proyecto. Milestones del proyecto. Aplicar pruebas y garantizar la calidad del software. Cumplir con las entregas.

Mantener feedback con el cliente. Realizar documento de cierre o certificación del proyecto.

Se sugiere rotación o incorporación de QAs a proyectos en donde se necesite apoyo, una vez se tenga organizada la carpeta del proyecto con toda la documentación necesaria.

[alacret]

• User Roles or Permissions
• Navigation Diagram
• Modules Diagram
• User Stories
• Initial Data model
• Business Rules
• UI and Screens
• INTRO VIDEO

[MetalMagno]

Documentacion requerida de acuerdo al nivel de autonomia que tiene cobuild dentro del proyecto: Disenos User flows Requerimientos

[CesarDav]

• Este documento tiene que ser creado entre en PM y el Líder técnico del proyecto.
• Este documento debería ser creado poco a poco, a medida que el proyecto va definiendo las especificaciones.
• El documento inicialmente debería contar con los siguientes elementos:
  • Reglas de Negocios
  • Al menos algunas pantallas para tener una base de donde empezar a maquetar.
  • Al menos algunas historias de usuarios