Share via

Recomendaciones para formalizar el desarrollo y la administración de software

  • Artículo

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:03 Formalizar procesos de ideación y planificación de software. Se basa en los estándares establecidos del sector y de la organización. Use un trabajo pendiente común, con prioridad y especificaciones suficientemente detalladas. En función de los resultados, impulse las mejoras continuas en el proceso de planeamiento.

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 articular claramente a las partes interesadas el trabajo que realizan los desarrolladores en cualquier momento en un ciclo de desarrollo. Por el contrario, los desarrolladores deben comprender los objetivos del ciclo de desarrollo a través de características bien escritas, casos de usuario y criterios de aceptación. Los estándares establecidos definen cómo se deben realizar las prácticas de desarrollo y permiten que el equipo de carga 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.

Estándares para el planeamiento del desarrollo

  • Colaboración: el proceso de definición de 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 ayudará a garantizar que no se pierdan las 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 mayor con experiencia en todos los dominios podrá proporcionar estimaciones respaldadas por la experiencia para el esfuerzo necesario.

  • Herramientas: use herramientas y procesos establecidos, probados por el sector, como los paneles Agile, Scrum y Kanban. Desarrollar sus propias herramientas y procesos es una empresa importante, lo que tarda 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 para nuevas contrataciones 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. Se esfuerza por un equilibrio entre los estándares y la innovación bien definidos.

  • Implementación: planee usar 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 produce un error en las implementaciones.

  • Términos: estandarizar 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.

  • 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 publicación y se debe enviar un aviso 24 horas antes de la publicación.

  • Casos de usuario: estandarizar una plantilla para casos de usuario. Asegúrese de que cada caso de usuario sea una unidad de trabajo discreta, 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 historias de usuario realistas que se pueden realizar 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 administrables y ayudan a mantener los elementos de trabajo factibles.

    • Los casos de usuario deben ser comprobables. 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 aún no se ha escrito una prueba para un caso de usuario determinado, debe haber una comprensión clara de cómo se puede desarrollar una prueba para demostrar la entrega de la característica.

  • Criterios de aceptación: estandarizar 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.

  • Seguimiento: asegúrese de que el proceso de desarrollo sea 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.

  • 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 inculpida 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: estandarizar informes para 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.

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 las 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.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de excelencia operativa