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管理工具，敏捷测试。