Recomendaciones para formalizar el desarrollo y la administración de software
Se aplica a esta recomendación de lista de comprobación de excelencia operativa del marco de trabajo bien diseñado de Azure:
| OE:03 | Formalice los procesos de ideación y planeamiento de software. Use como base los estándares establecidos del sector y de la organización. Use un trabajo pendiente común, priorizado y especificaciones suficientemente detalladas. En función de los resultados, impulse las mejoras continuas en el proceso de planificación. |
|---|
En esta guía se describen las recomendaciones para administrar prácticas de desarrollo de software de acuerdo con los estándares establecidos. La capacidad de su equipo para producir software de alta calidad se basa en un enfoque estructurado y colaborativo para la planificación del desarrollo. Los propietarios y administradores de productos deben ser capaces de comprender y explicar claramente a las partes interesadas el trabajo que están realizando los desarrolladores en cualquier momento del ciclo de desarrollo. Por otro lado, los desarrolladores deben comprender los objetivos del ciclo de desarrollo a través de características bien redactadas, casos de usuario y criterios de aceptación. Los estándares establecidos definen cómo se deben realizar las prácticas de desarrollo y permitir que el equipo de cargas de trabajo colabore de forma eficaz, lo que reduce el riesgo de confusión sobre los objetivos y las expectativas.
Estrategias de diseño principales
Formalice las prácticas de desarrollo de software para ayudar a garantizar que los propietarios de productos, los administradores de proyectos y los desarrolladores comprendan los objetivos de cada sprint y proporcionen una calidad coherente a las partes interesadas. Para revisar las instrucciones sobre las prácticas de desarrollo, consulte la guía de integración continua.
Establecimiento de estándares de colaboración y comunicación
Colaboración: el proceso de definición de los cambios propuestos en la carga de trabajo debe ser un esfuerzo colaborativo. La mayoría de los cambios en la carga de trabajo afectarán a varias funciones o componentes, por lo que la implicación de tantos miembros del equipo de carga de trabajo como sea posible le ayudará a garantizar que no se pierdan consideraciones importantes y que todos conozcan el impacto en su dominio determinado. La colaboración también ayuda a definir claramente el ámbito de un cambio y a dividir las tareas necesarias para realizar el cambio en elementos de trabajo bien definidos, ya que un grupo más grande con experiencia en todos los dominios podrá proporcionar estimaciones respaldadas por la experiencia para el esfuerzo necesario.
Comunicación: defina los protocolos estándar para los propietarios de productos y los administradores de proyectos para promover próximas versiones interna y externamente. Por ejemplo, podría establecer un estándar para las comunicaciones a terceros sobre las próximas versiones. El estándar podría dictar que la comunicación se debe enviar dos semanas antes de la versión y un aviso debe enviarse 24 horas antes de la versión.
Revisión: realice periódicamente auditorías internas de las prácticas de desarrollo a través de retrospectivas del ciclo de desarrollo y postmortems. La reflexión del proceso debe ser culpable y debe centrarse en el aprendizaje que se puede aplicar como mejoras. Asegúrese de que el equipo refleja la eficacia del caso del usuario y las tareas en la definición de las tareas necesarias y en la precisión de las estimaciones de tiempo.
Informes: normalice los informes de las partes interesadas que proporcionan métricas útiles centradas en el cambio. Centrarse en el cambio le permite realizar un seguimiento de la aceleración y la desaceleración del producto. Las métricas útiles pueden incluir cambios en:
Tasa de crecimiento mensual de adopción.
Rendimiento.
Tiempo de entrenamiento.
Frecuencia de incidentes.
Los informes no se deben usar como una herramienta para evaluar el trabajo de las personas, por lo que evite métricas como puntos de historia o líneas de código para cada ingeniero.
Elección de herramientas estándar del sector
Use herramientas y procesos establecidos, probados en el sector, como agile, Scrum y paneles Kanban. Desarrollar sus propias herramientas y procesos es una tarea importante, tardando tiempo y ciclos de desarrollo que, de lo contrario, podrían dedicarse a la carga de trabajo. La mayoría de los ingenieros y propietarios de productos experimentados de DevOps están familiarizados con estos tipos de herramientas y procesos, por lo que la curva de aprendizaje para adoptarlas debe ser mínima. Del mismo modo, el proceso de incorporación de nuevos empleados también se beneficiará del uso de herramientas y procesos estándar, ya que es probable que tengan un grado de exposición a las mismas herramientas y procesos ya.
Inconveniente: la metodología ágil puede ser demasiado estricta si es excesivamente prescriptiva. Esfuércese por un equilibrio entre los estándares y la innovación bien definidos.
Adopción de un estándar para capturar escenarios de usuario final
Casos de usuario: normalice una plantilla para casos de usuario. Asegúrese de que cada caso de usuario es una unidad discreta de trabajo, escrita desde la perspectiva del usuario final. Los casos de usuario bien escritos deben tener las siguientes características:
Cada caso de usuario debe ser totalmente independiente entre sí. Mantener los casos de usuario independientes entre sí evita cualquier confusión con el trabajo superpuesto y ayuda al equipo a comprender si el trabajo en un caso de usuario determinado se basa en el trabajo en cualquier otro, lo que ayuda a programar y priorizar.
Cada caso de usuario es negociable. Las perspectivas de los miembros del equipo del usuario final y de la carga de trabajo son esenciales para capturar casos de usuario realistas que se pueden lograr durante un breve período de tiempo.
Los casos de usuario son valiosos para el usuario final. Al escribir historias de usuario desde la perspectiva del usuario final, se capturan los cambios que les interesan ver y que agregarán valor a su experiencia. Mantener este enfoque a medida que el caso del usuario se divide en elementos de trabajo ayuda a garantizar que cada implementación proporciona una experiencia mejorada.
El esfuerzo necesario para un caso de usuario es estimable con un alto grado de confianza. Sin poder tener una aproximación cercana de las horas necesarias para un caso de usuario determinado, la planificación será difícil y la posibilidad de que falten plazos aumente, lo que podría provocar efectos en cascada en otros trabajos planeados.
Los casos de usuario bien escritos son pequeños, por lo que se pueden completar en unas pocas semanas. Los casos con ámbito más pequeños ayudan a mantenerlos estimables y manejables y ayudan a mantener los elementos de trabajo factibles.
Los casos de usuario deben ser probables. Sin poder probar que se ha entregado una característica, el usuario final no puede tener confianza en que se ha logrado el objetivo. Incluso si no se ha escrito una prueba para un caso de usuario determinado, debe comprender claramente cómo se puede desarrollar una prueba para demostrar la entrega de la característica.
Criterios de aceptación: normalice una plantilla para los criterios de aceptación. Asegúrese de que los criterios de aceptación se relacionan específicamente con el caso del usuario y pueden demostrarse inequívocamente mediante una o varias pruebas de aceptación.
Estandarizar los procedimientos de implementación
Implementación: planee el uso de implementaciones pequeñas e iterativas frecuentes en lugar de implementaciones poco frecuentes. El uso de este enfoque ayudará a mantener los casos de usuario y los elementos de trabajo administrables desde el punto de vista de la administración de proyectos y reducir el riesgo de problemas a gran escala cuando se produzca un error en las implementaciones.
Términos: normalice la definición de ciclos de desarrollo terminados para ayudar a garantizar que las funciones auxiliares, incluidas las pruebas, la documentación y las características de accesibilidad, se completen correctamente.
Seguimiento: asegúrese de que el proceso de desarrollo es rastreable. Debe realizar un seguimiento claro del estado de la carga de trabajo de producción y el código asociado a las pruebas de control de calidad, los criterios de aceptación, los casos de usuario y las características. El seguimiento detallado también podría ser un requisito normativo en algunos casos, como la atención sanitaria, por ejemplo.
Facilitación de Azure
Azure Boards es un servicio basado en web que permite a los equipos planear, realizar un seguimiento y analizar el trabajo en todo el proceso de desarrollo. Es adecuado para prácticas de desarrollo basadas en Agile.
GitHub Projects es una herramienta de administración de proyectos personalizable que puede organizar proyectos e integrarse mediante problemas y solicitudes de incorporación de cambios en GitHub.
Vínculos relacionados
Vínculos de la comunidad
Lista de comprobación de excelencia operativa
Consulte el conjunto completo de recomendaciones.