敏捷
背景
前前后后经历了几个公司敏捷的做法，有些些感悟，在此表一表。
开始
首先咱们说一下为啥需要敏捷，因为敏捷的业务目标是更早的交付价值以及更灵活的应对变化。我认为这是之所以那么多公司或者团队想要实践敏捷的最大原因之一。
让我知道敏捷的公司，那是在14年我进了一家主打3D数字建模的公司，我的直接领导是公司敏捷的推崇者，当时两个研发团队也是按照敏捷走的，但是敏捷到底是个啥？当时老大给了我一本书让我自己去悟。书名好像是《Scrum敏捷软件开发》。之后大体有了个了解，至少对站会、用户故事、backlog、sprint、SM、PO等词有个概念。
那时候觉得挺新鲜因为在此之前我只知道瀑布模式。在这家公司时我对敏捷印象是最深的，因为我经历了新旧之间的碰撞，不仅是思想上的还有实操上的。因为公司还有个管评审的年长型主管A大，他刚好更偏向于瀑布模式。
正文
chapter 1 ：
先交代一些往事，当时的我，迷茫的一逼，感觉写代码不适合我，我想要转产品，当然我说的产品不是UE性质那种产品哈，我说的是正儿八经的那种产品经理，“那种”指的是：从0到1打造适合用户且用户要买单的那种产品的产品经理。
刚好我的leader就有个类似经历的人，他曾经因为在上海的一个研究所交付的产品令客户不满意，他去呆了3个月，硬生生从0到1重新根据需求设计产品，最终成功交付，当时研究所的人对他的评价是，他比我更懂我得工作。不然为啥他被现在的公司拉去当了副总？你品一品他当时只是一个研发岗。
我虽然面试的是开发岗，刚好当时负责面试的人有事出去了，他刚好遇到了就说先跟他聊一聊，当我告诉他有意向走产品的时候，由于聊的很好，他果断把我留下来当他的助手了。所以我入职是没有经过技术面试的…。
入职的title是产品助理，前期主要干的事就是看书，用Latex写公司宣传文档和摸鱼，后期就让我跟项目，主要是做项目需求。
由于我们的客户多是各种工厂所以通常位置都比较偏僻，想去泡个脚都要摩托转公交再转出租的节奏。
犹记得当时把我一个人丢到工厂的时候，那种无助…工厂里的人通常都比较务实比较直接。被怼的体无完肤到和颜悦色，中间也就是几顿酒的事….故事太多以后写小说再用。
说这些是怎么个意思呢？其实没啥意思，就是说说一些背景，任何事物都是有联系的，你再细品。
chapter 2：
接上，在工厂第一次差不多进一个月，工作内容就是梳理各个环节各个干系人的需求，并整理成文档。
感觉终于告一段落之后，速度赶回北京。然后就是评审，这个时候问题就来了，我老大觉得现有的需求可以开始准备进入研发了，遇到需求问题再澄清就行，但是评审主管就不干了，说你这需求文档需要细化的地方还有挺多，不能进入研发，所以评审没过。会后两位大佬分别拉我谈了一次，一个觉得需求不够完整（瀑布），一个觉得需求已经够了（敏捷）。那为什么双方没有达成一致呢，在我看来当时我老大推崇的敏捷没有玩好，比如A提的一点，研发是敏捷了节奏都挺快，交付周期也缩短了，但是交付结果不太好，老有返工，导致一个项目迟迟不能最终验收，这就是A不赞同的根本原因，因为连客户想要什么都没有完全搞清楚。
对应到敏捷里的内容就是，在检视和调整两块没有足够重视。也就是下面的几个会议没有开好：
- Sprint 计划会议
- 每日 Scrum 站会
- Sprint 评审会议
- Sprint 回顾会议
我理解以上四个会议就是每个迭代里防止走偏的措施，但最后还是走偏了。
chapter 3：
现公司一进来就是敏捷，但是大多数时间也是走的不顺，有段时间还专门找了教练带着跑了几个月，效果也是一般般。
当时我想了想可能原因有下面几方面：
公司是家传统意义上的软件公司，前面都是瀑布模式，虽然是新产品线但是也有很多老员工，所以不管从公司还是从人来说，这个转变是需要时间且需要强有力的刺激，很明显是时间给够了但是刺激不够。我们都知道有刺激才会有反应。
大家对敏捷的理解参差不齐，很多朋友是随波逐流，且最致命的是这类朋友基本上都认为自己是懂敏捷的，但是真的懂吗，大概率不是的或者只停留在字面上的理解（我其实也是一知半解）。
敏捷应用其实在我看来是一系列的动作的组合，该套组合需是不断优化且需要组织严格遵守的，组合好之后，把该组合套在软件的开发周期里，然后一遍一遍的重复重复再重复。
另外很多人的误解是，敏捷就不用写任何文档了，在我看来不是的，必要的文档还是需要的比如设计文档。
前段时间公司大佬给够了刺激，比如重新梳理组织架构、丰富了工具、完善了开发/评审流程（必要的设计文档等）、强制执行双周迭代、双周演示会等等，我的感受是团队的流转效率是有提高的。
小结
我理解的敏捷其实是门大学问，不是只有简单的一些关键词，比如还有“以赋能和信任个人为中心的文化”这类的理念内容，持续学习中。
所以其实我没啥发言权，不过随便说说，也没谁管得着，反正是我自己的博客….。
从我的经历来看，敏捷是个好东西，但是落地也确实不容易，除了敏捷本身就代表一种变革（动作大）以外，它本身也涉及到很多关于人的因素，比如人的思维、习惯、团队文化等，但是如果因为对敏捷应用的不成功，就觉得敏捷不好用，并怀疑它的价值，不可取哈。
另外敏捷只是解决问题的一种方式，也不要把它捧得太高。
任何方法或者工具都有它所适用的上下文。
我认为敏捷是解决问题的一种方式，技术越来越多成为变现的一种手段。那当然你会问谁先行呢？思维观念要变，同时也需要给搭配上不同的手段，谁先谁后并不是主要矛盾。— DXcon
敏捷的价值观
摘自<说透敏捷>
- 个体和交互胜过过程和工具。
- 可以工作的软件胜过面面俱到的文档。
- 客户合作胜过合同谈判。
- 响应变化胜过遵循计划。
- 虽然右项有价值，但我们更重视左项。
一个公司或者团队要应用敏捷，不代表要全套接收，有可能只需要敏捷里的某块就可以，不信谣不传谣。
真正的敏捷应该是Be Agile而不是Do Agile。在我们强调/争执xx方法论，xx实践的时候，我们往往在做敏捷，而不是真正的敏捷了。
多说一句
团队，除了学会传统”规划、组织、领导、控制 “的管理方式之外，还需要”激励、授权、支持、交流 “，这实际上意味着，领导者(特别是CEO)把资源分配采取分布式，而不是集中制(集中在自己手里)。这对团队/组织/公司，在应对复杂、即时、阶层式问题时的灵活度、适应度增加很多。
本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。