截至目前為止,我們了解了:
- 前端開發的流程(需求同步 → 系統設計 → 功能實作 → 測試撰寫 → QA撰寫 → 版本發佈)
- 理解專案的方式(架構圖 + 序列圖)
通常在需求同步的時候,我們除了需要對業務和系統有極高的熟悉度以便能夠準確評估影響範圍以及開發的方向(架構圖 + 序列圖能幫上忙)。
還有一點,最重要的一點,沒錯,就是時程。
在這邊你可能會問,時程安排應該不關工程師的事吧?
俗話說的好,知己知彼,百戰百勝。 而且在面對需求尚不明確,但需先評估出開發工時的情況,有工具在手會覺得比較安慰。
於是乎,今天我們講一點不一樣的,PERT 計劃評核術。
chatgpt對PERT的解釋如下:
PERT(Program Evaluation and Review Technique,計劃評核術)是一種專案管理工具,用來計劃、排程和控制專案中的活動。它由美國海軍在1950年代研發,最初用於波利斯導彈計劃的管理。PERT主要用來處理專案中的不確定性和預測活動的持續時間,適合應用於時間表複雜且各項任務互相依賴的大型專案。
一句話翻譯,PERT是種時間規劃工具,主要用來處理時間不確定性高的專案。
PERT的核心概念有三,活動、時間估計、網絡圖。
活動: 活動就是專案中所需執行的項目,又可分成有依賴和無依賴,有依賴的項目需等待前面的項目完成後才可執行。
時間估計: PERT使用三種估計來計算每個活動的預期時間
- 最樂觀時間(Optimistic Time, O):在最佳情況下完成活動所需的最短時間。
- 最悲觀時間(Pessimistic Time, P):在最糟糕情況下完成活動所需的最長時間。
- 最可能時間(Most Likely Time, M):根據通常情況下預期的時間。
- 而計算預期時間的公式為: ***預期時間=(O+4M+P)/6 ***
網絡圖: 視覺化的圖表,用來展示活動之間的相依性和專案進程。
延伸閱讀: https://asana.com/zh-tw/resources/pert-chart
- 列出所有的工作項目
- 定義工作項目之間的依賴關係
- 圖表製作
- 列出時間
舉例來說一個前端專案重構的PERT可能會長這樣,
時間軸一樣是由左到右,由上到下,無相依性(二擇一或是可同時進行)的項目會垂直擺放。顏色主要用來自行定義。
我認為使用這個方式主要有幾個優點
- 可以比較容易與PM和QA溝通,能夠用圖像化的方式讓大家理解那些地方有高耦合,容易發生問題。或是那些項目可能不是那麼必要。
- 面對未知的事件比較能夠有脈絡的進行思考。
- 可與實際執行的結果進行比對,找出差異點,未來處理相似狀況時能更有掌握。
不過也當然有缺點
- 耗時,建議評估專案大小後再斟酌使用。
- 實際執行有可能還是會有意外狀況發生。
好的,到這PERT的部分就告一段落了,在跨團隊溝通遇到困難的夥伴可以試試看! 用視覺化的方式溝通!
下一篇文章我們接續開發階段所會遇到的SD文件設計來進行討論!
快可以不用畫圖了!
圖片出處:https://asana.com/zh-tw/resources/pert-chart