SOFTWARE SYSTEMS DEVELOPMENT

6: Agile/Lean Development

The problem with software development

1.3% of in improvement of success rate per year50% of success in 2020

Lean Production and Development Pioneered by Toyota

Cheap Cars->Mass Production Small Japanese Market How to make car in small quantities for

reasonable cost? Lean Manufacturing Lean Product Development Lean Project Management Lean Software Development

Lean Family

Production: “Keep it running”Development: Deliver

Lean: Seven Simple Rules/Principles

Eliminate Waste: spend time only on what adds real customer value

Amplify Learning: When you have tough problems, increase feedback

Decide as late as possible: Until a decision can be made based on facts and not on uncertain assumptions and predictions

Deliver as fast as possible: Deliver value to customers as soon as they ask for it

Empower the team: Let the people who add value use their full potential

Build integrity in: Don’t try to tack on integrity after the fact – build it in. The result of your work must not look like a collection of small solutions, but as one integral system.

See the whole: Beware of the temptation to optimize parts at the expense of the whole. customers see the whole organization as they see its worst element

7 Wastes

 

•Transportation (moving products that is not actually required to perform the processing)

•Inventory (all components, work in process and finished product not being processed)

•Motion (people or equipment moving or walking more than is required to perform the processing)

•Waiting (waiting for the next production step)

•Overproduction (production ahead of demand)

•Over Processing (resulting from poor tool or product design creating activity)

•Defects (the effort involved in inspecting for and fixing defects)

7 wastes of software development Inventory=>Partially Done Work

Never know if it works/solve the problem till it’s done

Extra Processing->Unnecessary Paperwork Overproduction->Extra Features Transportation->Task Switching

Task switching overhead up to 25% Waiting->Waiting (decisions, reviews etc.) Motion->Finding Information Defects->Undetected or late discovery

Development vs. Production in Software

Development/Design is risky, expensive and difficult to predict

Construction/Production is easier to predict Where is the line in the software?

Design vs. Coding Waterfall model (e.g. Requirements->UML->C++)

Coding vs. Compilation Production is free Iterative Models (coding is part of the design effort)

The Agile Manifesto

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. “

Some other Agile principles

Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-

location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

The Agile Methodologies

Extreme Programming(XP) Only essential activities: Activities: Listening, Coding, Testing

Scrum Only essential responsibilities: Roles: Team, Master (manage process), Owner

(represent customers) Feature Driven Development

Manage by features Plan, Design, Build and Deliver by Features

Test Driven Development Manage by Tests Plan , Design, Build and Deliver by test cases

Agile vs. Cowboy Coding

Eliminate waste does not mean throw away all documentation.

Amplify learning does not mean keep on changing your mind.

Decide as late as possible does not mean procrastinate.

Deliver as fast as possible does not mean rush and do sloppy work.

Empower the team does not mean abandon leadership.

Build integrity in does not mean big, upfront design. See the whole does not mean ignore the details.

SCRUM

Extreme Programming

Taking proven practices to the extreme If testing is good, let everybody test all the time If code reviews are good, review all the time If design is good, refactor all the time If integration testing is good, integrate all the

time If simplicity is good, do the simplest thing that

could possibly work If short iterations are good, make them really,

really short

XP: Pair Programming

Two people looking at one machine, with one keyboard and one mouse

Two roles: implementation and strategy

All production code is written in pairs

XP: Simple design

Do the simplest thing that could possibly work

Passes all the tests No duplicate code States every intention Fewest possible classes and methods

XP: Refactoring

Design becomes everybody’s daily business

Continuously improve quality of the code Unit Tests and Pair Programming give

courage

Result: Fast development speed Code becomes easy to change

18

Test-Driven Development

“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

TDD is a technique whereby you write your test cases before you write any implementation code

Tests drive or dictate the code that is developed

TDD

Feature-Driven Development

1.Develop an

Overall Model

2.Build aFeature

List

3.PlanBy

Feature

4.DesignBy

Feature

5.BuildBy

Feature

Wide rather than deep

MarketingparticipatesMRD input

CarefullyAnalyze

MRD

Prioritize and planCode development

Build code in small batches

Deep rather than wide

Code Refactoring: Some Bad Smells in code

Code that can make the design harder to change: Long methods Big Classes Big switch statements Un-encapsulated fields Duplicate code Data Classes