Transcript Section 1 - Colorado School of Mines

Section 1
Agile Development
Agile Development
Principles, patterns and practices are
important, but it’s the people that
make them work. – Alistair Cockburn
 We cannot manage teams of
programmers as if they were systems
of components driven by a process.
People are not “plug-compatible
programming units.” – Kent Beck

Chapter 1
Agile Practices
Why Agile?
unpredictability
repeated
error
No practice
slipping
schedules
So we become afraid of repeating past mistakes, and build a process.
And some of it is good, but the process grows.
I can slow a
team as well as
any defect!
process
process
huge
cumbersome
process
Manifesto for Agile 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.
Agile Principles
The following 12 principles differentiate a set of agile
practices from a heavyweight process:
1.
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.


2.
Sloan management report: less functional the initial
delivery, the higher the quality in the final delivery
Another finding: The more frequent the deliveries, the
higher the final quality.
Welcome changing requirements, even in late
development. Agile processes harness change for
the customer’s competitive advantage.

This book explores principles and patterns of OO design
to facilitate this type of flexibility
Agile Principles, continued
Deliver working software frequently, from a
couple weeks to a couple months, with a
preference to the shorter time scale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals. Give
them the environment and support they need,
and trust them to get the job done.
3.
4.
5.

If the office environment is an obstacle to the team,
change it. If certain process steps are an obstacle,
change them.
Agile Principles, continued
6.
7.
8.
The most efficient and effective method of conveying
information to and within a development team is face-toface conversation.

Documents may be created, but no attempt to capture
all project information in writing.
Working software is the primary measure of progress.

Don’t measure by what “phase” the project is in or how
much documentation has been produced. Project is 30%
done when 30% of necessary functionality is working.
Agile process promote sustainable development. The
sponsors, developers and users should be able to maintain
a constant pace indefinitely.

Avoid burnout, shortcuts, debacle. Don’t get too tired.
Run at fast but sustainable pace.
Agile Principles, continued
Continuous attention to technical excellence and good
design enhances quality.
9.

Simplicity – the art of maximizing the amount of work not
done – is essential.
10.

Always take the simplest path that is consistent with the
system goals.
The best architectures, requirements, and designs emerge
from self-organizing teams.
11.

12.
High quality is the key to high speed. Must keep the software
as clean and robust as possible. If you make a mess, clean it
up before you finish for the day.
Responsibilities are not handed to individuals from outside.
Team determines best way to fulfill responsibilities.
At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
Agile Processes
SCRUM (www.controlchaos.com)
 Crystal (crystalmethodologies.org)
 Feature Driven Development
 Adaptive Software Development (ADP)
 Extreme Programming

Chapter 2
Overview of
Extreme Programming
Practices of Extreme Programming

Customer Team Member





Person or group who defines and prioritizes features
Marketing specialist, User rep, paying customer, etc.
Best case: work in same room
If can’t be close, find someone who can
User stories





For planning purposes, don’t need details, just need
enough about requirement to estimate it
Customer writes a few words on an index card
Developer creates estimate
Story is a planning tool
Story represents an ongoing conversation between
developer and customer, doesn’t capture all details
XP Practices, continued

Short cycles
 XP
delivers working software every two weeks,
called an iteration. At the end of each iteration,
system is demonstrated to stakeholders to get
their feedback.
 Iteration plan. Collection of stories selected by
customer according to budget established by
developers. Can be any number of stories as
long as estimate does not exceed budget.
 Developers cut stories into tasks and develop
tasks in order that makes most technical sense.
 Customer cannot change stories once an
iteration has begun.
XP Practices, continued

Short cycles…
 Release
plan. Maps out next 6 iterations
or so. Usually 3 months of work.
Represents a major delivery that can
usually be put into production.
 Customer can change content of release
at any time (cancel stories, write new
stories, change priority of story).
XP Practices, continued

Acceptance tests
 Details
about user stories are captured in
form of acceptance tests. Should be
written preceding or concurrent with
implementation of story. Written in
scripting language so can be automated
(we’ll use JUnit).
 Once an acceptance test passes, it is
added to a body of passing acceptance
tests and is never allowed to fail again.
Maintains system in valid state.
XP Practices, continued

Pair Programming





All production code is written by pairs of programmers
working together at the same workstation. One member
drives the keyboard and types the code. The other
member watches, looking for errors and improvements.
The roles change frequently.
Pair membership changes at least once per day so that
every programmer works in two different pairs each day.
Over the course of an iteration, each team member should
have worked with every other member of the team, and
they should have worked on just about everything going
on in the iteration.
This dramatically increases spread of knowledge through
the team, including specialties.
Studies suggest that this does not reduce the efficiency of
the team (you might be surprised by that!), but it
significantly reduces the defect rate (no surprise there!)
XP Practices, continued
chapter 4

Test-driven development
 First
write a unit test that fails (because
functionality not in place)
 Then write code that makes test pass
 Test cases and code evolve together
 Iteration between writing test cases and
code is very rapid
 Test cases facilitate refactoring
 Encourages independent modules
XP Practices, continued



We’ll be using Subversion,
this will be true!
Collective Ownership
 A pair has a right to check out any module and
improve it.
Continuous Integration
 Programmers check in code and integrate
several times per day.
 Nonblocking source control is preferred (> 1
person may have module checked out). May
need to communicate when check in and merge
versions.
Sustainable Pace
 Called 40-hour work week in XP Explained. No
OT except in last week of release. Be alert!
XP Practices, continued

Open Workspace




Work in open room with workstations on tables. Walls
covered with status charts, task breakdowns, UML
diagrams etc.
Pairs are within earshot of each other.
This “war room” environment may increase productivity by
a factor of two.
Planning Game



chapter 3
Business people decide how important a feature is
Developers determine budget, based on how much they
were able to get done in the last iteration/release.
Customer chooses stories whose count totals to, but does
not exceed, that budget.
XP Practices, continued

Simple Design






Narrow focus to consider stories planned for current
iteration.
Don’t worry about stories to come. Migrate design from
iteration to iteration.
Don’t start with infrastructure. Only add when story
forces issue. Customers often can’t see infrastructure!
Consider the Simplest Thing That Could Possibly Work.
You Aren’t Going to Need It (YAGNI). Put in infrastructure
only if have very compelling evidence that putting it in now
will be more cost effective than waiting.
Once and Only Once. Also known as Don’t Repeat
Yourself (DRY). XPers don’t tolerate code duplication.
Wherever they find it, they eliminate it. Find code that was
copied with a mouse a plopped down in multiple places –
eliminate them!
abstractions, TEMPLATE METHOD pattern, etc.
XP Practices, continued
chapter 5

Refactoring
 Code
tends to rot. As features are added and
bugs are fixed, code structure degrades.
 Refactoring makes tiny transformations that
improve the structure of the system without
affecting its behavior.
 After each transformation, run tests to ensure
nothing broken.
 Should be done continuously, not at end of
project. Goal: keep the code as clean, simple and
expressive as possible.
Chapter 3
Planning
Helpful Resources
Planning Extreme Programming, Kent
Beck and Martin Fowler
 Extreme Programming Installed, Ron
Jeffries, Ann Anderson and Chet
Hendrickson
 Extreme Programming Explored,
William Wake

What is a Release?
A version of the system with enough
new features to be valuable to the
customer
 Probably represents 1 – 3 months
work
 Release planning can take one to a few
weeks

Release Planning Game
Customer*
Write a Story
“Too big”
“Don’t know how”
Estimate Story
Split Story
smaller stories less risky
> 3 weeks, split!
Programmer
Sort Stories
Spike Story
may need “quick”
exploration – couple days
max, throw-away code
Declare velocity
Choose Scope
*Only customer should write story, only when they want a feature
A Story
must provide value to
customer, not neat new
technology
Story: Story Title
Several sentences to describe a desired feature.
Cite or attach
supporting
materials
This is a promise to discuss a feature, not a
complete description of it.
Estimate: Added by programmer, in “story points”
Put story on index card: keep
terse (the shorter the better),
easy to manipulate
Ideal programmer weeks, most
important to indicate relative lengths
Release Planning
Could have
Customer sorts
Should have
Estimated
Stories
Must have
NOTE: Customer can change stories,
accept new date, get a different team…
but can’t change the estimates!
Customer chooses
stories
Velocity determined by
project history. At the
end of 1 iteration, how
many story points were
finished? That’s the
velocity.
Sample Stories
Vision
Produce a system for faculty to
track student progress
a little vague, but it’s a starting
point….
Story: Query=>Details
Given a query, return a list of all matching
items. Look at the details of any items.
Store the information in any format.
Programmers can’t estimate,
tell customer it’s too big
Split Story
Story: Query
Want to query by student name, student
username or by course
Story: Details
Want to know student name, email, GPA,
major, minor, student ID, courses taken
and grades received.
Story: Any format
Requires
“spike”
Want to store information as csv or as
xml or in .rtf
More stories
Programmers may prompt customers for stories, for example about
types of systems, performance, etc.
Story: Portable
System should be usable on a PC. Running
under Unix would be a plus.
Programmer may add constraint to the story when doing the estimate
(customer must agree). Or story could be split, so parts could be
estimated separately (e.g., PC vs Unix)
Story: Portable (Java)
System should be usable on a PC. Running
under Unix would be a plus.
More on Stories
Stories should be independent. Can
then be built in any order (can’t always
achieve, of course).
 Each story must be testable.
 Should trace acceptance test to story,
not underlying class.
 Writing stories should be iterative.
Write between 2-5 stories then stop.
Estimate stories, conversation between
programmers and customer.

More quick examples

Show hotels
 Show

hotels near a place
Book a hotel
 Book
a hotel. Charge to credit card and check
credit card validity. Send confirmation.

Cancel hotel reservation
 Find
reservation, cancel it, apply credit on credit
card, send confirmation

Bank Overdraft
 When
a transaction causes a customer’s account
to go into overdraft, transfer money from the
overdraft protection account, if any
Task Planning






Developer breaks stories into tasks
Task is something one developer can implement in
4-16 hours
List of tasks is created on flip chart, whiteboard,
etc.
Developers sign up for tasks, estimate in task
points
Each programmer’s budget is the number of points
he or she implemented in the last iteration. Sign
up for only that many in this iteration.
Task selection continues until all tasks assigned or
all developers at budget. May need to remove
tasks. If all tasks assigned and have more budget,
ask customer for more stories.
Halfway Point


At halfway point, team holds meeting. At
this point, half the stories should be
complete. If not, reapportion if possible. If
not possible, inform customer. May pull
task or at least determine which task has
lowest priority.
Nightmare scenario: Get to end of iteration
with 90% of tasks complete but no stories
complete. At halfway point, want to see
completed stories.
Conclusion

Using an agile method does not mean
that the stakeholders will get what
they want. It simply means that they’ll
be able to control the team to get the
most business value for the least cost.
Chapter 4
Testing
Important ideas to ponder…

The act of writing a unit test is more
an act of design than of verification

It is also more an act of
documentation than of verification
Test Driven Development
Design idea 1: refuse to implement a
function in our program until there is
a test that fails because that function
isn’t present.
 Design idea 2: Incrementally add
functionality to our programs by first
writing failing tests that assert the
existence of functionality and then
make the test pass.

Advantages






Can test every single function in the
program
If make changes, know if inadvertently
break existing functionality
Writing test changes point of view. Must
design functions to be convenient to call.
Forces program design to be testable.
Tests must stay current (unlike
documentation)
Tests show other programmers how to
interact with system
Hunt the Wumpus (Test-First Design)
public void testMove()
{
WumpusGame g = new WumpusGame();
g.connect(4,5,”E”);
g.setPlayerRoom(4);
g.east();
assertEquals(5, g.getPlayerRoom());
}
Design observations:
• no use of a Room class
• connecting rooms is the intent, no room
class needed
• for this test, could use integers to
represent the rooms
• The act of writing tests first is an act of
discerning between design decisions.
Intentional programming:
write the test the way you
want it to read. State your
intent in a test before you
implement it, making it as
simple and readable as
possible.
Other benefits:
• Could easily write the named
methods from this spec.
• This is a compileable and
executable document that
describes the program.
Dive Table JUnit Testing


Careful dive planning is important because bodies
absorb nitrogen during dives.
For a single depth dive you can calculate the
maximum allowable time (no-decompression limit,
NDL) based on depth of dive.


For calculations involving repetitive dives, the
pressure group must be determined.


What is the NDL for a dive to 50 feet? Answer: 80
minutes
What pressure group would be obtained for a dive to 59
feet for 30 minutes? Answer: L
Project requirement was 5 tests. Students
indicated that testing was very helpful, with most
teams producing ~15 tests.
Acceptance tests


Unit tests are white-box tests that verify the
individual mechanisms of the system
Acceptance tests are black-box tests that
verify that the customer requirements are
being met
 May
be written by customer or QA
 Should be programs
 Written in scripting language

Temptation to do acceptance tests
manually. Inadvisable – need pressure to
decouple business logic from GUI.
Acceptance Tests, continued
Convenient to save acceptance tests in
simple text files
 Acceptance test framework must parse
text file, separate system transactions
from acceptance-test directives

AddEmp 1429 “Robert Martin” 3215.88
Payday
Verify Paycheck EmpId 1429 3215.88
Payroll
Acceptance Test
How to create Payroll system to accept input from both GUI and Acceptance
Framework? One solution: XML.
Acceptance Tests, continued
<AddEmp PayType=Salaried>
<EmpId>1429</EmpID>
<Name>Robert Martin</Name>
<Salary>3215.88</Salary>
</AddEmp>
and to verify, payroll can create check as XML:
<Paycheck>
<EmpId>1429</EmpID>
<Name>Robert Martin</Name>
<GrossPay>3215.88</GrossPay>
</Paycheck>
This design decoupled transaction
sources from payroll application.
It has also decoupled the paycheck
printing mechanism from the payroll
application.
These are good architectural
decisions.
Chapter 5
Refactoring
Pay attention…
The only factor becoming scarce in a
world of abundance is human
attention. --Kevin Kelly, Wired
 This chapter is about paying attention
to what you are doing and making
sure you are doing your best.
 It is about the difference between
getting something to work and getting
something right.

Refactoring



Martin Fowler – “… the process of changing a
software system in such a way that it does not
alter the external behavior of the code yet
improves its internal structure. “
But what about “if it’s not broken, don’t fix it?”
Consider 3 functions of a software module:
1.
2.
3.

Function it performs while executing
To afford change (because almost all modules change,
should make change as simple as possible)
To communicate to its readers. No “undue mental
gymnastics.”
If it doesn’t do all 3 functions, it’s broken and
needs fixing.
But how? Most of this book is dedicated to that question!
Some potential keys*

Duplicated code
 Within
the same class
 Shared in several classes

Long methods
 Must

use good method names!
Large class
 Indicator:

too many instance variables
Large parameter lists
*Refactoring: Improving the Design of Existing Code, Fowler
More keys
switch statements
 temporary field (when not used)
 comments

 thickly
commented code may be an
indication that code is bad. Solution is
not to eliminate comments! Refine the
code!
Exercise

Do Refactoring Exercise
Chapter 6
A Programming Episode
Exercise

With a partner, read chapter 6 and
answer the Reading Questions