人家说，你们搞这贸贸然的就持续集成，不行的。
1、认清真正的敏捷通过学习和调研，认清什么是真正的敏捷。如果一些基本初始概念就错了，那么在后续的推行中必然会差之毫厘、谬之千里，真正的敏捷实施也就无从谈起。
2、预估推行敏捷的收益
在确认知道什么是真正敏捷的前提下，对自己团队、组织的现状、问题和薄弱环节进行评估，设定改进目标，并预估敏捷能否解决这些问题，带来潜在的改进。如果成功的把握小于 50%或者现状已经足够好，就不要推行敏捷，何必劳民伤财呢。
有意思啊。弄不清什么是“真正的敏捷”，“现状已经足够好”，就不需要改进了？就不要解决问题了？
怕啥呢？怕的就是这持续集成它是实打实的东西吧。怕的就是持续集成一上，所有的问题都以测试是红是绿这么截然的方式暴露出来，逼着不得不解决吧。怕的就是持续集成它没有放之四海而皆准的套话可以讲，build脚本得一点点写出来吧。怕的就是没人跟您玩“学习和调研”了吧。怕的就是“真正的敏捷实施”卖不掉了吧。
作为一个专门帮人解决问题的，我越来越频繁的说，我不在乎敏捷不敏捷。你告诉我，你有什么问题，咱们一起来看看怎么解决。可能一个项目做到最后你还是不搞敏捷，没关系，我解决你的问题提高你的效率就行。
ThoughtWorks是一个做实事的公司，所以我们认为每个项目应该做的第一件事就是让真正的软件开口说话，说出它有什么问题，然后我们来解决问题。难怪有人要怕呢。光顾着解决问题，那学习和调研基本初始概念的事可扔到哪儿去了呢？
怕是又动了谁的奶酪了吧。
