领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
代码永远是罪魁祸首吗？
作者 Vikas Hazrati 译者 金毅 发布于 2010年12月19日
软件项目的失败可能归咎于各种各样的原因。一些项目因糟糕的需求而失败，另一些则由于钱和时间超支了，还有少数单纯是因为糟糕的管理所致。如果我们探究其根本原因，是否会发现所有项目失败的罪魁祸首是糟糕的代码呢？全都是这样吗？
Bob大叔坚信糟糕的代码所带来的成本之大足够让一个项目失败。他提到：
我知道许多项目都败在代码问题上。更有甚者，许多公司因为代码问题而失败。
Bob觉得原因其实很简单。若维护代码所需的成本超出项目预算，项目就会失败；若成本超出公司预算，公司就得关门。再看另外一个极端，Bob认为，如果代码成本近乎为零，也就没有项目会失败了。
项目为什么会因为糟糕的需求、糟糕的管理、不合理的计划和预算而失败呢？其实它们的失败是由于错误成本太庞大。为什么错误成本会如此庞大呢？因为代码的成本大得惊人。如果产出代码没有花费，错误成本将几近为零。
然而，不是所有人都同意这一观点。
当这个问题被贴在twitter上，大多数人认为商业运营问题才是导致项目失败的原因。Alex Chaffee认为，糟糕的管理和需求根本无法通过优质的代码来弥补。
如果你的需求很烂、管理差劲，即使是免费的即时代码(instant code)依然拯救不了你的业务。如果你马上发布一个完美无瑕，但没人想要的、毫无价值的产品，并且为这个蹩脚的产品不断迭代，发布更多恐怖的版本，那么最终你还是会花光所有的钱和时间，甚至声誉，你的项目以至于生意仍旧以失败告终。
同样地，James Iry提出，糟糕的代码只是项目可能失败的原因之一. 他认为：
免费的代码当然会使公司有能力交付更多、更频繁的迭代，但如果迭代只是基于糟糕的想法、或者听上去不错但不适合市场需求也卖不出去的想法、又抑或卖得出去，但在设备或维护或其他什么方面成本过高的想法，那么公司最终还是会失败的。
Michael Dubakov认为，如果公司不能提供正确的解决方案，项目就会失败。他提到，如果代码整洁，那么对其进行重构，从而获得正确的解决方案就会比较容易，但这并不意味着好的代码就等于好的解决方案。Michael提议：
在这个世界上，你可以创建一个拥有最整洁代码的完美架构。你可以达成100%的测试覆盖率，不用布尔参数就将关注点、层次结构和方法完全分离。你可以在每个技术方面都做到完美，然而如果程序不能有效地解决用户的问题，最终依然难逃失败。
Michael Norton补充道 几乎所有项目失败的根本原因都会归咎于人。他认为：
如果一个项目由于解决的是错误的问题而失败了，这个项目就是由于参与的人错误地理解了问题而失败的。如果一个项目由于代码（或其它什么）质量不好而失败了，它就是由于参与的人相应写的代码太烂而失败的。
如此说来，虽然没人会轻视整洁代码的重要性，但也不是每个人都认同糟糕的代码是项目失败罪魁祸首的论调。你的想法如何呢？
查看英文原文：Code is the Culprit! Always?
译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。
被搞蒙了!
发表人
令狐有心 消失风雨中
发表于
没有好的游戏规则平衡软件开发中各种角色的权利和义务是罪魁祸首！
发表人
a dang
发表于
怎么可能是代码的问题
发表人
王 杰
发表于
Re: 怎么可能是代码的问题
发表人
赖 晨东
发表于
就是人
发表人
风 之子
发表于
Re: 就是人
发表人
Wang James
发表于
一直在追求高质量的代码
发表人
华杰 杨
发表于
那是什么导致了糟糕的代码呢？
发表人
赖 晨东
发表于
代码质量对系统的影响
发表人
金 毅
发表于
感触
发表人
曾 凡涛
发表于
-
项目失败最容易看到的原因是,糟糕的代码,可是造成糟糕的代码的原因又是什么呢?认为糟糕的代码是罪魁祸首只是在寻找一只替罪羊
-
没有工程师想写糟糕的代码，特别是有经验的工程师，会特别留意如何提高代码的可维护性，以应对需求的变化。但即使再小心，也仍然有考虑不周的时候，这是没办法的事。如果需求方不停地改需求，而且通过“过于失衡的权力”去强奸工程师，再优质的代码也会有扛不住的时候。提高代码品质是必须的，但绝不是唯一要做的事，提供一个平衡的游戏规则才是重中这重。
如何平衡软件开发中各种不同角色的权利和义务呢？我觉得ｓｃｒｕｍ就非常好，用一套游戏规则去平衡各方的力量，不至于失衡。产品负责人可以提需求，但不能在开发周期内改需求，如果一定要改，行，中止当前sprint，延误的工期由你来承担。scrum master不能命令开发团队如何去工作，他只能为团队提供帮助，他的权力是间接的。开发团队在这样一套游戏规则里，才有可能得到保护，才真正有可能高效地开发软件，不会中因糟糕的管理而导致项目失败。 -
不可否认，代码质量的确是会影响到后期的维护费用，而且占的比重还是很大，但是需求不清晰，或者需求经常大规模的变动，这些都会影响到整个项目框架的选型，及技术的应用，可能一开始选型可能针对某个方面的需求是很好的，但是后续的需求又变了一个方向，或者新的需求一次又一次的推翻以前确定的需求，再好的代码也会被写烂。
-
项目失败根本原因就是人的问题，这就是关键。
-
一直在追求高质量的代码
-
不管糟糕的代码是不是导致项目失败的罪魁祸首，但无疑他有很大的责任。那，是什么导致了糟糕的代码呢？管理混乱？时间紧迫？程序员自身的不负责？虽然没人会轻视整洁代码的重要性，但在项目的各种压力下。好像也没太多人会重视重视整洁代码的重要性。尤其是中国项目，这点在中国国内项目和中国对日外包项目上的对比非常明显。
-
不可否认，代码质量的确是会影响到后期的维护费用，而且占的比重还是很大，但是需求不清晰，或者需求经常大规模的变动，这些都会影响到整个项目框架的选型，及技术的应用，可能一开始选型可能针对某个方面的需求是很好的，但是后续的需求又变了一个方向，或者新的需求一次又一次的推翻以前确定的需求，再好的代码也会被写烂。
赞同！在认为代码导致问题的时候，应该想一下是什么导致了“有问题的代码”。从更深的层次找原因。 -
大家也可以看看这篇文章，作者是我们InfoQ的编辑张逸，他也发表他对这个问题的看法。
www.agiledon.com/post/2010/12/123.html -
就是人的哪些方面的问题？
我们所关心的任何问题最终都是源自人且为人服务的，因此将问题简单地归为人，无助于解决问题。 -
当然导致一个项目失败的原因不止一个。正如成功皆相似，失败尽不同之说。 作为一个程序员，同意Bob大叔的观点，有利于我们把代码写的更干净，在代码上做的更好。如同，一个人师从某一门派，师傅总是认为自己门派的武功是最好，以此激励徒弟刻苦练习，当徒弟出师之时，让人敬佩的师傅会告诉徒弟武学上没有什么门派的武功是最厉害的，你应该吸取百家之长，方能开宗立派。作为程序员，当你不能写出干净的代码，不能熟练写出整洁的代码之时，最好是相信代码整洁，是项目成本最关键的，以此激励自己熟练甚至达到本能的写出整洁代码，不把代码写干净了就浑身不舒服了的程度。再去关注或者掌握项目成败的其它武学。当认为代码整洁不是项目成败最关键，一般就没有意志去苛求代码的整洁，也就很难做到本能写出整洁代码。当能本能写出整洁的代码，至少我们减少一个影响项目失败的因子，不在为其所困。
10 条回复
关注此讨论 回复