《代码之殇》——1

写在前面的话，放假了，课设也做完了，离1月3号回家还有几天，在学校闲着没事，特别想看看无关代码、无关技术，而是项目管理、技巧一类的书籍，发现图书馆5楼的书非常多，真想给我两倍的时间，让我细细品读这些有意思的书籍，尤其是这本《代码之殇》，翻看几页，觉得真的写的特别好，满满的都是干货，有种徜徉在书海中的快感。也有好久没有写博客了，做做笔记，分享知识吧！感觉我的博客和大V们比起来，好稚嫩的说。。

关于作者：Eric Brechner　资深软件开发专家，拥有30余年开发经验，现就职于微软公司，担任“卓越开发”部门总监。曾在Bank Leumi、Jet Propulsion Laboratory、GRAFTEK、Silicon Graphics、Boeing等公司供职，担任过开发部门负责人、开发部经理、开发部总裁等职务。从2001年开始为微软公司员工撰写“Hard Code”专栏，该栏目在微软内部影响十分广泛，几乎是每一位工程师必读的，从而也激起了关于最佳实践的广泛讨论。如今，“Hard Code”专栏中的有益观点和真知灼见走出微软，走向整个软件开发社区，所有软件开发者都能从中受益。

内容：将这90余个问题分为10章：第1章讨论如何通过管理风险、范围和沟通来保障项目按时完成；第2章介绍消除经验主义的大量过程改进的方法与技巧；第3章讨论消除低效率的策略；第4章主要讨论开发者与其他工种之间的关系；第5章重点阐释软件质量问题；第6章解析软件设计的基本原理和错综复杂的本性；第7章探讨如何规划职业生涯；第8章分析工作与生活中存在的缺点的原因与纠正措施；第9章讨论如何进行有效管理；第10章分析如何成功应对一个软件业务所面临的挑战。

《代码大全》姊妹篇
资深软件开发专家30余年工作经验结晶微软公司软件工程师必读之书
被誉为“软件行业的财富”从软件开发流程、技术、方法、项目管理、团队管理、人际沟通等多角度总结出90余个具有代表性的问题并给出了解决方案，值得所有软件工程师研读

chapter 01 项目管理失当

一些神奇的伟大神话：

楼主:这些神话是不可能实现的，至少目前来看，同意，做过几个小项目和课设，基本上都没能按时完成任务，总是会靠走捷径或者熬夜加班来完成。

1. 人们可以按时完成任务。（In fact,项目可以按期交付，但是项目员可以完成任务的概率低于曲棍球概率）
2. 有经验的人估计概率日期比较准确。（事实上，他们能够较好地估算工作，但
   不是日期）
3. 人们必须准时完成各自的任务从而使整个项目按时交付（事实上，员工们不能按时完成自己的任务，所以你若想你的项目能够按期交付的话，你必须进行风险管理、范围管理并通过沟通来减轻人性的弱点可能给项目带来的负面影响）

2001 年 6 月 1 日：“开发时间表、飞猪和其他幻想”

能够说出在两天内完成任务的人都是骗子（开发成本计算和时间表是个笑话。相信它的人，要么是傻瓜，要么是初出茅庐的项目经理）

楼主：永远不知道编码会花费多长的时间，说‘我一定能在两天内完成’诸如此类之话的人，一定是猴子派来放屁的。

那么，开发时间表的问题该如何解决呢？

• 规定里程碑日期
  
  • 三个里程碑：
    
    • 第一个里程碑：必须有的功能。
    • 第二个里程碑：最好有的功能。
    • 第三个里程碑：希望有的功能。
  • 如果到了第三个里程碑仍然有较多“最好有”，“希望有”的功能未实现。那么，“希望有”的功能扔掉，“最好有”的功能删去一半。以到达交付日期完成主要功能的目的。
• 风险管理
  
  • 管理“必须有”，“最好有”，“希望有”
    -产品的成功与否 即降低风险的方法：把必须有、希望有、最好有的功能按照优先级别完成。
    

具有讽刺意味的是，几乎所有的工程师和经理都赞同优先处理“必须有”的功能，但事实上很少有人真的这么做，因为“必须有”的功能通常是乏味的，比如安装、软件工程创建、向后兼容性、性能优化和测试套件等。然而没有这些功能，你的产品根本就无法发布。因此，产品发布往往是因为这些问题而一拖再拖。

2001 年 10 月 1 日：“竭尽所能，再论开发时间表”

• 激励员工的方法（第三个是作者认为最好的方法，屡试不爽）
  
  1. 里氏震级估级
  2. 瞄准里程碑日期（很有可能因为到了交付日期压力增加导致员工抄近路复制代码或者生产出质量糟糕的产品）
  3. 风险管理方法（评估必须有、最好有、希望有）因此我告诉我的团队，如果他们想要做些很酷的功能，必须首先保质保量地完成之前的这些关键功能。

2002 年 5 月 1 日：“我们还开心吗？分诊的乐趣”

项目经理希望瞬间得到无穷多个功能，测试人员和服务营运人员希望永远也不要增加新的功能，而开发人员只想在不受外界干扰的环境下编码实现很酷的东西。现在，邀请这几个方面的主管，让他们带着相互冲突的理想去同一间房间，关上门，再给他们点可以用来打架的东西。会发生什么呢？分诊！

---

你怎样才能保证分诊正常地进行并且具有建设性呢？采纳我下面的 5 条黄金法则吧：

• 关上门 私下商量更容易坦诚相待、相互妥协达成一致
• 所有的决定就是团队的决定达成协议后，参与者必须无条件遵从这些决定
• 每个专职领域指派一名代表人越少，争论越少。减少个人情绪掺杂，提高效率
• 指定一个可以最终做决定的人如果不能达成协议，需要一个最终决定的人
• 遵从“贵格会”信条如果重读无法解决，所有参与者必须提出大家都能接受的方案。只不起冲突即可。

分诊的一些处理技巧，使分诊更加顺利：

• 如果分诊时需要另外的人来参与，当他参与完成后，必须送走这位访客，否则分诊机密性会破坏，所做的决定也就不再是分诊决定了。

  楼主：不明白。好像没什么影响？

• 如果你想让你的团队中的某个人了解分诊过程，则可以邀请他加入一个分诊会议，但叮嘱他，务必在你们讨论期间要像趴在墙上的苍蝇那样保持安静，并且向他强调协商过程的机密性。

如果分诊仍然很难进行下去 ，那么，使用银弹吧！！用一颗少一颗！

• 于是，大家都舍不得用银弹，最后话题会一直讨论直到讨论出结果。