领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
敏捷开发人员的责任
作者 Amr Elssamadisy 译者 李剑 发布于 2008年1月16日
当客户要求你给出一个快速而肮脏的解决方案时，作为一个开发人员，你的职责是什么？是因为客户是付钱的一方，所以要洗耳恭听，遵照要求走捷径；还是遵守自己的意愿，坚持技术上“最佳”的方案？或者，这二者可以折衷？
James Shore在《我们的专业职责》一文中简述了客户和开发者之间职责平衡的发展历史：
在过去使用瀑布式开发的那段黑暗岁月中，编程人员得提炼出需求，进行设计，并用技术上最便捷的方式来实现设计方案。开发者就是神一般的存在。计划也完全都是他们制定的。也可能是开发者的大老板来制定最终期限——或许是由政策方面的压力所动，或是根据他曾几何时在某个彪悍周末中的编程成果所留下的传奇式回忆——然后编程人员就为此疲于奔命。*
*是的，我是在过分简单化一个复杂的情况。但这没什么不妥。
敏捷开发对此作出了回应：“嘿！等一下！不能这么干！我们并没有给客户带来价值！”于是，计划游戏推动着一切趋于平衡——客户掌控价值，开发人员掌控开销。
但有些敏捷团队把钟摆向另一边推的太远了。他们放弃了自己的职责。他们说：“客户说了算！不管他们说什么我们都要照着做。”
这太离谱了。
他认为，开发者不能充当掌控者的角色，但与之同时也应该担负起开发高质量代码的职责。理应永远如此。
如果有人说，“你能不能走条捷径，干的快点？”你需要凝视着他的眼睛说：“不。”“不，我们不能这样干，否则就会破坏进度。不过我们可以一起找找，看有什么办法把这些特性简化一下，这样就能更快完工了。”
Reg Braithwaite在《工程学和医学中让我敬佩的专业精神》中说到，有的时候，如果客户想要一个快速而肮脏的解决方案时，听从他们的意见也不算什么坏事：
我不赞同当客户要求你去为了赶时间写一些肮脏而又难以维护的代码时，你可以对他说不。这种想法是好是坏，要靠你自己判断。我的做法是在我与客户或是雇主的关系限定范围内，尽可能的编写整洁的代码。我也在积极推广这种方式。
但是，我并不认为我有权在雇主或是客户坚持立场时，彻底回绝他们的要求。他们会因软件难以维护而遭受损失，所以，是他们，也只有他们在这个话题上有最终的发言权。
他的底线并不是质量，而是道德。
在从事软件开发的时候，如果我被要求开发一些不安全、会将私密用户信息置于风险之中的程序，我会做出自己的选择，对这种要求说不。
当然，我并不会受到法律保护。如果我被因此而解雇，我也无处求援。我甚至也没法拿到失业救济，因为我会被认为是因为某些原因被开除的。记住，是你主动选择了这个行业，所以如果你将此作为谋生之本，那么你就必须要以高标准要求自己的道德底线。
Robert Martin（Bob大叔）在《商业软件是混乱而丑陋的》一文中则陈述说，这种做法是错误的。他的客户里有一名经理说过这样一句话：“商业软件是混乱而丑陋的”，对此他反驳道：
不！绝非如此！商业规则可能很复杂、毫无章法而特殊性又很强；但是代码不一定非要也写成这样子。实际上，商业规则越复杂、越特别、越毫无章法，代码就应该越整洁。当一些乱七八糟的事情左右着整个规则，你怎么可能把无序的规则变的有序！要想从凌乱的规则中抽丝剥茧理清脉络，唯一的途径就是在力所能及的范围内，写出最整洁、最清晰的代码。
最后，在InfoQ上曾有一篇新闻写道：重构是必要的浪费（Refactoring is a Necessary Waste），很多读者都围绕着何时进行重构、何时不应重构进行了评论。
那你认为开发人员真正的职责是什么呢？当需要走捷径时，他们应该“仅仅说不”吗？他们应当顺从客户的要求吗？还是应该灵活一些，但又必须关注那些会影响到客户的事情，与之同时坚守自己的价值观和道德？
查看英文原文：An Agile Developer's Responsibility
译者 李剑 李剑──ThoughtWorks高级咨询师，在持续集成、重构等领域具有丰富的经验；多次为国内大型企业敏捷组织转型提供咨询和培训服务。
职业道德 vs. 专业技巧
发表人
Hisame Shizumaru
发表于
1 条回复
关注此讨论 回复