十九、與其他方法論共存
混合Scrum和順序式開發
1、三種交互場景
1）瀑布在前模式
Scrum和順序式開發在項目的開始時就交匯，通常發生在組織有項目批準障礙時
需要一開始就創建需求規格說明書、項目計劃等順序式開發特有的文檔
2）瀑布在后模式
Scrum和順序式開發在項目的結束時交匯，通常是在測試階段
這種場景比前一種好接受一些，畢竟開發工作已經完成了
3）瀑布兩頭模式
最難的模式，通常由兩個團隊協同開發，一個團隊使用Scrum而另一個團隊使用順序式
2、沖突的3個領域
可能發生的三種沖突：開發過程、業務過程、人
解決沖突的辦法：
1）所做的分析超過Scrum通常所需要的
2）創建一個剛好足夠的流程，而不是分拆一個大的流程
3）定義一個劃分了Scrum和順序式方法的系統架構
4）采用那些不管什么流程都能適用的敏捷實踐
5）教育項目干系人
3、Scrum和順序式能永遠共存嗎？
不能。
讓Scrum暫時與一個順序式過程并存在很多時候是必要的
但敏捷不是目標，敏捷意味著持續的改進
監管
項目監管和項目管理不是一回事，從項目管理中分離項目監管是可以的
1、用非敏捷的監管來運行Scrum項目
1）預先協商和設定預期
2）報告要滿足當前的期望——希望甘特圖，就提供甘特圖，希望燃盡圖，就提供燃盡圖
3）邀請他們參加你的過程
4）參考成功的例子——盡你所能讓前2個項目成功，將減輕或減少監管的檢查點
兼容
1、ISO 9001
最痛苦的事情是必須建立一套質量管理系統，這將花費相當長的時間，而且文檔需要非常齊全
2、能力成熟度模型集成（CMMI）
Scrum目前允許通過CMMI 5級模型
CMMI和相關的審計并不強制一個特別的方法論，而是嘗試幫助團隊遵循最佳實踐
3、實現兼容
1）在產品Backlog上投入足夠的精力
2）將監管相關的工作放入產品Backlog
3）考慮使用檢查列表——checklist不要引入新的強制性步驟
4）自動化
5）使用敏捷項目管理工具——索引卡、圖表、jira、禪道、釘釘等
6）慢慢而穩定地前進——增量進行
7）跟審計員一起工作
8）引入外部的幫助——引入一名對認證有經驗的外部咨詢師或者SM
二十、人力資源、后勤和PMO
人力資源
1、管理層次結構
企業結構應該盡量扁平，在團隊成員和公司高層之間的層級越多，就越有可能慢慢失去控制
1）向SM匯報
傾向于匯報給職能經理，向SM匯報不應影響績效
2）向PO匯報
PO的工作的部分內容就是盡量更多地加入功能特性并更快地提交它們
不建議向PO匯報，也不建議SM向PO匯報，但PO是老板另當別論
2、定期的績效評估
1）評估要盡量消除那些傾向個人的因素——字面意思
2）要包含團隊協作的因素——“團隊在預算和時間段內有效地管理他們的任務”
3）更頻繁地評估績效，每年超過一次——字面意思
4）廣泛收集反饋意見——從其他人收集反饋，范圍要大
5）培訓人力資源部門并讓他們參與——字面意思
3、開除團隊成員
團隊本身不應有權從團隊中開除某人，團隊組成的最終決定權必須留在企業領導層手里
4、職業發展
企業實施Scrum后，判斷某人的成功不能再用有多少人向他匯報來衡量，而是要根據這個人能承擔多少責任來衡量
精力充沛的腦力勞動會造就更高的績效，最終產出更好的產品
對出色表現的感謝就是更有挑戰性的項目
5、只要有人參與，就總是存在與人相關的問題
軟件開發本質上是一種天然的人力密集型活動，所以會有各種與人相關的問題
后勤
1、空間
隔間和公共區：一對沙發、一個白板、一個書架
開放區域里的協作精神和內在的能量會讓整個團隊充滿活力
2、將作戰指揮室變到整個空間
創建一個大型的、開放的區間，確保有足夠空間給團隊里的每一個人
這經常需要得到領導層的支持才可以實現
3、家具
開放的空間和可移動的桌子很重要，桌子需要適配結對編程，手機是必要的，SM最好坐在靠近隔間的門口，以便阻止和詢問閑雜人等
4、在工作空間里應該可見的東西
1）大的、可見的圖表——燃盡圖是必要的
2）額外的反饋設備——各種指示燈、測試服務器告警等
3）團隊里的每一個人——SM必須，PO可選但推薦
4）Sprint Backlog
5）產品Backlog——堆疊在顯眼處，使團隊有積極性
6）至少一個大白板——鼓勵突發的會議
7）一些安靜和私有的空間
8）食物和飲料——小冰箱、咖啡機、小吃、零食
9）一個窗戶——自然光非常不錯
項目管理辦公室
1、人員
敏捷的PMO應該做到如下事情：
1）開發培訓課程
2）提供指導
3）選擇和培訓教練
4）挑戰現有行為——主要是指阻止反對者，以及提醒團隊戒驕戒躁
2、項目
1）協助報告——每個項目的周狀態報告以及會議
2）協助完成符合性需求——比如ISO 9001這種帶有數據安全性的標準
3）管理新項目的流入——抵制快速啟動項目的沖動
3、過程
1）提供和維護工具
2）協助建立和收集度量——聚焦于在遞交價值方面有何表現
3）減少浪費——除非有必要，避免引入文檔、會議、批準等
4）幫助建立和支持實踐社區
5）保持團隊間適當的一致性——確保好的想法在團隊間快速地傳播
6）協調團隊——解決分歧和工作重疊
7）使用Scrum的典范——使用Scrum來運作PMO本身
8）和其他部門協作——與HR和后勤通力協作
4、重新命名PMO
敏捷PMO是一個好名字，不建議取其他的外號，這并不是重點
底線
個體和交互勝過過程與工具
要把HR、后勤和PMO視為需要招募的盟友而不是敵人
