[Scrum]推行Scrum前要有的心理準備

  • 490
  • 0

在工作中摸索Scrum的一些感想,依據Scrum的角色分別說明願景及方向

開發團隊

要有夠好軟體的架構及面對改變的心態

Scrum的出發點是快速回應改變,所以對於需求的變化的接受度相對於瀑布式開發會來得高。只是,對於開發團隊來說,要可以隨意地修改商業邏輯,就代表軟體架構要有彈性。各組件間的內聚力高、耦合度低,搭配完善的單元測試,才能讓商業邏輯的修改可以順利進行,不會因為改A,卻導致B或C發生問題。

另外,如果有開發人員之前已經習慣了瀑布式開發的方式,習慣了需求規格書嚴密載明系統規格。這時候,就需要請他們調整一下心態。因為Scrum所強調的就是隨時面對需求的改變。軟體開發,不會再像建造一棟建築物,有明確的藍圖。而會像是玩樂高,不斷的建立小元件,再不斷的組合及重構。(當然,一個穩固及彈性的系統架構還是非常需要的)

自我驅動

進行Scrum時,所有的任務都是自己選取,任務所要花費的時間,也是團隊的決策,而非管理者直接指定。更別說Scrum的活動中,包括Daily meeting、Retrospective meeting,講求開發的透明度。無論是開發進度,或是開發遇到的難題及Solution,都要明白的攤在陽光下。

要做到這一點,管理階層必須要充分尊重開發人員。要相信開發人員不會在工時上灌水、要相信開發人員的專業判斷。這時,管理所著重的,是如何讓團隊發揮整體戰力,而非績效導向的個人秀。

而開發團隊也要保持積極及開放的態度,在每個Sprint中發揮自己的專業,完成承諾的任務。並同時在Daily meeting、Retrospective meeting中,明白的說明自己遇到的問題及困難。一個積極開放的團隊在成員遇到問題時,其他成員都會盡力的幫忙及互補。這樣會讓團隊不斷地成長,遇到問題的成員會很快地解決問題,沒遇到問題的成員可以學到經驗。

因為沒有管理者的推動及壓力,Scrum成員領取任務及執行任務,都是要靠自我驅動力。一個好的團隊,成員們會形成良性競爭的循環,其他人積極的態度,以及完成任務的成就感,都會讓成員們體驗到程式開發所帶來的快感。

人際互動更頻繁

相對於傳統的開發方式,敏捷式開發(Agile)注重的是面對面的溝通,以及人員間的合作(敏捷軟體開發宣言),Scrum身為Agile的一員,所以該宣言的方向同樣適用。因此,開發團隊要了解到往後不是只跟機器講話,還要跟人講話。再加上Scrum Team並沒有管理者進行派工,所以有時候任務的分界是很模糊的,這更放大了溝通協調的重要性。Scrum的運作規則,其實有強迫開發團隊多進行溝通。包括每天進行的Daily meeting,每個Print進行前的Planning meeting,以及之後的Retrospective meeting,都是讓開發團隊成員可以規律性的進行問題的溝通,以及解決方案的協調。

Scrum Master

在沒有權力的前提下,協助開發團隊完成任務

因為Scrum強調自組織的架構,而組織權力的介入,會折損開發團隊的自組織能力。所以,Scrum Master比較趨近於協助者的角色。在沒有權力的前提下,協助團隊適應Scrum的運作模式,以及完成任務。輔助開發團隊解決非技術的問題,例如商業流程的限制、組織的壓力、甚至是設備及場地的問題。這也就表示,要做好Scrum Master的工作,除了對Scrum要有充分的瞭解及經驗外,不能使用傳統的人事權去推動團隊,只能使用軟實力來驅動開發團隊向前衝

實務上,部門主管通常會擔任Scrum Master的角色,只是這樣的安排要多留心如何不破壞開發團隊的自組織能力。

Product Owner

引導團隊真正的瞭解需求

若說Scrum Master負責對內,搞定開發團隊的正常運作。則Product Owner是負責對外,搞定Stakeholder(利害關係人)的需求及期待。而且,在Scrum中,其實是鼓勵使用者與開發團隊面對面地坐下來一起合作,以確保開發團隊能了解真正的需求是什麼。但是難就難在有某些時候,連使用者都不知道自己要什麼,甚至是連使用者都不存在(例如開發一個創新功能的App)。這種情況下,Product Owner就肩負了產品規劃的責任。也就是說,Product Owner是使用者的代理人,代表著使用者的需求。他決定了WHAT,並肩負著讓開發團隊了解需求的責任。當開發團隊搞清楚WHAT之後,才能決定HOW-如何把產品做出來。