Desarrollo

De Telstock Wiki
Saltar a: navegación, buscar

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.


Alcance.

Abarca el proceso de implementación (codificación) del aplicativo.


Referencia.

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.

Descripción de Actividades

Ejecucion de ProyectoBD2w.png

Diagrama de Flujo

Formato

Documentos Ejecucion.png