Analysis of the software with the 3C technique: User Stories – Digital4Pro

Analysis of the software with the 3C technique: User Stories

Reti geografiche cablate: la rete di distribuzione
26 Gennaio 2020
Analisi del software con la tecnica delle 3C: le User Story
3 Febbraio 2020

Continuous interaction with the customer is a fundamental component in the use of Agile methodologies for the production of software. From the beginning of the project, in the Agile method, a definition of the requirements made through frequent meetings in which both the work team and the customer participate.

These meetings have the dual purpose of incrementally define the functionality of the product and agree on the release priorities.
In the last twenty years the software analysis process has changed from extensive documentation to the use of narrative devices that see the software through the eyes of the final user. The editorial board of the project gantt, with the use of Agile methodologies, prefers User Stories as a communication tool between the team and the client.

The technique, rather simple to use, initially sees the drafting of stories with a very low level of detail and, only later, the enrichment of User Stories with details increasingly similar to the requirements.

Ron Jeffries, one of the three founders of the Extreme Programming software development methodology, describes the subsequent stages of this technique with the acronym 3C: Card, Conversation and Confirmation.

Card Phase

The Card phase contains a brief description of the functions to be implemented. A multitude of short sentences can be assimilated and many small episodes can open and close very quickly.

This approach allows the customer to easily understand the functionality as it takes shape, but also allows considerable feedback from him, leaving the necessary space to conversation. A requirement of functionality negotiated in this way becomes a proposal from which further ideas may
arise.

The customer’s needs are described with a broad vision thus revealing the benefits for the user, but postponing the implementation detail to a later time, avoiding the customer to define the specifications in their entirety from the beginning.

Interesting synergies can develop through the use of this technique thanks to the sharing of functionality with the whole team; in this way it is possible that other members of the team find similar functions to those already analyzed. A group of several similar User Stories is called Epic.

Conversation Phase

After the Card phase, we enter the merits of the features with a greater level of detail in order to resolve any ambiguity for the technician. The interaction with the customer takes place when you are in possession of the information necessary to identify the level of detail deriving from the data and no longer from the forecasts, which often turns out to be incorrect.

The User Story is divided into tasks assigned to specific team members. To do this, the technicians provide rewards and communicate the consequences of the choices that are made in implementing the required functions, while the customer defines the priority over the processing sheets that the technical team is able to take charge for that iteration.

Confirmation phase

Finally, we are in the Confirmation phase when, together with the customer, the end of the work is defined.

Extreme Programming requires that the customer determines the completion of a function and decide its acceptance during the Confirmation phase. A function is considered completed when the test previously agreed and prepared with the customer has been successful. It is precisely for this reason that, in Extreme Programming, the preparation of tests is a fundamental part of the process.

The first technique formulated in Extreme Programming was the Acceptance Test Driven Development (A-TDD) in which development is guided by acceptance tests written along the client. With the passing of time, this technique has evolved with the Specification By Example (SBE) with which we proceed by writing small examples of the features to be implemented and with the Behavior Driven Design (BDD), that is, with the development guided by user behavior.

Bibliography:

DevOps Guida per integrare Development e Operations e produrre software di qualità, Fabio Mora
User Stories Applied: For Agile Software Development, Mike Cohn

Condividi su:

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

EnglishFrenchGermanItalianRussianSpanish