真實故事：
有近70個工程師參與的軟體專案的組長會議中，除了專案經理之外，另有8個負責領導開發不同模組的組長一同與會。
例行的報告進度後，專案經理看了一下大家，帶著遲疑的臉說：「在兩三個禮拜大家的模組就都完成了，如果沒有問題的話，應該整個系統同時也都弄好了吧？」
負責UI以及整合模組的組長，看著大家漠然不語，也只能硬著頭皮的說：「現在最大的風險在於：如果所有模組都在最後實現完成，那根本不會有人知道組合起來會發生什麼事，所以我只好老實的建議，要不就額外增加整合測試的時間，要不就要減少某些模組的功能讓他可以早點進入整合」。
但其實大家心裡有數，這麼多人在短時間開發出來的系統，不可能在短期間整合完畢。
未料，專案經理似乎沒有體會事實，他說：「接下來大家就要在努力一點，就快要搞定了」。
可能是心情不好，在加上長時間加班的火氣：某組長就說：「我們到目前為止的問題是在於我們不夠努力嗎？」。
專案經理當然說：「不是，我知道大家都很努力...」話未說完，該組長就說：「既然問題不在於我們不夠努力，為什麼叫我們更努力，就可以解決問題？」。
專案經理：「...」
許多失敗的專案管理者，在遇到困境時，只會用幾個永遠不會有好結果的方式，來試圖解決問題。常見的方式像是：無意義的加班，默許降低品質，虛報進度，哭訴人力不足要求增加人力。在緊要關頭，這些作法都不會有好效果。只會這幾種方式的專案經理，儘快離開管理位階，才會是組織最大的貢獻。
最有天賦以及領導力的管理者，通常擁有不可言喻的直覺，並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦，特別是作為軟體專案經理者。很難具備以敏銳直覺，完成複雜系統開發。
然而，專案管理其實不需要天賦，所有人都可以透過自我學習，了解專案管理的精隨，透過自身的努力作個稱職的專案經理。和所有重要的事情一樣，首先是要了解事實。在略具規模的專案，應該透過事實的呈現，來了解專案目前進度，可能的風險，遭遇的困難，以及解決方式。
而且，只有盡可能了解事實，面對事實，才能引發可行的創意行動。
事實的取得有三個面相：
恰當的衡量：
恰當衡量，是判斷專案經理的好與壞的關鍵之一。恰當：簡而言之，必須是可行，正確，有效，有意義，精簡的衡量。
近年來Scrum蔚為風潮，其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後，burndown chart可以清楚的顯示，現在專案的進展，和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實，讓Scrum的團隊在取得洽當的衡量之後，做正確的因應。
不恰當的衡量，出現在幾乎所有失敗的專案場景裡。
有些專案經理會依賴WBS的圖表，來看進度是否得當，但WBS是固定的無法調整，即便調整，也很難追溯過去調整的細節。WBS在軟體專案中，很難達到可行，正確，精簡。
有些專案經理，會依賴團隊成員報口述「完成」來斷定進度，在沒有看到「實品」（例如程式碼，每天自動編譯測試的build等等），口述完成不是「有效」衡量。
最慘的專案經理，會透過大型，繁複，耗時的會議，逐一確定已經完成的項目，花在「了解事實」上的時間，遠超過「做事情」的時間。這種本末倒置的既不可行，也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理，花上不可置信的時間了解事情而已。一個不超過10人的團隊，要是每個禮拜耗費總時超過4小時在這類型的會議上，就表示專案經理沒有對技術有透悉能力，儘快換掉專案經理會是對團隊最有利的作法。
承認不確定性：
沒有人可以預知未來，必須承認不確定性，並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時，用過去之已知事實，並加上不確定性。
例如：未來3個月團隊的總人時？假設團隊成員共10人，每個月22個工作天。則總人時推測為220人日時，等於表示沒有推測。這220人日，根本沒有把「過去已知事實」考慮進去。比較好的推測應該是，220人日，減到(1) 過去3個月，這10人的總休假生病天數。再減掉(2)可能的季節性假日，例如颱風。再減掉(3) 組織已知的活動，例如員工旅遊，大型會議等等。當然，這些以過去的數字推測未來不一定準確。但是，以過去的事實推測未來的不確定性，總比當做沒看到的好得多。
一般專案管理中，不確定性會用風險管理來衡量並且控制。正是「真正」的風險，就是坦然面對事實。
失敗的專案經理在每週的報告中，會把「人力不足」當做風險，試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了，目前人力不足是風險，但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。
人力不足壓根就不是真正的風險！如果人力不足是真的，那麼專案時程規劃不正確，對技術掌握不足，專案經理沒有創意來解決問題...這些才是真正的風險！假如真有人力不足，它必定不是突然出現的可能機率，它是「已經存在的必然」，風險必須是某種可能會出現的事件，萬一出現，會對專案造成及大的影響。例如，在建築專案中，大地震就是風險，必須要規範出現的機率，但它很有可能不會出現。
把不正確的風險當風險，以及不把真正的風險當風險，都是不願意面對事實的畏縮專案管理者會做的事情。
理解認知偏誤：
在專案管理中，人類認知偏誤(Human Bias) 不可能全部去除，但可以盡量避免。根據事實原則，專案經理應該承認：認知偏誤的存在，盡可能減少影響，但也要理解，不可能全然去除認知偏誤，畢竟人非聖賢，也非機器。自認為已經去除所有認知偏誤，等於是一種認知偏誤。
去除是不可能，理解並且降低偏誤，是取得真正事實的最重要的方向。
例如：在code view的精簡會議中，常出現偏誤在於，極為資深的員工的程式碼，通常比較不會被挑出問題。但根據研究，只要運用程式語言超過2年以上，資深與資淺員工，在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤，最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前)，要求成員利用email寫出自己的意見，而意見也可以是匿名。
高階主管為另一個例子：高層主管對團隊的了解，大部分來自第一線主管或二級主管。高級主管必須要認知，取的團隊資訊，必然經過過濾和扭曲。這幾乎是不可避免的事情，畢竟第一線主管或二級主管也是「人」。例如，如果發現有某團隊老是有問題，進度不佳，人力似乎永遠不足，高級主管如果找第一線主管了解原因，不會有第一線主管直接了當的說「是我的問題」。但是，一個團隊有問題，75%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。
偶爾進行的團隊訓練活動，也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在，自然就有可能減少偏誤的發生。
只要能根據「事實」，降低並去除認知偏誤，比較有機會在困難的專案狀況下，發揮團隊潛能，並且找到有創意的解決方案！畢竟，根據「事實」，一個營利組織必然希望團隊能帶給組織真正的價值，而非僅只是達成表面目的。
真實故事 1:
某個陰暗的冬天早上，悠晃進辦公室的當下，看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康，也不會是祈福默禱活動。好奇的在旁邊觀察一下，在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度，並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。
真實故事 2:
某一次專案研討會中，演講者詢問與會人士，Scrum估計工時的時候，每個人每個工作天應該是多少小時才合理？新鮮人多半回答6-8小時。某些資管企管碩士生，大概讀了許多書，回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。
Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂，很容易在現有的團隊中採用運作，或許是因為趕流行？許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum，也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內，在台灣業界Scrum似乎無所不在，成功案例一個比一個容易找到。
但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性，克服與目標之間的各種障礙。但也因此，把握住Scrum的精神，最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。
追本朔源後，總是可以看出：太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻)：透過個案的深入觀察，兩位日本學者對於有彈性，有效率的產品開發過程中發現一些相似的點：內建的不穩定性，自我組織的團段，互相重疊的開發流程，多面向學習，精微的控制，組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體，例如汽車或者影印機。
乍看之下，和現在的軟體開發方法論似乎沒直接關係，但是，而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構，遠比傳統官僚結構，更能在短時間達成高效率，甚且更容易產生創造性思考的價值。
理論歸理論，如何實踐理論在工作上才是重點。
近年來畢業的資訊科技背景的學生，的確在學校多少聽過Scrum，許多資管的學生甚至上了不少相關的課程。但就實務的角度，除非教授像這位荷蘭的老師（eduScrum）一樣，真心誠意的採用Scrum在課程的本身上，否則對剛畢業的碩士生或大學生而言，Scrum就只是個似乎看的到，卻無法做得到的事情。學界與業界間的藩籬，仍然巨大看似難以突破。
因此，提供以下有三個務實的方式，可以作為剛畢業的學生突破藩籬的參考。
1.理解事實
對於剛畢業的學生來說，理解事實，是基礎中的基礎，但也確是整個職業生涯需要不斷強化的地方。
以Scrum而言，每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態：「還沒開始」，「進行中」，「已經完成」。
在每日stand-up，最常發生的是產生另一個狀態「快要完成」，也有可能混淆「已經完成」和「進行中」，更糟的是混淆「還沒開始」與「進行中」。
舉例來說，小馮在每日stand-up會議說：「訂單查詢功能已經差不多了，因為訂單查詢結果的排序雖然弄好了，可是分頁還有點問題，但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡，這種描述不但沒有必要，而且會引發更多問題，因為，接下來大家就需要探究所謂快要好了，是還要多久？最簡單正確的描述應該是「訂單查詢功能正在進行中，原本預計2天完成，已經花了1天，接下來1天會繼續完成，目前估計和預估所需時間一樣是兩天」
重點並不在於咬文嚼字，而是在於對事情的清楚認知。當意識到一件事情沒有完成，在產品開發裡，終究是沒有完成。
每個人多少都有報喜不報憂的心態，也多少都希望別人對自己有好印象。因此，常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議，僅說明三件事情：1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已，不多不少。
剛加入任何形式的開發團隊的人，能先確切的掌握和自己相關的事實，是看似簡單卻需要時間實現的基礎。
2.控制時間
既然Scrum是屬於Agile的方法論之一，當然符合最早的Agile 12項基本精神（參見這裡）。其中幾個精神和時間有莫大關係，例如，可用的軟體大重於詳細的文件，回應變化重於遵循計畫。而Scrum是最能達到的方式。
以團隊的角度，burndown chart(燃盡圖)是最能表達團隊目前能力，與專案時間預估的方式。他的做法極端簡單，請自行參考wiki。burndown chart展示了血淋淋的事實，可以透過過去一段時間的完成速度，有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤（例如：大家再努力一下，接下來某東西可能比較簡單...諸如此類），因此在沒有能力，沒有創意，沒有實務開發經驗的產品或專案經理的眼中，burndown chart只是拿來參考用，不能給長官看到。
以剛畢業的學生而言，最難的事情在於預估時間，特別是在比較長期複雜的任務。
解決方式為兩步驟：
(I) 決定第一件要做的事情並且去做
(II) 額外增加研究項目(也額外增加時間)
(I) 決定第一件要做的事情並且去做
對於很長的項目(backlog)，表示他可能隱含數個子項目，而每個子項目可能也不小。例如，讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人，分拆項目可能會遺漏，但是，有分拆比沒分拆好，有估計比沒估計好。有分拆之後，如果有漏列項目，也可以清楚知道有漏列。有估計之後，估計的錯誤以後還可以作為其他項目的參考。
而分拆之後，就直接進行第一件要做的事情！確實的腳踏實地去做！不用等，也不用試著把項目分拆的很精細，估計得很詳盡。因為萬事起頭難，當已經開始進行，就很容易知道之前想法是不是正確，還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇。
(II) 額外增加研究項目
如果分拆之後，很明顯的仍然難以著手，就額外列出一個有限定時間的研究項目在最前面。換言之，花個固定的4到12小時進行學習與研究，將這件事情也列入整個開發流程中。時間必定要是有限的，畢竟絕大部份的產品開發，無論多困難，都還是在有限時間一定可以找到解決方案。
從另外一個角度而言，如果在有限時間無法找到合理的解決方式，對新鮮人而言或許你也並不適合做這個行業，可預見的未來裡，或許你會勤能補拙，試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙，只是專長不在此，在有限的時間投入內，了解自己的專長不在此，或許更能幫助新鮮人找到最能讓自己發揮專長的地方。
3.確保產出
每個backlog表示一項「產出」。只要前兩個精神：理解事實跟控制時間，已經有效掌握，那麼這一項應該不會有太大意外。然而，對於剛畢業的學生來說，無論程式能力有多強，對於產出的完整性，常常會有誤解。不過這樣的誤解其實也很容易釐清。
一般軟體開發團隊，某人的某功能程式碼寫完之後，會經過以下階段：
1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認
在Scrum一開始，便應該定義何謂backlog完成？
- 會是 1.程式碼完成就算完成？
- 還是 6. 通過自動化編譯建構 才算？
- 甚且是要等 9. 經過產品經理確認 才算？
有許多開發團隊，產出的本身是透過「默契」來達成。然而就新鮮人而言，一開始一定比較難取得「默契」。開口詢問，並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。
參考閱讀-> 如何快速充實自己
