从《最后期限》得到的

废话大仙

汤姆·迪马可编写的《最后期限》是一本特别简单而又趣味性的小说。我向来对于项目管理方面那些枯燥乏味的理论书籍很反感，即便痛下决心拜读的时候也不过匆匆翻过二三十页，然后就丢在再也不会过问的角落。然而对这本书我也不禁感叹："早该出这么一本书了！" 虽然他的内容非常的简单，但你却能够从中得到与一项目管理方面的权威书籍同样的收获。更重要的是，他根本不需要你花太多时间太多精力去阅读，而只会使你象读一本简单的故事一样轻松。
我是用了两个半天的时间细细品味这本书的，一边阅读一边联系实际，真的很受益。这里我就从书中提取几个关键的主题，讨论并与大家一起分享。
一、人的管理
目前流行的轻量级软件开发方法的核心价值便是强调人的作用。它强调，软件开发是人与人合作进行的过程，因此成功的软件开发过程应该充分利用人的优势，而弱化人的缺点，突出了人在软件开发过程中的作用。西安高新人才服务中心副主任顾海文在分析企业员工流失原因时也指出：现在很多员工，不仅仅是因为工资待遇而跳槽，而往往对工作环境、个人没有发展机遇、周围的人际关系如何、有没有培训机会等等都非常重视。
看来，人的管理不仅仅威胁到软件开发是否成功，而且已经威胁到一个企业能否生存下去。优质的管理应该包括四大要素：选择正确的人；为他们分配正确的工作；保持他们的积极性；帮助团队凝聚起来并保持团队的凝聚力。说起来简单，做起来就不那么容易了。它是一个长期的过程，并涉及企业的各个方面，如需要为企业建立一个科学的管理体系，设计合理的薪酬待遇制度，为不同角色设计灵活多样的培训计划，建立高效的团队，等等一系列工作。
二、风险控制
风险控制过程是伴随软件开发整个过程的一个重要环节。可以说，软件开发过程就是风险不断得到控制的过程，就是不断处理和解决风险的过程，当所有风险结束的时候也就是项目关闭的时候。
进行风险控制的一个基础是首先需要为项目创建并维护风险统计表，用来记录风险，跟踪风险处理过程，并能够对风险进行查询和统计。这样，不管是项目团队的开发人员，还是项目的高层管理者，都可以随时掌控风险的状况。建议大家去参考以下ASC公司的RISK RADAR工具。
风险控制的另一个好做法是项目控制面板，可用作项目自动跟踪工具。将项目的各方面的数据（如需求变更数量，Bug数量等）录入对应的表格，即可自动得到当前关键指标的状态（是否处于正常的范围之内）。关键的项目指标可以包括：项目的进度，工作的效率，需求的变化，配置项的变化，人员的流动，不同阶段的缺陷数目，加班时间等。如果我们给每个指标一个可接受的阈值，当超过这个阈值时，系统便会自动给出警告。控制面板由一系列的度量仪表组成，仪表上的指示将随着你输入的项目信息计算而来，并随时更新。在ASC公司的网站上，也有类似工具的DEMO可下载。
为了及时地识别风险，建议建立简单的（可能是匿名的）通道，让坏消息能传递到高层。要知道：坏消息知道的越早越好。
三、高效的会议
为了增强开发人员之间的沟通，大会小会必然会很多。如何能够提高会议的效率就成了大家比较关注的问题。
一个好的策略是召开不同类型的会议，因为不同类型的会议参加的人员不同。这样自然地就减少了参与者的人数，提高了会议的质量和速度。比如在极限编程中就提到一种每天的例会—站立会议。这是每天所有开发人员都必须参加的时间很短的会议，团队的任何人可以在这里提出任何与项目相关的问题。由于大家每天都有机会聚在一起沟通相关事宜，自然就会省掉其他的许多会议，另外也能够大大减少工作中互相打扰的次数。
另外，对于会议一些大型的或时间较长的会议，一定要有会议议程，并且要提前通知参与人员。比如开发阶段结束时的质量评审会议，如果有详细的议程公布出来，开发人员则可根据自己的情况选择参加不同的内容。这样一来，所有的内容都是必要的人在参加讨论，从而保持了会议的精简和高效。
四、人员安排
在软件开发的早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让所有的人都有事可做）。如果在设计完成之前，工作先被分给了许多人，那么人与人之间、工作组之间的接口就会很复杂，这会使团队内部耦合度提高，会议时间、重复劳动和无数工作都会增加。理想的人员安排是这样：在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入大量的人手。
五、压力的效果
提起“加班”，大家都不陌生，而且往往自然地将它与“程序员”或“软件行业”联系在一起。而这里的观点是：压力之下的人无法快速地思考；增加加班时间只会降低生产力。短期的压力乃至于加班可能是有用策略，因为它们能使员工集中精力，并且让他们感到工作的重要性。但是长期的压力肯定是错误的。如果一个半年的开发项目在第二个月便进入频繁的加班，那么这个项目肯定死定了。
实践表明：最初压力的增加可以略微提高生产力。因为员工们喜欢压力，他们会积极地响应，至少在压力不太大的时候是这样。他们开始认真工作，而且真正全心投入。中等压力也许可以将生产力提高6%（最多是达到这个水平）。但是，只有当压力处在适当范围的时候。情况才是这样。压力再多一点，增加压力就不再有好的效果，事实上对交付时间一点作用也没有。
因为长时间的加班会带来很多负面影响：疲劳、失去能量、错误率上升，等。所以，加班会大大地降低生产率，没有加班的项目的生产率肯定会高于不加班的项目。如果你10个小时的工作别人8个小时就能完成的话，你加班的两个小时可以说没有任何意义，只能说多耗费了一点电费而已。
在极限编程中也一直强调：永远不加班。加班将导致项目组的人的精力和效率都下降，项目如果要加班才能完成的话将会延迟，无论你如何的进行加班。不如使用版本计划会议对项目进行重新的计划。
六、度量
度量可以使你的管理更准确更客观。但是一套完整而准确的度量体系不可能一次就建立起来，也更不可能从其他公司照搬而来。其实，度量只是一种思路，具体的内容要因公司的具体工作而定。
在建立度量体系时，可以按照以下思路进行：
1、 根据公司软件开发的特征找出一些可度量的有意义的度量数据。注意不要执着于单位。在等待客观度量的时候，先用你目前认为比较合适的度量单位；
2、 从已经完成的项目中收集原始数据，能收集多少就收集多少；
3、 对收集到的数据进行图形分析，从而推导出生产力趋向；
4、 不断完善你的度量方程式，直到它的计算结果与原始数据中的项目工作量有最好的对应关系；
5、 借助数据库画一条趋势线，把预期工作量作为人造度量单位值的函数显示出来；
6、 现在，针对每个要评估的项目，计算出人造度量单位值，并根据这个值在趋势线上找到预期工作量值
开始的数据得到的预测与实际情况的差异可能会较大，有了经验以后，收集的数据会越来越准确，当然得到的预测也越准确。等到那个时候，软件项目中所有的决定将都是从定量的数据分析而来，而不是有经验的开发人员拍脑袋想出来的，项目的开发风险自然而然不就降低了吗？再做得好一点，度量体系可以不仅仅是度量，你可以采用这些数据来实时地检测和控制项目的各种指标，如需求的变更，进度的变化，等等。
所以，完整的度量体系应该包括“定义软件的度量数据、测量和收集数据、分析这些测量结果并作出调整以保持项目指标在可接受的范围内”。

星空无垠

我来占个沙发