jim yeh on 十一月 8th, 2009

上個月 24 日應 MaoYang 兄之邀,分享我在敏捷開發的實戰經驗。這場分享會還找來了 David Ko 兄分享他在公司導入 scrum 開發管理方法的經驗,同人則負責分享我之前在專案中推行 extreme programming 工程實務的經驗。分享會在台北市電腦公會舉行,看到現場互動氣氛的熱絡,以及會後學員們給予不少正面的評價,感覺大家收穫都不少。其實包括我自己在分享會結束之後也產生了一些想法,倒是想藉由此文章分享我的分享會後心得。

同人很喜歡 David Ko 兄提到愛因斯坦為 Insanity 這個字所下的定義:「Doing the same thing over and over again and expecting different results」我認為這個定義很貼切地描寫許多人在軟體開發過程所展現的心態;過去做過行不通的做法,卻認為在今天可以行得通,結果讓人一直瘋狂或是不斷地精神錯亂。

但為什麼人們要盲目地做些行不通的事呢?其實以同人這麼多年軟體開發的經驗來看,他們不見得是意識不到這些做法行不通,而是可能因為害怕與恐懼,讓他們不敢嘗試新的方法來解決問題。

縱使無法解決問題的挫折是令人沮喪的,但如果要放棄過去習慣的做法來開發系統,他們更會茫然不知所措,擔心因此對現況失去掌控能力。於是明知過去的做法有問題,但更害怕失去它就會一無所有,於是只好將它緊緊地捉在手上,並期待這一次會有奇蹟出現,改寫過去失敗的命運。

不過如果人們理性一點,都會意識到要改變命運不應該期待奇蹟,而是需要「勇氣」讓我們改變心智模式,然後採用有效的方法來解決問題。在這方面,同人覺得比較幸運的是我常碰到好主管,能夠支持我想要把事情做好的想法。

記得過去的主管 Y.L. Liu 曾經告訴過我的話:「如果過去這樣做行不通,那今天就應該嘗試不一樣的做法」即使改變必然會遭遇到阻礙,然而當我們勇於面對阻礙而因應問題時,才能促使我們打破過去的習慣來進行有紀律地思考與行動,進而更有效地解決問題。

紀律,也就是 discipline 這個字。它的意義並不是做我們過去熟悉的事,而是熟悉了解問題是什麼,並加以解決問題的過程。如同我過去的文章所強調的,軟體開發不只是工程,或是工藝,而是解決問題的過程。敏捷開發其實並非依賴制式的軟體開發流程或方法,而是基於重要價值觀與原則發展出來的實務,而最重要的價值觀就是為了思考如何「解決問題」,至於使用流程方法都只是手段而不是目的。

然而,根據同人的經驗,想要軟體開發過程運用以上的觀念,我認為最困難的是對專案目標的混淆。在這次的分享會之中,同人也發現有些 PMP 背景的朋友,他們很關心如何準確預估專案的範圍、時程與資源,因此希望了解敏捷開發如何來解決這樣的問題。但其實敏捷開發方法根本不需要做精確的預估,因為改變是無法預估的。所以它強調的是反應變化的能力,而不去為預期或抑制變化做太多的努力。

或許有人會把精確的專案預估,看成是專案成功的重要目標之一。但以同人這位 PMP 對專案管理的認知來看,精確預估並非專案的目標,而是達成降低專案風險目標的手段之一。或許用這種手段來蓋房子,或生產看得到、摸得著,可以明確度量的產品可以做得很好,但用它來開發軟體卻不見得可以行得通。

我們應該改變對軟體開發專案的傳統思維;假如軟體開發的本質,就是難以精確預估,那麼我們就不該將力氣浪費在預測上,而是應該用來進行對專案更有效益的事情上。但這不代表敏捷開發方式不做規劃,而是規劃的重點不在精確地預測未來,而是用來定義專案的基準線;利用每一次的反覆過程的回饋,用來改善或調整後續的計劃,以增進我們回應變化的能力。

因此,使用敏捷開發我們不需要具細彌遺地預測未來的改變,只需集中心力面對今天所發生的問題。換句話說,開發者也不需要一份不會變更的功能需求清單,而是了解專案目前所要解決的實際問題,進而運用(adopt)思考及創意、調適(adapt)方法然後再熟練(adept)所需要的技能來解決問題。

那麼,以上敏捷開發的思維是否打破專案管理的基本觀念?同人從不認為如此。依照 PMBOK 的專案管理知識領域與流程本來就支援管理改變的做法,問題只在於管理者是否掌握住變更管理的重要原則並熟練它們:

首先、必須確認改變對專案有正面效益;

其次、必須確認影響變更的因素已發生;

最後、最重要的是管理變更。(PMI,2000)

我們看到這些原則不但並不違背敏捷開發的思維,同時兩者是相通並且相輔相成的。的確,對於軟體專案而言,改變意味著增加軟體開發的風險,但害怕專案風險的心態,也代表你的團隊面對風險只能迴避它們以確保安全,但你所獲取的利潤也相對變得較低(DeMarco & Lister,2007)。於是你必須辛苦地在市場上試圖降低軟體價格來與對手競爭,除非你能夠勇敢地面對挑戰,選擇快速回應變化才會創造機會,為專案產生更大的正面效益。

那麼對於環境或需求的變化,軟體開發團隊要如何快速回應呢?依據同人的經驗,大規模的事先設計(BDUF,Big Design Up-Front)通常無法立即迅速地反應變化,而且常常會造成過度的工程化(over engineering)的問題。而依賴開發組織導入某些流程、工具或方法論其實也並非成功的關鍵。我認為只有增進團隊溝通與合作,讓團隊能為面對問題而共同努力,才能夠快速地回應變化。

或許有人會認為詳盡的文件可以增進溝通,但實際上它的成效不高而且常常要人們花費很多的心力,除非你發現它真的有幫助,否則你應該只需要寫必要的文件。雖然工具或方法論可以增進開發的效率,但它們也會讓工作變得艱難。因為無法被替除的工作,它們是更具備知識密集的特性,需要更有才幹的人來完成任務(DeMarco & Lister,2007)。所以在導入任何工具或方法論之前,你應該提醒自己,敏捷開發是以人為基礎,面對的是現實而非理想

誠如 David Ko 在分享會中說得好,任何方法的導入如果最後變成政令宣導時,那就非常不妙了。同人則以為快速回應的關鍵不在於遵循方法論的做法,而在於面對專案的現實問題,讓團隊共同因應問題而改變。David Ko 提出了很多他的專案所導入的做法,同時分享他感受到團隊成員自動自發的喜悅,也讓同人希望能夠見賢思齊。



     

One Response to “敏捷開發實戰經驗分享會後感”

  1. [...] 還提到他很欣賞上次 David Ko 在敏捷開發分享會提到的經驗;團隊主動提出要使用 Scrum,這時候身為經理的 David [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">