¿Es ágil la falta de requisitos funcionales?

Hoy en día todos quieren ser ágiles. En cada equipo con el que trabajé, la forma de ágil era diferente. Algunas cosas son comunes, como las paradas diarias o la planificación, pero otras partes varían significativamente.

En mi equipo actual hay un detalle que encuentro inquietante. Es la falta de requisitos funcionales. No solo no hay una forma escrita de expectativas, sino que también en las tareas se define vagamente lo que hay que hacer.

El objetivo del proyecto es reescribir el sistema antiguo utilizando nuevas tecnologías. El sistema antiguo tampoco tiene documentación razonable. Seguro que al día no existe uno. La descripción de los requisitos de los dueños de negocios es: hagámoslo en una nueva implementación de la misma manera que en la anterior. Parece razonable pero no lo es. El sistema antiguo es una especie de código de espagueti y la extracción de los requisitos comerciales es costoso. Parece que la situación afecta la planificación de manera negativa. Seguro que es propenso a errores y errores en la nueva implementación (omitiendo algunos detalles).

Por lo tanto, estoy pensando: ¿es realmente ágil no tener requisitos comerciales en caso de reescribir un sistema antiguo?

Si falta o no requisitos funcionales es ágil, es una receta para el desastre. No puede reconstruir un sistema cuando no sabe cómo funciona ese sistema.

Debe decirle al dueño del negocio que no tiene idea de cómo funciona el sistema anterior.

Su mejor opción es trabajar con el propietario de su negocio o con algunos usuarios experimentados para comprender los procesos comerciales en juego y desarrollar sus propias pruebas de aceptación. Si puede trabajar con algunos usuarios finales, puede recibir más comentarios sobre cómo funciona el sistema anterior.

De lo contrario, deberá realizar algunas pruebas exploratorias en un entorno que no sea de producción para reunir sus propios requisitos. Muchas veces, cuando el dueño de un negocio dice "hacer que funcione como el anterior", están limitados a tiempo y no pueden ayudarlo como debería hacerlo el dueño de un negocio. Necesita la experiencia de algunos usuarios experimentados, o una gran cantidad de pruebas manuales de su parte para comprender cómo funciona el sistema anterior.

Informe al propietario de la empresa que la falta de requisitos y comprensión del sistema antiguo aumentará en gran medida el tiempo que lleva reconstruirlo, aproximadamente el triple del tiempo o más. Ante el aumento de la línea de tiempo y el costo, el propietario del negocio le brindará la experiencia necesaria para reunir los requisitos más rápido o decidirá que la reescritura no es económicamente factible en este momento.

Obtendrá uno de los siguientes:

• Requisitos adecuados y un ciclo de desarrollo más rápido.
• Tiempo para reunir requisitos y reconstruir el software
• Un nuevo proyecto que no terminará siendo una marca negra en tu carrera

Agile no cambia la necesidad de requisitos funcionales, pero generalmente cambia la forma en que los reúne . La forma no ágil es que alguien pase por un proceso largo y luego le dé algún tipo de documento que contenga todos los requisitos para el sistema.

La forma ágil de reunir los requisitos es trabajar juntos para especificar los requisitos para un pequeño incremento del sistema, construirlo, luego obtener retroalimentación y hacer el siguiente incremento. En su situación en la que tiene problemas para que los dueños de negocios inicien el proceso, comenzaría por pasar medio día explorando la parte del antiguo sistema en el que desea trabajar a continuación, y generaría una lista de preguntas sobre los requisitos.

Luego, siéntese con los dueños de su negocio y hágales las preguntas. Algunas preguntas serán fáciles de responder, algunas son más fáciles de responder mirando el código, y algunas son difíciles de responder de cualquier manera. Divide las preguntas difíciles en partes cada vez más pequeñas hasta que encuentres algo que pueda responderse.

El objetivo es obtener una respuesta suficiente a sus preguntas para construir algo, obtener comentarios y reiniciar el proceso. Recuerde, cuanto más pequeños sean sus cambios y más corto sea su ciclo de retroalimentación, menos importante será si construye algo incorrecto.

La captura de requisitos es una parte esencial de cualquier proyecto de software (exitoso). Pero escribir una especificación de requisitos no lo es.

• Un enfoque centrado en la documentación puede terminar como un juego de susurros chinos: un experto en la materia expresa un requisito, un analista lo escribe, un desarrollador intenta escribir algo que cumpla con la descripción del analista, el usuario final está confundido porque el software no No resuelvan su problema.

  Las técnicas ágiles sugieren que los desarrolladores deben reunir los requisitos directamente de los expertos en la materia, generalmente los usuarios finales. Hay una variedad de técnicas para hacer esto, por ejemplo, hablando a través de un escenario de ejemplo con la PYME. Los desarrolladores son buenos para detectar casos límite y pedirle a la PYME que aclare cómo debe comportarse el software en ese caso límite.

• En lugar de reunir todos los requisitos por adelantado (y por lo tanto arriesgarse a grandes malentendidos), los equipos ágiles probablemente comenzarán con una pequeña porción de requisitos, construirán un prototipo y lo usarán para recopilar comentarios para la próxima iteración.

• A medida que la comprensión de los requisitos cambia con el tiempo, una especificación de requisitos estáticos quedará desactualizada. ¿Cómo se puede prevenir esto?

  Expresando requisitos como pruebas ejecutables. Resulta que la "especificación legible" y las "pruebas ejecutables" no son conceptos exclusivos, pero pueden terminar siendo el mismo documento. Por ejemplo, Pepino y otras ideas fuera del espacio BDD pueden ser muy útiles aquí.

En el caso de que esté reescribiendo un sistema antiguo, el sistema original puede ser una gran fuente de requisitos. ¿Pero qué aspectos son relevantes? ¿Se utilizan incluso sus funciones de nicho? ¿Qué errores se deben volver a implementar para la compatibilidad? Por lo general, no hay una solución alternativa para hablar con los usuarios finales.

Tener un sistema de trabajo por ahí también puede ser muy útil para probar el nuevo software, pero eso no está relacionado con ninguna inquietud ágil.

Tenga en cuenta que los proyectos de alcance fijo y tiempo fijo con plazos inminentes son la antítesis de ágil. El enfoque ágil normal es elegir una porción de funcionalidad y entregarla primero, luego iterar. Lo más importante se hace primero, lo menos importante después (o nunca). Si todo es importante y DEBE hacerse lo antes posible, entonces nada es importante y es poco probable que el proyecto entregue algo.

En su situación, la falta de requisitos no es una característica ágil, sino más bien un caso promedio de disfunción organizacional. Si desea que el proyecto tenga éxito, necesitará encontrar una manera de superar esta disfunción. Por ejemplo, insta al propietario de la empresa a que no escriba un documento de requisitos completo, sino que intente organizar una reunión en la que explique sus requisitos para la característica más importante. Puede ver el sistema antiguo para obtener más detalles. Luego implemente esa característica e itere.

Así es como lo hicimos. Hablamos con los dueños. Hablamos con los gerentes. Hablamos con los usuarios que hacen el trabajo. Lo que encontramos al sentarnos en el escritorio de un usuario y mirar (y hacer preguntas) fue increíblemente útil. Los gerentes sabían con qué usuarios deberíamos sentarnos.

Descubrimos que algunas partes del sistema funcionaban muy bien, y podíamos escribir fácilmente requisitos suficientes para comenzar a diseñar, codificar y probar casos, etc., pero otras partes tenían algunas soluciones desagradables que los usuarios en el piso estaban usando, que los gerentes y los propietarios no sabían. Para estas partes del sistema anterior, volvimos al negocio y hablamos sobre el flujo de trabajo y los procesos por un momento antes de que pudiéramos precisar cuáles deberían ser las tareas más pequeñas y así poder dividirlas en las unidades que nuestro método ágil quería.

Entonces, si bien Agile pudo despegar rápidamente en algunas partes del sistema, otras tuvieron que pensar un poco más y documentar antes de que pudiéramos comenzar.

¿Recopilando requisitos en un marco ágil y nadie ha mencionado Historias de usuarios? Una historia de usuario es esencialmente una definición de alto nivel de lo que el software debería ser capaz de hacer. Por lo general, cualquier comentario o solicitud que provenga de la empresa o del usuario final puede escribirse como una historia de usuario. ... Puede pensar en los criterios de aceptación como los requisitos funcionales que respaldan una historia de usuario.

Esta pregunta sugiere lo que salió mal con el movimiento ágil. No es culpa de la persona que hace la pregunta; Caigo en esta trampa todo el tiempo porque años de vida corporativa me entrenaron para hacerlo.

La trampa de la que estoy hablando es pensar que hay una forma ágil prescrita y correcta de hacer las cosas. Esto podría ser porque la gente piensa que Agile existe. No puedes hacer Agile más de lo que puedes hacer Pragmatic.

No tener "especificaciones funcionales" o lo que sea, suena preocupante, pero podría no serlo. ¿Cuántos detalles necesitas para comenzar? La seguridad y el rendimiento son los obvios que se conocen por adelantado y se aplican en todo momento. De lo contrario, ¿es un motor de precios de opciones o una aplicación de reloj?

¿Habrá un lanzamiento continuo, discusión, aprendizaje, retroceder y cambiar el software? ¿Estás construyendo software o hardware?

Los desarrolladores que trabajan en un proceso en cascada a menudo no se involucran hasta una etapa posterior, lo cual es un problema. Involucrarlos antes o desde el principio significa que están al tanto de cosas poco claras, indefinidas y poco elaboradas, lo que parece molestar a los desarrolladores de mucho tiempo, cuando en realidad parte de su trabajo es hacer preguntas, como "¿cuáles son los requisitos funcionales para esta cosa que vamos a construir?

Identificar agujeros en el plan no se trata de encontrar fallas, es solo desarrollo de software.

Por esta razón, me encanta la respuesta de Guy.