〇、前言
因为工作需要，又开始对DevOps进行了一番研究，这次应该是认真的了。
DevOps算是一种当下比较流行的理念，知识体系也算不上繁杂，让我深有启发的是出自《DevOps三十六计》中的一幅图：
不过，本篇文章并不打算阐述DevOps的知识点，而是DevOps的一个抓手：敏捷开发。
根据豆瓣的推荐，我逮到了两本书：
《The Agile Samurai: How Agile Masters Deliver Great Software》
《User Stories Applied: For Agile Software Development》
两本书有一些知识点的重叠，目的是对照和巩固，以期能碰撞出更大的火花。
近来，我确实有一种冲动——拼接出一副技术管理者的知识图谱，深知不易。上一篇文章《技术管理的道与术》是对技术管理的通用“软技能”的一次横向碾展，那么这篇文章将会是一次纵向维度的深入。
一、谈感受
在这里，我并不会逐一罗列书中涉及的各个知识点，以后也不会，因为我觉得这样跟抄书没有什么分别。也不会去讲作者/译者的来历，知道了又怎样？书的内容才是主角！
不得不承认，我有一个难以逾越的障碍：外国人写的书，读译制本，好像作者在扯蛋，不知所云，读原著，mmp……
所以，很长一段时间，我都有意无意的在挑选国人写的书。
但是，这次读过这两本书后，却让我瞬间感觉振奋，酣畅淋漓：真爽！
难道脑子突然开光了？
这两本书完全覆盖了整个敏捷开发的生命周期，并且我着重对“用户故事”进行了一番深入了解。
当然，大部分都是一些理论基础，有一定的指导意义，还是需要读者活学活用。不过，作者在一些重要的地方还贴心的给了充足的应用场景，教读者如何应对，尽管实际情况并不会这么简单。
特别是在“The Agile Samurai”这本书中，教读者创建可视化工作区，随时准备迎接领导的莅临，随时可以汇报项目的进展情况。流程一气呵成，保证让领导看得目瞪口呆。
二、从用户故事讲起
无需急着给“用户故事”下定义，每个人对用户故事的把握尺度不尽相同， 也就不用太在意如何去概括“用户故事”的含义。
如果非得找个参照物，那就追溯到传统意义上的软件工程，当中有个“用例（user case）”的概念。注意，只是参照，并不可将这两者画上等号。
如果用例是粗犷难啃的老腊肉，那么用户故事就是精致细腻的小鲜肉。
如果读过用户故事，可能会误认为这是在描述一个场景（scenario），而真正意义上的场景描述却是具体而详实的，详细到了人机交互的每个细节，而用户故事是不能达到这种颗粒度的。
如果要把握编写用户故事的尺度，遵从INVEST原则即可。分别是Independent（独立的）、Negotiable（可讨论的）、Valuable（对客户有价值的）、Estimatable（可估算的）、Small（小的）、Testable（可测试的）六个单词的首字母。
其中，如何估算用户故事的大小，变成了一件伤脑筋的事情。
绝大多数是使用点数系统来表示用户故事的规模大小，以往的“人天”的概念，是有一项大前提：在办公室的8小时都是全身心投入到工作中。
作者称之为“理想日”，而“理想日”的是绝对估算——人类不太擅长的一种估算方式。
如果拿一块石头放在手中，没有任何参照的情况下，是很难说出这块石头大概有多重。但是如果另一只手上掂量过一颗已知重量的石头，那么对于估计另一块石头的重量，就显得更容易了。绝对估算容易犯“经验主义”的错，一切行事靠“感觉”。
绝对估算不行，那就用相对估算吧？
其实也没那么容易，因为需要寻找靠谱的参照标准。
不妨，按照“先定性，再定量，最后对齐”的方式进行估算。
“定性”就是先把用户故事大小简单区分等级，比如小、中、大，A、B、C，等等，不要细分太多等级，不然会造成不必要的负担。
“定量”就是每个等级给一个点数范围，比如，小对应13点，中对应410点，大对应11~20点。在相应范围内为每个用户故事给一个点数。
“对齐”点数是最后的关键步骤，类似“德尔菲法”，团队成员交叉进行估算，最终达到相对一致的估算结果。
以上过程会在项目前3轮迭代中频繁使用，后续团队速率（每次迭代完成故事的总点数）趋于稳定，对于估算来说，会变得更轻松愉快。如果团队速率持续震荡，可能是团队成员不稳定，或者是客户需求变更频繁。
最后，给大家看一下用户故事到底长啥样：
从模板内容上，不难看出，用户故事是以客户价值为导向的，并且促使开发团队去思考“WHY”的问题，而不是领完任务就一个劲儿的扎进代码的海洋里。
三、交付启动计划
这个概念也是从“敏捷武士”那里习得的，初看，确实不太容易理解，而且，书中多个章节都提到了“交付启动计划”，似乎是一个实施敏捷过程的必经之路，促使我又回到前面，去了解“交付启动计划”到底是什么。
“交付启动计划”并不是敏捷开发的必要过程，应该是ThoughtWorks总结出来的工作方法论。可以认为是给全员看的纵览全局的迭代计划，内容可能并不详实，但是都是踩到点上的，是项目干系人必须关心的东西。
“交付启动计划”是一项全员性的工作，这正是我所欣赏的原因所在，也是敏捷开发的精髓之一。如果说敏捷团队是一支4~7人的精悍组织，我是一点都不会反对的，这也间接导致了现在软件开发难以转入敏捷的问题。
思考“HOW”的人只增不减，而思考“WHY”的人却不见增多。
所以，在回答“为什么做这个项目”的时候，交付启动计划给出了非常有意思的答案：电梯演讲和产品包装。
电梯演讲的挑战在于需要你在30秒钟的时间内阐述你的核心思想。短小精悍，思路清晰，直达要点，能做到实属不易，需要和团队多次演练才能做出一个好的演讲。“敏捷武士”给出了一个电梯演讲的模板，读者可以自行填空：
不难看出来，电梯演讲是个好东西，应用的领域也不限于敏捷开发，完全可以作为一个技能点，不断的打磨升级，提升自己对事物的洞察力。
产品包装也是一项相当有意思的工作。作者在书中打了一比方。
把价值上百万的软件塑封起来，放在超市货架上，虽然离这一天还有很长的路要走，但这确实也引出了一个非常有趣的问题：如果可以从超市的货架上购买软件产品，那产品包装应该是什么样子？更重要的是，我们会购买吗？
“敏捷武士”把这个产品包装的设计过程分为了三步：集思广益，列举产品优势；设计一条广告词；设计产品包装（海报）。
如果你所在的是一支仪式感十足的团队，那么按上述步骤来做未尝不可，不过，大多数情况下是不会这么做的。
个人建议是把项目的优缺点给想清楚就行了，能清楚意识到自己在做个什么玩意儿就行了。至于那些非常酷炫的宣传图，slogan之类的，让其他部门去操心吧！
四、一些敏捷文化
这个章节并不是把《敏捷宣言》拿出来讲一遍，而是我从这两本书中强烈感受到的敏捷团队必须具备的文化氛围。在此，我只会抛出这些概念，不会进行详细阐述，可以自行阅读感受。
价值导向。很现实的一件事情，我只做对客户来说有价值的东西。如果一件事情风险高，一件事情价值高，螺旋模型会选择风险高，敏捷开发会选择价值高，当然，现实情况往往都是需要平衡的，无绝对。
集中办公。并不要求每个月拉团队出去浪一浪，每个礼拜请团队成员吃吃喝喝，保证团队成员畅通明晰的沟通渠道才是关键，能口头沟通的就尽量不要用IM，事后需要总结的话，就发一份邮件简要说明。
全员参与。这里的“全员”（最好）包括客户，如果有专职客户，那是一件非常幸福的事情。如果你自己都不知道客户是谁，或者从来就没见过客户，那就只能祝你好运了。
通用语言。你可能在DDD中看到过整个词汇，但这并不意味着一定用采用这种开发模式。通用语言的好处显而易见，至少在你说A的时候，别人不会理解成a。当然，实际情况是，业务部门才不管你用什么通用语言，各种词汇往外喷。多聊几次，建立起业务部门的通用语言与技术部门的通用语言的映射关系，当然，这是没有办法的办法了。
拥抱变化。其实你所做的大多数文档在软件交付之前就可能过时了，源码是最好的交付成果，而制造源码的程序员才是公司宝贵的资源。敏捷开发本质上是一个发现偏差，迅速纠偏的一个过程。
测试驱动开发。这个未必能做到，但是我注意到了其中单元测试的重要性，而且可行性很高：发现一个Bug，为此写一个单元测试。这样做可以让你了解Bug的存在，复现之，并且在今后的持续集成中，减轻回归测试带来的痛苦，自动部署的信心也增强了。
随时重构。不得不承认，这部分跟程序员的代码水平是有一定关系的，为了避免后期累积大量的技术债务，导致大面积重构，需要有随时重构的习惯，这部分的能力可以在Code Review阶段得到加强。
生产就绪。这种文化要求有些高了，人们都在追求财务自由，而敏捷开发的程序员们却在追求产品部署自由。
五、总结
最后，不要再去纠结一大堆的需求文档，产品文档，或者是技术文档，一切都是够用就行。可工作的软件是衡量项目进展成功的主要指标。
敏捷开发并不是对传统软件工程的一次颠覆，只是加速了整个软件开发过程的闭环，以适应当下时代对软件开发效率的更高要求。
敏捷开发不“敏捷”，与君共勉。