大家对这种比较“重度”的敏捷形式不感冒？。。

我想原因是现有的管理模式下，很难实践的缘故吧

况且，根据我的实践，还需要和TDD，铅笔草稿纸设计，任务卡等形式结合才能发挥最大作用。。

不好意思，让你见笑了。开圈子的时候正好赶上公司入职，公司离家比较远，又比较忙，就没怎么来得及管理圈子。不过猫咪决定在端午节这几天里多发点文章上来。
不过我觉得结对不是敏捷的专利。瀑布模型里有可以很好的使用。我觉得结对的最大压力在于公司管理层对这种开发方式的效率的怀疑。结对节约的时间很多是隐形的。是用高质量代码消灭了抓BUG的时间。而很多公司对抓BUG这个时间是不怎么考虑的（赶快完成，糊弄客户给钱就好）。所以就觉得很浪费时间。

“我觉得结对的最大压力在于公司管理层对这种开发方式的效率的怀疑。结对节约的时间很多是隐形的。是用高质量代码消灭了抓BUG的时间。而很多公司对抓BUG这个时间是不怎么考虑的（赶快完成，糊弄客户给钱就好）。所以就觉得很浪费时间”，猫咪好，你说的也正是我在想的，其实公司仔细计算每个BUG要花多少资源是可以计算出来的，想想从用户开始发现BUG，到BUG的周转到最后的修补花的人力会超过一个人的工时的，更糟糕的是BUG给产品带来的阴影，那可是致命的 。。。所以在开放时就多个眼睛多看看是会有好的效果的。。。