Agile Development - University of Texas at...
Transcript of Agile Development - University of Texas at...
Today’s Agenda
• Agile Development
– Extreme Programming (XP)
– SCRUM
1UTA - CSE 5324, Ali Sharifara
Agile Development
CSE 5324, Summer 2017
Outline
• What is Agile Development?
– The XP Process
– The Scrum Process
3UTA - CSE 5324, Ali Sharifara
What is Agile (Development)?
• A philosophy and a set of development
guidelines
– customer satisfaction, early incremental delivery,
minimal documentation, simplicity, small project
teams
– Active and continuous communication between
developers and customers
• What Do We Mean By “Agile?”
– In agile software development, “agile” tends to
mean “the ability to respond to change.”
4UTA - CSE 5324, Ali Sharifara
What is Agile (Cont.)
• The core ideas in Agile Development:
– Adaptive
– Iterative/incremental
– People-oriented
• Adaptive: Teams and the process should be flexible
in the presence of “rapid-fire change”.
• Iterative and incremental :Agile Development
produces working products in stages – a growing set
of “completed and working software”.
• People-oriented: Team organization and processes
will support good people, who are the most important
ingredient to project success.
5UTA - CSE 5324, Ali Sharifara
Cost of Change
6UTA - CSE 5324, Ali Sharifara
Unpredictability
• Difficult to predict which software
requirements will persist and which will
change
• Difficult to predict how much design is
necessary before construction
• Difficult to predict the progress of software
development activities
7UTA - CSE 5324, Ali Sharifara
Iterative development
8UTA - CSE 5324, Ali Sharifara
One way to organize agile development is using short iterations:
Today Ship date
Each iteration step:
• Has some analysis, some design, some
coding, some integration and testing
• delivers some kind of internally or externally
usable functionality – intermediate demos or
deliveries are possible!
Internal
prototype
(demo 1)
Customer-
viewable
prototype
(demo 2)
Customer-
viewable
prototype
(demo 3)
iteration
planning
iteration
1
iteration
2
iteration
3
iteration
4
iteration
5
iteration
6Each iteration
might be 2-4 weeks
Question:
• Could we do a “demo”
every iteration?
• Absolutely yes! The
team gets practice at
doing system integration
Main characteristics of Agile
Development
9UTA - CSE 5324, Ali Sharifara
Agile Development as a “software development framework” says:
– keep things small
– deliver partially-completed software frequently
– talk to the customer often
– write more code than documentation
– everyone on the team learns together
Work for future
iterations
Work for the
current
iteration
Every 2-4 weeks, produce a
new shippable product
Agile Practices
10UTA - CSE 5324, Ali Sharifara
Product Backlog Items
for current Sprint
Agile principles
9. Continuous attention to
technical excellence and
good design enhances agility.
10. Simplicity--the art of
maximizing the amount of
work not done--is essential.
11. The best architectures,
requirements, and designs
emerge from self-organizing
teams.
12. At regular intervals, the
team reflects on how to
become more effective, then
tunes and adjusts its behavior
accordingly.
5. Build projects around
motivated individuals. Give
them the environment and
support they need, and trust
them to get the job done.
6. The most efficient and
effective method of conveying
information to and within a
development team is face-to-
face conversation.
7. Working software is the
primary measure of progress.
8. Agile processes promote
sustainable development. The
sponsors, developers, and
users should be able to
maintain a constant pace
indefinitely.
1. Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
2. Welcome changing
requirements, even late in
development. Agile processes
harness change for the
customer's competitive
advantage.
3. Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
4. Business people and
developers must work together
daily throughout the project.
Requirements process
12UTA - CSE 5324, Ali Sharifara
• There is no “standard way” to gather requirements in Agile development
– Could be a normal “Software Requirements Document”
– But it is better to be more lightweight
One way to collect requirements:
Start with a much slimmer “initial
requirements document” at the beginning of
the iterations…
Initial list of overall “systems capabilities”
– written in the form of User Stories
Plus a section containing “global non-
functional requirements” (security,
reliability, performance, usability, etc.)
The list of system capabilities and global
non functional requirements will be the first
draft of the SRD.
In each iteration, elaborate a small set of
the functional requirements (the high-
priority behavior)
This avoids creating a big requirements
document too soon
A good strategy is to delay writing most of
the “fine details” in the requirements until
the iteration when they will be
implemented
Why? Because you will have learned
more about the problem…
For some key requirements, create some
acceptance tests at the same time as you
write the requirements
How hard is it to be Agile?
• “Don’t do Agile, be Agile”
– Just doing “development in iterations” isn’t enough
• Agile Development is about:
– Keeping the process lightweight
– Making real progress in each iteration
– Communicating – face-to-face when possible
– Actively gathering customer input – early and
often
– Being willing to make minor changes to your
process
13UTA - CSE 5324, Ali Sharifara
Agile Modeling
• The purpose of modeling is primarily to
understand, not to document
– Discover, understand, and share the
understanding
• A collection of values, principles, and
practices for modeling software in an effective
and light-weight manner
– Model with a purpose, use multiple models, travel
light, content is more important, know the models
and the tools, adapt locally
14UTA - CSE 5324, Ali Sharifara
Agile Modeling Practices
• Don’t model to all or most of the software
design.
• Use the simplest tool possible.
• Don’t model alone, model in pairs.
• Create models in parallel.
• Use “good enough” simple notation while
sketching.
• Know that all models will be inaccurate.
• Developers should do the modeling for
themselves.
15UTA - CSE 5324, Ali Sharifara
Agile Methodologies
16UTA - CSE 5324, Ali Sharifara
Extreme Programing (XP)
17UTA - CSE 5324, Ali Sharifara
What is
Extreme Programming (XP) ?
• “XP is a lightweight methodology for small-to-
medium-sized teams developing software in
the face of vague or rapidly changing
requirements.” (Kent Beck,1990’s)
• An agile development methodology
• Created by Kent Beck in the mid 1990’s
• A set of 12 key practices taken to their
“extremes”
• A mindset for developers and customers
18UTA - CSE 5324, Ali Sharifara
XP - The 12 Practices
1. The Planning Game
2. Small Releases
3. Metaphor
4. Simple Design
5. Testing
6. Refactoring
7. Pair Programming
8. Collective Ownership
9. Continuous Integration
10. 40-Hour Workweek
11. On-site Customer
12. Coding Standards
19UTA - CSE 5324, Ali Sharifara
1-The Planning Game
• Planning for the upcoming iteration– Predicting what will be accomplished by the due date
– Determining what do to next
• Uses stories provided by the customer
• Technical persons determine schedules, estimates,
costs, etc
• A result of collaboration between the customer and
the developers
• There are 2 key planning steps in XP addressing
these 2 question– Release Planning
– Iteration Planning
20UTA - CSE 5324, Ali Sharifara
1-The Planning Game
• Advantages: – Reduction in time wasted on useless features
– Greater customer appreciation of the cost of a
feature
– Less guesswork in planning
• Disadvantages:– Customer availability
– Is planning this often necessary?
21UTA - CSE 5324, Ali Sharifara
2-Small Releases
• Small in terms of functionality
• Less functionality means releases
happen more frequently
• Support the planning game
22UTA - CSE 5324, Ali Sharifara
2-Small Releases Cont.
• Advantages:
– Frequent feedback
– Tracking
– Reduce chance of overall project slippage
• Disadvantage:
– Not easy for all projects
– Not needed for all projects
– Versioning issues
23UTA - CSE 5324, Ali Sharifara
3-Metaphor
• The oral architecture of the system
• A common set of terminology
24UTA - CSE 5324, Ali Sharifara
3-Metaphor Cont.
• Advantages:
– Encourages a common set of terms for the
system
– A quick and easy way to explain the system
• Disadvantages:
– Another opportunity for miscommunication
– The system is often not well understood as a
metaphor
25UTA - CSE 5324, Ali Sharifara
4–Simple Design
• K.I.S.S.
• Do as little as needed, nothing more
26UTA - CSE 5324, Ali Sharifara
4-Simple Design Cont.
• Advantages:– Time is not wasted adding superfluous
functionality
– Easier to understand what is going on
– Refactoring and collective ownership is made
possible
– Helps keeps programmers on track
• Disadvantages:
– What is “simple?”
– Simple isn’t always best
27UTA - CSE 5324, Ali Sharifara
5-Testing
• Unit testing and Functional Tests
• Test a little, code a little – Test-first programming
• Tests give confidence in the system
• Tests give courage to change the system
28UTA - CSE 5324, Ali Sharifara
5-Testing Cont.
• Advantages:
– Unit testing promote testing completeness
– Test-first gives developers a goal
– Automation gives a suite of regression test
• Disadvantages:
– Automated unit testing isn’t for everything
– Reliance on unit testing isn’t a good idea
– A test result is only as good as the test itself
29UTA - CSE 5324, Ali Sharifara
6-Refactoring
• Goal : Optimal code design
• Changing how the system does something
but not what is done
• Improves the quality of the system in some
way
30UTA - CSE 5324, Ali Sharifara
6-Refactoring Cont.
• Advantages:– Prompts developers to proactively improve the
product as a whole
– Increases developer knowledge of the system
• Disadvantages:
– Not everyone is capable of refactoring
– Refactoring may not always be appropriate
– Would upfront design eliminate refactoring?
31UTA - CSE 5324, Ali Sharifara
7-Pair Programming
• Two Developers, One monitor, One
Keyboard
• One “drives” and the other thinks
• Switch roles as needed
32UTA - CSE 5324, Ali Sharifara
7-Pair Programming Cont.
• Advantages:– Two heads are better than one
– Focus
– Two people are more likely to answer the following questions:
• Is this whole approach going to work?
• What are some test cases that may not work yet?
• Is there a way to simplify this?
• Disadvantage:– Many tasks really don’t require two programmers
33UTA - CSE 5324, Ali Sharifara
8-Collective Ownership
• Goal : Spread responsibility to whole team
• The idea that all developers own all of the
code
• Any developer can change any code if
needed to complete a task
• Enables refactoring
34UTA - CSE 5324, Ali Sharifara
9-Continuous Integration
• Goal : reduce the impact of adding new
features
• New features and changes are worked into
the system immediately
– Merge tasks and tests to whole as soon as they
are completed
35UTA - CSE 5324, Ali Sharifara
9-Continuous Integration Cont.
• Advantages:
– Reduces to lengthy process
– Enables the Small Releases practice
• Disadvantages:
– The one day limit is not always practical
– Reduces the importance of a well-thought-out
architecture
36UTA - CSE 5324, Ali Sharifara
10 – 40-Hour Week
• The work week should be limited to 40 hours
per week
• Regular overtime is a symptom of a problem
and not a long term solution
37UTA - CSE 5324, Ali Sharifara
10 – 40-Hour Week Cont.
• Advantages:
– Most developers lose effectiveness past 40-Hours
– Value is placed on the developers well-being
– Management is forced to find real solutions
• Disadvantages:
– Some may like to work more than 40-Hours
38UTA - CSE 5324, Ali Sharifara
11 – On-Site Customer
• Just like the title says!
• Acts to “steer” the project
• Gives quick and continuous feedback to the
development team
– E. g. Product owner in scrum
39UTA - CSE 5324, Ali Sharifara
11 - On-Site Customer Cont.
• Advantages:
– Can give quick and knowledgeable answers to real
development questions
– Makes sure that what is developed is what is needed
– Functionality is prioritized correctly
• Disadvantages:
– Difficult to get an On-Site Customer
– The On-Site customer that is given may not be fully
knowledgeable about what the company does
– May not have authority to make many decisions
– Loss of work to the customer’s company
40UTA - CSE 5324, Ali Sharifara
12 – Coding Standards
• All code should look the same
• It should not possible to determine who
coded what based on the code itself
41UTA - CSE 5324, Ali Sharifara
12 – Coding Standards Cont.
• Advantages:
– Reduces the amount of time developers spend
reformatting other peoples’ code
– Reduces the need for internal commenting
– Call for clear, unambiguous code
• Disadvantages:
– Degrading the quality of inline documentation
42UTA - CSE 5324, Ali Sharifara
XP – Advantages
• Built-In Quality
• Overall Simplicity
• Programmer Power
• Customer Power
• Synergy Between Practices
43UTA - CSE 5324, Ali Sharifara
XP – Disadvantages
• Informal, little, or no documentation
• Scalability
• Contract Issues
• Misconception on the cost of change
• Tailoring
44UTA - CSE 5324, Ali Sharifara
Scrum
45UTA - CSE 5324, Ali Sharifara
Scrum in 100 words
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Our teams self-
manage to determine the best way to deliver the
highest priority features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance for another iteration.
46UTA - CSE 5324, Ali Sharifara
Characteristics
• Self-organizing teams
• Product progresses in a series of month-long
“sprints”
• Requirements are captured as items in a list
of “product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile
environment for delivering projects
• One of the “agile processes”
47UTA - CSE 5324, Ali Sharifara
How Scrum Works?
48UTA - CSE 5324, Ali Sharifara
Sprints
• Scrum projects make progress in a series of “sprints”
– Analogous to XP iterations
• Target duration is one month
– +/- a week or two• But, a constant duration leads to a better
rhythm
• Product is designed, coded, and tested during the sprint
49UTA - CSE 5324, Ali Sharifara
Sequential vs. Overlapping Dev.
50UTA - CSE 5324, Ali Sharifara
Requirements Design Code Test
No changes during the sprint
51UTA - CSE 5324, Ali Sharifara
SprintInputs Tested Code
Change
Plan sprint durations around how long you can commit to keeping change out of the sprint
Scrum Framework
• Roles :
– Product Owner
– Scrum Master
– Team
• Ceremonies:
– Sprint Planning
– Sprint Review
– Sprint Retrospective
– Daily Scrum Meeting
• Artifacts :
– Product Backlog,
– Sprint Backlog,
– Burndown Chart
52UTA - CSE 5324, Ali Sharifara
Product Owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the
product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as
needed
• Accept or reject work results.
53UTA - CSE 5324, Ali Sharifara
The Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and
practices
• Removes impediments
• Ensure that the team is fully functional and
productive
• Enable close cooperation across all roles and
functions
• Shield the team from external interferences
54UTA - CSE 5324, Ali Sharifara
Scrum Team
• Typically 5-10 people
• Cross-functional
– QA, Programmers, UI Designers, etc.
• Members should be full-time
– May be exceptions (e.g., System Admin, etc.)
• Teams are self-organizing
– What to do if a team self-organizes someone off
the team??
– Ideally, no titles but rarely a possibility
• Membership can change only between sprints
55UTA - CSE 5324, Ali Sharifara
Ceremonies
• Sprint Planning Meeting
• Sprint
• Daily Scrum
• Sprint Review Meeting
56UTA - CSE 5324, Ali Sharifara
Spring Planning Meeting
57UTA - CSE 5324, Ali Sharifara
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal
Parts of Sprint Planning Meeting
• 1st Part:
– Creating Product Backlog
– Determining the Sprint Goal.
– Participants: Product Owner, Scrum Master,
Scrum Team
• 2nd Part:
– Participants: Scrum Master, Scrum Team
– Creating Sprint Backlog
58UTA - CSE 5324, Ali Sharifara
Pre-Project/Kickoff Meeting
• A special form of Sprint Planning Meeting
• Meeting before the begin of the Project
59UTA - CSE 5324, Ali Sharifara
Sprint
• A month-long iteration, during which is
incremented a product functionality
• NO outside influence can interfere with the
Scrum team during the Sprint
• Each Sprint begins with the Daily Scrum
Meeting
60UTA - CSE 5324, Ali Sharifara
Daily Scrum
• Parameters– Daily
– 15-minutes
– Stand-up
– Not for problem solving
• Three main questions:1.What did you do since the last meeting?
2.What obstacles are you encountering?
3.What do you plan to accomplish by the next team meeting?
61UTA - CSE 5324, Ali Sharifara
Daily Scrum
• Is NOT a problem solving session
• Is NOT a way to collect information about
WHO is behind the schedule
• Is a meeting in which team members make
commitments to each other and to the Scrum
Master
• Is a good way for a Scrum Master to track the
progress of the Team
62UTA - CSE 5324, Ali Sharifara
Scrum FAQs
• Can Scrum meetings be replaced by emailed status
reports?
– No!
• Entire team sees the whole picture every day
• Create peer pressure to do what you say you’ll do
63UTA - CSE 5324, Ali Sharifara
Sprint Review Meeting
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or
underlying architecture
• Informal
– 2-hour prep time rule
• Participants
– Customers
– Management
– Product Owner
– Other engineers
64UTA - CSE 5324, Ali Sharifara
Product Backlog
• A list of all desired work (features and
requirements ) on the project
– Usually a combination of
• story-based work (“let user search and replace”)
• task-based work (“improve exception handling”)
• List is prioritized by the Product Owner
– Typically a Product Manager, Marketing, Internal
Customer, etc.
65UTA - CSE 5324, Ali Sharifara
Product Backlog
• Requirements for a system, expressed as a
prioritized list of Backlog Items (requirements
or features).
• Is managed and owned by a Product Owner
• Spreadsheet (typically)
• Usually is created during the Sprint Planning
Meeting
• Can be changed and re-prioritized before
each PM
66UTA - CSE 5324, Ali Sharifara
Sample Product Backlog
67CSE 5324, Ali Sharifara
From Sprint Goal to Sprint Backlog
• Scrum team takes the Sprint Goal and
decides what tasks are necessary
• Team self-organizes around how they’ll meet
the Sprint Goal
– Manager doesn’t assign tasks to individuals
• Managers don’t make decisions for the team
• Sprint Backlog is created
68UTA - CSE 5324, Ali Sharifara
Sprint Backlog during the Sprint
• Changes
– Team adds new tasks whenever they need to in
order to meet the Sprint Goal
– Team can remove unnecessary tasks
– But: Sprint Backlog can only be updated by the
team
• Estimates are updated whenever there’s new
information
69UTA - CSE 5324, Ali Sharifara
Sprint Backlog
• A subset of Product Backlog Items, which
define the work for a Sprint
• Is created ONLY by Team members
• Each Item has it’s own status (To do, In
progress, Resolved, Verified and tested)
• Should be updated every day
70UTA - CSE 5324, Ali Sharifara
Sprint Backlog
• No more than 300 tasks in the list
• If a task requires more than 16 hours, it
should be broken down
• Team can add or subtract items from the list.
(Product Owner is not allowed to do it)
71UTA - CSE 5324, Ali Sharifara
Sample Sprint Backlog
72UTA - CSE 5324, Ali Sharifara
Sprint Burndown Chart
• Depicts the total Sprint Backlog hours
remaining per day
• Shows the estimated amount of time to
release
• Ideally should burn down to zero to the end of
the Sprint
• Actually is not a straight line
• Can bump UP
73UTA - CSE 5324, Ali Sharifara
Burndown Chart - Example
74UTA - CSE 5324, Ali Sharifara
Actual
Ideal
Release Burndown Chart
• Will the release be done on right time?
• X-axis: sprints
• Y-axis: amount of hours remaining
• The estimated work remaining can also burn
up
75UTA - CSE 5324, Ali Sharifara
Scrum Pros/Cons
• Advantages
– Completely developed and tested features in short iterations
– Simplicity of the process
– Clearly defined rules
– Increasing productivity
– Self-organizing
– Each team member carries a lot of responsibility
– Improved communication
– Combination with Extreme Programming
• Drawbacks
– “Undisciplined hacking” (no written documentation)
– Violation of responsibility
76UTA - CSE 5324, Ali Sharifara
Scrum
77UTA - CSE 5324, Ali Sharifara
Let’s Review Scrum again!
78UTA - CSE 5324, Ali Sharifara