24

我的团队一直在逐步采用越来越多的轻量级方法，从 Scrum 转向精益/看板，那里的正式流程越来越少。在某个时候，我们将回到 Cowboy Coding；事实上，我担心我们可能已经在边界线上。

在非常轻量级的精益和敏捷流程与无政府状态之间可以划清界限吗？我们怎么知道我们什么时候越界了？我们如何防止自己越界？

这个问题也可以表述为，“在精益消除浪费的努力中，哪些流程不能安全地消除”？

4

14 回答 14

24

当您的团队中只有一个人知道或可以管理有关代码的某些内容时，您就处于一个漂亮的红色发光“轿车”标志下，并且您基本上是在推门。

于 2009-07-23T21:37:57.303 回答
14

大概你担心牛仔编码的影响：

  • 无要求
  • 没有设计
  • 没有测试
  • 没有用户反馈
  • 没有时间表
  • 不可维护
  • 总线因素
  • ...

只要您有一个计划/机制/流程来避免这些不良影响，那么您就可以了；对？

于 2009-07-23T21:56:11.153 回答
4

作为该行的一部分，何时完成任务/故事/工作单元的问题浮现在脑海中。如果您需要测试并且一双眼睛已经看过一些东西，这可能有助于防止想要成为牛仔的流氓开发人员的情况。同样，代码如何投入生产？如果团队中的任何人都可以随心所欲地推送代码，那对我来说将是一个警告信号。

我要注意的其他几个警告信号是：

  • 团队是否有编码标准并承诺维护该标准？
  • 是否有一堆代码更改来自一个人进行“重构”而其他人认为不值得？
于 2009-07-23T21:40:43.837 回答
3

我想如果你保持某种代码审查，这方面不会出错。如果没有人知道其他程序员在做什么以及他们是如何做的，那么你可能已经越过了这条线。

于 2009-07-23T21:41:05.740 回答
2

可能没有明确的警告标志清单，如果您看到这些标志说明您处于牛仔领域。就个人而言，如果人们发布未经测试的代码，开发未明确理解的功能，或者无论如何匆忙工作或忽略警告信号，我会感到担心。

最好用你自己的判断。希望，既然你在问这个问题，那么你就是合适的人选。

于 2009-07-23T21:45:42.110 回答
2

牛仔编码是流氓编码。唯一允许流氓行为的是当局没有监督。

敏捷的“自组织”经常被滥用到使该术语几乎毫无意义的地步，因为开发团队机会主义地将其重新解释为“自决”。

精益组织管理方法可能与我们习惯的方法有显着差异——即使是敏捷团队也是如此。正是这个组织和方向问题及其组织机制使一切变得不同。

在软件中采用精益产品开发还很年轻，不幸的是，看板会分散很多注意力。但这是意料之中的——一种方法最可外化的方面通常是最先被认可和采用的，而这些通常是最机械的方面。看板是精益的一个明显的机械部分。但这只是一部分。

与敏捷相比，精益是一种组织变革。如果您不改变组织中主管的角色，那么您最终可能只会访问精益的最物质和机械方面，并且可能以最幼稚的方式。

为了防止任何组织中的任何人流氓，他们需要被引导去满足期望。然而，主管在精益组织中的角色不仅仅是一个恶霸。精益组织（开发团队等）中的主管也是一名技术工人，能够教授其他人必要的技能，以便更加熟练地满足他们承担责任的期望。

无论您实施何种具体流程（代码审查、配对、激励等），都取决于在您碰巧考虑它们的特定时刻您的组织所特有的太多因素。努力的主管应该了解如何利用整个团队的集体脑力来找到好的解决方案或探索、实验和学习的途径，并做出最好的决定——即使这偶尔意味着与集体相矛盾（尤其是如果集体在精益方面很年轻）。

除非您的组织因精益知识唯物主义（例如看板）而完全分心于薄弱的董事管理问题。如果你让人们流氓，你没有方法问题，你有一个组织问题。如果你有一个组织问题，你不可避免地会遇到一个董事问题，以及一个非生产性使用权力的问题。

于 2010-07-11T23:50:45.157 回答
1
  1. 永远不要忘记您的自动化单元测试。
  2. 永远不要忘记您的功能测试。
  3. 永远不要忘记您的测试。

（我有罪）

于 2009-07-23T21:48:29.030 回答
1

正式程序越来越少。在某个时候，我们将回到牛仔编码......

敏捷/精益/Scrum“过程”的讽刺之处在于，不太正式的过程不会导致牛仔编程。

虽然这些方法更喜欢“人胜过流程”，但流程并没有被完全抛弃；还是需要管理的。归根结底，您仍然对客户和截止日期做出承诺。这些承诺应该控制奶牛。

于 2009-07-24T08:40:07.490 回答
1

“在精益消除浪费的努力中，哪些流程不能安全消除”？

这是一个非常笼统的问题，很难准确回答。

当您抛弃没有价值的管理流程时，您需要包括更多的技术实践，例如在极限编程中发现的那些。与我交谈过的大多数敏捷教练在采用敏捷时都认为测试驱动开发、结对编程和持续集成是给定的。使用这些技术很难摆脱“牛仔编程”。如果我担心代码失控，我也会进行一些代码审查。

于 2010-06-07T11:19:05.533 回答
0

雇用（或代理）一名警长，并把代码圈起来，这样它不仅会被提交，而且会被整个团队查看。

于 2009-07-23T21:56:10.670 回答
0

这就是 ScrumMaster/Lean/Agile 教练的价值所在。在您的团队中担任该角色的任何人都应该能够发现团队的自律何时下滑，并提醒团队他们对彼此做出的承诺他们的代码质量。

您可以做的另一件事是调整容器。将代码审查添加到您的看板，然后对其进行限制以确保其完成。更好的是，要求所有代码成对编写几个星期，这样好习惯得到加强，没有人可以声称对代码部分的所有权。

最后，考虑一下，也许你离开 Scrum 的正式流程有点为时过早。Scrum 的规则可以教你一种完全不同的思维和工作方式。如果精益和敏捷的价值观尚未在您的团队中根深蒂固，那么很容易重新陷入旧习惯。这就是在您的团队准备好之前，严格执行 Scrum 规则可以帮助您的地方。

请记住，看板是一种工具。如果您没有始终如一地将精益和敏捷原则应用于其使用，您将无法获得全部收益。

于 2010-05-01T03:43:03.993 回答
0

精益和敏捷都涉及在非常具体的环境中最大限度地减少浪费：交付价值。

如果您停止使用可帮助您有效产生价值的流程，那么您将产生更少的价值或更快地产生价值。

由于精益和敏捷技术都涉及衡量您在价值生产方面的进展情况，因此您应该能够判断何时越界并消除有用的实践。

如果您没有使用速度或周期时间来衡量您的价值交付，那么您已经越界了！

于 2012-04-23T10:05:47.133 回答
-1

牛仔编码有什么问题？如果您开始看到质量差，代码交付时间越来越长，无法满足最终用户的期望（或支付费用的人），那么是时候了（我是 PM 这么说的）。当你有一个优秀/稳固的编程团队时，不需要正式的流程——它通常是内化的——优秀的程序员自然会遵循良好的形式/流程——我认为很多流程都是为表现较弱的人制定的许多情况对表现良好/表现出色的人产生负面影响。一个好的项目经理需要根据具体情况来平衡过程……引导/跟随/避开类型的方法

于 2009-07-24T17:41:39.107 回答
-1

也许让客户参与进来，所以您不会在业务实际不想要的 BAU 预算下编写理论系统？多和你的经理谈谈。

于 2011-01-28T16:01:29.413 回答