敏捷体系在软件开发过程中多有运用, 种类不少，Scrum是其中最为著名的一种。Scrum注重迭代和增量化开发，和短周期的发布。这样给领导层很大的透明度。同时又尊重周期内团队的独立性，强调周期内不进行需求的变更。
我是2006年开始接触敏捷的。首先在美国接受客户的培训，作为Scrum 组员参与项目运作。同时在离岸中心建立团队，逐渐接轨客户现有的Scrum团队。在美国客户现场近八周，然后在离岸中心运作十八个月，作为离岸团队的Scrum Master配合客戶团队一起进行开发。客户是当时一家著名的软件产品开发公司，座落在西海岸一个很美丽的城市。
之后的这些年，我做过和看过这样那样的一些敏捷项目，想坐下来谈一下我对敏捷的的认知。
我不认为自己是敏捷大家，只是想略舒己见而已。
首先，敏捷对我来说，是需要用最近很流行的工匠精神来进行诠释的。
我所认识的美国产品公司，自有的敏捷团队成员平均从业经验超过20年。20年的程序开发，足以让他们知道在软件开发的过程中该做什么不该做什么。他们会静心了解产品本身，而不是急躁的马上下手干活。他们是合格的敏捷团队成员，知道自己能够和可以担当什么样的任务，然后给出合理的估算。他们在过程中也知道变通，把不能完成的推后，并且和团队良好沟通。
反观国内的团队，大致工作经验较低。很多情况下，传统的项目经理往往会取代了Scrum Master的职责。因为很多时候组员不懂得自己怎么去选任务，给出的估算很多时候也是上上下下的。每天通报任务进展的时候，明明是走不下去也不说，直到耽误其他人的进展时才被发现。
这里为了防止以偏概全，我想说我们还是有好些敏捷团队是走在了正确的道路上，是努力着用敏捷的理念来要求自己的。经验其实假以时日是可以补足的，正确的理念会让过程加速。
第二个重要的方面是领导层的理解和支持。
有很多时候，领导层实际不了解敏捷，或者曲解敏捷的含义。由此带来的现象往往是
1）Sprint的周期随心而定，明明定义的4周，这个周期变为6周，下个周期变为8周
2）周期内频繁变动需求，然后美其名曰认为敏捷就应该拥抱改变。
3）产品主管需求产出缓慢，Sprint开始时就只能给出三分之一的需求，时间过半时才能给全。
第三个方面我想说工具使用其实不是重点。
见过很fasion的Scrum团队, 用的是可以随时打印的电子看板，电视会议设备齐全，付费的Jira或Rally都配好。也见过只用excel sheet记录任务和追踪燃尽图的。其实不能说用先进工具的团队就一定占有先天的优势。我觉得团队是否能把敏捷的精髓运用到日常的运作中，才是成功的重中之重。
最后想着重说一下在项目外包场景里，实现敏捷有哪些问题需要注意
1. 尽量签署定时和材料（Time and material）合同，而不是固定底价合同
敏捷不等于随心所欲，敏捷不能需求无限，变更随意。项目成本需要由领导层和产品主管来把控。咨询顾问团队是需要通过签约和履行合同条款，来获得服务收费。定时和材料合同能够有效防止客户利用曲解敏捷的定义来延迟或拒绝服务费用。
极端的例子有见过客户说只同意支付每个sprint开始时的估算，然后不断在sprint周期里压榨更多的需求。
2. 使用有版本控制功能的系统进行sprint plan和任务追踪
这样与客户方能够有一个互相认可的平台，可以在有争议的时候有据可查。
3.一定不要以加班的方式完成超过团队能力的工作量，除非有客户最高授权负责人的书面认可
以上只是较随意地列出一些能想到的东西，应该是不完全的。
其实我常常反问自己，敏捷究竟在哪些场景里是合适？
我觉得可能只有两类 -
好的产品公司，愿意静心打磨一款产品
因为真敏捷是需要投入的，好的东西都有它的代价。测试驱动开发，自动化测试，开发运维管理都需要有额外的投资。
其他公司，真正理解敏捷的内涵，愿意用敏捷的理念来实现自身系统开发的
很多公司用敏捷只是喜欢花哨的名字和理念，而不懂内涵。软件外包和离岸团队的情况下就注定了成员的经验不会太多。如果是这样的搭配，做敏捷的道路肯定是崎岖的。
此文只是抛转引玉。以后也会就问题提出更多的一些解决建议和方案。
