You are on page 1of 55

SDLC AGILE METHODOLOGY

Copyright 2006 SoftServe, Inc.

SDLC SDLC abbreviation stands for software development life cycle


SDLC is a structured methodology used in the development of software products and packages. This methodology is used from the conception phase through to the delivery and end of project delivering software product.

SLDC methodology: SDLC definition


Waterfall SDLC V-Shape SDLC Spiral SDLC RUP SDLC Agile methods

Some Agile Methods

Extreme Programming (XP) Feature Driven Development (FDD)

Scrum
Agile Unified Process(AUP)

Extreme Programming - XP
For small-to-medium-sized teams developing software with vague or rapidly changing requirements Coding is the key activity throughout a software project Communication among teammates is done with code Life cycle and behavior of complex objects defined in test cases again in code

Extreme Programming (XP)


simple design CRC cards user st ories values accept ance t est crit eria it erat ion plan

spike solut ions prot ot ypes

ref act oring pair programming

Release
sof t w are increment proj ect v elocit y comput ed

unit t est cont inuous int egrat ion accept ance t est ing

Extreme Programming (XP)

XP Planning
Begins with the creation of user stories Agile team assesses each story and assigns a cost Stories are increment grouped to for a deliverable

A commitment is made on delivery date


After the first increment project velocity is used to help define subsequent delivery dates for other increments

Extreme Programming (XP)

XP Design
Follows the KIS (keep it simple) principle Design provides implementation guidance for a story Encourage the use of CRC (class-responsibility collaborator) cards

For difficult design problems, suggests the creation of spike solutionsa design prototype
Encourages refactoringan iterative refinement of the internal program design

CRC Cards
Class: Class: Descri p tion: Class: Descri p tion: FloorPlan Class: Descrip tion: Responsibility: Descrip tion: Responsibility: Responsibility: Responsibility:
defines floor plan name/type manages floor plan positio ning scales f lo or plan for display scales f lo or plan for display incorporates w alls , doors and w indow s show s position of video cameras Wall Camera

Collaborator: Collaborator: Collaborator: Collaborator:

Extreme Programming (XP)

XP Coding
Recommends the construction of a unit test for a store before coding commences

Encourages pair programming


Integration of work (done by pair programmer) on daily basis

Yielding
smoke testing helps to uncover errors early

Pair Programming
Pair programming is a dialogue between two people trying to simultaneously programming (analyze and design and test) and understand together how to program better. It is a conversation at many levels, assisted by and focused on a computer -- Kent Beck

Extreme Programming (XP)

XP Testing
All unit tests are executed daily Encourages a regression testing strategy when ever code is modified Acceptance tests are defined by the customer and executed to assess customer visible functionality

Feature Driven Design (FDD)


Five FDD process activities

1.
2.

Develop an overall model Produce class and sequence diagrams from chief architect meeting with domain experts and developers.
Build a features list Identify all the features that support requirements. The features are functionally decomposed into Business Activities steps within Subject Areas.
Features are functions that can be developed in two weeks and expressed in client terms with the template: <action> <result> <object> i.e. Calculate the total of a sale

3. 4. 5.

Plan by feature -- the development staff plans the development sequence of features Design by feature -- the team produces sequence diagrams for the selected features Build by feature the team writes and tests the code http://www.nebulon.com/articles/index.html

FDD Process Template


Entry Tasks Verification Exit : (ETVX)
Entry: A brief description of the process, and all preconditions that should hold before the process starts Tasks: A list of all tasks that should be done during the process.

Verification: Conditions which clarify if the process has been completed successfully

FDD Process (1/8)

Activities within each Process follow ETVX Template

FDD A 5 Step Process

1.Develop an Overall Model

2.Build a Feature List

3.Plan By Feature

4.Design By Feature

5.Build By Feature

Fig Source: Palmer, SR., Felsing , JM.2002,p.57).

Develop an Overall Model (2/8)


Entry Criteria Domain experts, Chief Programmers and the Chief Architect have been selected. Tasks Verification By users & Domain Experts Exit criteria Class diagram
(Fig. Source: Palmer, SR., Felsing , JM.2002,p.106)

Build a Features List (3/8)


Entry Criteria Domain experts, CP & CA have been selected Tasks Domain decomposed into Major Features Sets

Major Feature Sets comprise of Feature Sets


Feature Sets comprises Features

Verification
Self Assessment of Modeling Team Members
Source: Palmer, SR., Felsing , JM.2002,p.135

Exit criteria

Plan by Feature (4/8)

Entry Criteria Completed Building a Features List

Tasks To achieve development sequence Verification A self-assessment Exit criteria Business activities with Completion dates..

CP assigned to business activities.

Source: Palmer, SR., Felsing , JM.2002,p.146

Design by Feature (5/8)


Entry Criteria

Planning process has completed. Tasks CP, Work Package, Feature Team, Sequence diagram, Update the Object Model. (Next slide) Verification Design inspection is made. Exit criteria Sequence diagram(s).

Continued (6/8)

(Fig. Source: Palmer, SR., Felsing , JM.2002,p.160)

Build by Feature (7/8)


Entry Criteria The Design by Feature process has completed. Tasks Class owners implement the classes. Verification

Successful Code Inspection & Unit Testing


Exit criteria

Iterations of Design by Feature & Build by Feature Processes (8/8)

AUP (

Agile Unified Process)

Model

Implementation
Test Deployment Configuration Management

Project Management
Environment

Agile unified process

Agile Unified Process

Phases
Disciplines Philosophies

Releases

Disciplines
Model

Understand business & problem domain


Identify a viable solution Transform model(s) into executable code Ensure quality Verify that requirements are met

Implementation

Test

Disciplines
Deployment

Make system available to end users


Manage access to project artifacts Control and manage changes Managing risks, directing and coordinating people

Configuration Management

Project management

Disciplines
Environment

Ensuring a proper process, guidance and tools

Releases

Development release iteration


Deployment to QA or demo area

Production release iteration


Deployment to production area

SCRUM
Product Owner

Is (or is the representative of) the Customer

Develops and maintains the Product Backlog Prioritizes the Product Backlog Empowered to make decisions for all customers and users Presents and explains Product Backlog to team Scrum Team

Performs the work directed by the Customer

Self-organizing Business and technical skills to build an increment of functionality Responsible for estimating and committing to work Full autonomy and authority during a Sprint

ScrumMaster

Guides the Agile Execution

Responsible for the process Responsible for maximizing team productivity Sets up and conducts meetings Representative to management and team Characteristics of a border collie or sheepdog

How Scrum Works?

The Key Components of Agile

User Stories Simple statements of requirements written


from the customer's point of view. , user need to be able to retrieve and update vendor address information.

Product Backlog Collection of user stories that need to


be addressed to consider the effort (Product) complete.

Sprint A fixed length work period in which items taken from


the backlog are satisfied. An Agile project is a sequence of sprints.

Sprint Planning Session A team meeting in which the


product owner reviews and explains each backlog items and its priority, the other team members task out the items and commit (or not) to performing each item, and the agile coach sets up the sprint management tools.

Sprint Review Session At the closure of each sprint,


work completed is presented and reviewed, lessons learned discussed, the overall sprint is evaluated and reviewed.

Sprints
Scrum projects make progress in a series of sprints

Analogous to XP iterations
+/- a week or two
But, a constant duration leads to a better rhythm

Target duration is one month

Product is designed, coded, and tested during the sprint

No changes during the sprint

Change

Inputs

Sprint

Tested Code

Plan sprint durations around how long you can commit to keeping change out of the sprint

Scrum Framework
Roles : Product Owner, ScrumMaster, Team

Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting
Artifacts : Product Backlog, Sprint Backlog, and Burndown Chart

Product Owner
Define the features of the product

Decide on release date and content


Be responsible for the profitability of the product (ROI) Prioritize features according to market value Adjust features and priority every iteration, as needed

Accept or reject work results.

The Scrum Master Represents management to the project


Responsible for 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

Scrum Team Typically 5-10 people


Cross-functional
QA, Programmers, UI Designers, etc.

Members should be full-time


May be exceptions (e.g., System Admin, etc.)

Teams are self-organizing


What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility

Membership can change only between sprints

Ceremonies
Sprint Planning Meeting

Sprint
Daily Scrum Sprint Review Meeting

Spring Planning Meeting

Product Backlog Team Capabilities Sprint Goal

Sprint Planning
Business Conditions Technology Current Product

Meeting

Sprint Backlog

Parts of Sprint Planning Meeting


1st Part:

Creating Product Backlog


Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team

2nd Part:

Participants: Scrum Master, Scrum Team


Creating Sprint Backlog

Pre-Project/Kickoff Meeting
A special form of Sprint Planning Meeting

Meeting before the begin of the Project

Sprint
A month-long iteration, during which is incremented a product functionality

NO outside influence can interfere with the Scrum team during the Sprint
Each Sprint begins with the Daily Scrum Meeting

Daily Scrum Parameters


Daily 15-minutes Stand-up

Not for problem solving

Three questions:
1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way?

Daily Scrum
Is NOT a problem solving session

Is NOT a way to collect information about WHO is behind the schedule


Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to track the progress of the Team

Scrum FAQs Why daily?


How does a project get to be a year late? One day at a time. Fred Brooks, The Mythical Man-Month.

Can Scrum meetings be replaced by emailed status reports?


No

Entire team sees the whole picture every day


Create peer pressure to do what you say youll do

Team presents what it accomplished during the sprint

Sprint Review Meeting

Typically takes the form of a demo of new features or underlying architecture


Informal
2-hour prep time rule

Participants
Customers Management Product Owner Other engineers

Sprint Retrospective Meeting


Scrum Team only

Feedback meeting
Three questions Start Stop

Continue

Dont skip for the first 5-6 sprints!!!

Product Backlog
A list of all desired work on the project

Usually a combination of
story-based work (let user search and replace) task-based work (improve exception handling)

List is prioritized by the Product Owner

Typically a Product Manager, Marketing, Internal Customer, etc.

Product Backlog
Requirements for a system, expressed as a prioritized list of Backlog Items

Is managed and owned by a Product Owner


Spreadsheet (typically) Usually is created during the Sprint Planning Meeting Can be changed and re-prioritized before each PM

Sample Product Backlog

Sprint Burn down Chart


Depicts the total Sprint Backlog hours remaining per day

Shows the estimated amount of time to release


Ideally should burn down to zero to the end of the Sprint Actually is not a straight line Can bump UP

Release Burndown Chart


Will the release be done on right time?

X-axis: sprints
Y-axis: amount of hours remaining The estimated work remaining can also burn up

Product Burndown Chart


Is a big picture view of projects progress (all the releases)