Agile Artifact Cycle
Good day.
In this article, I want to continue the story of the “pragmatic” Agile software development process. For the reader’s judgment, a different perspective is proposed for a review of this process - from the point of view of the creation and evolution of artifacts (Artifact Flow) during the development of the project. We’ll also look at a practical approach for working with the “Requirements Collection” artifact using Google Wave and Google Docs.
An artifact is a man-made object. In a first approximation, the program code and documents written by programmers can be called artifacts. With a more thorough approach, we can significantly expand the range of examples and include emails, fragments of chats, and even drafts by a flamaster on the board, to artifacts.
In fact, the sequence of creation / modification of artifacts and their content is critical to the health of the project. Of particular importance, from my point of view, are collectively created artifacts.
Further, I suggest looking at sketches of the life cycle of artifacts at three different stages in the development of the 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 generated, and, in fact, the artifacts themselves. Please note that in the Communication processes collective artifacts are born, and in Development - personal ones.
Why am I emphasizing the importance of collective artifacts? Because they are communication channels and information synchronizers between the customer (s) (s) and the executor (s) (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 "will not recognize" the "picture" that is in his head in the finished system. As a result, conflict is inevitable.
So, let's see the “slides” ...
Project Initiation Artifact Flow stage .
The scenario here is this: Sales did their part and we got a potential customer. At this stage, a person stands out in the company 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 between the project owner and the customer, the very first of the collective artifacts, Vision & User Story titles, is formed. This is a text document which describes the main idea of the project and its functionality in the form of short User Stories.
This is followed by an internal meeting where the project owner and project manager meet. The purpose of this meeting is to decide on the composition of the development team and, based on its capabilities, build a preliminary or preliminary plan. For example, in our team, we “model” the execution of User Stories using the Gantt with resources.
The stage ends with the coordination of the evaluation plan with the customer at the level of Sales-, financial- manager and other superiors (this is the moment of purchasing the service) and the official start of development.
Architectural Iteration Artifact Flow
The first iteration is architectural, during which layers of the future system are built, 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 submitted to the first large rally with the team. The purpose 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 a draft architecture. Next, tasks are assessed and distributed - infrastructural (to configure and configure something), prototypes (to verify that the architectural idea works), architectural (to connect an architecture component - for example, Web Services). Estimates of the time come from the team itself. As a result, a second artifact appears - the iteration plan.
The iteration plan and architectural draft enter the largest node in our diagram - into development. The development results are code, a list of bugs, and engineering artifacts, such as installation instructions.
It is interesting that against the background of the artifact-turnover of development, a second, no less important, is fulfilled: the collection of Requirements. This is an ongoing process as a result of which the overall view of the system is coordinated and detailed. Sometimes, as a result of detailing, the original general view itself changes. The requirements collection process itself can proceed in different ways, but its participants are always the project owner (our analyst) and the customer (or its technical consultant). The result of this process is the ever-evolving Draft Requirements. In the second part of the article I will show how you can use the Google Wave and Google Docs services to work on this artifact.
It is also important here to note that the Project Owner should already have created an informal backlog at this stage for the accumulation and prioritization of User Stories that fall into the next iteration. It was on them that he should concentrate on collecting requirements. This practice - collecting “forward” - goes from one iteration to another.
Functional Iteration Artifact Flow
This is the most important part of the project. During functional iterations, the product “grows”. As a rule (with us), development begins with an architectural iteration, and then several functional iterations go on until the project is released.
If we describe the flows of artifacts of such an iteration in general terms, then in addition to the development flow and requirements collection, a specification stream is added: the QA team, based on the Requirements collection and the list of User History names, writes short but comprehensive Test Cases. These Test Cases along with the iterative plan are the main driving artifacts during development.
I want to dwell on the artifact of the requirements collection separately. This artifact is responsible for synchronizing the picture of the system’s functionality between all project participants. Our group got a lot of cones 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 programmer and the customer are well understood, they speak the same language at approximately the same level, they have the same mentality (use the same principles of Common Sense), the parts of the system that are discussed easily fit into memory (they are compact, and the system is usually small). In fact, such a case relates more to exceptions than to rules. Systems are built large and branched, the teams we have now distributed, with a different mentality, with different specializations, the world is multipolar, IMHO, this is good.
In my opinion, a 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 requirements accumulation process itself.
The wave consists of text and drawings. The figures represent page layouts of the system user interface. Text is a description of the layouts and logical flows 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 stupid cluttered space. We will discuss these rules in a couple of seconds.
Now about the layouts. At the moment, I think the best way to create them is with Google Document and its Drawing component. It is simple and reliable. The document is inserted into the wave using the iFrame gadget .
Now about the rules for building waves to collect requirements:
1. Separate User Stories are separate waves collected in a “wave” folder with the name of the project.
2. Layouts related to a particular page and its states are gathered together in a separate Google Docs folder with the name of the project. The names of these layouts include the name of the action or effect that they demonstrate. It should also be noted that each Google document has its own version system - therefore, do not duplicate versions of layouts with separate documents - this greatly simplifies the whole scheme.
3. Use one instance of the exact layout for one step of the User History. By exact layout, I mean a Google document. There can be many drafts. It’s convenient to use this gadget for sketches .
3. Inside the Wave has a clear structure: in separate messages there is a heading for the Wave that describes the general meaning of this User History, and then in separate messages the steps of this history follow.
Inside the history step, there are three sections in the form of Replies - the layout (Google document in iFrame), the text of the comments for the layout, and the text of the logical flows in this history step. These parts of the step are implemented as Replies so that they can be quickly closed - this is convenient for long and swirling Waves.
The advantages of this approach to organizing Waves are as follows:
1. Collection of requirements is easy to parallelize. If the project is voluminous, developers are easily included in the collection of requirements. The project owner simply creates the Waves with the first header message and shares them with the developers. Then the developers draw the layouts and discuss them with the customer directly.
2. Simplified and accelerated communication on the business domain during the sprint. If a programmer or QA-box has questions, he immediately asks them to the Wave.
3. The customer can quickly initiate a conversation at any point in the Requirements.
Example of collecting requirements for a simple User History
Consider some example of discussion and accumulation of requirements for such a story: a website visitor gets acquainted with the text of the home page and the news.
View screen shot of a wave, and then I will add a couple of comments. The development of this wave occurred in this way: the project owner created a wave called the corresponding user story. Then he added a message - a heading with common words on this story and the addresses of two gadgets (for convenience, so that they are always at hand). Then he invited the customer to the Wave. Created a message for the first step in user 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 got involved and wrote. that showing only the last three news on a home page is a bad idea, you need a component for pagination. For clarity, the customer inserted a gadget in the replica for sketching and quickly depicted the appearance of such a component.
The product owner agreed with the proposal and finished (without leaving the wave) the desired 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. For the reader’s judgment, a different perspective is proposed for a review of this process - from the point of view of the creation and evolution of artifacts (Artifact Flow) during the development of the project. We’ll also look at a practical approach for working with the “Requirements Collection” artifact using Google Wave and Google Docs.
An artifact is a man-made object. In a first approximation, the program code and documents written by programmers can be called artifacts. With a more thorough approach, we can significantly expand the range of examples and include emails, fragments of chats, and even drafts by a flamaster on the board, to artifacts.
In fact, the sequence of creation / modification of artifacts and their content is critical to the health of the project. Of particular importance, from my point of view, are collectively created artifacts.
Artifact flow diagrams.
Further, I suggest looking at sketches of the life cycle of artifacts at three different stages in the development of the 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 generated, and, in fact, the artifacts themselves. Please note that in the Communication processes collective artifacts are born, and in Development - personal ones.
Why am I emphasizing the importance of collective artifacts? Because they are communication channels and information synchronizers between the customer (s) (s) and the executor (s) (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 "will not recognize" the "picture" that is in his head in the finished system. As a result, conflict is inevitable.
So, let's see the “slides” ...
Project Initiation Artifact Flow stage .
The scenario here is this: Sales did their part and we got a potential customer. At this stage, a person stands out in the company 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 between the project owner and the customer, the very first of the collective artifacts, Vision & User Story titles, is formed. This is a text document which describes the main idea of the project and its functionality in the form of short User Stories.
This is followed by an internal meeting where the project owner and project manager meet. The purpose of this meeting is to decide on the composition of the development team and, based on its capabilities, build a preliminary or preliminary plan. For example, in our team, we “model” the execution of User Stories using the Gantt with resources.
The stage ends with the coordination of the evaluation plan with the customer at the level of Sales-, financial- manager and other superiors (this is the moment of purchasing the service) and the official start of development.
Architectural Iteration Artifact Flow
The first iteration is architectural, during which layers of the future system are built, 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 submitted to the first large rally with the team. The purpose 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 a draft architecture. Next, tasks are assessed and distributed - infrastructural (to configure and configure something), prototypes (to verify that the architectural idea works), architectural (to connect an architecture component - for example, Web Services). Estimates of the time come from the team itself. As a result, a second artifact appears - the iteration plan.
The iteration plan and architectural draft enter the largest node in our diagram - into development. The development results are code, a list of bugs, and engineering artifacts, such as installation instructions.
It is interesting that against the background of the artifact-turnover of development, a second, no less important, is fulfilled: the collection of Requirements. This is an ongoing process as a result of which the overall view of the system is coordinated and detailed. Sometimes, as a result of detailing, the original general view itself changes. The requirements collection process itself can proceed in different ways, but its participants are always the project owner (our analyst) and the customer (or its technical consultant). The result of this process is the ever-evolving Draft Requirements. In the second part of the article I will show how you can use the Google Wave and Google Docs services to work on this artifact.
It is also important here to note that the Project Owner should already have created an informal backlog at this stage for the accumulation and prioritization of User Stories that fall into the next iteration. It was on them that he should concentrate on collecting requirements. This practice - collecting “forward” - goes from one iteration to another.
Functional Iteration Artifact Flow
This is the most important part of the project. During functional iterations, the product “grows”. As a rule (with us), development begins with an architectural iteration, and then several functional iterations go on until the project is released.
If we describe the flows of artifacts of such an iteration in general terms, then in addition to the development flow and requirements collection, a specification stream is added: the QA team, based on the Requirements collection and the list of User History names, writes short but comprehensive Test Cases. These Test Cases along with the iterative plan are the main driving artifacts during development.
Gathering Information with Google Wave and Google Docs
I want to dwell on the artifact of the requirements collection separately. This artifact is responsible for synchronizing the picture of the system’s functionality between all project participants. Our group got a lot of cones 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 programmer and the customer are well understood, they speak the same language at approximately the same level, they have the same mentality (use the same principles of Common Sense), the parts of the system that are discussed easily fit into memory (they are compact, and the system is usually small). In fact, such a case relates more to exceptions than to rules. Systems are built large and branched, the teams we have now distributed, with a different mentality, with different specializations, the world is multipolar, IMHO, this is good.
In my opinion, a 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 requirements accumulation process itself.
The wave consists of text and drawings. The figures represent page layouts of the system user interface. Text is a description of the layouts and logical flows 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 stupid cluttered space. We will discuss these rules in a couple of seconds.
Now about the layouts. At the moment, I think the best way to create them is with Google Document and its Drawing component. It is simple and reliable. The document is inserted into the wave using the iFrame gadget .
Now about the rules for building waves to collect requirements:
1. Separate User Stories are separate waves collected in a “wave” folder with the name of the project.
2. Layouts related to a particular page and its states are gathered together in a separate Google Docs folder with the name of the project. The names of these layouts include the name of the action or effect that they demonstrate. It should also be noted that each Google document has its own version system - therefore, do not duplicate versions of layouts with separate documents - this greatly simplifies the whole scheme.
3. Use one instance of the exact layout for one step of the User History. By exact layout, I mean a Google document. There can be many drafts. It’s convenient to use this gadget for sketches .
3. Inside the Wave has a clear structure: in separate messages there is a heading for the Wave that describes the general meaning of this User History, and then in separate messages the steps of this history follow.
Inside the history step, there are three sections in the form of Replies - the layout (Google document in iFrame), the text of the comments for the layout, and the text of the logical flows in this history step. These parts of the step are implemented as Replies so that they can be quickly closed - this is convenient for long and swirling Waves.
The advantages of this approach to organizing Waves are as follows:
1. Collection of requirements is easy to parallelize. If the project is voluminous, developers are easily included in the collection of requirements. The project owner simply creates the Waves with the first header message and shares them with the developers. Then the developers draw the layouts and discuss them with the customer directly.
2. Simplified and accelerated communication on the business domain during the sprint. If a programmer or QA-box has questions, he immediately asks them to the Wave.
3. The customer can quickly initiate a conversation at any point in the Requirements.
Example of collecting requirements for a simple User History
Consider some example of discussion and accumulation of requirements for such a story: a website visitor gets acquainted with the text of the home page and the news.
View screen shot of a wave, and then I will add a couple of comments. The development of this wave occurred in this way: the project owner created a wave called the corresponding user story. Then he added a message - a heading with common words on this story and the addresses of two gadgets (for convenience, so that they are always at hand). Then he invited the customer to the Wave. Created a message for the first step in user 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 got involved and wrote. that showing only the last three news on a home page is a bad idea, you need a component for pagination. For clarity, the customer inserted a gadget in the replica for sketching and quickly depicted the appearance of such a component.
The product owner agreed with the proposal and finished (without leaving the wave) the desired component on the exact layout and updated the text.
Let's discuss this.
Good luck