《快速软件开发》学习笔记 之一
第1章 软件开发策略
1.1 软件开发中的四维
任何软件项目，都有四个重要的维： people、process、product和technology。为使项目能顺利进行，软件经理必须充分发挥这四维的作用。下表是对这四维的总结。
表 1-1 软件开发中的四维
| 维度 | 如何优化 |
| 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 软件开发的总体策略
一个软件进行的软件项目应该遵循如下的4点策略：
1. Avoid classic mistakes. （避免典型错误）
2. Apply development fundamentals. （采用软件开发的基础性实践）
3. Manage risks to avoid catastrophic setbacks. （管理风险，以避免灾难性的结果）
4. Apply schedule-oriented practices. （采用面向进度的实践）
这4点策略可以 用下图来形象地表示。
这4点策略就像是4根支柱，共同支撑起一个成功的软件项目。尤其是前面3点策略，是每个软件项目高效进行的关键。
第2章 典型错误
迈克尔·杰克逊曾唱过：“孩子，一个坏不要坏了整筐苹果”。但在软件开发领域，一个坏苹果是可以毁掉一筐苹果的！软件经理必须记住：一个软件项目只要犯了一个典型错误，就会滑向慢速开发的深渊；要实现快速开发，就“必须”避免所有的典型错误。
软件经理怎样做到避开这所有的典型错误呢？使用“典型错误列表”。
| 最佳实践：典型错误列表 1. 以表2-1作为初始的典型错误列表。 2. 从投入到某个项目的第一天起，每天在下班之前检查一遍典型错误列表，反省自己或团队有没有犯典型错误。如果有，思考一下怎么改变。 3. 在每个项目结束之后，分析总结在项目中所犯的典型错误。如果是典型错误列表中不存在的，把它加入到典型错误列表中，供下个项目使用。 |
表 2-1 典型错误列表
| 相关维度 | 典型错误 | 解决办法 |
| 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就绪之后，才开始启动你的项目。 |
