※ 引述《leicheong (睡魔)》之銘言： : ※ 引述《wade43 (wade43)》之銘言： : : 錯誤的觀念! 達到L5應該是會讓你生產出品質更好、cost更低的產品! : : L5和客戶要求的品質沒啥關係，L5的重點是你們組織內部的持續改進! : : CMMI 和 Agile沒有互斥 : : 為什麼一說到CMMI，就會提到很多文件、很浪費cost? : : CMMI沒有規定一定要有什麼樣子的文件或格式! : : CMU 發展出一個Model，來讓大家產出很多文件? 提高大家的Cost? : : make sense嗎? : 一個正常的PG寫documentation和寫code的時間比約為 7:3 : CMMI即使文件量不多, 但寫Joblog那些甚麼的總要花時間的吧? : 當PG為了那些額外的doc.真正產出code的時間比下降到 75:25, 甚至 8:2 的時候, : 我很難想像怎麼跟直接沒post CMMI的, 但因短期成本低而報價比你的公司低的公司 : 競爭, 尤其是許多非本行的根本不知道甚麼是CMMI的時候. : 對他們來說, 口碑往往是比較可信的. : 因此我說對中小型公司而言, 為CMMI的宣傳效果而做CMMI是相當不智的. 往往 : 級考不上去, 燒了一堆錢, 口碑因額外的工作量做成的延遲差了, 員工為額外 : 的工作量怨聲載道而出走... 那樣的話真的得不償失啊. 假設專案A, B, C, D, E代表一個產品版次的成長， 那不照流程不留文件的專案開發大約長的像這樣: A -(一個月)-> B -(兩個月)-> C -(三個月)-> D -(四個月)-> E... 共十個月。 因為程式越來越複雜，導致加入一個新的feature的成本增加， 加上不留文件造成經驗無法傳承，且因為缺乏有脈絡的設計， 導是程式開發越來越困難，且新人加入要上手的成本很高。 如果有依照流程並且留下文件，大概會長這樣， A -(兩個月)-> B -(兩個月)-> C -(兩個半月) -> D -(三個月)-> E... 共九個月，因為寫文件這些過程可以強迫PG完整的思考程式的架構， 為將來可能的功能擴充埋洞，並且後面的人接手的時候有文件可以降低 訓練時間的成本。 那個比較省時間? 更不用提，各種文件其實可以流用，比如說設計文件 改一下可以變成內部訓練教材，甚至是SDK文件出給客戶的邊際效應。 我是覺得大部分PG在叫工作過量其實是因為，大部份的人沒看過正確 跑專案的方式，認為專案只有自己經歷過的那種跑法，把錯誤的範例 當正確的一脈相承(?)下去，而且這些人常常是PM或是主管.... 實際上要不要做CMMI其實並不是這麼重要，實際上來說， 一個能夠將開發經驗留下來的流程的落實才是最重要的。 寫文件一定要寫的工工整整漂漂亮亮的嗎? 重點是下一個接手的人 拿到你的文件的時候能不能快速的接手你的工作才是重點。台灣的 RD不寫文件大部分是因為偷懶，或是自己想留一手罷了。殊不知， 這樣的行為只是增加專案的隱性成本，把問題往後面丟而已。 (反正死的不一定是我，就來賭他一把啊...) --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.116.233.11 因為你是寫完Code才開始補文件，當然會有這個問題，我自己的習慣是 一面寫程式一面寫文件，程式出來稍微補一下文件就完成。 我覺得文件要紀錄一個RD在開發程式時心靈活動的過程， 程式開始設計的時候，我會把各種設計的考量記錄下來， 不管這些設計最後有沒有被採用。並且，在寫程式之前 先把Test Case大致上開出來記錄下來。 寫程式的時候，碰到一些必須要記錄的事項，比如說編譯的環境需要設定， 需要哪些額外的函式庫等，我也會記錄在文件裡。寫程式的期間如果碰到 需要修改設計，或是想到新的Test Case，一併會將文件更新。 等到做測試的時候，之前想的Test Case直接可以拿來用，不必花太多時間想。 測試結果一併記錄在文件裡。 你說寫文件會增加RD負擔? 我覺得剛好相反，透過這種強迫記錄的流程， 一個RD程式出錯的機會比直接在腦袋想好就上的出錯機率小，而且小很多， 省下的是後期除錯的時間。 我的工作信條很簡單，不希望讓下一個人把時間浪費在我已經做過的事情上。 不過大部分的RD都沒有這種觀念就是,反正不信者恆不信....Zzz... BTW,我個人極度痛恨那種"code寫的好就是doc"的鬼話，除非有大量註解， 不然程式碼裡面永遠只有兩個東西: what and how，可是why永遠不會在裡面... ※ 編輯: iincho 來自: 122.116.233.11 (07/21 06:14)