Date post: | 14-May-2015 |
Category: |
Education |
Upload: | thomas-weinberger |
View: | 395 times |
Download: | 1 times |
Everything Old is New Again…
A look at repurposing existing tools to new uses…
April 12, 2023
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 2
Agenda
Some level setting, What does “Agile” mean?
A focus on SCRUM and its elements Using RequisitePro for SCRUM Elements What worked well… What didn’t work so well
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 3
What is Agile?
Methods and Techniques Organizational Keys How do we compare?
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 4
Agile is… A State of Mind… A concept – a set of techniques
Social engineering Project Principles Tactics for accomplishing speed and agility
Versus Methodologies that promote Agile techniques SCRUM Crystal OPENUP RUP / AUP LEAN Development DSDM
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 5
Agile is not… “Code and fix” An excuse not to document An excuse not to model An excuse to short-change quality An excuse to ignore enterprise concerns
(Architecture / Governance)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 6
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value: Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
(source: http://agilemanifesto.org/)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 7
Principles Behind the Agile Manifesto
We follow these principles: Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 8
Principles Behind the Agile Manifesto (2)
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 9
Principles Behind the Agile Manifesto (3)
Business people and developers must work together daily throughout the project.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 10
Principles Behind the Agile Manifesto (4)
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 11
Is Our Methodology Agile? How do you measure up to the principles in
the Manifesto? How many of the practices do you regularly
engage in? Are we Agile?
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 12
MYTH: Agile is a methodology
Lots of people claim “We‘re doing Agile!”
What they (hopefully) mean is we’re using agile practices in our project and we’re following “fill in the blank with your favorite” methodology
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 13
Teamwork Ground rules...
Think IterativelyCompromiseCollaborateAdd ValueNegotiate
Be Results Oriented
Help Stop the Churn
Drive for Decisions
Take Ownership
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 14
SCRUM Introduction
Scrum is an empirical Agile project management framework used to deliver increments of high value to the customer iteratively
Scrum relies on self organizing, empowered teams to deliver the product increments
It also relies on a customer, or Product Owner, to provide a team with a list of desired features using business value as the priority mechanism.
A Scrum is a mechanism in the sport of rugby for getting an out-of-play ball back into play
The term was adopted in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi to describe hyper-productive development.
Jeff Sutherland developed the Scrum process in 1993 while working at the Easel Corporation
Ken Schwaber formalized the process in the first published paper on Scrum at OOPSLA 1995
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 15
Scrum Roles, Artifacts and Meetings
Scrum defines roles, artifacts and meetings that provide a framework for the high value increments to be developed.
Roles There are three roles in a Scrum project:
The Product Owner (or customer) owns the product and prioritizes the list of desired features.
The ScrumMaster owns the process and ensures that teams remain unhindered and productive.
The cross-functional Team self organize to build the product.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 16
Scrum Roles, Artifacts and Meetings(2)
Artifacts Scrum defines three artifacts that the roles
interact with during the life of the project: The Product Backlog is a prioritized list of
desired features. The Sprint Backlog is a prioritized list of
tasks that the team have identified for the current Sprint (iteration).
The Increment of Product Functionality which is delivered at the end of each Sprint.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 17
Scrum Roles, Artifacts and Meetings(3)
Meetings There are four meetings, or collaboration
points, that are used during each Sprint: Sprint Planning allows the team to elect
what work they will be taking on for the Sprint.
The Daily Scrum allows the team to review the status of the Sprint and adapt to discoveries.
The Sprint Review gives the Team an opportunity to show the Product Owner the increment of product functionality.
The Sprint Retrospective allows the team to provide feedback and adapt the process.
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 18
The SCRUM Process…
Epics to User Stories…
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 19
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 20
SCRUM Team Product Backlog
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 21
SCRUM Team Sprint Backlog
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 22
SCRUM Team Sprint Backlog(2)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 23
How the Sprint Backlog is Normally Conveyed…
How the Sprint Backlog is Normally Conveyed… (2)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 24
How the Sprint Backlog is Normally Conveyed… (2)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 25
So what works…
Human Glue Spreadsheets don’t match boards Spreadsheets don’t match each other Traceability not provable Yet… the right work gets done
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 26
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 27
Translate to Requisite Pro…
Here is a Demonstration of usage… Lets look at the Epics that contribute to
the Product Backlog Here’s the Product Backlog Now, Lets look at the Sprint Backlog
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 28
Things that Work Well
Traceability Business Process to Epics
Epics to User Stories User Stories to Test First Design Tests
Prioritizing Business can plan ahead sprints Mix Match Velocity Points
(Velocity – the speed at which the team builds)
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 29
Things that Work Well(2)
Support for Daily Stand-ups Note “progress” on SPRINT mini-SDM
Waiting Development QA Done
Quick response to changing project priorities Simple changes to Progress or Sprint or
Backlog values by anyone
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 30
Things that Work Well (3)
Communication with Business Customer Metrics reports ReqWeb access for remote users Access to what’s happening on a sprint Opportunity to add Functional level
tests
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 31
Things That Don’t Work Well
Calculating Stuff Team Velocity
No way to facilitate this inside the product skin
Could be an interesting programmed add-on Traceability
Is still tedious Still only links two levels together Leg bone connected to thigh bone reports
difficult
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 32
Questions
If you need to reach me or have questions: Tom Weinberger
The Nimblestar Group, Inc www.nimblestar.com Tel. 312-805-0470 Fax. 815-838-9896 [email protected] [email protected] Come join me on LinkedIn
FYI – If you are attending the 2009 Rational Software Conference…
Kurt Bittner (CTO of Ivar Jacobson, Consulting, Inc.) and I are giving a joint presentation:
“Software Development Worst Practices: Cautionary Tales from the Front”
Please join us for a slightly humorous look at Worst Practices – kind of a take off on Tom Wolfe’s book “The Right Stuff” – Well, we are going to cover “The Wrong Stuff”!
04/12/23Tom Weinberger - Nimblestar -
AZRUG March 2009 33
34
IBM Rational Software Conference 2009
NPPM01
Software Development “Worst Practices”: Cautionary Tales From the Front
Kurt BittnerCTO - Americas, Ivar Jacobson International
Tom WeinbergerGeneral Manager, The Nimblestar Group, Inc
© 2009 IBM Corporation34