顯示具有 專案進度 標籤的文章。 顯示所有文章
顯示具有 專案進度 標籤的文章。 顯示所有文章

9/14/2019

絕不犧牲品質 (成為主管的31堂課)



無論是大型軟體公司,還是小新創公司,軟體主管常會面臨到時程壓力。畢竟快速交付產品並且到市場驗證,遠比花個數年慢慢搞出一個可能沒有市場的產品來的有用。速度絕對是成功的關鍵因素。再者,孫子兵法有云:兵聞拙速,未睹巧之久也。似乎都在說速度比任何事重要。

然而,做完軟體主管,唯一不能做的事情,就是犧牲品質,現在犧牲品質,下一個犧牲的就是自己和開發團隊,接下來就是公司本身。

兵聞拙速,未睹巧之久:指的是快速決定一個方向,並不指隨便打一場品質低的仗。品質低劣士兵前往戰場只有死路一條(或者只能期待對方更差)

為什麼不能犧牲品質?

(1)如果PM/Sales/BD說可以不再太在乎品質?我需要在乎品質嗎?


當然要在乎品質,事實上,負責任的人會是決定的人。當軟體出現問題的時候,難道PM會負責改code上patch?最終負責的人就是會真正感受到痛苦,並且付出代價的人。軟體品質有問題,會付出代價的一定是軟體開發團隊。其他人既然不能承擔代價,當然就不能決定品質。

(2) 這次改動範圍大,但是有環境上的時間限制deadline-driven的開發,難道我能說品質不好就不上線嗎?例如耶誕夜12/24要上線,無論如何耶誕節都會來,已經做得差不多了難道就不上線嗎?


品質是可以有範圍定義,畢竟不能可能期待大型系統完全沒有bug。但是,即便是有環境上時間限制,如果品質真得無法達到要求,上線只會讓事情變得更糟糕。最近的例子是7 pay,而我們其實可以輕而易舉地找到很多過去的例子。


那麼,為什麼還是會被「逼」上線?許多時候軟體專案主管會認為「這是上面高層交代」他們應該理解時間這麼短,大家工作這麼拼,每天都加班,品質要是有問題應該「高層能理解」! 這絕對是錯誤的認真,品質有問題的話,「高層」只會知道你們做得不好,更糟的是,你自己已經知道做得不好,連自己的良心也都過不去,而使用者拿到品質差的軟體,當然只是浪費他的時間,這會是個lose-lose-lose三輸的決定。相反的,直接說品質不好無法上線,高層也是知道你們做得不好,但起碼你不會對不起自己的良心,最起碼不是雙輸決定。

(3) 真的沒有時間怎麼辦?


時間資源,品質,規模範圍:這三個軟體開發的要素最多只能要兩者。不可能三者兼具。要三者兼具的話,會自動犧牲品質。然而,其實品質是可以控制,但絕對不能犧牲,因為一旦犧牲,整個軟體不能做出本來該做的事情,有再多功能,用再快時間上市都沒有意義。
因此,其實最應該考慮的是規模範圍,簡單的說就是盡量減少不必要的功能。這其實完全符合Lean-start-up(精實創業)的精神。





10/14/2018

企業巫醫:20分鐘搞定「工作做不完」的問題?



上班族常會遇到的老問題是:「工作做不完怎麼辦」

工作做不完是個老問題,解決問題的方法也很簡單,然而簡單事情不見得容易做。更重要的事情是:你需要正確的檢視現況,才能真正解決問題。因為每個人的「工作做不完」的實際情況都不同。舉例來說,假設你是在無良的黑心老闆血汗工廠,那麼你的工作做不完的解決方式應該是儘早辭職,而非增加效率。

以下步驟確保可以幫助你解決這個問題:


步驟一:暫停!休息5分鐘! 利用15分鐘進行計畫



1. 休息5分鐘


除非你的工作是急診室或者核電廠這類人命關天的地方,一般的上班族,一旦遇到工作做不完,慌慌亂亂急急忙忙的時候,其實第一件事情應該先放空自己。找個安靜的地方(萬一真找不到可以藉故離開辦公室幾分鐘),先盡量將自己的思緒清空,沒辦法放空冥想的話,打個手遊也可以。當你的思緒紊亂,壓力暴增,往往會使用直覺處理事情,使用直覺處理並沒有錯,但如果「只靠」直覺處理,就會失去成長和學習的機會,更糟的是,直覺處理事情通常和情緒結合在一起,關於這點請參考腦的結構杏仁核

所以讓自己休息五分鐘!


2. 計畫15分鐘


休息之後,拿出紙筆,先對現況做計畫。
列出事情的四個象限:重要/緊急矩陣(參考這裡) 。
如果你已經熟知這個事物分類方式,那就可以直接挑過這段,並思考自己為什麼不做這件事?

 2.1 重要且緊急:

 就是要專注處理的部份

 2.2 不重要但是緊急:

 要犧牲,或者交給別人,或者是忙碌狀況。但通常這種事情都是工作做不完的主要來源。最好的方式是縮小事情的影響。常見不重要但緊急的事情,不外乎老闆索取各種資料,感覺很急,

 2.3 不重要且不緊急:
  千萬不要去做它!普通上班族通常不小心會落入去做不重要且不緊急的事情,而且還不自知。最常遇到的事情是:對小事情花時間做無謂的討論。

 2.4 重要但是不緊急:

  千萬不要忽略他!忽略這裡,就無法徹底解決工作做不完的問題!



步驟二:按照計劃:逐一解決重要緊急的事


在計畫中,條列的重要與緊急的事情,要「逐一」處理。先不要想要同時處理,做個清單,搞定一個事情打個勾。

這聽起來簡單做起來很難。

有幾個簡單的執行要點可供參考:

(a) 自己找到專注工作的場地。很多工作其實不限定工作場合,只要你事先跟老闆講好,其實是可以嘗試找不會被打擾的地方好好專心把事情搞定。例如,在主管同意之下,中午三小時在公司附近某咖啡廳寫程式。在近年來開放式空間流行的狀況下,這點相對重要!

(b) 不要隨時檢查email與短訊。除非你的工作是急診室醫生或者某些人命關天的意外處理者,否則不應該時時檢查聯絡工具,你應該是控制工具的人,而非被工具控制的人

(c) 設定解決的定義。緊急而重要的事情的「回應」不代表解決。解決事情要像是恐怖片裡的殭屍,當你沒有徹底將它打爆頭,它很有可能會再爬起來咬你一口。


步驟三:重新檢討計畫,找到提高效率的方式,專注於重要但不緊急的事情規劃和執行


為什麼要專注於重要但不緊急的事?因為重要的事情如果都先處理好,可以大幅改善「未來還會有工作做不完的問題」 而且同時減少重要且緊急的事情發生。畢竟很多重要緊急的事情,就是當初重要但不緊急的事情一路拖延導致後來變緊急。

因此,這步驟用以確保可以有計劃地執行「重要但不緊急」

有幾個方式可以確保自己不遺漏「重要但不緊急」的事情

(a) 隨時檢查中期目標:組織通常有偉大的長期目標(例如登陸火星),但也由於通常太偉大,所以必須要逐步以中期目標達成。個人應該將中期(3~18個月)目標當作為重要的事情,而非最近短期目標。因為,短期事物常常會被迫打斷修改,就會容易淪落於被時間追趕而非控制時間。

(b) 每天排定固定時間處理「重要但不緊急」 即便是1小時,長期下來也會有效果。萬一不得已要加班,應該要加班處理的並非緊急的事,而是重要的事!

(c) 其他 (有空再說明此處)




步驟四:按照計劃,完成重要的事 ,並執行提高效率的方式


倘若已經執行到此。就可以考慮提高效率的方式。
其中最重要的方式就是「提高本身知識與能力」

提高工作效率有很多種方式,請參考這裡,或者這裡


步驟五:檢討成效,修改計畫


每個計畫都應該確實被檢討,自我檢討當然很好,不過,秘訣是請你認為做得比你更好的人幫你檢討計畫。

倘若這篇文章有某件100%保證有用的方式,那麼「請一個你認為比你厲害的人幫你檢討你的計畫和成效」是最最有用的一點。

3/06/2018

何謂:資深工程師


在招募人才過程中,經常被問到「資深工程師的定義是什麼?」

以軟體開發的角度而言,資深工程師有三個面向:

* 技術能力
* 實質經歷
* 團隊合作

聽起來簡單,其實不太容易。

技術能力指的是對「現在使用的技術的直接掌握能力,以及持續成長態度」。

實質經歷指的是「過去曾經做過哪些事,取得哪些成果」。

團隊合作和前述的實質經歷略有關係,不過指的是「處在組織裡,透過自己的能力對組織造成正面的影響」

在人才招募中的過程,在有效時限內,對應徵者針對這三個面向判斷是否符合「資深工程師」是有點難。有幾個方式可供參考。

技術能力


現在使用的技術的直接掌握能力。最簡單的方式是設計考試或者實做作業,根據其結果來判斷技術能力。典型的證照例如SJCP, CCNA都屬於此類。當然, 也常有組織採取直接面談的方式來判斷技術能力。

直接掌握的能力,當然不包含應徵者,自我宣稱說:"這個我google的到",或者,"我不記得但是查得到"。畢竟大家都可以查得到,既然都查得到就不是判斷的標準。

技術能力的判斷上:考試,作業,面試各有其優缺點。簡單的說,人為介入越多,就有不客觀的判斷;但是,無人介入的純客觀單純考試,難以判斷設計概觀等複合的技術能力。

使用半開放性的實做作業,加上2人以上,事先決定好的面試結構,應該是比較妥善的方法。不過,請避免幾個認知偏誤:(1)月暈效應 (2) 羊群效應 (3) 觀察者效應。這些偏誤,在技術面試時會特別嚴重,因為許多人會誤以為技術面試很「客觀」,但實際上,所有面試都很主觀。唯有特別注意偏誤,才能盡量降低主觀性。

月暈效應:因為某些光環,讓面試官覺得應徵者可能很厲害,而沒有去驗證事實。舉例來說,有三十年程式設計經驗,又做過某些驚人專案,就假設此應徵者「隨便學什麼都會」。又或者某應徵者可能是網路傳說的「大神」,就覺得他可能很厲害對團隊很有幫助。

羊群效應:面試之後的討論,如果有人先有意見,沒意見的人可能就會追隨之前的意見。

觀察者效應:因為外表或履歷表的直覺或第一印象,而讓面試官試圖尋找錄用或者不錄用的證據。而非客觀的先收集事實。

最後,在技術上持續成長態度很簡單,能認知到一個事實「當自己學的越多,表示自己不會的越多」,並且真有實質行為-固定閱讀也好,非工作之外寫程式也好,其他任何實質行為佐證對資訊技術有成長喜好。


實質經驗

所謂資深,當然表示在軟體開發類型的工作上,有很多經驗,並且這些經驗取得成果。

資深的實質經驗,通常包含「好事」以及「壞事」。更重要的是,經歷過的壞事,知道如何真正改善它。並且認知到,不是所有錯誤都是別人的錯,必然有自己的錯。

面試實質經驗也一樣要破除上一段的認知偏誤。就不再贅述。

團隊合作

資深工程師,能體會真正的團隊合作要素:(1) 技術溝通透明 (2) 控制進度透明 (3)  立基於事實的溝通

技術溝通透明是指:任何單純技術上的選擇,使用,表現,都是透明的。簡單的說,能真正了解技術完全不需要任何的隱瞞性。

控制進度透明是指:了解透明進度對團隊非常重要,並也了解:控制進度的單位是時間,而不是工作內容。

立基於事實的溝通是指:雖然許多事情必須要有假設和猜測,但就工作上的決定,必須要盡量立基於事實。舉例來說:「我覺得最近的release可能會有問題」這就是一種猜測的說法,然而:「最近的release並沒有執行回歸測試,所以我覺得可能會有問題」這也是一種猜測,但卻是立基於事實的猜測。




11/16/2017

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


孫子兵法:夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!

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

版本控制系統(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人,某些技術確實不見得能完全掌握,但專案管理者,仍然要保有部分自行檢查的能力。




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






8/14/2016

Scrum (實況) - 瞭解事實才能領導專案






近年來在符合Agile精神的各種專案方法論中,Scrum應該是最簡單,也是最熱門的。

雖然簡單,但要掌握其精神,必須對抗長久的習慣,而這並不容易。

目前市面上也衍生各式各樣Scrum架構的作法和細節,從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神,則「實況:瞭解事實」是最最最根本的Scrum精神。(註1)

Scrum架構中,理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。



1. 角色


實況(Scrum)只會有三種角色

1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)

而最根本的Scrum務實精神,在角色所扮演的任務中展露無疑。

也就是:

(A) 只有產品擁有者,才能排定產品功能的開發順序(product backlog)!

(B) 只有團隊成員,才會決定每一段時間,哪些功能會完成!

換言之,什麼事情先做後做,交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間,是由做事情的人 - 也就是團隊成員 - 來決定!這個作法完全奠基於事實,並且適用於絕大部分的情況。

這和傳統專案有很大的不同。許多專案的時間預估,都不是做這件事情的人來預估。自然就一定不可能預估的準確。

不過,在許多「精采的成功個案」中似乎常常會有一個超強的產品經理,能主導市場,產品進度,甚至使得專案團隊有突破性的創新結果:典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者,主導進度的鐵證?

然而,事實上絕大部分的產品經理都不是賈伯斯。可是,大部分的企業,卻可以雇用到接近賈伯斯擁有的研發團隊品質!!因此,絕大部分的情況下,將產品研發功能相關執行與時間預估,交由團隊成員,才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多,並且也能提出「具體證明」。(就如同大部分的資深程式設計師,都能提出具體的證明 - 程式碼,佐證他的經歷一樣)



2. 以結果來衡量團隊效率


在實況(Scrum)中,一個項目完成的定義就是「完成」。而團隊的速度,取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度,大概很難和自己預估的一樣。

然而,過了兩三個Sprint之後,團隊速度應該已經「固定」,而這個完成工作的速度,就變成「事實」。

要看研發團隊速度在這時候很簡單,打開燃盡圖(burndown chart),算一下每段時間 - 例如每週或月 - 可以完成多少單位,自此之後,要估計時間,只要能有效估計每個功能(user story)規模大概多少單位即可。

這個事實,原則上不會改變。然而,產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇:(a) 更換產品功能。(b) 改變團隊。

更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入,考慮市場都在台灣,因此就先做facebook登入即可。

當然產品擁有者也可以改變團隊,重新組織團隊,更換成員。但一旦改變團隊,就必須重新啟動新的sprint,而也會重新產生新的速度。



3. 以取得事實來固定會議時間


Scrum(實況)的會議,必然鎖定會議「目的」以及「時間」。在事實的基礎下,兩者有很大的關聯。

以每日會議為例-- 不管是不是站著開會,一定是一天工作的開始,最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事:

(a) 從上次開會到現在完成了什麼,沒有完成就說沒有 
(b) 今天打算做什麼,而且有什麼會完成 
(c) 遇到什麼困難需要ScrumMaster協助。

這三件事情,只是說明,若有問題,也是對說明的問題,絕不應該討論。要討論是開會之後,相關人等,聚集在適當的地方,最好是某個人的電腦前面,開始幫忙解決。

通常最容易花時間就是遇到困難的時候,大家紛紛都想提議見幫忙,但這並不是「這個會議的目的」。每天5-7人聚在一起,是為了將大家對狀況的認知統一,僅此而已。因為一旦開始討論困難,很有可能變成A和B熱烈的討論起來,其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間,具體果斷的打斷討論,讓會議前進。

或許有些人會認為,這樣會破壞創造性思考和創意思維。然而,事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後,Scrum Master可以根據遇到困難的情況,重新找適當的人,並且到適當的地點 -- 也就是電腦前面,手腦並用的解決問題,而非在會議室空談。

其他在實況(Scrum)框架中的會議,像是Sprint啟動會議,Sprint結束會議,Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的,特定的時間完成。


將能專注控制的事情完成,才能把時間與思維,留給創意。





註1. 因此,敏捷開發中的Scrum方法,中文翻譯應該叫做「實況」,至少也比google翻譯為「爭球」來的好。

註2. Scrum的學習可以參考這裡-> 學習Scrum,或者->Scrum認證

4/12/2016

你真的知道專案進度嗎?



只要是從事程設式設計相關工作的人,必然曾經參與某專案(Project)。專案的大小不一而足,有些只有幾天或幾週,有些橫跨數年。

如果有幸負責專案管理,則無論規模大小,掌握進度是除了管理利害關係人期望之外的第二重要的事情!!而實際上,要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後,才能調整應變可能發生的意外,降低風險。


只要看軟體專案進度的「掌握方式」,就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理,可以單靠自己,就能足以掌握專案進度。

一個普通的專案經理,可以利用流程,規範,加上開發成員的協助在一個合理的時間範圍內,掌握專案進度。

一個很爛的專案經理,會利用各種會議,各種形式文件的填寫(WBS之類),直接或者間接的資訊,花很多時間,仍然不能掌握專案真實的進度。


很遺憾的是,好的專案經理很少,好的軟體專案經理,更是極端的少。因為他同時需要具備技術能力,透悉問題的能力,以及有效的專案管理能力。



要點一:以時間為單位


非軟體專案管理上,掌握進度的單位有很多種,例如「以執行預算」或者「實獲值」來掌握進度。(請參見PMP相關網站)

以軟體專案而言,「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師:「A功能進度如何?」,而他回答「只剩下UI整合,加上DB欄位定義調整,就快好了」。這樣的回答,對於掌握進度幾乎完全沒有意義。因為,該程式設計師可能在A功能花了1天,然而UI整合與DB欄位定義調整,可能還需要另外花上3天,換言之「就快好了」根本不是真的,基本上只完成了25%。但該程式設計師並不是故意要說謊,因為或許最難的就是那25%。


程式設計師若以困難度為考量,進度就像下圖,功能完成之後,就「快要好了」。





但如果以實際時間進度為考量,則如下圖,功能完成之後,只完成了25%。離「快要好了」有很大的距離。




大部份的軟體工程師,著重於困難度。這並非不正確,只是專案管理在掌握進度時,實質進度必然是以時間為考量單位。即便「這件事情很簡單」,也必須要考慮「簡單的事情還是要有人去做」。



要點二:產出的事實


直覺上,大部份的產出當然是程式碼。實務上,非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。


基本情況


最基本情境是,根據規格要完成功能A。一開始,程式設計師寫好了程式碼,並且自己編譯(compile)並簡單測試之後,簽入(commit)到版本控制系統中,並且和其他相關程式碼合併(merge)之後,整合成新的版本,並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中,寫程式(coding)可能佔了70%的時間,另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於:整合成新版本並經過QA測試後也沒問題,至此,功能A才算完成。


進階情況


在一個稍微複雜的專案裡面,根據規格要完成的某任務,實務上可分為「功能A」與「功能B」。一開始,幾個程式設計師分頭完成自己負責的功能,並分別自己compile並簡單測試之後,功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時,QA分別進行測試,沒問題之後,協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程,或多或少有需要修改的程式碼,也許在合併工能A的時候沒問題,但是在合併功能B的時候有出現問題,並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於,最後新版本經過測試也沒問題。至此,某任務才算完成。

但是,這和基本情況不同的是,整個過程很長,從數天到數週都有可能。coding本身可能僅佔50%。而合併,測試,在合併,修改等等可能佔了另外50%的時間。

與前述要點一相同,專案管理者要能掌握實際上的進展,跟「未來還需要花的時間」。在複雜的情況中要掌握,除了最後的產出事實之外,中間的進度掌握,需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控,大部份是由專案經理個人獨立可以完成。其中,技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例,專案管理者如要能判斷產出的事實,必須要能做「自己獨立」做下列幾件簡單的事:

1. 在版本控制系統中(git, p4, cvs等),找出過去一段時間的所有commit過的程式碼變更,誰去變更,為什麼變更。

2. 在最近的新版本測試中,看到哪些新功能確實增加

3. 自行檢查目前bug的清單,並且找出幾個關鍵的bug



假如你是專案管理人員,而你不認為上述事情是自己應該獨立進行,或者你認為上述事情會花太多時間,


請參見下節:除去迷霧。


要點三:除去迷霧


許多「非技術背景」的專案管理人員,常常用各式各樣的大大小小的會議,來獲取專案進度的掌握:每天早上例行會議,每隔兩天來執行bug review,每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行,過多的會議,肯定會「拖累」專案進度。

如果你是一位主管或專案經理,而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上,並且只是為了呈報「目前進度」。那麼,你實在是個很糟糕的主管,要麻,你就盡快辭職,要麻,盡快提升自己的專案管理能力,否則你的存在只是浪費大家時間

了解目前專案的進度,等於是除去迷霧,看清事實。除去迷霧的方式,必須要是「貼近事實」與「清晰的技術檢視」。


貼近事實


事實有時候很容易了解。例如:app要可利用facebook帳號登入。此功能容易判斷有完成,或者沒完成。

但有些時候事實很複雜。例如:某程式設計師宣稱,app要可以利用facebook帳號登入,他需要花12個工作天完成。12個工作天到底是長還是短?如果覺得太長,是因為寫程式的人能力不足?還是既有的app過於複雜,所以要加任何新功能都很難?


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解,他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計,12天就拿來做這一個功能阿,你還要我花時間去分哪天做什麼喔!我哪來這個時間」。這表示事實是,12天根本只是沒有基礎的猜測,他可能22天才完成,也可能2天完成。

絕大部分軟體專案,程式設計師的某行動完成都應該至少可以以「天」為最小單位,(也可是以「小時」為單位,不過太細的單位也會造成不必要的麻煩)。

超過2天估計,就應該可以分成「兩個以上的事情」,超過12天的估計,應該是建立在至少6個以上的某行動完成。


不能分解行動,表示沒有計畫,也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作:

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出,這樣的WBS其實完全是在應付專案經理,對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人,專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面,將android studio打開,了解登入在哪邊加icon,如何到facebook取得App ID,facebook sdk如何使用。

對於有技術領導背景的專案經理,頂多花上一小時,就應該至少可以分解此任務如下:

(1) 到facebook developer網站了解sdk:1天
(2) 申請App ID以及了解相關規定:0.5 天
(3) 登入Icon要和美工討論實作方式:0.5天
(4) 執行登入,取得session:1天
(5) facebook帳號與其他帳號在db處理的不同:2天
(6) 與QA討論測試方式:1天
(7) QA測試:1.5天
(8) 其餘模糊規格的討論,例如是否可登出:0.5天

加總起來可能僅需要8天。但重點不再於天數減少,重點在於此計畫已經破除進度迷霧。當這個計畫開始執行,到了第三天,如果該程式設計師已經開始撰寫登入程式,那麼表示進度和預測相同,但如果他還在申請App ID,表示進度落後,專案經理需要調整進度,或找人幫忙。但無論如何,絕對在計畫開始執行的前期就已經知道如何處理問題,而不是到12天之後,突然發現根本無法完成。


(Android如何利用facebook帳號登入,請參考這裡)


清晰的技術檢視



前述的app利用facebook登入,專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間,其首要條件在於具備清晰的技術檢視能力。

簡要的說,能區分技術難度,區分使用該技術對於專案的影響,以及,使用技術可能產生的風險。清晰的技術檢視能力,會有效提高對整個產品或者專案的洞察力。雖然,洞察力可以經過訓練磨練取得相關經驗,但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度,每個專案經理所需要的技術能力各有不同,以下有個簡單的軟體專案經理自我問題清單,回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模:(行數, 檔案數, 平均每工作日增加的程式碼數量),無須依靠其他專案成員嗎?

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug,無須依靠其他專案成員嗎?

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題,無須依靠其他專案成員嗎?

* [Yes/No] 你會手動編譯專案,無須依靠其他專案成員嗎?

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況?

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時,你可以自己檢查該進度是否真的完成,無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式(例如查閱系統log之類),無須依靠其他專案成員?

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程,無須依靠其他專案成員?

* [Yes/No] 你能單靠記憶,繪出目前專案個模組之間大概關係,無須依靠其他專案成員?