Как систематически передавать проект?

У нас есть проект, переданный от береговой команды нашей команде (с берега) недавно. Однако у нас были трудности с процессом передачи.

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

Интересно, существуют ли какие-либо правила или лучшие практики, за которыми мы можем следовать, чтобы обеспечить успешную передачу проекта, как от нас, так и от нас.

Спасибо.

Ответ 1

Что касается чтения документации, лично я бы пошел на этот заказ:

Получите краткий обзор основной функции приложения - чего он должен достичь. Бизнес-пример, вероятно, лучший документ, который уже существует.
Тогда функциональная спецификация. На этом этапе вы не пытаетесь понять какие-либо способы или технологии, именно то, что предназначено для приложения. Если он массивный, спросите их, какими они являются ключевыми бизнес-процессами, и сосредоточьтесь на них.
Затем технический обзор высокого уровня. Это должно включать диаграмму архитектуры, необходимые платформы, версии, конфигурацию и т.д. Перечислите все ваши вопросы.
Затем просмотрите любые другие полезные технические документы - обязательно, если есть, часто задаваемые сценарии тестирования, так как они описывают подробные сценарии типа "как". Может быть, это только я, но я нахожу чтение технических документов, прежде чем я увижу, что система пуста - она слишком академическая, и они обычно шокированы. Это, конечно, область, на которую я бы ограничил время, в которое я потратил, если бы не чувствовал, что получаю разумный доход за время, которое я тратил.

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

Как только вы столкнетесь с ними лицом к лицу:

Начните с полной демонстрации системы. Задавайте вопросы по мере их появления, не позволяйте им обманывать вас нечеткими ответами - если они не могут ответить, что-то записано и поручить им получить ответ.
Теперь извлеките код и запустите его на своих машинах. Сделайте это, по крайней мере, на двух машинах - один из них, один из которых вы ведете. Документируйте весь процесс - это самый важный шаг. Если вы не можете запустить код, вы ввернуты.
Пройдите процесс сборки. Убедитесь, что вы можете создавать приложение (включая любые автоматические сборки и модульные тесты, которые они могут иметь). Обратите внимание, что все модульные тесты должны проходить - если они этого не делают или говорят, что "о, это всегда не удается", тогда они должны исправить это до окончательного принятия.
Пройдите процесс установки. Делайте это по крайней мере дважды, один из них ведет, как только вы возглавите. Убедитесь, что он задокументирован.
Теперь придумайте набор общих бизнес-функций, выполняемых с приложением. Используйте это, чтобы пройти код с ними. База кода будет слишком большой, чтобы охватить все это, но убедитесь, что вы закрываете репрезентативный образец.
Если есть база данных или API, выполните аналогичные упражнения. Придумайте некоторые стандартные данные, которые вам могут понадобиться извлечь или некоторые базовые задачи, которые вам могут потребоваться, используя API, и потратьте некоторое время на их работу с ними.
Спросите их, есть ли что-нибудь, что они думают, что вы должны знать.
Убедитесь, что на все вопросы, которые вы записали в другом месте, отвечают.
Вы можете подумать, что стоит пройти через список ошибок (открытый и закрытый) - начните с высокоприоритетных и расскажите о чем-нибудь особенно тревожно выглядящем. Даже если они исправили это, это может указывать на немного кода, который является неприятным.
И, наконец, если такая возможность существует - если есть какие-либо выдающиеся ошибки или изменения, посмотрите, можете ли вы пару программ пары.

Не принимайте приложение, если вы на 100% уверены, что можете:

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

Не принимать хэндовер завершение до тех пор, пока они:

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

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

Удачи.

Ответ 2

Мой основной процесс получения передачи обслуживания будет:

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

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

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

Ответ 3

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

Крайним решением является избавление от всех переносов и начало использования умного мышления.

Ответ 4

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

Ответ 5

Отъезд "Требования к программному обеспечению" и Шаблоны требований к программному обеспечению за идеи по вопросам, задаваемым при сборе информации о проекте. Я думаю, что так же, как они будут работать для новой разработки, они также помогут вам договориться с существующим проектом.