领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
质量是可以谈判的吗？
作者 Amr Elssamadisy 译者 郭晓刚 发布于 2007年12月3日
如果客户对你说，他们对软件的质量不感兴趣，他们只要求在规定的日期必须完成所有规定的事情——你会怎么做？你会听从客户的话在质量上妥协吗？（顺便一问，什么是质量？）
Simon Baker问道，你是否应该总是做客户希望的事情？
如果客户说他不想要“完美的代码”，只要能完成他想要的功能，质量低劣的代码他也无所谓，你会怎么办？我们的任务是交付客户想要的东西，对吧。那么，你会在质量上抄近道吗？我不会。我会去理解客户的思维，看看是否其实只是短线的想法（“我只想要最便宜的，质量无所谓”），如果他是无知，或者纯粹是糊涂，那我就撒手走人算了。我的良心不允许我在作品的质量上做出妥协。
在ScrumDevelopment Yahoo! 讨论组上也发生了一起相关的讨论，议题是“质量”是否不可谈判的。讨论从Pierre Mengal的提问开始：
我正面对一个情况，客户不关心质量，因为对他来说，那属于浪费时间。他们立了一个不可动摇的限期，不允许增加资源，不允许缩减项目的目标范围。如果有必要，他们可以在项目完成之后几个月内把整个应用完全重写一遍。这个绝对不是开发费用的问题（如果到了限期没法发布，他们的损失会以百万计）。
Esther Derby回以一个疑问：
我对“质量是不可谈判的”这句话很很好奇。
质量并不是一个绝对的词，因此*必须*经过谈判才能达到一个共同认可的特定含义。就我来说，“我不会牺牲协商好的质量水平”这样的说法更有意义。
Jerry Weinberg说过“质量是对某人的价值。”我们的任务是找出价值所处的位置。
你可以看看Jerry的《Quality Software Management》系列。
Also Kathy Iberle有一篇漂亮的论文《They Don’t Care about Quality》，里面谈了在不同业务背景中的“价值”：http://www.kiberle.com/2003/STAREast2003.pdf
Lance Walton揪住价值不存在明确定义的暗示不放。
这里有个很明显的问题，“质量”是个缺乏定义的词。比如，假设“发布某物，即使质量很差”指的是每次用户保存工作的时候软件都会崩溃（如果在崩溃前还真的保存好了，那情况又不一样）。或者假设质量很差的意思是每次按键都要花10秒钟去处理。这些情况包括在“发布某物，即使质量很差”的可接受范围内吗？
Alistair Cockburn举了一个详细的例子：
我刚刚访问过A公司，他们的软件比竞争对手B公司卖得好很多，让B都倒闭了。和我交谈的人说，B的产品比A功能更多，速度更快，Bug更少，但B没有建立现场专家支持部门，而A建立了。
从他们客户的角度来看，A产品比B产品“质量更高”。因此客户购买A产品而不是B产品。
仅仅避免Bug和编写可维护的代码还不算交付了质量，还得有人买它。购买的决定指出了“什么才算是质量”。
“质量”的因素多不可数，大多数谈判中谈的是各项因素的重要性排列，每项因素需要达到什么程度。如果你生意不好，“没有Bug和可维护”可帮不上什么忙。
Ken Schwaber在《Agile Quality: A Canary in a Coal Mine》演讲中讨论了另一种看待质量的方式，他认为代码质量应被视作公司的资产。
那么，当客户说他们不关心质量的时候，我们应该听从吗？我们应该盲目地做客户要求的事，还是说忽略他们，因为我们懂得更多？又或者有没有别的途径？我们应该如何与客户交流，才能建造出最好的软件呢？
查看英文原文：Is Quality Negotiable?译者 郭晓刚 是InfoQ中文站架构社区编辑，创建并终结过数家软件小企业，翻译过多本技术书籍。
客户不知道自己想要什么
发表人
Guo Xiaogang
发表于
Re: 客户不知道自己想要什么
发表人
里巴人 上
发表于
客户并非真的不关心质量，而是我们没有清楚客户对质量要求的底线
发表人
Chan Jackei
发表于
客户并不关注软件内部，而关心他所要的
发表人
zhong cl
发表于
这里的质量可能是指代码坏味道的多少
发表人
曹 云飞
发表于
基本同意，会选择合适的时机进行重构，才算真正的敏捷！
发表人
Zhang Charlie
发表于
怎么又回到敏捷的讨论去了
发表人
zhang wei
发表于
-
客户不知道自己想要什么
还是如何测量质量的问题。我们不容易有一个明确的指标来表示质量，谈判中很难直接讨论。
在谈判的结果中，质量常常是以其它要求来隐含地表示的。
即使存在测量软件质量的指标，粒度大概也是很粗的。质量/时间、质量/成本这些曲线都不是光滑的，不能按客户的要求滑来滑去。
质量的变动还有很多隐晦的连锁反应，难以预测。 -
我认为不是客户不关注质量，而是客户更关注在有限的时间内交付给他一个可用的产品。这个可用的产品对客户而言就是最好的质量的体现。
记得从前常有人以印度人写的程序烂为诟病，可是他们的项目就是稳定、可用。你说客户是重视你程序的质量，还是重视项目的可用？ -
作为客户来会所，不会真的对质量好不关心，他们想表达的通常是不需要耗费过多时间和人力为代价换取的"高质量"，而并不是连基本的功能和可用性都忽略掉。
所以对于PM或者QM，关键的是与客户一同定义好质量目标是什么，一定要让项目有一个可供验收参考的质量标准。 -
一般的客户是不管你用什么多好的技术，设计中的系统架构多么的优良，设置代码写的多么的优雅，一句话，在规定的时间内实现他所想要的稳定的功能就行了。其实从这也可以看出，客户其实也是很关注质量的，只是关注的点和开发方的不同，这其实也就是 关注的粒度不同而已，质量问题不是从谈判中解决的，而是在开发中解决的，不关心质量的软件，最终带给客户和自己都是一个噩梦。
-
我们程序员往往很在意坏味道，比如重复的代码，随时重构代码来消除坏味道。而对于客户来所，这些坏味道只要不影响功能，就没有必要花时间去重构。如果客户说没有必要考虑可维护性，那么我会认为没有必要清理代码中的坏味道，在项目规模不是很大的情况下，这样应该是可以节约时间的。也就是说，在这一点，我会听从客户的要求。
-
首先关于本案主题，我觉得应该先把什么是“客户”，什么是“质量”定义清楚，如果大家分别拿着不同的定义在讨论，那是浪费时间。
接着再谈谈重构，虽然好像有点偏题。
重构必然是有成本的。老练的工程师会评估重构的代价，巧妙地选择重构的最佳时机。
极端编程要求我们每时每刻地进行重构，作为“勇气”的表现，这当然是理想情况。对于初级程序员和新手，在把握不好的情况下，不分青红皂白地进行改动、重构，也是一种可以理解的简化（机械化）处理方式。随着开发经验的积累，我想他们也会主动思考出手的时机。
2007-12-5 1:59 cao yunfei 说：
我们程序员往往很在意坏味道，比如重复的代码，随时重构代码来消除坏味道。而对于客户来所，这些坏味道只要不影响功能，就没有必要花时间去重构。如果客户说没有必要考虑可维护性，那么我会认为没有必要清理代码中的坏味道，在项目规模不是很大的情况下，这样应该是可以节约时间的。也就是说，在这一点，我会听从客户的要求。
太极敏捷派
www.zhangxun.com -
客户往往关注最直接的东西，比如交付日期和可用性。对于质量，这一个内在的东西，国内的客户往往难于理解：怎么？做的软件bug很多？这不是你们的专业、特长吗？他们倾向于认为软件一做出来就是没有任何问题的。
7 条回复
关注此讨论 回复