业务驱动型软件开发的六大关键原则

### 业务驱动型软件开发的六大关键原则 在同一领域的组织，会像哈德逊河上的多座桥梁为交通流量竞争一样，争夺相同的市场、开拓新市场或巩固现有市场。维护将各种视角联系在一起的系统的团队，常面临在 IT 系统中执行最新业务规则的挑战，这使得软件工程师需要不同于其他工程师的流程模型来指导开发。IBM Rational 基于软件开发技术总结出了六个关键原则，助力组织和项目走向成功。 #### 1. 关键原则概述 这六个关键原则分别是： - 调整流程（Adapt the Process） - 平衡利益相关者的竞争优先级（Balance Competing Stakeholder Priorities） - 跨团队协作（Collaborate Across Teams） - 迭代展示价值（Demonstrate Value Iteratively） - 提升抽象层次（Elevate the Level of Abstraction） - 持续关注质量（Focus Continuously on Quality） 这些原则尤其适用于业务驱动的开发环境，它们是原本的六大最佳实践的演进，强调了对业务驱动开发的重要价值，且彼此同等重要、相互促进，易于记忆（从 A 到 F）。 #### 2. 调整流程 “一刀切”原则不适用于软件开发，需根据项目需求适当配置开发流程，包括活动粒度、输入输出工件、角色、政策法规等。诸多因素会影响流程配置，如项目规模、复杂度、风险和团队结构等。在 Rational 统一流程（RUP）中，环境学科致力于协助流程调整。 ##### 2.1 好处 - **生命周期效率**：适配流程能兼顾项目效率和有效性，交付高质量、低成本的软件解决方案。通过合理调整流程规模、仪式感、持续改进流程以及平衡项目计划与不确定性，可提高生命周期效率。在生命周期早期鼓励创新，后期增强可控性和可预测性。 - **风险沟通**：RUP 基于风险设计，尽早识别和缓解最高风险。项目早期较少的控制和宽松的形式有利于坦诚沟通，从而更好地识别和管理项目风险。 ##### 2.2 模式 - **合理调整流程规模**：流程规模体现所需的正式程度，包括工件和模型数量、细节、评审次数和报告类型及频率等。更多正式性不总是更好，需根据项目规模、资源分布、技术复杂度、利益相关者数量、合规要求和项目阶段等因素，正确配置基本流程以提高项目成功概率。 |影响因素|具体情况|对流程规模的影响| | ---- | ---- | ---- | |项目规模|大|可能需要更严格的流程| |资源分布|分散|可能需要更严格的流程| |技术复杂度|高|可能需要更严格的流程| |利益相关者数量|多|可能需要更严格的流程| |合规要求|有外部标准或法规要求|可能需要更严格的流程| |项目阶段|后期|可能需要更严格的流程| - **根据生命周期阶段调整流程仪式感**：项目生命周期的不同阶段对仪式感的需求不同。早期需要更多创造力，应保持必要的仪式感以鼓励创新；当项目进入架构和开发阶段，为确保产品按时符合愿景，需要增加控制。 ```mermaid graph LR classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px; classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px; A([项目启动]):::startend --> B(初始阶段):::process B --> C(细化阶段):::process C --> D(构建阶段):::process D --> E(过渡阶段):::process E --> F([项目结束]):::startend subgraph 仪式感变化 style 仪式感变化 fill:#ffffff,stroke:#000000,stroke-width:1px B1(低仪式感):::process --> B2(仪式感渐增):::process --> B3(高仪式感):::process end B --> B1 C --> B2 D --> B3 E --> B3 ``` - **持续改进流程**：在 RUP