顯示具有 敏捷開發 標籤的文章。 顯示所有文章
顯示具有 敏捷開發 標籤的文章。 顯示所有文章

9/02/2019

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


8/28/2019

人手不足?資源永遠都是不夠的 (成為主管的31堂課)



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


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


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


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

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

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


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

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

三:必要的犧牲 

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

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


陷阱


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

12/24/2017

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

8/07/2017

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


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

在這世界裡,「在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: 當然如果你是想考動力小船執照,由於上課時間是固定,當然沒辦法「更快」。

2/16/2017

建立軟體開發團隊 (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) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等






2/06/2017

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周來的快太多。其原因也很簡單,重構是繁瑣麻煩的事情,當然會被估計成很長的時間。





12/05/2016

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




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


假設團隊依照正確的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

12/02/2016

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




11/24/2016

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




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

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


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

首先,需求(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)讓客戶看到,並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤,也會在一定時間內被發現。

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

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

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





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

11/16/2016

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

11/12/2016

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老鼠:不是被無謂的壓力掌握自己的命運,就是試圖跳脫牢籠。