1.开发负责代码编写，dev环境发布和测试；beta则需要提转测申请，由测试把关，发布。IDC则更甚。
2.开发负责代码编写，dev环境发布和测试；beta开发也可以发布，IDC也是有开发控制发布节奏。测试介入beta环境，IDC测试用例
上面两种哪种更为敏捷呢？最近的经验告诉我，答案是1. 因为职责的分明，有了强烈的版本节奏感。在一个需要快速迭代的web服务项目，版本节奏非常重要！！做过的话，你就懂的。
方案2，相对于方案1，则更适合项目起步，快速发展期。(因为在方案1中，鉴于国情，测试经常资源不够，测试mm过于固执非要改xx地方。。。)
两种方案的敏捷区别，并不在于开发人员本身的代码素质。更多要求的是开发对业务的全面理解和对测试的理解。
3.DO分离，就是开发负责写代码，运维人员负责IDC机器的一切，开发人员不应该上IDC机器。
但是是不是敏捷了呢？
以前上IDC看日志文件，现在需要做模块，抓日志下来看。。。
以前开发可以上IDC top/free, 监控代码表现，现在只能YY。。。
以前可以上DB机，查看分表数据是否均衡，磁盘容量和占用比，现在只能听天由命，或者找运营的沟通，提需求，周期则从2分钟变成1D。
那么这么不敏捷的流程，为什么会执行？？就像现在的互联网服务一样，单点扩容的代价是高昂的，需要分区容忍性， 适当的单机效率降低，换取便捷的扩充性。从质量管理上看，非常合理，容易保证测试环境和IDC环境，控制代码风险，事故责任容易划分。