Дизайн в одній команді, кодування в іншій

28

Я буду брати участь у проекті, де весь дизайн програмного забезпечення розробляється місцевою командою, і ці проекти надсилаються офшорній команді для кодування.

Це перший раз, коли я стикаюся з проектом з такими характеристиками, і для мене це виглядає дивним чином: менеджери розраховують, що ми складемо дуже детальні проектні документи, щоб не було місця помилок для офшорної команди; з моєї точки зору, вони змушують нас кодувати папери, тоді як ми можемо це робити в IDE.

Отже, моє питання - чи такий підхід хороший, чи перевірений правильно? Які основні міркування повинні мати наш процес програмного забезпечення для успіху в нашому проекті?

— Карлос Гавідія-Кальдерон
джерело

11

500 сторінок 150MB PDF документ вимог до програмного забезпечення Apollo 11 .

— Майк

5

@mike: Програмне забезпечення космічних апаратів дещо відрізняється від більшості програмного забезпечення. Він повинен працювати ідеально весь час, інакше може трапитися втрата людей та надзвичайно дорогі активи. Дивіться fastcompany.com/28121/they-write-right-stuff

— Роберт Харві

9

Я здогадуюсь, що офшорна команда дешевша, вона також удвічі більша від команди дизайнерів? Чи є якісь реальні переваги перед власною командою? наприклад, вони розмовляють природною мовою кінцевих користувачів, поки ви цього не робите? У них є якийсь талант, якого у вас немає вдома? Якщо ні, я бачу, що у вашої компанії є поганий випадок отруєння PHB .

— ZJR

1

@mike: Я думаю, було б точніше сказати, що в більшості програмного забезпечення невелика кількість помилок вважається прийнятною, оскільки програмне забезпечення без помилок - це асимптота, а видалення цих інших помилок дуже дорого.

— Роберт Харві

9

Я пропоную вам негайно почати шукати іншу роботу. Програмісти не є взаємозамінними гвинтиками, що є основним припущенням такого типу розташування. Таким чином, відокремлення дизайну від розробки - на суші або в офшор - гарантує відключення між замовником і розробниками, що робить збій дуже імовірним.

— Стівен А. Лоу

36

Моя думка:

Якщо все, що ви подаруєте офшорним людям, - це документи та діаграми, у вас буде багато недоліків та розчарувань .

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

Не дайте їм стільки документів, а скоріше інтерфейси та абстрактні класи , щоб перетягнути їх у свої цілі дизайну .
Попросіть їх використовувати відомий стандарт називання.
Попросіть їх використовувати одиничні тести.
Надішліть одного з ваших дизайнерів / архітекторів за кордон до їхніх приміщень, щоб контролювати процес, це все одно буде дешевше, ніж кодування власного будинку, але ви отримаєте кращі результати.

— Тулан Кордова
джерело

2

Офшорні команди не працюють так, як це роблять берегові команди. Ви повинні бути дуже-дуже конкретними щодо того, що саме ви хочете, інакше ви не отримаєте те, що хочете.

— Роберт Харві

32

... Що є частиною того, чому велика кількість розробок повертається на берег США; такий підхід проектування на березі, розробки офшорних, а потім налагодження назад на березі моря вимагає від вас тих самих морських ресурсів, які ви використовували б для розробки в першу чергу всього супу до горіхів. У будь-якому іншому виробничому процесі, де прямі матеріали та робоча сила для виготовлення речі висока, офшорний підхід має сенс. Коли дизайн для того, що ви робите, становить не тільки більшу частину ваших витрат, але й може бути кінцевим продуктом, розробка офшорної галузі стає очевидно зайвою.

— KeithS

@KeithS Чудовий коментар. Я згоден з вами% 110.

— Tulains Córdova

2

Змусити їх використовувати класи та інтерфейси, які ви придумали, не написавши коду самостійно, - це рецепт катастрофи.

— Майк Веллер

2

@Euphoric Існує велика розтяжність між написанням abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()і власне його реалізацією.

— Тулен Кордова

26

Це називається Big Design Up Front, він же водоспад. Це не вважається широко успішною методологією. Але я бачив, як це працює, і коли він працює, він працює дуже добре. Дуже дорого робити правильно.

Це також те, що ваші роботодавці попросили вас зробити.

Офшорні команди не працюють так, як це роблять берегові команди. Ви повинні бути дуже-дуже конкретними щодо того, що саме ви хочете, інакше ви не отримаєте те, що хочете.

— Роберт Харві
джерело

Чи можете ви детальніше розповісти про "дуже конкретний"? Чи довелося мені дійти до рівня включення методу псевдокоду?

— Карлос Гавідія-Кальдерон

8

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

— Роберт Харві

2

Чи не так It's very expensive when it goes wrong. :-)

— LarsTech

@LarsTech: Ось чому додаткові витрати на те, щоб правильно це зробити, виправдані.

— Роберт Харві

Псевдокоді люблять докладати тих же зусиль, що й писати реальний код, + офшорне спілкування накладні

— Web Devie

16

Останній проект я був дизайнером програмного забезпечення. Вся розробка була офшорною. Ми були успішними. Тож цей процес може працювати.

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

Це дійсно залежить від того, наскільки ви довіряєте офшорному розвитку. Я довіряю своїй офшорній команді грамотним розробникам. Однак, я дав загальне керівництво, але дав їм можливість втілити, яку офшорна команда визнала приємною. У минулому вони були більш мікро-керованими. У певних ситуаціях я б керував ними, використовуючи дизайнерські шаблони за потребою. Я також регулярно проводив огляд коду та аналіз коду, який вони написали, і радив би рефакторинг чи очищення зусиль. Крім того, оскільки частина команди мала аварії з рекреаційними транспортними засобами, я закінчила кодування деяких історій під час впровадження, оскільки ми закінчилися дефіцитом деяких ресурсів.

Крім того, я думаю, що цей процес справді досягає успіху лише у вашій технічній діяльності щодо проекту та зв'язку між бізнесом, дизайнером, керівниками та розробниками. Ми витратили багато часу, переглядаючи кожну особливість і історію, і переконалися, що офшорні ведучі / ресурси добре розбираються в тому, які вимоги були. Якщо вони не ставлять запитань під час перегляду функції / розповіді, тоді очікуйте деяких питань. Крім того, робота не вважалася завершеною, поки не відбувся підпис на підприємстві. Тож це зробило всіх відповідальними, оскільки все було відстежено інструментом, який керував спритною розробкою.

Як уже згадувався один з інших відповідей, процес розробки включав стандарти іменування (вбудовані правила перерозподілу), покриття тестового випадку (використовувався TDD, глузування тощо), тож якщо на місці є хороший процес і процедура кодування, він збільшиться ваші шанси на успішний проект.

— Джон Рейнор
джерело

Чи використовуєте ви який-небудь спритний процес? Можливо, спеціально підібраний?

— Карлос Гавідія-Кальдерон

2

Це було не просто спритно, більше схоже на планові ітерації. Все було заплановано на передній план, а потім покладено на 2 тижні ітерацій. Ми використовували гнучкі процеси для кожної інтеграції. Діаграми швидкості та згоряння, що використовуються, стандартний щоденний режим стояння з наступною годиною або двома телефонними дзвінками в офшор. Визначально витрачайте багато часу на телефон в офшор, але наш ідеальний день розвитку був 6 годин для врахування часу спілкування.

— Джон Рейнор

2

Зауважте, що самостійно: усувайте рекреаційні транспортні засоби від майбутніх ітерацій програмного забезпечення.

— Роберт Харві

Чи вірите ви, що ваш успіх був пов’язаний із вибором правильної офшорної команди або просто довіряти їм робити правильну справу без мікроуправління? Як ви вважаєте, ваша методика "планових ітерацій" була критичною для вашого успіху?

— Роберт Харві

1

@Jess - Ні, команда несе відповідальність лише за отримання затверджених історій та функцій (функціональності). Майбутня функціональність не постачається, хоча дизайн програмного забезпечення, як правило, передбачає певну гнучкість, але ми надаємо лише те, що просили.

— Джон Рейнор

2

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

Не впевнений, наскільки великий ваш проект. Я припускаю, що це велике, інакше користуватися офшорною командою розвитку нецінно. Таким чином, мій досвід такий

Визначте код скелета, загальнодоступний інтерфейс, інтерфейс сервісу тощо та перегляньте разом
Визначте приймальні тести з іншого боку
Розділіть великий документ на невеликі історії, працюйте на основі невеликих історій. Великий документ - це лише велика картина всієї системи
Встановіть контрольні пункти розповідей, один тиждень або два тижні

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

— alistairw
джерело

1

Я думаю, певною мірою ми всі працюємо так. Хтось десь щось проектує, і ми кодуємо щось, що є частиною або працює з системою. Приклади - це створення програм на основі рамок, як-от неігрові програми на мобільних пристроях. Багато розробників інтерфейсу прийняли команду дизайнерів людей, які побудували рамку. Вони контролювали все: від того, щоб навчитися писати додаток до продажу вашого додатка. Якщо ви хочете подивитися, чому ця модель була успішною, просто подивіться на кількість документації та інструментів, наданих деякими постачальниками.

Інший приклад - веб-додатки, багато з яких намагаються реалізувати стиль REST. Цей насправді не говорить про те, як щось реалізувати, хоча коли є специфікації щодо використання HTTP. Так чи інакше, є специфікації та керівні принципи, яких слід дотримуватися. Якщо ви бачите кількість дискусій щодо впровадження REST на stackexchange або на робочому місці, це як би архітектор, який каже людям реалізувати щось певними способами. Я все ще вдала модель, я думаю, що стільки людей дотримуються стилю.

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

Якщо ви дасте мені свою специфікацію, я попрошу. Якщо ви дасте мені тест на одиницю, я кодую і тестую.

— име96
джерело