Empareje la lógica empresarial de programación con una persona que no sea de TI [cerrado]

¿Ha tenido alguna experiencia en la que una persona que no es de TI trabaja con un programador durante el proceso de codificación?

Es como la programación en pareja, pero una persona es una persona que no es de TI y que sabe mucho sobre el negocio, tal vez un ingeniero de procesos con experiencia en matemáticas que sabe cómo se calculan las cosas y puede entender el código de procedimiento no idiomático.

Descubrí que algunos lenguajes de procedimientos específicos de dominio como PL / SQL son bastante comprensibles para los ingenieros que no son de TI. Estas personas terminan siendo coautores del código y garantizan la corrección de fórmulas, factores, etc.

He encontrado que este tipo de programación de pares es bastante productivo, este tipo de usuarios de ingeniería consideran que también son "propietarios" y "autores" del código y ayudan a minimizar los malentendidos en el proceso de comunicación. Incluso ayudan a diseñar casos de prueba.

• ¿Es esta práctica común?
• Eso tiene un nombre?
• ¿Has tenido alguna experiencia similar?

Aunque está describiendo esto como una sesión de codificación compartida (no puedo llamarlo programación de pares, ya que solo una persona está "manejando"; en la programación de pares, ambas partes toman el teclado y escriben el código), lo llamaría reunir criterios de aceptación .

Es decir, está validando las reglas comerciales (cálculos y procesos correctos) con el usuario comercial (aunque uno con un rol muy técnico, un ingeniero).

En este caso, se traduce inmediatamente en código escrito (SQL), pero para muchas otras actividades no lo será, aunque existen herramientas de prueba de aceptación automatizadas para diferentes idiomas y plataformas (estoy pensando específicamente en el lenguaje de pepinillo y las herramientas relacionadas).

Esta práctica no es tan común como debería ser, pero está ganando cada vez más seguidores y aquellos que la siguen (obteniendo criterios de aceptación en una forma que se puede ejecutar) la encuentran invaluable como una herramienta tanto para comunicarse con el negocio como para conducir desarrollo.

Si. Donde trabajo hago el tipo de programación hardcore, mientras que los estrategas trabajan en la estrategia uhm. Es decir, escribo los programas que implementan sus modelos comerciales.

La clave para esto es sentarse justo al lado de ellos y comprender exactamente cuáles son las ideas, y hacer muchas preguntas sobre cosas que pueden ser incidentales para ellos, pero importantes para el lado de la ejecución. Por ejemplo, preguntaría qué tan rápido debe ejecutarse una operación, si eso afecta su modelo. Esto tiene un gran impacto en cómo escribiré el código. De hecho, tiendo a rociar preguntas en la habitación, ya que estamos sentados allí trabajando todos los días.

Hay una retroalimentación bidireccional. Si les digo que algún esquema comercial no será fácil de construir, regresan y piensan qué compensaciones se pueden tomar en el lado de la toma de decisiones. Si deciden que su nueva estrategia necesita alguna característica nueva, tengo una conversación con ellos sobre cuánto tiempo tomaría construir y cuáles son las posibles dificultades.

Realizan módulos de código que encapsulan algún aspecto de la estrategia comercial de vez en cuando, pero combino las piezas en una arquitectura que nos permite realizar un seguimiento de todas las diferentes estrategias, así como de las cosas operativas del backend. De esa manera, no necesitan saber el meollo del sistema.