there is less and less formal process. At some point we will be back to Cowboy Coding...
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.
"what processes cannot be safely eliminated in Lean's drive to eliminate waste"?
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.
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.
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!
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
或许可以吸引客户，这样你就不会在 BAU 预算下编写业务实际上并不想要的理论系统？ 多与您的经理交谈。
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.
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.
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:
Does the team have a coding standard and a commitment to maintain that standard?
Are there a bunch of code changes from one individual doing "refactoring" that no one else thinks is worthwhile?
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.
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.
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.
发布评论
评论（14）
（我已经有罪了）
(I've been guilty)
敏捷/精益/Scrum“流程”的讽刺之处在于，不太正式的流程不会导致牛仔编程。
虽然这些方法更喜欢“人胜于流程”，但流程并没有完全被放弃； 还是需要管理的。 归根结底，您仍然对客户和截止日期有承诺。 这些承诺应该能够约束奶牛。
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.
这是一个非常普遍的问题，很难准确回答。
当你抛弃没有价值的管理流程时，你需要纳入更多的技术实践，例如极限编程中的技术实践。我接触过的大多数敏捷教练当他们采用敏捷时，考虑测试驱动开发、结对编程和持续集成，如果我担心代码会脱离，那么很难摆脱“牛仔编程”的束缚。另一方面，我也会进行一些代码审查。
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.
雇用（或代理）一名治安官，并整理代码，这样它不仅会被提交，而且会受到整个团队的审查。
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.
这就是 ScrumMaster/精益/敏捷教练的价值所在。无论谁在团队中担任该角色，都应该能够发现团队的自律何时出现下滑，并提醒团队他们彼此之间做出的承诺。他们的代码质量。
您可以做的另一件事是调整容器。 将代码审查添加到您的看板中，然后对其进行限制以确保其完成。 更好的是，要求所有代码在几周内成对编写，以便强化良好的习惯，并且没有人可以声称拥有代码部分的所有权。
最后，考虑一下您放弃 Scrum 正式流程的时机可能还为时过早。 Scrum 的规则是为了教你一种完全不同的思维和工作方式。 如果精益和敏捷的价值观尚未在您的团队中根深蒂固，那么很容易回到旧习惯。 这就是严格执行 Scrum 规则可以为您提供帮助的地方，直到您的团队做好准备。
请记住，看板是一种工具。 如果您没有始终如一地将精益和敏捷原则应用于其使用，您将无法获得全部好处。
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.
精益和敏捷都涉及在一个非常具体的环境中最大限度地减少浪费：创造价值。
如果您停止使用帮助您有效创造价值的流程，那么您将产生更少的价值或更快地产生价值。
由于精益和敏捷技术都涉及衡量您在价值生产方面的进展情况，因此您应该能够判断何时越线并消除有用的实践。
如果您不使用速度或周期时间来衡量您的价值交付，那么您已经越界了！
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!
牛仔编码有什么问题？ 如果您开始发现质量很差，代码交付时间越来越长，无法满足最终用户的期望（或任何付费者），那么是时候了（我是一名产品经理，这么说）。 当你拥有一个良好/可靠的编程团队时，不需要正式的流程 - 它通常是内化的 - 优秀的程序员自然地遵循良好的形式/流程 - 我认为很多流程是为表现较差的人制定的许多情况下会对表现良好/表现出色的人产生负面影响。 一个好的项目经理需要根据具体情况平衡流程……领导/跟随/回避类型的方法
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
或许可以吸引客户，这样你就不会在 BAU 预算下编写业务实际上并不想要的理论系统？ 多与您的经理交谈。
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.
当您的团队中只有一个人知道或可以管理有关代码的某些内容时，您就站在一个巨大的漂亮的红色发光“沙龙”标志下，并且您基本上是在推门。
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.
想必您担心牛仔编码的影响：
只要您有一个计划/机制/流程可以避免这些不良影响，那就没事了； 正确的？
Presumably you're worried about the effects of cowboy coding:
So long as you have a plan/mechanism/process to avoid these ill-effects, then you're Ok; right?
作为该行的一部分，我想到了任务/故事/工作单元何时完成的问题。 如果您需要测试并且一双眼睛已经看过一些东西，这可能有助于防止流氓开发人员想要成为牛仔的情况。 同样，代码如何投入生产？ 如果团队中的任何人可以随心所欲地推送代码，这对我来说将是一个警告信号。
我要注意的其他几个警告信号是：
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:
我想如果你保持某种代码审查，这方面就不会出错。 如果没有人知道其他程序员在做什么以及他们是如何做的，那么您可能已经跨越了这条线。
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.
可能没有明确的警告标志列表，如果您看到这些标志，就会告诉您您已进入牛仔领域。 就我个人而言，如果人们发布未经测试的代码，开发尚未明确理解的功能，或者以任何方式匆忙工作或忽略警告信号，我会感到担心。
最好使用自己的判断。 希望既然你问了这个问题，你就是担任警长的合适人选。
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.
牛仔编码是流氓编码。 唯一允许流氓行为发生的是缺乏权威机构的监督。
敏捷的“自组织”经常被滥用，以至于使该术语几乎毫无意义，因为开发团队会机会主义地将其重新解释为“自决”。
精益组织的管理方法可能与我们习惯的方法（甚至敏捷团队的方法）有显着差异。 正是组织和方向及其组织机制的问题造成了一切的不同。
软件中精益产品开发的采用还很年轻，不幸的是，它受到看板干扰的影响很大。 但这是可以预料到的——方法的最外化的方面通常是最先被认识和采用的，并且这些通常是最机械的方面。 看板是精益的明显机械部分。 但这只是一部分。
精益是一种比敏捷更重要的组织变革。 如果你不改变组织中董事的角色，那么你最终可能只会接触到精益最物质和机械的方面，而且很可能是以最幼稚的方式。
为了防止任何组织中的任何人变得流氓，需要引导他们满足期望。 然而，在精益组织中，总监的角色不仅仅是一个恶霸。 精益组织（开发团队等）的主管也是一名熟练的工人，并且能够教授其他人必要的技能，以便更加熟练地满足他们所承担的责任的期望。
无论您采取什么具体流程（代码审查、配对、激励等），都取决于您的组织在您碰巧考虑这些流程时所特有的太多因素。 这项工作的负责人应该了解如何调动整个团队的集体智慧来找到好的解决方案或探索、实验和学习的途径，并做出最好的决定——即使这有时意味着与集体相矛盾（特别是如果集体在精益方面还很年轻）。
除非你的组织因精益知识唯物主义（例如看板）而完全分散了对薄弱董事问题的注意力。 如果有人作恶，那不是方法论问题，而是组织问题。 如果你遇到了组织问题，那么你就不可避免地遇到了董事问题，以及无效地使用权力的问题。
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.