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

14

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

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

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

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

  • Эта практика распространена?
  • У него есть имя?
  • Был ли у вас подобный опыт?
teamwork requirements client-relations business-logic pair-programming Тулаинс Кордова
источник

Ответы:

11

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

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

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

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

Одед
источник
По крайней мере, там, где я (небольшая компания), у нас много общения между бизнесом и инженерами, но я чувствую, что один из деловых парней, который знает свое дело, садится и просматривает код со мной. по линии будет пустой тратой ресурсов компании, особенно с учетом состояния экономики и того, как она заставляет бизнес быть максимально экономным. Если бы у нас было больше часов в рабочий день, это могло бы иметь смысл, но каждый час считается. Просто мой вклад в любом случае.
Ampt
@Ampt - вы пробовали это? Если вы используете исполняемые спецификации, вы можете пройти их через спецификацию вместо кода.
Одед
Я не пробовал, и я не говорю, что это неправильно! Вы только что заявили, что это не так часто, как должно быть, и я высказал свое мнение о том, почему это может быть. Я чувствую , что больше общения у вас есть между бизнесом и развития стороны, тем лучше ваш проект может быть. Качество этого общения часто определяет, насколько хорош ваш проект, и, исходя из этой логики, встреча с деловым человеком и просмотр кода, который он может понять, вероятно, попадет в категорию хорошего общения.
Невероятный
2

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

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

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

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

Carlos
источник