假敏捷与真敏捷

1. 假敏捷与真敏捷

一、什么是假敏捷和真敏捷？
  
 在变幻莫测的互联网环境下，快速的响应和发布是非常必要的，并且能得到ABtest的快速验证。
  
  1.假敏捷-7个团队各自为营 
                                          
 需求的产生来源就有一些问题，3月份在敏捷诊断的时候，几乎所有的产品都把最需要解决的问题投给了“产品定位”，当项目组的每个人对产品的理解不一致的时候，我们传达给用户的是将使一些非常矛盾的东西。举个例子，本来是一个服务于全球女性的APP，在一次商务的合作当中，商务的同学拉来的合作是“恐怖电影”。可想而知用户看到了这些启动页广告、banner大图的时候被惊吓的画面。
  
 同时，需求的产生是在每一条业务线中产生的；按照不同的业务线，产品、开发、测试被分成了7个团队，团队之间更多的是一些同步的工作，缺乏沟通和讨论。没有总体的共识，一个APP被分为7个团队，需求的产生比较分离，没有重点。
  
 在需求迭代的过程中，每个组只有一个开发和测试加入到需求讨论中，然后把会议精神带回团队；更多开发和测试的同学是直接按照PRD进行开发和测试的——团队缺乏沟通，对需求细节的把控没有那么到位。
  
 最后，在需求交付的时候，功能核对是在上线前1-2天。这会导致很多风险项都没有办法提前暴露，需求理解不一致的情况没有办法得到有效的处理。
  
  2.真迭代-两个团队试点，每周一个敏捷冲刺 
                                          
 敏捷项目启动初期，在面对一个需求从开始到落地的五个环节：“产品定位”-“用户定位”-“需求挖掘”-“需求开发”-“需求跟踪”时，几乎项目组所有核心人员都把最紧急、最缺失的一票投给了“产品定位”。
  
 我们发现，因为没有清晰的产品定位，所以每个人的着力点是不同的；大家像一盘散沙，看似忙碌充实却绵软无力。
  
 最致命的是：因为没有清晰的RoadMap，大家走一步算一步的状态影响团队士气和凝聚力。
  
 于是，产品团队利用将近一个月时间的依据公司战略、产品目标、用户需求和市场环境确定了清晰的产品定位“打造用户的专属摄影师”，以及根据产品定位确定了接下来1-2年的长期目标和近三个月的短期目标。同时，每条线也根据共同目标制定了版本迭代的计划。
  
 “计划的结果是无意义的，价值在与计划的过程本身”，在互联网瞬息万变的环境下，RoadMap肯定是会变的，但RoadMap能够让全项目成员做到“心中有数”，往同一个方向一起冲刺，这就是它最大的价值所在。
  
 在同一个产品目标下，我们把小组分为几个线，在产品内部共同讨论下形成了需求池。
  
 在需求迭代对过程中，我们也发生了一些改变。
  
 例如产品经理开始用用户故事去表达和拆解需求（用户故事会在接下来展开来说），基于用户故事，开发测试的同学参与到了需求细节的讨论中，逐步达成共识。
  
 在需求交付时，大家能够按照故事点做得点对点的每天交付，甚至为了迭代目标的达成，出现交叉开发、交叉测试的现象。
  
  3.Scrum Master是谁？ 
  
 在需求迭代和落地的过程中，敏捷引进了一个非常重要的角色“Scrum Master”（以下简称SM）；项目组渐渐弱化项目经理的角色，开始培养每一个团队的SM角色。
  
 SM是一个对产品迭代推进帮助特别大的人。
  
 目前跑下来在产品看来，SM可以帮忙解决这样几个问题：
  
  a.服务产品 ，确保每个团队成员都尽可能的理解目标和需求细节;
  
  b.服务开发 ，移除开发工作中的障碍，帮助开发梳理交付流程；
  
  c.服务组织 ，带领每一个迭代的进行并持续提升效率。
  
 SM和传统的项目经理最大的区别在于：驱动形式不同。
  
 项目经理是以任务范围驱动时间和资源成本，而SM则是要以时间去驱动任务范围，保证产品以一个节奏持续得往前走。
                                          
 在敏捷框架下，每周一个迭代是死的（这个死是相对的死，可以根据实际情况做调整）。
  
 每个团队都像赶火车一样在固定的时间点上车，如果没有赶上，把优先级高的需求先保证发布，这样就能保证我们总是在做有价值的事情。所以每一周，我们就是一个冲刺——时间点基本上是固定的，整个产品是有节奏的一步一步向前。
  
 二、用户故事的魔力？
  
 敏捷实施以来，产品这边最大的一个感受：需求思考和表达的维度从原本的流程图变为了用户故事。
  
 我们首先来看一下：用户故事解决了一个什么样的致命的问题。
  
 我们必须承认的是：文档并不等于共识。
  
 在敏捷的框架中有一个价值观——可交付的版本大于详尽的文档。文档写得再详尽，如果团队成员不够理解，在快速的迭代开发中会大大的影响效率和交付的质量。
  
 我们看这样一张图，当需求评审的时候，大家都说“我懂了”，但是在每个人心里，其实对需求的理解是不一致的；大家需要通过反复的沟通去保证，确保每个人心中对细节的把控大体一致，否则经常出现交付和产品的预想不一致。
  
 用户故事就是一个梳理需求的框架，它最大的价值是能在迭代开始之前，用这个框架让团队成员迅速对需求达成共识。
  
 用户故事到底是什么样的呢？
  
 就是： 一个角色，需要完成什么样的活动，最终达成什么样的目的。 
  
 例如，作为,我想要,以便我。
  
 用户故事是一个帮助产品和团队梳理需求的一个很好的框架，我们来看一个实例：
  
 左边是用“界面框图+跳转逻辑+逻辑细节”组成的需求，右边是用用户故事+界面框图表达的需求，我们会发现，左边的表达逻辑比较零碎，而右边结构清晰，考虑到所有的场景不会产生遗漏。
                                          
 用用户故事表达需求的时候，我们会发现用户故事的几个大优点：
  
 1. 测试和开发不一定有产品视角，但一定会有用户视角，用用户故事去梳理需求能够让大家对该需求的理解更加迅速、深入。
  
 2. 按照场景拆分，需求在整理把控和细节处理上更容易暴露出问题。
  
 3. 拆分之后，按照提供给用户的价值划分优先级，甚至帮助产品找到MVP。
  
 4. 按照用户故事做后期的迭代交付。
  
 三、敏捷中的团队精神？
  
 敏捷走了一个月的时候，我们开了一次总结会，回顾敏捷前、敏捷后、敏捷中你认为最大的变化。
  
  开发、测试的同学都在最大的变化的关键词几乎都写上了同一个词，那就是“参与感”——之前的需求评审的时候，产品和开发、测试有一种对立的感觉。 
  
 产品像是接受检阅，开发和测试像是被通知。这是一种很神奇的社会心理，当人拿出一个经过自己谨慎思考的方案的时候，其实是难以接受修改和质疑的。
  
 产品经理面对一个自以为很周全的需求的时候，实际上把需求框住了，把自己的思路和别人的思路一同框住。
  
 一旦别人提出一些质疑，会本能的抗拒——这是一种思维定势。
  
  需求应该是在团队的讨论下涌现得到的，这个团队不仅包括测试、开发，也包括团队里的任何一个角色。 
  
 产品把控方向，团队在讨论中不断得巩固和涌现细节。而且在讨论的过程中，我们经常会发现：开发和测试的同学也会有一些新奇的创意，其实他们渴望表达，渴望产品听到他们的意见；并且产品的方案如何落地，细节的部分开发、测试同学会更了解并提出宝贵的想法。
  
 非常感动的是：有一次一个需求delay了，其实我知道是因为产品在迭代的过程中对需求做了一些调整，但是那个开发在回顾的时候，并没有cue到产品，而是自己默默撑起了这口锅。
  
 当然我也做了自我的检讨，但是整个回顾会的过程就会让人觉得：大家是一个集体，没有人会默默甩锅给别人。
  
 四、敏捷给产品经理带来的成长？
  
 在敏捷的大框架之下，对产品经理有了更高的要求。
  
 不仅是对需求细节对把控能力，更是对整个产品方向和roadmap的把控能力都需要产品经理跟随敏捷的节奏一起成长。
  
 在这短短一个多月的时间里，非常有幸能够参与到敏捷中，同时我也切切实实的感受到了一些成长上的变化：
  
  1.在需求的不断拆分中重新思考需求的价值。 如何在有限的时间里做最有价值的事情，如果需求可以拆分，那么MVP是什么？我们在用户视角去拆分需求的时候，会重新定义MVP。
  
  2.用户故事， 强迫产品经理始终从用户视角和用户使用场景去思考需求的价值，这个思维转变非常重要。
  
  3.让产品经理从全局和细节对需求有更多的思考。 （1）全局的场景拆分（2）注重验收标准的细节，如果丢失重要的细节部分，产品经理需要背锅。
  
  4.团队沟通， 带团队的能力得到锻炼。让产品经理更参与到团队协作的方式中和团队文化建设的氛围中，我觉得为未来做一个管理的角色有铺垫作用。
  
 做任何改变都是需要付出一些代价的。例如产品的发版节奏被打乱，团队的工作方式方法被打乱，甚至会出现刚开始做敏捷时团队的产出效率变低，这都属于正常的“学习曲线”。经历过一番痛苦的挣扎，我相信在正确的使用敏捷后，团队中的每个人都能收获一定的成长，产品也能在这样的思路和框架下有更大的提升。

2. 谈敏捷之“伪敏捷”

 我们发现很多团队在做敏捷转型的时候热情高涨，学习了各种敏捷方法，工具，可是执行一段时间的敏捷以后会发现不是每个sprint都有可以demo 的进度，产品设计者并不会根据sprint的反馈澄清不清晰的需求，每个team的燃尽图都很漂亮，可是最后release却总是delay。
   之所以会造成这些问题的原因在于，你只是学习了敏捷的形而不是敏捷的神。以学武为例，只学了招式，却没有去学内功，到头来发现招式全会，可是真正要用的时候却发现一招也用不上，这时候你就会认为“武术不过是花架子，中看不中用“。
   推动敏捷常见的误区有：
   为了避免出现“伪敏捷”我们需要弄清楚什么是敏捷，接下来我会给大家介绍以下内容：
   在Ahmed Sidky启发下提出的模式将敏捷明确表述为一种思维模式，它由“敏捷宣言”的价值观所界定，受“敏捷12条原则”指导，并通过各种实践实现。
                                            敏捷宣言（价值观) ：
    敏捷12条原则 ：
   敏捷是是一种思维，是一套价值观和原则，而在这套思维下会有各种不同的具体实践，比如 Scrum，Kanban，LeSS等。 如果把敏捷看作膳食指南的话，那 Scrum，Kanban， LeSS则是具体的某一道菜。
   根据团队的大小，敏捷实践有如下几种：
                                           首先需要明确的一点是，敏捷是一种思维，我们并没有一个标准的方法用来衡量什么是敏捷。我们这里说的“伪敏捷”是指敏捷的实施上的“伪敏捷”。
   下图来自于美国国防部 （ US Department of Defence DoD），我们可以用它用来区别什么是一个成功的敏捷框架，什么是一个“伪敏捷”。
                                           某种程度上说，“伪敏捷“是一种浪费。
   虽然敏捷拥抱变化，不过一般一个迭代中确认的需求是尽量不变的。如果PO经常乱插入需求，毫不考虑已经排入迭代的计划，团队则需要花费大量的时间处理这些插入的需求，导致大量的工作无法如期进行。
   比如很紧的上线计划，导致计划会议的估点形同虚设，团队超负荷工作上线产品，导致产品质量很难保证，出现技术债，和返工。
   更典型的是，披着敏捷外衣的传统瀑布开发，比如print 0 用来设计，sprint 1 -3 用来开发， sprint 4 用来测试，这是违背敏捷第3条“经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。”
                                           我将从以下5个方面分析“伪敏捷” 和 “真敏捷” 的区别。
    a.  和客户的交流 
    b. 尽早交付有价值的内容 
    c. 责任感 
    d. 自动化流程 
    e.对于产品功能的重视程度 
   在正确使用敏捷中，我们可以借鉴日本剑道中的思想，那就是“守破离”，大概意思就和中国的武侠小说里面练剑的境界类似。
   守，就是要遵循既有的招式，一丝不苟地练习，“心中无剑，手中有剑”；
   破，就是要根据自己的情况，对招式中不合适的地方做局部的改善，做到“心中有剑，手中有剑”；
   离，当然就是最高的境界，从更高层次得到新的认识并总结，自创新招数另辟出新的境界。
   具体的落地方案将会在我后面的文章中提到。