若是拋掉軟件工程中的工做量評估

在軟件工程中，工做量評估是一件吃力、艱難、認真作又怕浪費力氣、敷衍作又很差向leader交代的事情。正所謂一千我的眼裏有一千個哈姆雷特，同一個項目，給不一樣人評估，每每會得出不一樣的答案。

假設準備啓動業務提出的一個需求項目：

• 有硬deadline限制（譬如響應政策、配合外部環境整改、leader不切實際的拍板），deadline不會變，還估啥工做量，正常幹不完的該996得996（多數狀況下加班比項目組加人管用多了）。
• 無硬deadline限制（譬如爲了搶佔市場、優化、改善性項目），不管最後估多少，正常該幹多久，就幹多久。

若是把評估工做量環節去掉，項目開發流程會有啥不同呢？

---

可能出現的現象

---

• leader不安心。leader老是想知道項目什麼時候能上線，要佔用多少人力成本。

---

項目的上線時間交給項目團隊定，除非leader親身參與項目細節裏頭，這樣就能夠對項目上線時間作評估。要佔用的人力成本就更不用擔憂了，業務部門提出的需求通常都是價值優先。若是以成本優先，那就只作最低成本的需求即可，有沒有市場價值就不用管了，這明顯就是一種不合理的方式。用最優的力量，作最高價值的項目。IT部門主要項目分析可行性即可，除非IT部門作了一個比業務更加專業的市場調查來打業務的臉。

---

• 員工不上心。既然一些項目上線時間能夠由IT團隊定，那就慢慢作。

---

這是人之常情，就像作暑假做業，有幾我的不是最後幾天趕出來的？不過，若是頻繁地作做業檢查，相信狀況會好不少。那如何保證項目進度？如下借鑑幾個scrum技巧

1.任務公開化可視化

把項目分解成一系列小任務，排個優先級，先作啥後作啥，找個牆或者小白板，寫上小紙條，貼在待辦區域裏。

團隊成員各自領取任務（團隊leader分派也行），貼到開發區域。

2.每日站會

天天找個固定的時間團隊一塊兒開個小會議，時間不用長，15分鐘之內吧，記得是站着開。每一個人說一下任務的新進展和遇到的問題。把完成的任務移動到完成區域，而後再領或派一個新任務。

3.按期展現成果

口說無憑，軟件說話。隔個一兩週，把你們叫到會議室時運行一下各自的代碼。若是兩次展現之間沒有進展，負責的程序丸在每日站會上又沒有報問題，那就要檢查一下出了什麼情況，及時糾正項目進度。

---

去掉工做量評估這一環節，省掉了很多事務性工做時間，只要增長項目的頻繁返饋，再創建儘快交付價值的團隊目標。

業務只需安排好項目優先級，IT只需努力盡快實現業務價值，作完一個項目，再挑一個優先級最高的作，保證在作的永遠都是當前最有價值的事情。

---

最後隨便扯一下，項目是並行作好，仍是串行作好？

若是一個團隊接到不止一個項目，先保證優先級最高的項目獲得最有效的投入，保證能夠儘快向業務交付價值。

譬如團隊接到三個項目（不能出現項目優先級相同的不按套路出牌的狀況），若是並行開發，6個月後三個項目同時期上線了。若是串行發，2個月後上線優先級最高的項目，4個月後上線優先級次高的項目，6個月後上線優先級最低的項目。

別覺得一個團隊並行開發項目效率總會比串行高，就像一我的左手畫圓，同時右手畫方，結果畫出來圓不是很圓，方又不是很方。

以上觀點自知膚淺，旨在探討軟件工程，拋磚引玉。