如何停止精益编程成为牛仔编码?[关闭]

当你的团队中只有一个人知道或者可以管理代码时,你就处在一个大的、漂亮的、红色发光的“酒馆”标志下,你基本上是在推门。

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

• 没有要求
• 没有设计
• 没有测试
• 没有来自用户的反馈
• 没有时间表
• 不可维护的
• 总线因子
• …

只要你有一个计划/机制/流程来避免这些不良影响,那么你就没事了;对吧?

作为这一行的一部分,我们想到的问题是什么时候完成一个任务/故事/工作单元。如果您需要测试,并且一双眼睛已经检查过一些东西,这可能有助于防止想要成为牛仔的流氓开发人员的情况。同样,代码是如何进入生产的?如果团队中的任何人能突发奇想地推动代码,那将是我头脑中的一个警告信号。

我注意到的其他几个警告标志是:

• 团队是否有编码标准和维护该标准的承诺?
• 有没有一个人在做“重构”时对代码进行了一系列别人认为不值得做的更改?

我想,如果您继续进行某种代码检查,在这方面不会出错。如果没有人知道其他程序员在做什么以及他们是如何做的,那么您可能已经越过了这条线。

可能没有明确的警告标志列表,如果你看到这些警告标志,你就会知道你在牛仔区。就个人而言,如果人们正在发布未经测试的代码,开发那些不被明确理解的特性,或者不管怎样,在匆忙的工作中,或者忽略我担心的警告标志。

最好用你自己的判断。希望,既然你在问这个问题,你是成为治安官的合适人选。

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

敏捷的“自我组织”经常被滥用到使这个术语毫无意义的程度,因为开发团队机会主义地将其重新解释为“自我决定”。

精益的组织管理方法可能与我们过去习惯的方法有显著的区别,甚至与敏捷团队也不一样。正是这个组织和方向的问题,以及它的组织机制,造成了所有的不同。

在软件中采用精益产品开发还很年轻,不幸的是,它受到了看板的干扰。但这是意料之中的——一种方法最外部化的方面通常是第一个被识别和采用的,而这些通常是最机械的方面。看板是精益的一个明显的机械部分。但这只是其中的一部分。

精益是一种比敏捷更重要的组织变革。如果你不改变主管在组织中的角色,那么你最终可能只会接触到精益最重要的物质和机械方面,而且很可能以最幼稚的方式。

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

无论您实施了什么特定的过程(代码审查、配对、激励等),都要依赖于太多的因素,这些因素在您碰巧考虑它们的特定时刻对您的组织是特别的。这项工作的负责人应该了解如何利用整个团队的集体脑力,找到好的解决方案或探索、实验和学习的途径,并做出最佳的决定——即使这偶尔意味着与集体发生矛盾(特别是当集体以精益的方式年轻时)。

除非你的组织完全被诸如看板之类的精益的知识唯物主义从薄弱的管理问题中分心。如果你让人流氓,你就没有方法论问题,你就有组织问题。如果你有一个组织问题,你必然会有一个管理问题,和一个无益使用权力的问题。

1. 永远不要忘记你的自动单元测试。
2. 永远不要忘记你的功能测试。
3. 永远不要忘记你的测试。

(我有罪)

有越来越不正式的过程。在某个时刻,我们将回到牛仔编码…

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

而这些方法论 更喜欢 “人过过程”,过程并没有完全被抛弃,仍然需要管理。一天结束时,你仍然对你的客户和最后期限有承诺。这些承诺应该控制奶牛。

“哪些过程不安全 消除了精益的驱动力 消除浪费“?

这是一个非常普遍的问题,很难准确回答。

当您抛出没有价值的管理过程时,您需要包括更多的技术实践,例如在极端编程中发现的那些。我所谈到过的大多数敏捷教练都会考虑测试驱动开发、结对编程和持续集成,这些都是他们在使用敏捷采用时所给出的。使用这些技术很难摆脱“牛仔编程”。如果我担心代码失控,我也会加入一些代码评审。

雇佣(或代理)一名警长,并更正代码,这样不仅可以让它成为承诺,而且可以让整个团队看到它。

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

你可以做的另一件事是调整容器。在看板板上添加代码审查,然后对其进行限制,以确保完成。更好的是,要求所有代码成对编写几周,这样良好的习惯就会重新被强制执行,并且没有人可以在代码的各个部分上声明所有权。

最后,考虑一下,从Scrum的正式过程中退出可能还为时过早。Scrum的规则是教你一种完全不同的思考和工作方式。如果精益和敏捷的价值观还没有根深蒂固地融入到你的团队中,那么很容易回到旧习惯中去。在团队准备就绪之前,严格执行Scrum规则可以帮助您。

记住,看板是一种工具。如果您不一致地将精益和敏捷原则应用到它的使用中,您将无法获得全部好处。

精益和敏捷都涉及到在一个非常具体的环境中最小化浪费:交付价值。

如果您停止使用有助于高效地产生价值的流程,那么您将要么产生更少的价值,要么产生更少的价值。

由于精益和敏捷技术都涉及到衡量你在价值生产中的进展情况,所以你应该能够分辨出你何时跨越了界限,并消除一个有用的实践。

如果你不使用速度或周期时间来衡量你的价值交付,那么你已经越界了!

牛仔编码有什么问题?如果你开始看到质量差,代码交付需要越来越长的时间,不能满足最终用户的期望(或是支付费用的人),那么它的时间(我是一个PM这样说)。当你有一个好的/可靠的编程团队时,不需要正式的过程——通常是内部化的——好的程序员自然会遵循好的形式/过程——我认为很多过程是为表现差的人准备的,这在很多情况下会对好的/好的执行者产生负面影响。一个好的项目经理需要根据具体情况平衡流程……引导/跟踪/让开方法类型

也许可以让客户参与进来,这样你就不会在BAU预算下写一个企业实际上不想要的理论体系了?多跟你的经理谈谈。