《软件开发珠玑》笔记

作者【美】Karl Wiegers（卡尔.魏格斯）博士是全球公认的软件需求工程、过程改进和软件质量专家，享有盛誉的技术作家，他经常在国际会议上发表演讲，并为各种组织提供培训和咨询服务。除了本书外，还有其它经典著作《软件需求》、《高质量需求》、《创建软件工程文化》、《软件同级评审》等。本书英语名《Software Development Pearls - Lessions from Fifty Years of Software Experience》，作者将50年在软件工程领域的经验和教训凝结为此书。

本书介绍了关于软件开发和管理的60条经验教训，分为6个领域，包括需求、设计、项目管理、文化与团队合作、质量、过程改进。

我对照下来，作者分享的经验与我们开展的研发质量改进活动的理念和举措大体一致，有些是提醒，有些是鼓励。下面分享总结一些重点内容：

第1章 吸取经验教训

除了介绍作者和本书内容，还给出很好的看书与学习新技术的建议。那就是快速学习并立即将所学的东西应用到正在做的事情上。学以致用，应用过的技术印象会比较深刻，否则看过就忘记了。我们都需要不断提高自己的能力，我们都需要尽量少“踩坑”。

第2章 需求

组建需求的过程不只涉及收集数据操作，同时涉及发现与创造（需求启发）。需求工程中的启发技术包括访谈、小组研讨会、观察、文档分析、调查、维基百科、原型。

高质量的软件是基于高质量的需求开发的，这些需求被精心设计成可用的形式，并被传递给每一个需要了解它的人。无论是敏捷开发项目还是传统开发项目，开发人员对实现正确功能所需的信息都是一样的。敏捷方法遵循轻量、实时的文档原则，但主要依靠口头沟通会带来风险。文档是一种持久的集体记忆，是团队成员可以跨时空参考的资源。文档必须是最新的、准确的、对于需要的人来说，还必须是可获取的。如果读者不能轻易找到他们需要的内容，那么文档好不好就无所谓了。有些人误解了敏捷开发的理念，抵制创建文档，这是从传统模型过于偏向文档走向了另一个极端。敏捷开发的目标是在文档和讨论之间录求平衡。有个判断是否需要文档记录的方法可以参考：如果你在实践过程中发现记录知识比发现或者重新发现知识成本低，那就记录下那些值得记录的信息。

要使沟通明晰，核心是使用标准词汇及符号。许多标准方法用以绘制分析与设计模型，强烈推荐大家使用：

• 结构化分析(Structured Analysis, SA)(DeMacro,1979)
• IDEF0(Feldmann, 1998)
• 统一建模语言(Unified Modeling Language,UML)(Booch et al.,1999)
• 需求建模语言(Requirements Modeling Language, RML)(Beatty和Chen， 2012)

第3章 设计

需求和设计之间的界限并不十分清晰，而是一个模糊的灰色地带。软件设计的本质是将需求与代码片段联系起来，包括四个方法：架构设计（又称概要设计、逻辑设计或高层设计）、细节设计（又称模块设计、物理设计或低层设计）、数据库设计以及用户体验设计。在我司用户体验设计是由专业的UX设计师负责。

无论是在需求阶段还是设计阶段，画图以代表系统的各个方面都很有价值， 我们可以在这些图表上持续迭代。强烈建议在为需求或设计进行建模时，使用既定符号。若你想探索、修改、记录和分享你的设计想法，请采用像UML这样的标准，而不是自己发明的符号，因为别人可能无法理解你自己的体系。

匆忙执行设计可能产生技术债。技术债应当是暂时的，并须稳定偿还。好的设计可最大限度减少技术债的产生，而重构则用于减少已积累的技术债。二者合理平衡将产生最好的结果。有缺陷的初始设计会导致过度返工；而过于规范的设计则会耗费过多的时间，有时这会错失商机，过犹不及。

第4章 项目管理

人类是单线程工作的，即同时只能完成 一项任务，在多任务之间只能来回转换。程序员特别容易受到多任务处理的影响而增加耗时。像软件开发、写文档等创造性的知识型工作，需要依靠进入心流状态才能高效工作。“打断”是心流杀手。一些报告指出，“中断”和“任务转换”会使知识工作者至少损失15%的时间。

无人可精准窥探未来，我们所能做的只是依据过往经验进行推演，在必要之处进行调整，并承认不确定性困难。项目团队必须从五个维度进行管理：范围、职员、质量、预算、排期。必须决定每个项目的哪些方面更为重要，并同时平衡其他维度，以此来实现项目的基本目标。

第5章 文化与团队合作

一致性是健康文化的关键。一致性意味着管理者和团队成员的行为方式与组织所宣称的价值一致，而不是按照可能与官方声明相冲突的潜规则形式。显性文化元素有助于所有团队成员接受共同价值观，从而促进合作。一个健康的组织会促进自由知识交流和持续学习的文化，不做知识守财奴。

雇用几个精英员工，比用普通员工组成的更大的团队效果更好。然而，你不能只把你的团队换成一组新的更有能力的人，你需要让你拥有的人更具生产力。如何提高生产力，作者推荐了四个方法：

• 第一个方法：停止做那些项目、产品或客户没有增值的工作；
• 第二个方法：提高团队产品的质量，增加静态分析、同行评审这类行之有效的做可能会花费一些时间，但它们可以减少下游的返工，从而得到回报；
• 第三个方法：搞清楚时间都在哪里浪费了，通过加快位于项目关键路径上的活动来提高产量；
• 第四个方法：提高团队成员的个人能力，选择更合适的流程和技术实践，可以产生效果显著的质量改进。

此外，培训是一个强大的绩效提升杠杆，但前提是人们把学到的东西真正运用到工作中去。

第6章 质量

质量描述的是产品实现了它所要完成的任务的程度。管理层必须塑造一种文化，让团队成员在第一次就把工作做好，而且要有这样的期望、能力和条件。

正确使用工具和实践可以为项目增加巨大的价值，提高质量和生产力，改善规划和写作，并从混乱中带来秩序。但即使是最好的工具也无法克服薄弱的流程、未经培训的团队成员、具有挑战性的变革倡议或组织中的文化问题。一个工具不能替代一个流程，而只能支持一个流程。

有时候为了加速开发进程，积累一些技术债是可以接受的，只要团队充分认识到不久后需要花费更多时间改进有缺陷的设计。很多预防性维护工作都是为了清除技术债。无论是对当前项目上一次迭代的代码进行重构，还是处理脆弱的遗留系统，你的目标都应该是让代码比你接手时更好。这样做比仅仅诅咒那些制造你面临混乱的早期开发人员更有建设性。

第7章 过程改进

软件过程改进的目标是降低开发和维护软件的成本。敏捷软件开发宣言第十二条原则是：“团队应定期反思如何变得更有效，然后相应地调整和改进行为”，这就是过程改进的精髓。

作者认为，在战略改进方面只有两次失败的尝试机会，然后人们会得出结论认为组织并不是真心想改变。在经历过两次失败之后，很少有团队成员会认真对待下一次变革举措。 其实就是中国的古话“一鼓作气，再而衰，三而竭”。

“成功的过程改进需要时间。组织需要坚持足够长的时间才能获益。几乎任何系统性的改进方法都可以带来更好的结果。然而，如果你中途放弃，即在投资评估和学习之后、变革带来回报之前放弃，你将让你的投资付之东流。因为大规模的过程变革不会很快，所以要学会从小胜仗中获得满足。试着去发现那些可以快速实施的改进措施，解决已知问题，同时也考虑那些长期的、系统性的变革。 ”摘抄这段话，与正在开展过程改进工作的同学们共勉。我自己参与了两年的研发质量改进工作，真知道这中间的复杂和困难，希望自己在变革带来回报之前不要放弃！

过程改进的本质：设定目标，识别障碍，选择你认为可以解决他们的技术。过程改进应强调首先扑灭火源，然后预防火灾，以此来减少项目带的痛苦。有效的变革举措必须考虑团队的整体成果，而不仅仅是对每个个体生产力、效率或舒适度的影响。作者给了好些实用的建议：根因分析、在期望的方向上施加持续的温和的压力、向上管理、使用能完成工作的最简单的工具、用文档模板践行自适应哲学。关于流程，作者认为它是一种结构而不是束缚，不要教条地遵循过于规定性的流程或方法，流程不能取代思考。基于经验而产生的判断力有助于实践者知道何时遵循流程是明智的，何时改进流程更为明智。

回顾与持续改进相结合，会促使已知痛点得到改变。

第8章 然后呢

软件过程改进是一段旅程，而不是一个终点。它是一个循环，而不是一条直线。