Together with two friends recently organized an event SEMP Sharon to discuss the possibility of working with Agile and CMMI. In discussing the demand for change management, there is doubt that agility is claiming to embrace change, but to guide the implementation of Scrum in and asked for demands in a Sprint is constant, this is not a contradiction of it? Here, I think on this issue, simply explore.
In fact, we say embrace change, does not mean that clueless changes, if changes in policy, is unable to ensure the success of the project. At this point, no matter what kind of methods are the same.
Traditional waterfall, because of its development approach is sequential, each step is established in the previous step basis, so the output of the previous step will require as accurate, complete, and when any change occurs late, whether it is design or demand, it will risk and cost of the entire project, a great impact, therefore, usually set strict approval process, assess the risks and costs to decide whether to accept the change, the more the latter, for a change of assessment the more stringent, the more difficult to accept change. In addition, the traditional development model, needs most is a detailed requirements document to manage, whether Use Case, or follow the standard IEEE 830, or ISO standards, there are very specific and detailed record demand, and many the demand is described from the perspective of system operation, many times, it is difficult for priority ranking. E.g:
- Phone should have a display screen
- Phone should have an input keyboard
- Phone should have a battery
- Phone should have a communication module
Such a requirement description, if we allow customers to decide which is more important and should not be done, the client will say, "These are the most important to me."
Scrum, agile as a practice, the demand management approach has the following advantages.
You can easily determine priority needs
Scrum, the demand is through user stories (User Story) and Product (Product Backlog) to maintain, is a from a user perspective, the feature list software should have hope, and that user stories organization is no hierarchy, so The user can easily determine which feature is more important to them, such as
- As a phone user, I want to be able to call
- As a phone user, I want to be able to send text messages
- As a phone user, I want to be able to replace the battery
- As a phone user, I want to be able to take pictures
- As a phone user, I want access to the Internet
In this way, the user is relatively easy to determine which function is more important, you can quickly determine the priority. In this way, the user can order according to the reality, flexible adjustment to achieve. Therefore, when any change needs arise, users only need to set the right priorities, you can apply the changes to the new system.
Conducive to the development of iterative
Scrum is by way of iterative development, and user stories and product inventory, and iterative development is a perfect fit. This demand management, can help the team more focused on the realization of the most important features in the technical solutions, do not rush to complete the design of all technical details to help them "delayed decision", the use of evolutionary design, and gradually achieve the most preferred technical solutions. In this way, it will lead the team based on the current needs identified through ongoing reconstruction, to get the best technical solution, not because of incomplete information in the case, but the rush to make a significant wrong technical decisions, which led to the late carried huge risks and costs of large-scale reconstruction brings. Therefore, this can be achieved from the technical aspect, to help teams more easily accept change.
Why, then, in a Sprint, we do not expect demand to change it? This is not contradictory to change and embrace it? As mentioned earlier, change is not allowed clueless embrace change, software development is a marathon is like long-distance running, the whole team needs to maintain a healthy rhythm, so as to smooth the finish line, if the rhythm is always constantly destruction, the project is difficult to ultimate success. Scrum and Sprint is the rhythm, if during a Sprint, the team is constantly new requirements interference, it is difficult to develop a feel for the entire team's ability, planning and estimating it will bring great project influences. Further, the length of Sprint often 2 to 4 weeks, that is to say, in response to the user change every 2 to 4 weeks, any new significant change in the maximum is 2 to 4 weeks after, and response can be implemented, this frequency, for most projects, is to meet the changing requirements of the user. Therefore, relatively stable demand in a Sprint is necessary, is also acceptable, if the user needs a higher frequency change, Sprint length can be shortened to improve the response speed.
In summary, any disorderly change, they need a certain way, into orderly change, it can contribute to the success of the project. Scrum by setting priorities, as well as the appropriate length of Sprint's reasonable to demand changes in demand will more orderly, through the development and evolutionary design iterations, to help the team more easily accept and adapt to change, therefore, Compared with the traditional waterfall development model, it is closer to the user, more flexible, lower cost and risk of change.
Reproduced in: https: //www.cnblogs.com/RelaxTintin/archive/2010/08/29/1811876.html