FAZAL WAHAB

Agile Software Development

What is Agile?

An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets thechanging needs of its stakeholders.

Core principles “Fits just right” process Continuous testing and validation Consistent team collaboration Rapid response to change Ongoing customer involvement Frequent delivery of working software

How Agile is Different

Focus on collaboration: Less paperwork and more conversation Stakeholders actively involved

Focus on working software: Greater feedback makes agile projects easier to manage Less documentation is required Less bureaucracy

Agilists are generalizing specialists: Less hand offs between people Less people required Specialists find it difficult at first to fit into the team

Agile is based on practice, not theory: This is a significant change from traditional You need to see how agile works in practice to truly understand it

Myth busters

Myth1. No Documentation 2. Undisciplined 3. No Planning4. Not Predictable5. Does Not Scale6. Is a Fad7. Silver Bullet8. RUP isn’t agile9. Not Fixed Price

Reality1. Agile Documentation2. Requires great discipline3. Just-in-time (JIT) planning4. Far more predictable5. Eclipse is agile6. It’s quickly becoming the

norm7. It requires skilled people8. RUP is as agile as you make

it9. Agile provides stakeholders

control over the budget, schedule, and scope

Why Agile Workswww.ambysoft.com/essays/whyAgileWorksFeedback.htm

Agile Development Practices

Regular Delivery of Working Software Only valid measure of progress Provides visible results to stakeholders True earned value, not documentation-based “earned

value”Daily Stakeholder Interaction

On-Site Customer Active Stakeholder Participation Product Owner

Continuous Integration Automatically compile, test, and style check your code Continuous code integration is nice Continuous system integration is nicer

Test First Design (TFD)www.agiledata.org/essays/tdd.html

With TFD you write a single test and then just enough production code to fulfill that test

Test-Driven Development (TDD) = Refactoring + TFD

TDD is a just-in-time (JIT) specification activity

TDD is a continuous confirmatory validation activity

TDD via Customer/Acceptance Tests Specification of requirements

TDD via Developer Tests Specification of design

TDD is also called Behavior Driven Development (BDD)

Other Agile Quality Practices

Non-solo development Pair programming Modeling with others Effectively continuous inspections

Following guidance Coding practices Database standards User interface (UI) standards Modeling style guidelines (www.agilemodeling.com/style)

Refactoring Small change to your code which improves the quality of the

design without changing the semantics Code refactoring UI refactoring Database refactoring

Working in Priority Order: Agile Change Managementwww.agilemodeling.com/essays/agileRequirements.htm

Agile Model Driven Development (AMDD)www.agilemodeling.com/essays/amdd.htm

Do just enough initial envisioning to understand the scope and technical direction

Model storm on a just-in-time basis to gather the details when you need them

31.8

53.4

68.2

66.7

85.5

47

65.9

77.2

77.7

92.7

0 20 40 60 80 100

CASE Tool Modeling

Paper Modeling

Init. Agile Arch. Modeling

Init. Agile Req. Modeling

Whiteboard Sketching

% Finding it Useful % Applying Technique

Agile User Experience (UEX)

Observations: User interface (UI) and usability issues are critical to the

success of most systems The UI is the system to the end user Few developers have solid UEX skills, although many think they

doAdvice:

Everyone should have some UEX training Have someone with UEX expertise within your organization,

and ensure that they pair regularly Part of initial envisioning should address UEX issues UEX issues will need to be addressed throughout development Recognize that few of us are building the iPod, but when we

tread into new territory we may need to do more up-front work than usual

Maximize stakeholder ROI Are treated as a requirementHave a specific customer and facilitate the

work efforts of that customer Are conciseFulfill a purpose Describe information that is less likely to

change Describe “good things to know”Are sufficiently accurate, consistent, and

detailed – But aren’t perfect

Agile Documentation Practiceswww.agilemodeling.com/essays/agileDocumentation.htm

Challenges with Agile in the Mainstream

Agile Development

Co-located

Geographical distribution

Global

Compliance requirement

Low risk Critical,Audited

Application complexitySimple, single platform

Complex, multi-platform

Team size

Under 10developers

100’s ofdevelopers

Organization distribution(outsourcing, partnerships)

In-house Third party

Degree of Governance

Informal Formal

Entrenched process, people, and policy

Minimal Significant

Scaling TDD: Agile Model Driven Development (AMDD) www.agilemodeling.com/essays/amdd.htm

The Generic Agile Lifecycle

References and Recommended Reading

www.agilealliance.com www.agilemodeling.com www.agiledata.org www.enterpriseunifiedprocess.com www.ibm.com/rational/agile/ Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and

the UP. New York: John Wiley & Sons. Ambler, S.W. (2003). Agile Database Techniques. New York: John

Wiley & Sons. Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with

UML 2. New York: Cambridge University Press. Ambler, S.W. and Sadalage, P.J. (2006). Refactoring Databases:

Evolutionary Database Design. Reading, MA: Addison Wesley Longman, Inc.

Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA: Addison Wesley

McGovern, J., Ambler, S.W., Stevens, M., Linn, J., Sharan, V., & Jo, E. (2003). The Practical Guide to Enterprise Architecture. Prentice Hall PTR.