執行SCRUM-24 -如果每件事都很重要，那就是每件事都不重要
我們自己的工作團隊，在上周的SPRINT檢討時，我請同仁A先完成某件緊急的事，但是同仁A說SPRINT已經排定需要完成的工作，如果先作緊急的事，SPRINT的成果將無法交付，並請身為產品經理的我確定何者先作。
其實這種狀況很常見，尤其組織龐大的體系內，更會因上級的交付，不得不處理這些緊急的事務。但是產品經理都知道目標，以及優先順序，並以創造價值，專注專案為責任，扛下壓力。因為臨時緊急事項不可以隨意安插給團隊，這樣會使工作團隊SPR...
執行SCRUM-23 -使用者故事(5)
執行SCRUM-23 -使用者故事(5)
最近對於使用者故事User Story的撰寫，對於團隊成員的意見，產生了一點反思。緣起是，團隊開發的怪手PMIS系統，由於客戶希望知道每周，專案人員在怪手的使用情形，所以需要增加系統報表功能。
針對客戶的需求，產品經理寫下了User Story，
這是管理者的需求，要向專案的PM回報怪手的使用情形，
1.我能夠知道某個時間區段(1周、2周、1月、或自設)怪手各個專案的活動紀錄，包含登出入的人員與次數、在怪手中的各項作業(每個功能的增刪修，人與時間)。
2...
一般記事5 - 當不同專業進入不同的市場，帶來的影響與反思
一般記事5 - 當不同專業進入不同的市場，帶來的影響與反思
1/14晚上看某個綜藝節目，邀請中天新聞的6位主播來訪談。大家都知道因為中天新聞被NCC關台，所以轉到直播平台去播報新聞。從訪談之中，述及2種平台的不同生態與樣貎。不論及好壞，只是這個發展讓我有些反思。
新聞是一種專業，我想大家都可以認同，而且大家的印象主播報新聞就應該在主播台、衣著整齊、一絲不苟地報導新聞。但是現在新聞的專業進入直播市場，也配合直播的習性作了一些改變，迎合觀眾也建立互動、多元、真實等好處。當然壞處也是有的，例如會不會公...
PMIS紀事-5 儀表板Dashboard製作的思考
PMIS紀事-5 儀表板Dashboard製作的思考
最近在作某公司PMIS儀表板的進版，同事根據我的描述作了一個版面，而我根據的來源卻是來自之前一些長官的指導，認為要有電視牆的概念，所以應該要有輪撥、監視器畫面、天氣之類的資訊顯示，在還沒深入思考之前，直覺認為，把大家想要的元素放進去就對了，而版面進版的規劃，也是朝這方面進行而產出。
之後參加某場會議討論，對於「電視牆」與「儀表板」有更深入的看法，兩者相同之處，
1.都是資料集成。
2.畫面有限，需要確定顯示的資訊(但是由誰決定呢??)。
3....
執行SCRUM-22 - 看板實務5 - 人月神話
執行SCRUM-22 - 看板實務5 - 人月神話
在軟體開發專案進行中，常會因為需求變更、除錯、測試、發佈等狀況發生，而導致期程落後的情形。此時，專案經理通常首先想到的是，投入人力資源，希望用更多的人力，提升專案開發的速度，企圖讓專案符合預定交付的期程。
在軟體業有著「人月神話」的說法。一般來說，100單位的工作量交給5人作，需要20天。若改成10人作，理論上期程會縮短成10天。但是，這個算法有個假設常被忽略，就是工作之間是彼此獨立的。而軟體專案的開發，通常涉及許多的資料規格、介面、流程等等，...
一般記事4 - 主管的職責之一，突發狀況的處理
一般記事4 - 主管的職責之一，突發狀況的處理
主管負有很多的工作，例如分配工作、管制進度、教育訓練、制定SOP等等，但是個人認為，突發狀況的處理，也是主管一項重要的工作。當狀況發生時，不管是緊急事件、危機處理或是臨時狀況等，主管應該幫忙完成，或是主要負責人。而不是將工作推給下屬，或僅負責無關緊要的事。
這樣作的理由有三個:
(1)依人力調配而言:一般的團隊平時皆是工作滿滿，依照著計畫性工作進行，所以不會有額外人力待命。所以，當緊急事件、危機或臨時狀況發生時，主管應該要主動支援處理。甚至是主要的...
執行SCRUM-21 - 看板實務4 - 緊急
執行SCRUM-21 - 看板實務4 - 緊急
在執行各種的專案中，緊急要處理的待辦事項常常發生，例如程式執行出現嚴重錯誤、客戶急需某功能修正，有時只是名詞修正，有時需要功能大幅度的調整。此時，在看板中對於此種情形，是另外開闢一條泳道(LANE)，並限制WIP個數。其原因是，緊急狀況的處理必須快速，所以獨立泳道是讓團隊能夠集合眾人的力量，快速地完成。此外，為了避免緊急工作與預劃工作一直切換，造成工程師多工，形成時間浪費，所以要限制WIP的數量。
不過，緊急工作除了藉由看板機制處理外，管理者要思考...
執行 SCRUM-20 - 看板實務3 - 作業
執行 SCRUM-20 - 看板實務3 - 作業
開始作業之後，就按照之前分配的工作及順序，每位工程師都有自己應該負責的部份。通常設定WIP很小的流程區間，會發生瓶頸卡住的現象。有時為了讓工作能夠進行，或者老闆不想看見某個員工閒著，可能會把WIP放大，但放大後，就會產生多工及排隊的現象，所以要謹慎為之。
另一方式是可以設置緩衝區，例如在開發階段，再分成「作業中」及「已完成」，如圖3所示，讓工程師A將完成的待辦事項放「已完成」欄位，可以繼續拉動下一個工作。此外，在完成排定工作後，在SPRINT結束...
執行SCRUM-19 - 看板實務2- 分配
執行SCRUM-19 - 看板實務2- 分配
從使用者故事拆分成待辦事項後，要不要指定誰來作，是個問題。一般看板是不指定工程師，由開發人員依序拿取待辦事項進行開發。而SCRUM是要指定每項待辦的負責工程師。我們團隊因為工程師專業不同(前端工程師、介面UI/UX設定)，所以工作比較無法彼此支援，所以我們採取指定的方式。
待辦事項指定負責人員後，接著要估算story point。我們是利用費式數列來估算(1,3,5,8,13)，是以待辦事項的規模來作評估。這個部份必須說明的是，數字的估算是以完成待辦...
執行SCRUM-18 - 看板實務1-初始
執行SCRUM-18 - 看板實務1-初始
在開始看板實作之前，我們似乎忘了作一件事，就是設定各個階段的WIP(Work in Progress)。WIP的限制是避免多工現象發生，進而產生浪費的情形。但是WIP的設定，通常要依團隊、專案的狀況而變化，沒有一種標準或公式可供參考。而且數字大些，造成多工浪費，數字小些，造成人員閒賦，老闆看了心情不好，所以如何取捨，要多多嘗試，無一定論。
在開發階段有2位工程師，WIP暫定4，測試階段有1位測試員，WIP暫定為2。至於預備階段，則要看每位工程師SPRI...
蔡柏良
以土木專業(土木技師)+專案管理(PMP認證)+資訊技術，在營建產業領域貢獻心力