Почему отдельные работы по техническому обслуживанию от технической разработки?

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

Возьмем, к примеру, микростанцию ​​Bentley. Это дизайнерское приложение для 3D (архитектура, дизайн растений, рельсы, мосты и т. Д.). Теперь предположим, что у нас есть v8, v9, v10 на рынке. У них разные функции, и формат файлов значительно изменился по сравнению с версиями. Но проекты настолько огромны (или клиенты настолько важны), что вам нужно поддерживать клиентов v8 и клиентов v9, а также разрабатывать материалы для v10. Таким образом, компании необходимо иметь группу обслуживания (или время), выделенную для предыдущих версий. Также,

Думаю, проблема более практическая:

• старый код был написан людьми, которых больше не было в компании или команде;
• старый код был написан внешними разработчиками;

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

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

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

Короче говоря, в большинстве случаев это делается по политическим / непрактичным причинам.

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

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

Я предполагаю:

• Делает новую разработку более предсказуемой, более легкой для расписание: потому что разработчиков не отзывает от него, чтобы исправить заранее неизвестное количество проблем с обслуживанием

• Возможность обучать новых разработчиков (например, меня)

Кроме того, код, который я поддерживал, не был " мусор »- это было программное обеспечение для телекоммуникационных компаний, ранняя сеть с коммутацией пакетов, которая была развернута для клиентов, таких как Bell и т. д. Она была хорошо спроектирована, хорошо написана, тестируемая (наборы автоматических тестовых примеров), поддерживаемая, имела множество файлов журналов, некоторая проектная документация ...

... подзаголовок к вашему OP, кажется, звучит так: «Чувак, этот код воняет! Я бы хотел найти оригинального разработчика,и потрите его носом: что выучит его! »

Итак, когда код уже написан хорошо, этот аргумент (обучение оригинальных разработчиков) неприменим.

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

[Я бы проанализировал и диагностировал проблему и запрограммировал исправление; и специалист по контролю качества должен добавить новый соответствующий тестовый пример в автоматизированный набор тестов.]

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

Кроме того, «обслуживание» может относятся к множеству действий, таких как развертывание, настройка, резервное копирование и т. д., которые определенно должны выполняться другой командой.