【51CTO專稿】互聯網時代的應用開發講究快速迭代，就算沒有一天發布個三版，怎么說也得兩天發一版才好意思出門跟人打招呼。而移動應用發布的周期，一般也在一個月以內。

在開源領域，現在Chrome、Firefox等項目基本都保持六周一個新版本，管他功能實現完了沒，先上了再說。幾個著名的Linux發行版本，則保持六個月一版的發布周期，但是測試版的周期也都維持在一個月的長度。另外，大部分成熟的開源項目都有Nightly Build，即一天一個新版本。

這里面的區別當然也很容易看出來，互聯網應用不用下載，用戶上去就能用，改動越頻繁、每次的改動越小，則越容易收集反饋，對產品更有利；而像是操作系統這種大塊頭，下載一個鏡像就要幾個小時，安裝升級再幾個小時，肯定不能讓用戶頻繁的折騰。

不過無論是哪種產品，業內當前對“應用交付”這方面已經有了統一的觀點，那就是無論你什么時候去看產品開發的***進展，它都應該是可用的，***能處在一個可隨時上線的狀態。

筆者上個月在百度開發者大會上遇到了百度高級架構師路寧（@路寧同學），跟其他幾位開發者一起聊了一些敏捷開發和持續交付方面的話題。感覺在互聯網行業，敏捷開發理念的進展、持續交付的狀態的確比兩年前的企業級開發領域要好很多了，但也有很多不盡如人意的無奈。

“一開始接觸敏捷開發的開發者，都很不習慣那種每天工作透明化的狀態，壓力很大。”

“我的團隊都是些新手，只有一年經驗的或者完全就是畢業生的，上來讓他們做預估，基本都是不準。一個功能預估做兩天，結果做了一周，經常都是這樣。”

“好不容易這個人成長起來了吧，別的企業待遇稍微好點就把人挖走了。而領導也不會太多考慮你的難處，只想用廉價勞動力，就再招新人進來，如此反復……”

這些無奈的聲音來自一位從業六年的開發者。王先生現在在一家電子政務方面的企業做產品研發經理，負責整個研發團隊的工作與培養。

“有些小孩進來吧，你也不能說他不努力，但總感覺心不甘情不愿的。”王先生講到自己的工作時，說到自己曾經有段時間每天工作18個小時，吃飯什么的全拋掉，只有2、3個小時用來睡覺。當然，他也表示不打算再這樣拼命了。“我們給畢業生的待遇也不算高，而敏捷開發的那種透明，雖然能夠讓他們快速成長，但確實造成很大的壓力。”

敏捷開發的理想狀態，是一個團隊在項目進行過程中能夠不斷成長，對項目越來越熟練；每次項目都是一次練兵，而團隊的整體能力則會越來越強，在敏捷開發的流程當中也會帶來越來越高的生產效率。然而，理想是豐滿的，現實是骨干的。對于國內的大多數技術團隊而言，不穩定可以說是一種常態。老板希望找廉價的工作力，還要進來就能用，進來的新人無論在能力還是忠誠度方面都不能盡如人意，在這種環境下想要做到準確的預估工時，想要讓他們堅持透明化的運作，是非常困難的事情。

最終，還是團隊的人員質量決定了持續交付的效率和質量。

一方面是團隊的參與者。“現在我招聘的時候，都會非常看中這個程序員的心態是否開放。他如果是那種特別以自我為中心的，聽不進別人的意見，也不愿意溝通的，這種我就會比較擔心一些。”路寧介紹說他自己帶過一些團隊，有的人就很不愿意做Pair Swapping，因為不愿意讓別人看到自己的工作進度，這樣的話就比較難展開。所以，開放的心態是非常重要的。

另一方面，團隊的管理者也很重要。路寧表示有的管理者會濫用敏捷開發流程當中的透明性，反而對團隊的發展不利。“比如，透明化之前的工作可能有張有弛的，這對于開發者來說是一種常態；但透明之后管理者可能看到，你原來這么快就把這個功能做完了，那我要給你加量，反而使得開發者無法得到充分的喘息。”

對于敏捷開發團隊的規模，路寧也提供了一些建議。一般敏捷團隊從6、7、8、9個人到20個人都是可以的，不過也有的團隊到10個人之后就搞不到一起去了。一般來說，6～12個人的團隊來完成持續交付會比較理想。