敏捷系列（1）不讲落地，都是耍流氓

       不讲落地，都是耍流氓——我相信这句话在各个知识领域都适用，但在“敏捷开发”这个领域尤甚，因为只讲理论、纸上谈兵的机构或个人实在太多，包括培训机构、咨询公司、应聘面试者等等。我想造成这种情况的原因，主要是因为敏捷落地的实际意义在于形成组织文化，而文化这东西，是一种基因（参见《人类简史》），不是一蹴而就，需要日积月累，而理论化的东西，在信息爆炸的今天，获取门槛很低，背熟几个专业术语也不是难事。目前所在的公司，已经实施敏捷一年多时间，虽难称形成“文化”，但基本具备雏形。最近开始梳理这一年多来敏捷落地的经验教训，希望能形成体系化知识结构，在操作层面可以传承，所以有此“敏捷系列”（希望不要太监）。最讽刺的，在讲操作层面之前，仍需从理论开始。开篇先讲理论……

    【背景】人类进入工业社会之后，每个人都是流水线中的一颗螺丝，通过流程串联每个个体，达到组织效率最大化。而软件工业也一样，需要流程来优化软件产品制作效率，而不管是瀑布模型还是敏捷模型，仅仅是人们抽象出来的通用模版，既然是模版，就需要结合不同团队实际情况，在执行中不断尝试，最后才能从中提升，团队认可了某种虚构的核心价值，正所谓“组织文化”。

    【目的】目的肯定不是为了赶潮流，而如果说目的是“快”，也不准确，核心目的在于有些软件产品（如互联网产品）无法充分调研用户需求，只能“拍脑袋”想出需求投入市场试错，既然叫试错，肯定要快，否则无法达到市场效益目标。第二目的是组织效率，但不一定是快，而是团队运转中，是每个岗位、每个时间点都能清晰当前任务，像《加勒比海盗》中的海盗，船长一声令下，所有人各施其职，看不到“发呆”的水手，即不会出现“空转”。而如果某公司主营企业信息化系统外包业务（需求清晰，无需试错），且形成了CMMM的流程体系（组织效率已经够高），那么就没必要赶“敏捷”这个时髦了。

    【利益点】目的很清晰，是的，理想很丰满，但骨感的现实，往往在执行层面遭遇种种碰壁，本来已经按部就班做得挺好，没有哪个部门会心甘情愿的配合执行。所以，如果你负责任何流程的落地，不管通过什么手段，忽悠也行，要先让每个部门团队知道他们的利益点在哪，而不要去讲上一段的那些目的，那些大道理没人关心。下面讲执行落地三大原则。

    【原则一】需求切片。更准确的讲，应该加上需求池打包，把需求集合打包装载在一个个版本车厢中，至于切成多大，每次打包多少工作量的需求，则看团队产能而定。我们现在基本能做到一周一个小版本，一月一个APP版本。下图是我们月度版本时间节奏。 

       但有例外，其一，MVP 最小化可行产品（Minimum Viable Product）不要去切片，那没有任何意义，反而增加了测试工作量和集成成本。其二，运营确定推广时间的，不宜切片，如每年的双11大促，因为那需要投入最大资源保证进度。这两种情况我们以独立版本管理，即有两类独立版本——MVP产品和大促版本。

    【原则二】职责打散。除了部门老大负全责，他往下分解责任时，不要集中在1-2个人身上，当然是效率考虑，精力和时间有限。我们的做法是打散到每位产品经理，谁提的需求，谁负责跟进，包括上线时间、开发进度、问题协调等等跟进到底，而项目经理负责版本统筹，确保版本的节奏感。

    【原则三】工具应用。敏捷的目的之一，就是要效率，如果哪个人介绍他们的敏捷落地基本靠手、沟通基本靠吼，那就不能叫落地，工具就是拿来提高效率用的，换句话说，没有工具，就不叫敏捷。工具分几大类：项目管理（我们用redmine）、沟通（wiki，用conflence）、代码管理（前端用git，后端用svn）、持续集成（jenkins）、测试（redmine）。

       好了，理论的东西基本讲完，往后会从我们在版本迭代过程中，包括计划制定、工具应用、测试、持续集成等方面去展开。