Agile Software Development (Part II)

Agile Software Development (Part II)

Netreptile recommendation []
Source: zdnet
By Brian swan
 

The last article in the next series of Agile Software Development MethodsArticleWe will discuss how the development team interacts with customers and how they can be involved in the development process.

In the previous series of agile software development, we learned how developers practice and technical advantages can significantly improve the quality. In this article, we explored the Development Group practices and how to build a development group with the highest efficiency, and focused onCodeCompile the standard, continuous integration, and general language used to describe the system. Now let's look at the outermost ring-one team practice, which includes developers, testers, and customers-and helps better coordinate business and IT.

Coordinate business and IT-"unified group" Practice
The Unified Team in Agile Software Development refers to the agile development team and all stakeholders to form a team for a common goal. Although every member of the group must focus on specific tasks, the Group prefers open, sincere, and frequent communication, rather than secretly operating.

The Unified Team emphasizes that developers should make technical decisions and customers should make business decisions. This is consistent, without exception. High level of communication, such as daily meetings and project radiation (discussed in the middle Article), will help increase communication and continue to ensure frequent feedback in a timely manner.

This concept is required to bring together all the elements of agile development.

Create background and obtain requirements-Step 1
Before you start agile development, you can obtain requirement information from customers, businesses, and users. They are the people who define requirements. As the business side plays a crucial role in these practices, they must fully understand what their roles are in the agile development environment and what they can do. To make it run fast, it is certainly necessary to carry out seminars and other training work.

When explaining agile development, you need to clarify the following important advantages to business personnel:

1. Yes. At any time, change its perspective on the minimum cost.
2. Ability to adjust and respond to feedback from the market or other places.
3. Know the status of the project at any time and have the foreseeable ability.
4. Be able to participate in project guidance from the business perspective.

Important Success Factors

• Understanding-the customer will need somethingProgramTraining can precisely understand the roles they play in the agile development environment.
• Communication-it is very important to communicate with customers in the form of collaboration. This should be done throughout the project process, but it is especially important to stick to it from the very beginning.

Customer/business side intervention-Step 2
In this step, we will let the customer participate in the development process through the user's materials and acceptance tests. Many customers may have little or no experience in writing user materials or performing acceptance tests. Once again, they may need a certain degree of discussion or training to help them complete their tasks.

User Material
The user's material is "demand ". Each clip represents how the system solves a specific problem. However, the user's materials are not a large number of documents that meet the requirements, but are written on the material card. They should be used as an introduction to further discussion.

What do good materials need?
Customers, or more common customer groups, need to get together and write user materials for the system on a 5x3 clip card. We use the property management software company 3q solutions as an example:

"The customer wants to obtain a rule engine that can be used to evaluate the customer's economic status ."

The problem with this requirement or material is too unclear. The correct rule for compiling the clip card should be invest:

Independent(INdependent)
Negotiable (NEgotiable)
Vertical (VErtical)
Evaluable (EStimable)
Short (SMall)
Testable (TEstable)

The material is obviously unpredictable (it is difficult to determine how long it takes), not short (this is a very huge and ambiguous requirement ), it is also not testable (how can you perform test-driven development on requirements like this ?). So the following material may be better:

"The customer wants to analyze the amount of cash that the customer currently has-too much, too little, or just right (depending on the cost of lifestyle and attitude towards risk )."

This material meets all the requirements of our invest standards. When this material is discussed in groups (customers and developers), it clearly conveys what customers really need is the ability to describe the rules engine. The preceding example shows that a rule is sufficient to describe your needs. This is the method for compiling materials. What is important is that the materials need to lead to a dialogue, and the dialogue provides a clear and true understanding of the customer's needs.

Communication
Remember, the dominant idea of materials is that they are the reference for further conversations. The reason is that the language is based on the above context and understanding. Without questions or conversations, we will not be able to understand the subtle meanings. Let's take the phrase Matt Cohn's buffalo as an example. Buffalo is a city in New York, United States. It is a synonym for bison and the verb "deception and confusion. Therefore, such a sentence "buffalobuffalobuffalobuffaro" is true. Or, more specifically, the bison from Buffalo (NY) intimidate and confuse other buffalo) from bufaro, New York ). Therefore, if there is no context, this phrase is meaningless.

On the back of each clip card, we recommend that you quickly write down any ideas about acceptance testing.

Acceptance Test
The acceptance test is used to guarantee:

1. The customer is confident that the given features can meet the design requirements.
2. Give developers a clear stop point: when the acceptance test is passed, the function is implemented.

In Agile development projects, the customer needs to write all acceptance tests. At the initial stage of the project, developers may need to work closely with the customer to compile the acceptance test content.

We also recommend that you use the at framework and automate testing. Developers need to be able to repeatedly run these tests as they keep adding new features.

The following is an example of the at framework related to the above materials.

Interactive Test (example)

// Overview
"Analyze customers' cash receipts and payments and check whether they hold too much cash at given lifestyle costs and attitudes toward risks ."

// Set customer data
Userclicksmainmenu	Menufinancialobjectives
Userinputstext	Financialobjectivesattitudetorisk	"3-low return-long-term investment"
Userclicksmainmenu	Menucurrentbalancesheet
Userinputstext	Currentbalancesheettotalcash	30000
Userclicksmainmenu	Menufinancialobjectives
Userinputstext	Financialobjectiveslifestylecost	25000
// Cash rules
Testvalueoftext	Analyseobservation	"If you are worried about risks, you should maintain a cash balance of no more than #12,500 ."
Testvalueoftext	Analyserecommendation	"Consider transferring #17,500 from a cash account to an asset that can be invested ."
Testvalueoftext	Analysedestination	"Query the total investment principal and transfer the excess cash to the cash storage account unless you purchase assets in cash ."
// Hyperlink
Userclickscontrol	Analysedestination
Testvalueoflabel	Workareatitle	"Total principal amount"

At 3q, the customer prepares Acceptance Tests and submits them to the development team every day in the form of electronic texts. All acceptance tests are provided to the development team as soon as possible. This process works well with the test-encoding-reorganization cycle, which allows developers to run the test-encoding-reorganization cycle after the acceptance test fails, then re-deliver the new acceptance test until you see it passed the test. Each clip can undergo multiple acceptance tests. However, once all the acceptance tests are passed, the implementation of the material/function is complete.

Important Success Factors

• Don't be in a hurry-user materials are not easy to write, so you have plenty of time to spend on the first batch of tasks and discussion tasks.
• Acceptance Test help-developers may need to write acceptance tests with customers from the very beginning. Dedicated time for this task-good acceptance testing will bring unusual gains.
• Ask for help-if you realize that you and your group need help-ask for help, don't hesitate!
• Existing Requirement documents-if there is an existing requirement document, you need to use it as the basis for compiling materials. Remember to treat these documents as "new" materials. They are the main points of the dialogue, rather than the fixed requirements.

Planning-Step 3
Agile Software Development has three levels of planning:

1. High-level release planning: all releases of the project are planned here. This usually depends on the scale of the project, but the multiple releases of some projects require high-level planning for a period of up to 18 months.
2. Release planning: the first release is planned here. The interval between each release is three months.
3. It is used to plan the work for the next two weeks.

The purpose of this level-3 planning process is to allow the team to first understand the final goal, but to plan only what they now know-the work for the next two weeks.

Release Planning
In the high-level release planning stage, customers and developers should discuss and understand the entire system together. The existing requirement document can be used to start this discussion. Ideally, the customer should include a clip card containing most of the content to be released during the meeting.

During the meeting, developers will need to estimate the difficulty of the materials. This can be performed during or after the meeting. We recommend that each person compare their respective materials and combine the materials with the same difficulty. Then, you can start to estimate the difficulty of each clip by using the most simple to the most difficult measurement scale ). The group uses different methods to score the materials, with 1 to 10 points for each difficulty.

Now the customer can plan the initial high-level release plan. High-level release does not have to be very accurate, and priority and estimation do not need to be very reliable, but it will set the direction for the group and provide sufficient information for decision-making.

Small release
Next, the customer needs to take the estimated clip card and arrange the importance of the clip in priority based on the latest release. Customers need to consider what they need the system to implement immediately, so these materials will constitute an upcoming release. These estimates have become very important here, because developers have estimated what they can accomplish at a given release time, which is usually three months.

Short-term release cycles can ensure a close feedback loop, and allow the team to focus on important objectives closely related to the project.

Repeated Planning
Now the group needs to develop specific plans for the next two weeks. Once again, customers must prioritize materials and describe the features they want to see in the next two weeks.

These clips are then put into two weeks of repetition (release ). The most recent repeat will be the immediate work of the Group. They will deliver this repeat, that is, full effort, software testing, and feedback (planning for the next two weeks), and then start again. If the material is completed before it is repeated, developers will ask for more materials. If all the materials seem to be incomplete, developers and customers should move the materials to the next repetition or split the materials appropriately.

Two weeks of repetition allow customers to take full advantage of any changes. For example, 3q met a customer with great foresight. He realized that a piece of material planned to be put in the post-release phase would actually need to be completed earlier. After a brief discussion, the Group replaced the materials that were equally valuable in the current release with the materials requested by the customer. What is the cost? It's just a 15-minute conversation.

The above is a brief overview of how the planning process works. We recommend that you seek help or guidance for this part of the process, because it may be very complex and careful adjustments are often necessary.

This recurring process and release plan should be conducted every two weeks and every three months, respectively.

Important Success Factors

• Carry out an inspection in the recurrence period-check the progress of the Group in the recurrence period as early as possible.
• This is probably the case-the Group's initial estimates often go far-developers are all optimizers! However, as the group progresses to new iterations and adapts to this process, the estimation (accuracy) or speed (how fast the group works) will be determined.
• Yesterday's weather-once it was done over and over again, you would have a rough idea of the speed of the group-how much material can be delivered in two weeks. This is the speed and team workload recognized by the Group in the next two weeks. As the group matures and has the ability to make better estimates, your speed may increase and your speed will be fixed at a stable speed.
• Speed is not a stick-it is a reminder to managers-it is not a great rod used to throw a group; it is used to measure natural fluctuations.
• Decision-the customer or customer group must have the decision-making power or be able to make decisions quickly, especially when changes or adaptation are needed.
• Willingness to negotiate-the customer must be willing to negotiate on the scope and other content. This is the way agile development works: negotiate the scope to prioritize the most valuable functions of the business.

Planning in Agile development may be very difficult, so we suggest you seek some help and take the time to complete it.

Efficiency-Step 4
One of the best ways to gradually promote this process is to have a customer at the site. The best way is to let the customer sit in the group members so that they can answer questions at any time. This limits developers' casual guesses. In addition, on-site customers can answer developers' questions as quickly as possible.

This does not mean that the customer does not engage in his "Daily" work, but that he is prepared to answer questions around him. Communication may be affected even though the first floor is located. Face-to-face conversations instead of phone or email.

Obviously, setting up on-site customers is not always possible. In this case, he should be as close as possible to the group and attend daily meetings as much as possible. If this is not possible, you need to invite him to daily meetings at least once a week to ensure your feedback and communication are ongoing.

The increase in feedback and communication also requires regular review. This should be done at the end of each iteration. Such a review gives the group the opportunity to sit down and check the previous review, find out what is done well, what is not done well, and what can be done better next time. Three questions should be asked: what is useful? What's useless? What should we improve?

Important Success Factors

• On-site or not? -On-site customers may have some problems, but if possible, they still need to find a on-site customer. If it cannot be implemented, we need to find other ways to ensure regular communication.
• Review-review at the end of each review as a discipline and put people's ideas into action.

We have just carefully discussed the outer ring of the first chart in the previous article, which requires the consent of all participants. This may be the most difficult part of agile development, but it can coordinate business and it well, and its benefits are not only valuable to business but also to it.

Summary
Although in this series, we explain how to develop agile software development capabilities step by step, and how to build the confidence of developers from inside and outside, and then the confidence of the development team, finally, the confidence of the entire project team. From the experience of exoftware, we can see that many companies have chosen to build a complete agile development lab team for a project, and have a mentor to help the team. If you choose this method, you will have the advantage of directly obtaining benefits from all practices, and it will give you valuable information to adapt to your specific environment. To put it simply, there are:

Experimental Agile Software Development-how to get started
What is your goal?
Evaluating where you are and where you want to go is crucial for using agile development practices. This will help you determine the expected results you want to achieve. External evaluations are often useful because they provide an objective perspective for your problem.

Experimental agile development
Although we have already described a method for developing agile development, guiding agile development in a project is the best way to understand whether the agile development method applies to your organization, it also helps you understand how to adapt to your environment.

Measurement Standard
If possible, you need to collect measurement standards before the project starts or before implementing agile development practices. Even if these standards come from other projects, they will help provide a good benchmark for the content that has been implemented by agile development. You also need to ensure that some high standards of measurement can be collected during and after agile development projects. Defect rate, test content or deadline are good and easy to use high standards of measurement.

Environment
Understanding that experimental agile development may require some changes to your physical environment. For example, an open workspace is a necessary condition for agile development to take effect.

Seek help
External help can guide your lab project to success. It helps you understand where you are and where you want to go, and shows you how to adapt agile development to your environment to achieve this goal. In addition, external help ensures that the Group is focused on answering issues that may occur at any time. It is also important to establish a business case to apply agile development to other engineering groups.

Brian Swan is an agile development instructor at exoftware. He has rich experience in Agile development technology and management. He once led many groups to successfully switch to agile development, it also uses agile development ideas and practices to train developers and managers. His work in exoftware and agile development has led him to many companies and has had a sustained and positive impact on his development team. Brian's previous experience also includes being a lecturer at Napier University, who teaches software development and human-machine interaction. Brian can contact us by email.