blocks|key|148180|text|当你的团队中只有一个人知道或管理关于代码的事情时，你就在一个又大又漂亮的“沙龙”标志下，基本上你就是在推门。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|148181|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When something about the code is known or manageable by only one person in your group, you are under a big nice red-glowing "Saloon" sign, and you are basically pushing the doors.

blocks|key|1448480|text|想必你会担心牛仔编码的影响：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1448481|1448482|无requirements|unordered-list-item|1448483|No设计|1448484|无测试|1448485|无用户反馈|1448486|无设计|1448487|1448488|只要你有一个计划/机制/过程来避免这些不良影响，那么你就没有问题；对吧？|1448489|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|W|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|X|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|Y|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Presumably you're worried about the effects of cowboy coding:

<ul>
<li>No requirements</li>
<li>No design</li>
<li>No testing</li>
<li>No feedback from users</li>
<li>No schedule</li>
<li>Unmaintainable</li>
<li>Bus factor</li>
<li>...</li>
</ul>

So long as you have a plan/mechanism/process to avoid these ill-effects, then you're Ok; right?

blocks|key|4388045|text|作为这条线的一部分，什么时候是任务/故事/完成的工作单元的问题出现在脑海中。如果你需要测试，并且一双眼睛已经看过一些东西，这可能有助于防止流氓开发人员想要成为牛仔的情况。同样，代码是如何进入生产环境的呢？如果团队中的任何人都能心血来潮地推动代码，那对我来说将是一个警告信号。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4388046|我要注意的其他几个警告信号是：|4388047|4388048|团队是否有一个编码标准以及维护该标准的承诺？|unordered-list-item|4388049|是否有一大堆代码更改来自于一个人进行的“重构”，其他人都不认为值得？|4388050|4388051|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|P|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|Q|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|L|$]]

The question of when is a task/story/unit of work done comes to mind as part of that line. If you require tests and that a pair of eyes have looked something over that may help prevent the situation of the rogue developer that wants to be a Cowboy. Similarly, how does code get into production? If anyone on the team can push code on a whim, that would be a warning sign to my mind.

A couple of other warning signs that I'd note are:

<ul>
<li>Does the team have a coding standard and a commitment to maintain that standard?</li>
<li>Are there a bunch of code changes from one individual doing "refactoring" that no one else thinks is worthwhile?</li>
</ul>

blocks|key|4388085|text|我认为如果你保持某种类型的代码审查，它不会在这方面出太大问题。如果没有人知道其他程序员在做什么以及他们是如何做的，那么你可能已经越过了这条线。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4388086|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I suppose if you keep some kind of code review, it can't go too wrong on this side. If no one know what the other programmers are doing and how they're doing it, then you might have crossed this line.

blocks|key|1450432|text|可能没有明确的警告信号列表，如果你看到这些信号，就会告诉你你处于牛仔的领地。就我个人而言，如果人们发布未经测试的代码，开发不被明确理解的功能，或者以任何方式仓促工作或忽略警告信号，我就会感到担忧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1450433|最好使用你自己的判断。希望，既然你问了这个问题你就是当警长的合适人选。|1450434|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

There's probably no definitive list of warning signs which if you see tell you you're in cowboy territory. Personally, if people are releasing untested code, developing features which aren't definitely understood, or in anyway rushing work or ignoring warning signs I get worried.

Better to use your own judgement. Hopefully, since you're asking the question you're the right person to be sheriff.

blocks|key|1171923|text|牛仔编码就是流氓编码。唯一允许流氓行为的是缺乏权威机构的监督。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1171924|敏捷的“自组织”经常被滥用到使这个术语变得毫无意义的地步，因为开发团队机会主义地将其重新解释为“自我决定”。|1171925|精益组织的管理方法可能与我们习惯的方法有很大的不同-即使是来自敏捷团队。正是这个组织和方向的问题以及它的组织机制造成了所有的不同。|1171926|在软件中采用精益产品开发还很年轻，不幸的是，它受到看板分心的影响。但这是意料之中的--一个方法的最可外部化的方面通常是首先被识别和采用的，而这些通常是最机械的方面。看板是精益的机械部分。但这只是其中一部分。|1171927|与敏捷相比，精益是一种组织变革。如果你不改变董事在组织中的角色，那么你很可能最终只会接触到精益的最重要和最机械的方面，而且很可能是以最天真的方式。|1171928|为了防止任何组织中的任何人变得无赖，他们需要被引导去实现期望。然而，在精益组织中，总监的角色不仅仅是欺凌弱小。精益组织(开发团队等)中的主管也是一名技术熟练的工人，能够向其他人传授必要的技能，从而更加精通地实现他们所承担的责任的期望。|1171929|您设置的任何特定流程(代码评审、配对、激励等)都取决于太多因素，这些因素在您考虑的特定时刻对您的组织来说是特定的。努力的负责人应该了解如何利用整个团队的集体脑力来找到好的解决方案或探索、实验和学习的途径，并做出最好的决定-即使这偶尔意味着与集体相矛盾(特别是如果集体是以精益的方式年轻的话)。|1171930|除非你的组织完全被精益的知识唯物主义分散了注意力，比如Kanban。如果你让人变得无法无天，你不是有方法问题，而是组织问题。如果你遇到了组织问题，你就不可避免地会遇到董事职位的问题，以及对权力的无效使用的问题。|1171931|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|V|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

Cowboy coding is rogue coding. The only thing that allows rogue behavior is an absence of oversight by an authority.

Agile's "Self-Organization" is often abused to the point of rendering the term mostly meaningless as development teams opportunistically re-interpret it to mean "Self-Determination".

A Lean organizational approach to management can be a marked difference from what we're used to - even from Agile teams. And it's this issue of organization and direction and its organizational mechanics that makes all the difference.

The adoption of Lean Product Development in software is still quite young, and unfortunately suffers quite a bit from distraction-by-Kanban. But this is to be expected - the most externalizable aspects of a method are usually the first to be recognized and adopted, and these are usually the most mechanical aspects. Kanban is a flagrantly mechanical part of Lean. But it's only one part.

Lean is an organizational change much more than Agile was. If you don't change the role of directors in the organization, then you'll likely just end up accessing only the most material and mechanical aspects of Lean, and likely in the most naive ways.

To keep anyone in any organization from going rogue, they need to be directed to fulfill expectations. The role of the director in a Lean organization isn't just a bully, though. A director in a Lean organization (development team, etc) is also a skilled worker and is capable of teaching others the skills necessary to become ever-more proficient at fulfilling the expectations that they have accepted responsibility for.

Whatever specific processes you put in place (code reviews, pairing, incentives, etc) depend on far too many factors that are particular to your organization at the particular moment that you happen to be considering them. The effort's director should understand how to enlist the collective brain power of the whole team to find good solutions or avenues of exploration, experimentation, and learning, and to make a decision for the best - even if it occasionally means contradicting the collective (especially if the collective is young in Lean ways).

Unless your organization gets utterly distracted from weak directorship problems by Lean intellectual materialism, like Kanban, for example. If you've got people going rogue, you don't have a methodology problem, you've got an organizational problem. And if you've got an organizational problem, you've inevitably got a directorship problem, and a problem of unproductive uses of authority.

blocks|key|4388151|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4388152|永远不会忘记您的自动化单元测试。|ordered-list-item|4388153|不会忘记您的功能测试。|4388154|永远不会忘记您的测试。|4388155|4388156|(我很内疚)|4388157|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|N|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|O|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|P|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|Q|7|@]|8|@]|9|$]]|$1|I|3|J|4|5|6|R|7|@]|8|@]|9|$]]|$1|K|3|-4|4|5|6|S|7|@]|8|@]|9|$]]]|L|$]]

<ol>
<li>Never forget your automated unit tests.</li>
<li>Never forget your functional tests.</li>
<li>Never forget your tests.</li>
</ol>

(I've been guilty)

blocks|key|148886|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|148887|有越来越少的正式流程。在某种程度上，我们将回到牛仔编码...|blockquote|148888|148889|148890|敏捷/精益/Scrum“过程”的讽刺之处在于，不那么正式的过程不会导致牛仔编程。|148891|虽然这些方法更喜欢“人而不是过程”，但过程并没有完全被抛弃；管理仍然是必需的。归根结底，你仍然要对你的客户和最后期限做出承诺。这些承诺应该控制母牛。|offset|length|style|BOLD|148892|entityMap^0|0|0|0|0|0|6|3|0^^$0|@$1|2|3|-4|4|5|6|P|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Q|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|R|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|S|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|T|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|U|7|@$J|V|K|W|L|M]]|8|@]|9|$]]|$1|N|3|-4|4|5|6|X|7|@]|8|@]|9|$]]]|O|$]]

<blockquote>
 there is less and less formal process. At some point we will be back to Cowboy Coding...
</blockquote>

The irony of Agile/Lean/Scrum "process" is that less formal process will NOT lead to cowboy programming. 

While these methodologies prefer "people over process", process is not completely abandoned; management is still required. An at the end of the day you still have a commitment to your customers and deadlines. These commitments should rein in the cows.

blocks|key|1448600|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1448601|“在精益消除浪费的运动中，哪些过程不能被安全地消除”？|blockquote|1448602|1448603|1448604|这是一个非常普遍的问题，很难准确回答。|1448605|当您丢弃不产生任何价值的管理流程时，您需要包括更多的技术实践，比如eXtreme编程中的那些实践。与我交谈过的大多数敏捷教练认为，测试驱动开发、结对编程和持续集成在他们从事敏捷采用工作时都是既定的。使用这些技术很难逃脱“牛仔编程”的惩罚。如果我担心代码失控，我也会加入一些代码审查。|1448606|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|M|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|P|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|Q|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|R|7|@]|8|@]|9|$]]]|K|$]]

<blockquote>
 "what processes cannot be safely
 eliminated in Lean's drive to
 eliminate waste"?
</blockquote>

That's a very general question which is hard to answer precisely.

While you are throwing out management processes that produce no value, you need to include more technical practices such as those found in eXtreme Programming. Most agile coaches I have talked to consider Test Driven Development, Pair Programming and Continuous Integration to be a given when they are working with agile adoption. It is very tough to get away with "cowboy programming" with these techniques in place. If I were worried about the code getting out of hand, I'd throw in some code reviews as well.

blocks|key|1171624|text|雇佣(或委派)一名警长，并将代码围栏起来，这样代码不仅会被提交，而且会被整个团队查看。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1171625|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Hire (or deputize) a sheriff, and corral the code so that it doesn't just get committed but rather gets looked at by the whole posse.

blocks|key|1171822|text|这就是ScrumMaster/精益/敏捷教练的价值所在。无论谁在你的团队中担任这个角色，都应该能够检测到团队的自律在何时下滑，并提醒团队他们对彼此所做的关于代码质量的承诺。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1171823|你可以做的另一件事是调整容器。将代码评审添加到看板中，然后对其进行限制，以确保完成。更好的是，要求所有代码在几周内成对编写，以便重新养成良好的习惯，没有人可以声称拥有代码部分的所有权。|1171824|最后，考虑到您离开正式的Scrum过程可能有点为时过早。Scrum的规则是教你一种完全不同的思考和工作方式。如果精益和敏捷的价值观还没有在你的团队中根深蒂固，那么很容易回到旧习惯中去。这就是严格执行Scrum规则可以帮助您的地方，直到您的团队准备就绪。|1171825|记住，看板是一种工具。如果你没有始终如一地将精益和敏捷原则应用到它的使用中，你就不会获得全部的好处。|1171826|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Here's where the value of a ScrumMaster/Lean/Agile coach comes in. Whoever fills that role on your team should be able to detect when the team's self discipline is slipping and remind the team of the commitment they've made to each other about the quality of their code.

The other thing you can do is adjust the containers. Add code reviews to your Kanban board and then put a limit on it to ensure it gets done. Better yet, require all code to be written in pairs for a few weeks so that good habits get reenforced and no one can claim ownership on sections of the code.

Finally, consider that perhaps your move away from the formal process of Scrum was a bit premature. The rules of Scrum are there to teach you a completely different way of thinking and working. If the values of Lean and Agile haven't been ingrained in your team yet, it's very easy to slip back into old habits. This is where the strict enforcement of the rules of Scrum can help you until your team is ready.

Remember, Kanban is a tool. If you are not consistently applying Lean and Agile principles to its usage, you won't get the full benefit.

blocks|key|1171992|text|精益和敏捷都涉及在一个非常具体的上下文中最小化浪费:交付价值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1171993|如果你停止使用帮助你有效创造价值的过程，那么你要么创造更少的价值，要么创造价值的速度更慢。|1171994|由于精益和敏捷技术都涉及到衡量您在价值生产中的进展情况，因此您应该能够判断您何时越过了这条线，并消除了有用的实践。|1171995|如果您没有使用速度或周期时间来衡量您的价值交付，那么您已经越界了！|1171996|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Both Lean and Agile involve minimising waste in a very specific context: delivering value.

If you stop using processes that help you efficiently produce value, then you will either produce less value or produce value less quickly. 

Since both Lean and Agile techniques involve measuring how you are progressing in the production of value, you should be able to tell when you cross the line and eliminate a useful practice.

If you're not using velocity or cycle time to measure your delivery of value, then you have already crossed the line!

blocks|key|1171780|text|牛仔编码有什么问题？如果你开始看到质量差，代码交付花费的时间越来越长，没有达到最终用户的期望(或者是谁在付钱)，那么是时候了(我是一位PM+)。当你有一个好的/可靠的编程团队时，就不需要正式的过程了--它通常是内化的--好的程序员自然会遵循好的形式/过程--我认为很多过程都是为表现较差的人准备的，这在许多情况下会对好的/好的表现者产生负面影响。一个好的项目经理需要根据具体的情况来平衡流程……领导/跟随/避开类型的方法|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1171781|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

What's wrong with Cowboy coding? If you start to see poor quality, code delivery taking longer and longer, not meeting end user expectations (or whoever is paying), then its time (and I'm a PM saying this). When you have a good/solid programming team, the need for formal process isn't needed - its usually internalized - good programmers follow good form/process naturally - I think that a lot of process is put in place for the weaker performers which in many cases negatively impacts the good/great performers. A good project manager needs to balance process to the specific situation...lead/follow/get-out-of-the-way type of approach

blocks|key|149043|text|让客户参与进来，这样你就不会在BAU预算下编写一个业务实际上并不想要的理论系统？更多地与您的经理交谈。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|149044|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Engage the customer perhaps, so you dont write a theoretical system under a BAU budget that the business dont actually want? Talk to your manager(s) more.

My team has been progressively adopting more and more lightweight methodologies, moving from Scrum to Lean/Kanban where there is less and less formal process. At some point we will be back to Cowboy Coding; indeed I fear we may already be on the border line.

Where can the line be drawn between a very lightweight Lean and Agile process and anarchy? How will we know when we have crossed the line? And how can we prevent ourselves from crossing the line?

The question might also be phrased as, 'what processes cannot be safely eliminated in Lean's drive to eliminate waste'?

How to stop Lean programming becoming Cowboy Coding?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我的团队已经逐渐采用了越来越多的轻量级方法，从Scrum转移到精益/看板，在那里正式的过程越来越少。在某种程度上，我们将回到牛仔编码；实际上，我担心我们可能已经在边界线上了。如何在非常轻量级的精益和敏捷流程与无政府状态之间划清界限？我们怎么知道我们什么时候越界了呢？我们怎样才能防止自己越界呢？这个问题也可能被表述为，“在精益消除浪费的努力中，哪些过程不能被安全地消除”？

问如何阻止精益编程成为牛仔编码？
EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何阻止精益编程成为牛仔编码？EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何阻止精益编程成为牛仔编码？
EN