Agile Development

1
Section 1

• Agile Development

2
Agile Development

• Principles, patterns and practices are important,
  but its 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

3
Chapter 1

• Agile Practices

4
Why Agile?
unpredictability
repeated error
No practice
slipping schedules
So we become afraid of repeating past mistakes,
and build a process.
I can slow a team as well as any defect!
And some of it is good, but the process grows.
process
process
huge cumbersome process
5
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.

6
Agile Principles

• The following 12 principles differentiate a set
  of agile practices from a heavyweight process
• Our highest priority is to satisfy the customer
  through early and continuous delivery of valuable
  software.
• 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 customers competitive advantage.
• This book explores principles and patterns of OO
  design to facilitate this type of flexibility

7
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.
• If the office environment is an obstacle to the
  team, change it. If certain process steps are an
  obstacle, change them.

8
Agile Principles, continued

• The most efficient and effective method of
  conveying information to and within a development
  team is face-to-face conversation.
• Documents may be created, but no attempt to
  capture all project information in writing.
• Working software is the primary measure of
  progress.
• Dont 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. Dont get too
  tired. Run at fast but sustainable pace.

9
Agile Principles, continued

• Continuous attention to technical excellence and
  good design enhances quality.
• 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.
• Simplicity the art of maximizing the amount of
  work not done is essential.
• Always take the simplest path that is consistent
  with the system goals.
• The best architectures, requirements, and designs
  emerge from self-organizing teams.
• 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.

10
Agile Processes

• SCRUM (www.controlchaos.com)
• Crystal (crystalmethodologies.org)
• Feature Driven Development
• Adaptive Software Development (ADP)
• Extreme Programming

11
Chapter 2

• Overview of
• Extreme Programming

12
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 cant be close, find someone who can
• User stories
• For planning purposes, dont 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, doesnt capture all
  details

13
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.

14
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).

15
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
  (well 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.

16
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!)

17
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

18
XP Practices, continued
Well 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 (gt 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!

19
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
• 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.

chapter 3
20
XP Practices, continued

• Simple Design
• Narrow focus to consider stories planned for
  current iteration.
• Dont worry about stories to come. Migrate design
  from iteration to iteration.
• Dont start with infrastructure. Only add when
  story forces issue. Customers often cant see
  infrastructure!
• Consider the Simplest Thing That Could Possibly
  Work.
• You Arent 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 Dont Repeat
  Yourself (DRY). XPers dont 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.
21
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.

22
Chapter 3

• Planning

23
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

24
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

25
Release Planning Game
Customer
Programmer
Write a Story
Too big
Dont know how
Estimate Story
Spike Story
Split Story
may need quick exploration couple days max,
throw-away code
smaller stories less risky gt 3 weeks, split!
Sort Stories
Declare velocity
Choose Scope
Only customer should write story, only when they
want a feature
26
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
27
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 cant change the
estimates!
Velocity determined by project history. At the
end of 1 iteration, how many story points were
finished? Thats the velocity.
Customer chooses stories
28
Sample Stories
Vision Produce a system for faculty to track
student progress
a little vague, but its a starting point.
Programmers cant estimate, tell customer its
too big
Story QuerygtDetails Given a query, return a
list of all matching items. Look at the details
of any items. Store the information in any format.
29
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 Want to store information as
csv or as xml or in .rtf
Requires spike
30
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.
31
More on Stories

• Stories should be independent. Can then be built
  in any order (cant 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.

32
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 customers account to
  go into overdraft, transfer money from the
  overdraft protection account, if any

33
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 programmers 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.

34
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.

35
Conclusion

• Using an agile method does not mean that the
  stakeholders will get what they want. It simply
  means that theyll be able to control the team to
  get the most business value for the least cost.

36
Chapter 4

• Testing

37
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

38
Test Driven Development

• Design idea 1 refuse to implement a function in
  our program until there is a test that fails
  because that function isnt 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.

39
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

40
Hunt the Wumpus (Test-First Design)
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.
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.

• Other benefits
• Could easily write the named methods from this
  spec.
• This is a compileable and executable document
  that describes the program.

41
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.
• What is the NDL for a dive to 50 feet? Answer
  80 minutes
• For calculations involving repetitive dives, the
  pressure group must be determined.
• 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.

42
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.

43
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.
44
Acceptance Tests, continued
ltAddEmp PayTypeSalariedgt ltEmpIdgt1429lt/EmpIDgt ltNam
egtRobert Martinlt/Namegt ltSalarygt3215.88lt/Salarygt lt/
AddEmpgt
and to verify, payroll can create check as XML
ltPaycheckgt ltEmpIdgt1429lt/EmpIDgt ltNamegtRobert
Martinlt/Namegt ltGrossPaygt3215.88lt/GrossPaygt lt/Paych
eckgt
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.
45
Chapter 5

• Refactoring

46
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.

47
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 its not broken, dont fix
  it?
• Consider 3 functions of a software module
• 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 doesnt do all 3 functions, its broken and
  needs fixing.

But how? Most of this book is dedicated to that
question!
48
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
49
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!

50
Exercise

• Do Refactoring Exercise

51
Chapter 6

• A Programming Episode

52
Exercise

• With a partner, read chapter 6 and answer the
  Reading Questions