- Introduction
- Study Goals
- Study Setup
- Example templates
- How to start capturing decision
- How to start capturing decision with tools
- How to start capturing decision with git
- Contributing
- Sources
This repository is used to publish and share templates and guidelines on capturing and using decision in agile software development. It is part of our research on decision management in agile software development. Unlike the approach of joelparkerhenderson, we do not only focus on architectural decisions but on decisions being important to the development team. Thus, we consider every development related decision to be potentially important. Nevertheless, these are often architectural decisions.
According to the agile principle 'The best architectures, requirements, and designs emerge from self-organizing teams' we assume that the team does know best what is an important decision and what is not. Thus, we only provide an examplary list of decisions types from previous studies with industry partners and students (see section). Nevertheless, we also encourage you to read joelparkerhenderson's elaboration on architectural decisions, if you are interested in the topic of managing decision. More literature on the topic of architectural knowledge management can be found further down.
The goal of this document is to provide a quick overview of methods and templates of capturing decisions in agile software development, how to create them, and where to look for more information.
As outlined above, we have no intention of telling someone what kind of decisions he/she should consider being particularly important. Thus, decisions to capture by the team can be of any type. In order to give you some help anyway, we have put together an exemplary list of decisions as follows:
- Decisions regarding development tools – e.g., employed IDE, project management tools.
- Architectural decisions – e.g., interfaces definitions, architectural decisions.
- Technology decisions – e.g., employed libraries and frameworks and its pros and cons.
- Decisions on the deployment plattform – e.g., deployment process, Android vs. iOS.
- Decisions on features – e.g., add / refine / change / remove a requirement.
- Decisions on priorising User Stories – e.g., postpone, prepone or omit a user story.
- Decisions on software quality measures – e.g., schedule a refactoring, a review or similar.
- Decisions regarding the user experience – e.g., revise the strategy for the user experience.
- Decisions regarding the team prganisation – e.g., changes of roles, staff reshuffling, or similar.
- Decisions on software development process – e.g., restructure the sprint based on the outcome of the retrospective
The list has been deduced on the basis of existing literature as well as student and industry studies we conducted. Precisely because there were decisions that we could not classify, the list does not claim to be complete. Nevertheless, the absolute majority of decisions recorded in our studies are represented by the above list.
In the following listing you can find links to three templates for capturing decisions. We currently use them for experiments with students and industry practitioners.
- Simple template (Provides ...)
- Extensive template (Provides ...)
- Table-based template (Provides ...)
TODO
TODO
TODO
Your comments and suggestions are welcome.
You can open a GitHub issue, or create a pull request, or email [email protected].
Other templates:
- Documenting architecture decisions - Michael Nygard
- Template for documenting architecture alternatives and decisions - Stack Overflow
In-depth:
- ADMentor XML project - GitHub
- Architectural Decision Guidance across Projects: Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge
- The Decision View's Role in Software Architecture Practice
- Documenting Software Architectures: Views and Beyond
- Architecture Decisions: Demystifying Architecture
- ThoughtWorks Technology Radar: Lightweight Architecture Decision Records
See also:
- REMAP (Representation and Maintenance of Process Knowledge)
- DRL (Decision Representation Language)
- IBIS (Issue-Based Information System)
- QOC (Questions, Options, and Criteria)
- DRL (Decision Representation Language),
- IBM’s e-Business Reference Architecture Framework