Home

the Gardener

The teaser

With BDD (Behavior Driven Development) :

• the product owner and the developers really understand each other's
• the overall development time is faster
• the team is confident about its product and its development

The idea: what we want to do?

Several use cases are poorly addressed :

• Support the collaboration between Developers and Product Owner during the specification stage
• Give an easy access to the generated documentation

Let's create a web application to address them:

The name

the Gardener : he's taking care of your features

Why ? The technology behind the BDD features is mainly driven by https://cucumber.io/. So it's a joke, the gardener is taking care of the plants, is taking care of the cucumbers, is taking care of your features.

As the main purpose of the application is to do a workflow so that Product Owner and Developers can write and iterate on a feature with several scenarios we can see that as little cucumbers that are growing....

The plan

• Main planned features
  • Show features in a pretty way
    • the features themselves
    • be able to decorate features so that the presentation is more userfriendly
    • a map of the scenarios included in a feature based on annotations (abstraction level / nomal, limit, error cases)
  • Easy access to those features :
    • several hierarchy to navigate to features : technical view, business view...
    • search based on annotation or on free text
  • Feature edition in collaboration
    • be able to create and edit features
    • be able to assign feature for review
    • dasboard with draft features to be reviewed

The prerequisites

In which context, we can use theGardener to take cake of our projects features ?

1. Code source managed by Git.
2. One branch is considered stable. By default : master.
3. The same Git project cannot be reference twice from 2 different git hosts.
4. theGardener consider that the development workflow is the feature branch workflow :
   • Create a feature branch
   • Define the specification on the feature branch
   • Implement the feature this branch
   • Merge the feature branch into the stable branch

The implementation of theGardener apply the "Convention over configuration" principle, this means that there should be to much to configure in theGardener in order to exploit its features.

The recommendations

TheGardener exploit the annotations linked to the scenario. Especially, some features of theGarderner assume that each scenario can have :

1. A level of abstraction :
   • @level_0_high_level: anybody can understand it
   • @level_1_specification (by default): DEV, Product Owner, Tester of the team can understand and update it
   • @level_2_technical_details: DEV of the team can understand and update it
2. A case type :
   • @nominal_case (by default)
   • @limit_case
   • @error_case
3. A status :
   • @draft
   • @ready
   • @ongoing
   • @valid (by default)

It will work fine if those annotations are no defined for the scenarios but if you want to exploit all theGardener features, it worth to define theme.

The main use cases

Configure a hosted project in theGarderner to get features

TODO : theGardener_sequence_diagram to get features

Access to features

TODO : theGardener_sequence_diagram to get features

Collaboration product owner and developers to write a feature

The architecture