Как систематически передавать проект? [закрытый]

Мой основной процесс получения передачи был бы следующим:

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

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

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

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

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

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

С точки зрения чтения документации, лично я бы выбрал такой порядок:

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

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

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

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

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

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

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

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

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

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

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

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

7. Спросите их, есть ли что-нибудь, что, по их мнению, вам следует знать.

8. Убедитесь, что на все вопросы, которые вы записали где-либо еще, есть ответы.

9. Вы можете подумать, что стоит просмотреть список ошибок (открытых и закрытых) - начните с самых приоритетных и обсудите все, что особенно тревожно. . Даже если они исправят это, это может указывать на фрагмент кода, который вызывает проблемы.

10. И, наконец, если возможность существует - если есть какие-либо нерешенные ошибки или изменения, посмотрите, сможете ли вы запрограммировать пару пар.

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

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

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

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

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

Удачи.

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