The document discusses principles of lean development and feature driven development (FDD). It outlines five principles of lean development: decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole. It then provides examples to illustrate each principle. The document also provides an overview of FDD, outlining its activities of developing an overall model, building a feature list, planning by feature, designing by feature, and building by feature. It describes the develop overall model activity in more detail.

1. Samra Siddiqui

2.  Lean Development
 Feature Driven Development

3.  Decide as late as possible
 As software development is always associated with some
uncertainty, better results should be achieved with an
options-based approach.
 Delaying decisions as much as possible until they can be
made based on facts and not on uncertain assumptions
and predictions.
 Delaying certain crucial decisions until customers have
realized their needs better.
3

4.  Deliver as fast as possible
 It is not the biggest that survives, but the fastest.
 The sooner the end product is delivered without
considerable defect, the sooner feedback can be received,
and incorporated into the next iteration.
 Customers value rapid delivery of a quality product.
4

5.  Empower theTeam
 Traditional belief: the managers tell the workers how to do their
own job .
 Lean approach: "find good people and let them do their own job”
 Encouraging progress, catching errors, and removing problems, but
not micro-managing.
 The developers should be given access to customer ; the team
leader should provide support and help in difficult situations.
5

6.  Build Integrity in
 Balance of function, usability, reliability and economy – perceived integrity
 Conceptual integrity - anywhere you look in your system, you can tell that the
design is part of the same overall design.
 One of the healthy ways towards integral architecture is refactoring. Repetitions in
the code are signs for bad code designs and should be avoided.
 At the end the integrity should be verified with thorough testing, thus ensuring the
System does what the customer expects it to and specifically the reduction of
defects
6

7.  See the Whole
 Software systems are not simply the sum of their parts,
but also the product of their interactions.
 The best parts do not necessarily make the best system.
 Ability of a system to achieve its purpose depends on how
well the parts work together, not just how well they
perform individually.
7

8.  The Client has asked for a simple calculator to perform
addition of two numbers.
 The Decision makers in delivery Team (Architects,
Analysts) planned for addition of two numbers and an
added benefit to customer for providing multiplication.
 As multiplication is nothing but adding the same number
as many times. E.g. 2 x 5 is same as adding 2 five times.
2+2+2+2+2.
 The time of Analyzing, Developing and Testing is spent.
Product is delivered to customer and they are using it only
for addition of 2 numbers.
 What should be considered as waste here?

9. •Introduction
•FDDActivities
•Mile Stones
•Practices in FDD
9

10.  Feature-driven development (FDD) is an iterative and
incremental software development process.
 Its main purpose is to deliver tangible, working software
repeatedly in a timely manner
 Activities
 Develop Overall Model
 Build Feature List
 Plan By Feature
 Design By Feature
 Build By Feature
10

12. Develop Overall Model
 High-level walkthrough of the scope of the system and its
context by domain members.
 More detailed walkthroughs are held for each area of
problem domain.
 After each walkthrough, the domain and development
members work in small groups to produce object models
for that area of the domain.
 It will be refined in process IV.
12