※ 引述《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)