面对慢慢流于形式的敏捷实践，该怎么办？
在某些情况下，敏捷实践不能够坚持而流于形式。作为项目管理者，需要做的不是强行用行政手段强推实践，也不是放任自流，而应该做的分析这个实践所期待发挥的价值，采取正确的策略应对。
以当前团队中对于验收条件的态度变化为例。
在实践验收条件几个月之后，从各方的反馈来看，似乎验收条件不被重视：
- 对于开发人员来说，因为有详细的设计文档，大部分详细信息都在设计文档中体现，他们倾向于看文档一步一步完成，而不是通过验收条件找具体设计；
- 对于测试人员来说，也因为有详细的设计文档，所有测试用例都在设计文档的帮助下完成，最终的测试脚本就是所有测试用例，而不是按照验收条件的顺序；
- 对于分析人员来说，因为开发和测试人员对于验收条件的漠然，对于书写验收条件的工作开始变得倦怠，验收条件质量下降，形成恶性循环，开发测试人员越不重视，分析人员越怠慢，验收条件质量越差，开发测试人员越不重视，最终的结果一定是流于形式；
这种恶性循环是各种实践（不限于敏捷实践）最后流于形式的定式。当一种实践需要一个工作环来执行，而纵观工作环上的每个角色都没有一人体会到这种实践的直接价值时，这项实践必然在某天被流于形式。发生这种情况一般有两种原因：
- 实践的价值隐藏得很深，在工作环之外或者工作环之内；
- 实践的价值根本不存在，或者期待的价值已经被其他实践替代；
那么通过分析发生这种情况的原因，制定的策略必然相异：
- 发现这种价值，让工作环上的人认同这种价值，使得实践持续；
- 验证是否存在价值，大胆舍弃，或者发现相同价值在其他实践上的体现，合理简化或调整；
简单来说，我们要做的是定位这个实践所预期达到的价值在哪里？在工作环之内、之外？或者在其他实践上？还是根本不存在？然后再制定相应的实践，改进这个实践。
我们首先思考一下验收条件期待被达到的价值：
- 明确用户故事的范围；
- 与客户达成业务价值的一致，这个用户故事能够完成什么样的业务价值；
- 在后期的验证反馈中成为一个可用的脚步用于演示；
- 作为可进行进一步拆分的框架，帮助测试人员书写测试用例和帮助开发人员分解实现任务；
我们可以简化成为几个方面：范围确定工具；达成一致的工具；验证的脚本；帮助书写用例和编码的工具。
接下来，我们要分析的是，在我们的实践里，这几个方面的价值被体现在哪里？
范围确定工具：客户通常按照需求的设计文档进行确认，在设计文档中明确了需求的各个业务场景下的相关功能点，验收条件基本根据这些功能点进行拆分和书写，实际上确定需求范围的价值在设计文档中包含，只是没有抽取出；
与客户达成一致：与客户达成一致的手段是设计文档的验收而不是验收条件；
验证的脚本：编码完成后程序员被把验收条件作为演示脚本向分析人员进行演示，做转侧前的第一次验证，由于分析人员都来自于开发背景，这种演示慢慢成为了实现级别，例如查看库表中是否更新了字段，某个请求是否被发送，而非业务层面；
帮助书写用例和编码：对书写用例来说，有些测试人员会根据验收条件的框架逐步细化编写用例，原因是之前验收条件的编写都是和分析人员一起完成的，这样的工作效率高，但是因为分析人员对验收条件的重视程度不高，导致不是所有验收条件都是和测试人员一起写的，这样，部分测试人员还是根据设计文档写用例，这一部分价值正在趋向减少；对编码来说，设计文档中的细节较多，开发人员不肯改变工作习惯，依旧按照设计文档进行编码；
从以上的分析我们不难看出，因为种种原因，验收条件的价值被交付团队感知的极少，唯一产生的价值——对测试人员的帮助也因为分析人员的不重视而慢慢消退。当我们弄清楚一种实践的价值到底在哪之后，便可以着手思考应对的执行策略。
根据讨论，我们对于验收条件中被设计文档覆盖的价值，抽取出去并强化，不在验收条件的实践中体现；对于验收条件更能够方便产生的价值进行强化。可能存在的具体改进动作有以下：
设计文档作为确定范围和与客户达成一致的工具，在每个需求设计文档中强化业务场景和相关功能点的验收范围，简化每个用户故事中的验收条件；
由测试人员和分析人员一起编写粗粒度的测试用例框架，作为转测前开发人员演示的脚本，以及帮助测试人员书写更详细测试用例；
仔细分析我们不难发现，当实践A（验收条件）的某些价值被另外一个实践B（设计文档）部分覆盖时，我们倾向于使用那个实践B（通常是旧实践），而渐渐忽略实践A中那些小部分不能被实践B覆盖的价值，实践A就会被流于形式。解决的办法是清晰地划分出实践A和实践B的界限，让它们相互独立，实践就会被坚持下去。敏捷中持续改进思想的重要一环便体现在一段时间内反馈一项实践的执行情况，让那些流于形式的实践无以遁形。