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

Question

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

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

Помимо передачи «старого кода» простым смертным, есть ли что-нибудь еще?

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

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

Answer 1

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

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

Пример побоев в реальной жизни:

Вам был назначен 1500-часовой проект разработки, и вы также несете ответственность за обслуживание и поддержку ваших последних 3 приложений. Во время этого нового проекта вас в среднем прерывали 7 раз в неделю, чтобы поддержать эти 3 приложения. Каждый раз, когда вы начинаете работать над тремя другими приложениями, вы тратите 20 минут на то, чтобы сосредоточиться на проблеме. После устранения проблемы вы потратите 20 минут на то, чтобы вновь обдумать код, который вы в последний раз касались в своем новом приложении. Это общая стоимость 40 минут за прерывание или 280 минут в неделю. Это означает, что вы потеряли 2,67 часа продуктивности за неделю, просто переключившись на поддержку этих приложений.

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

Я догадываюсь:

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

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

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

...подзаголовок к вашему ОП выглядит так: «Чувак, этот код воняет!Хотелось бы получить оригинального разработчика и потереть его нос это: что выучил бы его!"

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

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

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

Answer 7

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

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