這是敏捷開發團隊管理系列的第二篇。（之一，之二，之三，之四）
之前的各個系列中，已經涉及了很多團隊管理相關的內容，比如松結對程式設計系列中提到過大型團隊分拆為微觀開發團隊的管理，產品管理系列中提到過product owner團隊的管理，敏捷開發績效管理系列中提到過「用中醫理論管理團隊」，敏捷開發般若敏捷系列中提到過借助「無我、無人、無眾生」的概念凝聚不同團隊的目標於一處，等等。
本系列會專門從團隊管理的角度，一方面將曾經提到過的內容加以貫穿，另一方面則會提及之外的一些未提及的內容，比如產品團隊與開發團隊的互動，測試團隊與開發團隊的關係與工作方式，等等，以供專門從事團隊管理的讀者借鑑。
敏捷開發團隊的外在行為是「結果導向」，而內在支撐則是「團隊工作」（teamwork）。
所謂結果導向，就是直指結果，而不拘泥於形式。
可以被拘泥的「形式」各式各樣，比如方式、方法、流程、文件、部門、分工、職責……都是形式。這些形式本來是設立來幫助實現更好的結果的，但是如果拘泥於此，則可能起到反作用。
如果仔細審視敏捷宣言中右側的內容，就會發現他們都屬於形式，而非結果：
個體與互動 重於 過程和工具
可用的軟體 重於 完備的文件
客戶協作 重於 合同談判
響應變化 重於 遵循計畫
這些形式曾經保證了眾多早期軍工、航天、航空專案的成功，但若在任何行業任何專案——比如敏捷開發出現時的網際網路行業——拘泥於此，就可能導致失敗。
可怕的是，左側的4條，也是形式而非結果。所以對敏捷宣言的正確理解是：在現今的多數行業中，如果以結果導向為出發點，則左側的形式勝過右側的形式。
為什麼說團隊工作利於結果導向的實現？
有乙個兄弟射雁的例子可以說明：三個兄弟看著大雁飛過，乙個說要射下來烤著吃，乙個說要燉著吃，另外乙個則要炒著吃，三人爭執不下，大雁都飛走了。
比如有乙個bug，人們不去分析怎樣改正怎樣預防，而是討論是誰的責任；比如有乙個任務，人們不去分析怎樣做最快，而是討論應該誰做；比如有乙個變更，人們不去分析變更前後甲乙方是否有利，而是討論應該哪些部門走怎樣的流程；比如有乙個產品，人們不去分析怎樣做才能成功，而是討論成功後應該怎樣考核……就很難直指結果，而陷入部門和個人的紛爭之中。
這裡倒不是說後者不需要考慮，而是說出發點問題。如果思考問題的第一念頭是「我」「我們」「他」「他們」，那麼團隊協作就建立不起來，敏捷開發也做不好。
本系列將涉及幾種常見團隊的關係問題：產品團隊與開發團隊，設計團隊與編碼團隊，編碼團隊與測試團隊……以及團隊內部的工作方式。
其間會引用幾個以往見過的以及現在身在其中的團隊的做法，並分析其應用的環境、潛在的風險。
敏捷開發團隊管理系列之一 序言與出發點
這是敏捷開發團隊管理系列的第二篇。之一，之二，之三，之四 之前的各個系列中，已經涉及了很多團隊管理相關的內容，比如松結對程式設計系列中提到過大型團隊分拆為微觀開發團隊的管理，產品管理系列中提到過product owner團隊的管理，敏捷開發績效管理系列中提到過 用中醫理論管理團隊 敏捷開發般若敏捷系...
敏捷開發智慧型敏捷系列之一 序言
這是智慧型敏捷系列的第一篇。之一，之二，之三，之四，之五 本文將解決各種敏捷中需要辯證思考的問題，包括 寫文件還是不寫文件？擁抱變更還是迭代期內無變更？持續交付的產品因為不完整被客戶鄙視怎麼辦？做架構設計還是不做？突出進度忽略了質量怎麼辦？我們不用文件就能開發但客戶偏偏要文件怎麼辦？自動化測試費力而...
敏捷開發智慧型敏捷系列之一 序言
本文將解決各種敏捷中需要辯證思考的問題，包括 寫文件還是不寫文件？擁抱變更還是迭代期內無變更？持續交付的產品因為不完整被客戶鄙視怎麼辦？做架構設計還是不做？突出進度忽略了質量怎麼辦？我們不用文件就能開發但客戶偏偏要文件怎麼辦？自動化測試費力而且測試 可能跟應用 一起被拋棄怎麼辦？敏捷開發中一直有幾個...