Дизайн в одной команде, кодирование в другой

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

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

Итак, мой вопрос, является ли этот подход хорошим или доказанным правильным? Каковы основные соображения, которые наш программный процесс должен иметь успех в нашем проекте?

Мое мнение:

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

Моя рекомендация

• Не давайте им так много документов, а скорее интерфейсы и абстрактные классы , чтобы ограничить их в ваших целях дизайна .

• Требуйте от них использования известного стандарта именования.

• Требуйте от них использования модульных тестов.

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

Это называется Big Design Up Front, он же Waterfall. Это не широко расценивается как очень успешная методология. Но я видел, как это работает, и когда это работает, это работает очень хорошо. Это очень дорого делать правильно.

Это также то, что ваши работодатели попросили вас сделать.

Оффшорные команды работают не так, как они работают на суше. Вы должны быть очень, очень точны в том, что именно вы хотите, иначе вы не получите то, что хотите.

Последний проект я был дизайнером программного обеспечения. Все разработки были офшорными. Мы были успешны. Так что этот процесс может работать.

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

Это действительно зависит от того, насколько вы доверяете оффшорной разработке. Я доверяю своей оффшорной команде быть компетентными разработчиками. Тем не менее, я дал общее руководство, но дал им свободу действий для реализации, что офшорной команде было приятно. В прошлом они были более микроуправляемыми. В определенных ситуациях я бы руководствовался ими, используя при необходимости шаблоны проектирования. Я также регулярно проводил обзоры и анализ кода, который они написали, и посоветовал рефакторинг или очистку. Кроме того, так как некоторые члены команды попали в аварию с транспортными средствами для отдыха, я заканчивал тем, что кодировал некоторые истории во время реализации, поскольку у нас не хватало некоторых ресурсов.

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

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

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

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

1. Определите код скелета, открытый интерфейс, интерфейс службы и т. Д. И просмотрите вместе
2. Определите приемочные испытания с другой стороны
3. Разделите большой документ на маленькие истории, работайте на основе маленьких историй. Большой документ - это просто большая картина всей системы
4. Установите контрольные точки истории, одну неделю или две недели

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

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

Другой пример - веб-приложения, многие из которых пытаются реализовать стиль REST. Этот действительно не говорит, как реализовать что-то, хотя, когда есть спецификации о том, как использовать HTTP. В любом случае, есть спецификации и руководящие принципы, которым нужно следовать. Если вы видите количество обсуждений о реализации REST на stackexchange или на рабочем месте, это похоже на то, что есть архитектор, который говорит людям, чтобы они реализовали что-то определенным образом. Я думаю, что это все еще успешная модель, и многие люди следуют этому стилю.

Из этих двух примеров вы можете увидеть, как распространяются проекты, некоторые из них в виде бумажных спецификаций, другие идут с книгами, инструментами и примерами. Вы можете видеть, как люди спрашивают (в объеме), пытаясь получить правильное понимание с различной степенью в зависимости от того, каким стандартам / конструкциям они пытаются следовать. Просто зайдите в stackoverflow и смотрите;)

Если вы дадите мне свои спецификации, я спрошу. Если вы дадите мне тестовый модуль, я буду кодировать и тестировать.