View
221
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended