Підготуйте план передачі вихідного коду [закрито]


12

Наша компанія збирається придбати вихідний код величезного продукту.

Що потрібно враховувати, коли розпочнеться передача, щоб переконатися, що ми маємо все та чи зможемо підтримувати цей продукт у майбутньому?


1
Якщо можливо, подайте запит на придбання у деяких інженерів, які працюють над проектом. Це допоможе вирішити проблему безперервності ресурсів.
техніт

нам не пощастило. ми не можемо зробити це максимум, що ми можемо зробити, - це зробити інженера доступним протягом 3-4 тижнів.
Ахмед Асвані

Я знайшов відповідну відповідь. Я думаю, що вона завершує те, що більшість відповідей тут.
Ахмед Асвані

Відповіді:


8

По-перше, удачі.

Ось декілька речей, про які вам, мабуть, слід попросити / надати.

  • Список відомих дефектів.
  • Список записів про випадки та проблеми
  • Подробиці про останні два випуски, як; скільки часу їм потрібно було впроваджувати, чи був період посилених інцидентів після звільнення тощо.
  • Хто є ключовими експертами з питань теми
  • Які години роботи та первинної підтримки.
  • Скільки часу продукт існував і наскільки стабільна база коду.
  • Що таке дорожня карта продукту.
  • Що таке стек технологій.
  • Що таке точки інтеграції та хто підтримує інтегровані системи.
  • Чи є компоненти ДР
  • Хто відповідає за виклик ДР
  • Що таке угоди про надання послуг або цілі обслуговування.
  • Яке очікуване зростання файлової системи / бази даних / черг повідомлень.
  • Коли проводяться резервні копії системи, хто несе відповідальність і яка стратегія відновлення.
  • Хто несе відповідальність за управління запасом продукту.
  • Які угоди про контактну службу зв'язку та контактні дані постачальника.
  • Чи є якісь пакетні графіки чи тривалі процеси.
  • Чи система цілком транзакційна і як керується паралельністю.
  • Який основний процес управління інцидентами для програми.
  • Що, коли, кого та як повідомляють зацікавлені сторони про зміни та перебої в роботі.
  • Які погоджені періоди / періоди відключення.
  • Де зберігається вихідний код.
  • Як управляється резервне копіювання, відновлення та зміна журналу вихідного коду.
  • Де, що і кому належить архітектура рішення.
  • Яка мета розгортання (DEV, ST, UAT, Pre PROD, PROD, DR).
  • Коли поновлюються ліцензії сторонніх виробників
  • Чи є діаграма RACI
  • Скільки користувачів там і де вони знаходяться.
  • Назвіть найпоширеніші проблеми та скарги.
  • Хто відповідає за надання доступу до системи.
  • Коли проводяться тести / перевірки безпеки.
  • Де знаходиться CI та автоматизований процес збирання.
  • Хто відповідає за адміністрування джерела управління та створення сервера.
  • Де знаходяться посібники з установки.
  • Чи є документація на цільову інфраструктуру та мережу.
  • Назвіть види тяжкості та наслідки останніх інцидентів.
  • Чи є інструкції з налаштування робочої станції для розробників.
    • Які помічники та рамки для розробки використовуються та чи мають вони ліцензію для вашої команди.

Це про все, про що я можу подумати на даний момент.


8
Будь ласка, визначте "DR", "DEV, ST, UAT, Pre PROD, PROD, DR" та "RACI". Зауважте, що щось із цього не має значення для вихідного коду (тобто графіки RACI є організаційними, зовсім не пов'язаними з кодом.)
S.Lott

Я б хотів отримати доступ до сховища загального вихідного коду не лише до поточних версій вихідного коду. Зауваження в цьому часто дозволяють пояснити, чому код був змінений певним чином. Це важливо для його збереження.
HLGEM

@HLGEM вибачте, що моя заява про поточні версії вихідного коду передбачала (ну, все одно, мені) повний вихідний код для всіх компонентів.
Кейн

@ S.Lott DR використовується для опису "відновлення після аварій". Dev - це загальний термін для "середовища розвитку", що б не було для вашого середовища. ST - це абревіатура для тестового середовища системи. Я не погоджуюся з тим, що RACI є організаційним інструментом, оскільки він використовується для опису відповідальності, підзвітності, поінформованості та консультацій. Тож коли код вчиняється, хто за нього відповідає? З ким консультуються в рамках експертної оцінки? Кому повідомлено, що збірка вдалася / провалилася? І так далі
Кейн

@kame: Будь ласка, оновіть відповідь визначенням. Будь ласка, не додайте більше коментарів до відповіді. Будь ласка, оновіть відповідь.
S.Lott

6

Що потрібно враховувати, коли розпочнеться передача, щоб переконатися, що ми маємо все та чи зможемо підтримувати цей продукт у майбутньому?

Що ви повинні переконатися, це:

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

Все інше залежить від поточного технічного обслуговування.


2
Я б запропонував, щоб вони були змінені, щоб вони містили слова "Ви повинні їх бачити ...", наприклад, "Ви повинні бачити, як вони створюють код" і "Ви повинні бачити, як вони виконують одиничні тести" тощо.
S.Lott

@ S.Lott Показують вони чи пишуть у документі, це не має значення. Ахмед Асвані та його команда збираються підтримувати заявку, і вони повинні мати можливість зробити всі вищезазначені кроки самостійно. Я трохи змінив відповідь, але не впевнений, чи це саме ви запропонували.
BЈович

1
Ствердження про те, що цей код створюється, не є тим самим, як насправді бачити код, який будується. Був там. Зробив це. Документація може бути розпливчастою, заплутаною чи неповною. Це старий принцип "Довіряй, але перевіри". Поки ви цього не побачите, не повірите.
S.Lott

1
@ S.Lott Ok має сенс. Тепер, коли я думаю про це, я був у подібній ситуації раніше, коли вони змусили нас щось реалізовувати на зламаних дошках HW Ми витратили хороші 4 місяці, перш ніж з'ясувати, що насправді не так.
BЈович

5

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

Пізніше у вас з’являться запитання, про які ви не знали, що вам доведеться задавати їх заздалегідь, тому їм потрібно «приклеїтись», щоб пояснити вам речі, а не просто надавати код, документи та все, що вони мають у проекті.

Коли у вас є передача проекту, ви втрачаєте одне важливе: оригінальний досвід команди.

Іноді ви також отримуєте щось, чого ви не очікували: їхню неприязнь.

Чи компанія, яка робить хендовер, отримує добру справу з хендовером? Якщо вони втрачають бізнес через те, що вони звертають проект до вас, (горді) розробники, які створили код, можуть обуритись тим, що їх "дитина" віддана. Ви можете отримати відповіді на кшталт: "Це в документах, які ви отримали" ... навіть якщо це не так.

Технічні аспекти добре висвітлити, але також враховувати людську сторону цього.

YMMV!


0

Чи додається код із тестовим набором? Чи проходять усі тести в наборі тестів? Скільки покриття має люкс?

Я рекомендую, не вистачаючи тестового набору, ви зробите побудову тестового набору та відповідних рамок вашим першим пріоритетом.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.