Desarrollo
1. Propósito del procedimiento.
Elaborar el producto fundamental a través de la codificación de los módulos de programa definidos en la etapa de Análisis y Diseño.
Sumario
Alcance.
Abarca el proceso de implementación (codificación) del aplicativo.
Referencia.
- Políticas Generales de Desarrollo
- Estructura de Repositorio y Estatus de Nombre SVN
- Estándar de Proceso de Uso Aplicativo JIRA
- Liberación a QA
- Peer Review
Responsabilidades.
- Tramitador: Project Manager (PM), Product Owner (PO).
- Encargado: Team Leader (TL/LT)
- Ejecutor: Developer Team (DT), Team Leader (TL/LT), QA Team (QA), Coord TI
- Validador: QA Manager (QAM) y QA Team (QA), Cliente (CTE).
Definiciones.
- Scrum: Es un proceso de la Metodología Ágil que se usa para minimizar los riesgos durante la realización de un proyecto, pero de manera colaborativa.
- Codificación: Es el proceso por el cual la información de una fuente es convertida en símbolos para ser comunicada. Al codificar convertimos información de un formato o código a otro, con el propósito de estandarización, velocidad o de compresión
- Trazabilidad: Serie de procedimientos que permiten seguir el proceso de evolución de un producto en cada una de sus etapas.
Políticas y Lineamientos
1. Antes de iniciar con la fase de Codificación, los siguientes formatos deben contener la información necesaria hasta este punto:
TSK- Especificación de Diseño del Sistema
TSK- Diagramas
TSK- Plan de Pruebas de Sistema
TSK- Matriz de Pruebas del Sistema
TSK- Plan de Integración y Despliegue
2. Es estrictamente necesario, durante el proceso de desarrollo, realizar reuniones diarias de seguimiento (Daily).
Cada miembro del equipo de desarrollo es responsable de acudir puntualmente a los dailys. En caso que el PM se encuentre ausente, es responsabilidad del TL llevar a cabo el daily. Cualquier duda que se tenga respecto a la programación de un daily en específico debe ser aclarado directamente con el PM, ya sea en persona o por el canal de Slack destinado al proyecto.
3. Todas las actividades programadas para cada desarrollador, deberán ser actualizadas diariamente en el JIRA.
4. Es obligatorio estructurar las pruebas unitarias y de integración por parte del equipo de desarrolladores antes de notificar al QAM que puede dar inicio a las pruebas.
5. En caso de presentarse dudas o temas omitidos por parte del equipo de desarrollo, deberán informarse de forma inmediata a PM y PO, para resolverlas sin afectar tiempos de desarrollo. En caso de que existan, estas serán consideradas deuda técnica, ya que debieron desplegarse en la fase de análisis y diseño.
6.Cualquier falla Crítica que impida el desempeño del sistema se considera deuda técnica.
7.Cualquier falla técnica o de mejores prácticas será considerada deuda técnica, así como cualquier regla de negocio que NO cumpla con lo estipulado en la fase de análisis y diseño.
8.Fallas superficiales, faltas de ortografía, o error de UI/UX que SI permita trabajar y usar el sistema, serán enviadas a Back Log, así como cualquier regla de negocio o cambio de flujo que NO este estipulado en la fase de análisis y desarrollo. IMPORTANTE: el tiempo que se ocupe para adicionar estos nuevos flujos deberá ser cotizado de nuestra parte y ser cubierto por el cliente.