//作者: 王玮琳 2006-12-07
近期在一个小项目开发组里进行推行XP，尝试了一段时间。结合过去带项目开发组的经验，说说我对在实际项目开发里应用极限编程方法一些体会，和大家交流。完全是个人理解，也不太成熟，不对的大家来拍。
一 如何看待开发方法
首先说点开发方法本身的理解。我一向认为没有哪个开发方法可以彻底的解决项目开发的各个环节的问题，任何一个开发方法，其中有些理论的东西放到自己的实践中可能就是事倍功半，在实际开发中还是要灵活，要掌握一个应用的度。过去我一直是用RUP的那一套东西，不能说它差，更不能说它好。我觉得RUP也就是给我们组织项目提供了一个参考，我们并没有严格按它的来，比如文档，我就是按国标的要求来写，而不是RUP的；甚至文档的数量、质量方面，对每个项目我们也是灵活处理，比如这个项目组的人擅长文档编写，就要求他们写的详细点，要是项目组整体文档编写能力都不行，就要求写的简略一点，能突出重点就可以了。总之，我觉得实际项目开发的模式应该是慢慢摸索出来的适合自己的方法和模式，不需要严格遵守什么东西，另外就是要根据各方面的发展进行不断的调整。
二 推广XP价值观 极限编程中用来指导开发的五个主要的价值观是：
沟通、简单、反馈、勇气、尊重。我觉得对PM而言需要重点对Team成员强化的价值观是：
沟通、简单和反馈。这三个是实际影响所有工作方式的价值观，应当在任何时间、任何条件下要求大家来理解、实践。
沟 通：在实际开发过程中，通过平时及时的口头沟通来促进团队的了解及合作，开发过程中相关人员尽可能的及时主动报告开发进度、问题，一方面自己要将所做的工作及时的告诉他人，另一方面不要等着在他人进行阶段性的汇报时才了解项目开发情况，要随时询问、关注他人的工作进度，只有大家都了解了项目的真正的进展，才能消除对开发进度的怀疑、忧虑。
应该强调沟通的作用是多方面的，绝不能把沟通理解成去了解他人的工作进度，而是通过沟通来实现工作的简单化，实现较小的反馈周期。至于进度问题，从领导角度来说，应当本着尊重、信任的价值观进行合理的关注。
简 单：开发过程中各项事务性工作应当化繁为简，沟通方式、决策尽可能的简单化；系统实现方案也应当考虑选用简单的实现方式，尽早尽快的达到效果。
反 馈：反馈是沟通的核心部分，应当成为所有开发人员的核心价值观之一。大部分情况下，我们都不可能在开始的时候知道我们最终的系统是什么样的，需要群策群力参与进来，一方面对系统的功能进行改进、提高，一方面对项目开发的沟通组织方面进行改进，提高整体的开发效率。推行反馈的价值观是非常需要技巧的，因为我感觉大部分开发人员并不是不想反馈，而是不知道如何反馈、反馈什么，对此我提出的一个说法就是：一切都可反馈，一起都要反馈！
至于
勇气、尊重则是我认为这两点和人的天生个性有关，要因人而异，有针对性的对Team的部分成员做出具体要求。我个人认为一些XP的书籍强调这两个价值观的前提是不太严谨的，举个小例子，要组里一个弟兄本来就是个勇气过剩，喜欢在项目用高风险的代码的激进分子，我再老和他强调勇气，岂不是要搬起石头砸自己的脚？
三 掌握XP原则 极限编程方法提供了一整套的开发原则，在实际开发过程中，我觉得实践中需要重点遵循的开发原则有：
- 人性化
- 质量第一
- 互相受益
- 从经济角度出发
- 不断提高
- 慢慢走 (Baby steps，很多书翻成婴儿步)
挑两个说说，其中最有感受的是第一条人性化。
人性化是什么？看看国内众多的软件公司，老板大凡都是觉得自己还算对得起员工；PM总觉得自己比手下人更难更辛苦；干活的人就算受了委屈了，想想哪都差不多，只要薪水还可以能过的去就忍了，等差不多到了时候跳个槽就是了。在这种氛围下，人性化具体下来是什么东西呢，给点加班费还是多去加几顿餐？
老外谈人性化，说要把工作和生活分开，要让员工有安全感、成就感、归属感，未来能发展，还能对其他同事感到很亲切。对咱们中国的大部分工程师来说，除了遇到个好领导能感到亲切一些，安全感、归属感、成就感，甚至长远的发展就只是少数幸运的人才能拥有的了。这个问题我也没有很明确的理解，就我自己的看法，我觉得作为领导能做到公平、宽容、鼓励优先，能尽可能的让弟兄们少加几个班，就算是有点人性化原则了。
算了，撇开让人郁闷的人性化，来说说质量第一和不断提高。其实在俺们的项目中，尤其对PM而言，质量第一有时候会成了一个自欺欺人的口号。质量和进度有冲突，怎么办？我的经验是质量第一不等于质量最先，产品有Bug不会扣钱，按期交不出活不但要扣钱，还要损失信誉；那怎么办，要降低产品质量用不好的解决方案或者弄虚作假么？也不可！现在的程序都是B/S的，方便升级，先交互，再抓紧时间出补丁在客户反馈之前去升级就是了，你去升级，客户还高兴觉得维护费用没白交呢。
这里就引出另一个原则了，慢慢走。这个我体会也很深，做项目真的就是应该一步一步做，不能好高骛远，一下把功能设计的过复杂，把摊子铺的太大。开发中把功能一个一个实现了，然后一个一个做稳定；交互给用户后，不断的能做一些功能的改善、提高；这个慢慢走不仅是一个什么成本、风险的问题，更是一种感觉，一种让项目开发人员觉得不断前进，让用户觉得你的产品在不断的改善提高的Feeling！
四 XP实践
XP编程理论里列举了大量的实践方法，我挑感触比较深的和大家来交流一下：
这一条简直是中小软件开发设计的至理名言！项目做的少的人可能很难理解这句话的重要性，极端的说，那些想一开始就把各个东西都设计好的项目,基本和没有做设计差不多。过去我们提"原型开发法",在RUP里我们讲短周期迭代，在XP中我们说要周循环，季循环，要增量设计，这都是为什么呢？就是因为我们老是发现设计和后来的变化差别太大，要回去改设计又总存在各方面的问题（懒惰嫌麻烦、怕出问题有顾虑、有风险不愿担责任，太忙了没时间等等）。最早原型开发法就是不要设计了，根据实际做出的东西来调整，RUP是有致命伤的，不敢面对这个问题，不痛不痒的说把开发过程多弄几设几个里程碑，及时调整好了。而XP提出的一点一点设计，似乎是最靠谱的，把设计过程一点一点分解到开发的过程中，或许一直一来很多的优秀的团队也正是这样做的。
这一条对PM来说也是非常有实用价值。从负责人的角度，要尽可能宽松的制定计划，避免“高承诺、低交付”对团队带来的信心、热情、积极性的负面影响。一个弟兄，活干的快了受了表扬，下次干的可能就更好了；要是活没干好交不出来，他的信心受了打击，就不是简单谈谈话能调动的起来了。
这个从实际操作来说，XP讲究实事求是，成员间信息透明，让大家了解真实情况，不允许少干不报，也不允许多干少报。但我理解这是局限在团队内部的，属于人民内部矛盾，对于自己人，我们当然不能欺上瞒下，干活时，等或者是拖，都是不对的。但是对外面对那些只要结果的客户，有时也是需要应用一些必要的策略，尽可能争取到合理的时间，尽量把客户的预期引导到正确的范围内。
可能你觉得很多少时候这种事情超出了PM的能力范围，工作量、交互时间在你接到活时就已经定下来了，只能硬着头皮上。光是咬牙做当然是愚蠢的，这种情况我过去的做法往往是在过的过程中要想办法逐步降低用户的预期，即要设法降低承诺，强调强调困难，方法得当大部分情况下客户还是可以做出一定的让步的。当然同时一定要提高交付的产品质量，保证客户的满意度。
对这个我可能有些保守，我相信结对编程其实是大家一种在用的一种编程方式，并没有什么特别神奇的。除了XP理论书籍里的提到的那些弊端，我认为结对编程的负面作用其实还有很多。比如对新人，养成编写程序的独立思考能力很要紧，不能上来就老结对，靠别人的启发来慢慢搞。因此我认为让大家知道结对编程这种方式是可取的，有必要的时候(比如有些问题自己想不太清楚)找个合适的人结个对，讨论讨论就可以了。
声明：本博客中所有文章均为版主原创，转载请保留作者信息，并请注明出处。