Как правильно вести offshore software development?

[Плюшка]

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

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

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

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

ТИА

[Sergunka]

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

[stenking]

Что реально работает, во всяком случае для меня:

1. Четкие подробные спецификаци. Т.е. я насобачился рисовать очень чёткие wireframes с абсолютно всеми подробностями и states + бонусы за любую найденную в моей wireframe ошибку и ещё большие бонусы за принятое дополнительное предложение/изменение функционала.

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

[Интеррапт]

Т.е. я прошу делать коммиты каждый день и
реально смотрю на код, иногда прошу что-то поменять и т.д.

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

[rzen]

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

[stenking]

Т.е. я прошу делать коммиты каждый день и
реально смотрю на код, иногда прошу что-то поменять и т.д.

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

Ну напишут мне емаил, что код сложный, коммит ещё не готов, всем спокойной ночи а на след. день будет видно что там сложного было

[fruit6]

Что реально работает, во всяком случае для меня:

1. Четкие подробные спецификаци. Т.е. я насобачился рисовать очень чёткие wireframes с абсолютно всеми подробностями и states + бонусы за любую найденную в моей wireframe ошибку и ещё большие бонусы за принятое дополнительное предложение/изменение функционала.

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

сколько вы тратите в день времени на проверку коммитов, если не секрет?

[Komissar]

Я за конкретные спеки и детальные Test-cases. Если моим местным ребятам приходилось выверять все коммиты, то нафиг такой аутсорс? Я использую местных для early prototyping, technology assessment, research tasks. А оффшор - для четко поставленных исполнительных задач, с четко определенными acceptance criteria.

[stenking]

Что реально работает, во всяком случае для меня:

1. Четкие подробные спецификаци. Т.е. я насобачился рисовать очень чёткие wireframes с абсолютно всеми подробностями и states + бонусы за любую найденную в моей wireframe ошибку и ещё большие бонусы за принятое дополнительное предложение/изменение функционала.

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

сколько вы тратите в день времени на проверку коммитов, если не секрет?

Минут 5-10 на девелопера.

[Интеррапт]

Я за конкретные спеки и детальные Test-cases. Если моим местным ребятам приходилось выверять все коммиты, то нафиг такой аутсорс? Я использую местных для early prototyping, technology assessment, research tasks. А оффшор - для четко поставленных исполнительных задач, с четко определенными acceptance criteria.

+1, с одним исключением. До того, как люди себя зарекомендовали, делать code review для коммитов - довольно неплохая идея. Уже позже, когда видишь, что люди нормально работают и косяков не порят, то можно от такой практики надзора потихоньку отказываться.

[Palych]

сколько вы тратите в день времени на проверку коммитов, если не секрет?

Минут 5-10 на девелопера.

+1
Если знать что приложение делает, как устроено и куда движется - проверка не займёт много времени.
Если этого не знать - контролировать работу не получится.
Для меня, как девелопера, самый большой челендж - научится определять код, который идиотский по сути, но не наносит существенного вреда для приложения. Без этого навыка получится "Если хочешь чтобы было сделано хорошо - сделай это сам". Фраза хлёсткая и красивая, но не всегда верная.

[Sergunka]

Я за конкретные спеки и детальные Test-cases. Если моим местным ребятам приходилось выверять все коммиты, то нафиг такой аутсорс? Я использую местных для early prototyping, technology assessment, research tasks. А оффшор - для четко поставленных исполнительных задач, с четко определенными acceptance criteria.

+1, с одним исключением. До того, как люди себя зарекомендовали, делать code review для коммитов - довольно неплохая идея. Уже позже, когда видишь, что люди нормально работают и косяков не порят, то можно от такой практики надзора потихоньку отказываться.

Сейчас еще очень полезная вещь как Bamboo появилась которая на каждый коммит делает юнит тест всего приложения + функциональный тест. Если юнит тест написаны нормально то обычно лажа выскакивает автоматически.

[Интеррапт]

Сейчас еще очень полезная вещь как Bamboo появилась которая на каждый коммит делает юнит тест всего приложения + функциональный тест. Если юнит тест написаны нормально то обычно лажа выскакивает автоматически.

Ага, Bamboo используем уже несколько лет (так же как и два других продукта от Atlassian: JIRA, Confluence).

[Palych]

А можно мне вклиниться с техническим вопросом? Спасибо.
Придумали ли какой-нибудь технический способ отдавливать глюки связанные с неправильным scope and multuthreading?
Например - кто-то для удобства решил сохранять значение, изменяющееся с каждым запросом в static field.
Unit tests обычно однопоточные... Может какие-нибудь мудрейшие code analyzerы помогут?

[katit]

Надо не использовать static fields а использовать dependency injection. Тогда и тестировать легко

[Palych]

Надо не использовать static fields а использовать dependency injection. Тогда и тестировать легко

Вопрос не в том что надо, а в том как лучше отловить ситуацию когда в весь из себя dependency injected код кто-то впиндюривает статическое поле...

[АццкоМото]

Минут 5-10 на девелопера.

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

[Palych]

Минут 5-10 на девелопера.

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

Я протестую! Д'Артаньян - это я!

[stenking]

Минут 5-10 на девелопера.

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

Самое бессмысленное дело это рассуждать о бессмысленности действий других

[АццкоМото]

Самое бессмысленное дело это рассуждать о бессмысленности действий других

только до тех пор, пока сам не научился действовать осмысленно

[katit]

Надо не использовать static fields а использовать dependency injection. Тогда и тестировать легко

Вопрос не в том что надо, а в том как лучше отловить ситуацию когда в весь из себя dependency injected код кто-то впиндюривает статическое поле...

То что дебагить многопоточный код сложно это все знают. И тот-же Мицрософт советует его не писать (многопоточного кода)
А так набор Code Analysis, ReSharper и т.д. в принципе помагают порешить основные проблемы.

[Medium-rare]

Изините, что вмешиваюсь, не поясните ли:
1) Как именно Microsoft не советует писать многопоточный код, дав все инструменты для этого?
2) Необходимость динамического анализа для нахождения ошибок многопоточного кода понятна. Так и ищите "multithreaded errors dynamic analysis". Но зачем же столь явно такая ошибка со статическим полем создаётся? Ну решил кто-то закешить что-то в статической переменной, ну пишется/читается она из более чем одного потока, что ещё необходимо сделать? Неужто не проще сразу вставить critical section / mutex?

[АццкоМото]

1) Как именно Microsoft не советует писать многопоточный код, дав все инструменты для этого?

дык конечно же майкрософт ничего подобного не советует

[katit]

Изините, что вмешиваюсь, не поясните ли:
1) Как именно Microsoft не советует писать многопоточный код, дав все инструменты для этого?

Я не найду конечно где я это читал. Не буду на это время тратить

Я говорю за .NET. Мысль была в том что можно конечно но в большинстве случаев не нужно. Инструменты они дают и дают их много чтобы гемор был не таким сильным. Сегодня это асинхронное программирование, Action<T>, delegates, TPL with Tasks. Завтра async/await. И все для того чтобы оленям было полегче писать и не надо было ручками threads плодить и за ними смотреть.

[major Major Major Major]

А можно мне вклиниться с техническим вопросом? Спасибо.
Придумали ли какой-нибудь технический способ отдавливать глюки связанные с неправильным scope and multuthreading?
Например - кто-то для удобства решил сохранять значение, изменяющееся с каждым запросом в static field.
Unit tests обычно однопоточные... Может какие-нибудь мудрейшие code analyzerы помогут?

Я для подобных случаев писал правила для FxCop. Универсально конечно не получалось но кое что отлавливать помогало.