Подготовить план передачи исходного кода [закрыт]

12

Наша компания собирается приобрести исходный код огромного продукта.

Что следует принять во внимание при начале передачи, чтобы убедиться, что у нас есть все и мы можем поддерживать этот продукт в будущем?

documentation maintenance knowledge-transfer Ахмед Асуани
источник
1
Если возможно, запросите приобретение для некоторых инженеров, работающих над проектом. Это поможет с проблемой непрерывности ресурса.
Технит
нам не повезло. мы не можем сделать это максимум, что мы можем сделать, чтобы некоторый инженер был доступен в течение 3-4 недель.
Ахмед Асуани
Я нашел связанный ответ, я думаю, он завершает то, что большинство ответов здесь.
Ахмед Асуани

Ответы:

8

Во-первых, удачи.

Вот некоторые вещи, которые вам, вероятно, следует попросить / предоставить.

  • Список известных дефектов.
  • Список происшествий и проблемных записей.
  • Подробности о последних двух выпусках, как; сколько времени они потратили на реализацию, был ли период повышенных инцидентов после освобождения и т. д.
  • Кто является ключевыми экспертами в данной области.
  • Какие часы работы и первичная поддержка.
  • Как долго продукт существует и насколько стабильна кодовая база.
  • Какова дорожная карта продукта.
  • Что такое стек технологий?
  • Каковы точки интеграции, и кто поддерживает интегрированные системы.
  • Есть ли компоненты DR
  • Кто несет ответственность за вызов DR
  • Каковы SLA приложения или цели обслуживания.
  • Каков ожидаемый рост файловой системы / базы данных / очередей сообщений.
  • Когда выполняется резервное копирование системы, кто несет ответственность и какова стратегия восстановления.
  • Кто отвечает за управление бэклогом продукта.
  • Какой поставщик SLA и контактные данные на месте.
  • Есть ли какие-либо пакетные расписания или длительные процессы.
  • Является ли система полностью транзакционной и как управляется параллелизм?
  • Каков основной процесс управления инцидентами для приложения.
  • Что, когда, кто и как заинтересованные стороны уведомляются об изменениях и отключениях.
  • Каковы согласованные периоды / время простоя.
  • Где хранится исходный код
  • Как осуществляется резервное копирование исходного кода, восстановление и управление журналом изменений.
  • Где, что и кому принадлежит архитектура решения.
  • Какова цель развертывания (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Когда будут продлены лицензии третьих лиц?
  • Есть ли диаграмма RACI?
  • Сколько пользователей там и где они находятся.
  • Каковы общие проблемы устранения неполадок или жалоб.
  • Кто отвечает за предоставление доступа к системе.
  • Когда проводятся проверочные тесты / проверки безопасности.
  • Где находится КИ и автоматизированный процесс сборки.
  • Кто отвечает за администрирование системы контроля версий и сборки сервера.
  • Где находятся инструкции по установке.
  • Есть ли документация для целевой инфраструктуры и сети.
  • Каковы виды серьезности и последствия недавних инцидентов.
  • Есть ли инструкции по настройке рабочей станции разработчика.
    • Какие средства разработки и платформы используются и лицензированы ли они для вашей команды.

Это обо всем, что я могу думать в данный момент.

Kane
источник
8
Пожалуйста, укажите "DR", "DEV, ST, UAT, Pre PROD, PROD, DR" и "RACI". Обратите внимание, что кое-что из этого не имеет значения для исходного кода (т. Е. Диаграммы RACI являются организационными, а не связаны с кодом).
S.Lott
Я хотел бы получить доступ к хранилищу исходного кода whoel, а не только к текущим версиям исходного кода. Комментарии в этом разделе часто показывают, почему код был изменен определенным образом. Это важно для поддержания его.
HLGEM
@HLGEM Извините, мое утверждение о текущих версиях исходного кода подразумевает (в любом случае, мне) полный исходный код для всех компонентов.
Кейн
@ S.Lott DR используется для описания «аварийного восстановления». Dev - это общий термин для «среды разработки», независимо от того, из чего он состоит для вашей среды. ST - это аббревиатура от System Testing Environment. Я не согласен с тем, что RACI является организационным инструментом, поскольку он используется для описания того, кто является ответственным, подотчетным, информированным и проконсультированным. Итак, когда код фиксируется, кто за это отвечает? С кем консультируются в рамках экспертной оценки? Кому сообщают, что сборка прошла успешно / не удалась? И так далее
Кейн
@kame: Пожалуйста, обновите ответ с определениями. Пожалуйста, не добавляйте еще комментарии к ответу. Пожалуйста, обновите ответ.
S.Lott
6

Что следует принять во внимание при начале передачи, чтобы убедиться, что у нас есть все и мы можем поддерживать этот продукт в будущем?

Вещи, которые вы должны убедиться:

  • вы видите, как они успешно строят код
  • вы видите, как они собирают юнит-тесты и делают все успешно
  • вы видите, как они успешно выполняют другие тесты, и все проходят (прием, интеграция и т. д.)
  • вы получаете базу данных открытых вопросов (легко получить, если они используют bugzilla или аналогичные)
  • продукт работает (инструкция по установке).

Все остальное зависит от текущего сопровождающего.

BЈовић
источник
2
Я бы посоветовал изменить их так, чтобы они содержали слова «Вы должны их видеть ...», например, «Вы должны видеть, как они строят код» и «Вы должны видеть, как они запускают модульные тесты» и т. Д. Здесь важны доказательства.
S.Lott
@ S.Lott Показывают ли они или пишут в документе, это не должно иметь значения. Ахмед Асуани и его команда собираются поддерживать приложение и должны быть в состоянии выполнить все вышеперечисленные шаги самостоятельно. Я немного изменил ответ, но я не уверен, что это то, что вы предложили.
BЈовић
1
Утверждение, что сборка кода не совпадает с фактическим сборкой кода. Был там. Сделано это. Документация может быть расплывчатой, запутанной или неполной. Это старый принцип «Доверяй, но проверяй». Пока не увидишь, не верь.
S.Lott
1
@ S.Lott Хорошо, имеет смысл. Теперь, когда я об этом думаю, я уже был в подобной ситуации, когда нас заставляли внедрять что-то на сломанных платах HW. Мы потратили 4 месяца на то, чтобы понять, что же на самом деле не так.
BЈовић
5

Вы должны убедиться, что команда передаст код в течение определенного периода времени. Сделайте это подписанным контрактом!

Позже у вас возникнут вопросы, о которых вы не знали, что должны были задавать вопросы заранее, поэтому им нужно «постараться», чтобы объяснить вам вещи, а не просто дать код, документы и все, что у них есть в проекте.

Когда у вас есть передача проекта, вы теряете одну важную вещь: первоначальный опыт команды.

Иногда вы также получаете то, чего не ожидали: их враждебность.

Получает ли компания, осуществляющая передачу, хорошую сделку с передачей? Если они потеряют бизнес из-за того, что передают проект вам, (гордые) разработчики, создавшие код, могут возмущаться тем фактом, что их «ребенок» отдан. Вы можете получить ответы типа: «Это в ваших документах» ... даже если это не так.

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

YMMV!

JohnDoDo
источник
0

Код поставляется с набором тестов? Все тесты в наборе тестов проходят? Какой охват у люкса?

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

blueberryfields
источник