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

14

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

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

He descubierto que algunos lenguajes de procedimiento, específicos del 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 en pares es bastante productiva, este tipo de usuarios de tipo de ingeniería sienten 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?
  • ¿Tiene un nombre?
  • ¿Has tenido experiencias similares?
pregunta Tulains Córdova 20.10.2012 - 06:25

2 respuestas

11

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á "conduciendo"; en la programación de pares, ambas partes toman el teclado y escriben el código), lo llamaría reuniendo los criterios de aceptación.

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

En este caso, se traduce inmediatamente a código escrito (SQL), pero para muchas otras actividades no se realizará, aunque existen herramientas automatizadas de prueba de aceptación para diferentes lenguajes y plataformas (estoy pensando específicamente en el gherkin language y herramientas relacionadas).

Esta práctica no es tan común como debería ser, pero está ganando más y más seguidores, y aquellos que la siguen (obteniendo criterios de aceptación en una forma que puede ejecutarse) encuentran que es inestimable como una herramienta para comunicarse con la empresa. y para impulsar el desarrollo.

    
respondido por el Oded 20.10.2012 - 07:20
2

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

La clave para esto es sentarse bien junto a 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, me gustaría preguntar 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 sala, ya que estamos trabajando allí todos los días.

Hay una retroalimentación de dos vías. Si les digo que algún esquema de negociación no será fácil de construir, regresarán y pensarán qué compensaciones se pueden hacer en el lado de la toma de decisiones. Si deciden que su nueva estrategia necesita alguna característica nueva, converso con ellos sobre cuánto tiempo tomará construir y cuáles son los posibles escollos.

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

    
respondido por el Carlos 28.06.2013 - 14:59