Як впоратися з різними стилями розвитку (зверху вниз проти знизу вгору) в команді?

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

Методології

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

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

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

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

Проблема

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

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

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

Цілі

Загальні цілі, очевидно, - максимізувати ефективність кодування (тобто мінімізувати витрату часу) та написати корисне програмне забезпечення.

Питання

Простіше кажучи, як ви вирішуєте цю проблему і справляєтесь із цією ситуацією?

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

Чи є кращий спосіб?

Очевидно, вони обидва помиляються.

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

Хлопець зверху вниз може витратити так само довго на архітектурне бачення і не зробити нічого продуктивного.

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

Це називається Agile до речі (не BS версія agile, яку деякі практикують там, де процедури важливіші, ніж робоче програмне забезпечення), а справжня спритність, яка працює над досягненням загальноописаної та зрозумілої кінцевої мети.

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

Два розробники повинні підтримувати взаємну повагу один до одного.

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

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

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

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

Повідомте всіх!

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

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

Я думаю, що ця пропозиція є доцільною, враховуючи ваш сценарій.

"Якщо двоє людей погоджуються на все, одна з них непотрібна". ~ Якийсь Старий Гай

Це насправді звучить як ідеальний сценарій для мене. Потім знову я є обома тими розробниками. Мені подобається складати «велику картину» у вигляді приміток, які врешті-решт потрапляють у трекер випуску. Тоді я починаю думати про деталі реалізації знизу вгору. Велика картина розвивається, коли я набуваю кращого розуміння того, як шматки підійдуть між собою, а шматки еволюціонують, коли вимоги змінюються, і я отримую нові ідеї.

Можливо, це гарна модель для декількох мізків.

На мою думку, вони є додатковими профілями і можуть закінчитися дуже добре. І кодування, і проектування - це необхідні етапи програмування, і ви не хочете опинитися в команді, де ніхто не хоче робити X, все, що вам потрібно, - це трохи організації (див. Я можу мати також сміливе слово!)

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

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

Одна примітка: ви сказали

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

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

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

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

1. Я б хотів, щоб вони сіли та обговорили, закликаючи їх бачити це з точки зору іншого.

2. Після цього обговорення ви можете почати розмову про планування: це слід робити як команда, розуміючи, що жоден не повинен «поступатися» іншим, але компроміси не потрібно робити. Існує безліч способів планування архітектури кодової бази, які дозволяють її розширити досить легко пізніше, не вводячи тонни додаткового коду.

3. Як тільки ви зможете змусити їх прийти до якогось перемир'я, нехай вони розійдуться! Нехай "хлопець згори вниз" планує архітектуру високого рівня, інтерфейси, ієрархії тощо. Нехай хлопець "знизу вгору" заскочить і почне писати код, коли заплановано пару модулів. Запропонуйте їм офіційно погодитися прийняти методи інших як хороші для загального проекту: Планування, щоб забезпечити легкі майбутні зміни, добре, але його не потрібно кодувати таким чином відразу. Створіть інтерфейси та заглушіть методи, щоб отримати структуру коду, і прийміть, що хороший біт коду на майбутнє насправді не буде записаний до необхідності.

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

5. Це, мабуть, найважливіший момент: полегшення балів у циклі, де вони говорять лише про процес, а не про роботу, що виконується. Поміркуйте над динамікою, яка будується: є чотири питання, які вам слід задати. Що добре, що нам слід продовжувати робити? Що погано пішло, що ми повинні перестати робити це? Чого нам не вистачає? Що ми можемо зробити щодо того, чого нам не вистачає?

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

Взагалі, в моєму досвіді протягом моєї кар'єри, недостатньо конструкції на передній частині. А конструкція, яка все-таки відбувається спереду, низька якість . Це погано. Переважно тому, що результатом є (в більшій чи меншій мірі) кидання бруду на стіну і бачення того, що прилипає. Технічний борг викуповується з початку роботи.

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

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

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

Правда, необхідний змішаний підхід:

• майже неможливо придумати «правильний» дизайн наперед; необхідний ступінь експериментування для виявлення больових точок, вузьких місць, ... (натяк: вони ніколи там, де ти думаєш, що будуть)
• майже неможливо нікуди йти, просто «йдучи», ви швидше закінчитесь кудись, чого не хотіли, або просто біжите по колах, ніж що-небудь

Однак, змішуючи обидва, ви можете:

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

Оскільки не існує жодної існуючої системи, яка б відповідала цій меті, важливо заздалегідь усвідомити, що:

• експерименти / прототипування будуть необхідні
• тому ітерація буде необхідною

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

Для того, щоб зворотний зв'язок був цінним, найкраще спочатку вирішити основну частину.

Отже, що робити з колегами?

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

Тоді їм потрібно домовитись, хто що робить. Зауважте, що у підході до середини, підкресленому вище, обидва мають вирішити завдання, які вони цінують.

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

1. Вони обидва повинні отримати приблизний ескіз скелета, а потім разом вирішити, на якому «тонкому шматочку» сфокусуватись спочатку
2. Хлопець знизу вгору повинен почати працювати над найкраще зрозумілим твором "тонкого шматочка"
3. Хлопець зверху вниз повинен почати чіпляти скелет, в ідеалі спочатку вирішуючи більшість блокуючих частин, щоб виконати фрагмент

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

Остерігайтеся: це прототип, і обидва потрібно бути готовими викинути його і почати з нуля зовсім іншого дизайну.

Вам потрібен лідер (або керівник), який розуміє розробку програмного забезпечення та який приймає рішення про те, який підхід слід використовувати в проекті. У разі необхідності керівник скеровує розробників на роботу певним чином, незалежно від їх особистих уподобань.

Єдине ефективне рішення, на яке я думаю, не витрачає часу - це дозволити кожному розробнику слідувати своєму стилю дизайну.

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