经常听到很多敏捷实践者的问题：

什么才是真敏捷？

我们就是山寨敏捷，为什么不用TDD？

你持续集成了吗？

我们站立会议超过了30分钟，有关系吗？

Scrum就是一些管理实践，不用上TDD，持续集成这些技术实践，敏捷有啥用阿？

要不要结对阿？

问这些愚蠢的问题，就像问是不是用筷子吃饭，才叫真正的吃饭。而真正的问题是我饿了，我手抓羊肉，吃面包，喝水，甚至去打麻将，让我忘记饿的感觉，都是解决办法。

我写过这样一篇文章，《敏捷迷雾背后的本质》 ，关于这个，我还是想罗嗦几句。

把事情作对的方式很多，敏捷实践是其中的一种方式，它一方面带来了很多最佳实践，另一方面是一种新的思维方式。

关注问题，关注组织中的浪费，寻求方法进行改进。将敏捷实践看成做出这些改进，可以参考的集合。

如果一味的强调敏捷，就好像寻求银弹一样，在你还不清楚自己存在什么问题的时候，试图去寻找一个解决所有目前和预想未来可能存在问题的工具。

这，是不靠谱的。

敏捷只是一个代名词而已。

我们可以推演一下敏捷中的实践，它背后隐藏着的实际问题是什么。

1）站立式会议

这个主要是沟通问题，沟通永远不够。在固定的时间，固定的地点，交流固定的主题，就是为了沟通信息，从而事情的推进能够自然，紧凑的方式进行。

2)  编写测试

用什么方式保证你写的代码没问题。答案可能有很多，可以依赖功能测试，依赖Code Review，依赖你的细心。。。。，最终的目的，是使你的代码正确表达它的意思。如何验证它的正确？是“我觉得”，是“应该。。。”，靠主观是不能解决问题的。就像毒奶粉，靠用味觉品尝，靠用眼睛看，这些都不是能确定奶粉是否合格的方式。至于测试先行，还是测试后行，我觉得并不重要了，可以当作哲学问题来讨论，关键是最后你的测试，是否验证你的代码正确的表达了它的意图和逻辑。

3）团队计划会议

如果每个项目经理，都熟悉具体工作任务和优先级，没什么问题。如果不是这样，大部分项目经理独立做出来的计划，是拍脑袋的，包括任务划分和优先级都是欠合理的。 这时，就可以依赖团队的力量，一起做计划，将计划变得更加合理。只有开发人员自己才知道，具体细粒度的开发任务如何安排更加合理。

4) 看板

看板并不是敏捷实践独有的，我在以前的博客说过，越狱中，大家可以看到大量应用看板的实际例子。看板，解决的是公共信息沟通的问题。没有它，很多项目组成员公共的信息，需要通过很多点对点的沟通来弥补。沟通的效率会非常低。我们的群公告也可以起这个作用。

5)用户故事

为什么选择用户故事作为需求描述的一种方式呢？ 用户故事是从用户角度，给用户带来的价值角度来描述产品需求的。相比冗长的需求规格，这个是易于理解的。需求描述的最终目的，无非也是，在各个角色当中达成一致的理解。 如果一个功能实现的周期过长，就增加了很多不确定性，所以用户故事要求是小的，很容易实现的。这也就意味着，我在较短的时间内，就可以得到明确的结果。从价值流角度分析，用户故事粒度小，这些价值是持续交付的。 一个功能开发时间越长，在开发这段时间，价值是没有被交付的。

6）持续集成

如果说站立会议，保证team成员之间沟通无偏差。那么持续集成就保证，我们的系统，模块，始终能正确的沟通和表达。如果其中的问题发现的晚，就会导致解决问题的成本高。持续集成，就表明，我们想要的，一直都是OK。消灭问题与萌芽之中。

7）坐在一起

为什么要坐在一起？还是为了沟通，及时沟通，如果信息不一致，可能有同事基于错误的信息，做了错误的工作，白白浪费时间。作为信息民工，我们的工作的输入就是信息，如果输入信息delay（比如等邮件通知，等确认结果），那工作自然要delay，如果输入信息有误，自然会导致工作浪费。信息不仅仅是信息，它起的是控制作用。

这里我就列举了一些，其它的大家自己去思考吧。

总的来说，就是

1. 利用团队的力量来思考，来解决问题。

2. 强调端到端价值的交付 .

3. 强调信息沟通的及时性，一致性和准确性。

忘记敏捷，忘记agile，关注问题，关注细节，关注团队，勤思考，提高工作效率和软件质量的办法总是存在的。

把敏捷实践作为你的工具箱，它不是全部，它不了解你实际的问题，也不知道你将去向何方。

作为代名词，可以继续使用，但是它并不意味着什么，代表着任何你想给它的含义。