Basics
Before choosing a lifecycle or a framework, there is a smaller question: what is the process this team runs, how would you write it down, and how would you know whether it is working? These pages cover that groundwork — where process thinking came from, how to define one activity precisely, and what happens when you start measuring the people who carry it out.
The measurement pages are the ones to read carefully. Deciding what to measure and deciding who sees the result are different problems, and the second causes more damage than the first.
Which page to read next
| Page | What it covers | The core claim |
|---|---|---|
| Where Process Came From | Smith, Taylor, Deming, and why software adopted them | Defects propagate, so quality has to be built upstream rather than inspected in |
| Defining a Process | How to elicit, document and improve an actual process | Ask the people who do the work, and record why each step exists |
| ETVX | The notation for one atomic activity | Explicit exit criteria are what stop work being declared done by the calendar |
| GQM | Choosing metrics by deriving them from goals | Goal first, metric last — a metric with no question above it has no reason to exist |
| Process Metrics | What measurement does to the people measured | Aim a process metric at people and it stops being a measurement |
| Scoreboard | Tracking judgement when the thing that matters is not countable | Read the trend, and cover every role |
How solid is this?
The material here is a mix of long-established method and thin evidence, and the pages say which is which. ETVX and GQM are settled practice with decades of industrial use behind them. The claims about measurement dysfunction rest on practitioner reports rather than controlled studies — they show the behaviours occur, not how often — and the scoreboard is documented in a single student project. Where a page teaches something the sources do not actually support, it says so under its own How solid is this? heading.
Acknowledgments
These pages adapt material from lectures by Eduardo Miranda and David Root [1] on software project management.
References
- D. Root,Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.