《敏捷主义 ：从技术、商业和个人视角看敏捷商业思维》读书笔记（2017-03）
1、接受变化，改变自己
提到敏捷研发，你会想到什么什么词，比如下面这个？
为什么有这么多词，不单单是每个人对敏捷的理解不同，更主要的是每个人对敏捷的需求不同。有的人为了快速，多完成任务；有的人为了效率，少点加班；有的人为了灵活，解决不断需求变更的问题；有的人为了提高团队能力，不想像流水线一样工作；也有的人不清楚，只是知道敏捷好就追求使用，等等。这正是我们导入敏捷之前要做的，明确我们的目标，不同的目标导致我们执行出不同的结果，遇到不同的困难，敏捷仅仅是解决问题的一种方案，而不是唯一方案。
回到上面的问题，每个人估计都能说出10个以上的词，想想在没有敏捷的时候我们能不能办到？为什么有了敏捷才去考虑这些词呢？可能我们都习惯了吧。
老生常谈的一句话了，世界上唯一不变的就是变化本身，要拥抱变化，而不是拒绝变化，很多人都明白但是就是做不到，其实根源上来说仅仅明白了意思，而没有抽象出来的意识，也就是要有一种思维：拥抱而不是拒绝。比如压力来了要拥抱压力，提高自己抗压能力，而不是拒绝压力想办法减少压力；比如工作中我们遇到困难了，要想办法解决困难而不是辞职逃避困难；比如生活中对于未知的事物要敢于拥抱和尝试，而不是拒绝和恐惧......
敏捷就是为了适应变化存在的，很多思维需要转变，这个转变会非常痛苦，因为很多观念和我们过去的经验是矛盾的，甚至冲突的，也会有很多地方我们自以为困难，自以为现实条件如此而无法改变，从而自己限制自己，如何突破自我，拥抱变化是我们要迈出的第一步。心理学里变化之旅刚开始是一个痛苦的过程，一旦我们达到常态化，我们的能力就会上升一个层次，人生的台阶也正是这么一步步上升的。
如果一个人刚参加工作就进入一个使用敏捷模式的公司，那么不会存在思维转变的说法，就像我刚刚学编程的时候主要是C语言、嵌入式语言等，后来学Java需要理解什么是面向对象，如果一个直接学Java的人，根本不存在这个疑惑，直接就是面向对象的思维。所以对于熟悉传统研发模式的人，敏捷思维是第一道门槛，这就需要我们拥抱变化，能够断舍离一部分以往的经验，积极转变思维来接受敏捷。
提到敏捷模式，很多人第一印象就会想到站会、看板、演示、反思会等，这些都是工具和方法，其实用不用敏捷这些你都可以使用。还有人马上会想到迭代式开发、增量交付、用户反馈推动产品开发、自组织、跨职能团队等等，这些都是做完之后的结果，而不是目的，比如不能为了跨职能团队而去打造跨职能团队，而是为了目标，团队成员调整之后变成了跨职能团队，这个为什么要调整成跨职能团队，才是我们要有的思维。
2、关注人，高素质的人
记不清在哪里看过了，说传统研发模式vs敏捷开发模式就像计划经济vs市场经济，我觉得这个比喻很恰当。
传统模式像计划经济，依赖的是精英进行的顶层设计，迷恋于对流程规范的定义、监管、控制，不相信也不依赖基层参与者的创造力和自我决策，基层参与者被物化成了一个个活的机器或是蚁群中的工蚁。
敏捷更像市场经济，它当然也注重精英对社会的设计和他们的领导作用，但是它同时更尊重经济活动中每一个基层参与者的自我决策和创造力。敏捷开发的根本优势在于对人的解放，对团队成员的尊重和信任，承认他们是软件开发活动中必不可少的创造者而不仅仅是一个操作工。敏捷开发从它产生的第一天起就强调了对开发人员的重视，强调代码的进化和重构，要求开发人员能够发现代码中的一些不好的设计和不能清晰地体现设计的代码，并能够对其进行重构和改进。
不是操作工，也就对人的素质提出了要求，不论是跨职能还是自组织，都非常依赖团队成员的自发性，如果团队成员中没有敏捷意识，不够积极主动的话，任何敏捷方法都会回退。很多项目和公司采用敏捷失败的原因不是他们实践敏捷方法的细节有什么错误，而是他们从一开始找的人就错了，他们的团队成员水平不够，温饱都是问题，考虑工资低就跳槽呢，不太可能讲什么自组织，跨职能等等。举个例子，完成一个项目一种方法是高薪招了5个精英来做一个项目，另一个是招了10个普通人干活，因为他们水平低，为了他们还要招3个测试，招2个需求，招1个经理管着他们......
3、价值大于功能
传统开发模式多注重流程，是功能导向的，前期想尽办法调研、沟通、确认功能，一定保证按时完成，也就是限定时间限定范围；敏捷开发注重反馈，关注客户，是价值导向，也就是说允许放弃一部分功能，从而保证做的都是有价值的，整个研发过程一直都是在动态变化的，敏捷开发的一个核心理念便是："Fix time, Flex Scope"——固定时间，弹性范围。两者的目标从根本上来说就是不一样的，没有对错，只有适不适合。
举个我们实际的例子，我们项目实际每个月计划100个需求，传统模式下限定时间限定范围，一个好的研发经理分解到足够细，日常跟踪到足够细，想尽办法掌控精准的进度，加班加点，大家保证完成任务，如下图：
导入敏捷我们就要思考了，首先多就是对的吗？100个就一定比80个好吗？可能不一定；其次，我们可以尝试改变我们的模式，提高效率了说不定完成的更快了，效果如下：
现实情况远比上面例子复杂，往往版本开始会根据团队规模规划需求，比如规划要做100个需求（实际客户反馈了200个），研发过程中会临时插入了50个，这150个当中可能有10个分析后可能不做了，可能有10个需求改动太大推迟到下个版本，可能因为做不完砍掉了50个......最后交付了60个，最终完成的这60个和最初的计划的100个，重合的可能也就40个（有时候会更低）。在这种常态下，我们真正完成需求数量的多少已经不太重要了，完成需求的符合程度，划分需求优先级才是更重要的，更加适合敏捷。
简单来说，就像你在赶公交车的时候，这趟跟不上就要等下一趟，一趟车能装100人，30分钟一趟，你会什么感受？现在我们把这个车改小了，能装20人，5分钟一趟，就这个意思，没错，就是牛逼。
4、成长大于成功
在传统的模式下，目标单纯且唯一，就是交付功能，极端点说为了完成交付，天天通宵加班也是有的，每个人都像流水线上的操作工，虽然不至于说“我需要的是一双手，为什么给了我整个人？”，但也差不多了，开发人员只是负责把设计文档翻译成机器能读懂的代码，仅此而已，很多矩阵式管理下的项目组经常完成一个项目后解散或人员调整。
而敏捷模式则不同，注重的是持续长期交付，而不是短期利益，所以对团队和人员的要求比较高，需要团队能够不断成长，需要团队不停的学习、总结和反思，而且每次都必须是有效的反思，不能走形式，不能一个领导独自总结。这个模式下，关注的就是团队和每个人的成长，想尽办法让团队和每个人的水平都能提高。能力提高了自然完成更有效率了，虽然短期来看没有不像传统模式那么努力，仿佛每个人都没有发挥出120%的能力，但是长期来看，总的完成价值比传统模式要高很多。
简单来说，同样100分的能力，传统模式想尽办法让这个人发挥出120分的水平，而敏捷更喜欢想办法提高这个人的能力，比如提高到150分，发挥80%就超过了传统模式，这才是以结果为导向，不关注过程是否努力。
再次强调，这是一种思维，不是具体方法，就像Google不提具体敏捷，依然给每个人20%自由时间研究自己感兴趣的领域，有些公司要求研发人员必须写公众号，必须参加业界也是类似，相反还有很多公司禁止在公司看书，上班采用996，上班期间不允许手机上网等。当然，很多领导错误的理解结果导向，在无法保障最终结果的顺利完成的时候，只能保证过程中团队足够努力。
5、快的意识
几年前公司刚实践敏捷的时候，团队就有人问我，敏捷最关键一点是快，迭代了只是把迈大步变成了小步快走，没看出如何快。其实团队的行动要迅速，有很多要快的地方，反应快、交付快、发布快、开发快、纠错快、收效快等等。
那怎样才能快起来？一个很容易想到的答案是：轻装上阵。怎样才能轻装上阵？减少不必要的环节与各种开销、浪费。只为最终成果负责，中间过程能简化就简化，文档、流程、规范能够弱化就弱化，减少这些环节带来的消耗，把精力都投入在最终成果上，比如有些公司要求开发人员要保障85%以上时间在写代码，而不是沟通开会。当然，这也带来了较高的要求，就是团队能力和人员素质要高，这也是这些敏捷方法相互作用的结果，单拿出来某一个效果很薄弱。
另一个就是响应变化快，前面也说了关注价值，拥抱变化，以前加一个需求要下个版本，或者当前版本需要变更，讲究的是控制变化，如何把控需求变化有时候也是很多人的考核指标。而敏捷关注的成果有没有用，不在乎变化，所有的一起都是为了适应变化而调整的。
当然，做到这两步仅仅是形式上的快，真正的快是团队所有人要有快的意识，比如有时间管理意识，对时间敏感，有今日事今日毕，要事优先等等观念，而不是完不完成无所谓，晚几天就晚几天吧。
总结一下，敏捷主义对于个人和团队来说，主要是关注成长、拥抱变化。这本书的内容并不多，20多万字，每天早上看一点，几天就看完了，主要从企业和个人的视角看敏捷方法，从技术和软件的视角看敏捷，更像是一篇篇blog的总结，有很多方法论，适合有一定基础，比较懂敏捷的人阅读，后面还有关于敏捷文化的部分，后续再总结。
