¿Qué aspecto tiene su definición de hecho si está practicando Scrum?
Depende, las definiciones más simples de hecho están en la línea de ‘ La historia no necesita más trabajo (por parte del equipo) ‘ o ‘ La función no le costará (al equipo) más tiempo / presupuesto / dinero ‘. La versión que elija debe reflejar la realidad de la métrica utilizada por el Propietario del producto para determinar el éxito.
La parte que a menudo se pierde es (el equipo), pero esto es importante. Un equipo Scrum está facultado para hacer lo que sea necesario para cumplir con los requisitos cambiantes, y eso incluye cambiar sus procesos. También incluye cambiar los requisitos, proporcionando retroalimentación temprana y continua al propietario del Producto. La evolución de los requisitos de esta manera incluye la evolución de los criterios de aceptación.
- ¿Cuál es el uso principal del lenguaje de programación Go? ¿Alguna compañía lo usa para construir su software? Si es así, ¿cuáles son algunos ejemplos?
- ¿Por qué la gente de tecnología se molesta en mudarse a Silicon Valley?
- ¿Cuáles son las opciones de back-end (como Parse, FireBase, PubNub, Layer, etc.) para el desarrollo móvil y las ventajas de cada una?
- ¿Cómo pueden los profesionales del software tomar una desintoxicación tecnológica?
- ¿Cuáles son algunas de las fallas más grandes debido a la mala calidad del código?
Con demasiada frecuencia veo definiciones largas y sin aliento de hecho creado durante el descubrimiento, que generalmente implica una larga lista de verificación de actividades, verificaciones y pruebas. Detallarlos puede atascar el proceso de descubrimiento. El primer objetivo debe ser conseguir algo, cualquier cosa hasta el final. Estas listas de verificación deben minimizarse al principio, agregarse cuando sea necesario y eliminarse de cualquier lista de verificación explícita por automatización en el CI.
Algunas actividades están fuera de la responsabilidad directa del equipo; auditorías de seguridad y accesibilidad, por ejemplo. Cuando estas actividades o procesos están fuera del control directo del equipo, deben excluirse de la definición de hecho.
Algunos gerentes y equipos consideran que los términos ‘calidad de producción’ y ‘hecho’ significan que el software está listo para su lanzamiento, con el supuesto de que esto significa que está listo para un lanzamiento en vivo. Igualmente puede ser una liberación para una actividad de vapor descendente; las auditorías de seguridad o accesibilidad mencionadas anteriormente. Si estas actividades actúan como puertas de enlace, utilice una nueva historia para avanzar a la siguiente etapa, no un elemento en una lista de verificación para la definición de hecho que evite que se complete la historia original.
El enfoque que defiendo es considerar que la definición de hecho es como el software y el proceso de desarrollo, todo esto debería evolucionar a medida que se acumulan los sprints.
Comience con la definición más simple posible que funcione, construya la definición de hecho cumpliendo con el requisito de aceptación de los artículos listos para sprint. Desarrolle su definición de una historia Sprint Ready de la misma manera, desde la definición más simple posible que funcione.
