初識敏捷開發是在2006年，那時愉快的加入了畢業後第二家公司，一家打算在中國開展外包業務的美國公司。其業務形式就是讓在美國的總部接當地的IT單子，然後拿到中國來做。

中國分支的名字也很高大上，Global Development Center，其實當時在全球就這麼一個分支機構，不知當初的美國老闆怎麼選上杭州，而不是上海的。

我那時對軟體開發的流程認識基本停留在軟體工程課本里描述的所謂瀑布式開發，在專案開始前拼命的收集需求，根據可憐的尚不明確的資訊進行分析，爭取設計出一套合理的邏輯抽象，並祈禱在開發過程中客戶千萬別拍腦袋變更需求。由於國際外包規則就是看外包公司的CMMI等級，所以就是這家公司將看似風馬牛不相及的兩套開發流程（Scrum和CMMI）結合在了一起，有SQA team對質量進行度量，參加每日站會，challenge team leader，跟蹤文件。

那時有個為美國政府開發的較大專案，斷斷續續持續了近兩年，開發人數有近30人，為了提高跟美國BA(業務分析員)的溝通效率，同時派到美國去的開發最多時也有10幾人，成本很高。專案組一個PM，拆分成了4個team，每個組一個leader，再下面的開發3-5人。那是我就在考慮敏捷專案是否適合大專案，因為敏捷之所以能敏捷，是因為人數基本上是在9人以下的，這樣才能堅持短時間站會，提高每個迭代結束時review meeting的效率，在迭代開始做任務估算能半天搞定。

超過9人，人與人間的溝通成本大增，本來坐在一起的幾個人，喊下就能溝通的，現在不行了；物理上不能近距離的坐在一起，可能要靠IM，EMAIL,電話。大型外企呆過的都有個毛病，就是幹啥都喜歡寫郵件，大家發來發去，抄送一堆人，不亦樂乎，為什麼這樣？因為人離的遠了，交流要留下點文字的證據。不要說跨部門溝通，同一個部門人都有隔閡。

這樣的情況下如何讓大型開發團隊，而且還可能是跨國異地文化不同的團隊進行敏捷開發，那時我還沒有想清楚。直到年初朋友介紹了我這本書，內容就是HP如何將自己500人的團隊進行敏捷化改造，開發其核心功能Firmware的。其組織文化敏捷化過程改造也經歷了長時間陣痛，頂住了因循守舊的人類根性的質疑，提高了產品線的生產效率。

這是一本值得仔細品味的書。

文章來自微信平臺「麥芽麵包」。轉載請註明。