Agile (Software Engineering Framework)),

Test Driven Development (Software Dev) ,

Scrum (Project management)
Travel, Transportation & Hospitality
Shweta Agarwal (164255 )
shweta.ag@tcs.com

This presentation is a brief introduction for Agile Methodology – Software

Engineering Framework, and 2 of its implementations – Test Driven Development &
Scrum.

1
Agenda
1 Agile Methodology

2 Extreme Programming

3 Test Driven Development

4 Scrum

11 May 2009

2
 Relationship
Agile Methodology

Project Management

Extreme Scrum
Programming

Project Implementation/Development

Test Driven
Development

11 May 2009

This is one way of visualizing the relationship among different agile methodologies
and their implementations.
That Agile is an adaptive methodology for faster development of software.
With Extreme programming as a concept base lining main principles for an agile
project.
Test Driven Development is a practice of XP, and is a project development strategy.
Whereas Scrum is an implementation of Agile from project management
perspective.

3
Agenda
1 Agile Methodology

2 Extreme Programming

3 Test Driven Development

4 Scrum

11 May 2009

4
 Agile - quickness, lightness, and ease of movement
• A lightweight conceptual framework for undertaking software engineering projects,

• Agile methods attempt to minimize risk and maximize productivity by developing software in short
iterations and de-emphasizing work on secondary or interim work artifacts,

• Agile Manifesto described by the Agile Alliance

– Individuals and interactions over processes and tools
• Team work, self-motivation, accountability
– Working software over comprehensive documentation
• Engineering best practices for rapid delivery of high quality software
– Customer collaboration over contract negotiation
• Business Approach aligning dev with Customer needs and Company goals
– Responding to change over following a plan
• Frequent Inspection and Adaptation

• "the paradigm is predictability for classic and adaptability for Agile." - Poinsignon (2002)

• In words of Ken Schwaber at an eWorkshop in 2002:

– "...it is based on empirical methods rather than defined methods. Defined methods are when you
plan what you want and then enforce it. Agile, you lightly plan what you want and then adapt to
what you get." - First eWorkshop on Agile Methods

11 May 2009

As the name suggests, Agile means quick, light and ease of movement. On the same grounds, this software engineering
methodology is lightweight and aims to make quick deliveries of the working product/software.
It is lightweight, as it has a small set of rules to be taken care during the project. Also it lays less emphasis on comprehensive
documentation, they treat a working software as the documentation.
The agile methods attempt to minimize the risk and maximize the productivity at the same time. As agile methods involves
iterative deliveries of the software, by conducting testing in parallel to the coding. Also the customer involvement is
preferred to assure that requirements are met, and is of good quality.

Agile Alliance has compiled few ground rules for agile projects, which they term as Agile Manifesto. The points on the left
(bold ones) are more important as compared to the phrases on the right. They do consider that points on the right are
important, but they think that left ones should be definitely incorporated with higher priority.
1) Individuals and interactions are given more importance than processes and tools: The project is actually executed by
the team, which uses processes and tools for facilitating their job. So agile methods have small co-located teams where
each individual can design and refactor the code according to him. They believe if the team is highly motivated and work
in coordination with each other then the outputs are of higher quality.
2) Working Software is given more importance than the comprehensive documentation, which may take considerable
amount of effort. They believe that an actual working software work as a more reliable … of the user’s requirements. If
the client can see the actual system, rather than the planned system then he can have more confidence and any
changes due to the changing requirements or gaps in the understanding can be handled at earlier stages. Basic
documentation is done about the system, what It contains and how is it used.
3) Customer collaboration is laid more emphasis rather than contract negotiation. Agile methods wants that a customer
representative should be actively involved during the development of the system, so that the business approach can be
aligned as per the company goals. Availability of the customer rep helps resolve understanding issues in smaller
timeframes. The customers involvement is also required for the acceptance testing of each iteration, so that bugs are
found at earlier stages, and new req can be incorporated.
4) Responding to Change over following a plan: The agile methods lightly plan for the project, i.e they plan for each
iteration and focus on it. The plans and software is build in an extensible manner, so that any changes can be easily
included. As in this world, the requirements keep on changing, following heavyweight software development
methodologies spent lot of time on understanding the requirements, and designing them. They believe in predicting and
designing any thing that needs to be developed and then start developing and testing the system. Whereas agile offers
the platform where the system can be build incrementally and with less effort and less cost the changes can be
accepted. It helps in better RoI (return on investment).

5
 Characteristics of Agile
• Do things in small increments with minimal planning.
• Iterations – short time frames/timeboxes – lasts from 1-4weeks
• Follow full SDLC.
• Helps minimizing overall risk, makes project more adaptable to changes
• Basically it has minimal things (features/bug fixes) in each iteration
• Team sizes are usually small to help make team communication and team collaboration
easier.
• For larger dev efforts, multiple teams work with a common goal
• Each team has a customer rep. – for answering mid-iteration problem domain questions.
• There are frequent meetings – with the rep, and internally in the team to discuss the
progress being made and problems being faced
• Produce less written progress.

11 May 2009

This slide tells the basic characteristics followed during agile implementation. It
focuses on minimal planning by planning the deliveries in short iterations (also
referred as time boxes). Each iteration follows complete SDLC cycle, where the
team starts with the requirements in the form of user stories, and then they
understand them well and create a basic design. Then development and testing
goes hand in hand. It prefers small teams of 5-10 members, so that the team has
better interaction and collaboration. Each team has a customer representative for
answering any queries during the entire iteration. As well frequent meetings are held
among the team, and the customer representative to discuss the progress being
made, the tasks to be done and any impediments. They focus on less written
progress, or documentation.

6
 11 May 2009

This shows the development life cycle for agile. It basically consists of 4 phases:
1)Inception: The project is initiated, and all the requirements are listed as the work
items. A basic architecture is also designed, which acts as an input for all the
iterations, and it may get improved as the project develops.
2)Elaboration & Construction: The work items are converted into the working form,
by prioritizing them across the iterations. Each iteration is planned and executed
during this phase. During the iteration, there are daily stand up meetings to make a
note of the progress, and the problems faced by the team. The tasks not completed
during the iteration are returned back to the work item list with the proper priority. At
the end of this phase, a working software is reviewed, then plan for new iteration is
made and demo is given.
3)Transition
4) Production

7
 Agile Methods
• Dynamic System Development Method
• Feature Driven Development
• Extreme programming (XP)
• Software Development Rhythms
• Test Driven Development
• Scrum

11 May 2009

These are some examples of agile implementations.

8
Agenda
1 Agile Methodology

2 Extreme Programming

3 Test Driven Development

4 Scrum

11 May 2009

9
Extreme Programming
A discipline of software development that follows a specific structure that is designed to
simplify and expedite the process of developing new software. Kent Beck developed
Extreme Programming to be used with small teams of developers who need to develop
software quickly in an environment of rapidly-changing requirements.

XP teams design software for specific functionalities without adding any functionalities that
are not specifically requested that may slow down the process, keeping the development
course simple through systematic and regular testing and design improvements.

11 May 2009

10
Extreme Programming is based on 12 principles:

1. The Planning Process -- The desired features of the software, which are communicated by the
customer, are combined with cost estimates provided by the programmers to determine what the
most important factors of the software are. This stage is sometimes called the Planning Game.
2. Small Releases -- The software is developed in small stages that are updated frequently, typically
every two weeks.
3. Metaphor -- All members on an XP team use common names and descriptions to guide development
and communicate on common terms.
4. Simple Design -- The software should include only the code that is necessary to achieve the desired
results communicated by the customer at each stage in the process. The emphasis is not on building
for future versions of the product.
5. Testing -- Testing is done consistently throughout the process. Programmers design the tests first
and then write the software to fulfill the requirements of the test. The customer also provides
acceptance tests at each stage to ensure the desired results are achieved.
6. Refactoring -- XP programmers improve the design of the software through every stage of
development instead of waiting until the end of the development and going back to correct flaws.
7. Pair Programming -- All code is written by a pair of programmers working at the same machine.
8. Collective Ownership -- Every line of code belongs to every programmer working on the project, so
there are no issues of proprietary authorship to slow the project down. Code is changed when it
needs to be changed without delay.
9. Continuous Integration -- The XP team integrates and builds the software system multiple times per
day to keep all the programmers at the same stage of the development process at once.
10. 40-Hour Week -- The XP team does not work excessive overtime to ensure that the team remains
well-rested, alert and effective.
11. On-Site Customer -- The XP project is directed by the customer who is available all the time to
answer questions, set priorities and determine requirements of the project.
12. Coding Standard -- The programmers all write code in the same way. This allows them to work in
pairs and to share ownership of the code.

11 May 2009

11
 11 May 2009

This diagram shows the categorization of the basic 12 principles of XP into 3 rings:
1) Outermost Ring (Red): These are the principles at Organization level
2) Middle Ring (Green): These are the principles at Team level
3) Innermost Ring (Blue): These are the principles at individual level.

12
Agenda
1 Agile Methodology

2 Extreme Programming

3 Test Driven Development

4 Scrum

11 May 2009

13
 What is TDD?
• It is a software development technique based on Test first philosophy
– It uses short development iterations based on pre-written test cases that define
desired improvements or new functions
– TDD = TFD + Refactor

• A core practice of XP (Extreme Programming)

• “Before you write code, think about what it will do.

Write a test that will use the methods you haven’t even written yet.”

• A test is not something you “do”, it is something you “write” and run once, twice, three
times, etc.
– It is a piece of code
– Testing is therefore “automated”
– Repeatedly executed, even after small changes
– Tests drive or dictate the code that is developed

11 May 2009

TDD (Test Driven Development) is a practice of XP, which states that testing and
development goes hand in hand. It states that a test should be written before the
code is written for a requirement. So that every piece of code that is written is
properly tested. It prefers automated testing, so that the functionality can be
checked at any point of time by executing the collection of all test cases.

14
 Development Life Cycle of TDD

Add a Test

Run the Test

Understand the requirements of the story,
work item, or feature that being working
Pass – Dev fails on.
continues
Add functionality to the
Red
source/Make changes
Green
Refactor
fails

Run the Test

Pass - Dev
Over

Red-Green-Refactor Rule: Write test to fail. Code to pass. Refactor

11 May 2009

It shows the development life cycle of TDD. TDD is basically guided by Red-Green-
Refactor rule, where it states that first of all a test case should be written for a
requirement. It should fail in the first go as the corresponding is not coded. Then
write the code which is required for the testcase to run successfully. If some error is
still there, refine the code until the test passes. Once it has passed, then refactor
the code to remove the duplications and remove any piece of code which is not
required. If a new design pattern is to be applied, it can be applied during the
refactor stage and then run the test cases again that the program is still running
properly or not.

For navigating through individual steps please use hyperlinks, and return back to
this page by using Back button at the end of each concept.

15
Red
• Create a test and make it fail.

– Imagine how the new code should be called and write the test as if the code
already existed. You will not get IntelliSense because the new method does not
yet exist.

– Create the new production code stub. Write just enough code so that it
compiles.

– Run the test. It should fail. This is a calibration measure to ensure that your
test is calling the correct code and that the code is not working by accident.
This is a meaningful failure, and you expect it to fail.

Back

11 May 2009

16
Green
• Make the test pass by any means necessary.

– Write the production code to make the test pass. Keep it simple.

– Some advocate the hard-coding of the expected return value first to verify that
the test correctly detects success. This varies from practitioner to practitioner.

– If you've written the code so that the test passes as intended, you are finished.
You do not have to write more code speculatively. The test is the objective
definition of "done." The phrase "You Ain't Gonna Need It" (YAGNI) is often
used to veto unnecessary work. If new functionality is still needed, then
another test is needed. Make this one test pass and continue.

– When the test passes, you might want to run all tests up to this point to build
confidence that everything else is still working.

Back

11 May 2009

17
Refactor
• Change the code to remove duplication in your project and to improve the design
while ensuring that all tests still pass.

– Remove duplication caused by the addition of the new functionality.

– Make design changes to improve the overall solution.
– After each refactoring, rerun all the tests to ensure that they all still pass.
– Repeat the cycle. Each cycle should be very short, and a typical hour should
contain many Red/Green/Refactor cycles.

Back

11 May 2009

18
Characteristics of TDD
• Is generally a white-box unit-testing mechanism

• 2 guiding rules:
– Write new business code only when an automated test has failed.
– Eliminate any duplication that you find.

• Follows the principles of "Keep It Simple, Stupid" (KISS) and "You Ain't Gonna Need It" (YAGNI) –
– focus on writing only the code necessary to pass tests, i.e requirements
– designs can be cleaner and clearer
– Focus on small components, making the product extensible, flexible & modularized

• Taking small steps through iterations prevents bugs and the need for debugging

• Makes software development predictable on

– Reliability
– Scheduling, development cost

• Automated Testing
– Consistency
– Convenient reporting

11 May 2009

19
Important Terms related to TDD
• Unit Testing:
– A software development process in which the smallest testable parts of an application, called
units, are individually and independently scrutinized for proper operation. Unit testing is often
automated but it can also be done manually.
e.g. At method level/class level in Java applications

• xUnit Frameworks: Represent language agnostic versions of the same tool .

– The unit testing frameworks built for other languages based on JUnit’s minimal API
e.g. Nunit a .NET implementation that works with C# or VB.Net, SUnit for SmallTalk

• Test Suite/Validation Suite: It is a collection of test cases, which can be executed together

• Mocks/Actors/Stubs: The components which virtualizes the real components belonging to the external
world (e.g. Database calls) to mock their behavior.
If the mock objects have some assumptions embedded in them, based on SUT (system under testing),
then it is termed as ‘Critics’
e.g. jMock and Rhino Mocks Frameworks

11 May 2009

20
Benefits of Test-Driven Development
• The suite of unit tests provides constant feedback that each component is still working.

• The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which
can and frequently does.

• When the test passes and the production code is refactored to remove duplication, it is clear that the
code is finished, and the developer can move on to a new test.

• Test-driven development forces critical analysis and design because the developer cannot create the
production code without truly understanding what the desired result should be and how to test it.

• The software tends to be better designed, that is, loosely coupled and easily maintainable, because the
developer is free to make design decisions and refactor at any time with confidence that the software is
still working. This confidence is gained by running the tests. The need for a design pattern may emerge,
and the code can be changed at that time.

• The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a
test to reveal the bug and then modify the production code so that the bug goes away and all other tests
still pass. On each successive test run, all previous bug fixes are verified.

• Reduced debugging time!

11 May 2009

21
Agenda
1 Agile Methodology

2 Extreme Programming

3 Test Driven Development

4 Scrum

11 May 2009

22
 Scrum
• A lightweight, agile process to control and manage software and product development

• Phases
– Pregame
• Planning - define system. Product Backlog
• Architecture - high level design of system
– Development
• Iterative cycles (sprints) - new or enhanced functionality
– Postgame
• Requirements satisfied - no new items or issues

11 May 2009

Scrum is a agile methodology for project management. It emphasises on iterative

delivery by small interactive teams and with little planning and minimal
documentation.

23
 Roles and Responsibilities

Chicken Roles Pig Roles

•Users •Product Owner – represents the voice of
the customer, writes user stories, prioritizes
•Stakeholders (customers, them, then places them in the product
vendors) backlog.

•Managers •Scrum Master (or Facilitator) –

Enforcer of rules,

•Team -made up of 5-9 people with cross-

functional skills to do the actual work
The joke is meant to point out the difference between those who are committed on a project and those who are only
involved. Scrum affords special status to those who are committed and many teams enforce a rule in which only those who
are committed are allowed to talk during the daily scrum.

11 May 2009

This slide presents the way roles are categorized in Scrum. There is a joke of Ham’s
n Eggs which revolves around this concept. There are 2 types of roles:
1) Chicken roles: These are the roles who are important stakeholders of the
project, who’ll be benefitted by the project, and the managers who are managing
the implementation and progress of the project.
2) Pig Roles: These are the roles who are committed to the project. They are the
ones who are implementing the project.

24
 Scrum
• Practices

– Sprint – iteration – could be few weeks to 30 days

– Sprint Planning Meeting - decide goals for next spring and how team will implement
– Daily Scrum meeting -
• Creation of self-organizing teams – Co-located teams
• Same time and place
• Every team member answers –
– What did you do yesterday?
– What will you do today?
– Are there any impediments in your way?
– Sprint Review Meeting -present results of sprint

– Product Backlog -Current prioritized list of work to be done

– Sprint Backlog -Product Backlog items for sprint
– Burn Down Chart - shows remaining work in the sprint backlog

11 May 2009

Scrum process:
All the work items/requirements are listed in a log called as project backlog. It is
mainly managed by the project manager, and it can be changed as per requirement
changes. The items are prioritized as per the importance and cost involved.
It is an iterative project development methodology. Each iteration is termed as
Sprint.
At the beginning of each sprint, a Sprint Planning meeting is done. It is done to
decide the goals for the sprint. It takes the higher priority requirements and create a
sprint backlog. The sprint planning meeting mainly involves project manager, and
client representative.
There is a small team of size 5-9 people for implementing the sprint. The team is a
cross- functional team, and there is a scrum master who facilitates the daily scrum
meetings. Every team member answers 2 questions of what was done yesterday,
what is to be done today and what are the problems. He helps the team to become
more self motivated and self conducting. No one manages the team, rather the
team is self managing.
There is a sprint review meeting at the end of the sprint to present the results of the
sprint.
At any point of time, a burn down chart can be referred to see how many tasks are
left from the sprint backlog. Basically it maintains the progress chart of the sprint.

25
 Tools used in SCRUM (Java Projects)
• Project planning and tracking: SCRUMWorksTM (danube.com/scrumworks)
• Configuration Management: CVS (www.nongnu.org/cvs/) or SVN (subversion.tigris.org)
• Bug Tracking: Bugzilla (www.bugzilla.org)
• IDE: Eclipse for java and .net (www.eclipse.org)
• Project Management and Build: Maven (maven.apache.org) or Ant (ant.apache.org)
• Continuous build: CruiseControl (cruisecontrol.sourceforge.net)
• Code Coverage: Jcoverage (www.jcoverage.com)
• Standards Check: Check Style (checkstyle.sourceforge.net)
• Testing: JUnit (www.junit.org), DbUnit (www.dbunit.org), jMock (www.jmock.org)

11 May 2009

This slide lists some examples of the tools which can be used while implementing
an agile project, or Scrum in particular.

26
Why Scrum is powerful
• Focus is on team's work, and team's work only
• Daily communication of status occurs
• Enables low-overhead empirical management
• Makes impediments visible
• Someone is willing to make decisions and remove impediments real-time

11 May 2009

27
References
• http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/
• http://www.scrumalliance.org/
• http://ootips.org/xp.html
• http://www.agiledata.org/essays/tdd.html
• http://open.ncsu.edu/se/tutorials/junit/
• http://www.xprogramming.com/xpmag/whatisxp.htm
• http://www.extremeprogramming.org/
• http://agilemethodology.org/
• http://agilemanifesto.org/
• http://www.controlchaos.com/about/
• http://www.slideshare.net/Siddhi/intro-to-agile

• Agile Software Development link through Knowmax – Select the first option available on
the page:
– https://knowmax.ultimatix.net/sites/SearchCenter/pages/Results.aspx?k=Agile&s=All
%20Sources

11 May 2009

28
Thank You

29