敏捷學習－ Scrum與功能團隊 2016-7-13
現在流行一個詞“撕B”。這個詞，足可以形容，互聯網行業，人員和組織間的各種“摩擦”。
一個普通的程序員可能這麼度過一天的。拎着早餐，打開機器，郵件列表裏，已經有一堆的Bug列表了，隨便瀏覽了一下，心裏已經在暗暗的說，某某某，這個傻X，這麼明顯，環境變量少了一個，測試環境咋配的啊，不是早改了麼。
好不容易，喫完了早飯，還沒擡頭呢，項目經理正大聲的說，某某某，都三天了，你那個功能，寫完了麼？你這邊，馬上就說，代碼早寫完了，在聯調，框架那邊，跟他們說了好幾回了，缺個返回，他們一直都拖着不改。
程序員的“心情指數”已經下降到快冰點了。
這個場景，描述的，是一個項目組織的片斷。
如果用一個詞來概括，那就是依賴。
我們可以用下面的圖大致描述這樣的組織(組件團隊），一個PM（project manager）代理一個組織。
這種情況下，依賴關係，大部分出現在PO（Product Owner）和PM之間。（圖中，沒有體現PM和PM之間可能的依賴）。
目前的項目管理，主要針對針對這種依賴，相應的工具，有計劃，Deadline，成本，審計等等。
Scrum建議的組織的模型（功能團隊），與之不同，直觀上來看，是將依賴關係“下移”了一層。
下面的圖中的PB（Product Backlog）的屬主是 PO。
從左側來看，PO只看到他的待辦列表。他不再關心，這些Item怎麼實現的。
在社區活動中，老師用道家的陰陽雙魚圖來描述列表中的一個Item，他的一側是how，另一側是what。
我簡化如下：
PO : “What|How” : Developer
同一個 Item，在PO的視角下，看到是它是什麼，它能完成什麼功能，它有哪些特性。在Developer的視角下，它怎麼工作，怎麼實現它。
PO 和 Dev.，都做自己最擅長的工作。
現在，還有一個最重要的問題，依賴怎麼辦？
讓我們回到一個實際的問題中來。功能1需要調用功能2中的一個API。假設就是查詢當前在線用戶信息。這該怎麼辦？
我們很難等到功能2完成後，給出一個“穩定”的版本，再定這個API，原因很簡單，複雜的依賴關係。而且是動態的。從調用者的角度來看，可能剛開始的時候，覺得直接返回在線的人數，就夠用了。隨着功能的增強，希望返回的是一個列表。
如果這些功能是一個人來完成的，我想，大部分人採用的策略是兩邊調整的策略，不夠使了，根據具體的情況，再細化。
上升一個層次來看，爲什麼一旦涉及到多人之間協調的時候，就開始撕了呢？
在這張圖中，如果橢圓形代表是單個的人，那顯然，我們可以把這個組織看做一個PO帶若干開發共同組成一個團隊。
如果橢圓形又是一個小組織呢？
這就是多個團隊對應一個PO的情形。
這個問題，是這次活動的老師，一開場，提出的一個問題：如果1個PO，需要帶多個團隊，該怎麼辦？
（順便回答，上篇文章，提到的畫漫畫的事情，我們每次社區活動，都會贈給授課老師一張漫畫，因此活動組織者，在課程進行中，就邊聽邊畫了。。。）