避开开发过程中的陷阱——《代码之殇》读书笔记

　　本书作者系微软资深软件开发专家Eric Brechner，他在书中用鲜明的实例告诉我们在软件开发过程中如何通过风险管理、团队交流等技巧来顺利完成项目，其中的许多经验和教训都值得我们借鉴，且将在未来的小组合作中发挥指导性的作用。

 

①关于时间的规划和项目实现功能的选择

　　按照往常，一个大项目的各子功能都有一个精确的完成时间计划，可做软件就截然不同了。其他的设计或许有一定的模式，甚至常常有例可寻，所以较容易估算出具体时间。然而，在实现一个软件功能之前我们往往只能对它进行一个简单的评估，比如难度上的容易/中等/困难，基于此可以给出一个大概的时间周期，这个周期的估计范围随难度上升而变大。因此，我们在每次制定短期计划时要具有一定的灵活性，避免由于追赶自认为的截止期限而造成稳定性、可靠性的降低，此外宽松的期限使得组员间能够坦诚相见，减少了不必要的隐瞒带来的隐患。总而言之，项目需要松弛的时间来产生效率。大家需要时间去思考、阅读和讨论。没有这时间就只能依着仓促的判断去做事情。而仓促的判断往往是错误的，导致糟糕的设计、计划和质量，引来以后大量的返工或成堆的缺陷。

　　在功能的选择上，起初我们想要做的东西更像个大杂烩，在开选题讨论会时，大家提出了各种奇思妙想，以至于我们都无法给自己要做的东西取个合适的名字。经过进一步的讨论，我们挑选了几个比较棘手的问题作为目标，之后的调查问卷显示，多数人其实只对其中一两个功能有迫切的需求，其他功能则抱着无所谓甚至否定的态度，这体现了与用户/客户沟通的重要性，也让我们明确了方向。就像作者在本书中写的那样，我们需要将任务分成三个等级——“必须有”的，“最好有”的以及“希望有”的，其中“必须有”的功能是能够让用户满意的最小功能集合，是我们务必首先要突破的，在完成这些功能时，可以如上所述按难易度划分大致的时间周期；“最好有”的功能次之，放在第二块时间段内完成；那些“希望有”的功能有余力再去依次实现。这是一种很好的风险管理策略，通过调集所有资源来降低在预期时间内不能完成“必须有”的功能的风险，实际上，在时间非常紧迫的情况下，我们甚至可以完全放弃“希望有”的功能，“最好有”的功能完成一半也就OK了。

 

 

②关于团队成员间的交流

　　交流在任何团队合作中都至关重要，对于软件开发，一个令用户满意的产品必然来自一个交流良好的团队，反之，团队成员间的封闭则会带来致命的问题。在项目进行的过程中，我们应该及时进行状态汇报，好让大家互相了解各自的进程和出现的问题，对于阻碍整体进程的问题也可以联合解决。

　　在小组合作中容易出现的问题是每个人想法的不一致，即有人觉得功能应该更多一些，有人为了减少bug的产生而尽量缩减功能，还有的人或许只想做一些有趣的事情。面对这种状况，“分诊”便成为一个良好的解决方案，分诊会的目的是为了安排问题的优先级，并决定每个问题如何解决。分诊会有几个原则：所有决定都是团队决定，即协商以后达成的一致的意见都应该视为整个团队的决定；需要有人在场面胶着时进行调解及帮助大家做最后决定，比如组长；提议的通过不需要所有人同意，只需要没有人反对即可。此外，分诊针对的应该是问题，而不是个人，这样会议才会轻松有意义，而不会产生由互相攻讦造成的纷争与挫败。