攻城獅跳火圈

開發團隊

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

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

另外，如果有開發人員之前已經習慣了瀑布式開發的方式，習慣了需求規格書嚴密載明系統規格。這時候，就需要請他們調整一下心態。因為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-如何把產品做出來。