Emparelhe a lógica de negócios de programação com uma pessoa que não é de TI [fechada]

14

Fechado . Esta questão precisa ser mais focada . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela se concentre apenas em um problema editando esta postagem .

Fechado há 4 anos .

Você já teve alguma experiência na qual uma pessoa que não é de TI trabalha com um programador durante o processo de codificação?

É como programação em pares, mas uma pessoa é uma pessoa que não é de TI que conhece muito sobre os negócios, talvez um engenheiro de processos com experiência em matemática que saiba como as coisas são calculadas e possa entender código de procedimento não-idiomático.

Descobri que algumas linguagens processuais específicas do domínio, como PL / SQL, são bastante compreensíveis por engenheiros que não são de TI. Essas pessoas acabam sendo coautoras do código e garantem a correção de fórmulas, fatores etc.

Eu achei esse tipo de programação de pares bastante produtivo, esse tipo de usuário do tipo de engenharia sente que também é "proprietário" e "autor" do código e ajuda a minimizar mal-entendidos no processo de comunicação. Eles até ajudam a projetar casos de teste.

Essa prática é comum?
Isso tem um nome?
Você já teve experiências semelhantes?

— Tulains Córdova
fonte

11

Embora você esteja descrevendo isso como uma sessão de codificação compartilhada (não posso chamá-lo de programação em pares, pois apenas uma pessoa está "dirigindo" - na programação em pares, ambas as partes pegam o teclado e escrevem o código), eu chamaria isso de reunir critérios de aceitação .

Ou seja, você está validando regras de negócios (cálculos e processos corretos) com o usuário comercial (embora um com uma função muito técnica, um engenheiro).

Nesse caso, ele se traduz imediatamente em código escrito (SQL), mas, para muitas outras atividades, não será, embora existam ferramentas de teste de aceitação automatizadas para diferentes idiomas e plataformas (estou pensando especificamente na linguagem do maxixe e nas ferramentas relacionadas).

Essa prática não é tão comum como deveria ser, mas está conquistando cada vez mais seguidores e aqueles que a seguem (obtendo critérios de aceitação de uma forma que possa ser executada) acham inestimável como uma ferramenta para se comunicar com a empresa e conduzir desenvolvimento.

— Oded
fonte

Pelo menos onde estou (em uma pequena empresa), temos muita comunicação entre o lado comercial e o de engenharia, mas eu sinto que um dos caras de negócios que conhece as coisas dele se senta e percorre o código comigo por linha, seria um desperdício de recursos da empresa, especialmente considerando o estado da economia e como ele leva os negócios a serem o mais enxutos possível. Se tivéssemos mais horas no dia de trabalho, poderia fazer sentido, mas cada hora conta. Apenas minha entrada de qualquer maneira.

— Ampt

@ Ampt - você já tentou? Se você usar especificações executáveis, poderá orientá-las pela especificação em vez do código.

— Oded

Eu não tentei e não estou dizendo que isso está errado de forma alguma! Você acabou de declarar que não é tão comum como deveria ser e eu estava dando a minha opinião sobre o porquê disso. Eu sinto que quanto mais comunicação que você tem entre o lado de negócios e desenvolvimento, o melhor para o seu projeto pode ser. A qualidade dessa comunicação geralmente define o quão bom é o seu projeto e, por essa lógica, sentar-se com uma pessoa de negócios e analisar o código que eles poderiam entender provavelmente se enquadrava na categoria de boa comunicação.

— Ampt

2

Sim. Onde trabalho, faço o tipo de programação hardcore, enquanto os estrategistas trabalham na estratégia de hum. Ou seja, escrevo os programas que implementam seus modelos de negociação.

A chave para isso é sentar-se ao lado deles e entender exatamente quais são as idéias e fazer muitas perguntas sobre coisas que podem ser incidentais para elas, mas importantes para o lado da execução. Por exemplo, eu perguntaria sobre a rapidez com que uma negociação precisa ser executada, se isso afeta seu modelo. Isso tem um enorme impacto em como escreverei o código. De fato, tenho a tendência de espalhar perguntas para a sala, pois estamos sentados lá trabalhando todos os dias.

Há um feedback bidirecional. Se eu lhes disser que algum esquema de negociação não será fácil de construir, eles voltam e pensam sobre quais trocas podem ser feitas no lado da tomada de decisão. Se eles decidirem que sua nova estratégia precisa de algum novo recurso, eu converso com eles sobre quanto tempo levaria para criar e quais são as possíveis armadilhas.

Eles desenvolvem módulos de código que encapsulam algum aspecto da estratégia de negociação de tempos em tempos, mas eu misturo as peças em uma arquitetura que nos permite acompanhar todas as estratégias diferentes, bem como fazer backend de operações. Dessa forma, eles não precisam conhecer o âmago da questão do sistema.

— Carlos
fonte