维度

如何优化

People

l  为团队挑选胜任称职的成员

l  选择合适的团队结构

l  使用恰当的人员激励措施

Process

l  采用标准的软件工程实践，避免开发过程失控

l  做好风险管理

l  为项目选择合适的生命期模型

l  形成良好的质量保证机制

l  选择客户导向的开发方法，使开发的产品真正满足客户需求

Product

l  较准确地估算product size（产品规模）和effort（工作量），以便制定出现实的进度安排

l  采取恰当措施防止软件开发过程中product size或product scope失控

l  为产品设定合理的product characteristic（如内存占用、稳定性、可靠性等）。

Technology

l  选择恰当的、能确实提升生产率的工具（包括新的编程语言、新的开发实践、新的代码库等）

最佳实践：典型错误列表

1.       以表2-1作为初始的典型错误列表。

2.       从投入到某个项目的第一天起，每天在下班之前检查一遍典型错误列表，反省自己或团队有没有犯典型错误。如果有，思考一下怎么改变。

3.       在每个项目结束之后，分析总结在项目中所犯的典型错误。如果是典型错误列表中不存在的，把它加入到典型错误列表中，供下个项目使用。

相关维度

典型错误

解决办法

People

1.         Undermined motivation. （挫伤积极性）

激励开发人员，详见第10章。

2.         Weak personnel. （人员不能胜任）

招聘可胜任的人员，详见第11章。

3.         Uncontrolled problem employees. （对问题员工失去控制）

尽快处理问题员工，详见第11章。

4.         Heroics. （英雄主义）

团队领导或成员对自身能力过于自信。

客观认识自身能力，避免盲目自信。

5.         Adding people to a late project. （向已落后进度的项目增加人员）

不向落后进度的项目增加人员。如果实在要增加，可增加行政人员，帮助技术人员处理杂务。

6.         Noisy, crowded offices. （办公环境拥挤嘈杂）

营造安静、整洁的办公环境，详见第10.3.1节。

7.         Friction between developers and customers. （开发人员与客户之间产生摩擦）

维持良好的客户关系，详见第9章。

8.         Unrealistic expectations. （不现实的预期）

进行准确的软件估算，制定合理的进度计划，详见第7章和第8章。

9.         Lack of effective project sponsorship. （缺乏高层对项目的有效支持）

请求高层对于项目的支持。

10.     Lack of stakeholder buy-in. （干系人没有全身心投入项目）

请求干系人的全身心投入。

11.     Lack of user input. （缺乏用户介入）

在软件项目的全过程都重视用户反馈，详见第9章。

12.     Politics placed over substance. （玩弄政治）

实施有效措施保证项目和团队成功高于个人成功，详见第11章。

13.     Wishful thinking. （充满想象）

根据主观愿望而非客观事实对项目状况进行判断。

破除一厢情愿的想象，把项目执行落到实地。

Process

14.     Overly optimistic schedules. （过于乐观的进度计划）

进行准确的软件估算，制定合理的进度计划，详见第7章和第8章。

15.     Insufficient risk management. （风险管理不到位）

进行充分的风险管理，详见第4章。

16.     Contractor failure. （外包承包方违约）

有效管理外包项目的风险，详见第16章。

17.     Insufficient planning. （项目规划不到位）

完成有效的项目规划，详见第3.1.1节。

18.     Abandonment of planning under pressure. （在压力下放弃项目规划）

在压力下更要坚持规划，但需要根据项目进展状况及时调整和重新规划。

19.     Wasted time during the fuzzy front end. （在项目前期浪费时间）

不在项目前期浪费时间，争取尽快立项并进入执行阶段。

20.     Shortchanged upstream activities. （走样的上游任务）

草草完成需求分析、概要设计和详细设计。

认真进行需求分析、概要设计和详细设计，并进行technical review。

21.     Inadequate design. （低劣的软件设计）

进行高质量的软件设计。

22.     Shortchanged quality assurance. （走样的质量保证）

取消design review、code review和test planning。

任何时候都不放松对软件质量的要求，详见第3.6节。

23.     Insufficient management controls. （管理控制不到位）

加强对项目major milestone和miniature milestone的管理和监控，详见第3.1.2.1节。

24.     Premature or overly frequent convergence. （过早或过于频繁地开展项目收尾工作）

不要过早或过于频繁地开展项目收尾工作。

25.     Omitting necessary tasks from estimates. （项目估算中遗漏必要的任务）

把项目估算中易遗漏的任务列于显著位置，防止遗漏，详见第7.2节。

26.     Planning to catch up later. （试图赶上进度）

进度落后之后，不要试图赶上进度，而应该根据项目新的状况重新制定进度计划，详见第7.3节。

27.     Code-like-hell programming. （地狱式编程）

项目采用急就章式的、自由散漫的、“代码写到哪儿算哪儿”式的编程模式。

绝对避免急就章式的编程，任何代码必须经过严格的质量保证措施，详见第3.6节。

Product

28.     Requirements gold-plating. （需求镀金）

项目的需求规格书中具有用户不需要的、复杂的需求。

不要在需求规格书中加入用户不需要的需求。

29.     Feature creep. （功能蔓延）

项目进行过程中频繁出现需要变更（requirement change）。

采取措施防止功能蔓延，详见第13.2节。

30.     Developer gold-plating. （开发人员镀金）

开发人员为了学习新技术而给产品加入用户不需要的功能。

不要为了让开发人员学习新技术而加入不需要的功能。

31.     Push-me, pull-me negotiation.

软件经理一面批准了进度拖延，一面又向拖延的项目中加入新的需求。

在项目已经拖延的情况下，必须稳定需求，不再加入新的需求，详见第15.1.3节。

32.     Research-oriented development. （研究导向的开发）

把软件研究（如新算法）当成工程项目来做。

不在软件工程项目中搞软件研究。

Technology

33.     Sliver-bullet syndrome. （银弹综合症）

项目把解决进度问题的希望寄托在单独某一种新实践、新技术或新开发方法论上。

破除银弹综合症，详见第14.2节。

34.     Overestimated savings from new tools or methods. （过高估计了新技术或新方法带来的收益）

对新技术或新方法带来的收益有较理性的认识，详见第14章。

35.     Switching tools In the middle of a project. （在项目进行期间更换开发工具）

持续使用久经考验的旧工具，详见第14章。

36.     Lack of automated source-code control. （缺少自动化源代码控制）

必须使用自动化源代码控制系统。

最佳实践：Source Code Control System

给整个项目乃至整个公司选择一个source code control system。这个source code control system可以是商业软件系统（如ClearCase，Perforce等），也可以是免费软件。只有在source code control system就绪之后，才开始启动你的项目。