Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/schubmat/DecisionCapture

This repository is used to publish and share templates and guides on capturing decisions in agile software development. It is part of our research on rationale management in agile software development.
https://github.com/schubmat/DecisionCapture

Last synced: 5 days ago
JSON representation

This repository is used to publish and share templates and guides on capturing decisions in agile software development. It is part of our research on rationale management in agile software development.

Awesome Lists containing this project

README

        

# Making Decisions Sustainable in Agile Software Development -- A Research Study

* [Introduction](#introduction)
* [Study Goals](#studyGoals)
* [Study Setup](#studySetup)
* [Example templates](#decision-templates)
* [How to start capturing decision](#how-to-start-capturing)
* [How to start capturing decision with tools](#how-to-start-capturing-with-tools)
* [How to start capturing decision with git](#how-to-start-capturing-decisions-with-git)
* [Contributing](#contributing)
* [Sources](#sources)

Introduction

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](https://github.com/joelparkerhenderson/architecture_decision_record/), we do not only focus on [architectural decisions](https://github.com/joelparkerhenderson/architecture_decision_record/#introduction) 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](#decisions)). Nevertheless, we also encourage you to read [joelparkerhenderson's elaboration](https://github.com/joelparkerhenderson/architecture_decision_record/#introduction) 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](#sources).

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.

What decision are we talking about?

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.

Decision capture example templates

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](templates/captureTemplate_simple.md) (Provides ...)
* [Extensive template](templates/captureTemplate_full.md) (Provides ...)
* [Table-based template](templates/captureTemplate_table.md) (Provides ...)

How to start capturing decisions?

TODO

How to start capturing decisions with tools

TODO

How to start capturing decisions with git?

TODO

Contributing

Your comments and suggestions are welcome.

You can open a GitHub issue, or create a pull request, or email [email protected].

Sources

Other templates:

* [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions)
* [Template for documenting architecture alternatives and decisions - Stack Overflow](http://stackoverflow.com/questions/7104735/template-for-documenting-architecture-alternatives-and-decisions)

In-depth:

* [ADMentor XML project - GitHub](https://github.com/IFS-HSR/ADMentor)
* [Architectural Decision Guidance across Projects: Problem Space Modeling, Decision Backlog Management and Cloud Computing Knowledge](https://www.ifs.hsr.ch/fileadmin/user_upload/customers/ifs.hsr.ch/Home/projekte/ADMentor-WICSA2015ubmissionv11nc.pdf)
* [The Decision View's Role in Software Architecture Practice](https://www.computer.org/csdl/mags/so/2009/02/mso2009020036-abs.html)
* [Documenting Software Architectures: Views and Beyond](http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=30386)
* [Architecture Decisions: Demystifying Architecture](https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf)
* [ThoughtWorks Technology Radar: Lightweight Architecture Decision Records](https://www.thoughtworks.com/radar/techniques/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