2014年6月26日 星期四

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (二)讓我們來聊聊Scrum

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表),因此並不完整,閱讀時請務必參考相關的VS Online標籤以閱讀更完整的前後文。

Scrum和敏捷開發,在這幾年幾乎變成顯學。這很有趣,如果你深入觀察,會發現Scrum和過去的專案運行模式,有著"根本上"的差異。

而且確實,我對Scrum有些"自己的"看法。

在討論這些之前,首先,我必須先強調一件事情。我在團隊中導入Scrum,並不是為了要研究或驗證Scrum,也不是為了要遵循大師的腳蹤,更不是為了要體驗一下新的專案運行方式或是新的工具...都不是。

執行Scrum的理由只有一個,而且非常簡單,就是我們(專案團隊)希望讓案子成功。

會這樣說,是因為過去這十多年,在台灣,我們參與、執行、聽聞大大小小的案子,失敗不勝枚舉,幾乎沒有多少案子是在客戶和開發團隊都滿意的狀況下收尾的。專案不是延遲、就是超過預定的人天成本、再不然就是數不盡的客戶需求變更、或是解不完的Bugs和無法預測的未來、再加上客戶的預算和我們的成本看來永遠無法達到平衡。

經歷的案子越多,就越來越覺得這不是一個辦法。

客戶對於專案預算壓低又壓低、要我們提供報價卻不知道專案的範圍與具體內容、每一個案子的能見度都非常低,PM、開發人員、沒有人知道案子將會怎麼收場...

說真的,我們受夠了這樣的生活。

敏捷開發和Scrum的出現,讓我們『聽說』有一個更好的方式,讓客戶和專案團隊都過的開開心心。並且大家認真扎實的面對專案中的每一個問題,用合作與信任替代稽查、用溝通協調替代文件、用最簡單的工具和方法,讓整個專案回歸基本面。

由於我們是認真的開發團隊、有著相當資深的開發人員,我們不希望用哄抬的方式膨脹案子的預算,然後再打折來成交。我們的開發團隊真心喜歡編程,我們一點都不希望我們熱愛的工作在專案裡卻變成痛苦的來源。(真心話)

我們相信客戶想要一個真正能夠使用的軟體產品,而不只是想要結案交差,我們相信軟體可以有效的幫助企業實現利潤,而不只是畫一個美好卻遙不可及的大餅去騙客戶的錢。我們希望客戶真的使用我們所開發的軟體,讓我們的軟體創作與建設真正幫上客戶的忙。

所以,我們看到Scrum,我們開始覺得對未來有希望。
====================================================

因為上面提到的這些背景和原因,我開始讓團隊導入Scrum。(而原因只有一個,就是希望案子成功,專案中的每一個角色都快樂)

然而要談敏捷開發與Scrum的內涵,你必須知道幾件事情。這也是敏捷開發最主要的價值觀,對我來說,這幾乎可以說是Scrum實施的前提。

和進行傳統的專案不同,由於看到其他團隊累積的很多經驗,我們在啟動Scrum前,就有了底下的心理準備:
  1. 打從心底接受規格(需求)變更,而非期待客戶承諾出不可變更的規格。
  2. 著重產出可用的軟體成品,而非美美的文件或是結案報告。
  3. 與客戶的關係是基於合作與信任,而非一紙合約。

別小看上面這些。

上述的每一點,幾乎都顛覆了台灣現行的軟體專案開發的潛規則和行規...並且和現行的專案管理辦法可能南轅北轍、甚至完全不同,我們逐一扼要說明(後面幾篇會再詳細介紹與討論)。

第一點: 打從心底接受規格(需求)變更,而非期待客戶承諾出不可變更的規格

光是接受規格是可變動的,就是一個非常核心的不同。(以前我們在專案中一直在做的,則是拼命守住或鎖住規格)

有經驗的PM會立刻想到幾件事情,規格可以變動,那專案價格怎麼估算? 時程和人力怎麼安排? 如果客戶改了規格那我們要怎麼做? 不能擋? 都要吃下來???? 這個那個這個那個...一堆問題出現了...

不僅如此,這部分甚至整個影響了系統分析和設計,由於規格可能隨時改變,因此over design本身就會變成非常大的問題,這個原則很可能會改變的架構設計的實施方式。有時候,我們因此會採用漸進式設計(Progressive Design)的方式來取代一次到位的設計(對很多架構師來說,這很掙扎)。很多時候我們在每一個iteration之中,會允許不完美但可接受(重點是要可以用)的產出,這對很多Developer來說又是一個掙扎。(後來,我們採用架構範本來解決這個問題,不過這事後話了,以後有機會再跟大家分享)

接著,這可能會改變合約和時程預估...

因為規格可以變動(記得嗎? 我們真心歡迎規格變動!),所以開發團隊和案主必須能接受所謂的時程預估,就真的"只是預估",那既然是預估,就可能估不準。隨著預估的開發時間愈長,預估的準確度就愈差。例如,如果這個案子我們估計的時程是三個月,那也許正負誤差在兩周,但如果預估的時程是九個月,那正負誤差搞不好不只六周,而是12周了...

也因此,案主不能夠拿預估的時程,來計算這個案子的成本或預算,也就是說,合約上最好不要有固定的專案金額(因為規格根本還沒決定啊,甚至,規格是可以變的,那怎麼會有固定的金額呢?但如此一來,怎麼跟案主的老闆討論專案成本和預算? 這樣,這案子會不會根本無法成案? (專案團隊要怎麼面對這個問題呢???)

第二點: 著重產出可用的軟體成品,而非美美的文件或是結案報告。

軟體產品要可用,而且要時時可用,同時間我們要捨棄非常多的傳統紙本文件產出,讓開發團隊把時間都花在客戶真正要的"功能"上。那...交接怎麼辦? 開發時的依據和溝通怎麼辦?  難道不需要注意驗收條件? UAT和驗收不是才是專案的重頭戲嗎?

因為要著重產出可用的軟體成品,所以我們非常重視每一個iteration的Demo Meeting,每兩周或每一個月,我們會邀請案主(stakeholders)來看看我們的進度展示,及時提供反饋,如果案主不滿意,隨時可以暫停、甚至打掉重建,當然,案主必須和專案團隊一起承擔過程中的成本。

這意味著,案主不能再跟過去一樣,坐在自己家裡等著專案團隊來SA訪談,然後就沒事了。很可能,案主必須每個月參與軟體的測試,投入在整個案子的開發流程之中。再也不像過去,付了錢就等UAT時,再以上級指導員的角色,來指指點點。

但這樣,案主會願意嗎? (如果不願意,專案團隊怎麼辦?)

第三點: 與客戶的關係是基於合作與信任,而非一紙合約。

這點導致有一個和傳統軟體專案之間,非常非常巨大的差異。因為客戶要能夠和團隊一起承擔專案的風險,對開發團隊來說,最理想的合約當然是金額不固定的人月報價型的合約,但這樣案主就非常有可能擔心花了錢卻拿不到自己想要的軟件,卻又不能拿著合約和UAT的時程與罰則,來逼著專案團隊趕工或是吃下去各種需求變更。

這樣,對於案主來說會不會太虧了? (其實,實務上根本不會) 但這樣做,案主真的會接受嗎?
==============================================================

光是上面我刻意凸顯出來的這幾點,你就會發現這似乎跟台灣現在軟體專案的運行方式有著天大的差異,但實際上我們碰到的心理衝突遠遠不只如此(但讀者也不需要擔心,面對這些衝突,都有著不同的解決技巧),只是我挑了其中幾個和當前專案進行思路有著最大差異的部分,來凸顯敏捷開發和傳統開發的不同之處。

再說,寫這篇並不是為了研究Scrum,而是想將我們段時間以來,採用Scrum來開發專案所面對的問題與解決方式記錄下來。所以,我不能保證裡面每一個想法與作法都和坊間的書籍相符,因為專案管理,必須因時因地制宜,有時候團隊成員不同,採用或偏重的技巧就有所不同。

但我要強調的是,Scrum為我們帶來了一個面對專案新的可能性,並且讓團隊成員和PM對專案更加的有信心、有興趣、甚至有熱誠。光這一點...就讓我深深的覺得值回票價了!!!

本篇收錄自 - 『敏捷開發專案管理與架構設計實務

沒有留言: