## The clean Coder - 預估  note: 今天想跟大家分享我看的這本書的其中一個小章節，叫做預估，然後這本書比較算是軟實力的部分，主要是在說身為一個專業的工程師應該要有怎麼樣的態度、原則與行動。 --- ## Cindy  - github：https://github.com/cindyliu923 - blog：https://cindyliu923.com - medium：https://medium.com/@cindyliu923 note: 我是 Cindy 這是我的 github，技術部落格跟軟文章部落格 medium --- ## 小故事 note: 在開始之前想先跟大家分享一個小故事，2018 年小美認真學會寫程式之後，開始了第一份工程師工作，當小美打開專案的時候 ---  note: 小美以為他來到了深海之中，這是一個 2013 年就開始有程式碼的大專案，總共有六個 rails，在 gitlab 上有六個專案 ---  note: 小美待的公司很快地在小美待不到半年就結束營業了，新手小美必須找新工作，努力了一陣子，小美找到工作了 --- ## 新公司 note: 公司結束之後過了大約 2 個月左右，小美帶到了新公司，打開專案 ---  note: 小美看見熟悉的身影 --- ## ~~緣分~~ note: 這讓小美了解到這就是所謂的緣分，小美遇到了前公司的專案 ---  note: 也因為這樣小美對這張圖有了更深刻的體會 --- ## 排山倒海的需求  小美一個人消化 note: 剛開始接手專案，只有小美一個人負責寫 code，junior 小美和 junior PM 兩人相依為命，面對客戶如排山倒海而來的需求 --- ## 每個需求都很急 專案很大、很老、文件很多但不清楚又難找，客戶自己都搞不清楚原始的 spec，但又一直催促、逼迫 --- ## 沒有 buffer 的時間 junior 小美的估時被原封不動的提供給客戶 note: 在某天與客戶開會之後，小美最後崩潰了 --- ## 新的默契 - 小美：稍微悲觀的預估，code review 的時間要另外算 - PM：提供給客戶的時間會另外加上 code review 跟做雜事的 buffer note: 小美ㄧ直為估時苦惱，小美此後採取的作法是悲觀預估，每張票都有可能會需要花費時間研究，但客戶並不會把研究的時間算進去小美花費的時間，悲觀預估可以預防太樂觀導致客戶的逼迫，客戶如果覺得太慢小美會把詳細要做的事情先列出來給客戶看，但就會花費更多的時間在預估這件事情上，把要做的事情先列出來，再依據要做的細項做預估，預估上來說會相對準確，而且因為寫下來要怎麼做了，也相對可以簡單的 pass 給其他人來做。另外最後客戶也有發現人不夠最後這個專案有四位工程師開發。 --- # 什麼是預估？ note: 那我們回到這本書，一開始書中先問了大家，什麼是預估。預估是軟體開發人員面對的最簡單也最可怕的任務之一，作者說明了他曾經預估 1 個月完成的功能結果花了 3 個月完成。 --- ### 業務方 ---> 承諾 ### 開發方 ---> 猜測 note: 問題在於不同人對於預估有著不同的看法，業務方覺得預估是承諾，開發方覺得預估是猜測，兩者相差迥異 --- ## 承諾 承諾是必須做到的，專業的開發人員不隨便承諾，除非他們確切知道可以完成。 --- ## 預估 預估是一種猜測，不包含任何承諾色彩，我們之所以要預估，是因為 **不知道** 到底要花多少時間。 --- ## 不幸 大多數軟體開發人員都很不善於預估，不是因為他們沒有掌握關於預估的訣竅 ----『根本沒有這樣的訣竅』。預估的偏差總是很大，原因在於我們並不理解預估的真實本質。 --- ## 預估不是個定數， ```.md PM：「你估計要多久可以完成優惠折扣的計算功能。」 RD：「3天左右」 PM：「這功能對客戶很重要，有可能明天給我嗎？」 RD：「不可能，光是原始碼就10萬行了。」 PM：「那給你3天，你有把握做出來嗎？」 RD：「一半一半吧...老實說先前維護系統的工程師已經離職了，我很難短時間內釐清修改這個功能對其他功能的影響多大。」 PM：「那我跟客戶約4天後討論呢？」 RD：「嗯，沒意外的話，3天可以完成，如果發生一些錯誤，會再多出1~2天的時間。」 PM：「那給你兩倍的時間去處理呢？」 RD：「好的，如果6天的時間的話我會有九成的把握。」 PM：「我明白了。」 ``` 例子參考：[為何工程師時常無法兌現進度承諾？](https://medium.com/mr-efacani-teatime/%E7%82%BA%E4%BD%95%E5%B7%A5%E7%A8%8B%E5%B8%AB%E6%99%82%E5%B8%B8%E7%84%A1%E6%B3%95%E5%85%8C%E7%8F%BE%E9%80%B2%E5%BA%A6%E6%89%BF%E8%AB%BE-4ad6f33ec127) note: 書裡也有類似的例子，那預估不是個定數，所以是什麼？ --- ## 預估的結果  是一種機率分佈，3 天是可能性最大的那個 note: 預估的結果其實是機率的分佈，從剛剛的例子來看，一開始 RD 說的 3 天是機率最大的數字，最後結論的 6 天是大約有 9 成機會完成的數字，RD 應該避免給出暗示性承諾 --- # 預估方法 note: 接下來作者提供了一些預估的方法 --- ## PERT ([Program Evaluation and Review Technique](https://zh.wikipedia.org/wiki/%E8%A8%88%E7%95%AB%E8%A9%95%E6%A0%B8%E8%A1%93)) 樂觀預估( O )：如果一切都異常的順利，可以在這個時間內完成。(機率小於 1%) 常規預估( N )：最有可能完成的時間。 悲觀預估( P )：如果一切都異常的不順利，可能會在這個時間後才完成。(機率小於 1%) ``` 最核心公式為「專案期望時間」= ((樂觀時間+悲觀時間+4*最可能時間))/6 標準差 = (悲觀時間-樂觀時間)/6 ``` note: 又稱為三元分析法，透過上述三個數字預估某項任務 --- ## 預估任務 ### [莫爾菲法](https://zh.wikipedia.org/wiki/%E5%BE%B7%E5%B0%94%E8%8F%B2%E6%B3%95) - **共識** - 亮手指 - 規劃撲克 - 關聯預估 (排卡片順序) - 三元預估 (上述方法分別做悲觀、樂觀、常規預估) note: 多人預估的方式，利用共識來預估，亮手指就是每個手指先約定好一個單位，然後同時大家一起亮手指，來決定預估的時間。規劃撲克也差不多，就是把手指改成撲克牌，關聯預估的話是先把每個任務先寫在卡片上，然後打亂之後大家來排序，時間最久的排右邊，排完再討論 --- ## 大數定律 把大任務分成許多小任務，分開預估再加總 --- ## 作者的結論 在大多數情況下，專業的開發人員不會直接做出確定數字的承諾，而是會提供機率預估，來描述『期望的完成時間』及『可能的變數』。對需要妥善對待的預估結果，專業開發人員會與團隊的其他人協商，以取得共識。 --- ## 反思 更想要哪種？ - [ ] 花更多的時間預估，估的時間相對比較準 - [ ] 花少少時間預估，估的時間相對比較不準 - [ ] 其他還沒想到 note: 因為進公司以來我一直覺得我們的估時非常不準確，另外我也覺得我們花在預估這件事情的時間是太短的，如果小功能應該還好但如果是大功能的話絕對是不準的，我也在反思究竟該怎麼做才是好的，還沒想出答案 --- ### Thank you! :sheep: <!--  note: 其他我覺得可以分享給大家的 --> <!-- Interrupt and Context Switch are the MOST Waste of Engineers. --> <!-- # 時間管理 note: 先說後面的內容是作者的想法，大家可以參考就好，有些我覺得有點兇 --> <!-- ## 會議 1. 會議是必須的 2. 會議浪費了大量的時間 --> <!-- ## 拒絕 邀請你參加會議的人並不負責管理你的時間，為時間負責的只有自己，所以，如果你收到會議邀請，務必確保出席會議可以為自己目前的工作帶來切實且顯著的成效，否則不必參與。 -->