Как справиться с различными стилями разработки (сверху вниз и снизу вверх) в команде?

Скажем, вы только что начали работать в очень маленькой команде над {в настоящее время относительно небольшим, но, надеюсь, еще большим, проектом}. Обратите внимание, что это реальный проект, предназначенный для использования другими разработчиками в реальном мире, а не какой-то академический проект, который должен быть отменен в конце семестра.
Тем не менее, код еще не передан другим, поэтому решение пока не принято.

Методологии

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

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

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

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

Проблема

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

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

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

Цели

Общими целями, очевидно, являются максимизация эффективности кодирования (то есть минимизация потерь времени) и написание полезного программного обеспечения.

Вопрос

Проще говоря, как вы решаете эту проблему и справляетесь с этой ситуацией?

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

Есть ли способ лучше?

Очевидно, они оба не правы.

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

Сверху вниз парень может потратить столько же времени на архитектурное видение и ничего не сделать продуктивным тоже.

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

Кстати, он называется Agile (не BS-версия agile, которую некоторые люди практикуют там, где процедуры важнее, чем работающее программное обеспечение), но настоящая agile, которая продолжает работать над достижением обычно описанной и понятной конечной цели.

Чтобы решить эту проблему, попробуйте Agile-подход (Kanban, вероятно, лучший), который заставит парня сверху вниз выполнять какую-то работу и заставит парня снизу планировать то, чего он пытается достичь.

Двое разработчиков должны поддерживать взаимное уважение друг к другу.

Человек сверху вниз должен учитывать тот факт, что человек снизу вверх, возможно, придумал что-то, что действительно работает. Как сказал мне один из моих «квантовых» профессоров: «Рабочая модель стоит 1000 догадок». Если это так, то верхний человек должен подумать о том, чтобы заново сделать свой «дизайн», чтобы приспособить работу нижнего человека.

Человек снизу вверх должен также уважать «рамки» человека сверху вниз и понимать, что это может быть полезно для избежания напрасных усилий, решения неправильной проблемы, отклонения от темы и т. Д. Кодер снизу вверх должен, по крайней мере, помнить, что человек сверху вниз пытается это сделать, и пытается решить, по крайней мере, проблемы, возникающие у самого сверху, как это выражено в рамках. Это было бы верно, даже если бы нижний верх не согласился с частями самого каркаса.

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

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

Держите всех в курсе!

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

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

Я думаю, что эта цитата подходит для вашего сценария.

«Если два человека согласны во всем, один из них не нужен». Какой-то старик

Это на самом деле звучит как идеальный сценарий для меня. Опять же, я являюсь обоими разработчиками одновременно. Мне нравится чертить «общую картину» в форме заметок, которые в конечном итоге попадают в систему отслеживания проблем. Затем я начинаю думать о деталях реализации снизу вверх. Общая картина развивается по мере того, как я лучше понимаю, как части будут совмещаться, а части развиваются по мере изменения требований, и у меня появляются новые идеи.

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

На мой взгляд, они являются дополнительными профилями и могут в конечном итоге делать очень хорошо. Как кодирование, так и проектирование являются необходимыми этапами в программировании, и вы не хотите оказаться в команде, где никто не хочет делать X, все, что вам нужно, это немного организации (см., У меня тоже есть смелое слово!)

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

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

Одно замечание: ты сказал

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

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

Как уже говорили другие, оба взгляда могут быть правильными в определенных отношениях. Для двух разработчиков весьма необычно не соглашаться с практиками, особенно для чего-то столь же субъективного, как процессы проектирования и разработки. У вас есть два человека, которые увлечены тем, что они делают, и знают, как это сделать: принять это!

Здесь у вас есть большой потенциал, чтобы позволить обоим людям работать по-своему, и при этом совмещать куски, чтобы получить работающее приложение.

1. Я хотел бы, чтобы они оба сели и обсудили, поощряя их видеть это с точки зрения другого.

2. После этого обсуждения вы можете начать говорить о планировании: это должно быть сделано в команде, с пониманием, что ни один из них не должен «уступать» другому, но нужно будет идти на компромиссы. Существует множество способов спланировать архитектуру для кодовой базы, которая позволяет довольно легко расширять ее позже, не добавляя тонны дополнительного кода.

3. Как только вы сможете заставить их прийти к какому-либо перемирию, дайте им взбеситься! Пусть накопитель «сверху вниз» планирует высокоуровневую архитектуру, интерфейсы, иерархии и т. Д. Пусть подключится «снизу вверх» и начнет писать код, как только будет запланировано несколько модулей. Получите от них официальное согласие принять методы других как полезные для всего проекта: планирование, предусматривающее легкие будущие изменения, - это хорошо, но его не нужно кодировать таким образом сразу. Создайте интерфейсы и методы-заглушки, чтобы получить структуру кода, и согласитесь с тем, что большая часть кода на будущее на самом деле не будет написана, пока не потребуется.

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

5. Это, пожалуй, самый важный момент: Облегчите моменты в цикле, где они говорят только о процессе, а не о выполняемой работе. Подумайте о динамике построения: вам нужно задать четыре вопроса. Что хорошо, что мы должны продолжать делать? Что пошло плохо, что мы должны перестать делать? Чего нам не хватает? Что мы можем сделать с тем, что нам не хватает?

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

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

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

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

Ни один из подходов не является достаточным. Кажется, что каждый из них достаточно умен или опытен, чтобы понять недостатки другого подхода (может быть, они сгорели?), Но не видит недостатков в своем собственном выбранном подходе ...

Правда в том, что необходим смешанный подход:

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

Смешивая оба, вы можете:

• иметь грубый набросок, дающий указания и скелет инфраструктуры
• и разработка компонентов, соответствующих этому видению

Поскольку ни одна из существующих систем, удовлетворяющих этой цели, не существует, важно понимать, что:

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

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

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

Итак, что делать с вашими коллегами?

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

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

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

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

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

Осторожно: это прототип, оба должны быть готовы выбросить его и начать с нуля совершенно другой дизайн.

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

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

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