Download - Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Transcript
Page 1: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Unit 4

Agile Development Process

Agile Development: Agile manifesto, agility and cost of change, agility

principles, myth of planned development, toolset for the agile process.

Extreme Programming: XP values, process, industrial XP, SCRUM - process

flow, scrum roles, scrum cycle description, product backlog, sprint planning

meeting, sprint backlog, sprint execution, daily scrum meeting, maintaining sprint

backlog and burn-down chart, sprint review and retrospective.

Agile Practices: test driven development, refactoring, pair programming,

continuous integration, exploratory testing versus scripted testing

Page 2: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

2

Project Execution Traditional Approach

What comes to your mind ???

2

Page 3: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Project Execution Traditional Approach

• Big Bang / Code & Fix

• Waterfall 1950 - 1970

• Spiral Model 1980 - 1988 – Incremental

– Iterative

• RAD (Rapid Application Development) 1990

• Agile 2001

3

Page 4: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Typical Waterfall

4

Page 5: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

5

Agile framework & principles

The concept of iterative and incremental approach to development started away back from 1950s.

• In 1950s – NASA and The United States Department of Defence (DoD) have used the incremental and iterative development (IID) approach.

• In 1960s – the concept of Evolutionary project management (Evo) recommended a one- to two-week iterations, delivery of product in each iteration.

• In 1986 – The “rugby approach” was discussed with dedicated, self-organizing teams. Here a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.”

Origin -

Page 6: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

6

Agile framework & principles

Rugby Approach –

(Photo from www.zimbio.com – Northland club Rugby)

Page 7: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

What is “Agility”?

• Effective (rapid and adaptive) response to change!

• Effective communication among all stakeholders!

• Drawing the customer onto the team! Eliminate “us

and them” attitude

• Organizing a team so that it is in control of the work

performed!

• Yielding …!

• Rapid, incremental delivery of software!

Page 8: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Agility and the Cost of Change

• A well-designed agile process “flattens” the cost of change

curve

• Allowing a software team to accommodate changes late in a

software project without dramatic cost and time impact.

• You‟ve already learned that the agile process encompasses

incremental delivery.

• When incremental delivery is coupled with other agile practices

• such as continuous unit testing and pair programming the

cost of making a change is attenuated.

Page 9: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Agility and the Cost of Change

Page 10: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

An Agile Process

• Is driven by customer descriptions of what is required

(scenarios)!

• Recognizes that plans are short-lived! (some requirements

will persist, some will change. Customer priorities will change)

• Develops software iteratively with a heavy emphasis on

construction activities! (Design and Construction activities are

interleaved)

• Delivers multiple „software increments‟!

• Adapts as changes occur!

Page 11: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

11

Agile framework & principles

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

The above states that while there is a value in the items on the right,

we value the items on the left more.

Agile Manifesto –

Page 12: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

12

Agile framework & principles

Individuals and interactions over processes and tools –

• Promotes empowered, self-managing, cross functional teams • Advocates members to collaborate in person to solve a mutual problem • Tools support cannot replace individual interactions

Agile Manifesto –

Page 13: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

13

Agile framework & principles

Working software over comprehensive documentation

Agile Manifesto –

• Status / progress should be measured on actual working product and not by percentage completion of the functional milestones

• Agile encourages teams for face-to-face communication over documentation which is simpler, faster, and far more reliable

• Documents usually gets out-dated as system design keeps on changing

Page 14: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

14

Agile framework & principles

Customer collaboration over contract negotiation

Agile Manifesto –

• Customers become an integral part of the development process and not only during contract negotiation and defining specification

• Better way to deliver value instead of a carefully worded contract

Page 15: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

15

Agile framework & principles

Responding to change over following a plan

Agile Manifesto –

• Agile plans follow more of a rolling wave approach using top-down planning

• Change management is easier when the organization and the customer share a clear understanding of the project’s status

• In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated which is not the case in Agile developments

• Business needs and priorities can shift in the months or even years it can take for a large system to be fully built

Page 16: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

16

Agile framework & principles

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

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

12 Agile Principles –

Page 17: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

17

Agile framework & principles

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.

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 behaviour accordingly

12 Agile Principles –

Page 18: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Myths of Planned Development

Agile

development is

a methodology Agile is

undisciplined

Page 19: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Myths of Planned Development

Agile has no planning

Agile has no documentation

Page 20: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Myths of Planned Development

Agile has no upfront

design/architecture

Agile does not scale

Page 21: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Myths of Planned Development

Agile is just another fad

Page 22: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

22

Toolset for Agile Process

The objective of agile development tools is to help in one or more activities in agile development. Due to use of such tools the operational development software can be created rapidly.

The agile tool set consist of automated support for project planning, use case development, and requirements gathering, code generation and testing.

Examples :

1) Actif Extreme :- This tool is developed by Microtool. It provides the support for various technical activities.

2) Ideogramic UML :- it is developed by Ideogramic. This tool is used with agile process.

3) Together Tool Set :- it is distributed by borland. It provides support for technical activities within the XP(extreme programming) and other agile process.

Page 23: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

23

eXtreme Programming

The most widely used agile process, originally proposed by Kent Beck

in 2004. It uses an object-oriented approach.

XP Values :- Beck defined the set of five values that serve as a basis for the work performed in the xp. The values are,

1) Communication :- The effective communication must be established between software developers and stake holders in order to convey the important concepts and to get the important feedback.

2) Simplicity :- XP focuses on current needs instead of future needs to incorporate in design.

3) Feedback:- The feedback for software product can be obtained from the developers of software, customers, and other software team members.

4) Courage:- The agile xp team must be disciplined to design the system today, recognize the future requirements and make changes dramatically as per demand.

5) Respect :- by following the above states XP values the agile team can win the respect of stakeholders.

Page 24: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Extreme Programming (XP)

Page 25: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• XP Planning

• Begins with the listening, leads to creation of “user stories” that describes

required output, features, and functionality. Customer assigns a value(i.e., a

priority) to each story.

• Agile team assesses each story and assigns a cost (development weeks. If more

than 3 weeks, customer asked to split into smaller stories)

• Working together, stories are grouped for a deliverable increment next

release.

• A commitment (stories to be included, delivery date and other project

matters) is made. Three ways: 1. Either all stories will be implemented in a few

weeks, 2. high priority stories first, or 3. the riskiest stories will be implemented first.

• After the first increment “project velocity”, namely number of stories

implemented during the first release is used to help define subsequent

delivery dates for other increments. Customers can add stories, delete

existing stories, change values of an existing story, split stories as development

work proceeds

Page 26: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

26

• XP Design ( occurs both before and after coding as refactoring is encouraged)

• Follows the (keep it simple) principle Nothing more nothing less than the story.

• Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented

context. The only design work product of XP. They identify and organize the classes that

are relevant to the current software increment.

• For difficult design problems, suggests the creation of ―spike solutions‖—a design

prototype for that portion is implemented and evaluated.

• Encourages ―refactoring‖—an iterative refinement of the internal program design. Does

not alter the external behavior yet improve the internal structure. Minimize chances of

bugs. More efficient, easy to read.

• XP Coding

• Recommends the construction of a unit test for a story before coding commences. So

implementer can focus on what must be implemented to pass the test.

• Encourages ―pair programming‖. Two people work together at one workstation. Real time

problem solving, real time review for quality assurance. Take slightly different roles.

• XP Testing

• All unit tests are executed daily and ideally should be automated. Regression tests are

conducted to test current and previous components.

• ―Acceptance tests‖ are defined by the customer and executed to assess customer visible

functionality

Page 27: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Industrial XP

The industrial XP can be defined as the organic evolution of XP. It is customer centric. It has

expanded role for customers and advanced technical practices.

Various new practices that are as follows:-

1) Readiness Assessment :- in this assessment following issues are assessed-

- Proper Environment must be available to support XP.

- Team should contain appropriate stakeholders.

- The organization should support quality programs and continuous improvement.

- The organization culture should support new values of agile team.

Page 28: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

2) Project Community :- Skilled and efficient people must be chosen as the agile team

members for the success of the project.

- The team is referred as the community when extreme programming approach is

considered.

The project community consist of technologies, customers, and other stakeholders who play

the vital role for the success of the project. The role of the community members must be

explicitly defined.

3) Project Chartering :- it means assessing the justification for the project as a business

application. That means, the IXP team assess whether the project satisfies the goals and

objectives of organization.

Page 29: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

4) Test Driven Management :- for assessing the state of project and its progress the

industrial XP needs some measurable criteria. In test driven management the project is

tested with the help of these measurable criteria.

5) Retrospectives :- After delivering the software increment, the specialized review is

conducted which is called as retrospective. The intension of this is to improve the

industrial XP process.

6) Continuous learning :- the team members are inspired and encouraged to learn

new methods and techniques that can improve the quality of product.

Page 30: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

XP and Scrum

• Scrum teams typically work in iterations

(called sprints) that are from two weeks to

one month long.

• Scrum product owner prioritizes the

product backlog but the team determines

the sequence in which they will develop

• Scrum teams do not allow changes into

their sprints.

• Scrum doesn't prescribe any engineering

practices

• XP teams typically work in iterations that

are one or two weeks long.

• XP teams work in a strict priority order.

• XP teams are much more amenable to

change within their iterations.

• XP prescribes engineering practices,

particularly things like test-driven

development, the focus on automated

testing, pair programming, simple design,

refactoring.

Page 31: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Scrum Methodologies

Page 32: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

32

User Story Definition –

A user story describes functionality that will be valuable to either a user or purchaser of a system or software.

A User Story Is

• An agreements between customers and team members to discuss detailed requirements during an iteration

• Emphasize verbal rather than written communication. • Right size for planning

A User Story Is Not

• A Requirement document, requirement needs to be captured by discussion , if the discussion is not possible then should be augmented by documentation

Page 33: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

User Story

33

• Your user story needs to have, at a minimum, the following parts

✓ Title: <a name for the user story>

✓ As a <user or persona>

✓ I want to <take this action>

✓ So that <I get this benefit>

• The story should also include validation steps. That step is worded as follows:

✓ When I <take this action>, this happens <description of action>

Page 34: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

34

Scrum

• Scrum is a simple yet incredibly powerful set of principles and practices that help teams deliver products in short cycles, enabling fast feedback, continual improvement, and rapid adaptation to change. As the leading Agile development framework, Scrum has predominantly been used for software development, but it is also proving to be effective in efforts far beyond -- Source: Scrum Alliance

• Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". – Source: Wikipedia

• In short :

Scrum is an agile process that focuses on delivering the highest business value in the shortest time thereby rapidly and repeatedly inspect actual working software.

The business sets the priorities. Scrum teams self-organize to determine the best way to deliver the highest priority features. Time-boxed for two to four weeks, anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.

What is Scrum?

Page 35: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

35

Scrum

Picture source: www.agileforall.com

Page 36: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

36

Scrum

• With inputs from business stakeholders, the Product Owner creates a prioritized business wish list called a product backlog

• Based on priorities set by product owner, the Scrum Team takes up a small chunk from the top of the product backlog, in sprint backlog, and decides how to implement those pieces

• Scrum team has a time-boxed period — a Sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum)

• The ScrumMaster keeps the team focused on its goal throughout.

• At sprint end, the work outcome is potentially shippable: ready to be handed over to customer, put on a store shelf, or show to a stakeholder

• A sprint review and retrospective concludes a sprint

• The next sprint begins with another chunk of the product backlog

Framework –

Page 37: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

37

Scrum Framework –

• Product Owner

• Scrum Master

• Team

Roles

• Sprint Planning

• Daily Scrum Meeting

• Sprint Review

• Sprint Retrospective

Ceremonies

• Product Backlog

• Sprint Backlog

• Sprint Burndown Chart

Artifacts

Page 38: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

38

Scrum Framework –

• Product Owner

• Scrum Master

• Team

Roles

• Sprint Planning

• Daily Scrum Meeting

• Sprint Review

• Sprint Retrospective

Ceremonies

• Product Backlog

• Sprint Backlog

• Sprint Burndown Chart

Artifacts

Page 39: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

39

Scrum Roles 1. Product Owner – Responsibilities

• Define the features of the product

• Work on a shared vision as he represents the business stakeholders

• Manage and Prioritize features according to market value in Product Backlog

• Accept / reject the work at the end of each iteration

• Managing the release plan

• Responsible for the profitability of the product (ROI)

• Decide on release date and content

Page 40: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

40

2. Scrum Master – Responsibilities

• empower and shepherd the Scrum team

• Represents management to the project

• Keeps the process moving by 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

• Socialising Scrum to the greater organisation

Page 41: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

41

3. Team – Responsibilities

• Typically a team of 5-9 people

• They are usually cross-functional: Programmer, QA, UX designers, Analyst, etc.

• Estimate size of backlog items

• Committing to increments of deliverable software and delivering it

• Tracks own progress

• Is self-organising—but accountable to the Product Owner for delivering as promised

Page 42: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

42

Scrum Framework –

• Product Owner

• Scrum Master

• Team

Roles

• Sprint Planning

• Daily Scrum Meeting

• Sprint Review

• Sprint Retrospective

Ceremonies

• Product Backlog

• Sprint Backlog

• Sprint Burndown Chart

Artifacts

Page 43: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

43

Scrum Artifacts Artifact stages –

Page 44: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

44

1. Product Backlog –

• list of work items that need to be done over time. • Items may be added to the backlog by anyone • only the Product Owner has the right to determine the order in which they will be executed by the team and he negotiates this with stakeholders and the team. •The Product Backlog is a living document and requires constant grooming to keep it current and useful. •Many new items will be added over time; existing items are disaggregated to multiple, smaller items; some items may be removed on realising that a desired feature is no longer needed.

Good Product Backlog contains:

Good product backlogs should be DEEP (Coined by Roman Pichler and Mike)

• Detailed appropriately

• Emergent

• Estimated

• Prioritized

Page 45: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

45

Contents of Product Backlog –

Type Example

Feature As a recruiter I want to search candidates using keywords so that I can find the suitable job seeker

Change As a job seeker I want default ordering job search results to be by freshness rather than location so that its easier to see latest jobs first

Defects Please fix defect #148 so that space characters in search wont crash the system

Technical Improvement Upgrade to the latest version of Internet Information Server

Knowledge Acquisition Create integration prototype using MSSQL Server and Salesforce.com and run performance test to check real time integration speed and reports.

Page 46: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 47: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 48: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

48

2. Sprint Backlog –

•The Sprint backlog is more of like a task board •It the physical representation of the list of work that the Scrum team have committed to do during the current sprint. •It tells the whole team and anyone else what work they have planned or the sprint and their current status.

In short:

• The Sprint Backlog defines the work team will perform to turn selected Product Backlog items into a “Done” Increment

• The list emerges during the Sprint. • Every team member takes responsibility / ownership of each task in progress task • Each Tasks has information about estimated amount of work remaining on the

task on any given day during the Sprint

Page 49: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

49

Sprint Backlog Management –

• Individuals take up work of their own choosing. Work is never assigned

• Estimated work remaining is updated on daily basis

• Any team member can add, delete or change the sprint backlog

• If work is unclear, define a sprint backlog item with a larger amount of

time and break it down later

• Update work remaining as more becomes known

Page 50: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 51: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

51

Scrum Definition of Done –

• Everyone must understand what done means

• This varies significantly per Scrum Team, members must have a shared

understanding of what it means for work to be complete, to ensure

transparency

• This guides Development Team in knowing how many Product Backlog items

it can select during a Sprint Planning Meeting.

• The purpose of each Sprint is to deliver Increments of potentially releasable

functionality that adhere to Definition of “Done.”

• Definition of Done may change during the project

Page 52: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

52

3. Sprint Burndown Chart –

The sprint burndown chart helps the Scrum team to monitor its progress and

works as an indicator of whether it will meet its commitment at the end of the

sprint.

It requires teams to estimate the duration of each task in hours and on a daily

basis to chart the total remaining hours for all uncompleted tasks.

Helps to:

• Estimate new tasks and re-estimating in-progress tasks requires effort

• Re-estimate inaccurate tasks

• Completion of tasks delivers no value; only completed stories (features) deliver value

Page 53: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

53

Sprint Burndown Chart Sample –

Picture source: Wikipedia

Page 54: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

54

Scrum Framework –

• Product Owner

• Scrum Master

• Team

Roles

• Sprint Planning

• Daily Scrum Meeting

• Sprint Review

• Sprint Retrospective

Ceremonies

• Product Backlog

• Sprint Backlog

• Sprint Burndown Chart

Artifacts

Page 55: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Scrum Ceremonies 1. Sprint Planning –

• The Team and the Product Owner collaborate to help the Team determine how much Product Backlog it can turn into functionality during the upcoming Sprint.

• The Team create plans (Sprint Backlog) by identifying tasks for converting selected Product Backlog into functionality

• Team selects items from the product backlog that they can commit to complete within a Sprint

• Sprint backlog is created

Tasks are identified and each is estimated (1-16 hours)

Collaboratively, not done alone by the Scrum Master

• High-level design is considered

55

Page 56: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

2. Sprint Planning –

56

• Product Backlog

• Team Capacity

• Business Conditions

• Current Product

• Technology

• Analyse and evaluate product

backlog

• Select sprint goal

• Decide how to achieve sprint

goal (design)

• Create sprint backlog (tasks)

from product backlog items

(user stories / features)

• Estimate sprint backlog in

hours

• Sprint Goal

• Sprint Backlog

Inputs Sprint Planning Meeting Output

Sprint prioritization

Sprint planning

Page 57: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Sprint Planning –

57

Prioritizes

Product

Backlog

Develops

Sprint Backlog

Facilitates

Page 58: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

3. Daily Scrum Meeting –

•The team meets daily to communicate and synchronise its work.

• Since the team is collaborating, it’s essential to ensure that continued project progress and avoiding work blockages.

•The team continuously assess its own progress towards achieving its sprint goal and NOT report progress to the ScrumMaster or Product Owner or anyone else.

58

Helps to: Parameters

• Fine-grain coordination

• Daily commitment

• Raising impediments

• Peer pressure

• Access Progress towards sprint goal

• Helps avoid other unnecessary meetings

• Daily 15-minutes Stand-up

• Not for problem solving

Only team members, Scrum Master, Product Owner can talk

Comprises of:

Story

To Do

WIP

Done

Impediment

Page 59: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Daily Scrum Meeting –

59

Observes

1. What have you done yesterday?

Facilitates

2. What are you going to do today?

3. Are there any impediments in your

way?

Page 60: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

60

3. Scrum Board

Page 61: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

61

Page 62: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

62

Page 63: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

4. Sprint Review –

•The focus is the product the team is building.

•While it does include a demonstration of the new features the team has completed

during the sprint,

•its primary purpose is to inspect what the team has delivered and gather feedback

from the attendees to adapt the plan for the succeeding sprint.

63

Helps to:

• Team presents to product owner, stakeholders and scrum master what it accomplished during the sprint

• Typically takes the form of a demo of new features

• It’s usually Informal

2-hour prep time rule

No slides

• Whole team participates

• Audience – Invite the world!!

Page 64: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Sprint Review –

64

Provides

feedback

Provides

feedback

Presents the new

development

Facilitates

Page 65: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

5. Sprint Retrospective –

•final meeting of the sprint.

• It follows immediately after the sprint review and should never be omitted.

•The retrospective is focussed on the process—the way in which the Scrum

team is working together, including their technical skills and the software

development practices and tools they are using

65

Parameters:

• Periodically take a look at what is and is not working

• Done after every sprint

• Participants

Scrum Master

Team

Product owner (Optional)

Page 66: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Sprint Retrospective –

66

Observes

1. Start doing

Facilitates

2. Continue doing

3. Stop doing

Page 67: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Agile Practises

Page 68: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Test Driven Development

Page 69: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Test Driven Dvelpoment (TDD)

• The basic tenets are developing and implemen

ting

• unit tests before writing a line of code

• Unit tests will and must fail up front

• Code is developed after the test is developed.

• A unique idea that is still foreign to many

developers

Page 70: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

TDD steps

Page 71: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• Quickly add a test just enough code to fail test

• Run testsuite to ensure test fails (may choose to run a subset of suite)

• Update your functional code to ensure new test passes

• Rerun test suite and keep updating functional code until test passes

• Refactor and move on

Page 72: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 73: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

TDD and agile

• TDD implies agile.

• Strong emphasis on testing

• Tests should span entire breadth of codebase

• Once all software is ready for delivery, all tests

should pass

• A unique way to address modern challenges in

software development

Page 74: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Myths about TDD

• Myth: TDD is ok for small projects involving a handful of folks but won't sc

ale to large projects involving scores or hundreds of people.

• Answer: Not true.

Kent Beck worked on a pure TDD project developed in

• Smalltalk.

• 4 years and 40 man years of effort resulting in 250K lines

• of func code and 250K lines of test code

• 4,000 tests run in under 20 mins

• Full suite runs several times a day

Page 75: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

TDD benefits

• Shortens the programming feedback

• Provides detailed (executable) specifications

• Promotes development of highquality code

• Provides concrete evidence that your code works

• Requires developers to prove it with code

• Provides finelygrained, concrete feedback (in mins)

• Ensures that your design is clean by focusing on creation of

operations that are callable and testable

• Supports evolutionary development

Page 76: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Refactoring

• Refactoring is:

– restructuring (rearranging) code...

– ...in a series of small, semantics-preserving transformations (i.e. the

code keeps working)...

– ...in order to make the code easier to maintain and modify

• Refactoring is not just any old restructuring

– You need to keep the code working

– You need small steps that preserve semantics

– You need to have unit tests to prove the code works

• There are numerous well-known refactoring techniques

– You should be at least somewhat familiar with these before inventing

your own

Page 77: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

77

When to refactor

• You should refactor:

– Any time that you see a better way to do things

• “Better” means making the code easier to understand

and to modify in the future

– You can do so without breaking the code

• Unit tests are essential for this

• You should not refactor:

– Stable code (code that won‟t ever need to change)

– Someone else‟s code

• Unless you‟ve inherited it (and now it‟s yours)

Page 78: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

78

The refactoring environment

• Traditional software engineering is modeled after traditional

engineering practices (= design first, then code)

• Assumptions:

– The desired end product can be determined in advance

– Workers of a given type (plumbers, electricians, etc.) are interchangeable

• “Agile” software engineering is based on different assumptions:

– Requirements (and therefore design) change as users become acquainted

with the software

– Programmers are professionals with varying skills and knowledge

– Programmers are in the best position for making design decisions

• Refactoring is fundamental to agile programming

– Refactoring is sometimes necessary in a traditional process, when the

design is found to be defective

Page 79: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Pair Programming

Page 80: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 81: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 82: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 83: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 84: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 85: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 86: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 87: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

How does it Help? • Continuous Review.

• Less Defects caught early.

• Better Problem Solving.

• More Economical.

• “Pair-Pressure” ensures timely delivery.

• Rapid Hands-on Approach to Learning.

• Better Induction of new Team Members.

Page 88: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 89: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,
Page 90: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

What is NOT pair programming?

• Splitting up the work

• Taking turns doing the work

• One person doing all the work

• Being located in different places

• Sitting at different computers

• (Exception – it‟s ok to use remote shared

desktop technology, such as VNC, if

absolutely necessary)

Page 91: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Continuous Integration

• software development practice

• members of a team integrate their work

frequently,

• usually each person integrates at least daily -

leading to multiple integrations per day.

• Each integration is verified by an automated

build (including test) to detect integration

errors as quickly as possible” – Martin Fowler

Page 92: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

CI – What does it really mean?

• At a regular frequency (ideally at every commit), the system is:

• Integrated :All changes up until that point are combined into

the project

• Built: The code is compiled into an executable or package

• Tested: Automated test suites are run

• Archived” Versioned and stored so it can be distributed as is, if

desired

• Deployed: Loaded onto a system where the developers can

interact with it

Page 93: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

CI - Workflow

Page 94: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

CI – Benefits

• Immediate bug detection

• No integration step in the lifecycle

• A deployable system at any given point

• Record of evolution of the project

Page 95: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-95

What is Scripted Testing?

• Small (but realistic) example:

• How to script and test this login?

(Functional tests only – not security!)

Page 96: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-96

Sample test scripts (4 of “many”):

• Sample test script 1: – Launch the Login screen

– Enter User-id: “xyz”

– Enter Password: “zyx”

– Press <Enter>

– Expected result: login ok

• Sample test script 2: – Launch the Login screen

– Enter User-id: “xyz”

– Enter Password: “zyx”

– Click the “Login” button

– Expected result: login ok

• Sample test script 3: – Launch the Login screen

– Enter User-id: “”

– Enter Password: “zyx”

– Press <Enter>

– Expected: login rejected

• Sample test script 4: – Launch the Login screen

– Enter User-id: “”

– Enter Password: “zyx”

– Click the “Login” button

– Expected: login rejected

Page 97: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

ET Workshop v. 1.20 -

Introduction ©2002 Amland Consulting 1-97

• Sample generic test script 1:

– Launch the Login screen

– Enter valid User-id

– Enter valid Password

– Press <Enter> or click button

– Expected result: login ok

• Sample generic test script 2:

– Launch the Login screen

– Enter invalid User-id

– Enter valid Password

– Press <Enter> or click button

– Expected result: login rejected

Page 98: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-98

Sample test “Pattern” script (checklist)

• Input fields:

– Valid data

– Invalid data

– Length > max

– Length = max +1

– Length = max

– Length = max –1

– Combinations of above

– …

• Actions:

– Keyboard

– Buttons

– …

• Operations:

– Add, Modify, Inquiry, Delete • What to test for each…

– …

Page 99: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Manual v. automated

• Automation is cool, it gets respect … but …

– Automation is code

• like any code it will take time, have bugs, cause false

positives and require maintenance

• it will have an imperfect oracle

• Manual testing is tedious … but …

– It finds over 90% of the bugs in the system

Page 100: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Manual testing

• Scripted manual testing

– From rigid (click this button, enter this value) to

flexible (achieve this result)

– Requires preparatory work

– Scripts act as their own documentation

• Exploratory testing

– Minimizes preparatory work

– Documentation of testing is extra work

Page 101: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-101

When to use Exploratory Testing?

• A common goal of exploration is to query for weak

areas of the program.

• Test team‟s resource consumption per week:

– 25% of the group‟s time developing new tests

– 50% executing old tests (including bug regression)

– 25% on exploratory testing

Page 102: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-102

• When there is little or no specifications and / or requirements

• When you have little or no domain knowledge

• When you don‟t have time to specify, script and test

Uncertainty and Time Pressure!

Page 103: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-103

• Exploratory Testing is extremely useful when

faced with software that is

– Untested

– Unknown or

– Unstable

• The tester must create a map of the

application as he goes on testing it.

Page 104: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

1-104

• Take a more scripted approach when:

– There are little uncertainty about how to test

– New tests are relatively unimportant

– The need for efficiency and reliability in executing

tests is worth the effort of scripting

– We are prepared to pay the cost of documenting

and maintaining tests

Page 105: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Types of exploratory testing

• Freestyle

• Scenario

• Strategy

• Feedback

Page 106: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• Freestyle exploratory testing

– Ad hoc exploration of an application‟s features

– No rules, not necessary to account for coverage,

past tests, etc.

– Good for:

• familiarizing yourself with an application to prepare for

more sophisticated methods

• quick smoke tests, sometimes finds bugs

Page 107: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• Scenario-based exploratory testing

– An extension of traditional scenario testing

– Start with:

• user stories

• e2e scenarios

• test scenarios

– Then widen the scope and inject variation as you

execute the scenarios

Page 108: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• Strategy-based exploratory testing

– Freestyle testing combined with known bug finding

techniques

• documented strategies like boundary values and

combinatorial testing

• intuitive instinct from experience or familiarity with the

application

Page 109: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

• Feedback-based exploratory testing

– Starts out freestyle until a test history is built up

– That feedback then guides future exploration

• Test history

• Coverage

• Churn

• …

– Tools are often an integral part of this type of

testing as they „remember‟ history for us

Page 110: Unit 4 Agile Development Process · Unit 4 Agile Development Process Agile Development: Agile manifesto, agility and cost of change, agility principles, myth of planned development,

Obstacles to exploratory testing

• Where‟s the accountability?

• How do we track completeness?

• What metrics are important?