如何指派工作 (軟體主管的31堂課)

作為團隊領導者，自然會遇到任務分配，指派工作任務的情況。軟體開發團隊也不例外，雖然敏捷式開發方式中的Scrum方法論，是希望在每個Sprint中採取「自己認領」工作，但其實極少有團隊可以完全做到這點。

指派工作任務最完美狀況是：團隊成員對主管有100%的信任，同時對組織中短期目標也有深切體會；並且都有完整的技術能力可以達成任務；而且所有人對於專案與時間管理都有經驗；而更重要的是，每個人都士氣高昂，迫不及待地完成任務。很遺憾的是，這種情況幾乎不會存在，好的軟體主管必然認知到的是，自己的任務必然是在於讓團隊成長前進，往好的地方邁進，而非期待自己「已經處於」一個完美的團隊。

如果你是個軟體團隊的主管，常常在夜深人靜時自己抱怨自己的環境與團隊，並且自認為委屈，那麼你就是屬於「期待自己已經處於完美團隊的主管」，這通常不會是讓事情變好的心態。

指派工作的方式看似很多，但重點只有幾個：

(一) 指定清楚的目標

指定清楚目標表面上很簡單，但主管自己其實需要考慮是這件事的真正目標，和指定任務的項目。

舉例來說，如果軟體主管指定任務目標為：「A工程師，請把某個AWS的一組VM，從micro升級到xlarge。」這看似清楚目標，但升級機器，必然不是目標，升級機器要達到的結果才有可能是目標，更有可能的是結果後的結果才是目標。

例如，稍微清楚描述目標：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，請把某個AWS的一組VM，從micro升級到xlarge。」

但是，更好的方式其實是，清楚目標先指定，然後再討論出來。例如：「A工程師，我剛收到通知明天由於行銷活動，我們網站流量應該會暴增，為了讓我們能處理高流量，我們在AWS上的各種VM和使用的服務，有需要做哪些改變呢？」

當然，目標本身一定要涵蓋作法/行動。沒有具體行動的目標也沒有意義。

(二) 時間視為最重要衡量方式

時間是衡量所有事情的最重要的方式，在清楚指定或者討論目標作法之後，所有的行動必須以時間為衡量方式。而時間除了長度，還有實際完成時間。

例如：「A工程師，根據我們剛才討論結果，我們需要升級所有120個VM，這需要2小時，並且是在後天早上10:30am之前完成」

(三) 寫下來！

指派工作的另一個重點在於，所有任務指派一定要文字化或者圖形化，即便是很簡單的瑣碎小任務，也應該用一張紙寫下來。現在專案管理工具其實很多，例如JIRA。當然也可以用它來指定所有任務。

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還是任何工具，都應該有自己的處理相依性的方式。

Scrum: 三件不能少的事

Scrum是敏捷開發原則下，目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論，並沒有所謂的標準，各個組織的應用方式皆有不同。常見的應用(practice)，例如：spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中，哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神，以下三件事情是「最基本要有的」。也就說，如果這三件事情做不到，那麼其他事情做到也沒有用。

(1) 每個Sprint有交付具體產出

Scrum的Sprint都要有具體「可交付」的產出。sprint的開始，就應該以「結果」為計畫的導向，而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由，設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題：(1) sprint結束的檢討，並不基於產出的事實 (2) kick-off下一個sprint的意義不大，因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off，畢竟這個sprint沒有有意義的產出，而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度，請參考這裡。 

(2) PO有確實加入Scrum團隊

Scrum團隊成員有三個角色，team member, scrum master, product owner。其中最容易不在的人，就是product owner。許多軟體開發團隊，product owner就是PM。但無論如何，Product owner必須要真實參與團隊。

所謂真實，指的是所有standup應該參加，在團隊運作過程，能夠回答該sprint的需求問題，並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後，DOD(definition of done)的標準才會具有「市場一致性」。舉例來說，不成熟的軟體研發人員常會對事情做完有不同的定義：
「程式寫完只是還沒review，所以還沒merge」
「程式寫完測試也沒問題，只是QA還沒通過」
「功能搞定了，QA也沒問題，只是還沒...」

PO確實加入後，可以讓事情做完的定義，統一在於「可準備交付到市場」。換言之，所有和程式設計相關的工作：測試，相關文件，環境設定，certificate等等都會以「可準備交付到市場」為原則。沒有這個原則，跑Scrum很難達到預計效果，要達到這個原則，最基本的就是PO需要確實投入團隊。

(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)

這世界上沒有完美的團隊，也沒有不用修正的軟體開發方法論。每個sprint的確實檢討，是修正團隊，讓團隊趨於一致的唯一方式，而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易，要做到兩件事情：
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 

基於事實的檢討

檢討的內容必須基於事實，不是基於感覺與想像。感覺和想像的情況如下：
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下：
「這個sprint我們沒有按照當時說好的DOD的定義，所以有XX與XX項目，本來說完成了，後來隔幾天又說沒完成」

不檢討不在場的人事物 

檢討確實是對事不對人，然而，事情都是人做的，不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過，要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確，導致我們要重做某些事情」如果UI/UX是同一個scrum團隊，那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為，Scrum的檢討會議目的是產生「團隊要改善的項目」，而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得，但經驗的獲得又必須從知識學習的取得為基礎，要成為看似不錯的Scrum專家不難，但要實際應用於專案中，並取得可重複成功的結果就不這麼容易了。

沒有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。然而，誠如前所述，工作角色名字不重要，做出事情才重要。

How to build a self-motivated software developer team

A team which all team members are self-motivated is a dream team where everybody want to join in. But, it is really rare. Well, maybe the 1992 dream team was one of the cases but we didn't see many examples in software developer's world.

Nevertheless, to build a self-motivated team is a major task of a manager. If you are the manager, this should be your priority-zero task, and should be only one zero, if you are going to build a new team.

Self-motivated might be the best way to drive software engineer's performance. Since high productive engineer works high involved in creativities and mental work.  These are hardly be gain or impacted by salary or physical award (reference: 1, 2, 3). Sometimes it could be driven by a noble target: save all poor children in the world, increase average human life to 200 years. But unfortunately, that kind of things normally happens in non-profit organization with a born charismatic leader. 

So how to build a self-motivated software developer team in a common working place?

Three key points: (1) selection (2) intersection (3) automation.

(1) Selection

If a member who is already a self-motivated person, then it will be easy to keep his good attitude. Since it is pretty hard to change a person's mindset, therefore to get a right person is the most easy way.

Do select a person who already has record on self-motivation. DON'T select a person who has good skill-set but has bad records on self-motivation and you believe you can change his/her mindset, I won't say it is possible but you need to understand that you really have much less changes. Since you can't be with the person 7x24 and his mindset is only inside his brain.

The key point of selection is try to understand his past. Do not judge his "self-motivation" by ask future question like: will you be self-motivated in our team? Understand his past working experience by asking the difficult moment. Especially, sometime he might not be in spotlight and what he did on that moment.

Again, identify a person's past is the best way to select right attitude candidates. And a best fitting person can really have positive impact for the team. 

(2) Intersection

There is no way to read team member's mind. People have left-hand-column, even if you already selected best people to join your team and you were very sure they all are honest. But they surly have things which can't tell or won't tell.

Some leaders or managers will try to dig it out, it is fine to do but not that easy. The best way is to admit the existence. And then leaders should focus on the intersection which is the area that covers the target of a single team member, the team and the organization. And that is also the area where creates win-win-win.

A self-motived member could find that area by himself. But if you are leader/manager, you should keep in mind that figure out the area and knowing the area is very different in each individual. To fine tune a bit earlier can largely reduce the risk of un-motivated situation.

For example, "Ken" is always in good performance and deliver pretty good result. And you believe that you knew that his career interesting is pure technical area. Which means he might want to be an architect in the future. However, if you see he is pretty happy to lead junior members to work out teamwork activities, for example : organize a study group, handle company travel, or year end party. That might be a sign of that he is actually want to be a manager in the future. If his actions is toward his goal then it is fine. However, if his actions didn't reflect your assumption, then it is your time to reset yourself or/and make a little changes.

The bottom line is to avoid lose-lose-lose situation. This sounds funny and should not even considered to happen. But there are too many true sad stories existed in the world. An usual/typical sample in software developer's world was: a team (which members are well-pay) worked over-time on an ambiguous project for months, delivered a product which didn't fit PM's expectation, company lose money, members lose life, customer didn't get result: no body wins.

To avoid 3-lose situation, make sure there is an intersection of all. If you were the manager, make sure you can guide your members into his own intersection. But if you really see that there is NO intersection at all, make sure to create one.

(3) Autopilot

Autopilot means a member knows exactly what to do, how to do. And most important thing is if there are tasks out of his current skill set, he will know how to learn. He can even do self-consideration of intersection and selection. Totally worry-free.

Again, if the selection was done good, to let team member become autopilot will be easy. All you need to do is coaching. Coaching is another topic of a few books plus lots of trainings/experience. If you are an experienced leader/manager then you already know how to do, just reminder to keep open your mind. And also please keep in your mind that open-your-mind is never easy.

The bottom line is to avoid micro-management.  Software development is highly brain consuming job. Micro-management never works in software development, it does work in other kind of job but it definitely doesn't work in software development. If you need to talk to your member about when to arrive in office, when to leave, what to update in Slack, how to write email. That means you are NOT trying to build self-motivated team or this specific person won't fit in a self-motivated team.

Sorry, No short-cut

There is no short-cut in for organization theory. However, practically do the right things normally will get the positive result in a few months. Of course, sometimes in a rapid startup environment, it seems no time to wait. But most of us in software developer world are running marathon not a sprint.

Skill sets and performance concerns:

There is one more thing. I didn't discuss skill sets and performance here. But this is actually extremely critical for a software developer's team. Without an excellent skill sets and performance delivery the self-motivated will be useless. However, this "should" be not difficult to identify during interview and resume check.

Scrum: Feature-boxing of Sprints

In certain scenario, a scrum project could allow different length of Sprints and still satisfies Timeboxing principle. It benefits an involving software product of build MVP, increase integration quality and make members even more focus.



Time-boxing is one of fundamental practices in Scrum methodology. Most of actions in scrum are time-boxed. It makes sure the project keep going and also lets members focus on current task.

Time-boxing is one of the cure of Parkinson's Law of Triviality for all kind of meeting. No matter it is Sprint kick-off or daily standup. I believe it should apply to not only project management but also other area of organization, as long as the timeframe is a consensus of members. 

You can easily find the definition or discussion of how important time-boxing (or timebox) is in google. For example: this one or this one.

Timeboxing in Sprint

A Sprint in scrum also apply to time-boxing. Normally it means when project kick-off, all scrum members will decide how long is a Sprint. The recommended length is 4 weeks in software development. After that all Sprint will be in 4 weeks, no matter how many stories have done or what changes happened between Sprints. That also means if a project is in Sprint-11, 40 weeks was gone. 

A fixed timebox sprint make process happens. But is it necessary to keep the same length of Sprint?

Still timeboxing but flexible in next Sprint

Timeboxing is still critical and should be applied in the moment before event start. Sometimes, we should not fix timeframe in project kick-off and keep for next 40 weeks or more.

In fact, every Sprint kick-off meeting should also discuss a timeframe of this specific Sprint.

Image a sprint-kick-off meeting. Everybody: Product Owner, Scrum Master, Scrum Members were together in this Sprint kick-off meeting, discuss stories and story-points. If PO select 3 stories: P1, P2 and P3 which needs 2 weeks, 1 weeks, 3 weeks. What team should do? The general practice should be keep P1 and P2 in this Sprint and also select a few lower priority task to fill up that one left week. However, there are a few drawbacks in this situation. Firstly, remember Parkinson's Law? members might extends the time for not select lower priority tasks which sometimes is not a bad idea. But secondly, if a scrum team keep doing select a lower priority to fill up time slot, it make the "priority" not "priority" any more. 

If all members have consensus of flexible Sprint length, they can easily setup next Sprint to 3 weeks. And that Sprint will done  P1+P2. Or with Product Owner's agreement, they can setup next Sprint to 6 weeks to complete all P1~P3. 

In some scenario, the most beautiful way should be keep P1 in next sprint only. And this Sprint will be just 2 weeks. 

Make MVP possible

Why do one story at one Sprint is a beautiful way? Well, in some scenario, we need to make MVP(Minimum Viable Product)...and keep make MVP for a while to identify market and make sure minimum waste. Unfortunately, no body can foresee the future. A quick/early delivery is the reason why MVP is useful and also the reason why it is good to stick a single story delivery in a single Sprint. To achieve that, we need flexibility in different Sprint.

The key person of MVP is Product Owner (PO). And to make MVP possible, the bottom line of scrum is to have PO's real participant. In reality, it is very very hard to PO to focus on what he needs to do. A single story delivery forces PO to make a decision of the real priority of backlogs. Since the team will really delivery a things in every Sprint and of course PO should then put the thing in the market. PO can't say: well, it is too early to go for market. Since this is his priority one! Priority one should go for market right away! 

Why Quality improved?

Very simple, each Sprint with only one story has its own QA process and due to the complexity of change is short. we can easily fix integration issue or new defeat much quicker than a sprint with more than one story.

Agile: Feel comfortable to Adopt reality

An agile team should be comfortable to adopt changes and those changes should reflect to reality. But should still keep the critical concept. There is always a way to enjoy both without compromise to an uneasy method. 

To be flexible in Sprint length doesn't mean to break Timeboxing. But it does break some rule from the regular Scrum training. Nevertheless, process is continuously improving is the bottom and spirit of Agile. Scrum master or organization leader should take responsibility to make sure the process could be tailored after retrospective.

Case Study

As developer manager of a enterprise software product, I modify a bit of product release method to make sure PO's backlog is a real priority to reflect market needs. 

The result is since 2016/July to 2017/Mar (8 Month), we delivery 5 releases. The longest Sprint is 8 weeks and the shortest Sprint is 2 weeks. We actually complete 5 major stories and achieve following technical result.

(1) Quality: no side effect in these 5 release. Compare to previous fix Sprint length model much lower technical defeat in beta.

(2) Productivity: averagely, more code conduct per engineer compare to previous fix Sprint length model. However, at the same period of time, we enjoy more team building activity then before and very very very few overtime.

(3) Motivation: engineer could see the result (no matter good or bad) few weeks after delivery. Previous fix Sprint length model needs 3 to 9 months to know if our works really matters.

If you'd like to know more detail, please drop me email.

軟體專案管理 - 版本控制系統內的程式碼基本分析

孫子兵法：夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！

任何軟體開發專案的基礎都是「程式碼」。即使，專案經理不需要親身撰寫程式碼，但是必然要能夠透過程式碼，取得專案關鍵資訊，作為專案領導管理的最佳參考。(關於專案進度，請參見這篇。)

版本控制系統(git, cvs, p4, svn等等)，則是有效控制程式碼的基礎，開發過程大部分的事情會發生在這裡，也應該發生在這裡。

如果你的軟體開發專案，沒有使用版本控制系統！！？？...呃....請參考註1。

版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者：

(1) 截至目前為止，有多少人實質參與專案
(2) 截至目前為止，專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內，此專案程式碼品質的推測
(4) 一段時間內，例如過去48小時，軟體團隊的實質產出
(5) 一段時間內，例如過去7天，有沒有人在非上班時間內工作


專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼？？

---

"Доверяй, но проверяй" 
 - 俄羅斯名言，意思是 Trust, but verify  

冷戰期間美國總統雷根特別愛用此名言，根據wiki說明，雷根是受到一個作家的影響

---

因為，過去專案管理者常見兩種極端：

(1) 極端放任自由：在Scrum的精神下，雖然每天站立會議和燃燼圖，都可以揭露專案最確切的進展，完全相信成員的口頭回報
(2) 極端間接的繁複審閱：在沒有技術背景的情況下，透過頻繁而起瑣碎的會議，加上各式各樣文件追蹤，試圖了解目前進展。

這兩者都有明顯的問題，Trust, but verify才是正確做法。以Scrum的精神取得每日進展，並且，專案管理者應該「自己」想辦法檢查。專案管理者，如果沒辦法自己檢查，表示對此專案的本職學能不足。(註2)


專案管理者能夠做的程式碼基本分析有很多。好的專案管理者，至少需要能自己「動手」，利用工具或者程式，透過事實，了解下面三件事情：

(a) 基本專案狀態分析：哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要：某些程式碼就是常有問題
(c) 哪些人需要額外關注：某些人工作壓力大常加班

以下以git為例，其他版本控制系統也能做到類似的事情。

基本專案狀態分析

靜態程式碼分析工具有很多。例如，gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡。
以github上的serverless.com為例，在github上clone這個專案，並且執行#gitinspector的結果如下：


首先會大致列出作者和過去的產出摘要，例如Aaron在這個專案一共commit了8次，包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途，但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。




接下來隨即會列出還存在的程式碼行數。以Austen來說，他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期，而開發後期的版本沒參與。

哪些程式可能容易有問題？

程式設計師每天辛勤的工作，自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」

git log指令，可以加上 --grep=<string> 來濾出字串，以下例子只用fix當作過濾條件，並且配合linux其他指令：sort, uniq 就做出簡單的報表：

~/serverless# git --no-pager log --name-only \

--grep=fix  --pretty="%s" | sort | uniq -c | sort -n

     19 lib/ServerlessState.js
     19 tests/tests/actions/ResourcesDeploy.js
     20 lib/ServerlessProject.js
     23 lib/actions/EndpointDeploy.js
     23 lib/actions/ProjectInit.js
     23 lib/actions/RegionCreate.js
     23 lib/SerializerFileSystem.js
     24 lib/Serverless.js
     25 lib/actions/ResourcesDeploy.js
     25 lib/actions/StageCreate.js
     25 tests/test_utils.js
     27 package.json
     27 README.md
     28 lib/actions/FunctionRun.js
     34 lib/actions/FunctionDeploy.js
     38 lib/actions/FunctionCreate.js
     55 lib/utils/index.js
    101 tests/all.js

當然，以上報表只是列出有fix字串的commit中，哪些檔案出現次數最多。 tests/all.js 明顯是最多的，但也很明顯這檔案本來就是會被一直修改。此外，README.md也是一樣，大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。

程式有問題的的判斷方式有很多，除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數，刪除的行數，增加的行數，並且配合QA/bug tracking系統，才較為完整。

哪些人需要額外關注？

「人的問題」，永遠是最難解決的問題。然而，卻也是要優先解決的問題。組織中必然有需要「被關心」的人。

專案組織中，最要被關心的人是「表現好且有潛在壓力大」，以及「表現不好且對團隊有負面影響」這兩種。其中，表現好的人更是要優先處理。

除了每天例行工作接觸之外，專案管理者應該要有確切的「數字」。假設，我們想知道在此專案中，哪些人常常「晚上」工作。最簡單的方式是分兩步驟，先用git列出作者時間，然在寫個簡單的統計程式，列出所有人的「晚上」工作時間和「平常」工作時間次數。

* 步驟一：先取得所有的branch, 然後, 以下git log指令可以列出作者和時間，並且輸出到檔案author_time_log

 

# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log

檔案內容大概如下

....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....

* 步驟二：撰寫簡單的分析程式，設定正常時間是早上7點到晚上8點，其餘都算不正常時間。用人名為單位加總之後，就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡。

此表中，Eslam幾乎有一半的commit都是在晚上產生，而Kamil則是標準完全正常時間工作。

Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]

當然這並不代表Eslam的表現好而且壓力大，這只是提供給管理者參考的事實。專案管理者，必須要事實層面，檢查軟體專案的狀況，因為很多時候「會吵的小孩有糖吃」，只單純被煩就會給糖的專案主管，其實對團隊是沒有價值的。

小心統計陷阱

統計數字都可能會有陷阱，程式碼的基本分析也是統計的一種，自然要小心陷阱的存在。專案管理者應該要善用統計數字，切勿被統計數字所左右。請參考統計與謠言。


 

---

註1：軟體開發專案不使用版本控制系統，會讓專案本身暴露在極端的風險中。如果你是專案管理者，讓專案暴露在風險中就是你的責任。如果你只是個開發人員，儘早離開高風險的環境才是上策。

註2：某種情況是，專案規模過於龐大，例如參與開發者超過100人，某些技術確實不見得能完全掌握，但專案管理者，仍然要保有部分自行檢查的能力。

如何成為Scrum專家 - 極簡計畫書

Scrum是推進團隊進度，合作專案的敏捷方法論之一。在過去幾年來從資訊產業，金融業，甚至學校教育，都有不少人在倡導這個簡單而且踏實的方式。因為Scrum有很多優勢，例如減低壓力，具有務實的彈性，容易評估現況，易於控制品質。這些優勢，可以用在大部分的企業環境中。因此，成為Scrum專家對職業生涯很有幫助。

學習Scrum並不困難，在各企業巫醫的網路資料中，早就擁有看不完的資料。請參考這篇。

對職業生涯有幫助的不僅是「學會什麼是Scrum」，更重要是成為Scrum專家。或者，至少成為在他人眼中的Scrum專家。專家的定義，請參考註1。

或許你在職場有2-4年的工作經驗，作為一個團隊成員，在專案領導人的帶領下，參與以Scrum為基礎的專案。然而，這不會讓你變成Scrum的專家，因為你只是「照著做」而已。

在此提供一個極簡計畫，可以在很短的時間內讓自己變成Scrum專家。

如果懶得看說明的長篇大論，可直接到這個網頁下載計畫書

開始之前的條件

這份一頁極簡計畫書有使用上的條件：

(a) 必須要有還不錯的英文閱讀能力，TOEIC750以上。如果你的英文能力自認不夠，請參考這裡。

(b) 必須要有2-3年以上的實務工作經驗。而且在工作環境中，至少聽過Agile/Scrum。

(c) 必須打從心裡認為有效使用Scrum是有好處的。換言之，不能是因為「有人叫我要學Scrum」而學Scrum。因為，此極簡計畫書本身執行的方式也是Scrum！


如何成為Scrum專家極簡計畫書的使用步驟如下：

(1) 確認目標的實質意義

此極簡計畫是要在2個月內，讓執行計畫的你變成「Scrum專家」。而何謂Scrum專家的實質意義就是在此極簡計畫中三個sprint的「實質產出」。

Sprint-1 知識：讀完2本Scrum書籍，以及2份網路資料

Sprint-2 證照：取得Scrum證照

Sprint-3 研討會：舉辦公司組織內Scrum研討會或分享會

這三個實質產出的組合意義，目的就會讓你成為Scrum專家。即便不是Scrum大師，至少也是被大部分人承認的專業人士。

這三個Sprint各有已經設定好的任務(Task)，所有任務完成後，就表示該Sprint完成了。而每個任務本身的描述都是有簡單清晰的「完成條件」definition of done。

(2) 分配每個Sprint的時間

計畫書中，每個Sprint各有數個任務，每個任務都有估計的時間。時間是以小時為單位。加總起來，會有要完成Sprint所需要的總時數。

一般軟體專案Scrum估計都可能會有錯，在Sprint過程中，要能實際反映團隊實際的「速率」，因此前1-3個Sprint的燃盡圖很重要，可以讓團隊知道實際的效率。所以每個Sprint都是固定時間，大約4-6週，sprint時間到就結束了，只會看做完哪些Story，在下一個Sprint才調整要完成的story數量。

然而，個人Scrum做法會略有不同。整體概念仍然一樣，但因為Product Owner也是「你自己」，因此Sprint時間可以變動。換言之，可能第一個Sprint是4週，第二個Sprint是5週。

請在極簡計畫書中，每個Sprint任務表格上方，填寫預計的Sprint開始的日期，和結束的日期。Scrum是要反應實際狀況，因此，也許整個sprint需要5小時，但因為你有本來的工作要做，因此可能要花2個月才能有5小時的空閒。

(3) 每日工作

當有超過30分鐘空閒的時候，就可以把那張極簡計畫書拿出來，在這個Sprint選一個任務(Task)開始「執行」，或者，繼續上次未完成的任務。這些Task都是大約設計成30-40分鐘完成，但是根據Scrum的精神，每個人的績效不同，因此也有可能會花的時間多或者少，但無論如何，在還沒完成已經做一半的任務之前，不要換任務！

當然，如果該日沒空，自然就不需要拿出極簡計劃書來執行。

每個任務，都有完成條件，確定滿足完成條件後就可以塗黑空格，並且在右邊簡單的紀錄所花費時間，和大約日期。時間不用太精確，以半小時為單位即可。有些任務很簡單短暫，也許10分鐘就完成，但也以半小時紀錄就好。

如果沒辦法在0.5小時內完成一個任務，那要請自己休息一下，再決定要繼續完成該任務，也可以決定今天就先到此為止。

不能有某任務做到一半，就「先拿了」下一個任務，也不能有這個Sprint還沒完成，就先開始做下個Sprint的某個任務。當然Sprint中的任務，有些是沒有前後關聯，因此Sprint中的任務不需要按順序。只是，一旦開始做，就一定要做完為止。

某些任務需要下載檔案，請參考註2的各個下載網址，可以一次下載完成。

在計畫書中的任務描述都很簡單清楚，但如果真有問題，也歡迎來信詢問

(3) Sprint 結束自我檢討和下個Sprint的開始

完成Sprint中所有任務之後，表示這個Sprint完成。要花15分鐘時間，先自我檢討一下Sprint過程中有哪些阻礙，而自己應該怎麼改善阻礙。

接下來就要開始下一個Sprint。實際上，本來Sprint的開始是需要先討論Story和Task的選擇。然而，極簡計畫書希望你不要花時間在研究這些Task重不重要，而是先努力的花時間搞定它。畢竟這些任務所需要的時間都不多，實務上也對你有莫大的幫助。

不過，或許有些任務你早就已經完成，那就可以看一下完成的條件(DoD)，已經達到就可以自動塗黑。

(4) 計畫書完成？專案結束了嗎？

三個Sprint完成之後，這個極簡計畫書就達到它的功能。但就個人專案的角度來說，專案不見得要結束。只是這時候你已經有足夠的能力和經驗，可以決定要不要繼續以Scrum的方式來學習Scrum。

(5) 3個Sprint結束後的彩蛋！

很簡單，當你完成這個極簡計畫書，實質上你自己完成了一個Personal Scrum。

彩蛋要靠自己完成。請在計畫書背面以三個Sprint的各任務所花的時間，「手工」繪製燃盡圖。

這件事的意義在於，你有確切證據證明你能有效運用Scrum在非工作事項上。也證明你有自我學習的能力。它可以用在未來履歷表，面試，或者說服同事Scrum不如想像中困難，只需要一點點毅力去執行。


在此下載計畫書

常見問題：

Q1：這個極簡計畫書，很多地方跟我在工作上用的Scrum都不一樣啊？

Ans：當然不一樣，因為他屬於Personal Scrum。但是它的最基本精神是一樣的。請參考這裡，了解Scrum哪些最基本精神比較重要。

Q2：我不就是自己的Product Owner？為什麼我一定要用這三個產出來達到「變成Scrum專家」。

Ans：你當然可以自我決定產出和任務，也有機會變成Scrum專家。極簡計畫書，是在如果你還沒有好的定義時，可以透過過去人的經驗，減少時間浪費，讓你專注在精進自己。

Q3：為什麼要取得Scrum認證，這樣就會變成專家嗎？

Ans：有些人可能會以「取得相關證照」，作為專家的標準。這的確是個參考標準，但也只是參考而已，因為Scrum並沒有所謂官方證照，所以市面上各種證照到底哪一個比較適合？請參考這篇「Scrum認證！不要再浪費錢了」。在此採用的是Scrum-Institute的低成本證照。

---

註1：即職場上的專門行業，指具備專業化知識及技能的職業人士。通常，專業技能須符合科學原理，經過長時間的學習及訓練，並有經專業認證的考試獲得的合格證書或執照，擁有自我約束行為的職業操守（或道德）及可量化的專業標準等。...定義細節請參考這裡。


註2：各種需要下載的資料

(a) 任務 1.4 的2個pdf教材
* https://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf
* https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

(b) 任務1.7的wiki頁
* https://zh.wikipedia.org/wiki/Scrum

(c) 任務2.1的pdf
* http://www.scrum-institute.org/Scrum_Books_International_Scrum_Institute.php

(d) 任務3.1與任務3.3的材料

* http://www.eduscrum.com/

* https://www.crisp.se/gratis-material-och-guider/scrum-checklist

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結束要做事情是(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的精神中，團隊的溝通跟改善，遠比「規定」來的重要。由於軟體專案太常出現這類問題，所以後續文章也會有針對這種問題的建議解決方式。

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