需求拆分。需求拆分是一个基础实践，没有该实践，后续的很多实践就无从谈起或者效果会打很大的折扣。在Scrum指南中也有指出product backlog是逐步细化并且是持续的过程。

拆分在此作为一个基础实践在很大程度上是可以影响scrum团队每迭代交付能力的。比如现实中经常遇到的一个问题就是团队说需求没办法拆分。尤其是To B行业的需求或者平台类的需求更是如此，比较大的需求粒度会对于后续的实践比如估算造成影响，粒度越大对于估算准确性的影响越大，较大的粒度还会影响透明，因为一个需求level的卡片会长时间保持一个状态，更大的粒度甚至能影响是跨迭代交付还是在一次迭代内交付。想象一下，极端情况下如果在一个Sprint里面只有一个US，那么跟瀑布的区别有多大？拆分才能更好的排列优先级，比如一个登录功能，只有拆分了，我们才能知道先做的是手机号验证登录、邮箱登录还是微信一键登录。否则优先级无从谈起；拆分才能帮助渐进明晰，产品可以细化最高优先级的需求，可以更快的交付价值得到反馈，从而调整后续的需求设计和优先级；拆分才能按价值交付，而不是迭代结束非零即一，比如搜索功能，可以拆分成按照ID搜索、按照关键字搜索、模糊搜索、根据搜索结果智能推荐等，拆分了在迭代结束可能交付前三个可用功能，而不会功能都处于待开发不可用状态。作为一个实践，需要注意的是拆分的方式，不能为了拆而拆分，比如按照组件切片，正确的方式在用户故事的相关书籍和资料中有诸多描述，不再赘述。

持续集成。持续集成也是技术实践中非常基础的一个。严格来说持续集成并不是跟敏捷绑定的实践，也不是一个新的概念。在诺记工作的时候，公司里的CI做的比较成熟，从代码提交、分支管理、静态检查、单元测试、系统测试、冒烟测试直到硬件测试，已经做的比较完善。一度我以为这就是工作的常态，从诺记出来才发现跟敏捷一样，有好多好多的团队和工程师只是用这么一个名词，甚至是互联网企业也是，依然没有持续集成，而这正阻碍团队在每迭代的交付。只有实施了持续集成，才能将PDCA的周期降的足够短，也就是小时和分钟级。敏捷也好，甚至只是为了缩短交付周期，没有持续集成将会是非常困难的一件事儿。持续集成实际上是把人与人之间的集成变成了人与机器集成，或者是代码与代码的集成，随着疫情的发展，跨地理位置和时区的协作越来越是常态，那么持续集成更是变得重要。不同的工程师、不同的组件、不同的模块，随时可以集成到同一个分支，并且迅速得到反馈。好的持续集成可以帮助团队及早甚至随时处于可交付状态，而不是“我的工作做完了，但是....”的情况。

UT。如果说前两个实践是没有多少争议的，充其量是做的好一些差一些，那么UT却是一个理论上多数人认可，但是实践上千差万别的一个实践。UT代表了很多工作方式的改变，比如测试左移、比如开发工程师保证质量而不是专职的测试人员、比如测试驱动开发（并不总是如此），道理或多或少大家能接受，但是真实的工作中，能把UT做好的，却是相对较少。原因有这么几个，一是不会，或者说不熟悉。以往的工作中大家都没有先写UT的习惯，上来就是撸代码，质量好坏看测试人员的。改为UT以后需要学习UT怎么去写，如果先写代码后写UT，由于代码没有考虑可测试性，往往会遇到各种障碍，难度和所需时间都比较多，开发人员很容易退缩；如果先写UT后写代码，跟原来的工作习惯差别很大，需要先考虑清楚要实现的功能，在没有一定自驱力的情况下，不太容易做这个改变。还有一个场景是UT并没有抓住多少bug，但是投入却比较大。极限编程的拥趸者认为写UT不会增加整体的开发时间，但是大部分人做不到，写UT确实增加了他们的开发时间。在诺记UT覆盖率非常高，但是抓取bug的比例并不高，尤其是跟系统测试比较，所以对于UT的争议始终存在。但是后来起码与我自己的理解是UT是重构的基础，是集体代码所有制的基础，是持续集成的基础，没有UT，频繁重构就不是很现实，因为回归测试就无法保证，没有UT，也就没有办法保证现有的代码不被其他人新写的代码破坏掉，所以UT的必要性还是有的。还有种场景是有的组织中业务不明朗，希望糙快猛的上线功能去试错，等稳定下来再谈UT，建议是核心代码加上UT保护。回到本文的主题，有了足够覆盖率的UT，可以持续的保持并改进每迭代的交付能力，因为UT对于新功能的扩展和更频繁的代码提交提供了回归测试和保护。