Descripción general del proceso y procedimientos de desarrollo

Este documento ofrecerá una visión general de los Procesos y Procedimientos de Desarrollo de Leading2Lean. Este proceso describe las responsabilidades, políticas y procedimientos que Leading2Lean debe seguir al realizar cambios en el servicio de producción y la infraestructura. Todos los empleados deben seguir esta política.

El Equipo de Tecnología de Leading2Lean tiene la tarea de proporcionar una infraestructura de TI estable y confiable para nuestros clientes. El propósito del Proceso de Desarrollo es minimizar las interrupciones del servicio en nuestro entorno de centro de datos y promover la disponibilidad e integridad del sistema. El Director Técnico (CTO) es responsable de mantener y actualizar el Proceso y los Procedimientos de Desarrollo según sea necesario. Este proceso se rige además por controles organizativos definidos como parte de nuestro programa de cumplimiento AICPA SOC 2 Tipo 2. Estos controles son auditados anualmente por nuestro auditor externo.

El proceso de desarrollo comienza cuando un desarrollador revisa el ticket, coordina con sus colegas respecto a la arquitectura y el diseño, escribe el código, recibe comentarios del equipo de Control de Calidad y, finalmente, lanza el software a los clientes. 

Alcance

Este documento define el ciclo de vida de las solicitudes de funciones y los errores. También describe los procesos y procedimientos utilizados para garantizar que se realicen las pruebas y validaciones adecuadas para cada lanzamiento. Este documento no describe el Proceso de Gestión de Cambios definido en nuestra Descripción general de la política de control de cambios.

Definiciones

Lista de pendientes: Una colección de errores y funciones cuyo desarrollo no ha comenzado. La Lista de pendientes es donde residen todos los tickets de menor prioridad. 

Error: Una función que no está funcionando como se esperaba. Los errores pueden variar de no graves a extremadamente graves. La lista de Errores es donde residen todos los errores de menor prioridad. Los tickets se colocan en la lista de Errores durante la reunión de clasificación. Los tickets se asignan a los miembros del equipo de desarrollo desde la lista de Errores.

Función o mejora: Comportamiento que no se ha desarrollado para el software. Esto puede ser una modificación de la funcionalidad existente o la creación de nueva funcionalidad.

Proyecto o épica: Una colección de errores y funciones. Los proyectos se gestionan en la Hoja de ruta. 

Hoja de ruta: Una colección de proyectos. La Hoja de ruta es el tablero de planificación para proyectos grandes. La Hoja de ruta impulsa el desarrollo de nuevas funciones, grandes y pequeñas. 

Triaje: Recopilación de nuevos tickets. La lista de Triaje es donde se crean todos los tickets nuevos. El equipo de Triaje colocará los tickets en la lista de Errores, la Hoja de ruta o el Backlog.

Descripción general

Hay 3 fases principales para cada ticket de desarrollo: 1. Planificación, 2. Desarrollo y 3. Pruebas de aseguramiento de la Calidad. Cada fase se analizará a continuación.

Planificación

Utilizamos un enfoque de triaje multidisciplinario para el proceso de planificación. Nuestros equipos de Soporte, Desarrollo y Calidad se reúnen periódicamente para una Reunión de Triaje con el fin de evaluar nuevos problemas, solicitudes de funciones y mejoras. Según la gravedad, estos problemas pueden activar un ciclo de respuesta escalada de interrupción/reparación para restaurar el servicio en caso de elementos de alta Prioridad o representar una degradación del servicio. De lo contrario, se les asigna una Prioridad inicial y se envían a nuestro Equipo de Producto para una planificación, priorización y programación adicionales.

Las funciones suelen planificarse con la participación de un pequeño número de personas.  Esto puede incluir miembros del Equipo de Producto, expertos en la materia, clientes, etc. Esto está dirigido por nuestro equipo de gestión de productos.

La mayoría de las solicitudes de funciones se analizarán durante la reunión de Planificación de la Hoja de ruta. Durante esta reunión, se analizarán los proyectos y las solicitudes de funciones escaladas. Los proyectos se priorizarán frente a otros proyectos, y las solicitudes de funciones se revisarán y trasladarán al backlog. Las solicitudes de funciones pueden vincularse a un proyecto de la hoja de ruta.

Desarrollo

Una vez completado el proceso de planificación, este trabajo se asigna al equipo de Desarrollo. El equipo de Desarrollo cuenta con su propio conjunto de entornos de desarrollo que es un espejo de nuestro entorno de Producción. Esta es una parte esencial de nuestro programa de Calidad. En cada etapa de nuestro ciclo de vida de desarrollo (Desarrollo, Control de Calidad, Preparación y Producción) mantenemos una Infraestructura separada para garantizar que cualquier trabajo completado se pruebe y verifique adecuadamente antes de ingresar a nuestro entorno de Producción.

Empleamos un conjunto completo de herramientas de desarrollo estándar de la industria diseñadas para el control de versiones, las pruebas automatizadas, el análisis estático del código y la limpieza del código. Estas herramientas proporcionan retroalimentación temprana y frecuente al desarrollador para garantizar la mejor calidad de código posible. También ayudan a mantener una separación adecuada de las ramas de desarrollo para evitar la contaminación cruzada entre desarrolladores que trabajan en diferentes proyectos, tareas y elementos de la base de código. Estas herramientas proporcionan un método estandarizado para las revisiones de código entre pares y los procesos de aprobación, con el fin de garantizar que cualquier código listo para las pruebas de Calidad haya superado todas las comprobaciones automatizadas de pruebas y validación.

Nuestros desarrolladores se comunican directamente con el equipo de soporte, el equipo de producto u otros desarrolladores cuando surgen preguntas sobre cómo implementar un ticket. Todos los cambios en la interfaz de usuario requieren la aprobación del equipo de producto. Dado que los cambios en la interfaz de usuario afectan a los clientes y pueden requerir Entrenamiento, trabajamos con los clientes, el equipo de soporte y el equipo de producto para garantizar que se tenga el cuidado adecuado al diseñar cualquier cambio en la interfaz de usuario, minimizando así el impacto en los clientes. Todos los cambios en la interfaz de usuario también son revisados por nuestro equipo de soporte durante la fase de pruebas de Calidad para validar que exista la funcionalidad adecuada y que los clientes reciban las Notificaciones y el Entrenamiento correspondientes.

Los desarrolladores deben ejecutar correctamente nuestro conjunto de pruebas automatizadas con cualquier cambio como parte de sus procedimientos operativos normales. Una vez que el ticket supera estas pruebas automatizadas, está listo para ser revisado por alguien distinto del desarrollador. Este evento permite a los miembros clave del equipo saber que es momento de proporcionar comentarios y también indica que el ticket está cada vez más cerca de su lanzamiento.

Todo el código es revisado por otro desarrollador antes de ser enviado al equipo de QA. Esto ayuda a garantizar que más de una persona conozca y comprenda qué se está cambiando y por qué. El propósito de una revisión de código debe ser reflexionar sobre el objetivo general de los cambios, revisar el código en busca de errores simples, analizarlo para detectar ineficiencias, solicitar aclaraciones cuando algo no parezca correcto y tratar de mantener la coherencia con los estándares de codificación y las mejores prácticas. En ocasiones, el desarrollador original refactorizará el código debido a los comentarios recibidos durante la fase de pruebas. Si esto da lugar a una cantidad significativa de cambios en el código, se realiza una revisión adicional. Cuando el consenso de la revisión del código se registra y documenta, el código está listo para ser enviado al equipo de QA

Pruebas de Calidad

Una vez que el conjunto de pruebas automatizadas se ha completado correctamente sin errores y la revisión del código se ha completado satisfactoriamente, el equipo de QA puede comenzar el proceso de pruebas de Calidad.

Las dos actividades principales relacionadas con el proceso de pruebas son la ejecución de scripts de pruebas automatizadas y las pruebas manuales. L2L cuenta con un conjunto de casos de pruebas de interfaz de usuario y unitarias que se ejecutan desde la línea de comandos. También existe un proceso de linting que se ejecuta sobre el código para verificar errores básicos de programación. Todos los desarrolladores deben ejecutar tanto el conjunto de pruebas como el proceso de linting antes de enviar su código para revisión. El equipo de QA realiza su propia revisión de los resultados del conjunto de pruebas automatizadas después de implementar el código en el entorno de pruebas de QA. Esto garantiza que tengamos un entorno de pruebas limpio para evaluar la capacidad de la actualización del código para funcionar según lo diseñado y de acuerdo con nuestro estándar de Calidad.

El equipo de QA coordinará las pruebas manuales del código para garantizar una Calidad adicional. Los comentarios del equipo de QA se incorporarán al ticket de desarrollo. A menudo, será necesario refactorizar y actualizar el código antes de que QA otorgue su aprobación. QA indicará que el código está listo para fusionarse al aprobar la solicitud de extracción. QA fusionará el código en la base de código principal una vez que todo haya sido aprobado. Esto garantiza que los desarrolladores no puedan fusionar código en nuestra base de código principal y omitir el proceso de QA.

Durante la fase de pruebas de aseguramiento de la Calidad, el equipo de QA también utilizará a miembros del equipo de soporte y al cliente para realizar pruebas de aceptación del usuario. Estas pruebas son vitales para garantizar que los cambios en el código sean utilizables, satisfagan las necesidades de los clientes y cumplan con las regulaciones y requisitos de la industria.

Proceso de Control de Cambios e Implementación en Producción

Para garantizar que cualquier cambio en nuestro entorno de Producción siga un proceso estándar, hemos implementado un Proceso de Gestión de Cambios, tal como se define en nuestra Descripción general de la Política de Control de Cambios. Esto garantiza que contemos con los controles y equilibrios adecuados en la organización para garantizar la Calidad, la Seguridad y la disponibilidad del entorno de Producción. Para obtener más información sobre este proceso, consulte el enlace anterior.

Es importante señalar que, como parte del proceso de control de cambios, L2L utiliza un script de implementación automatizada para liberar el software del repositorio de código a los servidores de los clientes. En ningún momento los empleados actualizan manualmente el entorno de Producción. Este sistema automatizado crea un registro de auditoría para cada nueva versión o implementación y verifica que existan las aprobaciones correspondientes. Una vez hecho esto, se permitirá que los scripts de lanzamiento actualicen los servidores de Producción. Este script automatizado también proporciona una notificación interna de la empresa sobre las implementaciones. Una vez completada la implementación, este sistema automatizado también realiza "pruebas de humo" para validar que la implementación se haya realizado correctamente y que el entorno de Producción funcione adecuadamente.

Reunión retrospectiva

En caso de que el código publicado vuelva a generar un problema antiguo o haga que el sistema emita una alerta, se llevará a cabo una reunión retrospectiva, también conocida como post mortem. El propósito de la reunión será recopilar los hechos relacionados con la publicación del código defectuoso, debatir formas de evitar que ocurran eventos similares en el futuro, asignar tareas relacionadas con la prevención de eventos futuros y educar al equipo sobre el incidente. Estas reuniones deben celebrarse dentro de las 36 horas posteriores al evento y deben involucrar a tantos desarrolladores y miembros del equipo de aseguramiento de la Calidad como sea posible, con fines de análisis de la causa raíz y Entrenamiento. 

Notificación al cliente

Las notificaciones a los clientes pueden ocurrir en varios momentos durante este proceso. A menudo se consulta a los clientes durante las fases de planificación, desarrollo y control de Calidad, así como una vez que se publica el código. El cliente será notificado mediante los siguientes métodos:

• Contacto personal / Reuniones programadas. Los clientes involucrados en proyectos de desarrollo específicos pueden ser invitados a asistir a reuniones periódicas de actualización para revisar los planes, diseños y el estado del proyecto.
• Correo electrónico personal a los clientes. Todos los tickets de soporte originados se actualizarán informando al cliente que el cambio se ha publicado en los servidores de Producción, y el ticket se cerrará. Si no se creó un ticket de soporte, un representante de soporte puede contactar directamente al cliente. Si solo un cliente se vio afectado por un cambio, es posible que no se utilicen otras formas de notificación.
• Registro de cambios. Todos los cambios que afecten a los clientes incluirán un registro de cambios. Esto incluye correcciones de errores, actualizaciones menores y solicitudes de funciones. Cuando un cambio solo afectó a un único cliente y el impacto fue menor, y si se contactó directamente con el cliente, es posible que no se agregue un registro de cambios. Los clientes pueden acceder al registro de cambios desde el menú Soporte de la aplicación.
• Correo electrónico masivo. Se enviará un correo electrónico a todos los administradores para todos los cambios importantes en la aplicación. Los correos electrónicos masivos se utilizan principalmente para anuncios de productos y grandes mejoras de la interfaz de usuario, pero pueden utilizarse en otros escenarios.
• Notificaciones dentro de la aplicación pueden utilizarse para cambios que generen impacto.