Skip to content

Latest commit

 

History

History
173 lines (126 loc) · 6.14 KB

cycle.md

File metadata and controls

173 lines (126 loc) · 6.14 KB
Raw

The Cycle of Change

TL;DR

4D
  • Discussion
    • Problem
    • Complexity
  • Documentation
    • Manual
    • Scenarios
  • Decomposition
    • Solution
    • Change Requests
  • Development
    • Steps
    • Code

Definition

The goal of the Cycle is to help teams producing simple1 non-broken2 software in a fast and predictable way.

Cycle of making changes consists of four mandatory straight forward steps3: discussion, documentation, decomposition and development. Each iteration of the Cycle starts with the input, which is a description of the customer needs, provided in arbitrary form.

Discussion

Analyse the input to transform it into correct4, consistent5, complete6 and realizable7 form, that is strict problem definition.

Discussion should have an artifact which is a document that should have the following sections:

Abstract
Strict abstract definition of what problem to be solved, and how it should be solved.
Change Requests
Empty at this step.
Complexity
A number, which is abstract points estimation.
Statements
List of what is known.
Questions
List of what is unknown. At this step many questions may don't have an answer.
Options
Empty at this step.

While given sequence of sections ensures comfortable reading later, it will be most likely hard or impossible to create the document in such order.

Example

Documentation

Create the description from end-user perspective. Documentation must describe how to use the feature yet to be implemented, not how to implement it.

Documentation step consists of two sequential processes: writing the user manual and scenarios.

User Manual

Create or update User Manual. Form of this documentation part depends on type of software being developed. It can be end-user manual, public or private API reference, interface of the library or microservice, etc.

The creation of the user manual is a crucial part of the Cycle. Note that at this point a concrete solution is yet to be found, thus an author of the manual is not bound to the upcoming implementation complexity.

Designing an end-user application interface without regard to the complexity of the implementation is a key to producing a simple software. Thus, the end goal of writing user manual is to produce a software that doesn't need a manual.

Scenarios

Using the manual, describe expected software behaviour in a semi-formal format as a complete set of scenarios, using first-person narrative.

Important
Ensure the completeness of the set of scenarios as it is the iteration completion criteria.

At this point scenarios either failing or not executable due to missing implementation of new steps.

Failing or not executable scenarios are not the reason not to commit. Actually, failing scenarios is a permanent state of any feature branch until the iteration is completed.

Decomposition

Find and describe the solution of the problem. As the result of decomposition discussion document must be updated with:

  • answers to all questions, and some answers should have become statements
  • a list of considered options, starting with selected one and containing description of the selection criteria
  • a list of change requests

Change Requests

The list of changes to be made at the most top-level available in the software being developed. Each item basically should be the message for the future commit or pull request conforming the existent commit message convention.

In case a commit message is not enough to fully describe the request, then it should become an independent iteration of the Cycle without blocking current. Thereby, problem decomposition will continue until it composes a decision tree with elementary leaves described with a commit message.

Example

feat(cli): add option -e to toa export command

Development

Implement Steps

Add missing step implementations until all scenarios are executable and failing.

Important
Behaviour steps are programs, thus must be composed of developer's units of work.

Write the Code

Add the implementation in compliance with the solution and according to the set of change requests until scenarios are green and the feature branch is closed according to existent flow. See development requirements.

At this point, it is likely that reasons will be found to update the solution, change requests, manual or scenarios. If so, the update must be performed at the appropriate step and the Cycle must continue sequentially from that step.

At any moment of this step it should be clear what to do now and what to do next. Otherwise, it is necessary to return to one of the previous steps.

Perfect Result

Feature: Confident Delivery

  Automatically deliver changes once scenarios are green.

  Given I am automatic workflow
  When changes have been pushed to a feature branch
  And all scenarios are green
  And there are no conflicts with default branch
  Then merge feature branch to default branch
  And delete feature branch
  And deploy default branch to production

Footnotes

  1. Meeting a common sense expectations. ↩

  2. Meeting the requirements. ↩

  3. Neither step may be skipped when going forward. Going backward is arbitrary. ↩

  4. Does not conflict with the input. ↩

  5. Does not conflict with itself. ↩

  6. Contains enough information for next steps of the Cycle. ↩

  7. Able to be implemented. ↩