摘要： 想起我刚毕业后，进入一家以软件外包为主的外企做开发。它使用传统的瀑布式的软件开发流程，没有使用任何的敏捷实践。我每天上班打开电脑，拿到自己的任务，然后从版本控制更新代码，打开工程按下Build，准备进行今天的开发任务。突然发现Build失败（通常是编译不过），大喊一声“谁Break Build啦”，也没有人响应，自己一个人郁闷，接着查看是哪些文件导致编译失败，找到最后的提交人，让他去Fix Build。后来团队里如果某个人Break Build，其他某些团队成员就在MSN的签名上写着“XXX Break Build，今天要请客吃饭”等等。其实Build失败在软件开发过程中会经常出现，不同的程序员实现自己的模块，写单元测试，完成后提交代码，难免会造成冲突导致Build失败。但是对于开发者来说，应当能够最快的获得当前Build的反馈，如果该Build失败必须在最短的时间内修复它，以免它影响其他人的开发进度。 阅读全文