Scrum的缺點 (軟體主管的31堂課)

當手上有榔頭，看到任何東西都像釘子 -- Abraham Maslow 1966
------

過去數年來Scrum明顯成為Agile軟體開發裡最常被討論跟使用的方法。

當然也有不少文章討論scrum的缺點(請參考這裡)。然而，Scrum是個在agile development範疇內的方法論，它是個很好的參考軟體開發流程的工具，而這工具有其「特性」，無所謂好與壞，當然就無所謂優點與缺點。

然而，這些特性不可否認，需要對該工具有一定的認知，特別是一些「預設要知道的事情」，以免誤用。舉例來說，當你使用榔頭的時候，大概會知道它是用來釘釘子，而不是拿來釘螺絲。此外，你也會大概猜到，右手拿榔頭左手扶著釘子時，要記得不要敲到自己的手指。

以下Scrum缺點（特性），也是常見的陷阱僅供參考。

(1) 團隊成員對Scrum的了解必須一致，工作能力最好也要差不多。

Scrum的運作中，高度依賴成員的自主性。Scrum Master雖然很重要，但僅在於Scrum本身的運作。對於任務完成的定義以及任務的品質，還是靠所有成員的能力。

換言之，如果有人技術能力特別糟糕，或者技術能力雖好，但對於Scrum的運用與瞭解和大家都不一樣，那麼有可能會有意想不到的長時間磨合期。

(2) Scrum並不會真正加快速度，只是讓速度透明，讓大家專注重要的事情。

許多企業導入scrum的目的是為了加速產出。事實上，Scrum並不會加快「某件事情的速度」。Scrum會讓事情變得透明，同時也讓團隊進行的速度變透明，讓大家更容易專注於正確的事情上。

整體來說，Scrum會減少各種不必要的浪費，讓整個專案效率提升，但就個別事情的速度而言，Scrum並不會提升。換言之，軟體工程師仍然需要有自己的方式來提升個人效率。

(3) Scrum並不會解決工作內容的相依性 

傳統的專案管理方法論，常常會提供類似甘特圖的工具。然而，Scrum方法論專注於某件任務(story)的完成，而隱含著希望每個任務的相依性，會在團隊成員的「成熟考慮」下被處理完成。

換言之，有相依性的工作就是有相依性的工作，軟體開發團隊還是必須要有自己的方式解決相依性。使用scrum並不表示相依性消失，也並不表示當有個寫得很獨立的story產出時，就一定會跟其他工作無關。這些都還是得靠團隊來處理。無論是使用Jira還是agilefant還是任何工具，都應該有自己的處理相依性的方式。

人手不足？資源永遠都是不夠的 (軟體主管的31堂課)

大部分的情況下，所有研發與軟體主管都會面臨到人手不足的情況，特別是新創企業和快速發展的公司。資源有限，人手不足是必然的「現實」，能夠有效解決此問題也是普通主管和好主管最大的差異之一。解決的方向有三個：(一) 事實是事太多而非人太少。(二) 突破性思考，至少想出解決方案。(三) 必要的犧牲 

---

案例：主管V負責一個長期專案，已經有接近30個工程師是直接由V管理。然而，最近一段期間由於主要客戶的變更，加上CEO的臨時任務，讓這部門的員工疲於奔命。主管V也沒有什麼對策，只好和業務盡量模糊客戶需求以及驗收方式，看能不能減少工程師的工作量。

---

一：真正的事實是：事太多而非人太少

人手不足的真正意涵是「事情太多」。在以人才導向為主的組織裡，人力不足採取的短期策略如果是「增加人力」通常也不會真正解決問題。但如果短期採取「調配人力」也就是說某些事情先不做，有些事情先做，的確是可行的做法。

作為主管的你可能會說：我這些事情都很重要，每一件事情都要做。在營利組織裡，所有事情都很重要根本不可能發生。絕大部分的情況是：主管無法針對事情的優先順序做必要的排序。除非你管理的組織是急診室或者核電廠，不然不可能什麼事都很重要。要做必要的排序表面上很簡單，將事情列一個「優先順序的清單」，從1排到N，數字都不能重複，1就是最重要的事情。實務上，需要主管本身的本職學能判斷以及個人意志力。

二：突破性思考，至少想出幾個不同的解決方案

關於思考問題的框架，請參考這裡和這裡。在此就不重複。

但要提醒的事，在盈利企業裡面，不可能有什麼事情是「只能」這麼做的，一定會有不同的解決方式。問題只在於有沒有想到，還有這樣做效果好不好而已。

三：必要的犧牲 

必要的犧牲並不是指長期加班。長期加班最後通常也是三輸。必要的犧牲指的是幾種可能：
(1) 犧牲不必要的事情，請參見第一段
(2) 極短暫的加班，和長期加班不同，短暫加班是為了解決特定問題，並且要確定能盡快補假，讓團隊成員合理的休息
(3) 縮小範圍，犧牲部分功能
(4) 延長時程，犧牲時間 

然而請謹記，不能犧牲組織重要的長期目標的前進，以及不能犧牲組織文化價值。主管一旦犧牲不該犧牲的事務 （即便是無意間），就表示其領導方式有極大的問題。

陷阱

案例中的主管採取的作法非常糟。會直接踩到許多陷阱。要注意的陷阱是：
(1) 任何情況下降低品質都是飲鴆止渴，很少看到好下場。然而縮小功能範圍(例如MVP的概念)卻常常能夠成功
(2) 滿足政治因素(要和CEO打好關係)而非滿足實際困難，短期雖然可能有效果，但長期通常也不會有好下場
(3) 任何變化仍然要滿足組織整體方向，以此案例來說，必須要了解CEO這些臨時任務和目前專案比較起來何者重要

沒有QA？如何確保軟體開發品質

任何軟體專案或產品，達到高品質是開發團隊必然的目標。不過高品質並非垂手可得，它需要團隊的共識和努力才能達成。

確保品質有很多方式。過去常見的方式是瀑布式開發方式(waterfall)中，在程式設計師確定code complete之後，靠QA/QT/QC(註1)來執行測試，並且在測試週期中，驗證是否符合設計規格，並記錄追蹤問題(bug)，有時候甚且扮演催促修復的角色。因而，特別是大型團隊，專門「處理」品質的QA角色十分重要。很多時候，團隊可能面臨沒有QA的狀態，此時要如何確保品質呢？

為什麼會沒有QA

有時候，環境造就沒有QA的局面。例如，新創公司可能也只有5個人，無法有專責QA。又例如，大型企業中因資源分配不均，導致某些專案無法有專責QA。

但更多時候，沒有QA指的是，沒有能做「真正QA工作」的人。也許團隊裡面有許多人持有QA的職稱。但很可能僅做到QC/QT的工作(註1)。實務上，在軟體開發團隊中，實際做的事情其實比職稱來的重要。就品質的角度而言，QA大部分的時間應該花在開發循環「前期」或者「中期」。以Scrum中的Sprint來說，在kick-off時，QA應該花最多時間在定義DOD，決定產出的評斷標準，在sprint每天活動中，QA應該花時間在檢視產生的程式碼(code review)並且透過每個工作產出，主動改善現有品質。換言之，QA應該比單純的程式設計師，更會程式，更知道系統的交互作用細節，並能透過直接或間接修改程式，直接影響開發過程中的品質。因為，開發前中期的品質修正，效果好，成本低，遠比開發「後期」再來幾個測試循環來的有效！

簡要的說，能真正做QA工作的人，必須能比程式設計師團隊更會寫程式。起碼也要是「曾經」非常會寫程式。

如果團隊不巧沒有這樣的人，有三種方式可以在沒有QA的情況下確保軟體開發的品質：

方式一：Scrum

Scrum方法論中，概念上每個Scrum成員都是「同樣質量」。換言之，Scrum進行中重視的是產出，每個SPRINT的結果是「可交付的東西」。而Sprint中間要完成的細項，應該將品質涵蓋入內，而由自行取得該任務的人，完成其保證。

有許多作法和上面這段熬口的說明有關。首先，DOD (definition of done) 除了涵蓋unit-test之外，其實應該也涵蓋整合測試。如果不涵蓋整合測試，就應該另外有一個任務是專做測試。並且，每個story完成中，必定涵蓋這個story應該要有的使用測試(用以檢驗規格)以及回歸測試(用以檢驗是否有副作用)。這些測試，可以單獨成為一個工作，也可以作為DOD的一部分。

無論如何，基本概念是：「人人應該都可以生產程式碼，當然人人應該都可以測試」。實際執行時，或許有些人比較常「拿到」測試工作，但這並不代表這些成員就只是進行測試而已。有些人比較常拿到「寫程式性質」的工作，但並不代表這些人不負責品質。

Scrum的團隊重視每個Sprint的共同結果，此結構也讓沒有QA也能達到高品質。因此Sprint的長度不能太長，太長就會落入「團隊中自行區分QA和Engineer」的後果。

方式二：Pair Programming

Pair Programming是指兩個人一起用一台電腦，一個鍵盤來共同寫程式。這作法在2000年左右發展的Extreme Programming被大大推崇，不過能有決心推動的團隊並不常見。

由於Pair Programming讓每段程式碼至少都會被兩個人看過，而且在頭腦中想過。它可以避免大部分的低級錯誤(拼錯字)，也可以避免懶人錯誤(程式風格，漏寫unit-test)，然而，更重要的是它讓兩個程式設計師的真實想法，在執行同件事情的時候被「好好溝通」。而這更大幅避免對設計或需求的誤解。

Pair Programming似乎有效率和產能上的疑慮，但無論如何，它確實是在沒有QA的情況下，確保開發品質的絕妙方式。強烈建議閱讀一下wiki上的Pair Programming最下面的參考論文。

注意！

前兩個方式雖然符合敏捷開發的精神，並且能從系統結構層面，解決問題。然而，這兩種方式都必須要有結構性的改變，除非是剛剛成立的新團隊，要造成結構性的改變很困難，而且，即便做的好，也得花上其他心血才能有「能見度」，有能見度，才有所謂的功勞。

有兩個古時候的例子：

(a) 鶡冠子扁鵲：扁鵲曰「長兄最善，中兄次之，扁鵲最為下。」魏文侯曰：「可得聞邪？」扁鵲曰：「長兄於病視神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於閭。若扁鵲者，鑱血脈，投毒藥，副肌膚，閒而名出聞於諸侯。」

(b) 孫子兵法：故善戰者之勝也，無智名，無勇功，故其戰勝不忒。

然而，對於一個軟體專案的主管而言，這些結構性的改變才是自己真正的價值。即便價值很難被衡量，但價值會永遠存在自己的手上。

如果短時間難以改變環境，可以考慮以下的方法三：

方式三：Part-time & Automation

工讀生(part-time student)和自動化測試(automation)似乎是兩個不同主題，但就確保軟體開發品質而言，把他們當做「一件事情」來處理，會有驚人的效果。

簡單的說，就是雇用3至4個優秀的工讀生，每週上班2-3天，組成工讀生團隊，執行測試任務，並且在熟練測試任務之後，開始進行測試自動化撰寫，並且在小組長(team leader)帶領下視情況參與更多品質管理的事情。這聽起來是個繁複的事情，但執行起來，遠比方法一二簡單。

其步驟如下：

(a) 選定一位以後想要朝專案經理或主管方向前進的優秀資深工程師，讓他作為工讀生團隊小組長

(b) 到各大學相關科系徵求大四以上的長期工讀生，一般來說，只要能妥善說明對他們未來就業的好處，通常可以找到足夠優秀的人。工讀生至少需要在職6個月以上。

(c) 組成團隊後，第一個月僅只需要熟悉目前軟體系統，第二個月才開始讓他們執行測試計畫，回報並記錄問題

(d) 在此過程中，由小組長指定測試內容和範圍，換言之，這段期間，其實小組長才是扮演QA的角色。而其他成員都可以將繁瑣的測試交給工讀生。然而，程式的品質仍然是所有成員負責，工讀生不在Scrum的範圍內，因此不「負擔責任」。

(e) 當測試進行2個以上SPRINT，工讀生應該已經開始覺得測試是很煩人的事情，但也應該知道品質對產品的重要性。這和在學校做專案計畫有天壤之別。因此，就可以開始由小組長領導工讀生進行測試自動化。

(f) 測試自動化並不期望把所有整合測試/回歸測試，100%統統自動化。只要把「簡單瑣碎」的測試自動化，通常就能節省一半以上的時間

(g) 通常六個月後，3-4人的工讀生團隊就能完成部分整合測試，和大部分的回歸測試。而下一輪的新工讀生，可以選擇從頭開始打造新的測試自動化，也可以接手前期工讀生做到一半的自動化。打造新的自動化通常可以用新的工具，新的角度來測試既存系統，可以讓品質在一次提高。接手前期工讀生的自動化，可以讓自動化範圍更廣，空出時間來做其他的事情


工讀生進行自動化測試的開發，對組織，對小組長，對工讀生有三贏的效果。(參考：實習生的三贏)

組織：讓沒有QA的團隊，能確保高品質的產出。除了要花些微的工讀費用之外，讓團隊成員能把瑣碎的事情下放給優秀的工讀生，使團隊成員能集中心力，但又同時負責個人生產的品質。同時，由於利用工讀生來培養小組長，讓組織能了解這個資深工程師，適不適合作為領導者，萬一不適合，頂多也是犧牲工讀生而已。

小組長：沒有人生下來就會當主管，當主管必須要有經驗，而工讀生團隊是主管最容易讓資深工程師測試自我的地方。因此小組長可透過這獨立運作的團隊，練習各種管理技能。

工讀生：大部分優秀的大四以上學生，都猜得到業界和學界的差異。許多人可能會在暑假應徵summer intern，然而其實短短兩個月，通常會做比較獨立的專案，雖然都很有趣，但是和在學校有很大的不同。加入實際開發團隊，即便只是做測試，也能了解「現實和學校」的差距，並且體會到軟體專案開發時，品質的重要性。讓有此六個月經驗的工讀生，更容易在未來找到更好的工作。

---

註1：關於Quality Control, Quality Test, Quality Assurance, test engineer, SQA的各種工作角色的區分，請參見wiki。然而，誠如前所述，工作角色名字不重要，做出事情才重要。

快速學習技能 - 解決職場困境

快速學習工作上需要的技能，而技能與知識同時成長，是在職場上能空出時間，進而控制時間的最好方式。

在這世界裡，「在N小時內學會XXX」的書籍研討會不在少數。這些都很有參考價值，然而，學習是非常「個人化」的事情。例如：國高中花很多時間在補習班的學生不在少數，但真能夠發揮補習的目的 - 也就是考上最好的學校 - 卻僅有少數。

有些書籍，宣稱找到共通的方式可以在N小時內，學習「任何」技能。並且當然以自己過去一年學習到的技能，作為鐵 證 (參考文末的註1)。不過，共通的方法都僅能參考，每個人終究都還是需要找到自己的方式 - 只要是真的想學。

在職場工作，會遇到的困境很多，有很大一部分是「人」的問題。但無論哪種問題，如果你是個「技術上的狠角色」，你就有很大的機會撇除人的問題。即使無法排除，擁有更多技能，就表示有更多選擇 - 大不了就是離開現在的環境。

技能的快速學習，首要之務，應該是找到自己的方法。

在還沒找到之前，或者，自己現有的方法似乎有所侷限。倒是可以考慮以低成本的方式，嘗試一下各個企業巫醫所提供的方式。

重點在於：有方法遠比沒方法好！

以下是幾個常見共通步驟與確切花費時間：

(1) 原因與目標確立

不知為何而戰，當然容易半途而廢。

有些原因很清楚，例如：目前會寫java，而現在因為工作需要學習Scala。有些是個人喜好，例如：常喜歡去日本旅行，想學基本對話比較方便。有些則是好奇性質，例如：聽說Big Data大數據分析很紅？不知道到底是那是什麼。有些技術是「執照類型」：例如開怪手，駕駛遊艇。

無論是哪種原因，需要一個簡單的目標，例如：學會Scala，了解Big Data，學會日文會話，學開船等等

不應該花太多時間在目標確立，最多0.5小時。

(2) 階段性成果確立

長期預測是很難，而且接近不可能。因此，快速而踏實的方式是計畫階段性成果。

階段性成果指的是一個「可以衡量的」，「有意義的」，「可展現的」，「務實的」極短期目標。

所謂極短期，是指20小時之內：也就是禮拜一到禮拜五，每天2小時，連續兩週。

這並不是指，超過20小時就是太多，也非20小時就能夠變成專家。而是必須要讓自己在20小時內「有所成果」。

舉一些例子如下：

Scala：撰寫網路爬蟲程式，可針對wiki做特定字串資料檢索和統計。

日文會話：用日文會話辦理飯店check-in，詢問餐廳資訊和找路。

Big Data大數據：選擇並且看完三本大數據的科普書籍。

學開船：考取動力小船執照。


階段性成果的確立，其實和每個人對該技能瞭解程度的不同而有所有不同。了解的越淺，就會訂出越模糊的階段性成果。但其實無妨。因為這只是第一階段的成果而已。

其實，要能確立階段性成果，某種程度已經完成一個小型計畫。計劃本身是死的，「做計劃」這件事情才是重點。這個階段應該花費3-4小時的時間。

(3) 找到練習與取得知識的方式

取得知識和練習的方式非常重要。這方式必須要同時符合「階段性成果」和「目標」。

要快速學習知識和技能，必須「專心花一點時間」得先找確切練習方式，取得知識材料，和額外獲得協助的地方。

取得知識最踏實而且快速的方式，其實還是圖書館。先考慮，或者試用一下圖書館堆書法(參考這裡)。

然而，許多技能是需要練習的。例如：寫程式，學日文，Linux操作等等，就需要找到最適合自己的練習方式。

以學會寫Scala程式而言：即便只是做個簡單的網路爬蟲，仍要再細分小階段，先準備環境，簡單了解語法，知道怎麼使用Scala來執行http get...等等。每個練習的動作，都是為了達到階段目標。

以學日文會話而言：最好而且便宜的方式應該是「馬上去找」語言交換。其次則是去借幾本基本會話的書，再加上幾個app/網站。(註2)

當然，有些技能最簡要的方式，還是花錢受訓，例如「動力小船駕駛」。這反倒是最簡單的，只要有決心即可。

除了花錢受訓之外，這階段恐怕需要額外的時間，預計6小時是合理的。


步驟(1)到(3)，最好是不要花超過8小時，也就是一個假日的時間。

(4) 練習與取得知識

這一階段的重點在於「專注」。如果計畫是兩個星期，共計20小時，則這時候，就該專注於自己決定的方式，無論如何，都要在兩星期/20小時之後來檢視成果。

這也是為什麼，設定階段性成果時間不能太長(註3)。

如果的目標過於抽象，例如要「瞭解什麼是Big Data」，在這段練習與取得知識的過程，就會變得更加含糊不清。以因此，階段性目標才會設定成「看完三本科普書籍」，這樣才能檢視成果。

要讓自己專注的方式有很多：短時間專注可用番茄工作法。長時間則需要計畫與經驗，而目前你在看的這篇文章，實務上就是在解釋，如何將學習技能知識時間專注於學習。

在這個階段，根據計畫的不同有不同的時間。但是切記「越短越好」。如果不確定時間長短，那就以10個小時，每天2小時為準。

(5) 自我評量

必須要有客觀方式自我評量。

因為是自我評量，當然一定要確實。

以學習Scale的第一階段：完成網路爬蟲為例，如果在20小時內完成，那麼就可以有信心的說學習Scale已經前進很多。

以學習日文會話來說：如果可以和日本人測試對談飯店用語，那就表示階段性成功。

再次強調：快速學習技能的階段性成果，必須要以務實為主。許多人在學日文一開始是以背熟50音為第一階段。但這其實不太務實。因為死背永遠是無聊的，而且即便你可以把50因背得滾瓜爛熟，在日文能力 - 特別是會話 - 的務實進展也等於零。

(6) 收成：前進或者換目標

達到目標後，請隨意犒賞自己。

而接下來，就是要決定往下一個階段前進，或者更換目標。

這時候的更換目標，並不是半途而廢，畢竟你已經前進了一段務實的路。這和達不到目的而放棄，無論在心態上，還是事實上都有很大的不同。

往前進的時候，記得也是重複設定一個「短期可達到」的務實目標。

例如：

學習scala，已經完成網路爬蟲程式，接下來的目標是在Spark中，以scala撰寫一個可分析http log的分散式程式。

瞭解Big Data大數據：已經看了三本書，接下來的目標是找一個有意義的主題，寫一篇部落格文章。

這樣的快速學習，真的能解決困境嗎？

快速學習能讓你在職場上，取得更多的「選擇性」，讓你對事物有所掌控。這才是針對困境的真正解決之道。

或者也可以跟我們聯繫取得困境的快速協助。

---

註1: 有幾個例子

   * Fluent in 3 Months: 三個月內可以流利的學會任何語言。作者甚至示範了中文學習，對外國人來說，學非拼音文字真的難為了他們。

   * The First 20 Hours: How to Learn Anything FAST. 作者示範了如何快速學會各類不一樣的技能：瑜伽，寫程式，風帆板，圍棋...但個人覺得比較難以置信的還是「新鍵盤佈置：colemak 」

   * The 4-hours 系列：作者Tim Ferriss寫的幾本書。內容從健身到創業都有，其中都會涵蓋快速學習的方式。

註2: 請參考Fluent in 3 Months 一書

註3: 當然如果你是想考動力小船執照，由於上課時間是固定，當然沒辦法「更快」。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

Scrum - 團隊中永遠的反對黨

最近被問到的幾個問題：

   - 怎麼聚焦討論，譬如說有人很愛插話，或者有人很愛在會議室角落另開討論群，或者有人非常堅持己見，很愛先否決對方 ...

   - 有遇過非常固執的人，總是以否定句開頭去否定對方嗎 ？

   - 有人固執的反對什麼事情都反對

....


以Scrum/agile方法為核心的團隊有先天上的「平等」和「自發」的假設。Scrum假設人人都有某種能力，並且也假設，團隊成員對於「溝通」都有某種程度的共識和經驗。

然而，實際情況通常不太美好。

** 技術人員常常會因為麻煩，而反對業務上的決定
** 業務人員因為對技術不了解而作出自相矛盾的決定
** 開會時候常常岔開話題
** 因為不專心，很多人在開會時候搞不清楚情況
** 某些人常常提很多意見，而且實在太多意見！

任何由人組成的團隊，多少都有溝通問題。如果你是團隊領導者，或者Scrum Master，溝通問題一定是你必須要負責的問題！

Scrum溝通問題，就像處理bug一樣，最好的解決方式是「事先解決」。有三個基本共識必須要事先建立。

建立這三個基本共識，可以讓未來的溝通變得簡單清晰，減少不必要的誤會。

(1) 建立雞與豬的基本共識

專案管理中的「負責角色」有各種說法。RACI可能是近年最常見的。

** 負責人（R = Responsible），負責執行 
** 誰批准（A = Accountable），對任務負全責的角色，通常是負責人的老闆 
** 顧問（C = Consulted），提供意見或建議的人 
** 通知誰（I = Informed），被通知結果的人，例如其他部門的相關人等 

在Scrum專案中，可以被簡化成兩種人：雞和豬。(雞與豬的故事可以在網路上找到很多版本，例如這裡)


豬：負責做的人也是負全責的人

雞：所有其他人（當然必須是和這個專案有關的人）

在溝通時，所有雞都可以出意見，但是豬一定擁有真正決定權。畢竟是豬被切肉出來做火腿，雞只要下蛋而已。

就平等的軟體開發Scrum而言，任務是有自己選取。但是就實務上，專案管理者不但身兼Scrum Master可能還會身兼分配任務的角色。這時候，等於是分配「誰是豬」！

任何會議上，對「豬」的正面或負面意見都可以討論，但是最終決定必須要是「豬」。

例如，PM決定哪個功能要先做，而工程師都反對，原因是嫌未來會有其他麻煩的事情產生。然而，就決定功能的先後次序來說，「PM就是那隻豬」而其他所有人「都是雞」。

團隊必須要有清楚的認知，才不會有無謂的抱怨和繁瑣的溝通。而清楚的認知，是團隊領導者的任務。

 (2) 建立事實優先的基本共識

Scrum溝通，必須，而且只能，建立在事實上。

這也是為什麼每日例行會議只說明三件事情：哪些工作完成，接下來做哪些，遇到什麼問題。

假設有人在某討論會議中說「現在UI速度很慢，登入要等很久」。某種程度來說，可能是事實。但是，「慢」以及「等很久」，都只是形容詞，必須要請他提出何謂慢，什麼叫做等很久才能繼續有意義的討論。

或者，有人提出「如果先做A會讓之後變得很麻煩，應該要先做B」。這其實也是模糊的說法，A和B這兩個功能，如果先做A是會讓以後時程延後8小時？還是8天？還是8個月？這才是根據事實的討論。

然而，這種建立於事實的共識，Scrum Master必須要不厭其煩的提醒和導正，才能建立這種共識。

(3) 建立產出優先的基本共識

大部分的專案，都是需要產出某些東西。無論這個東西是軟體，或者硬體，或者某些解決方案。

在團隊討論中，要讓「為反對而反對」的人閉嘴的最佳方式，就是以「產出優先」而不是以「嘴巴講」優先。

例如，某工程師強烈反對A做法，希望改用B做法。最好的方式就是請這個工程師，作出他自己希望的A做法，用以和B做法比較。如果他說「沒空」或者是有「更重要的事情在做」，那表示他的強烈反對，也不是那麼強烈。

至於對於「只反對而不提出取代方案」的人，其意見大概也只是僅供參考。如果經過負責的豬判斷，其意見很好，當然可以欣然接受，加以改進（例如在code review的時候）。





如果尚未建立這三個共識。就已經發生溝通問題。團隊領導者或者Scrum Master仍然有彌補的方式。

不過，越早了解，並試圖解決溝通問題，通常成本越低。

那麼可能的解決方法有：

(1) 自己的問題？

如果你是一個領導5人以上的團隊領袖，無論你的名稱是Scrum Master還是專案經理，如果你認為團隊裡「大部分的人」都有溝通上的問題。

那麼真正有問題的人是你！！

但是也不要太緊張。這並不代表你是個無能的領導者。只是你的實際行為，讓團隊容易產生溝通問題。

問題的產生點可能是：

(a) 試圖面面俱到，顧及每個人的感受，而非先考慮事實。每個人都喜歡受人愛戴，但是在軟體開發團隊中，鄉愿和受人愛戴只有一線之隔。唯有根據事實，腳踏實地領導事情的進展，才是長久之道。為了顧全少數人的面子，或者僅為了顧及某一兩個老是抱怨東抱怨西的人的心情，對團隊從來都不會有好處，反而只會讓多數沉默工作者更難獲得信任


(b) 未掌握Scrum精神，只是掌握Scrum的作法。請參考這裡。

(c) 其他，請參考：作為技術領導者的方式。

(2) 解決老鼠屎

如果團隊之中，溝通問題老是產生於某個人。

除非此人是像高斯，愛因斯坦之類的天才中的天才，否則不應該容許有嚴重溝通問題的人存在於團隊。

這類型人有幾種表徵：

(a) 無論什麼事情都悲觀 
(b) 事情不分大小時常抱怨 
(c) 問題都是別人的錯  
(d) 常認為自己懷才不遇
(e) 不願意做某些無聊的雜物

其實，每個人或多或少都會抱怨，也會有悲觀的時候。此乃人之常情。但是如果非常嚴重，那麼這個人就會變成鍋子裡的老鼠屎。只要鍋裡面有一顆屎，即使被稀釋了幾萬倍，也不會有人想吃那鍋飯。團隊也是如此，一個負面老鼠屎，其影響範圍遠超過5個好隊友。

老鼠屎不見得就是錯的，他或許自己創業會變成一個好創業家。因此，及早讓不適合目前至個團隊生活的人離開對大家都有好處。

(3) 縮小範圍

當溝通問題發生，可以將重要的溝通，盡可能縮小範圍，讓溝通清楚簡單。

這聽起來是淺白無聊。但是，實際上在團隊之中，太多無聊的溝通錯誤發生，以致於這麼簡單的事情，仍然值得注意。

以Scrum而言：「DOD」什麼是完成，乃是基本的問題。即便團隊已經彼此合作過一段時間，仍然三不五時要確定一下什麼叫完成。

以溝通進度而言，必然將最近在做的事情，縮小其範圍到「最近的一個完成點」。 無法縮小表示根本不知道自己在做什麼。舉例來說，軟體開發中，如果有一個人的某A任務，需要20個工作天，那麼在3天的進度報告，絕對不能聽到「還有17天就完成」，而是要縮小範圍到：「下一個milestone會是明天，而預期也會如期完成」。因為，最近的一個檢查點(milestone) 如果不能如期完成，就代表未來的17天，很有可能也不會如期完成。反過來說，最近的一個milestone會完成，那麼未來就比較有可能如期完成。

縮小範圍也可以讓「雞和豬」的責任範圍展示的更清楚。

有個真實的案例：有個團隊舉辦慶功宴，由甲和乙兩位負責。甲很熱心的定好了餐廳，並且就「自認為剩下的事情乙會處理」，然而乙心理認為，既然甲定了餐廳，表示後續的小事情甲也會處理，畢竟許多事情和餐廳有關係。那麼到了慶功宴當天，當然除了餐廳定好之外，其他的雜物(例如當天如何報帳之類)一件都沒完成。

另一個真實的案例：有個軟體開發專案，大家都認為某甲的程式需要重構(refactorying)。但是，某甲認為他需要4周才能完成，因此遲遲不肯進行，大家也難以和某甲溝通。專案經理於是縮小範圍，先找某甲也認為很小規模的一個功能-原本預計一天-加以重構，透過pair-programming，確定某甲專注於這個任務上，最後只花了1小時。因為有這樣的證明，專案經理於是要求某甲先完成全部程式碼翻修，最後整體只花了2天就完成，雖然仍是麻煩事，但遠比某甲估計的4周來的快太多。其原因也很簡單，重構是繁瑣麻煩的事情，當然會被估計成很長的時間。

Scrum - 檢討完了...然後呢？

定時檢視目前的進度與問題，是所有專案管理都會做的事情。Scrum方法會在每個Sprint之後，舉行檢討會議(驗屍會議)，找到在過去一段時間最需要改善的事項。

請參考前篇：Scrum - 回顧。檢討？驗屍！

假設團隊依照正確的Scrum的事實認定原則，踏實的列出問題。接下來就應該「解決」它。誠如前篇，所有的問題必須要有歸屬「某人」。某些事情是「很多人」或者「不知道什麼人」，這種情況的歸屬就屬於Scrum Master。

稍微強調一下，只要Scrum Master稍微不注意，就會讓歸屬人這件事情變成互相指責，試圖鞭屍，對人不對事的謾罵。但是，如果不試圖歸屬某人，就常會讓問題懸空，無法真正解決。

只要確切的定義真正的問題，就等於是產生了一半的解決方法。

不過有些常見老問題，還是值得探索一下。

例如：

(1) PM/PO 常常在Sprint中間要求修改規格，甚至新增額外的項目...

(2) 某個人的產出和績效，明顯的比其他人差很多...

(3) 某個功能的實際時程遠超過預估，以至於某些團隊成員需要很大幅度的加班...

而常見問題都有其共通性，常見的試圖解決方法也有共通性。然而，以Scrum而言，Scrum Master在此扮演非常重要的角色，因為所有的問題，其有效解決方式，應該都和Scrum Master本身有關。

Scrum Master必須要掌握以下原則：

原則一：試圖做到完美是不可能

    完美的team不可能存在，每次sprint應該試圖解決最重要的幾個問題就好。

原則二：持續做同樣的事情，不可能產生一樣的結果

    參考愛因斯坦的名言：Insanity: doing the same thing over and over again and expecting different results.

原則三：任何創意方式都應該嘗試：包括「無作為」

    
    當定義好問題之後，下一個sprint應該要試圖改善問題。但是，改善問題的本身有時候需要「時間」，而由於Scrum每個sprint都只有4週，Scrum Master應該要將「無作為」當作某些問題的處理選項。畢竟，有時候過度反應某個未來可能不存在的問題，也沒太大意義。

但是也請謹慎區分「無作為」和「逃避」，這兩者只有一線之隔(註1)。
    

針對身為Scrum Master的人，在此提供一些解決問題的範例：

(1) 時間相關的問題

由於時間是軟體專案衡量進度的唯一單位。時間是最初，也是最後要考慮的事情。因此許多檢討事項都和「時間」有莫大關係。

--- 在Sprint中某些時間估計錯誤，導致加班 ---

這在專案前幾的sprint特別常發生。建議解決方式有：

(a) 探詢真正的需求點和重要的事情，移除根本不重要的工作事項

(b) 減低時間浪費，特別是大型專案中開會的時間

(c) 無作為：因為團隊已經了解問題，而且下個sprint估算也應該會比較正確，加班問題很可能自然消失。

(d) 厲行「最大時間」單位，假設是1天。換言之，工作項目超過1天，就需要分拆成不同的項目，或者不同的完成階段。這樣可以在比較短的時間內，很快發覺時間錯估的規模。


絕對不建議解決的方式是：讓某些人繼續加班；犧牲品質；謊報進度...

--- 某個人的事情老是做不完 ---

這個也很常發生。如果是該員能力無法趕上團隊。似乎是個很大的問題。然而，絕大部分的團隊都應該利用分工導致的比較利益法則（參考這篇），根據相對優勢來分工。

細節請參見下一節：(2)人才和人力的問題


建議解決方式有：

(a) 先確定他不是不想做。假設有個不想在這個團隊努力的人，無論再怎麼調整，也都沒有意義。應該用最快的方式讓他好好離開。

(b) 讓他做可以用時間苦勞換取績效的工作，而非需要能力才拿達成的工作 ，例如將其人力保留用於意外任務或者PM臨時修改需求 

(c) 找到他的相對優勢，換言之，Scrum Master要略為調整scrum的精神，改以指派的方式指定工作。但這點需要觀察並且徹底了解他的優勢才有辦法執行。

--- 團隊有意外任務 ---

這個問題也很常見，可能的解決方式有

(a) 無作為：經過一番思考，發現這只是意外，下個sprint應該不會發生

(b) 根據前sprint所耗在意外任務的時間，重新估計下個Sprint意外任務要花的時間

(c)  設定意外任務防火牆：可以找一個專門的人，處理所有意外任務。不得已的時候也可以找工讀生，委外人員等等。

(2) 人才與人力的問題

許多軟體開發的相關研究，都一再顯示，一個好的設計師和普通的程式設計師的績效相差很大。某些1980-1990之間的研究認為可能差距10倍，當然這個10倍厲害的程式設計師的爭論很多(註2)。但就一般的情況來說，超過5個人的團隊，就自然而言有人能力以及產出比較好，而有可能有某人能力和產出都比較差。

一個團隊裡，人力和人才必須要平衡，並且由Scrum Master在前幾個sprint的結果瞭解哪些是人力，哪些是人才。人力和人才的衡量標準在於「產出」而不在於「個人能力」。換言之，即便大家都認為他能力很好，但是某些原因，他的產出只有一般般，那麼他就不是人才，而是人力。

但是，無論是人才還是人力，團隊的組合的先決條件就是1+1>2，團隊合作可以讓整個團隊獲利。Scrum Master在發現團隊有某些人的績效和產出問題時，應該優先考慮分配工作上的比較利益法則。（台灣經濟學的入門書通常會用蓋木屋與磚屋的例子：參見這裡）

要注意的是，過於追求表面上的公平，但是反而會團隊績效的降低。公平雖然重要，但是團隊合作產生的獲利更為重要。Scrum Master要能讓團隊追求團隊目標，而非追求個人公平。其方法有：

(a) 讓團隊成員看這篇文章

(b) 不要設定表面的績效衡量標準(例如：bug數量) 而是設定每個人不同的標準

(c) 所有不同的標準，朝向同一個目標。例如，在籃球比賽中，得分籃板助攻失誤阻攻...等等都是指標，而所有指標必須都要朝向球隊勝利才有意義。而不應該對每個球員設定同樣的目標。

(3) 目標的問題

目標指的是現在要做什麼，現在什麼事最重要，要達到什麼效果...簡單的說，每個專案都有其最終目標，但是在專案開發過程中，都有中間目標，PM/PO理論上應該會透過各類型中間的目標，達到（也有可能會修正）最後的目標。

然而，Scrum為了讓開發人員專注於工作，在一段短時間的Sprint是不允許修改目標。因此，如果遇到PM中間亂入，常常會造成團隊困擾。

但其實更為重要的是，如果團隊方向具有很大的不確定性，Scrum Master應該視其為「機會」，而非「威脅」。因為Scrum的天生優勢就是在於處理不確定性。

--- PM客戶或其他長官常常突然要求修改做的一半的規格---

(a) 無作為：因為這可能是專案開始的意外插曲，Scrum Master很確定下個sprint不會發生

(b) Scrum Master作為擋箭牌。在Sprint中間過程，用盡一切手腕，擋住所有需求修改，直到sprint結束為止。但是，允許PM重新開始一個sprint。

(c) 找個專門窗口作為擋箭牌。指定一個專門「被聯繫」的擋箭牌，將擋下需求，或者臨時修改需求這件事情是為他的工作項目。但是他所完成的程式碼，放在另一個branch(分支中)，每個sprint結束之後，才檢討他的branch是否要合併。這個做法的依據在於，通常會修改的規格，都會被一改再改，與其影響團隊作業，不如將影響範圍降到最低。

--- Sprint產出PM不喜歡或不要了 那我們不是白做 ---

這樣的抱怨也很常見，它不是問題，而是Scrum天生所展示的優勢。Scrum Master只要解釋幾點Scrum基本概念即可：

(a) 我們頂多白做4個禮拜，如果是project結束才發現這件事情？那浪費的成本是高得嚇人。

(b) 如果是PM不喜歡，那麼起碼我們會了解什麼地方他不喜歡。如果他「不要了」表示這是PM在產品需求判斷上的錯誤，在檢討會議應該要求PM改善此項目。



如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com。我們會持續修改這篇文章。

---

註1：許多事情好與壞都只有一抹微妙的界線。除了「無作為」和「逃避」之外，還有「足夠自信」vs 「自我感覺良好」；「自卑」vs「謙虛」...

註2：請參見這裡

註3：如果有其他常見問題在這裡沒有獲得解答？也請用email與我們聯繫 support@talent-service.com

Scrum - 回顧。檢討？驗屍！

在Scrum方法中，每個Sprint結束要做事情是(1)實際交付產出 (2) 回顧檢討這個Sprint (3) 決定下個Sprint的開始。

其中，回顧檢討這個Sprint的做法，通常是一個2-4小時的Retrospective Meeting(回顧會議)，再加上改善動作。


實務上，回顧檢討是sprint最難做得好的項目。


困難因素在於，人類有天生的認知謬誤。回顧檢討會議既然是人來召開，人來組成，當然很難確切找到此Sprint的需要改善的問題，並對症下藥。偏偏，絕大多數專案Sprint問題和人有關。

說得更直白的：

    - 所有專案團隊的主要關鍵問題，都跟人有絕對的關係。每個sprint檢討會議不去檢討「人」，就等於是兇殺案發生而不去驗屍一樣。

    - 所有未來改善項目，其改善效果和速度，也都和人有絕對關係。

Scrum基本作法

在大部分的Scrum教學材料中(註1)，都很輕而易舉地說，團隊要在回顧檢討會議說，瞭解並討論三個項目：

(a) 這個sprint哪些地方團隊做得很好

(b) 這個sprint哪些地方團隊做得不好

(c) 下個sprint 團隊要做哪些事情使其變得更好



許多Scrum教學中，回顧會議都用一些簡單的方式：例如每個人提出3個意見，然後由Scrum Master逐一唸出，並且分類意見，接下來針對分過類型的意見投票，投完票之後再指定人選負責在下一個Sprint中改善。這個方式當然可以消除不少偏見和謬誤，但是容易忽略了「改善是需要針對人的行為而非針對事情」。


舉個某回顧會議中，團隊認為最需要改善的問題：

* 需求在sprint開始時還沒確定

這是個極為常見的sprint回顧問題，也通常是軟體團隊的困難。Scrum方法雖然試圖避免這個困難，但是還是非常容易在回顧會議中被提出來。筆者常看到會議記錄中，天真且單純的紀錄這一條問題....然後？也只是記錄而已。


這個紀錄有什麼問題？  ....有很大的問題！


大部分團隊，剛組成的時候，其Sprint檢討會議中，會不自由主的「避免」提出直接針對「某些人」的能力，做法，產出的問題。團隊會因為想要「努力團結」而避免針對人的討論。然而，除了超短期專案外，所有軟體專案，幾乎不可能「沒有人的問題」。反過來說，解決重要的人的問題，專案就會執行得更好。

回顧檢討要注重「人的問題」，並非單指某個人的能力不夠，也非某些人難以溝通。而是要透過實際的事物，探究人的行為造成的問題，而非問題的本身。「需求在sprint開始時還沒確定」是個血淋淋的事實。

但是，回顧檢討的重點在於，過去4周內，到底團隊成員知道是「誰做了什麼，或者沒做了什麼造成這個事實」，這才是重點。

正確的回顧檢討事實，可以是：


* 需求在sprint開始時還沒確定，因為Scrum Master沒有邀請Product Owner參加kick-off會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在kick-off會議沒講清楚，而團隊當時卻認為自己清楚需求，直到開始做了才發現不清楚，偏偏Product Owner之後就不參加每日例行會議。

也可以是：

*  需求在sprint開始時還沒確定，因為Product Owner在專案中間需求有改變，但是Scrum Master並未注意到大幅變更。

無論哪種回顧，都需要有「人」，「當時做的事情或這沒做的事情」，「產生的結果或沒產生的結果」。這樣的回顧檢討才會有意義。

但是，Scrum的方法論，看起來都是對事不對人。要如何在不交互指責的憤怒會議中，做到針對人的檢討，並能在下個Sprint還能持續團結合作？

如果你是專案經理或者Scrum Master，有三個基本的關鍵作法可供參考。(1) 先個人，再團隊。只內部，無外部。(2)  沒有問題，是最可怕的問題 。(3)實際事實，實際行為優先。

(1) 先個人，再團隊。只內部，無外部。

在會議開始之前幾天，先通知大家，回顧檢討會議的重點：先檢討自己，再檢討團隊，只檢討團隊內，不檢討團隊外。

(a) 先檢討自己的「行為」，再檢討團隊的「行為」。

並非要檢討個人的價值觀。例如，是不是很認真，很願意和其他人溝通...等等。而是自己先看自己過去做的「行為事實」，有什麼可以改善的地方。

例如：完成某功能程式碼之後，沒有先執行整合測試，就在某天每日會議報告已經完成，隔天發現，該功能有很多問題，還得修正進度，並且讓測試人員額外進行rollback。

另一個例子：這次sprint開始的時候，Scrum Master沒有堅持要Product Owner確定所有要完成的項目的需求，就讓Sprint展開。使得Sprint需要額外需求確認時間。

檢討團隊的行為，也和個人一樣。稍微不一樣的是，團隊行為通常是「個人行為」的組合。換言之，以「沒有人」為開頭的陳述就是團隊行為。Scrum Master或者專案經理，或者實際決定事情的主管，要特別注意，絕大部分的「沒有人」開頭的陳述，就要當作「自己」！

例如：沒有人發現在第二週自動測試的伺服器當機，連續好幾天的測試報告都沒有自動email出來，以至於團隊錯失及早修復bug的時間。

另一個例：沒有人提醒Product Owner開會的時間。

(b) 只檢討團隊內，不檢討團隊外

Scrum對於團隊有很嚴格的定義：做事情的人+Scrum Master = 團隊成員。

回顧檢討會議，必須要檢討內部，而不是檢討外部。許多檢討會議看似檢討內部，但其實是在檢討外部。

例如：加強和UX/UI部門溝通

這通常隱含對方不好溝通，我們只好努力跟他溝通。

又例如：公司有臨時交辦事項，團隊得分心處理

這隱含是更高階主管來的非專案任務，需要打斷專案時間。

這兩個例子並非不要改善。而是檢討回顧方式，會大幅「限制」或影響改善方式。與其他部門溝通問題，應該是具體列出過去4週，那些確切事情「被誤解」或者「理解錯誤」。根據實際的錯誤，來改變團隊對應的方法。

以UX/UI而言，釐清理解錯誤，可以用「雙方討論事情的時候，一定要至少要有mock-up」。

而以公司有臨時交辦事項為例。應該是「每個sprint預設的工作時間原本是160小時，下個sprint改為145小時，因為上個sprint臨時交辦非專案任務大約15小時」。這樣是以具體的事實，解決公司有臨時交辦事情的問題。

重點是：解決問題必須在「團隊內部能做的行為」，而非「希望團隊外去做的事情」。

會不會有回顧檢討的問題是「團隊內部解決不了」的事情？的確有可能，但是機率很低。團隊解決不了的事情，早就在sprint kick-off (開始會議)被隱含排除，所有團隊「認知到」的專案問題，幾乎都是團隊內部有方式解決或減少影響的。

(2) 沒有問題，是最可怕的問題。

有為數不少的專案團隊，在回顧檢討會議時，因為很多因素，無話可說。只好拿一些雞毛蒜皮的小事，或者看似重要但是不太重要的事情敷衍一下。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的。
* 我們的螢幕太小，寫code很不方便。
* 每天站著會議好累，可不可以坐著
* 能不能有免費可樂
* 昨天code view有說code style要統一但是還沒有
* 我們可以固定一段時間來分享一下大家coding的心得

如果檢討會議的重要事項，全都是這類型的，那有三種可能(註3)：

(A) 團隊有如NBA夢幻一隊素質極高，工作合作超級愉快，成果驚人。

(B) 團隊失去對專案的信心和動力，或根本不相信Scrum Master。

(C) 團隊絕大部分的成員經歷太淺，不知如何開始檢討。



--- (A) ---

如果你認為你現在的團隊是A，大概有49.99%的機會你是在欺騙別人。另外有49.99%的機會是你自己騙自己，或被別人騙。


--- (B) ---

如果你認為你所處的團隊是B，而你恰好是Scrum Master，或者是專案經理，或者任何領導階層。那你最最需要做的事情是「檢討改善自己」，而非「檢討改善別人」。一個團隊，大部分的人不願意說真話，最有可能有問題的一定是管理階層。

如果你認為你所處的團隊是B，而你非管理階層，也非Scrum Master。你可以先審視自己專案對社會的重要性。如果你是在核電廠，或者急診室，那你應該盡自己一切的可能，不計代價，不眠不休地改善現況。

然而，如果只是一般的軟體專案，建議你先就自己可以改善的地方檢討自己。確定當你看到不正確的事情時，會先審視自己的能力與做法。但也不需要強出頭，把自己當作革命烈士。畢竟，大部分的軟體專案並不是那麼重要。


--- (C) ---

這種情況似乎也常發生，但是解決方法很簡單。

首先Scrum Master應該在第一時間對於「雞毛蒜皮小事」，做立刻回應。對於每個小事的回應都是：下次不用等到sprint結束，中間任何時候都可以馬上找我講。這樣才會讓團隊成員養成自動自發，並容易判斷哪些事情很不重要。

例如：

* 每週固定的下午茶太不健康，看能不能換健康一點的

...可以，馬上就換。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 每天站著會議好累，可不可以坐著

...不行，因為站立會議的目的就是要讓你累。以後想到這類型問題，不用等到sprint結束，任何時候馬上跟我反應。

* 能不能有免費可樂

...可以，你馬上去買，發票給我。以後一遇到這種問題，不用等到sprint結束，任何時候馬上跟我說或者寫信給我。

* 我們可以固定一段時間來分享一下大家coding的心得

...可以，你馬上去發固定會議通知時間。以後一遇到技術分享的事情，只要不影響sprint時間，任何時候就直接去做，不用等到sprint結束。

(3) 實際事實，實際行為優先

Scrum的精神在實況與事實，而檢討的實況和事實在於「行為」而不在於「想法」或者「內心深處的感覺」或者「價值觀」。

這個概念非常重要。缺乏了這個概念，就容易讓檢討回顧會議，變成「互相責怪」會議。

然而，執行也很重要，執行不當，也會讓回顧檢討會議變成「互相責怪」會議。

首先會議一開始Scrum Master一定要強調，接下來的會議以事實優先，而事實當然是根據某人做的事情。在團隊成員互相不熟悉的情況下，要「反覆」的重述事實優先。並且在討論時，嚴守只看事實的承諾。

會議的形式此時就不太重要，不過：點名發表意見是個簡單的好方法。當然Scrum Master應該要自我拋磚引玉一下。

以下舉幾個常見例子：

成員J說：PM常常來叫我們改東改西，為什麼之前不確定好需求。

這時候Scrum Master應該列出這個sprint完成的task。追尋到底哪些task的需求被改變，大約影響了多少工作小時。
當然成員可能會說他不記得，就請他大致猜測一下。然後再跟sprint的時間做比對。如果改動所花時間很少，那其實不是問題。如果改動時間比率很高，才是值得關注的問題。值不值得處理，要看比率原則。-- (註4)

成員A說：我覺得我的task太多，都做不完。

這時候Scrum Master應該立刻請成員A把過去一個sprint做完的Task列出，看看是不是有做完，並且完成這些task是否有加班，或者，其實他的task是由別人完成，但是每日站立會議中並沒有說明？總之，現場應該了解事實，而事實也一定能被了解，不能等到「之後」。因為每個Sprint只檢討這個sprint，也就是過去4周左右，不可能需要很長的時間了解事實，也不可能有「我現在忘了要回去找一下」

成員K說：負責前端的人的bug太多，有時候負責後端的人都得幫忙修復bug。

這時候，Scrum Master應該立即根據bug清單，看看前端的bug數量，和負責解決bug的人。假設前端bug數量在過去sprint中有100個，而99個bug是由前端的人解決，有1個是後端的人幫忙解決，而且也只花了1小時。那麼這個問題根本不成立。只是因為後端開發伺服器的人，會特別記得「例外事件」就會有別人bug多太多害我多花時間的印象。這事情比例上多寡，是不是值得處理就要看「實際情況」列出判斷。一旦列出來給團隊成員看，就很容易大家一起判斷。

成員F：我coding速度是沒很快，但是有些速度更慢的人，就完成比較少的task，好像不太公平。

這時候Scrum Master應該根據git或其他版本控制系統，列出團隊成員程式碼數量。配合完成的task數量，bug產生數量(表示code品質不好) 以及bug解決數量(表示解決的問題)大約比對一下，看看團隊的產出是否「差不多」。當然，不同的作業系統，不同的平台，不同的程式語言是不能這樣比較。

不過大部分的情況下，這個問題並不會被提出來。但是，這個問題會存在在壓力比較大的團隊成員中，並且有礙於團隊成長。因此，Scrum Master自己必須要有客觀的衡量產出的方式！即便沒有人提出這個問題。

成員L：我們對所使用的open source工具不太了解，導致於需要學習的時間。

由於這個問題很具體，Scrum Master只需要確定這件事情是否還存在。下個sprint還會不會有不熟悉的工具需要使用。

後續？

 Retrospective檢討回顧會議中，如果找到重要的事項應該要改善。當然就是Scrum Master或者管理階層需要去「執行改善」的時候。前述內容都只有「找到問題」而關於如何有創意的解決問題，還請參閱後續文章。

---

註1：網路上參考資料非常多，例如：這裡，這裡 或者 這裡

註2：專案驗屍(postmortem)在許多人心中另有其定義，可以參考這裡，或這裡

註3：就只有這三種而已啊？確實有可能有別種，但是不太需要討論。例如：在某些軟體專案團隊的前幾個sprint，因為「蜜月期效應」的確真沒有大問題。也有很多軟體專案，本身的目標比較特殊：例如學校的畢業專案，或者政府國科會案，雖然要交付結果，但結果的本身根本不重要，當然也不有大問題。也有某些專案，並不適合採用單純的Scrum，所以無法使用檢討會議針對人進行檢討。

註4：Sprint的中途按照Scrum的精神本來就不能由PM/Owner隨意修改需求規格。但是，在這裡是Sprint的結束。如果Sprint中途真的發生臨時修改的事情，Sprint的結束當然要作為「事實」加以檢討。要注意的是，目的是檢討事實，而不是簡簡單單的說PM/Owner沒遵守「Scrum的規定」。Agile的精神中，團隊的溝通跟改善，遠比「規定」來的重要。由於軟體專案太常出現這類問題，所以後續文章也會有針對這種問題的建議解決方式。

企業巫醫 - 如何拒絕或調整客戶不合理的需求

在各類型的軟體開發情境中，有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生，在即將離職時，問了一個經典的問題：

--------------
你們是如何拒絕或調整客戶不合理的需求？
--------------


問題的本身很經典，但是卻必須要追本溯源。

首先，需求(requirement)本身是很難被界定清楚，因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人，現代化造車的始祖 - 早在一百年前的名言，至今仍難屹立不搖：

--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼，他們會希望跑得更快的馬"
--------------


然而，「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象，問了正確的問題，正確地理解回答。透徹的了解問題，才能知道客戶的需求是不是真的不合理，抑或，其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕，很有可能是自己故作姿態，甚至是知識技能不足的表徵。(註一) 

反過來說，隨意「答應」客戶，風險也很驚人。因為也許答應了一件根本不應該做的事情，或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸：客戶與企業都受害，甚至三輸：客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情，卻一直在企業界發生。


因為誤解客戶需求，或者不夠及時調整需求導致於雙輸的例子，在近20年內的有很多，隨便找一些範例如下：

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做？

1. 根據事實的正確溝通

抽象化的形容詞，對溝通不會有助益。

例如：「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語，在務實的書面報告中越少越好。當然某些摘要形式的報告，會很抽象，但隨後必定附上務實的參考依據。

例如：

「高可靠度系統」：已兩台伺服器互為備援的方式，達到高可靠度

「網路速度很快」：過去對外連線的速度是1MB，現在提高到1TB，因此網路速度很快。

「網站介面很好用」：過去每個月平均有150次客服電話，是在詢問網站某些功能要怎麼使用，現在每個月僅有10次。並且，每個月平均使用人數並沒有減少。

2. 透過具體內容決定接下來的執行事項

互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關？

首先，合不合理的判斷本身就很難客觀。對某人來說不合理的事情，對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見，只要接下來的執行「事項」，確實都是雙方認為最重要的事項即可。

和第一段相同，具體內容必須是清晰可見的動作(action)

例如：

* 將第一批手機抽15%樣本共150隻，進行電池過度充電放電測試。並在N月N號之前，給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上，增加可以使用fb帳號登入的功能，在N月N號之前，給出設計文件。

不是清晰可見的動作，會造成很多不必要的誤解，而誤解就會產生不合理的需求。


不清晰的動作例子如下：

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試，一隻也可以嗎？要測試哪種類型的爆炸？太陽曬到玻璃破碎也算嗎？)

* 我們的iphone app要趕快上架了 -- (？是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成？只要登入就可以，細節我們自己決定就好了嗎？還是要先看一下設計文件)

3. 務實的密集檢討事實

這可能是最重要，但最被台灣企業所忽略，也最容易被企業巫醫上下其手的地方。

可參考這幾個地方：(a) 錯誤檢討，(b) 自我反省，(c) Scrum檢討


「務實」：指的是根據事實來檢討，而非根據感覺。即便是需求檢討也是。

例如：某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊，這樣的要求讓專案經理非常不高興，覺得根本不合理也太不可思議。

如果不務實檢討，那麼每次與客戶的會議，大概就在針鋒相對中度過。但是探究事實，其實是因為該企業內部系統無法擺脫WinXP，而又因為WinXP能使用的IE就是IE8，導致客戶有此需求。就網站廠商來說，當然不可能協助內部全面升級為Win10，但卻可以提供其他在WinXP上，仍然持續更新的瀏覽器(firefox)。


「密集」：指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到，並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤，也會在一定時間內被發現。

「事實」：有時候事實很難全面探究完整。有時候細節太多，即使都是正確的資訊也過於繁複。

巫醫在同樣的事實上，都會有不同的詮釋。例如：經過鞭打火烤病人之後，病人仍然掛了。巫醫的詮釋通常是：惡靈不願意離開病人，是天命所致。

而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開，乃是天命」。而應該「改變」執行方式，應對不合理需求。如果巫醫不願意改變(註二)，換一個醫生是根據事實最合理的方法。

---

註一：違法的需求，當然是要直接拒絕。這類型的基本常識，不在此討論範圍之內。
註二：如果巫醫很容易以事實說服，那就不是巫醫了

Scrum - 務實的彈性，千萬不要削足適履 (下)

夫所以養而害所養，譬猶削足而適履，殺頭而便冠 ......除小害而致大賊，欲小快而害大利

--- 淮南子說林訓


誠如上篇，雖然說Scrum的方式與工具十分簡單，能務實並且彈性運用比照著字面嚴守方式來的重要。 

「形式主義者」嚴格遵守字面的意義，而非真實的意義，已經是很嚴重的錯誤。

但更糟糕的是「極端基本教義派」將學習到的Scrum技巧，視為不可侵犯的條款，凡是侵犯了條款視為大逆不道，非除之不可。 

Scrum是專案任務執行的技術與方法，它符合agile的精神 (註1)，並且延伸出一套可供參考的作法。這套執行的技術概念中，定義了角色，專案進行的基本流程，進度控制方式。

 而最最最重要的Scrum重點(註2)應該是： 

1. 一段時間之後(sprint)會交付可被驗證，可使用的產品 。

2. 每段時間的產出，都是市場在當時最最最需要的 。

3. 這段時間之後，整個流程會被檢討改進。

無法掌握到以上最基本的三點，任何字面上的意義都沒有用。而Scrum基本流程都是為了掌控以上三點。 做的到這三點，就可以進一步掌握更重要的要素。有個清單可供參考。

極端基本教義的錯誤有很多種。

然而有錯誤並不可怕，可怕的地方在於極端基本教義派難以自省問題，因為他們的存在目的在於「迫使」其他人跟隨絕對不會錯的自己。 

Scrum終究仍是管理類型的技術，因此不會工程或科學一樣有細節標準可循。光是Scrum證照在市面上就有N種，更何況是各種細微技巧。 

極端基本教義派常會其中的技巧視為必須，反而遺忘真正的重點。 

更慘的是，極端基本教義會將補習班的奇淫巧技，是為基本重點，舉例如下： 

例一：堅持每天舉行「站立會議」，而且會議中唯一堅持的事情就是大家要「站著」。 

會議內容倒是五花八門，從討論問題，到穿插最近公司要大家額外參加的同樂活動都有。Scrum的每日會議僅只講三件事：「上次會議到現在做完了哪些task」「到下次會議之前打算做完哪些task」「目前遇到什麼重大問題」！ 

例二：估計時程的撲克牌，堅持使用點數來估計task。但從來也不檢討時程為何不準確。 

不可否認Scrum撲克牌是有用也有趣的觀念。但是，它並不是唯一最好的估算時程方式。

事實上，只要是軟體團隊，經歷過2-3個sprint的團隊，在第3到4個sprint開始之後，直接以時間來估計時程更容易更確實！

因為絕大部分軟體的困難度是時間與執行問題，在撲克牌估計點數中都有個假設是：難度可能和時間無關，但就軟體開發而言，幾乎不可能！ 

再者，Scrum撲克牌根本也不是Scrum獨有的，大約在2005年之前就已經有人提出類似的方式(註3)。當時需要以點數(point)而非確切的時間來估計時程，一部分的原因是：估計時程的人根本不是「做事情的那個人」！ 

由於搞出以點數估計task難度，在以團隊速度推算時間這種以繁馭簡的人，在當時，他是為了是搞出另一套可以拿PMP的PDU/SDU課程讓大家來學習，並不是因為他有專案實例在此！因此，就目的而言，其實也不太能讓人苟同。 

撲克牌工具仍然是好工具，非線性的點數分配仍然是好觀念。

但如何操作還是要看團隊在每個sprint結束檢討而定。 

例三：因為各種原因，沒有先執行最重要的事情 

所謂最重要的事情，就是最重要的事情。如果他是最重要的功能就應該先行完成。如果他不是，就不要現在去做。 

基本教義派最常以「這個sprint是4週，如果先做P2，下個sprint做P1就會比較快，不然先做P1可能sprint沒辦法是4週」作為技術上，區別功能先後完成的依據。 

 如果Product owner也認為是如此的話，那麼只有兩種可能：(1) P2其實是最重要，P1相較之下不重要，或者差不多重要。(2) product owner無法代表市場，了解事情的重要性。或者很難了解。 這兩者其實都會發生，也都無可厚非。因為agile的精神本來就在於適應變化。

但scrum團隊絕對的基本觀念就是：如果已經很確定這件事情真的是最重要，就絕對應該先做！ 

而Scrum Master除了處理團隊問題，每日站立會議之後，要問自己的就是團隊是不是正在做「最重要的事情」，這遠比趕快更新燃盡圖(burndown chart)來的重要。確保團隊隨時都在做「當時最重要的事情」是Scrum Master「隨時最重要」的任務。

---

註1：agile基本精神如下：

(1) Individuals and interactions over processes and tools
(2) Working software over comprehensive documentation
(3) Customer collaboration over contract negotiation
(4) Responding to change over following a plan


註2：但是這三個重點，也是補習班沒辦法直接教的

註3：http://www.informit.com/store/agile-estimating-and-planning-9780131479418

Scrum - 專案壓力來自於無法掌握的命運

一個壓力實驗：

有兩個籠子(A,B)，都連結同一個電極器，各有一隻老鼠。A籠子中，有一個燈號和按鈕，當燈號亮起時，如果在數秒內，A老鼠沒有按下按鈕，則就會產生高壓電極，讓A,B兩籠的老鼠都被電的很不舒服。不過，如果燈光亮了，在時間內A老鼠按下按鈕，則A,B兩籠就都沒事。B籠的老鼠則是全然被動的，只要A老鼠能做好他的工作，B老鼠就沒事。當然，經過幾次電極之後，A老鼠很快就學會了一旦看到燈亮，就應該儘速去按按鈕。

過一段時間之後，哪一隻老鼠的壓力大？

經過健康檢查，A老鼠幾乎看不到壓力大的特徵。而B老鼠，則出現各種癥狀：高血壓，胃潰瘍，成長障礙等等不一而足。

(以上內容取自:數位痴呆症：作者Manfred Spitzer)


軟體專案的壓力和該實驗有異曲同工之妙。真正的壓力來源不在於事情有多難，而是在於自己「全然」隨著命運擺佈，無法控制。以A老鼠的情況來說，他仍然是被關著，而還得三不五時瞄一下燈是不是有亮，一旦亮了就得趕快反應。

然而，「至少有一件事情」A老鼠可以控制：他可以決定自己要不要被電極。B老鼠則是沒有一件事情是自己可以決定。因而壓力無從擺脫。

Scrum(實況)是根據事實，固定的時間，以及有效團隊分工來達到敏捷開發的精神。而在此基本精神內，每一個角色都有「至少可以全然控制」的事情，不但可以正確減低無法掌握命運的壓力，更能組合出正確的團隊合作方式。

Product Owner（產品擁有者或產品經理）

在傳統的「瀑布開發模式」，或者，系統整合商SI的「隨意無止盡需求模式」中，產品經理會就所有應該要做的事情列一個驚人的功能清單，交由專案經理負責領導開發。接下來的18個月，產品經理就在B老鼠的壓力下度過，即便有檢查，也不知道產品真正的進度。而18個月後發現意外的機率...已經不是機率而是必然。

而過於認真擔憂的產品經理，更有可能在每一段時間，修改需求，讓開發團隊變成B老鼠，不確定哪個需求改變的命運降臨。

在Scrum中的產品擁有者(Product Owner)擁有非常簡單而清晰的責任，這個責任用非常簡單而清晰的方式減低他的壓力：「撰寫並排序需要完成的使用者情境」。

專案開始時，產品經理會撰寫數個使用者情境(user story)並且排定優先順序，而每個sprint開始時，團隊會告知這個sprint(4周)會完成到第幾個story。產品經理等候4周之後，檢查這些當初答應的story是否有如預期完成，並且在下個sprint開始時，或確定，或重新排列，或增加，或減少接下來要完成story的優先順序。

產品經理仍然不會去「做東西」。然而他確實全然掌握階段性完成，並且確定每sprint開頭都能選他最想要的事情先做完。因此，產品經理確實能掌握這個產品每一段時間的「樣貌」，而不是在最後關頭才求神拜佛，或者要求加班。甚至，在sprint的中間階段，若有必要，產品經理可以要求sprint停止，重新開始新sprint，用來調整後來才發現不正確的優先順序(priority)

Scrum Master (開發領導者)

過去一個團隊的技術領導者，帶領團隊解決技術困難並協調各類工作。他常常會是夾在產品經理（或客戶）以及開發成員中的角色。

在傳統模式下，他若非變成一個技術獨裁者，用以壓迫成員前進並反抗大幅需求改變，就是變成試圖面面俱到的好好先生，用以彌平不同角色的紛爭。「能良好溝通」這個字眼會常出現這個角色的工作描述(job description)，但事實上，困難的專案，不會因為一個很能講話的專案經理，就變得簡單。最後最常出現的結果是：專案經理總是能有效呈現「自己的貢獻和功能」，但無法反應在專案成功。換言之，常常看到自己從來不失敗的專案經理，曾經領導了很多壓根不成功的專案。

Scrum Master並非傳統的專案經理，其責任和角色也有很大的不同。而他能有效掌握的事情，也能讓他減少原本專案經理的壓力。

Scrum Master 掌握「會議」。他可以確保每日會議只「說明三件事」：完成了哪些事情，接下來要做什麼，有遇到什麼困難。確保每個sprint開始的會議，領導團隊能完成哪些使用者情境(user story)，並且確定這幾個要完成的事情，產品經理都有完整而合理的描述。他雖然沒有掌握全部18個月會完成的事情，但是透過掌握每一個sprint，腳踏實地的一個一個完成優先要完成的事項。

Scrum Master 掌握「真實進度」。透過領導決議「和未完成」以及以事實展現的燃盡圖，Scrum Master掌握過去真實進度。因而可以有效推測未來進度，並有足夠的證據顯示給產品擁有者。因此，才能有足夠的「動作權力」成為A老鼠：仍然在籠中，但掌握部分真實權力，以減少壓力。

Member (團隊成員)

傳統模式下，團隊成員經常是壓力末端。所有的壓力最後承受的出口。所有過勞死最可能發生的地方。傳統上最常出現的是：「某功能我們在要X月X日之前出來！」「現在馬上改做XX不然沒辦法驗收」。

而傳統的產品經理和專案經理 - 無論是軟性還是強硬 - 通常不得已的把壓力直接轉嫁給團隊成員。

但是，在Scrum中團隊成員，決定使用者情境：「真正完成的所需要的時間」。而這個權力，僅代表一個事實：由做事情的人傳達做事情的時間與結果。成員不再在決定什麼事情先做後做，只要決定現在在做的事情，什麼時候可以完成，以及「真的去做他」。換言之，Scrum團隊真正的A老鼠，其實只有團隊成員，只有他才會真正的按下按鈕。然而，如果Scrum團隊不能掌握分工負責的精神，團隊成員很快就變成B老鼠：不是被無謂的壓力掌握自己的命運，就是試圖跳脫牢籠。