[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (二)讓我們來聊聊Scrum
請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。
Scrum和敏捷開發，在這幾年幾乎變成顯學。這很有趣，如果你深入觀察，會發現Scrum和過去的專案運行模式，有著"根本上"的差異。
而且確實，我對Scrum有些"自己的"看法。
在討論這些之前，首先，我必須先強調一件事情。我在團隊中導入Scrum，並不是為了要研究或驗證Scrum，也不是為了要遵循大師的腳蹤，更不是為了要體驗一下新的專案運行方式或是新的工具...都不是。
執行Scrum的理由只有一個，而且非常簡單，就是我們(專案團隊)希望讓案子成功。
會這樣說，是因為過去這十多年，在台灣，我們參與、執行、聽聞大大小小的案子，失敗不勝枚舉，幾乎沒有多少案子是在客戶和開發團隊都滿意的狀況下收尾的。專案不是延遲、就是超過預定的人天成本、再不然就是數不盡的客戶需求變更、或是解不完的Bugs和無法預測的未來、再加上客戶的預算和我們的成本看來永遠無法達到平衡。
經歷的案子越多，就越來越覺得這不是一個辦法。
客戶對於專案預算壓低又壓低、要我們提供報價卻不知道專案的範圍與具體內容、每一個案子的能見度都非常低，PM、開發人員、沒有人知道案子將會怎麼收場...
說真的，我們受夠了這樣的生活。
敏捷開發和Scrum的出現，讓我們『聽說』有一個更好的方式，讓客戶和專案團隊都過的開開心心。並且大家認真扎實的面對專案中的每一個問題，用合作與信任替代稽查、用溝通協調替代文件、用最簡單的工具和方法，讓整個專案回歸基本面。
由於我們是認真的開發團隊、有著相當資深的開發人員，我們不希望用哄抬的方式膨脹案子的預算，然後再打折來成交。我們的開發團隊真心喜歡編程，我們一點都不希望我們熱愛的工作在專案裡卻變成痛苦的來源。(真心話)
我們相信客戶想要一個真正能夠使用的軟體產品，而不只是想要結案交差，我們相信軟體可以有效的幫助企業實現利潤，而不只是畫一個美好卻遙不可及的大餅去騙客戶的錢。我們希望客戶真的使用我們所開發的軟體，讓我們的軟體創作與建設真正幫上客戶的忙。
所以，我們看到Scrum，我們開始覺得對未來有希望。
====================================================
因為上面提到的這些背景和原因，我開始讓團隊導入Scrum。(而原因只有一個，就是希望案子成功，專案中的每一個角色都快樂)
然而要談敏捷開發與Scrum的內涵，你必須知道幾件事情。這也是敏捷開發最主要的價值觀，對我來說，這幾乎可以說是Scrum實施的前提。
和進行傳統的專案不同，由於看到其他團隊累積的很多經驗，我們在啟動Scrum前，就有了底下的心理準備:
- 打從心底接受規格(需求)變更，而非期待客戶承諾出不可變更的規格。
- 著重產出可用的軟體成品，而非美美的文件或是結案報告。
- 與客戶的關係是基於合作與信任，而非一紙合約。
別小看上面這些。
上述的每一點，幾乎都顛覆了台灣現行的軟體專案開發的潛規則和行規...並且和現行的專案管理辦法可能南轅北轍、甚至完全不同，我們逐一扼要說明(後面幾篇會再詳細介紹與討論)。
第一點: 打從心底接受規格(需求)變更，而非期待客戶承諾出不可變更的規格。
光是接受規格是可變動的，就是一個非常核心的不同。(以前我們在專案中一直在做的，則是拼命守住或鎖住規格)
有經驗的PM會立刻想到幾件事情，規格可以變動，那專案價格怎麼估算? 時程和人力怎麼安排? 如果客戶改了規格那我們要怎麼做? 不能擋? 都要吃下來???? 這個那個這個那個...一堆問題出現了...
不僅如此，這部分甚至整個影響了系統分析和設計，由於規格可能隨時改變，因此over design本身就會變成非常大的問題，這個原則很可能會改變的架構設計的實施方式。有時候，我們因此會採用漸進式設計(Progressive Design)的方式來取代一次到位的設計(對很多架構師來說，這很掙扎)。很多時候我們在每一個iteration之中，會允許不完美但可接受(重點是要可以用)的產出，這對很多Developer來說又是一個掙扎。(後來，我們採用架構範本來解決這個問題，不過這事後話了，以後有機會再跟大家分享)
接著，這可能會改變合約和時程預估...
因為規格可以變動(記得嗎? 我們真心歡迎規格變動!)，所以開發團隊和案主必須能接受所謂的時程預估，就真的"只是預估"，那既然是預估，就可能估不準。隨著預估的開發時間愈長，預估的準確度就愈差。例如，如果這個案子我們估計的時程是三個月，那也許正負誤差在兩周，但如果預估的時程是九個月，那正負誤差搞不好不只六周，而是12周了...
也因此，案主不能夠拿預估的時程，來計算這個案子的成本或預算，也就是說，合約上最好不要有固定的專案金額(因為規格根本還沒決定啊，甚至，規格是可以變的，那怎麼會有固定的金額呢?但如此一來，怎麼跟案主的老闆討論專案成本和預算? 這樣，這案子會不會根本無法成案? (專案團隊要怎麼面對這個問題呢???)
第二點: 著重產出可用的軟體成品，而非美美的文件或是結案報告。
軟體產品要可用，而且要時時可用，同時間我們要捨棄非常多的傳統紙本文件產出，讓開發團隊把時間都花在客戶真正要的"功能"上。那...交接怎麼辦? 開發時的依據和溝通怎麼辦? 難道不需要注意驗收條件? UAT和驗收不是才是專案的重頭戲嗎?
因為要著重產出可用的軟體成品，所以我們非常重視每一個iteration的Demo Meeting，每兩周或每一個月，我們會邀請案主(stakeholders)來看看我們的進度展示，及時提供反饋，如果案主不滿意，隨時可以暫停、甚至打掉重建，當然，案主必須和專案團隊一起承擔過程中的成本。
這意味著，案主不能再跟過去一樣，坐在自己家裡等著專案團隊來SA訪談，然後就沒事了。很可能，案主必須每個月參與軟體的測試，投入在整個案子的開發流程之中。再也不像過去，付了錢就等UAT時，再以上級指導員的角色，來指指點點。
但這樣，案主會願意嗎? (如果不願意，專案團隊怎麼辦?)
第三點: 與客戶的關係是基於合作與信任，而非一紙合約。
這點導致有一個和傳統軟體專案之間，非常非常巨大的差異。因為客戶要能夠和團隊一起承擔專案的風險，對開發團隊來說，最理想的合約當然是金額不固定的人月報價型的合約，但這樣案主就非常有可能擔心花了錢卻拿不到自己想要的軟件，卻又不能拿著合約和UAT的時程與罰則，來逼著專案團隊趕工或是吃下去各種需求變更。
這樣，對於案主來說會不會太虧了? (其實，實務上根本不會) 但這樣做，案主真的會接受嗎?
==============================================================
光是上面我刻意凸顯出來的這幾點，你就會發現這似乎跟台灣現在軟體專案的運行方式有著天大的差異，但實際上我們碰到的心理衝突遠遠不只如此(但讀者也不需要擔心，面對這些衝突，都有著不同的解決技巧)，只是我挑了其中幾個和當前專案進行思路有著最大差異的部分，來凸顯敏捷開發和傳統開發的不同之處。
再說，寫這篇並不是為了研究Scrum，而是想將我們段時間以來，採用Scrum來開發專案所面對的問題與解決方式記錄下來。所以，我不能保證裡面每一個想法與作法都和坊間的書籍相符，因為專案管理，必須因時因地制宜，有時候團隊成員不同，採用或偏重的技巧就有所不同。
但我要強調的是，Scrum為我們帶來了一個面對專案新的可能性，並且讓團隊成員和PM對專案更加的有信心、有興趣、甚至有熱誠。光這一點...就讓我深深的覺得值回票價了!!!
本篇收錄自 - 『敏捷開發專案管理與架構設計實務』
留言