DF14900
"
Peter Bunus !
Department of Computer and Information Science !
Linköping University, Sweden !
marka@ida.liu.se
!

"
!
§   Background !
§   Extreme Programming (XP) !
§   Test-Driven Development (TDD) !
§   Refactoring !
§   Agile Softwrae Development; Agile Testing !
2

"
§   Extrem Programming explained, Embrace Change.
By Kent Beck
!
§   Test-driven Development, A practical guide.
By David Astels !
§   Agil testing: Tutorial Documentation; Software and Systems
Quality Conferences, 2006.
By David Evans, Scott Syme !
§   Fit for Developing Software, Framework for Integrated Tests
By Rick Mugridge, Ward Cunningham !
3

"
§
: !
Ÿ   the field of software development was in trouble , !
Ÿ   projects were delivered late , !
Ÿ   cost much more than was expected, !
Ÿ   and/or did not deliver the originally requested features, !
Ÿ   programming was often a stressful job !
Ÿ   programmer s were feeling overworked and underappreciated .
!
4

"
§   1994: "
Ÿ   Chaos Report (Standish Group) documented that only 16
!
procent of projects were completed successfully .
Ÿ   Follow-up report: what did successful projects look like?
They were low cost, short, and done by small teams .
!
§   1999:
!
Ÿ   eXtreme Programming ( XP ): programmering methodology ; developer in the center of process (+
!
customers); test-first philosophy .
Ÿ   eXtreme programming is one of the most revolutionary movements in the history of programming !
5

"
§   IT Project Success Rate 2009 !
Ÿ   32% all projects succeeding (delivered on time, on budget, with required features and functions) !
Ÿ   44 % were challenged (late, over budget, and/or with less than required futures and functions) !
Ÿ   24% failed (canceled prior to completion or delivery) !
§   Cost an Time Overruns 2008 !
Ÿ   Cost overrun (47% in 2006) – ( 54% in 2008) !
•   High point in cost overrun 2004 (84%) !
Ÿ   Time overruns (72% in 2006) – ( 79% in 2008) !
Ÿ   Features and Functions !
•   66% in 1998, 70% in 2000, 67% in 2002,
68% 2009 !
•   20% of the features and functions get used
(Standish Study) !
Statistical Data from the “Chaos
Summary 2009 Report” – The Standish
6 !

" Peter
Bunus,
Linköpin
§   IT Executive Managers opinion about why projects succeed !
y
SWEDE g
N !
1.
15.9% !
User Involvement !
2.
13.9% !
Executive Management Support !
3.
13.0% !
Clear Statement of Requirements !
4.
9.6% !
Proper planning !
5.
8.2% !
Realistic Expectations !
6.
7.7% !
Smaller Project Milestones !
7.
7.2% !
Competent Staff !
8.
5.3% !
Ownership !
9.
2.9% !
Clear Vision & Objectives !
10.
2.4% !
Hard-Working, Focused Staff !
11.
13.9 % !
Other !
TDDD29 IT Project
Management !
7 !

"
§   IT Executive Managers opinion about factors that cause projects to be challenged !
1.
12.8% !
Lack of User Input !
2.
12.3% !
Incomplete Requirements & Specifications !
3.
11.8% !
Changing Requirements & Specifications !
4.
7.5% !
Lack of Executive Support !
5.
7.0% !
Technology Incompetence !
6.
6.4% !
Lack of Resources !
7.
5.9% !
Unrealistic Expectations !
8.
5.3% !
Unclear Objectives !
9.
4.3% !
Unrealistic Time Frames !
10.
3.7% !
New Technology !
11.
23.0% !
Other !
TDDD29 IT Project
Management !
8 !

"
§
"
Ÿ   Test-First Development / Test-Driven Development
!
( TDD ): a core practice of XP .
Ÿ   TDD stands on ITs own !
§
"
Ÿ   Manifest for Agile Software Development
"
Ÿ   Agile testing "
9

"
"
§
Feature-Driven development (FDD)
"
§
"
Ÿ   Behavior Driven Development (or BDD ) It was originally
!
conceived in 2003 by Dan North as a response to Test
Driven development (TDD).
Ÿ   It is an Agile software development technique . !
10

"
- you complete one phase (e.g. planning) before moving on to the next phase (e.g. development).
!
- You can actually introduce some agility in the waterfall development process. !
- The focus is on delivering a sprint of work !
Picture fromTara Lee Whitaker !
www.agile101.net !
- focus on delivering fully-tested, independent, valuable, small features.
!
- focus on features as opposed to groups of features !
-you select, plan develop, test and deploy one feature (in its simplest form) before you select, plan, develop, test and deploy the next feature !
11 !

Extreme Programming (XP); Extreme Testing (XT) "
§   XP , a new programmering methodology (software development methodology), born in the 1999 by Kent
Beck.
!
§   XP was likely developed to support the adoption of programming languages such as Java, Visual Basic, and C#. These object-based languages allow developers to create large, complex applications much more quickly than the traditional languages such as C,
C++, Fortran, or Cobol.
"
13

Extreme Programming (XP); Extreme Testing (XT) "
The purpose of the
is to create
in short time frames
!
§
tends to work well for
development efforts in environments that have
and
!
where near-instant communication is possible
The primary difference of
is that it focuses on testing.
"
14

"
§   Planning and requirements !
§   Small, incremental release !
§   System metaphors* !
§   Simple design !
§   Continuous testing !
§   Refactoring !
§
§
§
§
§
Pair programming
40-hour work week
On-site customer
Coding standards
!
!
!
§   Collective ownership of the code !
Continuous integration
!
* !
Guide all development with a simple shared story of how the whole system works.
If you have a good metaphor in place, everyone on the team can tell about how the system as a whole works.
!
!
15

"
§   Unit testing: !
Ÿ   All code modules must have unit tests (defined and created) before coding begins
!
Ÿ   All code modules must pass unit tests before being released into production
!
§   Acceptance testing: "
Ÿ   Customers ( not together with developers) create the acceptance tests from user stories
!
Ÿ   More than one acceptance test may be needed for each user story !
16

JUnit : Creators: Kent Beck, Erich Gamma "
!
§   JUnit is a freely available open-source tool used to automate unit tests of Java applications in Extreme
!
Programming environments.
§   The creators, Kent Beck and Erich Gamma , developed
JUnit to support the significant unit testing that occurs in the Extreme programming environment.
!
!
There is more information on XP and XT at the: www.junit.org
!
17

"

"
!
§   TDD is a mechanism for designing software
"
§   TDD = TFD (test first design) + refactoring "
!
Refactoring "
Pass "
Write Test " Write Code " Run Test "
Fail "
19

"
List Class: "
§   Start with the simplest thing that could possibly work: empty list "
§   Write the test (and the code for that matter; executable test):
!
Public void testEmptyList() {
MovieList emptyList = new MovieList() assertEquals ( ” Empty list should have size of 0 ” , 0, emptyList.size())
}
§   To pass this test we need a MovieList class that has a size() method !
§   After Compile we get the error:
!
MovieList cannot be resolved or is not a type.
!
!
20

"
!
§   So create a new MovieList class: !
!
Public class Movie {
}
§   Compile again; another error:
!
!
!
The method size() is undefined for the type MovieList
§   Add a stub size() method
!
Public int size() { return 0;
}
§   Now it will compile !
!
21

"
!
TDD is difficult to use in some situations, such as graphical user interfaces or relational databases, where systems with complex input and output were not designed for isolated unit testing or refactoring.
!
22

"

"
"
!
Refactoring is the process of making changes to existing, working code without changing its external behavior.
In other words, changing how it dose it, but not what it does.
The goal is to improve the internal structure.
!
24

Refactoring is closely related to TDD in two ways: "
"
§   After doing the simplest thing possible to make a test pass, we refactor to clean up ,
!
Ÿ   mostly removing duplication we introduced getting the test to pass
(magic numbers or strings) !
Ÿ   refactor the code to the organization ʼ s coding convention "
Ÿ   To satisfy architectural, security constraints "
§   If we are practicing TDD, then we have the safety net of tests in place that allows us refactor with confidence , that refactoring is not damaging any existing functionality !
25

"
§   mostly removing duplication we introduced getting the test to pass
(magic numbers or strings), ” everything once and only once ”
(Jeffries et al.),
!
Don ʼ t repeat yourself ”
(Dave Thomas & Andrew Hunt).
§   refactor the code to the organization ʼ s coding convention
"
§   To satisfy architectural, security constraints.
"
§   when we perceive that the code and /or its intent isn ʼ t clear (ex. choose better names for things, not out of the air).
!
§   code smells : refer to characteristics of code that indicate less than acceptable quality (ex comments, data class, duplicate code, large class,long method,...).
!
§   If we are practicing TDD, then we have the safety net of tests in place that allows us refactor with confidence , that refactoring is not damaging any existing functionality !
26

§   We need to have automated tests in place that will give us feedback as to whether we ʼ ve broken
!
anything as we are refactoring.
§   In small steps , running the tests after each one. That way we know exactly what caused the break : the last step we took. We must back it out and try again.
!
§   Use a good refactoring tool (jFactor, RefactorIt.
Eclipse, jBuilder) !
27

"

"
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 " process and tools "
"
Working software "
Customer collaboration
Responding to change "
"
"
" over over over "
"
" comprehensive documentation contract negotiation following a plan "
"
That is, while there is a value in the items on the right, we value the items on the left more !
"
Kent Beck !
Mike Beedle !
Arie van Bennekum !
Alistair Cockburn !
Ward Cunningham !
Martin Fowler !
!
!
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern !
!
Brian Marick !
!
!
!
2001, the above authors !
Robert C. Martin !
Steve Mellor !
Kent Schwaber !
Jeff Sutherland !
Dave Thomas !
!
29

"
TDDD29 IT Project
Management !
30 !

"
§   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. !
§   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. !
TDDD29 IT Project
Management !
31 !

"
§   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. !
§   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. !
§   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. !
32 !

The foraging analogy
Agility is taking many small steps, gathering as you go "
§   An agile project is like foraging for food in a forest "
§   Your objective is reached by many small steps "
§   You must know where to look "
Ÿ   But planing every step is pointless "
§   You can (and should!) start with the low-hanging fruit "
§   You should know what is good to eat "
Ÿ   So you can make choices about what is worth collecting "
§   You can taste new things "
Ÿ   If they ʼ re bad, spit them out and move on !
§   You can stop at any time "
Ÿ   You decide when you have enough in the basket "
Source: QSQ Tutorial Agil Testing, Dave Evans and Scott Syme !
33

"
§   Lean : lean manufacturing concepts ( drived from Toyota) applied to software development !
§   Scrum : lightweigh management framework !
§   Crystal : lightweight set of development practices !
§   eXtreme Programmin (XP) : rigorous set of practices designed to keep both the code and team agile !
§   Dynamic System Development Method ( DSDM ) !
§   Feature-Driven Developmen (FDD) "
34

"
§   Lean and Scrum are project-centric in that they provide managers with tools to monitor , prioritize , and control projects without specifying anything about how the software is built.
!
!
§   Crystal and eXtreme Programmin (XP) are developer-centric in that they provide a set of good practices for a development team and less for a project manager.
!
§   One common combination : XP + Scrum !
35

Typical process framework "
Review working practices "
High level "
planing "
Identify next " priority feature "
Implement " feature "
Deliver to " the customer "
Wrap up & "
celebrate "
36

"
!
Principles: "
§   Eliminate waste !
§   Amplify learning !
§   Decide as late as possible !
§   Deliver as fast as possible !
§   Empower the team !
§   Build integrity in !
§   See the whole !
!
Tools: "
§   feedback !
§   iteration !
§   cost of delay !
§   testing !
§   refactoring !
§   ....
!
Source: Mary poppendieck, TomPoppendick. Lean Software development: an Agile
Toolkit.
!
37

" Peter
Bunus,
Linköpin g
Universit y
SWEDE
N !
TDDD29 IT Project
Management !
38 !

•   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. Teams self-organize 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 it for another sprint.
!

"
!
•   Microsoft !
•   Yahoo !
•   Google !
•   Electronic Arts !
•   Lockheed Martin !
•   Philips !
•   Siemens !
•   Nokia !
•   IBM !
•   Capital One !
•   BBC !
•   Intuit !
•   Nielsen Media !
•   First American Real Estate !
•   BMC Software !
•   Ipswitch !
•   John Deere !
•   Lexis Nexis !
•   Sabre !
•   Salesforce.com
!
•   Time Warner !
•   Turner Broadcasting !
•   Oce !

"
§   Commercial software !
§   In-house development !
§   Contract development !
§   Fixed-price projects !
§   Financial applications !
§   ISO 9001-certified applications !
§   Embedded systems !
§   24x7 systems with 99.999% !
uptime requirements !
§   the Joint Strike Fighter !
•
Video game development !
•
FDA-approved, life-critical systems !
•
Satellite-control software !
•
Websites !
•
Handheld software !
•
Mobile phones !
•
Network switching applications !
•
ISV applications !
•
Some of the largest applications in use !

"
24 hours !
Sprint goal !
Return !
Sprint backlog !
Return !
!
Gift wrap !
!
Cancel !
!
Product !
backlog !
Coupons !
Sprint !
2-4 weeks !
Potentially shippable !
product increment !

"

"
§   Scrum projects make progress in a series of
“sprints” !
Ÿ   Analogous to Extreme Programming iterations !
§   Typical duration is 2–4 weeks or a calendar month at most !
§   A constant duration leads to a better rhythm !
§   Product is designed, coded, and tested during the sprint !

"
Requirements !
Design !
Code !
Test !
!
!
Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.
!

"
!
"
§   Three questions each team member answers: !
1.
What have you done since the last scrum?
!
2.
What do you plan to do before the nest scrum?
!
3.
Wha is getting in the way?
!
46

"
"
§   The lead designer and two to seven other developers in a large room or adjacent rooms, !
§   using information radiators such as whiteboards and flipcharts, !
§   having easy access to expert users , !
§   Distractions kept away, !
§   deliver running, tested, useable code to the users every month or two ( quarterly at worst ), !
§   reflecting and adjusting their working conventions preiodically.
!
!
!
Source: Alistair Cockburn, Crystal Clear .
!
47

!
"
§   Adapt : Embarace change. Give up on ” managing ” or
” controlling ” !
§   Get feedback : Test early, test often. Everyone tests.
Customer ” accepts ” .
!
§   Delivery value : Do important features first. Reduce waste.
Redusce overhead, reduce rework.
!
§   Collaborate : co-locate team members. Whole team thinking. Get close to the customer.
!
§   Communicate : Information radiators. Big visible charts.
Daily standup meeting.
!
§   Continuously : Short timeboxes ( ” iterations ” or ” sprints ” ) !
48

"
§   Background !
§   Extreme Programming (XP) !
§   Test-Driven Development (TDD) !
§   Refactoring !
§   Agile Softwrae Development; Agile Testing !
49