├── CITATION.cff ├── CODE_OF_CONDUCT.md └── README.md /CITATION.cff: -------------------------------------------------------------------------------- 1 | cff-version: 1.2.0 2 | title: Software development methodologies, practices, tactics 3 | message: >- 4 | If you use this work and you want to cite it, 5 | then you can use the metadata from this file. 6 | type: software 7 | authors: 8 | - given-names: Joel Parker 9 | family-names: Henderson 10 | email: joel@joelparkerhenderson.com 11 | affiliation: joelparkerhenderson.com 12 | orcid: 'https://orcid.org/0009-0000-4681-282X' 13 | identifiers: 14 | - type: url 15 | value: 'https://github.com/joelparkerhenderson/software-development-methodologies/' 16 | description: Software development methodologies, practices, tactics 17 | repository-code: 'https://github.com/joelparkerhenderson/software-development-methodologies/' 18 | abstract: >- 19 | Software development methodologies, practices, tactics 20 | license: See license file 21 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | 2 | # Contributor Covenant Code of Conduct 3 | 4 | ## Our Pledge 5 | 6 | We as members, contributors, and leaders pledge to make participation in our 7 | community a harassment-free experience for everyone, regardless of age, body 8 | size, visible or invisible disability, ethnicity, sex characteristics, gender 9 | identity and expression, level of experience, education, socio-economic status, 10 | nationality, personal appearance, race, caste, color, religion, or sexual 11 | identity and orientation. 12 | 13 | We pledge to act and interact in ways that contribute to an open, welcoming, 14 | diverse, inclusive, and healthy community. 15 | 16 | ## Our Standards 17 | 18 | Examples of behavior that contributes to a positive environment for our 19 | community include: 20 | 21 | * Demonstrating empathy and kindness toward other people 22 | * Being respectful of differing opinions, viewpoints, and experiences 23 | * Giving and gracefully accepting constructive feedback 24 | * Accepting responsibility and apologizing to those affected by our mistakes, 25 | and learning from the experience 26 | * Focusing on what is best not just for us as individuals, but for the overall 27 | community 28 | 29 | Examples of unacceptable behavior include: 30 | 31 | * The use of sexualized language or imagery, and sexual attention or advances of 32 | any kind 33 | * Trolling, insulting or derogatory comments, and personal or political attacks 34 | * Public or private harassment 35 | * Publishing others' private information, such as a physical or email address, 36 | without their explicit permission 37 | * Other conduct which could reasonably be considered inappropriate in a 38 | professional setting 39 | 40 | ## Enforcement Responsibilities 41 | 42 | Community leaders are responsible for clarifying and enforcing our standards of 43 | acceptable behavior and will take appropriate and fair corrective action in 44 | response to any behavior that they deem inappropriate, threatening, offensive, 45 | or harmful. 46 | 47 | Community leaders have the right and responsibility to remove, edit, or reject 48 | comments, commits, code, wiki edits, issues, and other contributions that are 49 | not aligned to this Code of Conduct, and will communicate reasons for moderation 50 | decisions when appropriate. 51 | 52 | ## Scope 53 | 54 | This Code of Conduct applies within all community spaces, and also applies when 55 | an individual is officially representing the community in public spaces. 56 | Examples of representing our community include using an official e-mail address, 57 | posting via an official social media account, or acting as an appointed 58 | representative at an online or offline event. 59 | 60 | ## Enforcement 61 | 62 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 63 | reported to the community leaders responsible for enforcement at 64 | [INSERT CONTACT METHOD]. 65 | All complaints will be reviewed and investigated promptly and fairly. 66 | 67 | All community leaders are obligated to respect the privacy and security of the 68 | reporter of any incident. 69 | 70 | ## Enforcement Guidelines 71 | 72 | Community leaders will follow these Community Impact Guidelines in determining 73 | the consequences for any action they deem in violation of this Code of Conduct: 74 | 75 | ### 1. Correction 76 | 77 | **Community Impact**: Use of inappropriate language or other behavior deemed 78 | unprofessional or unwelcome in the community. 79 | 80 | **Consequence**: A private, written warning from community leaders, providing 81 | clarity around the nature of the violation and an explanation of why the 82 | behavior was inappropriate. A public apology may be requested. 83 | 84 | ### 2. Warning 85 | 86 | **Community Impact**: A violation through a single incident or series of 87 | actions. 88 | 89 | **Consequence**: A warning with consequences for continued behavior. No 90 | interaction with the people involved, including unsolicited interaction with 91 | those enforcing the Code of Conduct, for a specified period of time. This 92 | includes avoiding interactions in community spaces as well as external channels 93 | like social media. Violating these terms may lead to a temporary or permanent 94 | ban. 95 | 96 | ### 3. Temporary Ban 97 | 98 | **Community Impact**: A serious violation of community standards, including 99 | sustained inappropriate behavior. 100 | 101 | **Consequence**: A temporary ban from any sort of interaction or public 102 | communication with the community for a specified period of time. No public or 103 | private interaction with the people involved, including unsolicited interaction 104 | with those enforcing the Code of Conduct, is allowed during this period. 105 | Violating these terms may lead to a permanent ban. 106 | 107 | ### 4. Permanent Ban 108 | 109 | **Community Impact**: Demonstrating a pattern of violation of community 110 | standards, including sustained inappropriate behavior, harassment of an 111 | individual, or aggression toward or disparagement of classes of individuals. 112 | 113 | **Consequence**: A permanent ban from any sort of public interaction within the 114 | community. 115 | 116 | ## Attribution 117 | 118 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 119 | version 2.1, available at 120 | [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1]. 121 | 122 | Community Impact Guidelines were inspired by 123 | [Mozilla's code of conduct enforcement ladder][Mozilla CoC]. 124 | 125 | For answers to common questions about this code of conduct, see the FAQ at 126 | [https://www.contributor-covenant.org/faq][FAQ]. Translations are available at 127 | [https://www.contributor-covenant.org/translations][translations]. 128 | 129 | [homepage]: https://www.contributor-covenant.org 130 | [v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html 131 | [Mozilla CoC]: https://github.com/mozilla/diversity 132 | [FAQ]: https://www.contributor-covenant.org/faq 133 | [translations]: https://www.contributor-covenant.org/translations 134 | 135 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Software development methodologies, practices, tactics 2 | 3 | This page summarizes various software development methodologies, practices, and tactics. The choices and summaries are based on our experiences with our teams, clients, and customers. 4 | 5 | Suggestions for improvements are welcome; you can open an issue, or send a pull request, or email joel@joelparkerhenderson.com. 6 | 7 | Contents: 8 | 9 | - [Agile](#agile) 10 | - [Disciplined agile delivery](#disciplined-agile-delivery) 11 | - [Infrastructure as Code (IaC)](#infrastructure-as-code-iac) 12 | - [Kanban](#kanban) 13 | - [Scaled agile framework](#scaled-agile-framework) 14 | - [Scrum](#scrum) 15 | - [Spiral development model](#spiral-development-model) 16 | - [Sprints](#sprints) 17 | - [Six thinking hats](#six-thinking-hats) 18 | - [Run Until Caught](#run-until-caught) 19 | - [Technical debt vs. unhedged call option](#technical-debt-vs-unhedged-call-option) 20 | - [Waterfall model](#waterfall-model) 21 | 22 | 23 | ## Agile 24 | 25 | https://wikipedia.org/wiki/Agile_software_development 26 | 27 | Agile Manifesto: 28 | 29 | * Individuals and interactions over processes and tools 30 | 31 | * Working software over comprehensive documentation 32 | 33 | * Customer collaboration over contract negotiation 34 | 35 | * Responding to change over following a plan 36 | 37 | Principles: 38 | 39 | * Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 40 | 41 | * Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 42 | 43 | * Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 44 | 45 | * Business people and developers must work together daily throughout the project. 46 | 47 | * Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 48 | 49 | * The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 50 | 51 | * Working software is the primary measure of progress. 52 | 53 | * Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 54 | 55 | * Continuous attention to technical excellence and good design enhances agility. 56 | 57 | * Simplicity--the art of maximizing the amount of work not done--is essential. 58 | 59 | * The best architectures, requirements, and designs emerge from self-organizing teams. 60 | 61 | * At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 62 | 63 | 64 | ## Disciplined agile delivery 65 | 66 | https://wikipedia.org/wiki/Disciplined_agile_delivery 67 | 68 | Key aspects: 69 | 70 | * People-first 71 | 72 | * Learning-oriented 73 | 74 | * Hybrid 75 | 76 | * Full delivery lifecycle 77 | 78 | * Process goal driven 79 | 80 | * Solution focused 81 | 82 | * Risk-value lifecycle 83 | 84 | * Enterprise aware 85 | 86 | Primary roles: 87 | 88 | * Stakeholder 89 | 90 | * Product Owner 91 | 92 | * Team Member 93 | 94 | * Team Lead 95 | 96 | * Architecture Owner 97 | 98 | Secondary roles: 99 | 100 | * Specialist 101 | 102 | * Domain Expert 103 | 104 | * Technical Expert 105 | 106 | * Independent Tester 107 | 108 | * Integrator 109 | 110 | 111 | ## Infrastructure as Code (IaC) 112 | 113 | https://wikipedia.org/wiki/Infrastructure_as_Code 114 | 115 | Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. 116 | 117 | Advantages: 118 | 119 | * Cost savings: IaC removes manual tasks, thus freeing up people to do other work. 120 | 121 | * Speed improvements: IaC enables faster execution, and also enables visibility among teams which accelerates collaboration. 122 | 123 | * Risk reduction: IaC removes risks associated with human error, like manual misconfiguration 124 | 125 | There are generally two approaches to IaC: 126 | 127 | * Declarative (functional): what is the target/goal/outcome. 128 | 129 | * Imperative (procedural): how changes should be run/applied/processed 130 | 131 | 132 | ## Kanban 133 | 134 | https://wikipedia.org/wiki/Kanban_(development) 135 | 136 | Kanban (Japanese: 看板, meaning signboard or billboard) is a lean method to manage and improve work across human systems. 137 | 138 | * Kanban aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks. 139 | 140 | * Work items are visualized to give participants a view of progress and process, from start to finish, usually via a kanban board. 141 | 142 | Notable advantages: 143 | 144 | * Visualizes the work, such as tasks, todos, feature requests, use cases, user stories, etc. 145 | 146 | * Captures work-in-progress (WIP) limits for development steps. 147 | 148 | * Documents policies, also known as done rules. 149 | 150 | * Shows flow management from step to step, such as "ready to do", "in progress", "awaiting signoff", etc. 151 | 152 | 153 | ## Scaled agile framework 154 | 155 | https://wikipedia.org/wiki/Scaled_agile_framework 156 | 157 | Principles: 158 | 159 | * Take an economic view 160 | 161 | * Apply systems thinking 162 | 163 | * Assume variability; preserve options 164 | 165 | * Build incrementally with fast, integrated learning cycles 166 | 167 | * Base milestones on objective evaluation of working systems 168 | 169 | * Visualize and limit work-in-progress, reduce batch sizes, and manage queue lengths 170 | 171 | * Apply cadence (timing), synchronize with cross-domain planning 172 | 173 | * Unlock the intrinsic motivation of knowledge workers 174 | 175 | * Decentralize decision-making 176 | 177 | 178 | 179 | ## Scrum 180 | 181 | https://wikipedia.org/wiki/Scrum_(software_development) 182 | 183 | Key roles: 184 | 185 | * A "customer voice" a.k.a. "product owner role". This role that represents the product's stakeholders and the voice of the customer. The product hat creates roadmaps, is accountable for the backlog, and maximising the value that team delivers to the business. The product hat defines the product in customer-centric terms such as user stories, adds them to the product backlog, and prioritizes them based on importance and dependencies. 186 | 187 | * A "team voice" a.k.a. "scrum master role". This role is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The role is not a traditional team lead or project manager but acts as a buffer between the team and any distracting influences. The role has also been referred to as a team facilitator or servant-leader. 188 | 189 | * A "delivery team" a.k.a. that does all tasks required to build the product increments (analysis, design, development, testing, documentation). The team is multi-disciplinary; the team is not just programmers. 190 | 191 | 192 | ## Spiral development model 193 | 194 | https://wikipedia.org/wiki/Spiral_model 195 | 196 | https://resources.sei.cmu.edu/asset_files/SpecialReport/2000_003_001_13655.pdf 197 | 198 | The spiral development model is a risk-driven process model generator. It guides multi-stakeholder concurrent engineering of software-intensive systems by using five major spiral features: 199 | 200 | * cyclic concurrent engineering 201 | 202 | * risk driven determination of process and product, including choices of sub-methodologies such as incremental, waterfall, evolutionary prototyping, etc. 203 | 204 | * growing a system via risk-driven experimentation and elaboration 205 | 206 | * lowering development cost by early elimination of nonviable alternatives and rework avoidance 207 | 208 | * anchor point milestones for ensuring stakeholder commitment, for driving the spiral toward completion, for comparing progress among spiral projects. 209 | 210 | 211 | ## Sprints 212 | 213 | Calendar time sprint: 214 | 215 | * A "calendar time sprint" aims for given amount of time, such as one month, then tries to choose work that can fit into the time. 216 | 217 | * Example: A team decides to do a monthly sprint, then looks at all the potential work to do, and does a planning session to choose the work that is likely to fit into the time. 218 | 219 | Customer value sprint: 220 | 221 | * A "customer value sprint" aims for a business goal, such as delivering a new feature, and then gives options for scheduling time and resources. 222 | 223 | * Example: there is a customer cohort that will pay more when the product has a new feature. The team estimates the work, and then works on it. 224 | 225 | Internal value sprint: 226 | 227 | * An "internal value sprint" aims for an infrastructure goal, such as refactoring, replatforming, or research. 228 | 229 | * Example: the team wants to change the code from using one kind of code to another kind, or from one hosting company to another, or from internally-built code to vendor-built code. The team estimates the work, and then works on it. 230 | 231 | 232 | ## Six thinking hats 233 | 234 | https://wikipedia.org/wiki/Six_Thinking_Hats 235 | 236 | The six thinking hats are described as a role and a hat color: 237 | 238 | * Managing = Blue. What is the subject? what are we thinking about? what is the goal? Can look at the big picture. 239 | * Information = White. Consider purely what information is available; what are the facts? 240 | * Emotions = Red. Intuitive or instinctive gut reactions or statements of emotional feeling (but not any justification). 241 | * Discernment = Black. Logic applied to identifying reasons to be cautious and conservative. Practical, realistic. 242 | * Optimistic response = Yellow. Logic applied to identifying benefits, seeking harmony. Sees the brighter, sunny side of situations. 243 | * Creativity = Green. Statements of provocation and investigation, seeing where a thought goes. Thinks creatively, outside the box. 244 | 245 | 246 | ## Run Until Caught 247 | 248 | https://github.com/run-until-caught/Run-Until-Caught-Development 249 | 250 | Run Until Caught Development is a set of principles for moving faster than large company processes normally would allow through strategic positioning of your work relative to burdensome internal processes. 251 | 252 | There are six higher-order concepts within Run Until Caught development. 253 | 254 | The first 4 concepts are part of the "run" part of "run until caught" development. 255 | 256 | * Believable Ignorance 257 | 258 | * Creatively Leverage Definitions 259 | 260 | * Defer Until Tomorrow 261 | 262 | * Piggyback Rides 263 | 264 | The last two concepts are all about the "caught" part of "run until caught" development. 265 | 266 | * Cost Accounting (no not that one) 267 | 268 | * How to Respond to being 'caught' 269 | 270 | 271 | ## Technical debt vs. unhedged call option 272 | 273 | Bad code isn’t Technical Debt, it’s an unhedged call 274 | 275 | By Steve Freeman on 2010-07-23. 276 | 277 | This is all Chris Matts‘ idea. He realised that the problem with the “Technical Debt” metaphor is that for managers debt can be a good thing. Executives can be required to take on more debt because it makes the finances work better, it might even be encouraged by tax breaks. This is not the same debt as your personal credit card. Chris came up with a better metaphor, the Call Option. 278 | 279 | I “write” a Call Option when I sell someone the right, but not the obligation, to buy in the future an agreed quantity of something at an price that is fixed now. So, for a payment now, I agree to sell you 10,000 chocolate santas1 at 56 pence each, at any time up to 10th December. You’re prepared to pay the premium because you want to know that you’ll have santas in your stores at a price you can sell. 280 | 281 | From my side, if the price of the santas stays low, I get to keep your payment and I’m ahead. But, I also run the risk of having to provide these santas when the price has rocketed to 72 pence. I can protect myself by making arrangements with another party to acquire them at 56 pence or less, or by actually having them in stock. Or, I can take a chance and just collect the premium. This is called an unhedged, or “Naked”, Call. In the financial world this is risky because it has unlimited downside, I have to supply the santas whatever they cost me to provide. 282 | 283 | Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up. 284 | 285 | On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called. 286 | 287 | Even if it is more expensive to do things cleanly (and I’m not convinced of that beyond a two-week horizon), it’s also less risky. A messy system is full of unhedged calls, each of which can cost an unpredictable amount should they ever be exercised. We’ve all seen what this can do in the financial markets, and the scary thing is that failure, if it comes, can be sudden—everything is fine until it isn’t. I’ve seen a few systems which are just too hard to change to keep up with the competition and the owners are in real trouble. 288 | 289 | So that makes refactoring like buying an option too. I pay a premium now so that I have more choices about where I might take the code later. This is a mundane and obvious activity in many aspects of business—although not, it seems, software development. I don’t need to spend this money if I know exactly what will happen, if I have perfect knowledge of the relevant parts of the future, but I don’t recall when I last saw this happen. 290 | 291 | So, the next time you have to deal with implausible delivery dates, don’t talk about Technical Debt. Debt is predictable and can be managed, it’s just another tool. Try talking about an Unhedged Call. Now all we need is a way to price Code Smells. 292 | 293 | 294 | ## Waterfall model 295 | 296 | https://wikipedia.org/wiki/Waterfall_model 297 | 298 | The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous phase. 299 | 300 | Waterfall phases typically include these: 301 | 302 | * System and software requirements: captured in a product requirements document 303 | 304 | * Analysis: resulting in models, schema, and business rules 305 | 306 | * Design: resulting in the software architecture 307 | 308 | * Coding: the development, proving, and integration of software 309 | 310 | * Testing: the systematic discovery and debugging of defects 311 | 312 | * Operations: the installation, migration, support, and maintenance of complete systems 313 | 314 | Key advantags: 315 | 316 | * Provides the entire plan up front. 317 | 318 | * Emphasizes documentation, which enables teams to understand aspects by reading. 319 | 320 | * Easy to understand, because the model progresses linearly through discrete phases. 321 | --------------------------------------------------------------------------------