昨天晚上和部門的幾個SC在新加坡項目現場聚餐, 期間有個資深SC問我: 我們不是已經敏捷了嗎? 敏捷到底是什么?
上面說的'我們已經敏捷了', 指的是2017年初開始EBS項目作為公司的試點項目, 自上而下開始推行的敏捷轉型. 這位資深SC因為長期在項目現場, 未參與母公司的敏捷導入培訓, 也沒有參加后期的敏捷教練訓練營, 問的是合情合理. 其實就算參與了公司的導入培訓, 我也觀察到很多研發的同事在這個問題的理解上還不算清晰. 比如, 敏捷就是Scrum嗎? 有了站例會和看板是否意味這團隊就開始敏捷了? 作為一個早期參與到敏捷轉型實踐的員工, 結合最近看的一些書籍資料, 寫一些我的理解.
首先, 用排除法. 看敏捷不是什么:?
敏捷不是方法論, 不是特別的軟件開發模式, 也不是一套工作框架和流程.?
也就是說敏捷不是一個可以生搬硬套的理論和流程. 比如, 它不像一個編程語言, 有一套固定的語法和語義. 也不像一個工作流程, 只要按照流程圖走, 就可以到達終點. A公司的敏捷實踐不一定適用于B公司, 也許實踐起來有諸多矛盾之處. 假如你在市面上看到有推銷XX公司敏捷方法的書籍或者咨詢公司, 比如IBM敏捷, 微軟Scrum, 等等, 建議你三思而后行.
敏捷是一套價值觀(values)和原則(principles). 我們談論敏捷時, 經常會談到具體的實踐(如站會, 回顧會), 甚至具體的工具(如Leangoo). 然而這些實踐或工具本身并不是敏捷, 而是用來讓團隊去貫徹敏捷的價值觀和原則. 換句話說, 只有當具體的實踐/工具帶來的效果符合敏捷的價值觀和原則, 它才是敏捷實踐的一部分, 理解敏捷價值觀和原則是用來幫助我們在研發過程中做決策.?
這么去理解敏捷, 就會發現在敏捷實踐中, 每個團隊/項目/公司所采用的方式可以是非常靈活的.??
現在來看看這些價值觀和原則, 也就是所謂的敏捷宣言(agile manifesto), 包含了4個核心價值觀和12條原則.(http://agilemanifesto.org/iso/zhchs/manifesto.html)
4個核心價值觀:
我們一直在實踐中探尋更好的軟件開發方法，
身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動高于 流程和工具
工作的軟件高于 詳盡的文檔
客戶合作高于 合同談判
響應變化高于 遵循計劃
也就是說，盡管右項有其價值，
我們更重視左項的價值。
注意人們在閱讀時, 經常喜歡劃重點, 而忽略了很多其他關鍵信息. 如敏捷宣言的前兩句.
我們一直在實踐中探尋更好的軟件開發方法，
身體力行的同時也幫助他人
兩個關鍵字: '實踐中探尋', '同時也幫助他人'.
強調了敏捷除了實踐沒有捷徑可走. 也強調了敏捷不是一個人的事, 只有團隊的敏捷才是真正的敏捷.
還有最后兩句(比起前兩句, 這后兩句話現在被強調的次數更多):
也就是說，盡管右項有其價值，
我們更重視左項的價值。
這里強調了右項不能被忽略, 但是在決策時, 如果最后決定更符合左項價值觀, 應該如何行動.
12條原則:
我們遵循以下原則：
我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意。
欣然面對需求變化，即使在開發后期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。
業務人員和開發人員必須相互合作，項目中的每一天都不例外。
激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
不論團隊內外，傳遞信息效果最好效率也最高的方式是面對面的交談。
可工作的軟件是進度的首要度量標準。
敏捷過程倡導可持續開發。責任人、開發人員和用戶要能夠共同維持其步調穩定延續。
堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
以簡潔為本，它是極力減少不必要工作量的藝術。
最好的架構、需求和設計出自自組織團隊。
團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。
以上每一條都可以通過閱讀專業書籍來解讀, 這里不累述.
舉例來說如何理解并參考敏捷敏捷價值觀和原則:?
比如,當開發人員接到一個任務時, 他發現如果設計一套規則表, 不光可以解決現在的問題, 還能更靈活的支持其他復雜場景. 但是開發工期可能要延期1周. 當他考慮到'及早交付有價值需求', 以及'以簡潔為本'的原則, 他會找需求負責人談, 是否這個場景未來會經常變化? 還是特殊業務? 客戶對版本交付的時間敏感? 而不是自己直接做決策.?
又比如, 測試人員原則在做UAT, 現場網絡很差, 準備數據要花半天時間. 考慮'激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標'的原則, 團隊負責人應該第一時間解決網絡問題.
再比如, 需求分析人員經常出差, 無法在所內辦公, 考慮'業務人員和開發人員必須相互合作，項目中的每一天都不例外'的原則, 團隊負責人應該考慮如何增加需求分析師, 或者和客戶說明需求調研必須在某個時間段完成(當然這個也不符合'欣然面對需求變化'的原則, 在公司合同約束的前提下很難改變, 當然也應該是我們努力改變的方向), 留出與開發人員溝通的時間.
當所有的團隊成員(需求,設計,開發,測試,甚至到交付)每天的工作都以敏捷價值觀和原則來作為決策基礎, 持續改進, 假以時日,這個團隊可以自豪的說我們已經在走向敏捷了.
