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

28

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

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

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

Карлос Гавидия-Кальдерон
источник
5
@mike: Программное обеспечение космического корабля немного отличается от большинства программного обеспечения. Он должен работать идеально все время, иначе может произойти гибель людей и чрезвычайно дорогие активы. См. Fastcompany.com/28121/they-write-right-stuff
Роберт Харви
9
Я думаю, что оффшорная команда дешевле, она также вдвое больше команды разработчиков? Есть ли у нее какие-то реальные преимущества перед собственной командой? например, они говорят на естественном языке конечных пользователей, а вы нет? У них есть какой-то талант, которого у вас нет внутри? Если нет, то я вижу, что у вашей компании серьезный случай отравления ПГБ .
ZJR
1
@mike: Я думаю, что было бы более правильно сказать, что в большинстве программ допустимо небольшое количество ошибок, поскольку программное обеспечение без ошибок является асимптотой, а устранение оставшихся ошибок обходится очень дорого.
Роберт Харви
9
Я предлагаю вам немедленно начать искать другую работу. Программисты не являются взаимозаменяемыми Cogs, что является основным предположением такого рода договоренностей. Таким образом, отделение дизайна от разработки - на суше или на море - гарантирует разъединение между заказчиком и разработчиками, что повышает вероятность отказа.
Стивен А. Лоу

Ответы:

36

Мое мнение:

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

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

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

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

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

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

Тулаинс Кордова
источник
2
Оффшорные команды работают не так, как они работают на суше. Вы должны быть очень, очень точны в том, что именно вы хотите, иначе вы не получите то, что хотите.
Роберт Харви
32
... Что является частью того, почему большая часть разработки возвращается на берег в США; Такой подход к проектированию на суше, разработке на шельфе, а затем отладке на суше в значительной степени требует наличия у вас тех же самых береговых ресурсов, которые вы использовали бы для разработки всего этого супа. В любом другом процессе производства, где прямые материалы и трудозатраты на изготовление изделия высоки, оффшорный подход имеет смысл. Когда проектирование того, что вы делаете, не только составляет большую часть ваших затрат, но и может быть конечным продуктом, оффшорная разработка становится более очевидной излишней.
KeithS
@KeithS Отличный комментарий. Я согласен с вами.
Тулаинс Кордова
2
Заставить их использовать классы и интерфейсы, которые вы придумали, не написав код самостоятельно, - это путь к катастрофе.
Майк Веллер
2
@Euphoric Между написанием abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()и реализацией есть большой разрыв .
Тулаинс Кордова
26

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

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

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

Роберт Харви
источник
Можете ли вы подробнее рассказать о «очень конкретном»? Пришлось ли мне дойти до уровня псевдокода метода include?
Карлос Гавидия-Кальдерон
8
Псевдокод повысит ваши шансы получить код от оффшорной команды именно так, как вы этого хотите. Как уже отмечали другие, процесс успешного выполнения офшорной работы может быть более дорогостоящим, чем просто держать всю работу на месте. Но это не ваше решение.
Роберт Харви
2
It's very expensive when it goes wrong.
Разве это
@LarsTech: Вот почему дополнительные расходы, связанные с правильным решением, оправданы.
Роберт Харви
Псевдокоду нравится делать то же самое, что и писать настоящий код, + накладные расходы на оффшорное общение
Web Devie
16

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

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

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

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

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

Джон Рейнор
источник
Используете ли вы какой-то конкретный гибкий процесс? Может быть, специально?
Карлос Гавидия-Кальдерон
2
Это не было чисто проворно, больше похоже на запланированные итерации. Все было спланировано заранее, а затем разделено на две недели. Мы использовали гибкие процессы для каждого взаимодействия. Используются графики скорости и сгорания, стандартная ежедневная стоянка с последующим часом или двумя телефонными звонками в море. Определенно тратить много времени на телефон в оффшор, но наш идеальный день разработки был 6 часов, чтобы учесть время связи.
Джон Рейнор
2
Примечание для себя: исключите транспортные средства для отдыха из будущих программных итераций.
Роберт Харви
Верите ли вы, что ваш успех был в большей степени связан с выбором правильной оффшорной команды или просто с уверенностью в том, что они делают правильные вещи без микроуправления? Как вы думаете, ваша техника «запланированных итераций» имела решающее значение для вашего успеха?
Роберт Харви
1
@Jess - Нет, команда отвечает только за предоставление утвержденных историй и функций (функциональность). Будущая функциональность не предоставляется, хотя дизайн программного обеспечения обычно допускает некоторую гибкость, но мы предоставляем только то, что было запрошено.
Джон Рейнор
2

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

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

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

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

alistairw
источник
1

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

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

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

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

imel96
источник