English
A software process organizes how a team discovers needs, makes decisions, builds and checks changes, delivers them, and learns from their use. It includes how work enters a queue, who can resolve an unclear requirement, and what happens when a test or deployment fails. Even a team with no named methodology has a process, because these decisions still occur.
The central problem is coordinating work while important facts are still being learned. A customer may request “cancel a booking” without specifying when a refund is permitted or what should happen after a payment timeout. Coding faster does not resolve that ambiguity. A short example reviewed with the customer may prevent several components from implementing incompatible rules.
A useful process makes work and uncertainty visible, obtains feedback before too much depends on an assumption, and gives someone authority to act on the result. Documentation, reviews, prototypes, and automated checks serve different parts of this task. Their value depends on the information they provide and the consequences of an error, not on whether they belong to a fashionable method.
Prerequisites: Programming (§2.1), testing (§7.2), and basic architectural boundaries (§7.1). A small collaborative project provides enough context to observe handoffs, waiting, and integration.
From Sequential Plans to Continuous Delivery
The software engineering discussions of the 1960s addressed more than programming technique. Large operating-system projects had to coordinate interfaces, schedules, testing, and changing requirements across many people. The 1968 and 1969 NATO conferences helped establish software engineering as a shared agenda; they should not be treated as the first time anyone organized software development or necessarily the first use of the term.
Brooks’s The Mythical Man-Month drew on the OS/360 experience. Adding staff late can delay a project because existing staff must teach newcomers, communication grows, and some work cannot be divided. This is a warning about onboarding and dependencies, not a law that every additional person reduces output. The relevant question is which work can be delegated and when the new capacity becomes usable.
Royce’s 1970 paper showed a sequence of development activities but also described the risk of discovering crucial problems only during late testing. He proposed additional design work, feedback, a preliminary implementation, and customer involvement. Treating this as a simple endorsement of one-pass development loses its argument. Boehm’s later spiral model made the next cycle depend explicitly on risks: an uncertain interface, performance limit, or user requirement may call for different kinds of investigation.
Iterative development revisits and improves a solution; incremental development adds usable capabilities. A project can do both. Scrum and Extreme Programming developed before the 2001 Agile Manifesto. The manifesto expressed priorities for adapting through working software and collaboration while still recognizing value in plans, tools, contracts, and documentation. It did not prescribe a single workflow.
Scrum supplies a cadence for inspection and adaptation; XP specifies reinforcing engineering practices such as frequent integration, testing, and refactoring. Kanban focuses attention on the flow of work and limits on work in progress. These approaches overlap but are not interchangeable labels. A sprint containing separate analysis, coding, and testing queues can still delay feedback until the end.
Continuous delivery brought the release path into the same discussion: software should remain deployable, with evidence from a repeatable pipeline (§7.4). DORA’s research has found relationships among delivery practices, delivery outcomes, and organizational outcomes. Its surveys and statistical models are useful evidence, but structural equation modeling alone does not remove confounding or establish what changing one practice will cause in every organization. Use the findings to form local improvement hypotheses and examine the results.
Process Structure, Feedback Loops, and Organizational Context
The Fundamental Structure of Effective Processes
Separate feedback questions. A unit test can reveal that a calculation is wrong, an integration test that two components disagree, and a user review that the intended feature solves the wrong problem. Shortening one loop does not replace the others. Choose a small deliverable that exercises a meaningful path through the system, such as reserving one kind of seat, rather than completing all database tables before showing any behavior.
Continuous integration combines changes frequently and checks the combined result. Running CI software on isolated branches is not enough if the branches are only merged after weeks. Small changes and short-lived branches reduce the amount of work whose assumptions can diverge. Unfinished behavior can remain inaccessible behind a controlled feature flag, but that flag and the integrated code still need checks.
Queueing often dominates elapsed time. If an item takes two hours to implement, waits three working days for review, and then takes an hour to release, faster typing addresses little of the delay. Record waiting and active work separately before deciding where to improve. Starting more items can increase the review queue without increasing completed work.
Little’s Law relates long-run averages for a stable flow with consistent boundaries: L = λW, where L is work in progress, λ is completion throughput, and W is time in the system. If a workflow averages 10 items in progress and finishes 5 per week, its average time is 2 weeks. Reducing average work in progress to 5 would imply 1 week only if throughput remains 5 per week. The relation does not prove that any WIP limit will preserve throughput, nor predict an individual item’s finish date.
A process also needs a response to feedback. Assign responsibility for a broken build, an unanswered requirement, or a growing queue. A retrospective is useful when an observed problem leads to a specific experiment, an owner, and a later review. An automated deployment can repeat a configuration mistake consistently; automation reduces manual variation while making review and observation of the automated process necessary.
Planning, Backlog Management, and Estimation
Distinguish a goal, a forecast, and a commitment. A goal states a desired outcome, a forecast estimates what is likely under assumptions, and a commitment allocates responsibility for an agreed result. Turning a forecast into a demand without changing scope, resources, or risk does not make the forecast more accurate.
Clarify a work item with examples and acceptance conditions. “Cancel a reservation” might require releasing the seat, requesting a refund where permitted, and making retries harmless. A short investigation is appropriate when the payment provider’s behavior is unknown. Splitting the work should expose usable progress or reduce a specific uncertainty, not simply create more tickets.
Dependencies constrain schedules. If tasks A and B take 2 and 3 days and can run in parallel with sufficient capacity, followed by a 1-day task C that needs both, the earliest completion is 4 days. If B must wait for A, it is 6 days. More staffing does not remove that dependency. These are simplified deterministic estimates; real forecasts also need uncertainty, review time, and resource constraints.
Historical cycle times and throughput can support forecasts when the work, team, and measurement boundaries remain reasonably comparable. Use ranges or percentiles, identify scope assumptions, and revise as evidence arrives. A forecast derived from small fixes is weak evidence for an unfamiliar data migration. Story points can support local discussion, but their scales are not standardized across teams and should not become productivity rankings.
Scrum’s 2020 guide defines Sprints of one month or less and the accountabilities of Product Owner, Scrum Master, and Developers. Kanban can manage continuous flow without a sprint boundary. Either approach needs clear entry and completion conditions, explicit priority decisions, and capacity for interruption. Define where lead time and cycle time start in your own measurements; different tools use those terms differently.
Coordination at Scale
As teams multiply, map dependencies among deliverables and the decisions required at each boundary. A shared API needs an owner, examples of compatible behavior, and a migration policy. A platform team can reduce repeated work by supplying a usable capability, but can also become a queue if every ordinary change requires its manual approval. The number of teams is less informative than the waiting and coordinated changes between them.
Conway’s observation connects communication patterns with system structure (§7.6). It suggests checking whether teams can make routine changes through stable contracts. It does not require one team per service or predict an exact architecture from an organization chart. Temporary collaboration may be useful while a domain is poorly understood; a stable service interface may later reduce that need.
Measure delivery as a system. DORA’s current five metrics cover change lead time, deployment frequency, failed-deployment recovery time, change fail rate, and deployment rework rate. They concern delivery of an application or service, not individual output. Pair these with user outcomes and reliability. Improving a count by splitting deployments differently may change the metric without improving the product.
Teams also need to report unwelcome information. An engineer who can say that a migration is not ready gives the organization a chance to adjust. A manager who asks for uncertainty estimates and then penalizes every changed estimate encourages concealment. Clear ownership, respectful challenge, and explicit escalation paths make the technical feedback mechanisms usable.
What Studying This Changes
You can examine a process by following one work item from request to use. Record the decisions, active work, waiting, and feedback. This often reveals why adding a meeting or another tool does not address the actual delay.
For a small project, choose one observed obstacle and one change: for example, arrange a daily review window to reduce a long review queue. Measure both waiting time and the quality of reviewed changes. Keep scope and workload differences in view rather than attributing every improvement to the intervention.
The practical skill is choosing an appropriate next source of information. A requirements example, a prototype, a test, and a production measurement reduce different uncertainties. Effective process makes it possible to obtain that information and revise the plan while there is still time to benefit.
Resources
Books and Texts
Brooks describes coordination problems in large projects; Beck’s Extreme Programming Explained develops a set of interacting practices. Continuous Delivery follows a change through release, while Team Topologies examines team boundaries. Accelerate is useful for its research questions and historical findings; use subsequent DORA material to check definitions that have changed. These books provide different perspectives, not a required sequence for every project.
| Book | Role | Type |
|---|---|---|
| Accelerate / DORA research (§7.4 reference) | Empirical foundation for delivery performance | Entry |
| The DevOps Handbook (§7.4 reference) | Practical DevOps implementation | Practice |
| Continuous Delivery (§7.4 reference) | Deployment pipeline foundational text | Depth |
| Beck, Extreme Programming Explained (2nd ed.) | XP foundational text | Depth |
| Brooks, The Mythical Man-Month (anniversary ed.) | Software management primary text | Depth |
| Team Topologies | Team structure for delivery | Depth |
| Kim, Behr & Spafford, The Phoenix Project | Fictional case of delivery and operations coordination | Practice |
| Anderson, Kanban: Successful Evolutionary Change | Kanban methodology | Depth |
| Reinertsen, Principles of Product Development Flow | Flow-based development theory | Depth |
| Winters, Manshreck & Wright, Software Engineering at Google (free online; paid print) | Large-scale engineering practice | Depth |
Courses, Papers, and Current Sources
Compare Royce’s original paper, the Agile Manifesto, and the Scrum Guide with common summaries of them. DORA’s metric guide defines the delivery measures; its research models make some modeling assumptions visible. SPACE and DevEx add perspectives on productivity and development experience.
| Resource | Platform | Type |
|---|---|---|
| DORA research program and State of DevOps reports (free) | dora.dev | Reference |
| Royce, “Managing the Development of Large Software Systems” (1970) | Original paper; university-hosted scan | Depth |
| Agile Manifesto and principles (free) | agilemanifesto.org | Reference |
| SPACE framework (free) | ACM Queue | Reference |
| DevEx framework (free) | ACM Queue | Reference |
| Shape Up (free online; paid print) | basecamp.com/shapeup | Auxiliary |
| The Scrum Guide (free) | scrumguides.org | Reference |
Practice, Tools, and Current Sources
Map one actual work item, including waiting, clarification, review, testing, and release. Choose one delay to investigate before introducing another tool. A simple log or board is sufficient to start. Keep the definitions of start, finish, and failure stable enough that a before-and-after comparison has meaning.
| Resource | Platform | Type |
|---|---|---|
| DORA DevOps Quick Check (free) | dora.dev | Practice |
| Value stream mapping exercise | Local | Practice |
| Deployment frequency tracking | CI/CD system | Practice |
| Trunk-Based Development (free) | trunkbaseddevelopment.com | Practice |
Traps
| Trap | Why it misleads | Better response |
|---|---|---|
| Adopting ceremonies without a feedback purpose | A meeting can report progress without resolving any uncertainty. | State what decision or adaptation each activity supports. |
| Calling branch checks continuous integration | Separate branches can pass while their eventual combination fails. | Integrate frequently and check the combined result. |
| Treating estimates or story points as individual targets | Pressure can change reporting and ticket size without improving outcomes. | Forecast with stated assumptions and evaluate useful delivery and quality. |
| Reading survey associations as universal causes | Context, selection, and confounding can affect observed relationships. | Use research to propose improvements and assess local evidence. |
| Starting more work to speed completion | A bottleneck may accumulate a larger queue instead. | Track work in progress, waiting, and completion together. |
中文
软件过程组织团队怎样发现需求、做决定、构建和检查修改、交付软件，并从使用结果中学习。它包括工作怎样进入队列、谁能澄清模糊需求、测试或部署失败后怎样处理。即使团队没有采用具名方法，也仍然有过程，因为这些决定始终会发生。
核心问题是在重要信息仍未确定时协调工作。客户可能提出“取消预约”，却没有说明何时可以退款，或支付超时后应该怎样处理。更快写代码并不能消除这些歧义。先与客户审阅一个简短示例，可能避免几个组件实现相互冲突的规则。
有用的过程使工作和不确定性可见，在太多后续工作依赖某个假设之前获得反馈，并使相关人员有权据此行动。文档、审查、原型和自动检查分别承担其中不同任务。它们的价值取决于提供的信息和错误的后果，而不是是否属于流行方法。
前置知识：编程（§2.1）、测试（§7.2）和基本架构边界（§7.1）。小型协作项目就足以帮助观察交接、等待和集成。
从顺序计划到 Continuous Delivery
1960 年代的软件工程讨论不只涉及编程技巧。大型操作系统项目需要许多人协调接口、进度、测试和不断变化的需求。1968 年和 1969 年的 NATO 会议，帮助把软件工程确立为共同研究议题；不应把它们当成人们首次组织软件开发，也不宜断言它们首次使用了这个术语。
Brooks 的《The Mythical Man-Month》源于 OS/360 的经验。项目后期增加人员可能延误交付，因为原有成员需要培训新人，沟通增加，而且部分工作无法拆开并行。这是在提醒人员上手和任务依赖的成本，而不是“每增加一个人都会降低产出”的定律。应具体判断哪些工作能委派，以及新增能力何时才可用。
Royce 在 1970 年的论文中画出了开发活动的顺序，也说明了直到后期测试才发现关键问题的风险。他提出补充设计工作、反馈、初步实现和客户参与。把这篇论文理解为简单支持一次通过的开发方式，会丢失其论证。Boehm 后来的螺旋模型进一步明确，下一轮工作应取决于风险：不确定的接口、性能上限或用户需求，需要不同的调查方式。
迭代开发反复改进方案；增量开发逐步增加可用能力，项目可以同时采用两者。Scrum 和极限编程在 2001 年《敏捷宣言》之前已经发展起来。宣言强调通过可工作软件与协作来适应变化，同时仍承认计划、工具、契约和文档的价值。它没有规定唯一工作流程。
Scrum 提供检查和调整的节奏；XP 规定相互支持的工程实践，例如频繁集成、测试和重构；看板把注意力放在工作流动与在制工作限制上。这些方法有重合，但不是可以随意替换的名称。即使采用冲刺，如果内部仍设立分离的分析、编码与测试队列，反馈也可能一直拖到最后。
持续交付把发布路径纳入同一讨论：软件应保持可部署，并通过可重复的流水线取得证据（§7.4）。DORA 研究发现了交付实践、交付结果与组织结果之间的联系。其调查和统计模型提供了有用证据，但仅凭结构方程建模，并不能消除混杂因素，也不能证明每个组织改变某项实践都会产生相同效果。应把研究结果用于提出本地改进假设，再检查实际结果。
Process Structure、Feedback Loops 与 Organizational Context
有效过程的基本结构
应区分反馈回答的问题。单元测试可以发现计算错误，集成测试可以发现组件理解不一致，用户审阅可以发现功能本身解决错了问题。缩短其中一个循环不能替代其他循环。可以选择贯通系统的一小块有用能力，例如预约一种座位，而不是先完成所有数据库表，最后才展示行为。
持续集成频繁合并修改，并检查合并结果。如果分支几周后才合并，那么只在隔离分支上运行 CI 软件还不够。小改动与短期分支减少了可能沿着不同假设发展的工作量。未完成行为可以放在受控的功能开关之后，但开关和已集成代码仍然需要检查。
排队常常占据大部分经过时间。如果一项工作实现需要两小时，等待审查需要三个工作日，发布再用一小时，那么提高打字速度改善不了多少延迟。决定如何改进之前，应分别记录等待和实际工作时间。开始更多事项，可能只会扩大审查队列，而不会增加完成量。
Little 定律描述边界一致、流量稳定时的长期平均关系：L = λW，其中 L 是在制工作量，λ 是完成吞吐量，W 是事项在系统内停留的时间。如果流程平均有 10 项工作在进行，每周完成 5 项，那么平均停留时间为 2 周。只有在吞吐量仍为每周 5 项时，把平均在制量降到 5 项才意味着平均时间降到 1 周。这个关系既不能证明任意在制量限制都会保留吞吐量，也不能预测某个事项的具体完成日期。
过程还需要有人响应反馈。构建失败、需求无人回答或队列持续增长时，应明确由谁处理。回顾会议的作用体现在：观察到的问题是否带来具体试验、负责人和后续检查。自动部署可以稳定地重复同一个配置错误；自动化减少人工操作差异，同时也需要审查和观察自动化过程本身。
Planning、Backlog Management 与 Estimation
应区分目标、预测和承诺。目标说明想达到什么结果；预测在一定假设下估计可能发生什么；承诺为约定结果分配责任。如果不改变范围、资源或风险，只把预测变成要求，并不会提高预测的准确性。
用示例和验收条件澄清工作项。“取消预约”可能要求释放座位、在允许时请求退款，并使重试不产生重复影响。如果支付提供方的行为未知，就适合先做短期调查。拆分工作应当暴露可用进展或减少具体不确定性，而不只是增加工单数量。
依赖关系限制进度。假设任务 A 和 B 分别需要 2 天与 3 天，在资源足够时可以并行；随后任务 C 需要 1 天，且依赖两者，那么最早 4 天完成。如果 B 必须等待 A，则需要 6 天。增加人员不能消除这个依赖。这是简化的确定性估计；实际预测还需要考虑不确定性、审查时间和资源限制。
当工作、团队和测量边界相对可比时，历史周期时间与吞吐量可以支持预测。使用区间或分位数，说明范围假设，并随新证据更新。由小修复得出的预测，对陌生的数据迁移支持有限。故事点可以帮助团队内部讨论，但不同团队的尺度并不统一，不应把它当成生产率排行榜。
2020 年《Scrum 指南》规定冲刺不超过一个月，并定义产品负责人、Scrum Master 和开发者的职责。看板可以在没有冲刺边界的情况下管理连续流动。两种方式都需要明确进入与完成条件、显式决定优先级，并为中断预留能力。测量时应说明前置时间和周期时间各从哪里开始，因为不同工具对这些术语的使用并不相同。
Scale 下的协调
团队增多时，需要梳理交付物之间的依赖，以及每个边界需要哪些决定。共享 API 需要负责人、兼容行为示例和迁移政策。平台团队可以通过提供易用能力减少重复工作；但如果每个普通修改都要等待其人工批准，它也可能成为队列。团队数量本身，不如团队之间的等待与协调修改情况有解释力。
Conway 的观察把沟通模式与系统结构联系起来（§7.6）。它提示我们检查团队能否通过稳定契约完成日常修改，而不是要求一个团队对应一个服务，也不能从组织图精确推导架构。在领域还不清楚时，临时协作可能很有用；之后稳定的服务接口可以减少这种需要。
应把交付作为整体衡量。DORA 当前的五项指标包括变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率。它们关注应用或服务的交付，而不是个人产出。还应结合用户结果与可靠性观察。仅仅改变部署拆分方式，可能改善计数，却没有改善产品。
团队还需要能够报告不受欢迎的信息。工程师能明确说迁移尚未准备好，组织才有机会调整。如果管理者要求估计不确定性，却惩罚每一次估计变化，就会鼓励隐瞒。明确归属、尊重地质疑和清楚的升级处理路径，使技术反馈机制真正可用。
学习这一部分会改变什么
你可以通过追踪一个工作项从请求到实际使用的全过程，检查过程是否有效。记录决策、实际工作、等待和反馈，往往就能看出，为什么增加一次会议或一个工具并没有解决真正的延迟。
对于小型项目，可以选择一个已观察到的障碍和一个改动，例如安排每天的审查时段，以减少长期等待的审查队列。同时测量等待时间和修改质量，注意范围与负载的变化，不要把所有改善都归因于这次干预。
实际能力在于选择下一步应该获得什么信息。需求示例、原型、测试和生产测量减少的是不同不确定性。有效的过程让团队能够获得这些信息，并在调整仍有价值时修改计划。
资源
书籍与文本
Brooks 描述大型项目的协调问题；Beck 的《Extreme Programming Explained》发展了一组相互支持的实践。《Continuous Delivery》追踪修改如何完成发布，《Team Topologies》分析团队边界。《Accelerate》的研究问题和历史发现有参考价值；已经变化的定义应对照后续 DORA 材料。这些书提供不同角度，不是所有项目都必须依次完成的阅读清单。
| 书籍 | 作用 | 类型 |
|---|---|---|
| Accelerate / DORA research（§7.4 参考） | Delivery performance 的经验基础 | 入门 |
| The DevOps Handbook（§7.4 参考） | DevOps 实践实现 | 实践 |
| Continuous Delivery（§7.4 参考） | Deployment pipeline 奠基文本 | 深入 |
| Beck, Extreme Programming Explained（第 2 版） | XP 奠基文本 | 深入 |
| Brooks, The Mythical Man-Month（anniversary ed.） | Software management 一手文本 | 深入 |
| Team Topologies | 面向交付的团队结构 | 深入 |
| Kim、Behr、Spafford，The Phoenix Project | 关于交付与运维协调的虚构案例 | 实践 |
| Anderson, Kanban: Successful Evolutionary Change | Kanban 方法论 | 深入 |
| Reinertsen, Principles of Product Development Flow | Flow-based development 理论 | 深入 |
| Winters, Manshreck & Wright, Software Engineering at Google（免费在线；纸质版付费） | 大规模工程实践 | 深入 |
课程、论文与当前资料
可以把 Royce 原文、敏捷宣言 和 Scrum 指南 与常见概括对照阅读。DORA 指标指南 定义交付测量，其研究模型 则展示部分建模假设。SPACE 与 DevEx 从生产率和开发体验角度补充观察。
| 资源 | 平台 | 类型 |
|---|---|---|
| DORA research program and State of DevOps reports（免费） | dora.dev | 参考 |
| Royce，〈Managing the Development of Large Software Systems〉（1970） | 原始论文；大学保存的扫描件 | 深入 |
| Agile Manifesto and principles（免费） | agilemanifesto.org | 参考 |
| SPACE framework（免费） | ACM Queue | 参考 |
| DevEx framework（免费） | ACM Queue | 参考 |
| Shape Up（免费在线；纸质版付费） | basecamp.com/shapeup | 辅助 |
| The Scrum Guide（免费） | scrumguides.org | 参考 |
实践、工具与当前资料
追踪一个实际工作项，包括等待、澄清、审查、测试和发布。引入新工具之前，先选择一个延迟调查。开始时使用简单记录或看板就足够。保持开始、完成和失败的定义足够稳定，使改进前后的比较有意义。
| 资源 | 平台 | 类型 |
|---|---|---|
| DORA DevOps Quick Check（免费） | dora.dev | 实践 |
| Value stream mapping exercise | Local | 实践 |
| Deployment frequency tracking | CI/CD system | 实践 |
| Trunk-Based Development（免费） | trunkbaseddevelopment.com | 实践 |
陷阱
| 误区 | 为什么会误导 | 更好的做法 |
|---|---|---|
| 采用仪式却没有反馈目的 | 会议可能只汇报进度，没有解决任何不确定性。 | 明确每项活动支持什么决定或调整。 |
| 把分支检查称为持续集成 | 各分支可以分别通过，最终组合却失败。 | 频繁合并，并检查组合结果。 |
| 把估计或故事点当成个人指标 | 压力可能改变报告方式和工单大小，却没有改善结果。 | 说明预测假设，评价有用交付与质量。 |
| 把调查关联当成普遍因果 | 背景、样本选择和混杂因素都可能影响观察结果。 | 用研究提出改进方案，再检查本地证据。 |
| 靠开始更多工作加快完成 | 瓶颈处可能只是积累更长的队列。 | 一起观察在制量、等待和完成量。 |