【51CTO专稿】互联网时代的应用开发讲究快速迭代，就算没有一天发布个三版，怎么说也得两天发一版才好意思出门跟人打招呼。而移动应用发布的周期，一般也在一个月以内。
在开源领域，现在Chrome、Firefox等项目基本都保持六周一个新版本，管他功能实现完了没，先上了再说。几个著名的Linux发行版本，则保持六个月一版的发布周期，但是测试版的周期也都维持在一个月的长度。另外，大部分成熟的开源项目都有Nightly Build，即一天一个新版本。
这里面的区别当然也很容易看出来，互联网应用不用下载，用户上去就能用，改动越频繁、每次的改动越小，则越容易收集反馈，对产品更有利；而像是操作系统这种大块头，下载一个镜像就要几个小时，安装升级再几个小时，肯定不能让用户频繁的折腾。
不过无论是哪种产品，业内当前对“应用交付”这方面已经有了统一的观点，那就是无论你什么时候去看产品开发的最新进展，它都应该是可用的，最好能处在一个可随时上线的状态。
笔者上个月在百度开发者大会上遇到了百度高级架构师路宁（@路宁同学），跟其他几位开发者一起聊了一些敏捷开发和持续交付方面的话题。感觉在互联网行业，敏捷开发理念的进展、持续交付的状态的确比两年前的企业级开发领域要好很多了，但也有很多不尽如人意的无奈。
“一开始接触敏捷开发的开发者，都很不习惯那种每天工作透明化的状态，压力很大。”
“我的团队都是些新手，只有一年经验的或者完全就是毕业生的，上来让他们做预估，基本都是不准。一个功能预估做两天，结果做了一周，经常都是这样。”
“好不容易这个人成长起来了吧，别的企业待遇稍微好点就把人挖走了。而领导也不会太多考虑你的难处，只想用廉价劳动力，就再招新人进来，如此反复……”
这些无奈的声音来自一位从业六年的开发者。王先生现在在一家电子政务方面的企业做产品研发经理，负责整个研发团队的工作与培养。
“有些小孩进来吧，你也不能说他不努力，但总感觉心不甘情不愿的。”王先生讲到自己的工作时，说到自己曾经有段时间每天工作18个小时，吃饭什么的全抛掉，只有2、3个小时用来睡觉。当然，他也表示不打算再这样拼命了。“我们给毕业生的待遇也不算高，而敏捷开发的那种透明，虽然能够让他们快速成长，但确实造成很大的压力。”
敏捷开发的理想状态，是一个团队在项目进行过程中能够不断成长，对项目越来越熟练；每次项目都是一次练兵，而团队的整体能力则会越来越强，在敏捷开发的流程当中也会带来越来越高的生产效率。然而，理想是丰满的，现实是骨干的。对于国内的大多数技术团队而言，不稳定可以说是一种常态。老板希望找廉价的工作力，还要进来就能用，进来的新人无论在能力还是忠诚度方面都不能尽如人意，在这种环境下想要做到准确的预估工时，想要让他们坚持透明化的运作，是非常困难的事情。
最终，还是团队的人员质量决定了持续交付的效率和质量。
一方面是团队的参与者。“现在我招聘的时候，都会非常看中这个程序员的心态是否开放。他如果是那种特别以自我为中心的，听不进别人的意见，也不愿意沟通的，这种我就会比较担心一些。”路宁介绍说他自己带过一些团队，有的人就很不愿意做Pair Swapping，因为不愿意让别人看到自己的工作进度，这样的话就比较难展开。所以，开放的心态是非常重要的。
另一方面，团队的管理者也很重要。路宁表示有的管理者会滥用敏捷开发流程当中的透明性，反而对团队的发展不利。“比如，透明化之前的工作可能有张有弛的，这对于开发者来说是一种常态；但透明之后管理者可能看到，你原来这么快就把这个功能做完了，那我要给你加量，反而使得开发者无法得到充分的喘息。”
对于敏捷开发团队的规模，路宁也提供了一些建议。一般敏捷团队从6、7、8、9个人到20个人都是可以的，不过也有的团队到10个人之后就搞不到一起去了。一般来说，6～12个人的团队来完成持续交付会比较理想。