Парное программирование бизнес-логики с не-IT человеком [закрыто]

Был ли у вас какой-то опыт, когда не программист работает с программистом в процессе кодирования?

Это как парное программирование, но один человек - не ИТ-специалист, который много знает о бизнесе, может быть, инженер-технолог с математическим прошлым, который знает, как все рассчитывается, и может понимать неидиоматический, процедурный код.

Я обнаружил, что некоторые процедурные, предметно-ориентированные языки, такие как PL / SQL, вполне понятны для не-ИТ-инженеров. Эти лица становятся соавторами кодекса и гарантируют правильность формул, факторов и т. Д.

Я нашел этот вид парного программирования довольно продуктивным, такого рода пользователи инженерного типа чувствуют себя также «владельцами» и «авторами» кода и помогают минимизировать недоразумения в процессе коммуникации. Они даже помогают разрабатывать контрольные примеры.

• Эта практика распространена?
• У него есть имя?
• Был ли у вас подобный опыт?

Хотя вы описываете это как совместную сессию кодирования (я не могу назвать это парным программированием, так как только один человек "ведет" - в парном программировании обе стороны берут клавиатуру и пишут код), я бы назвал это сбором критериев приемлемости ,

То есть вы проверяете бизнес-правила (правильные вычисления и процессы) с бизнес-пользователем (хотя и с очень технической ролью, инженером).

В этом случае это немедленно переводится в письменный код (SQL), но для многих других действий это не так, хотя существуют автоматические инструменты для приемочного тестирования для разных языков и платформ (я специально думаю о языке корнишонов и связанных инструментах).

Эта практика не так распространена, как следовало бы, но приобретает все больше и больше последователей, и те, кто ей следует (получение критериев приемлемости в форме, которая может быть выполнена), считают ее неоценимым инструментом как для общения с бизнесом, так и для стимулирования. развитие.

Да. Где я работаю, я занимаюсь хардкорным программированием, в то время как стратеги работают над стратегией. То есть я пишу программы, которые реализуют свои торговые модели.

Ключ к этому сидит прямо рядом с ними и понять , какие именно идеи и задавать много вопросов о вещах , которые могут быть случайно к ним, но важно , чтобы стороны исполнения. Например, я бы спросил о том, как быстро должна выполняться сделка, влияет ли это на их модель. Это имеет огромное влияние на то, как я буду писать код. На самом деле я склонен задавать вопросы в комнате, так как мы сидим там каждый день и работаем.

Есть двусторонняя обратная связь. Если я скажу им, что какую-то торговую схему будет нелегко построить, они вернутся назад и подумают, какие компромиссы могут быть приняты на стороне принятия решений. Если они решат, что их новой стратегии нужна какая-то новая функция, я поболтаю с ними о том, сколько времени потребуется, чтобы построить и каковы потенциальные ловушки.

Они создают программные модули, которые время от времени инкапсулируют какой-то аспект торговой стратегии, но я объединяю кусочки в архитектуру, которая позволяет нам отслеживать все различные стратегии, а также оперативную часть бэкенда. Таким образом, им не нужно знать все подробности системы.