Agile Software Development: principles, patterns and practices--the 3rd chapter plan

3rd Chapter Plan

3.1 Initial exploration

At the start of the project, the developer will discuss with the customer about the new system to identify all the really important information. However, they do not attempt to determine all the characteristics. As the project progresses, customers are constantly discovering new features. The feature discovery process continues until the project is completed.

When an attribute is identified, it is broken down into one or more user stories, and these user stories are written on the index cards and the like. In addition to the name of the user story, there is no need to record anything else (such as login,add user,delete user or change Password). At this point, we do not attempt to record details. We just want something that reminds us of what we've been talking about these features.

The developers work together to estimate these stories. The estimate is relative, not absolute. We write some "points" on the story card to indicate the relative time required for the story. We may not be sure how much time a "dot" represents, but we know that the time required to achieve a 8-point story is twice times that of 4 points.

Exploration, decomposition and speed

Stories that are too big or too small can be difficult to estimate. Developers tend to underestimate big stories and overestimate small ones. Any story that is too big should be broken down into smaller pieces, and any story that is too small should be combined with other small stories.

For example, consider the following user story: "Users can safely deposit, withdraw, transfer activities." "It's a big story. It would be difficult to estimate it, and it would be inaccurate to be able to do so. However, we can break it down into some of the more easily estimated stories:

• Users can log in
• User can exit
• Users can deposit to their account
• Users can withdraw money from their account
• Users can transfer funds from their account to other accounts

When you split or merge a story, you should re-estimate it. The simple addition or subtraction of estimates is unclear. The decomposition or merging of users is entirely to make their size suitable for accurate estimation. Don't be surprised when an estimated 25-point story breaks down into a story with a few points totaling 30 points! The 30 point is a more accurate estimate.

Every week, we will achieve a certain number of stories. The sum of the estimates of these already realized stories is a measure called velocity. If the sum of the points of the stories we realized last week is 42, then our speed is 42.

After 3 or 4 weeks, we will be more aware of our average speed. We can use this average speed to predict how much work can be done in the next few weeks. In XP projects, tracking speed is one of the most important management tools.

At the beginning of the project, the developers were not very well aware of their speed. They have to give an initial guess, and in guessing they can do it any way they feel they will bring the best results. It doesn't need to be very accurate at this point, so they don't have to spend too much time on it. In fact, it's enough to be as good as a conservative intuition test (SWAG).

3.2 Release Plan

If you know the speed of development, customers will be able to understand the cost of each story and its business value and priority levels. As a result, customers can choose the stories that they want to complete first. This choice is not based solely on the priority level. Some important but costly stories can be deferred and implemented first, while some of the less important, but much cheaper, stories are realized first. Such choices fall within the scope of business decisions. It is up to the business people to decide which stories will give them the best benefit.

Developers and customers agree on the project's first release time, usually after 2-4 months. Customers pick the stories they want to implement in the release and roughly determine the order in which the stories are implemented. Customers must choose the number of stories to implement based on their current development speed. Because the development speed is not accurate at the beginning, so the selection is also sketchy. But the accuracy of the Test selection is not very important. When the development speed becomes accurate, you can adjust the release plan.

3.3 Iteration Plan

Then, developers and customers decide on the iteration scale, typically 1-2 weeks. Similarly, the customer chooses the story in the first iteration they want, but cannot choose more stories that do not match the current development speed.

The order of realization of user stories during iteration belongs to the technical decision category. Developers implement these stories in the most technically meaningful order. They can be implemented serially, complete with one at the completion of the next, or they can share these stories and then develop them in parallel. This is entirely up to the developer to decide.

Once the iteration begins, the customer can no longer change the story that needs to be implemented during the iteration. In addition to the stories that developers are implementing, customers can arbitrarily change or reschedule any other story in the project.

Even if all user stories are not implemented, the iteration ends on a previously specified date. They will sum up the estimated values of all the realized stories and calculate the development speed of this iteration. This speed is used to schedule the next iteration. The rule is simple: the development speed that is used for each iteration of the plan is the development speed that was measured in the previous iteration. If the team completed 31 story points in a recent iteration, they should plan to complete 31 points in the next iteration. Their development speed is 31 points per iteration.

This speed feedback helps keep the schedule synchronized with the team's actual situation. If the team improves on the opposite side of expertise and job skills, the speed of development will be improved accordingly. If someone leaves the team, the speed of development will be reduced. If the system architecture evolves in a direction conducive to development, then the speed of development will increase.

3.4 Define "Done"

Unless all the acceptance tests pass, it is not possible to say that a story has been completed. These acceptance tests are performed automatically. Acceptance testing is written by customers, business analysts, quality assurance experts, testers, and even programmers, at the beginning of each iteration. These tests define the details of each story and are a decisive basis for judging how the story behaves correctly.

3.5 Mission Planning

At the beginning of a new iteration, developers and customers are co-customizing the plan. The developer breaks down the story into a development task. A task is a feature that developers can implement within 4-16 hours. The developers analyzed the stories with the help of the customer and enumerated all the tasks as much as possible.

These tasks can be listed on Flipchart, Whiteboard, and other handy media. The developers then sign the tasks they want to accomplish, estimating each task in random task points.

Development can sign any type of task. Database experts do not have to sign database-related tasks. If you prefer, a GUI-proficient person can also sign a database-related task. It does not seem to be able to do as much as possible, but there is a way to manage the situation. The benefits are obvious: the more developers understand the whole project, the healthier and more knowledgeable the team will be. We want the knowledge of the project to be communicated to every team member, even if the knowledge is irrelevant to their profession.

Each developer knows the number of task points completed in the last iteration, which is the developer's budget. No one is going to sign a point beyond their budget.

The selection of tasks continues until all tasks are assigned, or when all developers have exhausted their budget. If there are tasks that are not assigned, the developers will negotiate with each other and interact with the respective tasks based on their expertise. If this does not complete all tasks, then the developer asks the customer to remove some of the tasks or stories from this iteration. If all of the tasks have been assigned, and the developers still have budget space to do more, they will want to ask more stories from the customer.

When the iteration is halfway through, the team will convene a meeting. At this point in time, half of the stories scheduled in this iteration should be completed. If not, the team will try to reassign tasks and responsibilities that are not completed to ensure that all stories are completed at the end of the iteration. If the developer cannot implement this reassignment, then the customer needs to be informed. The customer can decide to remove a task or story from the iteration. At a minimum, customers can identify tasks and stories at the lowest priority level so that developers can avoid spending time on them.

For example, suppose that in this iteration the customer chooses 8 stories, a total of 24 story points. Also assume that these stories are broken down into 42 missions. At the midpoint of the iteration, we want to complete 21 tasks-12 story points. These 12 story points represent a must-have-complete story. Our goal is to complete the story, not just the task. If 90% of the tasks are completed at the end of the iteration, but none of the stories are complete, it will be a nightmare scenario. At the midpoint of the iteration, we want to see a story with half the story points being completed.

3.6 iterations

Every two weeks, the iteration ends and the next iteration begins. At the end of each iteration, the client is presented with a program that is currently running. Customers are required to evaluate the appearance, feel and performance of the project program. Customers will provide feedback in the form of new user stories.

Customers can often see the progress of the project. They can measure development speed. They can predict how quickly teams work, and can schedule high-priority stories in the early stages. In short, customers have all the data and control they need to manage them as they wish.

3.7 Tracking

For XP projects, tracking and management is the result of recording each iteration, and then using these results to test the content of the subsequent iterations.

3.8 Conclusion

Through iteration and release, the project has entered a predictable and comfortable development rhythm. Everyone knows what they are going to do and when to do it. Stakeholders see the progress of the project often and in real time. What they see is not a notepad full of pictures, full of plans, but a working software that can be touched and sensed, and they can provide their own feedback on the software.

Developers see a reasonable plan for development speed control based on their own estimates and measured by themselves. Developers choose to feel comfortable with their tasks and maintain high quality of work.

Managers always get data at each iteration. They use this data to control and manage projects. They don't have to impose, threaten, or plead with developers to express arbitrary, unrealistic goals.

It sounds like a nice, relaxing thing, but it's not. Using the data generated by the stakeholders is not always satisfactory, especially when it is just beginning. The use of agile development methods does not mean that stakeholders can get what they want. It simply means that they will be able to control the team to get maximum business value at the lowest cost.

Excerpt from: "Agile Software Development: principles, patterns and Practices (C # Edition)" Robert C.martin Micah Martin

Agile Software Development: principles, patterns and practices--the 3rd chapter plan