基本上只要一说敏捷就会提到两个东西，一个是上次说到的用户故事，一个就是Scrum，似乎做了这两个就敏捷，然而几乎都是形式上的敏捷，而从Knowing Agile到Being Agile实际上还有很大的距离。
当你大学才毕业的时候简历上往往有这样一句精通word/excel，然而过了几年你才会理解word/excel要精通得多难，而这仅仅还只是一个工具，不是一个方法学甚至是一种思维方式。
在行业中介绍Scrum的资料很多，基本都是围绕3355来谈的，当然本来确实Scrum就是个很轻量级的框架，当然面对更大的团队自然也有更大的框架。
在面对当前世界的变化，使用迭代的模式是能够快速调整目标适应的，Scrum提供了基本的3个角色、3个工件、5个事件、5个价值观来归纳。而Refinement和Planning是比较容易混淆的。
在大多数情况下Planning事件包含了需求澄清及迭代排期两个关键任务，但是如果每次要在具体排期前才开始梳理需求，那么在时间和准确性上会有影响，而期待完全把梳理需求的过程自由到迭代中的随时，也有一点理想的成分，所以如果出现Planning时间长或者估算不准确的情况，就可以回归到两个会议Refinement和Planning，各自关注不同的重点。
Refinement是需求的澄清梳理，基于团队或者公司的DOD完成定义，对下个迭代的主要故事进行澄清，作为测试在这个过程中关注验收标准的各个场景覆盖情况，完成ATDD面向验收标准的测试驱动用例，并且与团队共同评估故事的Storypoint点数，来评估完成故事的复杂度。
而在Planning中，由于大多数故事已经进行了梳理，那么就可以直接根据故事的Storypoint估算具体完成所需要的事件，如果团队稳定，就可以根据历史直接换算StoryPoint与WorkPoint之间的关系，然后根据Sprint的Capacity进行填充。而在Planning中需要注意的是故事的大小以及故事达标的概念，对于一个故事是完成了测试才能算完成的，所以在大多数企业中的开发敏捷测试瀑布是错误的，而导致的原因表面上是测试人员能力不够，更多其实是质量意识或者测试环境治理的能力问题。让开发与测试并行，确保每一个故事的高质量，以持续集成为基础，在Review会议中使用系统测试环境作为演示基础，确保迭代完成后的故事几乎可以随时上线。而如果遇到更大的多个团队协作发布，还需要考虑更高层次的需求验收，而这点在大多数团队中都是忽略的。
其实敏捷从来没说不考虑质量，而只是在我们大多数落地的时候总是没有把质量这个概念放在合适的位置，总考虑先做出来，看起来很快然而后续的隐形成本却被忽略了，最终导致有干不完的活，当然有时候我们也就是为了有干不完的活而刻意做了某些事情
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/350425.html
