敏捷宣言

1. 个体和互动 高于 流程和工具

惯性和本能让我们依附于某个具体流程带来的虚假的安全感。遇到问题，先选择与团队沟通，永远避免搞一个流程出来以防止某种情况的发生。这种害怕出错的担忧和恐惧，是阻碍我们把“人”放在第一位考虑的一个重要原因。

按照流程不出错的执行，并不能够带来产品的成功，在敏捷开发中，使开发过程中每个工程师的理解达成一致，快速反馈，快速调整，激发个体的能量，参与到过程中来把产品开发做好。而不是仅仅成为软件开发过程中的一个“环节”。

在Scrum中，我们通过Daily Scrum来促进团队的信息同步，通过开放式办公环境的渗透式沟通来促进团队协作。

举例：在近几年的敏捷实践中，我们始终坚持着Daily Scrum每天同一时间在看板前开的形式。2020年初疫情最严重的一段时间，大家不能聚集，站会变成了线上的形式，大家打开工具，连着语音轮流发言。尽管线上的站会也起到了一定的沟通的作用，看起来使用了更高级的工具，事实上削弱了人与人之间面对面的这种感知和链接。尽管Scrum Master引导站会也想了一些办法，很遗憾，效果并不是那么理想。在疫情缓解之后，我们就恢复了面对面的站会形式。对于跨区域的团队，可能线上的站会也是一种更好选择，对于每天能够面对面沟通的团队，在面对面的时间里，个体和互动会更有效。

2. 工作的软件 高于 详尽的文档

遵守流程不等于成功，详尽的文档同样，带来的仍然是虚假的安全感。在敏捷开发中，更重要的是带给最终用户的体验，端到端的产品交付，快速上线，快速收集反馈，快速调整的能力。这是能给我们带来价值的部分，需要通过频繁的发布可工作的软件实现，文档有作用，文档的作用是有限的。

在Scrum中，我们在每个Sprint结束发布产品增量，并邀请Product Owner评审。

举例：2019年初，我发起了一个维护测试数据的产品，并且成为这个产品的PO。因为公司有统一的授权登录系统，我们的产品必须要与这个系统对接，找到联系人，联系人扔给了我们几个Confluence的链接，让我们自己去研究，真是苦不堪言。文档再详尽，也有它的局限性。本身对接的这个授权登录系统非常复杂，写在文档里各种情况各种分支更是云里雾里的，最后还是要找人问。之前想着写了详尽的文档，可以节省对接的工作量，殊不知把所有人都绕晕还是要口述解答。通过与联系人不厌其烦的沟通，厚着脸皮反复打电话，很快就把系统对接好了，完成了上线。我们也没有为这篇已经看不懂的Confluence贡献任何的文字。

在做这个产品的过程中，还有一个体会，让用户对着使用手册使用产品，不如把系统做的更好理解，让用户看到就自然知道怎么操作。这样既省去了写文档，又降低用户使用的门槛，也有机会获得更多的用户。所以我们在讨论一个新业务的时候，会花很多时间讨论用户怎样去使用，事实证明，这些讨论是值得的。

3. 客户合作 高于 合同谈判

关于“以客户为中心”这句话，基本上成为每个公司的理念和主张。但这句话却很少实现，在软件行业更是如此。过去很多看，IT资源有限，能够做成系统就不错了，根本不考虑用户的使用感受。不论多么笨重、不好用，用户都不得不为此买单。如今，互联网资源丰富，开发成本降低，用户有足够的话语权选择自己真正想要的东西，因此，产品开发的过程，是理解和解决真实用户的真实问题的过程。

在Scrum中，我们在每个Sprint结束发布产品增量，收集用户反馈，不断的迭代产品功能，形成与用户共创产品的机制。

举例：还是关于测试数据的这个产品例子。一个负责测试管理的同事，想在我们的平台上发一条公告。这本是很简单的一个诉求，我就编辑了一段文字发布上去，然后给她看。接着，得到了反馈：某某句话能不能突出一下，换个颜色显示更突出。我按照她的需求改了，又给她看，她又说：这句话我希望......我又按照她的需求改了。只是一个小小的公告，来来回回改了好几次。这让我很感慨，我们和客户之间，是存在GAP的，通过合作，快速的获取反馈并且快速的迭代产品，才有可能达到双方的共赢。一个小小的公告尚且如何，更何况更加复杂的系统功能呢。

4. 响应变化 高于 遵循计划

在VUCA的时代，唯一不变的就是变化。当外部环境已经发生变化，遵循计划的意义就不那么大了。相比遵循计划的能力，更重要的是随时计划随时行动的能力，也就是对外部变化作出反应。

在Scrum中，每个Sprint定义Sprint Goal，并随时回看Product Goal，在Sprint Review中随时检视和调整。不断提升团队响应变化的能力。

举例：在我们的产品开发中，最常见的情况是紧急突发的更重要的要做的事，然后根据正在进行的用户故事迅速调整。比如上级部门在进行某个低层业务的迁移，需要我们配合测试，需要首先进行测试数据的对接。为了不影响测试进度，把测试数据平台的其他开发工作延后，首先进行测试数据对接，以保证测试进度。快速的对接，不一定是一个完美的版本，先把业务打通，再去完善细节。类似的情况还有很多，保持小团队随时能够应对变化的能力，是一种核心竞争力。

敏捷开发十二原则

1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

在每个Sprint结束发布产品增量，收集用户反馈。

我的做法：两周一个Sprint，在Sprint中开发完成符合DoD的经PO确认立即上线。上线后发给最需要该功能的同事体验收集反馈，再嘱咐通过IM推送给其他同事。（内部产品，同事即用户）

2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

对于优先级较高的PBI，优先在Sprint的中处理。极端情况下，需要调整当前Sprint的Backlog Item。

我的做法：业务部门找到我，他们在被一个测试搞得痛苦不堪，手工测试用例上万条，日程已经排到了明年三月份，问我们团队有没有办法解决。了解了他们的需求多之后，发现可以对他的上万条用例批处理，只要他准备好测试数据和期望结果，一分钟就能出结果。业务部门急得火烧眉毛，我们还有几天结束迭代。和团队商量，先把前后端设计做起来，下个迭代再进入开发。所以在最后几天我们和业务部门明确了需求和开发细节，界面交互等，又用了两天时间完成了开发和交付，用户满意。

3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

Sprint 1-4周，越短的周期，越快的上线，能够及早的得到反馈。周期越短越好。

我的做法：两周一个Sprint，在Sprint中开发完成符合DoD的经PO确认立即上线。开始的时候，我们也是两周Sprint结束之后再在下一个Sprint一起上线，实践了一段时间，我们会在上线过程中投入很多。后来我提出了这个想法，开发完成就上线，大家都愿意试试，经过一段时间的试验，大家都适应了这种方式，不再有繁重的集中上线，大家可以更灵活自主的安排工作，上线压力也减小，所以在我们团队就一直延用了这个方式。

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

通过Daily Scrum每天沟通，在Sprint中能够随时能够找到PO。

我的做法：在刚做产品的时候，出现过几次这样的情况，在Planning的时候谈请楚了需求，前端开发在画界面的时候没有找人确认，结果对接后端做完了，完全不是我想要的功能，只好重做。发生过几次之后，开发同学终于把这个习惯改过来了，随时随地的找PO确认和讨论需求，就没在这个事情上面再出过问题。这也给了我一个提示：我们自以为是的那个沟通频率，通常都是不够的。

5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

在Scrum Master的协助下建立自组织团队。

我的做法：我们的团队建立的时候，刚好是团队共同经历过一段痛苦的低谷期。大家心里都憋着一股劲儿想做些事情，因此心特别齐，目标一致，也特别有干劲。第一个Release上线的时候，我们没有什么经验，为了扩大业务范围拉更多的人入伙，第二天要演示，我们就一边弹着UKULELE一边修着BUG，直到10点多在生产环境发出了第一张测试卡片。团队基础好，所以在工作很多事情就简单了很多，大部分精力集中在做事。后来团队发生了变动，一半的人离开，又有新加入的同事，新的团队又开始了重新磨合，大家参加这个产品开发的目的并不一致，就给Scrum Master带来了一些挑战，也影响了开发效率。在这个过程中，还是克制了自己去干预具体的事，给新人更多的空间，多倾听他们的问题和困难，在彼此之间搭建桥梁。经过一段时间的磨合，新人对团队的归属感增强了，整个团队的氛围和交付能力又上来了。

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

Daily Scrum，每天，同一时间同一地点面对面。

我的做法：在团队中出现问题需要讨论，虽然我们有IM随时沟通，仍然会召唤大家见面。在群里约定大家都合适的时间，通常不太复杂的问题，讨论一下就能解决了，并且能够确定大家都达成了一致。线上很多情况下都是各说各的，或者是有人有不同意见又懒得打字，就不表达了。

7. 可工作的软件是进度的首要度量标准。

每个Sprint发布产品增量。

我的做法：从第一个迭代起就把发布上线作为完成标准。一直坚持不会把一个用户故事拆成一半一开发一半测试。开始的时候，我们每个迭代上线一次，后来改成用户故事开发完成PO确认直接上线，团队也很适应和喜欢这样的节奏。避免了很大的上线带来的各种风险和问题。

8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

Sprint是Scrum的心跳，保持节奏，但不是机械执行。

我的做法：2019年我把自己摆上了PO的位置发起关于测试数据的产品至今两年多了，两年间只要是工作日Sprint和Release就一直在持续，始终保持两周一个Sprint的节奏。这个团队开始建立的时候，我们在一个团队，大家共同的部分很多，很多时候因为产品的一个交互争论半天都是常有的事，目标一致，就是为了做一个真正的产品而不是工具平台。后来，因为组织架构调整，一部分同事独立出去，他们自己选择退出了这个项目。再后来，又有同事离职，也有同事因为种种原因加入进来。作为一个团队，我们尽力去磨合团队保持发布节奏，当然因此带来的问题和思考又是另一个话题了。

9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

产品不断的迭代，代码重构的能力。

我的做法：刚做产品的最初，团队对重构这件事还很陌生。在持续的迭代中，大家更理解倾听用户的声音的意义，同时影响到周围的人。有一个小故事，我印象很深。为了解决我们自己造续转卡测试数据的问题，我们把需要手工操作的部分实现了，只需要用户在前端点几下鼠标就能够实现。麻烦的是，后续的流程要送到总行系统跑批，但总行并没有意愿配合我们改造。于是，我们想了一个妥协的办法，把生成的档打包提供下载供能，再在页面上提示去找总行XXX手工操作。这个功能上线之后，变成了一个非常HOT的业务，总行XXX每天要接收到N多要操作的数据，最后撑不住了，主动联系我们，最终把他后续需要手工操作的部分也都在平台中实现了。他解放了，我们的业务也更顺畅了。在这个过程中，我们的同事始终保持着开放的态度，并且以最快的速度响应和对接，我想，这也是一种敏捷能力吧。

10. 以简洁为本，它是极力减少不必要工作量的艺术。

用最简洁的方法实现最简单的功能。尽能发布简单和少的东西，而不是花很长的时间，做很复杂的，大而全的东西。

我的做法：接到一个复杂的业务，和团队一起找到Walking Skeleton，然后先做出来，上线，听听用户怎么想，再考虑下一步行动。我们团队之前想了一个数据池的功能，想放在产品里推给用户用，但又不知道用户喜欢自己造数据还是喜欢直接从数据池里领取数据，于是只做了一个基本的数据类型，只有一个领取按钮，没想到一下子访问量就上去了，然后我们才继续迭代把功能做得更丰富，满足用户更复杂的需求。

11. 最好的架构、需求和设计出自自组织团队。

构建自组织团队，团队是好的产品开发的基础。

我的做法：在我们的团队中，关于产品的所有的架构和需求都是经过团队的讨论和确认。因为是内部的产品，相对来说障碍要小很多，团队环境也相对宽松。在需求讨论等会议中，我在引导时会多给那些不太爱表达的人更多的机会，多问问他们的相法，而不是意见领袖的一言堂。涉及的到架构和技术细节，团队中有技术相对优秀的人会提出意见，大部分情况我们会基于这个意见讨论，在讨论的过程中确保大家达成一致理解，有时候也会有不同的意见出现，或者推翻最初的想法找到更好的，最终以大家都明确和认可的结论为准。另一方面，在团队建设的最初，就建立这样环境，能够帮助大家更快的磨合。比如在有新的团队成员加入时，他们会抱怨有些用户故事不太清楚，或是因为技术上没想明白，所以不敢领任务。这时候我们就把之间老的成员可能默认的都知道了的一些东西，又拿出来与整个团队对齐，经过一段时间，团队新老成员之间的GAP就弥合了。

12. 团队定期地反思如何能提高成效，并依此调整自身的行为表现。

通过Retrospective在每个Sprint的结束反思和回顾。作为Scrum Master，根据团队的状态和实际情况设计回顾会的形式，激发大家参与和深入的讨论。

我的做法：目前团队采用两周一个Sprint，每两周Retrospective回顾。比较多的采用ORID的方式引导团队成员表达迭代的真实情况和感受，识别出具体的可改进的Action。为了避免形式主义，回顾会上我们仅选出大家认为最需要解决的问题，以及最需要去调整的行动。对于大家都认可并且同意去调整的，一般都能够得到比较好的改善。这里还有一个关键的点，是对“好”的定义。在我们的环境中，很容易把标准和要求认为是“好”，而忽略团队自己的认知和感受，作为Scrum Master在引导团队过程中，尽量帮助团队松绑，从感受出发倾听彼此内心真实的声音。