Как лучше всего объяснить ветвление (исходного кода) клиенту?

Question

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

Мне было поручено объяснить, почему они не принимают решение о первом наборе изменений (либо заканчивают их, либо мусор) могут понести дополнительные затраты (по сути, потому что изменения необходимо внести в филиал, тогда если они будут продолжаться с Первый набор изменений нам придется объединить их с туловищем - что будет грязным - и повторно их).

У меня есть вопрос:

Как лучше объяснить ветвление кода нетехническому клиенту?

Answer 1

Объясните это как написание двух исследовательских работ. Вы можете пойти с несколькими разными мыслями. Для этого вы создаете копию и продолжаете работать над «филиалами» одновременно. Эта проблема возникает, когда вы выполняете работу над различными статьями, и вам нужно «объединить» их в результат.

Это объяснение всегда работало для меня.

Answer 2

Вероятно, не так важно объяснить ветвление. Важно то, что вы объясняете влияние их не принятие решения.

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

Если они не понимают, почему оценки разные, вы можете объяснить, как у вас уже есть. Тестирование должно быть проведено дважды, а несовместимость должна быть решена и т. Д.

Вы также можете использовать метафоры здания. Лично они мне не нравятся, но это не было бы так сложно сделать. Одним из примеров, который приходит в голову, заменив ванну и сантехника вместе, дешевле, чем замена ванны и сантехника отдельно, поскольку вам нужно разорвать ванну только один раз и повторно разоблачить один раз и так далее.

Answer 3

Вы строите грузовик. Вы думаете, что хотите использовать его для буксировки, поэтому вам нужен больший двигатель и тормоза. Тормоза дешевле, поэтому вы поставите их на первое место. Не подождите .... вам не нужно буксировать. Пауза выбор двигателя.

Теперь вам нужен лучший пробег бензина, поэтому он должен быть легче, вы поменяете некоторые компоненты, поэтому он легче, но если вы не можете определить тяжелый двигатель/буксировку или нет. Большие тормоза могут теперь привести к тому, что он сломает тягу и вышла из -под контроля. Если мы выберем большие тормоза, грузовик может не остановиться.

Любая ситуация создает проблему. Чтобы завершить конечные задачи, зависимые задачи должны быть полными или двойной/тройной работой.

Движение вперед вообще создает двойную работу. Двойная работа стоит денег или времени. Больше денег == за бюджет / больше времени == за пределами времени.

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

ИМО, вы попытаетесь объяснить влияние затрат один раз. Если они этого не получают, вы указываете, что новые результаты требуют пересмотра контракта. Вы приближаетесь к вехе оплаты? Это может быть и так, они хотят заставить либо вы съесть эту функцию, либо сбой контрактного пересмотра, чтобы они могли перейти в другую команду разработчиков с достижением, которое они имеют, и не платить за это.

Answer 4

Не беспокойтесь. Это не ваша работа, чтобы обучать их своей работе.

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

Answer 5

Я бы даже не попробовал. Просто скажите им, хотят ли они внести оба набора изменений, теперь это будет стоить меньше, чем если вы сделаете релиз сейчас для их недавних изменений, а затем более поздний релиз, который приведет к старому набору изменений, которые приостановлены. Почему? Потому что сам релиз стоит денег.

Answer 6

У вас есть поезд «А» с несколькими машинами с тысячами коробок. Через 9 месяцев вы решили создать еще один поезд на сайдинге под названием «AB», заполненный аналогичной нагрузкой, чтобы тренироваться «A», но некоторые коробки и автомобили были добавлены, а некоторые удалены.

Поезд «А» продолжает бежать по трассе, и никто не решил, хотят ли они поезд «А+Б». Обход рассматривается. Поезда «А» придется разгрузить некоторые коробки и загрузить некоторые другие, а поезд «А» будет переименован в «a+c».

Железная дорога должна попросить клиента принять некоторые решения о том, какую поставку они хотят.

• Забудьте о «A+B», разгрузите все автомобили и съешьте расходы на погрузку.
• Попросите поезд «A+B» и замените поезд «А» перед обходом и создайте поезд A+B+C '.
• Пусть поезд «А» сделает обходной путь в поезде «A+C», а затем сделает поезд «A+B», а затем перенастроет поезд «A+C» и станет '(A+C) (A+B) '

(A+C) (A+B) будет стоить дороже и займет больше времени из -за всей загрузки, разгрузки и выяснения, как соответствовать новой конфигурации заказа на поезде.