¿Cómo una empresa típica de desarrollo de software mantiene registros de los requisitos del cliente? Por ejemplo:
A) Un día, el cliente nos pidió que agregáramos un código de seguimiento a su sitio web.
B) Otro día, el mismo cliente nos pidió que agregáramos un código diferente pero el mismo código de proveedor en una página separada. Este código no funcionará sin el código de seguimiento anterior A).
Después de unos meses, el mismo cliente nos pidió que actualizáramos el código de seguimiento del punto A). En esta situación, si los desarrolladores toman medidas para actualizar el punto A), entonces el punto B) causará el problema y nadie lo sabrá, hasta que cause algún problema.
Dado este ejemplo, ¿puede decirme cómo una gran organización maneja este tipo de situaciones? ¿Están esperando que aparezcan errores en la página?
La dependencia debería haberse capturado en los criterios de aceptación : cuando se escribe la historia B, debería haberse vinculado de nuevo a la historia A. Y se debería haber escrito un criterio de aceptación para capturar eso.
La prueba unitaria debería romperse : si bien no todos los equipos Agile pueden estar escribiendo pruebas unitarias, Agile intenta mejorar las prácticas de ingeniería. El desarrollo dirigido por pruebas (TDD) es una práctica clave de la programación extrema.
Los equipos de desarrollo ágiles están activamente involucrados en comprender por qué se necesita una historia : no estoy seguro de si esto es típico. Sin embargo, algunos de los equipos de desarrollo de Waterfall que he visto están más centrados en ejecutar lo que pide el cliente. El enfoque parece ser que si el cliente lo quiere y está dispuesto a pagar por él, puede tenerlo. Por otro lado, los equipos de desarrollo Agile trabajan mano a mano con el propietario del producto para escribir historias de usuarios y criterios de aceptación para alcanzar los objetivos comerciales acordados en común. Por lo tanto, tienden a desafiar lo que quiere un Product Owner si no tiene sentido.
En general, Agile tiene retrospectivas frecuentes. Incluso si algunos de estos tipos de errores se colaron en la producción, deberían salir a la superficie en una retrospectiva y las oportunidades están disponibles para generar mejoras prácticas en los procesos.
Lo que necesita es un control de cambios formal.
Comienza capturando el requisito en una solicitud de cambio. Esto debe detallar todo lo que el cliente quiere cambiar. Si el cambio es significativo, también puede requerir el uso de una Especificación de requisitos por separado, pero eso aún se mencionaría en la Solicitud de cambio.
Una vez que se ha enviado al proveedor, el proveedor debe evaluar el costo y el impacto de realizar el cambio. Por lo general, la solicitud de cambio haría rondas en varios departamentos/equipos conectados, como Desarrollo, Pruebas, Hardware/Infraestructura, MI, etc. Cada equipo puede evaluar el impacto en su área de realizar el cambio. Los desarrolladores deben codificar el cambio. , los evaluadores deben escribir scripts de prueba y ejecutar pruebas de sistema e integración, MI debe averiguar si el cambio afecta una fuente de almacenamiento de datos y los informes posteriores y estimar el tiempo para cambiar las fuentes y los informes, etc.
Cuando cada equipo haya evaluado el impacto (los desarrolladores recogerían los problemas de regresión) y los costos en términos del esfuerzo de implementación, los costos y el impacto se analizarían con el cliente en un Tablero de cambios. Si el cliente acepta los costos y los impactos, se permite programar el cambio en una versión.
Si opera un proceso de desarrollo Agile, no estoy seguro de que esto se aplique, pero ciertamente es la forma en que hacemos las cosas en un entorno de cascada controlado.
Una forma de capturar los requisitos es ponerlos en un documento (word/pdf) con tantos detalles como sea posible. Mencione los requisitos establecidos, si es necesario, proporcione un diagrama de estructura alámbrica y también indique sus suposiciones en los requisitos. Y tomar una firma por escrito del usuario/cliente.
Por lo general, dichos documentos de requisitos deben compartirse en un portal común (sharepoint, jira) donde su equipo de TI y los usuarios tendrían acceso.
Este mecanismo de aprobación y uso compartido asegurará que el cliente haya aceptado el requisito y usted puede cobrar dinero adicional por cualquier cambio en los requisitos.
En el mejor de los casos, ha documentado todas las capacidades comerciales que el cliente desea en el contrato. Esto tiene varias ventajas para ambas partes:
A partir de las capacidades comerciales documentadas en el contrato, puede trabajar en el desarrollo de documentos de requisitos por ViSu, pero primero debe tener el contrato vigente para ayudar a protegerse contra el aumento del alcance.
Usamos un formulario llamado formulario de solicitud de modificación para rastrear la solicitud de cambio del Cliente. A cada solicitud se le asigna un número único, área de cambio, etc.
El cliente completa la solicitud de cambio en el formulario de solicitud de modificación. Evaluamos la solicitud de cambio, preparamos un documento de entendimiento y lo devolvemos al usuario para su confirmación. Con la confirmación del usuario iniciamos el proceso de cambio.
Almacenamos esta solicitud de modificación y el documento de comprensión en un sistema desarrollado internamente y agregamos un número de solicitud de modificación único al código para que el equipo pueda consultarlo fácilmente en el futuro.
El control de cambios no ayudará si no tiene una documentación sólida para empezar.
Sugeriría buscar documentos de requisitos comerciales (BRD) y especificaciones de requisitos de sistemas (SRS) como referencia.
Sí, los requisitos del cliente deben documentarse y rastrearse. Cualquier solicitud de cambio o actualización debe traducirse en cambiar los documentos originales para que coincidan con los nuevos requisitos y asegurarse de que se hayan analizado todos los impactos.
MCW
FR ESTRELLA