Why does an iterative process make it easier to manage change? Is every agile process discussed in this chapter iterative? Is It possible to complete a project In lust one Iteration and still be agile? Explain your answers. An Iterative approach enables customers to evaluate regularly, provide feedback, and Influence the required changes.
(The software team manages change by focusing on a defined increment and postponing any changes until the next Increment). All agile processes are Iterative.If a project were completed In Just one Iteration It would not be agile because frequent software delivery Is a key characteristic of agile development. 3. 7.
Why do requirements change so much? After all, don't people know what they want? It is difficult to predict in advance which requirement will persist and which will change, It is difficult to predict how customer priorities will change as the project proceeds, and it is difficult for customers to verbalize their software needs until they see a working prototype. . 13. Does the 80 percent rule in and the time-boxing approach defined for AND achieve the same result? Yes.
In fact, the time-boxing method is suggested and used by many. It has been adopted by the , but should be used after the customer agrees to cut features and not quality with some situations. Chapter 4 Questions for Week 2 4. 2. Of the eight core principles that guide process (discussed In Section 4.
2. 1), which do you believe is most important? I think that principle 5 Is the most Important one because you are able to assess he risk, have a great team, manage change, adapt, and create a quality of work that will provide value for others when you establish mechanisms for good communication and coordination your team. . 7. Why is it necessary to "move on"? Sometimes if something it iterated continuously, people will not want to hear about it or do it again.
It can be very time consuming, thus moving on will allow for 4. 11 . What three "domains" are considered during requirements modeling? The three domains considered during requirements modeling are information, functions, and behavior.
