如何制止镀金并满足于发布工作进展


29

我所属的开发团队最近适应了敏捷实践的工作。这个人突出地表明了一个事实,就是我无法停止自己的镀金代码(和文档),因此,当我可以更早地交付满足要求的解决方案时,我就超出了最初的估计。

我认为我的道德观念与强迫症接壤,因为我过于依赖自己的代码,在重构和完善到第n级之前,很少满足于发布。我很高兴自己意识到了这一点,但是我如何才能改变自己的态度/心态来满足自己的进步并按时发布呢?


7
定义镀金。对我而言,镀金正在添加不必要的东西(按精益计算,会产生浪费,例如不必要的功能,过多的文档或非增值文档)。似乎您并没有添加不需要的东西,而只是花时间进行重构而不是撤消新的工作产品。
Thomas Owens

通过镀金,我的意思是努力完善已经满足其要求的设计(也许尝试并鼓励其在将来重新使用),而不必添加新功能。
安迪·鲍克斯基尔

你的老板怎么看?
JeffO

Answers:


22

最好是足够的敌人。

您总是可以做更多的测试,编写更好的文档,找出那些极端情况,填写您认为缺少的功能,使架构更整洁。它永无止境。但是,它必须结束。必须满足截止日期,外部约束取决于完成的产品部分。在产品的一小部分中追求完美会损害整个产品。


2
谢谢大卫,这使我想起了我最近读到的一则相关的名言:“完美是完成的敌人”。
2012年

1
由于原始版本是法文(Voltaire),因此很难说哪个版本是“正确的”-除非有人用法语编写。
大卫·哈门

24

首先,我希望更多的开发人员遇到这个问题,不是因为软件最终发布的时间比预期的要晚,而是因为它可能是更高质量的版本。

如果您超出了自己的原始估算,则可能需要将“镀金”步骤包括在内。如果它们不是您自己的估计,也许您应该参与制定它们。

无论如何,如果您有发布截止日期,则应该遵守。任何“镀金”都应作为不阻止发布的最后一步。如果您绝对认为它必须包含在版本中,请考虑在自己的时间(即工作时间以外)添加“镀金”。

您应该做的是向您的团队和/或管理层提出“镀金”步骤,并讨论为什么您认为它们很重要。如果您可以说服他们这些步骤是有益的,则它们应成为将来版本的一部分。


谢谢伯纳德,很好的建议。是的,这也突出了时间和成本以及最终产品权衡的质量。
Andy Bowskill 2012年

@AndyBowskill,我遇到了与您相同的问题。你现在怎么样了?
datasn.io

14

镀金软件

我第一次看到镀金用作软件描述是在Barry Boehm一篇论文中,他给出了以下根本原因:

镀金。在设计之前进行固定需求的规范往往会鼓励软件镀金。用户被问到他们的要求时经常会说:“我不知道我是否需要此功能,但为以防万一,我不妨指定它。”

在他的描述中,他建议使用研究中描述的方法,包括螺旋软件生命周期模型,在该模型中,项目的范围限定为每个周期生产一系列原型,并且随着螺旋的变大,产品将逐渐具备功能。螺旋在软件研究人员中具有广泛的影响力,是瀑布与敏捷之间的重要桥梁。螺旋线的一个关键限制是,每次绕螺旋线,周期都会变得更长且更昂贵。

与敏捷一样,螺旋式通过缩小范围并安排足够长的项目交付时间以使团队可以完成需求来避免镀金,同时又要足够短以允许从第一天到交付日专注于目标。像Scrum这样的敏捷方法优越的一种方式是,Scrum冲刺的时间范围不会因迭代而变长。从本文看来,项目管理对镀金的影响似乎比单个开发人员要大。

搏击天才

计时的能力非常重要,但这不是一项二进制技能。您没有它或缺少它。你或多或少都很好。无论是来自您的老板还是来自您,我都希望没有人说您不能停止镀金。这听起来是个人的,普遍的和永久的。

根本原因分析可能有助于确定几个问题。我敢肯定,他们不会全都指向你,除非你与精神病患者一起工作,否则团队中的其他人也会看到类似的需求,以提高他们的敏捷技能。如果您认识某个没有问题的人,那么您对他们的了解就不是很好。如果您认识某个认为自己不需要改进的人,那么他们对自己的了解就不会很好。

我希望您确定的改进将是您可以凭自己的认识和团队帮助解决的问题。但是,我认为这不是终点。撰写您的评论的主管或经理对我的期望是,他们也可以指导下属取得成功。当组织正在发生革命性变化(例如从计划的转变为敏捷(或从临时的转变为敏捷))时,这一点尤其重要。

快速和肮脏还是风险管理的原型?

我有一个经理,他曾经要求以某种方式执行任务。

又快又脏,但很美。

他知道这很愚蠢,这是他忧虑的幽默感的一部分。许多人说这样的话,他们变得非常认真。在某个地方,存在使用改进的技术或方法来解决问题的折衷方案或机会。

我们可以牺牲些什么来适应我们的时间范围?

在《极限编程说明》第二版的第一章中,肯特·贝克(Kent Beck)谈到了快速行动所需要的条件。他的回答是“您只做为客户创造价值所需要做的事情”。

风险

在同一本书的第一版中,贝克说,他与博姆关于控制风险的观点更加接近,这对他的方法至关重要,他说:

“风险是软件开发的基本问题”

在这两个版本中,Beck都列出并描述了八种常见风险,然后断言XP(或可能是敏捷的扩展)以特定方式解决了每种风险。对我而言,他的大多数解释都归结为使用较小的增量,而更快的迭代使我们能够在风险变得太大以至于无法处理之前将事情重新引导。

心态充足

贝克以有关山区人民和森林人民的故事为背景讨论资源,并介绍了一个名为“自给自足的心态”的概念。在您遇到的情况下,他问“如果有足够的时间,您将如何做?” 仅仅作为本书的预览版的第一章可能为思考XP(以及其他敏捷方法)如何思考诸如时间之类的约束提供了很多参考。

强迫症可能是症状而不是疾病

几年前,我看了一本关于拖延症的书,书中说很多拖延症都源于恐惧。如果您不开始,就不会犯错,也许您不会受到批评。强迫和完美主义可以使我们的道德观念告诉我们,比拖延要好,但是可能会有相同的结果。考虑一下,也许您在以其他形式拖延问题?

批评与竞争

在诸如Scrum之类的敏捷方法中,因拖延而受到批评或惩罚的机会从未如此高。那是一个恶性循环。我拖延是因为我受到批评,我受到批评是因为我拖延了。在每天的Scrum会议上,我们总是保持警惕,因为距向团队汇报完成的工作总是一天或更短的时间。

在理想的团队中,Scrum每天提供纠正拖延症的机会。在帮助到达之前,错误应该没有时间变得更大。团队并不总是在应该信任的地方,因此团队中的领导者可能需要主动应对批评或对批评的恐惧,以使事情向前发展。

在我们的工作世界中,团队中的每个人还必须与他人竞争。相信拥有一支能够分享工作和成就成就的团队,但随后使用年度绩效管理流程来奖励其20%的成员,惩罚或开除10%或更多的成员,以及假装70%的多数人没有激励就做出了自己的最大贡献。我认为这是WRT会议室中促进团队合作的一头大大象,并且引用肯特·贝克的故事,就可以看出与成为“山区人民”有着深厚的文化联系。

前进的道路

作为敏捷团队的成员,最好与他人进行研究并进行对话,以探讨有效的方法。如果您的团队使用TDD通过工具自动执行单元测试,请找最能帮助您的人来指导您。如果您的主管或经理对您的文档编制方法有疑问,请找出他喜欢或喜欢的人,然后按照他们的方法去做。如果归结为原始编码速度,请研究加快编码速度。

领导者可以通过对期望的行为进行角色建模来朝正确的方向迈出正确的一步,例如坦率地谈论自己的问题(而不是别人的问题),提供帮助和跟进,并就团队如何转变为敏捷海军风格(即没有人)进行对话被留下来)。并非团队中的每个人都有相同的能力。探索与团队成员配对或分配任务和角色以强调相关人员的互补优势可能是适当的。规划技能的增长或补救对上司和下属而言都是工作的奖励部分,但必须尽早且经常有效。


尼斯,详细的答案。+1。关于“但必须早点发生”:这是秋天,所以我将使用美国体育类比。想象一下,如果一个橄榄球队的经营情况与典型的企业一样,并对其年度员工进行审查。“我们将您的薪水降低了50%。在第一场比赛中您错过了三个简单的接球机会,在接下来的四场比赛中,您直到第二季度都没有表现出来,整个赛季的表现都很差。” 批评每年弊大于利。如果来不及了,就不会有建设性的批评。
David Hammen,2012年

与山区人和森林人的链接断开。
通配符

7

您也为娱乐而编程吗?我还对工作中的限制感到恼火,这些限制使编程失去了乐趣,为了弥补这一点,有时我会在家中启动一个新项目并“正确地做”。拆分使我可以同时满足:我的需求和公司的需求。

或者,您可以开发一种除编程之外的新技能来在您的课余时间(最终)满足工作所不能提供的条件。;)


欢迎并感谢您在Stack Exchange Programmers上发表您的第一篇文章。请考虑输入后续问题,作为对问题的评论而不是答案。您可以了解更多有关编写高评分问题和答案的标准的信息,并通过阅读程序员
DeveloperDon

感谢duanev,您的第一段肯定也对我适用!
Andy Bowskill 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.