Неправильное понимание коллективной собственности в Agile-среде [закрыто]

Насколько я понимаю, коллективная собственность решит общие проблемы с устаревшим, такие как качество, отказ из-за отсутствия и обмен знаниями.

Однако есть некоторые вещи, которые я не понимаю.

  1. Является ли команда демократией? Если да, то что, если большинство ошибается?
  2. Зачем выбирать техническую корректность, а не «человеческую корректность»? т.е. то, что технически правильно, может быть не самым мотивирующим/приятным выбором для людей, работающих над проектом. Недовольная команда с большей вероятностью создаст плохое качество, чем мотивированная команда.
  3. Как насчет индивидуального творчества, понимания, исследования и экспериментирования? Скорее всего, ими будут пренебрегать, если единственные решения, которые принимаются, основаны на взаимном согласии.
  4. Как обрабатывается мошенническая активность? Например, если проект выполнен на 99% и вся команда, за исключением одного человека, уходит в отпуск на следующий день, что мешает этому человеку изменить вещи, которые уже были согласованы во время сеансов парного программирования, непосредственно перед выполнением последнего 1%? ?
  5. Не увеличится ли время производства кода в разы? Если вся команда должна изучить весь код, который создается, то технически одновременно может создаваться только одна вещь.

Изменить : добавлены пункты 4 и 5.

Это несколько вопросов. Хотя они могут быть смутно связаны, это явно разные вопросы, которые следует задавать отдельно, чтобы не быть слишком широкими. Кроме того, тема кросс-функциональной команды против индивидуализма в проектах заполняет целые книги и явно слишком широка, если не сужается до конкретной проблемы, с которой вы сталкиваетесь.
Ветки комментариев ко всем ответам выходят из-под контроля. PMSE — это сайт вопросов и ответов, а не дискуссионный форум. Пожалуйста, используйте комментарии только для уточнения или улучшения ответов; все остальное надо перенести в чат .

Ответы (3)

«Коллективное владение кодом» не означает, что каждый в команде имеет право голоса по каждой написанной строке кода. Код по-прежнему пишут отдельные люди (если только вы не занимаетесь парным программированием), и они принимают решения, которые считают лучшими в данный момент. Дело в том, что ни один человек не «владеет» разделом кода.

Если Джон написал модуль Foo, и по какой-то причине в его отсутствие была обнаружена критическая ошибка, ничто не должно мешать Сью вмешаться и исправить ее. Это не "код Джона", это команды.

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

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

Что касается пункта 3, эксперименты, исследования и т. д. принадлежат прототипам и личным проектам, а не производственному коду.

Если это не делается построчно, тогда, когда Джон работает над кодом, это решение Джона. Когда Сью работает над кодом Джона, это решение Сью, поскольку они могут изменить код в соответствии со своими предпочтениями? В вашем ответе на пункт 3 такой менталитет приведет к тому, что никто никогда не захочет работать дольше и усерднее, поскольку их работа всегда будет просто жертвой, а не захватывающей возможностью. Я не думаю, что это надежно или эффективно. В принципе, я считаю, что правильность должна быть с людьми, а не с технологиями, потому что счастливые люди делают хорошие технологии, а не наоборот.
Когда Джон работает над кодом, это решение команды, когда Сью работает над ним, это также решение команды. Если Сью вносит несвязанные изменения исключительно из личных предпочтений, то она действует эгоистично и противоречит интересам команды.
Для пункта 3: код может быть творческим, экспериментальным и частью прототипа утром, а к вечеру быть хорошо документированным и четко написанным куском производственного кода. Дело в том, что если вы запускаете в производство код, с которым никто другой не может работать, то вы не работаете в команде.
Джон и Сью не могут читать мысли друг друга, и поэтому им придется делать предположения в отсутствие друг друга. Если это выбор между потенциально неверными предположениями и предпочтениями, почему бы не отдать предпочтение? Творчество подразумевает, что другим придется учиться, поскольку это что-то новое. Я не думаю, что это означает, что Джон или Сью не являются командными игроками, я думаю, это просто означает, что они изобрели новый и эффективный способ сделать что-то, что команда еще не поняла. Зачем наказывать за инновации?
@ThreaT: Построчно не может быть никаких предположений. Компьютер не может читать мысли и делать предположения. На более высоком уровне дизайна вы можете быть «излишне умным» (чего следует избегать) или действительно новаторским. В последнем случае, поскольку Джон знает, что Сью может работать над одним и тем же кодом, Джон должен должным образом задокументировать свой проект, чтобы Сью могла понять его, не делая предположений. Это также может помочь ему вспомнить, какие хитрые уловки он проделывал год назад.
@BartvanIngenSchenau: Кажется, что коллективная собственность всегда приводит к выбору общего подхода на этапе проектирования, что никогда не допускает творчества.
@ThreaT «фаза проектирования» кричит о водопаде, а не о гибкости. Я думаю, у вас слишком драконовское представление о том, что подразумевается под «коллективной собственностью». Просто пишите код, как обычно, но имейте в виду, что над ним должны будут поработать другие (комментарии, чистота и т. д.), не расстраивайтесь, когда кто-то его редактирует, и не бойтесь редактировать код, который «не подходит». твой". Речь идет о том, чтобы отложить в сторону эго и работать в команде.
@MikeGossmann: Я думаю, что это очень демотивирует, если кто-то не боится пойти и изменить ваш код, чтобы сделать его более «стандартизированным», пока вы находитесь в процессе создания чего-то нового. Наверняка должны быть какие-то сроки, границы и альфа-владелец / окончательный решающий, иначе это просто анархия, и никто не будет счастлив и мотивирован?
@ThreaT: Люди не вникают в код, чтобы сделать его более нормализованным, так как на такую ​​«праздную работу» обычно нет времени. И должно быть общение между разработчиками, чтобы избежать конфликтов. Если я работаю над большим изменением классов X, Y и Z и вижу в бэклоге вторую функцию, связанную с одним из этих классов, то я бы предупредил, что команду следует оставить в покое, пока я не закончу свое большое изменение. После того, как я закончу, любой может начать с этой другой функции.
  1. Что делать, если большинство ошибается

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

  1. Почему предпочли техническую правильность человеческой правильности

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

  1. Пренебрегают ли индивидуальным талантом

Хорошая команда ищет способы сделать хорошую работу. Они будут делать это как путем сотрудничества, так и путем укрепления сильных сторон отдельных членов команды.

  1. Как обрабатывается мошенническая активность

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

Хороший ответ. Я хотел бы, чтобы вы расширили пункт 3, прежде чем признать его правильным. Я до сих пор не понимаю, как индивидуальный рост поощряется коллективной собственностью.
Многое будет зависеть от личностей членов команды. Если они открыты и неконфронтационны, то они увидят потенциал человека и будут развивать его. Ключ в том, чтобы иметь быстрый подход и отсутствие взаимных обвинений, когда что-то идет плохо. Ретроспективы будут отзывами о том, что было хорошо, а что плохо. Если человек делает что-то, что действительно помогает, он должен быть упомянут в ретроспективах. Позитивная команда будет стремиться поддержать этот успех.
@BarnbyGolden: По моему опыту, доска спринтов каждый раз имеет приоритет над ретроспективой. Даже если вы упомянете что-то в ретроспективе, маловероятно, что вам будет предоставлена ​​возможность делать что-то новое творчески самостоятельно, вместо того, чтобы делать что-то коллективно.
Постоянное совершенствование — это сердце процесса Scrum. Если людям трудно добиться принятия мер по предлагаемым улучшениям, может возникнуть проблема с тем, как проводятся ретроспективы. Но если люди предлагают изменения, важно, чтобы они также описали, как это изменение улучшит ситуацию, и, что не менее важно, как они могут измерить это изменение. При наличии аргументированного аргумента и определенной меры успеха команда обычно позволяет осуществить изменение. Если команда не хочет пробовать, это говорит об отсутствии доверия и о том, что они упускают преимущества Agile.
Не всегда возможно посоветовать, как исследование обязательно улучшит ситуацию, потому что вы не узнаете, пока не попробуете. Исследование новых идей может потерпеть неудачу, но также может оказаться действительно полезным. Даже если в ретроспективе вы поднимете вопрос об отсутствии креативности, если есть более приоритетные задачи, которые требуются постоянно, креативность всегда будет отложена в сторону. Одна из возможностей — позволить разработчикам делать что-то в одиночку время от времени, но это явно противоречит коллективной собственности.
Хорошие ответы. Коллективная собственность заключается в том, что члены команды поддерживают друг друга и могут поддерживать свой продукт, даже когда людей нет. 1, 2 и 4 — проблемы групповой динамики, которые верны независимо от того, работаете ли вы в гибкой среде. Для № 3 среда Agile должна поощрять культуру обучения и контролируемого экспериментирования. Это должно создать возможности для изучения вариантов. Конечно, можно предположить, что организационная динамика вынуждает команду срезать углы и выбирать первый вероятный путь, независимо от качества, но это будет плохой agile-реализацией.
  1. Что делать, если большинство ошибается?

Ничего страшного, если это произойдет! Идея состоит в том, чтобы «быстро ошибаться», адаптироваться, обновлять свой план и двигаться дальше, пробуя что-то еще. Концепция «быстрого провала» — это просто еще один способ применить научный метод к вашей работе.

Пока отвечаю только на первый вопрос, я на мобильном телефоне.

Неправильное понимание коллективной собственности в Agile-среде [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v