读微软项目-求生法则

        最近时间还算充裕，记得有一次查冒烟测试，查到了微软项目-求生法则这本书，好奇之下就翻了一遍，这本书写的真的很好，按照书里的求生测试测试了一下目前做的项目，不够及格的分数，我以前还觉得我们的项目做的还好，看了这本书才发现原来有很多问题是可以提前预防的，还有很多问题是因为早期的工作做的不够。

        回想我的这个项目，去年9月份就开始了，时间特别紧，要在年底完工上线，我带着几个工作不久的同事一起开发客户端程序，那时候还没有采用敏捷的方法开发，也没有求生法则里那么规范。当时的开发项目管理就是我这边根据需求然后切分工作任务，然后分配给这几个同事，带领他们做开发，结果日夜赶工，什么架构，什么编码规范，什么异常处理，都扔到了一边，结果几万行的程序，600多个bug，到了年底根本就不能用。

        今年过年回来，公司采用了scrum，大家对这个东西还是比较感兴趣，这个项目的二期需求大致确定下来后，采用翻牌的办法估算时间，估计不到1个月就能搞定二期，我当时就觉得不太可能完成，对scrum产生的怀疑。因为我以前了解过一些rup的开发过程，rup比较注重架构和后面的增量，迭代，而scrum主要注重项目管理，基于任务的开发。不过scrum有一个好处就是在开发过程中需求的变化能够很好的响应。

        后来我们弄了白板，站立会议也正常进行，然后使用了禅道软件帮助管理项目，一个月下来，二期项目只延期了2天，bug也少了很多，而且没有怎么加班。我觉得在使用scrum时因为前期的需求在我们几个开发人员的讨论下已经被细化到一定程度，时间估计就比原来准确很多，与产品经理的即时沟通也为我们扫除了不少需求障碍。我们才能大致按照时间完成。

        由于一期的项目管理太差，前期规划也没有规划好，所以软件质量没有保障，按照《求生法则》里所说，前期的需求不明确会导致后面会花费50~200倍去修复。当时的低质量代码给我们造成了很大的困扰，刚fix了几个bug，就又出来了几个bug，在相当长一段时间内都不能继续下面的工作。

        《求生法则》里说的变动管制我觉得这个想法非常好，因为我们开发项目时经常会有一些变动，比如需求变动等，以前的需求一变动我们这边就要马上改变，然后也没有明文记录为什么这么改变，改变后对项目有什么影响，谁应该为这个变动负责，结果后面有时候就会出现这个变动延误了其他任务的时间等问题。

        《求生法则》与其他的书的不同之处在于他能够针对真实项目给出定量的方案，而不是一些理论性的东西，书中的数据非常具有参考价值。使用书中的各种法则，可以对当前项目进行定位，找出关键性的问题原因。

        以后还是要找时间仔细把这本书看一遍，认认真真做笔记。