Scrum敏捷开发之我的总结

Team刚刚完成了一个敏捷项目，做一下项目总结，以备以后借鉴和提高。

需求 - 沟通 – 人 - 过程 - 工具

项目要成功的最关键因素是什么？软件要快速高效又高质量的提交靠的是什么？有人说最关键是项目经理，关键是沟通，有人说是技术设计，有人说是对需求的把握… … 从我看来，都是盲人摸象，项目要成功，软件要快速高效又高质量的提交，靠的是多重因素的整合和平衡；首先要对需求的准确理解和把握，贯穿全流程的沟通，做项目靠人，对人/士兵的管理（物质、心理），适合组织的先进的过程（开发，测试，评审，组织，考核），还有工具的运用和整合大大提升组织效率，缺少那一样都是不行的。成功的模式只有一个，而失败却有各式各样，就是这个道理。

沟通，随时随地，全方位立体的，有效的，及时的沟通

沟通，沟通，随时随地，全方位立体的沟通。面对面、站立会议、咖啡间、IM、Email、文档、电话。上下级、跨部门、客户，沟通，直到双方的理解没有Gap（鸿沟），没有Misunderstanding（误解）。主动沟通，有问题随时反馈。对被动的同事，主动问他。注意沟通的效率和时间表，不要一个会议开两个小时。如果有必要，尽量让少的人参与，除非是kick-off会议。此外，沟通会影响时间表，比如你有个问题要问某人，而这个人下周开始休假了，要早做预防。否则，吃亏的是自己。

白板，任务板，Sketch，Prototype

Team位置必须坐在一起，最好是圆圈式的座位，旁边有玻璃白板，上面画好下一个里程碑和Release的Roadmap，玻璃白板便于马上沟通。任务板便于大家清楚当前致力的目标和Release。对于Sketch要用好，在产品或者功能还没有做出来以前，先把Sketch或者Prototype发给客户看一下是否认可，获得用好Remarks，然后再开始动手；毕竟动手了再修改代价就更大了。所以一定要用好Sketch草图。

Stand up meeting要不要

很多人说到Scrum就要每日晨会Stand Up Meeting，但我们Team的实践来看，并不是必须的，其实敏捷也是根据组织和项目实际情况因人而异的（有人说敏捷对结对开发人员的能力要求很高，我觉得敏捷是一种境界，良好的架构，代码规范，成员间非常好的默契，才能敏捷的起来）。不能拘泥于形式主义，我主张实用主义。现在不是有反敏捷、有瀑布敏捷（Water-Scrum-Fall）、实用敏捷吗？关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开发流程，而只是依葫芦画瓢学个一招半式，那就真的不是敏捷了。我听到有人说，敏捷只适用于产品型公司和小型项目，还有人说敏捷只适合于需求不稳定的项目，还有人说敏捷了就等于速度快，就等于客户报价可以低一些，还有人说敏捷说的什么迭代持续集成和重构都是理论，没有考虑到实际执行起来的风险……都没有错，关键是我们还没有领会敏捷的深刻内涵和思想体系，不会用敏捷的思想和思维方式高屋建瓴的思考我们的开发流程，而只是依葫芦画瓢学个一招半式，在这儿讨论，说白了还是理论，坐而论道不如起而行，所以积极实践，加深对敏捷内涵的深刻理解，寻找适合自己组织的最佳敏捷实践方法才是良策。这样子思想理顺了，我们就不会拘泥于Stand Up Meeting到底要不要的问题了。

保证代码质量

如何获得高代码质量？打个比方，现在要打仗了，如何打个漂亮的胜仗。我想你肯定知道答案了。那就是你的队伍必须各个是精兵，能力强，平时训练有素，而且还有实战经验，这样的一个兵强马壮的精兵队伍你拉出去，只要指挥好，士气高，就能打漂亮的胜仗。OK，现在你明白了，软件开发何不如此？你手下的程序员是不是技术能力很强，是不是平时就对技术研究很深，对某科技术有很深的理解，还有很多项目经验，是不是干劲十足，是不是对他们做了培训，是不是做了编程规范的要求，都明白了命名规范、异常处理、日志处理、安全性、用户权限、配置文件、设计模式、线程安全、单元测试、调试技巧、条件编译等项目标准处理；如果还没有这些标准的贯彻，那你的士兵还需要培训（训练），这样子上战场会很危险。当然，有个变通办法，让资深程序员带小弟，小弟在一边看着，下个项目备用。当然。除了培训以外，分享、知识库都是团队很重要的机制。

基础不扎实的程序员代码质量不会高起来，比如有的C#程序员根本理解Task.Factory.StartNew这句话是异步执行的线程池起线程，就把它放到同步的循环里面，导致问题。再比如，有的程序员用匿名函数，不懂闭包，导致放在循环里面每次取到的都是最后一个值。再比如有的程序员不深刻理解Session，就认为浏览器关了Session就没有了。再比如有的C#程序员不理解GC以为一个类只要实现了IDisposable接口就一定会内存释放……举不胜举，都是项目中遇到过的（注：对基础不扎实的程序员进行代码Review管用吗？我们项目实践来看不管用，因为资深程序员很忙，不可能一行一行去看去调试。）……所以，优秀的程序员都是建立在对该技术的深入理解的基础上的。优秀的成熟的程序员员工都有专业化（技术方面）、职业化（服务意识、协作能力、解决问题的能力和态度）和商业化（替客户思考和解决问题）多方面的优秀特质，才能真正的为业务创造价值。

保证代码质量的另外一个非常重要的方面就是测试，一定要写单元测试，使用Moq做单元测试。这可以培养程序员面向接口的思维方式，如果代码不能做单元测试往往是耦合度很高的代码，所以单元测试能发现代码质量的问题。此外，测试组的工作要及早介入，对业务的深刻理解，重复利用bug管理工具，敏捷测试。

为需求变化和维护早作准备

在系统设计的时候，要考虑到未来可能的需求变化，做好面向变化的架构设计。但不要过度设计。（这需要深入理解商业需求）

为维护早作准备，意思是说，在编码阶段，就要考虑到系统的可维护性，设想你自己就是将来维护这个系统和这段代码的人，这种意识很重要。有的程序员以为系统提交了上线了就没他的事情了，结果到头来上线了出现问题，系统又没有很好的log和trace，导致问题极难线上调试，而线下又不能模拟真实的环境，这种情况下必须为维护而设计，提升系统的可维护性、可追溯性、可管理性。

不要过度设计和过早优化

过度设计是敏捷开发应该避免的，很多工程师都有过度设计的冲动。例如，在一个web系统还没有看到被大规模使用的曙光以前，就设计了系统规模化，什么集群、负载均衡、读写分离、分布式缓存系统……说真的，这些东西确实是好东西，但也很贵。在系统还没有被大规模的用户接受和喜爱之前，这样做是否会抵消了我们把专注点放在核心功能和简练和简单的努力呢？时间是有限的，投资也是有限的。我们必须把有限的时间和有限的金钱用在当前最核心的功能和体验上。有时候系统初期，可能一两台服务器就足够了。只有在看到产品有被大规模使用和用户喜爱的曙光之后，才来增加功能和规模量。当然，你的网站功能，在你只有 10 万用户的时候，可能和你有 1 亿用户的时候会很不一样。所有太多太早太频繁的架构上的大动作可能会适得其反。这一点上，你要小心判断。系统架构需要及早规划，但不要提前实施和过早优化。

关注非功能性需求

也许大多数客户和咨询师也会听说过神马TDD、迭代、原型、持续集成和持续部署、Agile等时髦的词语，这些也让管理者很兴奋，以为软件产品是可以在很短的时间内高质量的完成的，即使完不成也可以在后面用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。这听起来好像很美好。但其中有个很大的陷阱，那就是客户和咨询师，还有原型、TDD大都只关注功能性需求，而忽略了非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。客户和咨询师在项目前期闭口不提这些或很少提及，但一旦功能性需求都做完了他们就会抱怨这些隐藏的非功能性需求。而像性能问题，高可用性问题，系统维护问题（模块的耦合问题）等并不是很容易重构，往往涉及到Re-design, re-architect；因此这些问题往往都在后期会成为重构噩梦，甚至可以让你的软件设计重新来过！更加糟糕的是，大多数客户不愿意为这些隐藏的功能重构而付钱。笔者曾经遇到过前期只注重功能性需求而后期发现性能不好而进行re-design, re-architect，这对项目管理来说有很大的挑战，因为不单单是程序和架构重构的困难，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。这是一个很大的陷阱。

所以，前期就要关注非功能性需求，不要急于动手，如果你能有多一些时间去和客户讨论一下需求和未来可能的变化，去调查一下实现的技术难点和细节，去和其他有经验的人讨论并推敲一下架构和设计，去思考设计上的缺陷，那么，你的coding会变得非常地直，直到你一眼就看到尽头，你的测试案例也会写得非常地好，你会几乎不需要重构，于是，你会在未来少写很多代码，从而你的软件开发会越来越轻松，直到技术开始换代。这就好像我们修路造桥一样，我们需要花大量的时间勘测地形地质，分析数据，思考可能出现的各种问题（各种自然灾害），评估不同的设计方案，而不是先尽快建好再说。(：磨刀不误砍柴工) 说到这里，有些反敏捷（反Scrum），没错，好的程序员要会做权衡/平衡，好的架构师要会做平衡，好的项目经理也要会做平衡，这非常重要。

再补充一点，有资深经验的工程师/架构师对非功能性需求的设计和平衡很有经验，这些经验对系统设计和项目成功至关重要。如果你很不幸，手头没有这些有经验有价值的人，而只有一堆码农，那么恭喜你，你可以在一张白纸上画画了。就开发他们的潜力吧，做好这个项目给他们积累经验的心理准备吧，量力而行吧，小马过河吧……实在不行你就自己上吧，毕竟公司要求用最少的钱在最短的时间内出来最优秀的东西；如果你有话语权，那就把你的困难及早让上层知晓。

严格控制需求和范围，和进度权衡，不出现资源空闲

领导一般会给项目经理压力，要求在什么时间提交一个版本赶进度等，这时候项目经理要么能调整一些需求和范围（Scope），要么就把可能出现的问题进行报忧，因为现在如果不这样做，你就等着现在报喜，后期报忧吧。所以项目经理一定要严格控制需求和范围（scope），和进度，和质量权衡。同时要合理调配资源，不要出现项目进行中资源空闲的情况（这个在Project工具中可以看出）。

项目风险管控

项目经理要有项目风险管控能力，及时在项目进行的各个阶段进行风险的预识别和管理。项目一般是前期工期松，风险低；而后期工期紧，风险高。所以项目经理要尽可能在项目早期能列出大部分的风险，这样在项目的风险应该是倒三角形状的，就是前期风险多，后期风险少。要预先把下阶段可能的风险明确告诉客户，让客户提供帮助来控制风险的发生，同时迫使客户加强风险意识，不让需求任意扩散和蔓延。在各个阶段都要有双方风险认知的会议纪要记录。一般情况下，项目的外部依赖条件是最不可管控的风险（比如要和第三方联调，要第三方提供API等）。其次是需求的不明确和需求蔓延的风险（需求问题占项目成功的40%因素以上，你能控制需求，你就成功60%了）。然后还有资源的可用性（如：项目进行中核心人员流失，要知道项目进行中间换人和加人都很是问题）。

资源提供者和问题解决者

大家都知道，打仗的时候什么最重要？对了，补给（后勤保障）。士兵上战场了，谁做后勤？项目经理。每天都要问大家，你下一步需要什么，你还缺什么输入？你有什么问题需要我这边配合的？程序员旁边有垃圾了，项目经理去扫一下地，这就是后勤补给。所以管理者首先要理顺管理者和人的关系，调整好服务的意识，做好资源源源不断的提供、帮助大家解决问题，系统就有了润滑剂，有了源源不断的输入，就能顺畅的开展。否则，千里马到你手里也跑不快的。

管理用户期望

对每一个Sprint提交，谨慎选择功能集合，多和客户沟通，管理好用户期望，他下一阶段希望有什么功能，这些功能的优先级如何，实现难度如何，及早告诉他下一个版本会友什么，不会有什么。

增加团队成员之间的亲密感

有时候如果一个团队成员里面有多个牛人，大家都是很有主见的人，就很容易在一些问题上争执，甚至产生内部竞争。两个聪明人意见采取谁的呢？紧张关系在所难免。这种纠结的合作和竞争关系是同事关系的主线。但要保持合作为重点。所以，要把这样的状况保持在一个健康的状态，需要加深团队成员的亲密感。具体来说，坐在一起聊天、吃午餐、喝咖啡、散步、打球、打牌，都是增加亲密感的方法，这样拉近人与人的距离，就不会觉得有什么竞争的紧张感了。

管理团队目标和情绪

Scrum有一个优点就是短周期快速迭代，每周大家都有明确的目标，因为Release周期很短，大家Vision很明确，所以为什么Sprint就是冲刺的意思。管理好团队的目标、Vision，有明确的目标，有冲刺的干劲。及时发现团队的情绪波动，采取应对措施（休整，腐败，激励）。

保持耐心，不断调整

技术上要重构，架构改进和提炼等。信任程序员，给他们时间来重构，来调整和优化架构等。管理上要重构，代码促进委员会，评审组等等。改进适合组织规模和业务发展的流程，目标是获得持续、快速、更好质量的交付产品和更好的客户满意度、更低的成本和更高的效率。总之，要不断努力，不断调整，不断尝试新的方法，做的越来越好。要保持耐心，给员工/系统的成长/成熟一点信任和时间。

项目经理的人格魅力和以德服人

作为项目经理您必须与同事以团队合作方式才能保证项目的顺利完成，如何鼓舞团队成员的士气？让大家心甘情愿的与你朝着共同的目标努力。要做到这一点，人格魅力非常重要。但要让大家真正服你，真正的服是以德服人。比如，你要求所有的手下都主动配合你的工作，但是你自己如果没有首先要求自己主动配合大家，你就不会赢得大家的尊重。这只是一个例子而已，很多点滴细微之处会让大家感觉到你的人格魅力，究竟是一个值得尊敬的人，还是一个不值得尊敬的、自我的、高高在上的发布命令者。总之，做人是最要紧的，做人没做好，做事肯定做不好了，项目多半要搞砸。

但就项目经理的项目管理能力来说，也关系到项目的成败，比如能否引导客户需求、对问题的透彻理解、对复杂的任务紧密跟踪并设定轻重缓急、利用各种渠道和方法来沟通解决问题、有能力做出适当的取舍、说服客户或领导的能力、推销自己解决方案的能力、突破性格制约的沟通技巧、面向全局思考的思维方式、如何合理动态分配大家的工作项使不被Block住……

总结

先写这么多吧，想到了再补充。

Update：现实项目管理中的一些实际矛盾

1. 测试资源不足和保证软件质量的矛盾

没有可用的测试团队或测试人员，在很多小型开发团队和小公司都普遍存在测试资源不足的问题，甚至在某些大公司也可能出现。严格的成本控制，导致测试资源相对不够；失败的项目开发计划会导致压缩测试的时间来保证研发的时间；到了测试的时候，就肯定出现你们现在这样的情况。最后的结果呢，是所有人都得不了好：领导会因为客户的投诉而头疼甚至被老板骂；项目经理会对质量负主要责任，对整个项目负主要责任。如果有测试团队，测试会对质量控制负主要责任。没有，项目经理负主要责任。

应对办法有以下几个：让开发人员做测试；让有限的测试人员只测试主要核心功能点；项目经理死扛，自己亲力亲为；降低软件质量；让领导充分意识到这个矛盾的风险。

2. 项目日程表异常紧急和按时上线的矛盾

这类项目最大的问题是时间成本。时间成本越紧，失败风险越大。要提高这种项目的成活几率，只有一个办法。砍范围。把所有可有可无的需求砍掉，放到下一期去实现。确保团队能够以合理的生产率产出成果。项目经理要做的最重要的就是，想尽一切办法，把优先级低的功能砍掉。集中资源保证高优先级需求的产出。要随时告诉明白客户，团队最大的产出是多少，团队正在做哪些功能。及时让客户进行确认和调整。让客户明白风险在哪里有多大。这是非常考验项目经理沟通、谈判、组织协调能力的。能把客户啃下来，保证团队正常工作，还有1、2分活的可能。不然，最后就当替罪羊吧。团队、老板、客户，都需要你承担责任。

3. 团队的生产率严重低于估计和项目按时上线的矛盾

项目竞标的时候是公司专家组资深架构师按照已有生产率来进行项目估时和报价的，但项目开始以后出现资源不足问题，例如：原来C++团队的资深工程师走光了，只有两个新人可用。原先是按照资深C++开发工程师的生产率来估计的时间，现在给你这样的一个团队，生产率和资深C++开发工程师相差很多倍。项目日程表却异常紧急，这怎么办? 没办法。这种项目的失败风险是极高的。解决办法只有找外援或者项目经理死扛了，否则这类项目失败是必然的。团队人员突然离开是项目的一个极大的风险，特别是核心资深开发人员，公司往往处于成本原因不可能对每个人有一个备份的人员，所以核心资深开发人员突然离开往往使项目处于高危状态。

4. 项目经理兼任Team Leader的矛盾

项目经理和Team leader这两个职位貌似是一样的，其实不一样。项目经理的职责包括：项目进度控制，成本控制，需求控制，风险管理，配置管理、任务分配以及与客户相关的沟通和交流等。而Team leader的主要职责包括技术方案确认，开发计划制定和跟踪，技术架构设计，重要技术问题攻关，核心代码编写和技术指导以及开发团队管理。对于小公司来说，为了节约成本很可能把两个角色让一个人来承担，这样的混合角色对个人能力要求非常高，需要两方面的专业知识，两方面都得一手把握，压力很大。现在很多大公司基本都将这两个角色分拆了，项目经理就是管进度，做协调，Team Leader就负责开发相关事宜，另外还有一个角色，叫Product Manager，这个角色主要是市场和开发之前做协调了。按照我的理解，项目经理需要对项目功能和需求（产品）有非常深入的了解，对软件开发过程相当有经验，同时具有很强的沟通能力，因为客户都是牛的一塌糊涂，你要引导客户的需求，那是沟通功夫了得。另外，项目经理是项目总负责人，对领导对跨项目和部门也需要及时的沟通协调以获得最佳的资源，以解决过程中的问题。而Team leader需要控制开发过程中的系统性风险，总体架构把我和关键核心部分开发。软件开发过程有很多的环节，任何一个环节出现大的差错都会导致焦头烂额并最终项目失败。但是在大多数公司，我们都不会称其为失败，一般会说：项目延期，好的延期半年，差的甚至有的延期1年！核心竞争力：开发管理＋过硬的技术能力。

5. 有限的资源和时间与按时上线的矛盾

项目管理的主要矛盾就是如何在有限的成本（资源）和时间内高质量的完成系统。根据毛*泽(东思想，革命为什么成功，要能分清各个阶段的革命主要矛盾，集中优势兵力来予以打击。在时间管理上就是轻重/缓急。轻重，即是否为核心需求；缓急，即优先级、顺序。资源有限，那就把核心资源放在核心功能和最大风险的部件上。我记得自己工作那几年，从来不考虑这种问题，领导让做啥就做啥，被动式积极(有任务就全力以赴，没任务就自学、不闻不问)，那时候我只是一位执行者。其实，任何事情都可以分成两阶段：先分配，再执行(日常生活中，我们做任何事情都是先在脑子里分配好了)。而在公司，这两件事往往是分离的：领导做分配，下属做执行。

分配任务的核心原则，就是先分清轻重缓急，作为管理者，一定要将它养成习惯。

Update：优秀项目经理必备素质

1. 交付能力

项目经理是项目的负责人，不管发生了什么，都能按时交付，优秀项目经理要具备这个素质。充分理解需求和范围，充分和客户明确详细需求和期望，充分考虑自身团队的技术能力、项目依赖、队员排期冲突、负面情绪、技术方案风险、未预知的技术障碍、需求变化等。具备为功能的设计做取舍的能力，但功能取舍并不以牺牲产品的核心愿景为前提。具有极强的交付能力的前提是具有极强的责任心。有了责任心，你会把项目当成自己的孩子，倾注你的全部心血，即使出现极端困难的局面也会死扛。责任，会驱使你关注项目的进度，千方百计去寻找各种资源，推着项目往前走。甚至吃饭、睡觉，走路、坐车，都想着整个项目团队，想着他们还在加班加点，你可能很自然地给他们带点夜宵、冲杯咖啡，犒劳员工。有了你这样的项目经理做表率，整个团队会鼎力支持工作，士气非常高，技术问题也迎刃而解，得到领导称赞和客户肯定，项目将朝着预想的方向发展。许多开发人员抱怨项目经理一天没干多少事情，而工资还挺高。其实，项目经理一刻都没闲着，他总在想着怎样更好的执行项目计划，调整项目进度等，脑子一直在不停地运转，所以说项目经理是真累。

2. 沟通能力

项目经理上有老板、客户，下有项目组员，属于夹板层，沟通不好，容易出事。PMBOK(项目管理的知识体系)指出，项目经理75%～90%的时间用在沟通上。沟通的对象不同，方式也有多种（正式非正式）、技巧也很多、沟通的媒介也多种（Email, SNS，电话，视频，面谈），但最终的目标是沟通必须能让对方接收、理解并和你取得一致。

3. 引导客户的能力

“客户是上帝”，但客户不一定全对，而且有的时候是错的，尤其在项目还没开发出模型的时候，客户有时根本不知道自己需要什么样的东西。所以，在项目启动会议后，双方要“把丑话说在前面”，分清责任。项目经理要站在客户的立场，努力满足客户的业务要求，让软件真正为客户创造价值。但是，如果项目经理总被客户牵着鼻子走，就很容易陷入被动的局面，结果是客户的需求一直在变化，造成程序不停地返工，项目总在原地打转，很难推进，久而久之，大家筋疲力尽，积极性严重受挫。最后，项目做得一蹋糊涂!对于客户提出的需求，项目经理要凭借优秀的技术水平、充沛的业务知识快速估算需求的变更需要多少开发工作量，有没有更好的解决方法。理想的情况是程序基本不做改动，又能满足客户的需要。但笔者往往是采用变通的方法，换一种方式实现客户的需求。这种情况下，需要项目经理对系统结构有全局的认识，尺寸一定拿捏得很准。项目经理有时充当白脸、有时是黑脸，但无论如何，一定要维护组员的利益，笔者经常看到很多项目经理有意无意地在客户面前说开发人员的不是，遇到客户不满意的地方，就指责开发人员。这种方法欠妥，笔者一般是跟客户表态，向客户承认“错误”，回头再找开发人员讲道理，做到“内部的问题内部解决”。