Parte de la dificultad en términos de que el cliente redacte un documento de especificaciones es que el cliente a menudo no sabe cómo traducir las cosas que el cliente quiere a un idioma que realmente describa lo que el cliente necesita. Si bien el cliente puede decir que desea que exista un determinado comportamiento en un sistema, generalmente no está tan preocupado por las minucias hasta que haya visto y utilizado y experimentado que el software funciona de una manera que el cliente considera que no coincide con sus necesariamente.
Cuando los clientes describen un proceso de negocios, a menudo dejan fuera mucha información relevante. A menudo, esta información se relaciona con cosas sobre un proceso que comúnmente se entienden dentro del dominio particular del cliente y que, por lo tanto, se da por sentado y a menudo no se transmite al programador. En otras ocasiones, el cliente en realidad no sabe cómo lidiar con todas las condiciones límite dentro de un sistema, y está buscando ayuda del programador. A veces es todo un caso simple de usabilidad, con el cliente pensando que quiere que algo funcione de una manera, pero luego cambia de opinión cuando se hace más claro que las cosas deberían funcionar de manera diferente.
Ok, basta de "relaciones con los clientes 101 para programadores". La pregunta es si todavía hay valor en hacer que el cliente use un DSL legible para el negocio para definir cómo definir una especificación. Creo que con orientación, la respuesta es un "sí" tentativo, y digo tentativo porque la siguiente pregunta que viene a la mente es, ¿por qué un cliente crearía un DSL cuando puede hacer que un programador defina más fácilmente uno que ¿Proporcionar a un cliente un lenguaje simple pero rico para definir cómo debe funcionar un sistema?
Cuando haya proporcionado a un cliente un lenguaje para describir cómo le gustaría que funcione un sistema, terminará con declaraciones que dicen algo como:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Este tipo de declaración termina describiendo un requisito de una manera muy clara, proporcionando la forma general que el cliente básicamente desea que asuma el sistema, u otra forma de verlo es que el cliente está describiendo qué es el sistema. Si desea que su cliente piense un poco más sobre las cosas, puede pedirles que describan las reglas que la característica debe cumplir utilizando una serie de afirmaciones similares, tal vez a:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Nuevamente descripciones muy claras, esta vez sobre cómoEl sistema debe comportarse. La cuestión es que esto no reemplazará la necesidad de que un desarrollador de software complete todos los espacios en blanco y descubra más detalles de los que el cliente puede tener conocimiento periférico. Si bien el cliente puede ser 'capacitado' por el programador para describir características y comportamientos en un formato agradable para el programador, el cliente realmente no tendrá las habilidades o el conocimiento para generar casos de prueba significativos, ni para proporcionar la implementación código. Creo que este fue el punto del artículo de Martin Fowler al que se ha referido el OP. Entonces, sí, el software en sí no puede ser escrito por el cliente, pero la descripción del software ciertamente puede, y en mi humilde opinión, debe ser escrita por el cliente. Por lo que vale, no leí el artículo de Fowler diciendo que el cliente no debería
Siento que los programadores a veces podemos olvidar que nuestros clientes son generalmente muy inteligentes en cuanto a su comprensión de sus negocios y procesos comerciales, ciertamente mucho mejor que nosotros. Cuando no tienen un programador que les diga cómo construir un sistema de software, los clientes generalmente recurren a otros medios, quizás menos eficientes, para resolver sus problemas particulares de gestión empresarial. Con esto me refiero a bases de datos simples (piense en Access) u hojas de cálculo, o incluso en libros escritos a mano, y con reglas y procedimientos bien definidos para administrar esos procesos. Lo que a muchos clientes les falta no es un medio para determinar cómo debe funcionar un sistema, sino cómo debe construirse y, lo que es más importante, qué tan eficientemente se describen las reglas de comportamiento de un sistema a las personas queno tienen las habilidades para construir realmente el sistema.
Si efectivamente existe un consenso sobre la falta de capacidad de escritura, ¿vería un problema con una herramienta que, en lugar de comenzar con los escenarios e instrumentarlos, generaría escenarios legibles para el negocio a partir de las pruebas reales?
Creo que esto está analizando el problema al revés. Vería un gran problema con una herramienta que genera documentación a partir de pruebas si esa documentación tuviera la intención de representar una especificación de alguna manera. Para probar un escenario, debe comprenderlo, por lo tanto, el escenario ya debe existir para que ambos definan una prueba para él. Si describe el escenario en una sintaxis BDD, entonces ya lo ha especificado y, por lo tanto, solo puede instrumentar los escenarios después del hecho. Si, por otro lado, tuviera una herramienta que le permitiera al cliente describir un sistema en un buen DSL amigable con la programación, y si esa herramienta pudiera usarse para generar las plantillas de código que se usarían como un conjunto de pruebas, entonces yo ' Yo diría que habría un gran valor en tal herramienta. No vería al cliente sacar a los programadores de la ecuación, y ayudaría a reducir el esfuerzo requerido para cumplir con los deseos del cliente y generar requisitos codificados por prueba de una manera BDD, y tal vez haría que los deseos del cliente se entiendan más fácilmente. Sin embargo, no sería un sustituto de tener a mano un desarrollador de software experimentado para ayudar al cliente a separar las necesidades del cliente de sus deseos.