跳转至

Chapter 7 | Principles that Guide Practice

约 3566 个字 预计阅读时间 18 分钟

Principles that Guide Process（指导过程的原则）

  1. Be agile（保持敏捷）

无论你选择的是规范性的还是敏捷的软件过程模型，敏捷开发的基本原则都应当指导你的方法。灵活应对变化，快速响应需求。

  1. Focus on quality at every step（每一步都关注质量）

每一个过程活动、动作和任务的退出条件都应关注所产出的工作产品的质量。质量控制贯穿于开发的每一个环节。

  1. Be ready to adapt（随时准备适应变化）

过程不是宗教信仰，经验主义和教条主义没有立足之地。必要时，应根据问题、人员和项目本身施加的约束调整你的方法。

  1. Build an effective team（建设高效团队）

软件工程的过程和实践固然重要，但归根结底最重要的是人。建立一个自组织、互相信任和尊重的团队。

  1. Establish mechanisms for communication and coordination（建立沟通与协调机制）

项目失败往往是因为重要信息被遗漏，或利益相关者之间缺乏协调。必须建立机制，确保信息畅通和团队协作。

  1. Manage change（管理变更）

无论采用正式还是非正式的方法，都必须建立机制来管理变更的请求、评估、批准和实施。

  1. Assess risk（评估风险）

软件开发过程中可能出现各种问题，必须建立应急预案，及时识别和应对风险。

  1. Create work products that provide value for others（创造有价值的工作产品）

只创造那些对其他过程活动、动作或任务有价值的工作产品，避免无效或多余的产出。

Principles that Guide Practice（指导实践的原则）

  1. Divide and conquer（分而治之）

用更技术化的方式来说，分析和设计应始终强调关注点分离（Separation of Concerns, SoC）。将复杂问题分解为更小、更易管理的部分，有助于降低复杂性，提高效率。

  1. Understand the use of abstraction（理解抽象的使用）

抽象的本质是对系统中某些复杂元素的简化，用于用一句话传达复杂含义。善用抽象可以帮助我们更好地理解和表达系统。

  1. Strive for consistency（追求一致性）

熟悉的上下文让软件更易于使用。保持设计和实现的一致性，有助于用户理解和使用系统。

  1. Focus on the transfer of information（关注信息传递）

特别关注接口的分析、设计、构建和测试。信息的有效传递对于系统的正确性和可维护性至关重要。

  1. Build software that exhibits effective modularity（构建高效模块化的软件）

关注点分离（原则1）确立了软件设计的哲学，而模块化为实现这一哲学提供了机制。良好的模块化有助于系统的扩展和维护。

  1. Look for patterns（寻找模式）

Brad Appleton 指出，模式的目标是为软件开发社区创建一套文献，帮助开发者解决在整个软件开发过程中遇到的重复性问题。

  1. When possible, represent the problem and its solution from a number of different perspectives（多角度表达问题及其解决方案）

尽可能从多个不同的视角来表达问题和解决方案，有助于更全面地理解和解决复杂问题。

  1. Remember that someone will maintain the software（牢记软件需要维护）

始终记住，软件最终会由他人维护。良好的设计和文档能够极大地降低维护成本。

Communication Principles（沟通原则）

  1. Listen（倾听）

专注于倾听对方的话语，而不是急于组织自己的回应。有效的沟通首先要理解对方的观点和需求。

  1. Prepare before you communicate（沟通前做好准备）

在与他人会面前，花时间理解问题。准备充分可以让沟通更高效、更有针对性。

  1. Someone should facilitate the activity（需要有协调者）

每次沟通会议都应有一位领导者（协调者），以确保讨论高效进行、及时调解冲突，并保证其他沟通原则得到遵守。

  1. Face-to-face communication is best（面对面沟通效果最佳）

面对面沟通通常最有效，但如果能有相关信息的其他表达形式辅助，效果会更好。

  1. Take notes and document decisions（记录要点和决策）

沟通中应有人担任“记录员”，将所有重要观点和决策记录下来，便于后续追溯和落实。

  1. Strive for collaboration（追求协作）

团队成员的集体知识结合在一起，才能实现真正的协作和共识。

  1. Stay focused, modularize your discussion（保持专注，模块化讨论）

参与沟通的人越多，话题越容易发散。要有意识地聚焦主题，将讨论模块化，避免无效扩散。

  1. If something is unclear, draw a picture（不清楚就画图）

如果某个问题难以表达清楚，可以用图示帮助理解和沟通。

  1. 关于分歧和不确定性的处理
  • 一旦达成一致就继续推进；
  • 如果无法达成一致也要及时推进；
  • 如果某个功能或特性暂时无法澄清，也要先继续，后续再完善。
  1. Negotiation is not a contest or a game. It works best when both parties win（协商不是比赛，双赢为佳）

协商不是比赛或游戏，只有双方都获益时，协商才最有效。

Planning Principles（计划原则）

  1. Understand the scope of the project（理解项目范围）

如果你不知道目的地，就无法使用路线图。范围为软件团队提供了目标和方向。

  1. Involve the customer in the planning activity（让客户参与计划活动）

客户定义优先级并设定项目约束条件。客户的参与有助于确保计划符合实际需求。

  1. Recognize that planning is iterative（认识到计划是迭代的）

项目计划不是一成不变的。随着工作的推进，计划很可能会发生变化。

  1. Estimate based on what you know（基于已知进行估算）

估算的目的是根据团队当前对工作内容的理解，给出工作量、成本和工期的初步指示。

  1. Consider risk as you define the plan（制定计划时考虑风险）

如果识别出高影响、高概率的风险，就必须进行应急预案。

  1. Be realistic（保持现实）

人们不可能每天都100%高效工作，计划时要考虑实际情况。

  1. Adjust granularity as you define the plan（调整计划的细化程度）

细化程度指的是项目计划中引入的详细程度。应根据实际需要调整计划的粒度。

  1. Define how you intend to ensure quality（明确如何保证质量）

计划中应明确团队将如何保证软件质量。

  1. Describe how you intend to accommodate change（说明如何应对变更）

即使是最好的计划也可能被不可控的变更打乱，必须说明如何适应和管理变更。

  1. Track the plan frequently and make adjustments as required（持续跟踪并及时调整计划）

软件项目往往是每天一点点落后于进度，因此要经常跟踪计划并根据实际情况及时调整。

Modeling Principles（建模原则）

在软件工程工作中，可以创建两类模型：

Requirements models (also called analysis models)（需求模型/分析模型）

需求模型用于通过描述软件在三个不同领域中的表现来表达客户需求：

  • 信息域（information domain）：系统需要处理和管理的数据。
  • 功能域（functional domain）：系统需要实现的功能和服务。
  • 行为域（behavioral domain）：系统在不同情况下的行为和响应。

Design models（设计模型）

设计模型用于表达软件的特性，帮助开发者高效地构建系统，包括：

  • 架构（architecture）：系统的整体结构和组件关系。
  • 用户界面（user interface）：用户与系统交互的方式和界面设计。
  • 组件级细节（component-level detail）：各个组件的具体实现细节。

Agile Modeling Principles（敏捷建模原则）

  1. The primary goal of the software team is to build software not create models（首要目标是构建软件而非建模）

敏捷团队的核心目标是交付可用的软件，模型只是辅助工具，不应本末倒置。

  1. Travel light – don’t create more models than you need（轻装上阵，只建必要的模型）

只创建真正需要的模型，避免无谓的文档和模型负担。

  1. Strive to produce the simplest model that will describe the problem or the software（追求最简模型）

力求用最简单的模型描述问题或软件，避免复杂化。

  1. Build models in a way that makes them amenable to change（模型易于修改）

模型要易于修改和扩展，以适应需求和环境的变化。

  1. Be able to state an explicit purpose for each model that is created（明确每个模型的用途）

每个模型都应有明确的目标和用途，避免无效建模。

  1. Adapt the models you create to the system at hand（模型要贴合实际系统）

所建模型要与当前系统实际情况相适应，不能脱离实际。

  1. Try to build useful models, forget about building perfect models（实用优先，不求完美）

关注模型的实用性，而不是追求形式上的完美。

  1. Don’t become dogmatic about model syntax. Successful communication is key（不拘泥于语法，重在沟通）

不要死板地追求模型语法，关键是模型能否促进有效沟通。

  1. If your instincts tell you a paper model isn’t right you may have a reason to be concerned（直觉不对就要警惕）

如果直觉告诉你模型有问题，要及时关注和调整。

  1. Get feedback as soon as you can（尽早获取反馈）

尽早让团队和相关人员对模型提出反馈，及时发现和修正问题。

Requirements Modeling Principles（需求建模原则）

  1. The information domain of a problem must be represented and understood（必须表示并理解问题的信息域）

在需求建模时，首先要清楚系统涉及和处理的数据内容。

  1. The functions that the software performs must be defined（必须定义软件执行的功能）

明确系统需要实现的所有功能，为后续设计和开发提供基础。

  1. The behavior of the software (as a consequence of external events) must be represented（必须描述软件的行为）

需要建模系统在外部事件驱动下的各种行为和响应。

  1. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion（模型应分层/分级揭示细节）

信息、功能和行为模型应分层或分级展开，逐步揭示系统的细节。

  1. The analysis task should move from essential information toward implementation detail（分析应从本质信息逐步深入到实现细节）

需求分析应先关注核心和本质信息，再逐步细化到实现层面的细节。

Design Modeling Principles（设计建模原则）

  1. Design should be traceable to the requirements model（设计应可追溯到需求模型）

设计的每一部分都应有明确的需求来源，确保实现的内容与需求一致。

  1. Always consider the architecture of the system to be built（始终考虑系统架构）

设计时要有全局观念，关注系统的整体结构和各部分的协作关系。

  1. Design of data is as important as design of processing functions（数据设计与功能设计同等重要）

数据结构和数据流的设计与功能处理同样关键，不能忽视。

  1. Interfaces (both internal and external) must be designed with care（接口需谨慎设计）

无论是内部接口还是外部接口，都要精心设计，确保系统各部分能顺畅协作。

  1. User interface design should be tuned to the needs of the end-user. Stress ease of use（用户界面设计应以用户为中心，强调易用性）

用户界面要贴合终端用户需求，注重友好性和易用性。

  1. Component-level design should be functionally independent（组件级设计应具备功能独立性）

各组件应尽量独立，减少相互依赖，便于维护和扩展。

  1. Components should be loosely coupled to each other than the environment（组件之间应松耦合）

组件之间的联系应尽量松散，降低耦合度，提高灵活性。

  1. Design representations (models) should be easily understandable（设计模型应易于理解）

设计表达要清晰明了，便于团队成员和利益相关者理解和沟通。

  1. The design should be developed iteratively（设计应迭代推进）

设计过程应分阶段、逐步完善，持续优化。

  1. Creation of a design model does not preclude using an agile approach（建模不排斥敏捷方法）

创建设计模型时可以结合敏捷开发理念，灵活应对变化。

Living Modeling Principles（动态建模原则）

  1. Stakeholder-centric models should target specific stakeholders and their tasks（以利益相关者为中心的模型应针对具体对象和任务）

建模时要明确服务的对象和他们的实际需求。

  1. Models and code should be closely coupled（模型与代码应紧密关联）

模型和代码应保持同步，模型的变更能及时反映到代码中，反之亦然。

  1. Bidirectional information flow should be established between models and code（模型与代码之间应建立双向信息流）

信息应能在模型和代码之间自由流动，确保一致性和可追溯性。

  1. A common system view should be created（应建立统一的系统视图）

团队成员应共享统一的系统整体视图，促进协作和沟通。

  1. Model information should be persistent to allow tracking system changes（模型信息应持久化以便跟踪系统变更）

模型信息要能长期保存，便于追踪和管理系统的演变。

  1. Information consistency across all model levels must be verified（各层级模型的信息一致性需验证）

不同层级的模型之间要保持信息一致，避免矛盾和遗漏。

  1. Each model element has assigned stakeholder rights and responsibilities（每个模型元素应分配利益相关者的权责）

明确每个模型元素对应的责任人及其权利和义务。

  1. The states of various model elements should be represented（应表示各模型元素的状态）

对模型中的各个元素，其状态变化应有明确的表达和记录。

评论