The cycle of artifacts in Agile
Good day.
In this article I want to continue the story of the "pragmatic" Agile software development process. A different perspective of the review of this process is offered to the Reader’s court - from the point of view of the creation and evolution of artifacts (Artifact Flow) during the development of the project. We will also consider a practical approach to working with the “Collection of Requirements” artifact using Google Wave and Google Docs.
An artifact is a man-made object. In the first approximation, the artifacts can be called both program code and documents written by programmers. With a more careful approach, we can significantly expand the range of examples and assign e-mails, chat fragments and even a flag on the board to artifacts.
')
In fact, the sequence of creating / modifying artifacts and their content is critical to the health of the project. From my point of view, collectively created artifacts are of particular importance.
Next, I propose to take a look at the sketches of the life cycle of artifacts at three different stages of the development of an Agile project. In this case, we will use the following notation:
Where Person and Group are the creators of artifacts, Communication and Development are the processes in which artifacts are born, and, in fact, the artifacts themselves. Please note that in the communication processes collective artifacts are born, and during development - personal.
Why do I emphasize the importance of collective artifacts? Because they are communication channels and synchronizers of information between the customer (s) (s) and the contractor (s) of the project. In the absence of such communication channels, the project will proceed according to the “laws of common sense”, which are very subjective, and as a result, the customer “does not recognize” the “picture” in his head in the finished system. As a result, conflict is inevitable.
So, let's see the "slides" ...
The project initiation stage (Project Initiation Artifact Flow) .
The scenario here is this: Sales have done their part and we have a potential customer. At this stage, the company is allocated a person who will begin to communicate with the client on technical topics. The role of this person can be called differently - analyst, consultant, project owner (Product Owner). We will use the last name.
During the first (real or virtual) conversation of the project owner with the customer, the very first of collective artifacts is formed - Vision & User Story titles. This is a text document describing the main idea of ​​the project and its functionality in the form of short User Stories.
Then there is an internal meeting where the project owner and the project manager meet. The objective of this meeting is to decide on the composition of the development team and based on its ability to build an evaluation or preliminary plan (Preliminary Plan). For example, in our team, we “model” the execution of User Stories with the help of Gantt with resources.
The stage ends with the approval of the appraisal plan with the customer at the level of Sales-, financial-manager and other superiors (this is the moment of purchase of the service) and the official start of development.
Architectural Iteration Artifact Flow
The first iteration is architectural, during which the layers of the future system are built, and prototypes of dark places are written. Let's see what's going on with the artifacts.
At the entrance we have Vision & User Storiy titles. This artifact is made at the first big meeting with the team. The task of the rally is to develop a software architecture and a plan for architectural iteration. There is a discussion, the board is cluttered with drawings ... The first artifact that is born in the dispute is the draft of the architecture. Further, the tasks are evaluated and distributed - infrastructure (something to configure and configure), prototypes (check that the architectural idea works), architectural (connect the architecture component - for example, Web Services). Time estimates come from the team itself. As a result, a second artifact appears - an iteration plan.
The iteration plan and architectural draft arrives at the largest node in our diagram, the development. The results of the development are code, a list of bugs and engineering artifacts, such as installation instructions.
It is interesting that against the background of the artifact-turnaround of development, the second, no less important, is performed: the collection of Requirements. This is an ongoing process as a result of which the general view of the system is coordinated in detail. Sometimes, as a result of detailing, the initial general view itself changes. The process of collecting requirements may take place in different ways, but its participants are always the project owner (our analyst) and the customer (or his technical consultant). The result of this process is a constantly evolving Draft Requirements. In the second part of the article, I will show how you can use the services of Google Wave and Google Docs to work on this artifact.
Also here it is important to note that the Project Owner already at this stage should create an informal backlog for the accumulation and prioritization of User Stories, which fall into the next iteration. It is on them that he must concentrate on the work of collecting requirements. This practice — gathering in advance — moves from one iteration to another.
Functional Iteration Artifact Flow
This is the most important component of the project. During functional iterations, the product “grows”. As a rule (we have), development begins with an architectural iteration, and then several functional iterations go through until the release of the project.
If we describe artifact flows of such iteration in general terms, then besides the development flow and requirements gathering, a specification flow is added: the QA team based on the Requirements collection and the list of User History names writes short but exhaustive Test Cases. These Test Cases, along with an iterative plan, are the main driving artifacts during development.
On an artifact of a collection of requirements I want to stop separately. This artifact is responsible for synchronizing the image of the system functionality between all project participants. Our group stuffed a lot of bumps here and if I manage to remove a couple of rakes from your road, I will be happy).
The first question in an Agile project always arises: why write Requirements if you can just talk on the phone or Skype? Such a scenario is not excluded, but it is limited to the case when the domain is well understood by both the programmer and the customer, they speak the same language at about the same level, they have the same mentality (use the same principles of Common Sense), parts of the system that are discussed easily fit in memory (they are compact, and the system is usually small). In fact, such a case relates more to exceptions than to rules. The systems are built large and branched out, the teams we now have are distributed, with a different mentality, with different specializations, the world is multi-polar, IMHO, this is good.
In my opinion, the collection of requirements should be considered as a draft law, and test cases (as a specification) - as a law for this project and its participants.
In this approach, Google Wave is used to build a synchronous discussion tree. By synchronicity, I understand that there is no waiting time between sending data and receiving it by your interlocutor. You can see what he writes and vice versa. This property significantly activates the speed of the process of accumulation of requirements.
The wave consists of text and pictures. Figures represent page layouts of the system user interface. Text is a description of the layouts and the logical flow around them. At first glance, everything is simple. However, the Wave has its drawbacks. Oddly enough, the most serious problem is that the wave has too much freedom to organize branching. If you start using the Wave without a well-thought-out set of rules, it will quickly turn into a senseless cluttered space. We will discuss these rules in a couple of seconds.
Now about the layouts. At the moment, the best way to create them, I think Google Document and its component Drawing. It is simple and reliable. The document is inserted into the wave using the gadget's iFrame .
Now about the rules for constructing waves to collect Requirements:
1. Separate user stories are separate waves, collected in the "wave" folder with the name of the project.
2. Layouts related to a particular page and its states are gathered together in a separate folder of Google Docs with the name of the project. The names of these layouts have the name of the action or effect that they demonstrate. It should also be noted that each Google document has its own versioning system - therefore you should not duplicate the versions of the layouts with separate documents - this greatly simplifies the whole scheme.
3. Use one copy of the exact layout one step of the User Story. By exact layout, I mean a Google document. In this case, there may be many sketches. For sketches it is convenient to use this gadget .
3. Inside the Wave has a clear structure: in separate messages are the title of the Wave, which describes the general meaning of this User History, and then in separate messages follow the steps of this history.
Inside the story step, there are three sections in the form of Replies - the layout (Google document in iFrame), the text of comments to the layout and the text of logical flows in this step of the story. These parts of the step are implemented as Replies so that they can be quickly closed - this is convenient for long and twisted Waves.
The advantages of this approach to organizing Waves are as follows:
1. Collecting requirements is easily parallelized. If the project is voluminous, developers are easily included in requirements gathering. The project owner simply creates the Waves with the first header message and shares them with the developers. Then the developers draw layouts and discuss them directly with the customer.
2. Simplified and accelerated communication on the business domain during the sprint. If a programmer or QA-boxer has questions, he asks them right there in the Wave.
3. The customer can quickly initiate a conversation on any point of the Requirements.
Sample requirements gathering for a simple User Story
Consider an example of discussing and accumulating requirements for such a story: a website visitor reads the text of the home page and news.
Look at the screen shot of the wave , and then I'll add a couple of comments.
The development of this wave took place in the following way: the project owner created a wave called the corresponding user history. Then he added a message - a heading with common words on this story and the addresses of two gadgets (for convenience, so that they were always at hand). Then he invited the customer to the Wave. Created a message for the first step of the user's history, created a Google document with the first page layout. Added a few words to describe the layout and logical flow.
At this stage, the customer joined the work and wrote. that showing only the last three news on the home page is a bad idea, you need a component for turning the pages (Pagination). For clarity, the customer inserted a gadget for drawing sketches into the cue and quickly depicted the appearance of such a component.
The product owner agreed with the proposal and finished (without leaving the wave) the necessary component on the exact layout and updated the text.
Let's discuss this.
Good luck!
In this article I want to continue the story of the "pragmatic" Agile software development process. A different perspective of the review of this process is offered to the Reader’s court - from the point of view of the creation and evolution of artifacts (Artifact Flow) during the development of the project. We will also consider a practical approach to working with the “Collection of Requirements” artifact using Google Wave and Google Docs.
An artifact is a man-made object. In the first approximation, the artifacts can be called both program code and documents written by programmers. With a more careful approach, we can significantly expand the range of examples and assign e-mails, chat fragments and even a flag on the board to artifacts.
')
In fact, the sequence of creating / modifying artifacts and their content is critical to the health of the project. From my point of view, collectively created artifacts are of particular importance.
Artifact flow diagrams.
Next, I propose to take a look at the sketches of the life cycle of artifacts at three different stages of the development of an Agile project. In this case, we will use the following notation:
Where Person and Group are the creators of artifacts, Communication and Development are the processes in which artifacts are born, and, in fact, the artifacts themselves. Please note that in the communication processes collective artifacts are born, and during development - personal.
Why do I emphasize the importance of collective artifacts? Because they are communication channels and synchronizers of information between the customer (s) (s) and the contractor (s) of the project. In the absence of such communication channels, the project will proceed according to the “laws of common sense”, which are very subjective, and as a result, the customer “does not recognize” the “picture” in his head in the finished system. As a result, conflict is inevitable.
So, let's see the "slides" ...
The project initiation stage (Project Initiation Artifact Flow) .
The scenario here is this: Sales have done their part and we have a potential customer. At this stage, the company is allocated a person who will begin to communicate with the client on technical topics. The role of this person can be called differently - analyst, consultant, project owner (Product Owner). We will use the last name.
During the first (real or virtual) conversation of the project owner with the customer, the very first of collective artifacts is formed - Vision & User Story titles. This is a text document describing the main idea of ​​the project and its functionality in the form of short User Stories.
Then there is an internal meeting where the project owner and the project manager meet. The objective of this meeting is to decide on the composition of the development team and based on its ability to build an evaluation or preliminary plan (Preliminary Plan). For example, in our team, we “model” the execution of User Stories with the help of Gantt with resources.
The stage ends with the approval of the appraisal plan with the customer at the level of Sales-, financial-manager and other superiors (this is the moment of purchase of the service) and the official start of development.
Architectural Iteration Artifact Flow
The first iteration is architectural, during which the layers of the future system are built, and prototypes of dark places are written. Let's see what's going on with the artifacts.
At the entrance we have Vision & User Storiy titles. This artifact is made at the first big meeting with the team. The task of the rally is to develop a software architecture and a plan for architectural iteration. There is a discussion, the board is cluttered with drawings ... The first artifact that is born in the dispute is the draft of the architecture. Further, the tasks are evaluated and distributed - infrastructure (something to configure and configure), prototypes (check that the architectural idea works), architectural (connect the architecture component - for example, Web Services). Time estimates come from the team itself. As a result, a second artifact appears - an iteration plan.
The iteration plan and architectural draft arrives at the largest node in our diagram, the development. The results of the development are code, a list of bugs and engineering artifacts, such as installation instructions.
It is interesting that against the background of the artifact-turnaround of development, the second, no less important, is performed: the collection of Requirements. This is an ongoing process as a result of which the general view of the system is coordinated in detail. Sometimes, as a result of detailing, the initial general view itself changes. The process of collecting requirements may take place in different ways, but its participants are always the project owner (our analyst) and the customer (or his technical consultant). The result of this process is a constantly evolving Draft Requirements. In the second part of the article, I will show how you can use the services of Google Wave and Google Docs to work on this artifact.
Also here it is important to note that the Project Owner already at this stage should create an informal backlog for the accumulation and prioritization of User Stories, which fall into the next iteration. It is on them that he must concentrate on the work of collecting requirements. This practice — gathering in advance — moves from one iteration to another.
Functional Iteration Artifact Flow
This is the most important component of the project. During functional iterations, the product “grows”. As a rule (we have), development begins with an architectural iteration, and then several functional iterations go through until the release of the project.
If we describe artifact flows of such iteration in general terms, then besides the development flow and requirements gathering, a specification flow is added: the QA team based on the Requirements collection and the list of User History names writes short but exhaustive Test Cases. These Test Cases, along with an iterative plan, are the main driving artifacts during development.
Collecting information using Google Wave and Google Docs
On an artifact of a collection of requirements I want to stop separately. This artifact is responsible for synchronizing the image of the system functionality between all project participants. Our group stuffed a lot of bumps here and if I manage to remove a couple of rakes from your road, I will be happy).
The first question in an Agile project always arises: why write Requirements if you can just talk on the phone or Skype? Such a scenario is not excluded, but it is limited to the case when the domain is well understood by both the programmer and the customer, they speak the same language at about the same level, they have the same mentality (use the same principles of Common Sense), parts of the system that are discussed easily fit in memory (they are compact, and the system is usually small). In fact, such a case relates more to exceptions than to rules. The systems are built large and branched out, the teams we now have are distributed, with a different mentality, with different specializations, the world is multi-polar, IMHO, this is good.
In my opinion, the collection of requirements should be considered as a draft law, and test cases (as a specification) - as a law for this project and its participants.
In this approach, Google Wave is used to build a synchronous discussion tree. By synchronicity, I understand that there is no waiting time between sending data and receiving it by your interlocutor. You can see what he writes and vice versa. This property significantly activates the speed of the process of accumulation of requirements.
The wave consists of text and pictures. Figures represent page layouts of the system user interface. Text is a description of the layouts and the logical flow around them. At first glance, everything is simple. However, the Wave has its drawbacks. Oddly enough, the most serious problem is that the wave has too much freedom to organize branching. If you start using the Wave without a well-thought-out set of rules, it will quickly turn into a senseless cluttered space. We will discuss these rules in a couple of seconds.
Now about the layouts. At the moment, the best way to create them, I think Google Document and its component Drawing. It is simple and reliable. The document is inserted into the wave using the gadget's iFrame .
Now about the rules for constructing waves to collect Requirements:
1. Separate user stories are separate waves, collected in the "wave" folder with the name of the project.
2. Layouts related to a particular page and its states are gathered together in a separate folder of Google Docs with the name of the project. The names of these layouts have the name of the action or effect that they demonstrate. It should also be noted that each Google document has its own versioning system - therefore you should not duplicate the versions of the layouts with separate documents - this greatly simplifies the whole scheme.
3. Use one copy of the exact layout one step of the User Story. By exact layout, I mean a Google document. In this case, there may be many sketches. For sketches it is convenient to use this gadget .
3. Inside the Wave has a clear structure: in separate messages are the title of the Wave, which describes the general meaning of this User History, and then in separate messages follow the steps of this history.
Inside the story step, there are three sections in the form of Replies - the layout (Google document in iFrame), the text of comments to the layout and the text of logical flows in this step of the story. These parts of the step are implemented as Replies so that they can be quickly closed - this is convenient for long and twisted Waves.
The advantages of this approach to organizing Waves are as follows:
1. Collecting requirements is easily parallelized. If the project is voluminous, developers are easily included in requirements gathering. The project owner simply creates the Waves with the first header message and shares them with the developers. Then the developers draw layouts and discuss them directly with the customer.
2. Simplified and accelerated communication on the business domain during the sprint. If a programmer or QA-boxer has questions, he asks them right there in the Wave.
3. The customer can quickly initiate a conversation on any point of the Requirements.
Sample requirements gathering for a simple User Story
Consider an example of discussing and accumulating requirements for such a story: a website visitor reads the text of the home page and news.
Look at the screen shot of the wave , and then I'll add a couple of comments.
The development of this wave took place in the following way: the project owner created a wave called the corresponding user history. Then he added a message - a heading with common words on this story and the addresses of two gadgets (for convenience, so that they were always at hand). Then he invited the customer to the Wave. Created a message for the first step of the user's history, created a Google document with the first page layout. Added a few words to describe the layout and logical flow.
At this stage, the customer joined the work and wrote. that showing only the last three news on the home page is a bad idea, you need a component for turning the pages (Pagination). For clarity, the customer inserted a gadget for drawing sketches into the cue and quickly depicted the appearance of such a component.
The product owner agreed with the proposal and finished (without leaving the wave) the necessary component on the exact layout and updated the text.
Let's discuss this.
Good luck!
Source: https://habr.com/ru/post/82388/
All Articles