Как принимаются решения в вашем цикле разработки программного обеспечения?

Question

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

Как бы вы описали способ принятия решений в процессе разработки программного обеспечения в вашей компании? Это демократия?/Это дикция?/Это анархия?

Вот что я слышал от одного из моих друзей: «Это не демократия, я менеджер, я решаю, что делать».

Что вы думаете?

Answer 1

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

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

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

• Размер команды - после того, как команда растет более чем на 3-5 человек, вы больше не могут принимать решения как группа. Это ограничение на небольшие группы людей. Очень сложно провести эффективную встречу с численностью свыше 5. Если вы не можете эффективно разговаривать, вы не можете принять совместное решение. Именно в этом случае необходимо будет назначить несколько потенциальных клиентов и дать им возможность принять решение и объединить субтемы, если это решение не может быть принято в рамках одной команды.
• Опыт команды - в команде, в которой только очень небольшой процент разработчиков имеет опыт работы с соответствующей технологией, имеет смысл изолировать важные решения эксперта по технологиям + разработчика с информацией о проблемных доменах , Это соответствует идее архитекторов. Предположительно, у архитектора есть лучшее, чем среднее понимание технологий и технологических рисков, и он находится в лучшем положении для принятия важных решений. Это может быть не так необходимо, если каждый разработчик имеет некоторый опыт работы с технологией.
• Характер продукта - если безопасность, например, вызывает большую озабоченность, возможно, потребуется отдельная группа, которая только роль определяет архитектуру безопасности. Эта область может быть достаточно большой частью работы, что один человеческий мозг не может справиться с требованиями безопасности и регулярными функциональными требованиями.
• Степень формального процесса - компании, поддерживающие критически важные приложения или большие приложения, могут иметь определенную степень строгости в процессе рассмотрения. Лично я предпочитаю, чтобы «рецензируемые обзоры» были точкой, в которой каждый проверяет решения, принятые одним человеком. Если решения противоречивы, лучше рассмотреть другой способ общения до того, как закончившаяся вещь будет завершена.
• Личность группы - Различные команды работают лучше с разными стилями управления. Я видел ситуации, когда члены команды не могли найти компромисс даже после многих месяцев совместной работы. Идея счастливой команды «штурмовать, нормировать, соответствовать, выполнять» не всегда достижима в определенные сроки. В этих случаях он собирается попасть на высокопоставленного человека с официальной властью (например, архитектором или менеджером) для принятия решений, потому что команда просто не может принять решение иначе.

Лично я считаю, что команды работают лучше, когда люди чувствуют, что они заинтересованы в решении. Гораздо проще приложить 100% усилий, когда вы твердо верите, что у вас есть рука в больших решениях, которые вы сейчас застряли. Разработка программного обеспечения - это не беспилотная работа, и если люди плывут, не принимая на себя ответственность за решения, они занимаются лишь половиной работы, потому что они не будут искать недостатки в решении или планы по преодолению этих недостатков.

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

Answer 2

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

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

Мой нынешний проект (в новой компании) - это приложение, которое я написал с нуля, и никто его еще не использует, поэтому я становлюсь диктатором и решаю, как все будет выглядеть. Я могу широко распространять изменения в коде, изменять шаблоны дизайна по своему усмотрению и переименовывать и рефакторировать объявление. И пока кому-то еще не нужно входить в код, требуется много самоконтроля, чтобы убедиться, что код будет иметь смысл для аутсайдера. Но я надеюсь, что когда я закончу, кто-то еще сможет прыгнуть прямо и взять верх. (В противном случае я буду поддерживать этот код навсегда.)

Answer 3

Худший случай, это своего рода анархия.

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

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

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

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

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

Answer 4

Кто-то должен принять окончательное решение. Иногда (часто раз) все в команде не согласятся на что-то. У хорошей команды будет «человек, останавливающийся здесь», для принятия решений, которые не имеют консенсуса или задерживаются. Много раз я призван быть тем человеком. Я делегирую большую часть принятия решений руководителям групп, которым я доверяю, но время от времени причалы не могут договориться о направлении. Я установил архитектурное руководство для компании и обеспечил ее соблюдение. Я использую вклад от каждого члена команды, это руководство и мое суждение, чтобы разбить тупики. Я бы не сказал, что он самодержавный, но это не полная демократия.

Answer 5

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

Answer 6

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