English
A software process is the set of activities, practices, and coordination mechanisms that a team uses to turn requirements into working software. Every software organization has a process, whether it is explicit or not: the sequence in which work happens, how requirements are communicated and refined, when code is integrated, how decisions are made, how progress is measured, how the team responds when something is not working. The question is not whether to have a process but whether the process is effective — whether it produces working software reliably, whether it surfaces problems early, whether it enables the team to respond to new information.
The field has a complicated relationship with process. Process improvement has periodically been captured by bureaucratic formalism — heavyweight methodologies that substitute ritual for judgment and compliance for competence — and the reaction against bureaucracy has periodically produced anti-process stances that conflate the failure of specific bad processes with the failure of process in general. The empirically grounded understanding is more nuanced: lightweight, iterative, feedback-driven processes that allow teams to adapt based on evidence consistently outperform heavyweight, sequential, plan-driven processes for the kinds of software most teams build. This is not a philosophical preference; it is the finding of the DORA (DevOps Research and Assessment) research program that has tracked software delivery performance across thousands of organizations for over a decade.
The practitioner who has studied software process can read a team’s practices and identify the mechanisms (or their absence) that determine whether the team can deliver software reliably and respond to change. They can distinguish practices that have empirical support from those that are ritual or fashion. They can evaluate proposals for process change against the evidence and against the specific context of their team. These are analytical capabilities that require study, not just experience — experience in a dysfunctional process produces expertise in dysfunction.
Prerequisites: Programming (§2.1) — process context is software development. Testing (§7.2) — many process practices address the relationship between development and verification. Architecture (§7.1) — system structure affects team coordination patterns.
From Sequential Plans to Continuous Delivery
The intellectual history of software process is, in large part, a history of discovering what does not work and why, and slowly developing alternatives.
The first systematic thinking about how to organize large software projects came from IBM’s experience in the 1950s and 1960s. Frederick Brooks’s The Mythical Man-Month (1975), distilling his experience leading the OS/360 project at IBM, established several empirical observations that remain correct: adding people to a late software project makes it later (Brooks’s Law), the second system is often the one that fails (the second-system effect), and conceptual integrity — coherent design from a unified vision — is the most important property of a software system. Brooks was not describing a methodology; he was describing the patterns he had observed in large-scale software failure.
Winston Royce’s 1970 paper “Managing the Development of Large Software Systems” is frequently cited as the origin of the “waterfall model” — a sequential process in which requirements are gathered completely, then design is completed, then implementation, then verification. This citation is an irony: Royce was arguing against the pure sequential model, noting that the pure version was “risky and invites failure” and proposing a modified version with iterative feedback between adjacent phases. The misreading of Royce’s paper produced a straw man that dominated government and defense software contracts for decades: a rigid sequential process that assumes requirements can be understood completely before any design begins, and that design can be completed before any coding begins. The assumptions are rarely valid; the process produces expensive failures when they are not.
The NATO Software Engineering conferences of 1968 and 1969 coined the term “software engineering” and articulated the “software crisis”: software projects were consistently delivered late, over budget, and failing to meet requirements. The conferences proposed that software development should be more like other engineering disciplines — rigorous, based on systematic methods, producing reliable results from reliable processes. The ambition was legitimate; the specific approaches it generated (formal specification methods, mathematical program verification) proved difficult to scale to the kinds of software most organizations were building.
The spiral model, proposed by Barry Boehm in 1986, was the most influential early response to the limitations of the waterfall model. The spiral identifies risk as the driver of project structure: each cycle of the spiral involves identifying and mitigating the most significant risks before committing to the next increment of development. The spiral model gave explicit attention to risk management and recognized that requirements evolve — both insights that the waterfall model had obscured. It was, however, still a heavyweight model that required significant planning overhead and was primarily applicable to large contractual development.
The empirical foundation for iterative, incremental development came from the Standish Group’s CHAOS Report (1994, and subsequent editions), which surveyed IT project outcomes and found that the majority of software projects were “challenged” (late, over budget, or missing features) or “failed” (cancelled before delivery). Smaller projects had dramatically better success rates than larger ones, which pointed toward iteration: if smaller scopes succeed more often, delivering small increments rather than large releases should produce better outcomes. This empirical observation was one of several inputs that converged in the Agile Manifesto.
The Agile Manifesto (2001), signed by seventeen practitioners including Kent Beck, Martin Fowler, and Jim Highsmith, articulated four values and twelve principles that responded to the accumulated failures of heavyweight, sequential methodologies. The values — individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan — were deliberately counterpoints to the dominant bureaucratic practices. The manifesto was not a methodology; it was a statement of values from which methodologies should be derived. The methodologies that emerged — Scrum, Extreme Programming, and later Kanban and SAFe — varied significantly in their specific practices while sharing the iterative, feedback-driven orientation.
Scrum, developed by Ken Schwaber and Jeff Sutherland, provided the most widely adopted specific methodology. Its core structure — short iterations (sprints, typically two weeks), daily standups, sprint reviews with stakeholders, and sprint retrospectives — created a regular cadence of feedback and adjustment. The roles (Product Owner, Scrum Master, Development Team), artifacts (Product Backlog, Sprint Backlog, Increment), and ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) provided a complete operational framework. Scrum’s widespread adoption created a large population of practitioners who could name its ceremonies but not necessarily explain their purpose; Scrum certification became an industry, and “doing Scrum” was often theater rather than substance.
Extreme Programming (XP), developed by Kent Beck, was more radical and more technically specific than Scrum. Its practices — test-driven development, pair programming, continuous integration, small releases, collective code ownership, simple design, refactoring, customer on-site — formed a coherent technical methodology in which the practices reinforced each other. XP was more demanding than Scrum (it required specific technical practices, not just process rituals) and consequently less widely adopted in its pure form. Many of its specific technical practices — TDD, continuous integration, refactoring — have been adopted broadly independent of the full XP methodology.
The DORA research program, founded by Nicole Forsgren, Jez Humble, and Gene Kim and later acquired by Google, provided the most rigorous empirical foundation for software delivery practices. Their research, published in Accelerate (2018) and in annual State of DevOps reports, identified four key metrics of software delivery performance: deployment frequency, lead time for changes, time to restore service, and change failure rate. Elite performers deployed multiple times per day with low change failure rates and rapid recovery; low performers deployed monthly or less with high change failure rates. The research also identified the technical practices that predicted elite performance: trunk-based development, continuous integration with automated testing, continuous delivery, loose coupling of architecture, monitoring and observability. The evidence was causal rather than merely correlational, established through structural equation modeling across thousands of organizations.
Continuous delivery, formalized by Jez Humble and David Farley in Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010), is the practice of keeping software in a releasable state at all times and being able to deploy to production on demand. It requires a deployment pipeline — an automated sequence of build, test, and deployment stages that every code change passes through — and the organizational discipline to keep that pipeline working. CD is not primarily a technical practice; it requires the organizational commitment to prioritize pipeline health over feature delivery, to invest in test automation that makes fast verification of the full system possible, and to treat deployment as a routine event rather than a special one.
Process Structure, Feedback Loops, and Organizational Context
The Fundamental Structure of Effective Processes
Effective software processes share several structural properties, regardless of their specific methodology. Each of these properties has empirical support from the DORA research and from decades of practice observation.
Small batch sizes reduce the time between doing work and discovering whether the work was correct. A team that integrates code once per sprint discovers integration problems once per sprint; a team that integrates multiple times per day discovers them within hours. The same principle applies to feature development: a team that delivers features in small increments gets feedback from users much faster than a team that delivers large releases. Small batches reduce work in progress, which reduces the time each item spends in the system (Little’s Law: average time in system = work in progress / throughput), which reduces feedback latency.
Continuous integration — the practice of merging all working branches to the main trunk multiple times per day, with an automated test suite that runs on each integration — eliminates the long-lived feature branches that produce integration disasters when they are eventually merged. Trunk-based development (the DORA-recommended practice) or short-lived feature branches (no more than a day or two) prevent the accumulation of integration debt. A team that integrates daily can diagnose conflicts between team members’ work within hours; a team that integrates after weeks of parallel development faces the “integration hell” that has delayed software projects since the discipline began.
Deployment automation removes the variability and cognitive overhead of manual deployment. Every manual step in a deployment process is a potential source of error; a process that is automated runs identically every time. The effort to automate deployment is repaid through the ability to deploy frequently and confidently, which enables the small batch sizes that make everything else work.
Feedback from production — through monitoring, observability, error tracking, and user behavior analytics — closes the loop between what the team built and whether it is working correctly for real users. A team that cannot see how its software performs in production is flying blind; problems that would be caught quickly by someone watching the metrics go undetected until users complain loudly enough to generate a support ticket. The DORA research identifies monitoring and observability as one of the technical practices most strongly predictive of software delivery performance.
Planning, Backlog Management, and Estimation
Work item management — keeping track of what needs to be done, in what order, and what is in progress — is a process concern that intersects with product strategy. The product backlog (in Scrum terminology) or the work queue (in Kanban) is a prioritized list of work items. Effective backlog management requires a few specific things: items at the top of the backlog should be small enough to complete in a day or two, well-defined enough that a developer can begin them without extensive clarification, and prioritized by value rather than by request sequence.
Estimation is the most controversial process activity, with empirical evidence that cuts against common practice. Teams routinely overestimate their ability to predict the duration of software work; estimation errors compound and plans become fictions. The strongest evidence-based practices for managing this uncertainty are: use historical throughput (how many items does the team typically complete per week?) rather than point estimates for planning, focus on making items small and consistent in size rather than estimating their duration, and treat estimates as probability distributions rather than commitments. The #NoEstimates movement (Vasco Duarte and others) argues for eliminating estimates entirely in favor of throughput-based forecasting; the more moderate position is that estimates should be rough and treated as ranges, never as commitments.
Kanban, developed from Toyota’s manufacturing system and adapted to software by David Anderson, provides an alternative to sprint-based delivery. Rather than time-boxing work into sprints, Kanban limits work in progress (WIP) at each stage of the workflow and optimizes for flow: items move through the system as quickly as possible, with WIP limits preventing overloading at any stage. Kanban’s metrics — lead time (time from commitment to delivery), cycle time (time from starting an item to delivering it), throughput (items delivered per week) — are more directly predictive of delivery performance than story points or velocity.
Coordination at Scale
Conway’s Law — that organizations design systems that mirror their communication structure — is one of the most empirically robust observations in software engineering. A team organized as frontend, backend, and database will produce a system with three tiers; a company organized as separate product teams will produce loosely coupled products. This is not a statement about what teams choose to do; it is an observation about the structural forces that shape what teams produce.
The inverse Conway maneuver — designing the team structure to produce the desired system architecture — requires treating team structure as a deliberate architectural decision. If the desired architecture is loosely coupled microservices, the team structure should be organized around those services, with teams that own complete services rather than technology tiers. Team Topologies (Matthew Skelton and Manuel Pais, 2019) provides the most systematic framework for aligning team structure with system architecture and delivery mode, with four team types (stream-aligned, enabling, complicated subsystem, platform) and three interaction modes (collaboration, X-as-a-Service, facilitating).
Psychological safety — the belief that the team is safe to speak up, surface problems, and take interpersonal risks without punishment — was identified by Google’s Project Aristotle (2016) as the single most important factor in team effectiveness. Teams with high psychological safety surface problems earlier, learn faster from failures, and collaborate more effectively than teams where members feel punished for honesty. This is not a soft observation; it has direct productivity consequences. Processes that create blame, that punish people for surfacing problems, or that reward the appearance of good news over the reality of problems systematically undermine the safety that effective teams require.
What Studying This Changes
Software process changes how practitioners understand organizational behavior and how they evaluate process practices.
The first change is the ability to identify feedback latency as the primary diagnostic variable. Most software process problems are fundamentally problems of delayed feedback: requirements misunderstood for months before the software is shown to stakeholders, bugs introduced and not discovered until the integration happens, performance problems not noticed until production load hits. The practitioner who has internalized feedback latency as the key variable can identify where feedback loops are long and what changes would make them shorter.
The second change is evidence-based evaluation of process practices. Many process practices are ritual without evidence of effectiveness. The DORA research provides empirical baselines against which practices can be evaluated: does this practice correlate with higher deployment frequency? lower change failure rate? faster recovery from incidents? The practitioner who knows the evidence can distinguish practices with empirical support from those that are industry fashion.
The third change is understanding process as a system rather than a set of independent practices. TDD, continuous integration, deployment automation, and small batch sizes reinforce each other: TDD makes continuous integration valuable (there is something to verify); continuous integration makes TDD practices visible; deployment automation makes continuous integration produce releasable software; small batch sizes make deployment automation used frequently enough to stay working. Adopting practices in isolation produces less improvement than adopting the interconnected system.
The fourth change is recognizing that process problems are often organizational and human problems rather than technical ones. A deployment pipeline that nobody trusts (because it produces false positives) will be bypassed. A sprint planning process that produces overloaded sprints (because the team cannot say no to scope) will produce burnout and low quality. A retrospective process that surfaces problems but produces no changes will produce cynicism. Technical process changes require organizational support to be effective; understanding this prevents the common failure of introducing new practices that fail because the organizational conditions do not support them.
Resources
Books and Texts
Forsgren, Humble, and Kim’s Accelerate: The Science of Lean Software and DevOps (IT Revolution Press, 2018) is the essential text for evidence-based software process. Its findings — on the four key metrics, on the technical practices that predict elite performance, on the relationship between software delivery performance and organizational outcomes — are the empirical foundation that any serious discussion of process must engage with. Short and direct; the most important book in this section.
Kim, Humble, Debois, and Willis’s The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Your Technology Organization (IT Revolution Press, 2nd ed., 2021) provides the practical implementation of the practices that Accelerate identifies as effective. The three ways of DevOps — flow (fast delivery), feedback (monitoring and learning), and continual learning — organize the book’s content.
Humble and Farley’s Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley, 2010) is the foundational text on deployment pipelines and continuous delivery practices. It covers the structure of a deployment pipeline, the test automation that makes it possible, and the organizational changes that making CD a reality requires.
Beck’s Extreme Programming Explained: Embrace Change (2nd ed., Addison-Wesley, 2004) is the foundational XP text. Its description of the XP practices and their interactions — why TDD and pair programming and continuous integration and simple design work together better than any of them alone — remains compelling.
Brooks’s The Mythical Man-Month (anniversary ed., Addison-Wesley, 1995) is the most important primary text on the difficulty of software management. The essay “No Silver Bullet: Essence and Accident in Software Engineering” (added to the anniversary edition) is the most important single essay in software engineering on why there is no process or technique that eliminates the inherent difficulty of software development.
Skelton and Pais’s Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution Press, 2019) provides the most systematic contemporary treatment of how team structure affects software delivery. The four team types and three interaction modes give vocabulary for designing organizational structure around delivery effectiveness.
| 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, The Phoenix Project | Novel-format DevOps entry | 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
The annual State of DevOps reports (free, dora.dev) provide the ongoing DORA research findings. Reading reports from multiple years together reveals which practices have sustained correlation with performance and how the frontier has shifted.
Royce’s original 1970 paper “Managing the Development of Large Software Systems” (free, IEEE) is worth reading specifically to see that the paper critiques the sequential model rather than advocating for it — and to understand how misreadings of technical papers propagate.
The Agile Manifesto (agilemanifesto.org, free) and the associated twelve principles are the primary sources for agile values. Reading the principles together with the practices that have emerged from them reveals which practices faithfully implement the principles and which have drifted from them.
| Resource | Platform | Type |
|---|---|---|
| DORA research program and State of DevOps reports (free) | dora.dev | Reference |
| Royce 1970 “Managing the Development…” (free) | IEEE | 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
DORA’s DevOps Quick Check (dora.dev, free) is a validated survey instrument for measuring a team’s delivery performance against the four key metrics. Running the survey for a team and comparing to the benchmarks provides a baseline for understanding current performance and identifying improvement priorities.
Value stream mapping — drawing the sequence of activities from code commit to production deployment, with the time each activity takes and the wait time between activities — is the most effective diagnostic tool for identifying process bottlenecks. The cumulative wait times typically dwarf the cumulative work times, revealing where process improvements would have the most impact.
Deployment frequency tracking — a simple count of how many times per week or month the team deploys to production — is the single metric most predictive of overall software delivery performance. Teams that track this (and can see it is trending in the right direction) have the most basic feedback loop on process health.
| 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 practice |
|---|---|---|
| Scrum theater | “Doing Scrum” without understanding the purpose of its practices produces rituals without substance: daily standups that are status reports rather than coordination, sprints that end without working software, retrospectives that produce no changes. Scrum’s ceremonies are designed to create specific feedback loops; adopted as rituals without understanding, they create overhead without value. | For each Scrum ceremony, articulate its purpose and assess whether it is achieving that purpose. The daily standup is for identifying blockers and coordinating, not for reporting status. The retrospective is for identifying and implementing process improvements, not for venting. If a ceremony is not achieving its purpose, change it. |
| Mistaking process adoption for process improvement | Adopting agile methodologies, OKRs, or any other process framework does not automatically improve outcomes. What matters is whether the specific changes improve the feedback loops, reduce batch sizes, or increase deployment automation — the mechanisms that the DORA research shows drive performance. | Measure before and after. Use the four DORA metrics as the baseline. Track whether process changes produce measurable improvements in deployment frequency, change failure rate, lead time, or recovery time. If they do not, the change is not working, regardless of how orthodox the methodology. |
| Sprint commitments as predictions | “We committed to delivering these stories in this sprint” treats sprint planning as a contract rather than a forecast. When sprints consistently fail to deliver what was planned, the team is either overcommitting, underestimating, or facing scope changes — all of which require diagnosis and response, not just more commitment. | Treat sprint plans as forecasts of what is most likely to be completed, not as promises. Track throughput (items completed per sprint) rather than velocity (points planned vs. delivered). Use historical throughput to forecast how much work will be completed in a given time period, and present forecasts as probability distributions (80% likely to complete X, 50% likely to complete Y). |
| Process as substitute for technical practices | Organizations sometimes believe that adopting an agile process framework will fix delivery problems caused by poor code quality, insufficient test automation, or manual deployment processes. Process cannot compensate for technical debt, slow builds, or unreliable test suites. | The DORA research is clear: technical practices (continuous integration, automated testing, deployment automation, trunk-based development) predict delivery performance more strongly than process practices alone. Address technical foundations — fast automated tests, automated deployment, clean code — alongside process changes. |
| Ignoring Conway’s Law in process design | A team that is organized as frontend/backend/database will naturally build a three-tier architecture, even if the intended architecture is microservices. A team where multiple engineers own the same service will produce a different architecture than a team where one engineer owns each service. Process design that ignores organizational structure will produce systems that reflect the existing structure regardless of what the architecture diagram says. | Explicitly consider Conway’s Law when designing both the system architecture and the team structure. Use the inverse Conway maneuver — design teams around the desired system architecture — and use Team Topologies as the framework for this design. Treat team structure as a deliberate architectural decision with long-term consequences. |
中文
软件过程是一个团队用来把需求转化为可运行软件的一组活动、实践和协调机制。每个软件组织都有过程，无论它是否被显式说明：工作以什么顺序发生，需求如何被沟通和细化，代码何时被集成，决策如何做出，进度如何衡量，当某件事不起作用时团队如何回应。问题不是要不要有过程，而是这个过程是否有效——它是否能可靠地产出可运行软件，是否能尽早暴露问题，是否能让团队根据新信息做出回应。
这个领域与“过程”的关系很复杂。过程改进周期性地被 bureaucratic formalism 捕获——重量级方法论用仪式替代判断，用合规替代能力；而对官僚化的反应，又周期性地产生反过程立场，把某些糟糕过程的失败误认为过程本身的失败。基于经验研究的理解更细致：对于大多数团队构建的软件，轻量、迭代、feedback-driven，并允许团队根据证据调整的过程，持续优于重量级、顺序式、plan-driven 的过程。这不是哲学偏好；这是 DORA（DevOps Research and Assessment）研究项目的发现，该项目十多年来追踪了数千个组织的软件交付表现。
学习过软件过程的实践者，可以阅读一个团队的实践，并识别出决定该团队能否可靠交付软件、能否回应变化的机制，以及这些机制是否缺失。他们能区分哪些实践有经验证据支持，哪些只是仪式或流行。他们能根据证据和团队具体语境，评估过程变更提案。这些是需要学习才能获得的分析能力，而不只是经验——在功能失调的过程中积累经验，只会产生对功能失调的熟练。
前置知识：编程（§2.1）——过程的语境是软件开发。测试（§7.2）——许多过程实践处理开发与验证之间的关系。架构（§7.1）——系统结构会影响团队协调模式。
从顺序计划到 Continuous Delivery
软件过程的智识史，在很大程度上是一段发现什么不起作用、为什么不起作用，并逐渐发展替代方案的历史。
关于如何组织大型软件项目的第一批系统性思考，来自 IBM 在 1950 年代和 1960 年代的经验。Frederick Brooks 的 The Mythical Man-Month（1975）总结了他在 IBM 领导 OS/360 项目的经验，并确立了若干至今仍正确的经验观察：给一个已经延期的软件项目增加人手，会让它更晚（Brooks’s Law）；第二个系统往往是失败的系统（second-system effect）；conceptual integrity——来自统一愿景的连贯设计——是软件系统最重要的性质。Brooks 不是在描述一种方法论；他是在描述自己在大规模软件失败中观察到的模式。
Winston Royce 1970 年的论文 “Managing the Development of Large Software Systems” 经常被引用为 “waterfall model” 的源头——一种顺序过程：先完整收集 requirements，然后完成 design，然后 implementation，最后 verification。这种引用具有讽刺意味：Royce 实际上是在反对纯顺序模型，他指出纯版本 “risky and invites failure”，并提出了一种在相邻阶段之间带有 iterative feedback 的修正版。对 Royce 论文的误读，制造了一个支配政府和国防软件合同数十年的稻草人：一种僵硬的顺序过程，假定 requirements 可以在任何 design 开始前被完全理解，design 可以在任何 coding 开始前被完成。这些假设很少成立；一旦不成立，该过程就会制造昂贵失败。
1968 和 1969 年的 NATO Software Engineering conferences 创造了 “software engineering” 这个术语，并阐明了 “software crisis”：软件项目持续延期、超预算，并无法满足 requirements。会议提出，软件开发应当更像其他工程学科——严谨、基于系统方法，并从可靠过程中产生可靠结果。这个抱负是合理的；但它产生的具体方法（formal specification methods、mathematical program verification）被证明很难扩展到多数组织正在构建的软件类型上。
Barry Boehm 于 1986 年提出的 spiral model，是对 waterfall model 限制的早期最有影响力回应。Spiral model 把 risk 识别为项目结构的驱动因素：螺旋的每一圈都包含识别并缓解最重要风险，然后再承诺进入下一个开发增量。Spiral model 显式关注 risk management，并承认 requirements 会演化——这两个洞见都被 waterfall model 遮蔽了。不过，它仍然是重量级模型，需要显著 planning overhead，且主要适用于大型合同式开发。
迭代、增量开发的经验基础，来自 Standish Group 的 CHAOS Report（1994 及后续版本）。它调查 IT project outcomes，并发现多数软件项目要么是 “challenged”（延期、超预算或缺少功能），要么是 “failed”（交付前被取消）。小型项目的成功率明显高于大型项目，这指向 iteration：如果更小 scope 更常成功，那么交付小增量而不是大版本，应该能产生更好结果。这个经验观察是汇聚到 Agile Manifesto 的若干输入之一。
Agile Manifesto（2001）由包括 Kent Beck、Martin Fowler 和 Jim Highsmith 在内的十七位实践者签署，它提出四项 values 和十二条 principles，回应了重量级、顺序式方法论长期积累的失败。那些 values——individuals and interactions over processes and tools；working software over comprehensive documentation；customer collaboration over contract negotiation；responding to change over following a plan——有意成为当时主导性官僚实践的对照。Manifesto 不是方法论；它是一组价值声明，方法论应从中派生。后续出现的方法论——Scrum、Extreme Programming，以及后来的 Kanban 和 SAFe——在具体实践上差异很大，但共享迭代、feedback-driven 的取向。
Scrum 由 Ken Schwaber 和 Jeff Sutherland 发展，是最广泛采用的具体方法论。它的核心结构——短迭代（sprints，通常两周）、daily standups、与 stakeholders 的 sprint reviews，以及 sprint retrospectives——创造了固定的反馈和调整节奏。Roles（Product Owner、Scrum Master、Development Team）、artifacts（Product Backlog、Sprint Backlog、Increment）和 ceremonies（Sprint Planning、Daily Scrum、Sprint Review、Sprint Retrospective）提供了完整 operational framework。Scrum 的广泛采用，创造了一大批能说出其 ceremonies 名字、但未必能解释其目的的实践者；Scrum certification 成为产业，而 “doing Scrum” 往往变成 theater，而不是 substance。
Extreme Programming（XP）由 Kent Beck 发展，比 Scrum 更激进，也在技术上更具体。其实践——test-driven development、pair programming、continuous integration、small releases、collective code ownership、simple design、refactoring、customer on-site——构成一种连贯技术方法论，其中每项实践会相互强化。XP 比 Scrum 要求更高（它要求具体技术实践，而不只是过程仪式），因此纯粹形式采用较少。它的许多具体技术实践——TDD、continuous integration、refactoring——已经脱离完整 XP 方法论而被广泛采用。
DORA research program 由 Nicole Forsgren、Jez Humble 和 Gene Kim 创立，后来被 Google 收购，它为软件交付实践提供了最严谨的经验基础。他们的研究发表在 Accelerate（2018）以及年度 State of DevOps reports 中，识别出软件交付表现的四个关键 metrics：deployment frequency、lead time for changes、time to restore service 和 change failure rate。Elite performers 每天部署多次，同时 change failure rates 低、恢复迅速；low performers 每月或更少部署一次，同时 change failure rates 高。研究还识别出预测 elite performance 的技术实践：trunk-based development、带 automated testing 的 continuous integration、continuous delivery、loosely coupled architecture、monitoring and observability。其证据不是单纯相关性，而是通过跨数千个组织的 structural equation modeling 建立出的因果证据。
Continuous delivery 由 Jez Humble 和 David Farley 在 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation（2010）中形式化，它指的是让软件始终保持可发布状态，并能按需部署到生产。它需要 deployment pipeline——每次 code change 都会经过的一系列自动化 build、test 和 deployment stages——也需要保持 pipeline 正常运行的组织纪律。CD 不是单纯技术实践；它要求组织承诺将 pipeline health 置于 feature delivery 之上，投资 test automation 以实现对完整系统的快速验证，并把 deployment 视为常规事件，而不是特殊事件。
Process Structure、Feedback Loops 与 Organizational Context
有效过程的基本结构
有效的软件过程具有若干结构性性质，无论其具体方法论是什么。这些性质都受到 DORA research 和数十年实践观察的经验支持。
Small batch sizes 会缩短完成工作与发现工作是否正确之间的时间。一个每个 sprint 集成一次代码的团队，每个 sprint 才发现一次 integration problems；一个每天集成多次的团队，则在数小时内发现它们。同样原则也适用于功能开发：以小增量交付 features 的团队，比交付大版本的团队更快从 users 那里获得反馈。Small batches 会减少 work in progress，而根据 Little’s Law（average time in system = work in progress / throughput），这会减少每个 item 在系统中停留的时间，从而降低 feedback latency。
Continuous integration——每天多次把所有工作分支 merge 到 main trunk，并在每次 integration 上运行 automated test suite——消除了 long-lived feature branches，因为后者最终 merge 时会制造 integration disasters。Trunk-based development（DORA 推荐实践）或 short-lived feature branches（不超过一两天）可以防止 integration debt 积累。一个每天 integration 的团队，可以在数小时内诊断团队成员工作之间的冲突；一个在数周并行开发后才 integration 的团队，则会遇到自软件学科开始以来就不断拖延项目的 “integration hell”。
Deployment automation 消除了 manual deployment 的变异性和 cognitive overhead。Deployment process 中的每一个 manual step 都是潜在错误来源；自动化 process 每次运行都相同。投入自动化部署的成本，会通过能够频繁且有信心地部署而收回，而这种能力正是让 small batch sizes 发挥作用的前提。
来自 production 的反馈——通过 monitoring、observability、error tracking 和 user behavior analytics——闭合了团队所构建内容与其是否为真实用户正确工作之间的循环。一个看不到软件在 production 中如何表现的团队，是在盲飞；那些本可以被观察 metrics 的人快速发现的问题，会一直不被发现，直到 users 大声抱怨到生成 support ticket。DORA research 把 monitoring and observability 识别为最强预测软件交付表现的技术实践之一。
Planning、Backlog Management 与 Estimation
Work item management——跟踪需要做什么、按什么顺序做、什么正在进行中——是一种与 product strategy 交叉的过程关切。Product backlog（Scrum 术语）或 work queue（Kanban）是 work items 的优先级列表。有效的 backlog management 需要几个具体条件：backlog 顶部的 items 应足够小，能在一两天内完成；定义足够清楚，使 developer 不需要大量澄清就能开始；并且按 value 而不是 request sequence 排优先级。
Estimation 是最有争议的过程活动，其经验证据与常见实践相抵触。团队经常高估自己预测软件工作时长的能力；estimation errors 会复合，plans 会变成虚构。管理这种不确定性的最强 evidence-based practices 是：用 historical throughput（团队通常每周完成多少 items？）而不是 point estimates 做 planning；把重点放在让 items 足够小且大小一致，而不是估计它们的 duration；并把 estimates 当作 probability distributions，而不是 commitments。#NoEstimates movement（Vasco Duarte 等人）主张完全取消 estimates，改用 throughput-based forecasting；更温和立场则是 estimates 应粗略，并被视为 ranges，绝不能被视为 commitments。
Kanban 来自 Toyota’s manufacturing system，并由 David Anderson 改造到软件中，它提供了 sprint-based delivery 的替代方案。Kanban 不是把工作 time-box 到 sprints 中，而是在 workflow 每个阶段限制 work in progress（WIP），并优化 flow：items 尽快通过系统，WIP limits 则防止任何阶段过载。Kanban 的 metrics——lead time（从承诺到交付的时间）、cycle time（从开始处理一个 item 到交付它的时间）、throughput（每周交付 items 数量）——比 story points 或 velocity 更能直接预测交付表现。
Scale 下的协调
Conway’s Law——组织会设计出镜像其 communication structure 的系统——是软件工程中经验上最稳固的观察之一。一个被组织为 frontend、backend 和 database 的团队，会产生一个三层系统；一个被组织为独立 product teams 的公司，会产生 loosely coupled products。这不是在说团队选择做什么，而是在观察塑造团队产出的结构性力量。
Inverse Conway maneuver——设计团队结构以产生期望系统架构——要求把团队结构视为有意识的架构决策。如果期望架构是 loosely coupled microservices，团队结构就应围绕这些 services 组织，团队应拥有完整 services，而不是技术分层。Team Topologies（Matthew Skelton 和 Manuel Pais，2019）提供了将团队结构与系统架构和交付模式对齐的最系统框架，其中包含四种 team types（stream-aligned、enabling、complicated subsystem、platform）和三种 interaction modes（collaboration、X-as-a-Service、facilitating）。
Psychological safety——团队成员相信自己可以发声、暴露问题，并承担 interpersonal risks 而不受惩罚——被 Google 的 Project Aristotle（2016）识别为 team effectiveness 中最重要的单一因素。Psychological safety 高的团队，比成员因诚实而感到会受惩罚的团队更早暴露问题、更快从失败中学习，也更有效协作。这不是“软性”观察；它有直接生产力后果。那些制造 blame、惩罚暴露问题的人，或奖励好消息表象而不是问题真实情况的 processes，会系统性破坏有效团队所需的安全感。
学习这一部分会改变什么
软件过程会改变实践者理解组织行为，以及评估过程实践的方式。
第一个变化，是能够把 feedback latency 识别为主要诊断变量。多数软件过程问题，本质上都是延迟反馈问题：requirements 被误解了几个月，直到软件展示给 stakeholders 才发现；bugs 被引入后，直到 integration 才被发现；performance problems 直到 production load 出现才被注意到。把 feedback latency 内化为关键变量的实践者，能够识别 feedback loops 在哪里过长，以及哪些变化会让它们变短。
第二个变化，是基于证据评估过程实践。许多过程实践只是没有有效性证据的仪式。DORA research 提供了经验基线，可以用来评估实践：这个实践是否与更高 deployment frequency 相关？是否与更低 change failure rate 相关？是否与更快 incident recovery 相关？了解证据的实践者，可以区分有经验支持的实践和行业流行。
第三个变化，是把过程理解为一个系统，而不是一组彼此独立的 practices。TDD、continuous integration、deployment automation 和 small batch sizes 会相互强化：TDD 使 continuous integration 有价值（因为有东西可验证）；continuous integration 使 TDD practices 可见；deployment automation 使 continuous integration 产生可发布软件；small batch sizes 使 deployment automation 被足够频繁使用，从而保持可工作。孤立采用 practices，比采用相互连接的系统带来更少改进。
第四个变化，是认识到过程问题往往是组织问题和人的问题，而不只是技术问题。一个没人信任的 deployment pipeline（因为它产生 false positives）会被绕过。一个制造 overloaded sprints 的 sprint planning process（因为团队不能对 scope 说不）会产生 burnout 和低质量。一个能暴露问题、却不会带来任何变化的 retrospective process 会制造 cynicism。技术过程变更需要组织支持才能有效；理解这一点，可以防止常见失败：引入新实践，却因为组织条件不支持而失败。
资源
书籍与文本
Forsgren、Humble 和 Kim 的 Accelerate: The Science of Lean Software and DevOps（IT Revolution Press，2018）是 evidence-based software process 的必要文本。其发现——关于四个 key metrics、预测 elite performance 的技术实践、software delivery performance 与 organizational outcomes 之间的关系——是任何严肃过程讨论都必须面对的经验基础。篇幅短、表达直接；它是本节最重要的书。
Kim、Humble、Debois 和 Willis 的 The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Your Technology Organization（IT Revolution Press，第 2 版，2021）提供 Accelerate 所识别有效实践的实际实现。DevOps 的 three ways——flow（快速交付）、feedback（monitoring and learning）和 continual learning——组织了全书内容。
Humble 和 Farley 的 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation（Addison-Wesley，2010）是关于 deployment pipelines 和 continuous delivery practices 的奠基文本。它覆盖 deployment pipeline 的结构，使其成为可能的 test automation，以及让 CD 成为现实所要求的组织变化。
Beck 的 Extreme Programming Explained: Embrace Change（第 2 版，Addison-Wesley，2004）是 XP 的奠基文本。它对 XP practices 及其互动的描述——为什么 TDD、pair programming、continuous integration 和 simple design 一起工作时，比任何单项实践单独使用都更有效——至今仍有说服力。
Brooks 的 The Mythical Man-Month（anniversary ed.，Addison-Wesley，1995）是关于 software management 困难的最重要一手文本。收录在 anniversary edition 中的文章 “No Silver Bullet: Essence and Accident in Software Engineering”，是软件工程中关于为什么没有任何 process 或 technique 能消除软件开发固有困难的最重要单篇文章。
Skelton 和 Pais 的 Team Topologies: Organizing Business and Technology Teams for Fast Flow（IT Revolution Press，2019）提供了关于 team structure 如何影响 software delivery 的当代最系统处理。四种 team types 和三种 interaction modes，提供了围绕 delivery effectiveness 设计组织结构的词汇。
| 书籍 | 作用 | 类型 |
|---|---|---|
| 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, The Phoenix Project | 小说形式 DevOps 入口 | 实践 |
| Anderson, Kanban: Successful Evolutionary Change | Kanban 方法论 | 深入 |
| Reinertsen, Principles of Product Development Flow | Flow-based development 理论 | 深入 |
| Winters, Manshreck & Wright, Software Engineering at Google（免费在线；纸质版付费） | 大规模工程实践 | 深入 |
课程、论文与当前资料
annual State of DevOps reports（免费，dora.dev）提供持续的 DORA research findings。连续阅读多年的 reports，可以看出哪些 practices 与 performance 的相关性持续存在，以及前沿如何变化。
Royce 的原始 1970 paper “Managing the Development of Large Software Systems”（免费，IEEE）值得阅读，特别是为了看到这篇论文批评的是顺序模型，而不是倡导它——同时也能理解技术论文的误读如何传播。
Agile Manifesto（agilemanifesto.org，免费）及其十二条原则，是 agile values 的一手来源。把这些原则与后来从中发展出的 practices 一起阅读，可以看出哪些 practices 忠实实现了原则，哪些已经偏离。
| 资源 | 平台 | 类型 |
|---|---|---|
| DORA research program and State of DevOps reports（免费） | dora.dev | 参考 |
| Royce 1970 “Managing the Development…” （免费） | IEEE | 深入 |
| 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’s DevOps Quick Check（dora.dev，免费）是经过验证的 survey instrument，可用于根据四个 key metrics 衡量团队交付表现。让团队完成该 survey，并与 benchmarks 比较，可以建立理解当前表现和识别改进优先级的 baseline。
Value stream mapping——画出从 code commit 到 production deployment 的活动序列，以及每项活动耗时和活动之间等待时间——是识别过程瓶颈最有效的诊断工具。累计等待时间通常远大于累计工作时间，从而揭示过程改进在哪里最有影响。
Deployment frequency tracking——简单计算团队每周或每月部署到 production 的次数——是最能预测 overall software delivery performance 的单一 metric。跟踪这个指标，并能看到它朝正确方向变化的团队，拥有关于 process health 的最基本 feedback loop。
| 资源 | 平台 | 类型 |
|---|---|---|
| DORA DevOps Quick Check（免费） | dora.dev | 实践 |
| Value stream mapping exercise | Local | 实践 |
| Deployment frequency tracking | CI/CD system | 实践 |
| Trunk-Based Development（免费） | trunkbaseddevelopment.com | 实践 |
陷阱
| 陷阱 | 为什么会误导 | 更好的实践 |
|---|---|---|
| Scrum theater | “Doing Scrum” 但不理解其实践目的，会产生没有实质的 rituals：daily standups 变成 status reports 而不是 coordination，sprints 结束时没有 working software，retrospectives 不产生任何改变。Scrum 的 ceremonies 是为了创造具体 feedback loops；如果被当作不理解目的的 rituals 采用，它们只会制造 overhead 而没有价值。 | 对每个 Scrum ceremony，明确说明其目的，并评估它是否实现了目的。Daily standup 是为了识别 blockers 和协调，而不是汇报状态。Retrospective 是为了识别并实施 process improvements，而不是发泄。如果某个 ceremony 没有实现目的，就改变它。 |
| 把 process adoption 误认为 process improvement | 采用 agile methodologies、OKRs 或任何其他 process framework，并不会自动改善 outcomes。真正重要的是具体变化是否改善 feedback loops、减少 batch sizes，或增加 deployment automation——这些才是 DORA research 证明会驱动 performance 的机制。 | 在前后进行测量。把四个 DORA metrics 作为 baseline。追踪 process changes 是否在 deployment frequency、change failure rate、lead time 或 recovery time 上产生可测量改进。如果没有，那么无论方法论多正统，这项改变都没有起作用。 |
| 把 sprint commitments 当成 predictions | “我们承诺在这个 sprint 交付这些 stories” 会把 sprint planning 当成 contract，而不是 forecast。当 sprints 持续无法交付计划内容时，团队要么 overcommitting，要么 underestimating，要么面临 scope changes——这些都需要诊断和回应，而不是更多 commitment。 | 把 sprint plans 当作最可能完成内容的 forecasts，而不是 promises。追踪 throughput（每个 sprint 完成的 items）而不是 velocity（planned points vs. delivered points）。使用 historical throughput 预测给定时间段内能完成多少工作，并把 forecasts 表达为 probability distributions（80% 可能完成 X，50% 可能完成 Y）。 |
| 用 process 替代 technical practices | 组织有时相信，采用 agile process framework 就能修复由糟糕 code quality、不足 test automation 或 manual deployment processes 引起的交付问题。Process 无法弥补 technical debt、slow builds 或 unreliable test suites。 | DORA research 很清楚：technical practices（continuous integration、automated testing、deployment automation、trunk-based development）比单独的 process practices 更强地预测 delivery performance。把技术基础——fast automated tests、automated deployment、clean code——与 process changes 一起处理。 |
| 在 process design 中忽视 Conway’s Law | 一个被组织为 frontend/backend/database 的团队，会自然构建三层架构，即使目标架构是 microservices。一个由多个工程师共同拥有同一 service 的团队，会产生不同于每个工程师各自拥有一个 service 的架构。忽视组织结构的 process design，会让系统反映既有结构，而不管 architecture diagram 怎么写。 | 在设计 system architecture 和 team structure 时，都显式考虑 Conway’s Law。使用 inverse Conway maneuver——围绕期望系统架构设计团队——并用 Team Topologies 作为设计框架。把 team structure 当成具有长期后果的有意识架构决策。 |