March 2009 Azrug Everything Old
•Download as PPT, PDF•
0 likes•339 views
Recycling Old Tools to New Uses… Some say everything old is new again. This is true with requirements management regardless of the type of project methodology you adopt. You have to identify them, gather them, prioritize them, and essentially manage them. The new agile methods like SCRUM require that for your projects you define, collect and manage your requirements just as you did before, but in new ways and new formats. So why not use proven tools and methods to do so? I will examine the benefits and shortcomings of managing requirements for an agile project method (specifically SCRUM) utilizing the Rational Requisite Pro tool. We will look at the opportunity to manage burn down lists and user stories as two of the important SCRUM process elements, and see how this “Old” tool can support “New” tricks.
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Similar to March 2009 Azrug Everything Old
Similar to March 2009 Azrug Everything Old (20)
Recently uploaded
Recently uploaded (20)
March 2009 Azrug Everything Old
- 1. Everything Old is New Again… A look at repurposing existing tools to new uses… June 22, 2009
- 18. The SCRUM Process… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 19. Epics to User Stories… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 20. SCRUM Team Product Backlog 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 21. SCRUM Team Sprint Backlog 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 22. SCRUM Team Sprint Backlog(2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 23. How the Sprint Backlog is Normally Conveyed… 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 24. How the Sprint Backlog is Normally Conveyed… (2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
- 25. How the Sprint Backlog is Normally Conveyed… (2) 06/22/09 Tom Weinberger - Nimblestar - AZRUG March 2009
Editor's Notes
- Note the emphasis on “Valuable Software” as a delivery objective Welcome changing requirements requires that early in a project you delay decision making by exploring the problem and the potential solutions rather than drilling down into a solution quickly. It is a balancing act. By attempting to attack the “breath” of a system problem rather than the “depth” you can defer making too many detailed decisions and mitigating the risk of locking into an incorrect or useless solution Another strategy – iterative delivery – get a quick feedback loop going through deliveries. Find out if you can “fail fast” if you are going to do so.
- So, what motivates you? Face to face – how do we do that if we have geographically distributed clients? What communications points do you have, and how often do you use them? OK, so here’s a challenge – how long has this project been underway, and how often have you delivered software by this point in time?
- How often do you visit with your clients? Again, what communications points or vehicles do you have and with what frequency or regularity do you use them? (ICG example – visit once a day whether I liked it or not) In order to maintain a constant pace indefinitely, you must practice delivery and measure “ velocity ” (A SCRUM TERM) to determine what you are capable of as a team. How do you measure “ velocity ”? # of requirements completed, Function Points, Use Cases delivered, # of defects removed, high risk requirements accomplished? Technical excellence – Risk based Architecture centered design and delivery – make a resilient and quality architecture implementation. Barry Beohm recommends all tasks not related to analysis and coding are overhead and waste… Deliver Valuable, Workable software to the customer.
- I ALWAYS recommend “be Practical and Pragmatic” Keep it Simple (KISS) – Don’t make a [problem more complex than it needs to be. How do you decide that? A Zen-like analogy – “how long does a piece of sting need to be?” Long enough to do the job – no longer.
- So, is our methodology agile or not? Let’s review the point again that there are actually a lot of “Agile” methodologies out there. Agile is a point of view, a means of organizing effort around certain principles and driving work based on those principles. What work gets driven, is hat we understand as a “Methodology”
- Summary: Many organizations struggle with how to capture and communicate requirements. While documents are still dominant, more agile approaches favor discussions and prototyping. In this presentation, an approach for starting with the simple "agile" backlog, and then applying other techniques as needed, is outlined and explained. Criteria for choosing techniques and strategies for blending techniques are highlighted. Examples and demonstrations will be used to illustrate the approach. Abstract: Attendees will come away with strategies for effectively blending a variety of different approaches to capturing and communicating requirements, including backlog entires (change requests, work items, and even defects), declarative requirements, use cases and scenarios, prototypes, business rules, and even test cases. An additional dimension, the level of detail to which the requirements need to be described, is also explored. In addition to documenting the requirements, strategies for reviewing and approving the requirements in an iterative lifecycle are discussed. Topics discussed include: - Capturing business needs and desired outcomes - Using the Backlog to capture requirements - The role of scenarios and the Use Case Model - The role of sketching and visualization to elicit and capture requirements - Capturing business rules - Using a domain model to capture data requirements - The role of declarative requirements - When and how to write fully-described use-case specifications - Working with requirements iteratively - Reviewing requirements and gaining agreement