Как остановить программирование Наклона, становящееся Ковбоем, Кодирующим? [закрытый]

Что не так с ковбойским кодированием? Если вы начинаете видеть низкое качество, доставка кода занимает все больше и больше времени, не соответствует ожиданиям конечного пользователя (или того, кто его платит), то его время (и я, PM, говорю это). Когда у вас есть хорошая / солидная команда программистов, необходимость в формальном процессе отпадает - он обычно усваивается - хорошие программисты естественно следуют хорошей форме / процессу - я думаю, что для более слабых исполнителей вводится много процессов, которые многие случаи отрицательно сказываются на хороших / отличных исполнителях. Хорошему менеджеру проекта необходимо уравновесить процесс с конкретной ситуацией ... подход типа "вести / следовать / уйти с пути"

Наймите (или замените) шерифа и загоните код в ловушку, чтобы он не был просто зафиксирован, а был просмотрен всей группой.

все менее формальный процесс. В какой-то момент мы вернемся к ковбойскому кодированию ...

Ирония "процесса" Agile / Lean / Scrum заключается в том, что менее формальный процесс НЕ приведет к ковбойскому программированию.

Хотя эти методологии отдают предпочтение «людям над процессом», от процесса полностью не отказываются; управление по-прежнему требуется. В конце концов, у вас все еще есть обязательства перед своими клиентами и сроками. Эти обязательства должны обуздать коров.

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

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

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

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

Я хотел бы отметить еще несколько предупреждающих знаков:

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

Предположительно вас беспокоят эффекты ковбойского кодирования:

• Нет требований
• Нет дизайна
• Нет тестирования
• Нет отзывов от пользователей
• Нет расписания
• Не поддерживается
• Фактор шины
• ...

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

1. Никогда не забывайте свои автоматизированные модульные тесты.
2. Никогда не забывайте свои функциональные тесты.
3. Никогда не забывай свои тесты.

(Я был виноват)

Вот где проявляется ценность ScrumMaster/Lean/Agile тренера. Кто бы ни выполнял эту роль в вашей команде, он должен уметь определить, когда самодисциплина команды ослабевает, и напомнить команде об обязательствах, которые они взяли друг перед другом в отношении качества кода.

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

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

Помните, Канбан - это инструмент. Если вы не будете последовательно применять принципы Lean и Agile при его использовании, вы не получите полной пользы.

"какие процессы не могут быть безопасно какие процессы нельзя безопасно устранить в стремлении Lean устранить отходы"?

Это очень общий вопрос, на который трудно ответить точно.

Пока вы отбрасываете управленческие процессы, которые не приносят никакой пользы, вам нужно включить более технические практики, такие как те, что есть в eXtreme Programming. Большинство agile-тренеров, с которыми я общался, считают тестовую разработку, парное программирование и непрерывную интеграцию само собой разумеющимися при работе с внедрением agile. С этими техниками очень трудно избежать "ковбойского программирования". Если бы я беспокоился о том, что код может выйти из-под контроля, я бы также добавил несколько обзоров кода.

Ковбойское кодирование - это мошенническое кодирование. Единственное, что допускает мошенническое поведение, - это отсутствие надзора со стороны властей.

«Самоорганизацией» Agile часто злоупотребляют, делая этот термин практически бессмысленным, поскольку команды разработчиков оппортунистически интерпретируют его как «самоопределение».

Бережливый организационный подход к управлению может заметно отличаться от того, к чему мы привыкли, даже от Agile-команд. И все значение имеет вопрос организации и направления, а также его организационная механика.

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

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

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

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

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