3. Approach is simple
It is more disciplined
Is well structured
the model itself progresses linearly through
discrete, easily understandable and
explainable phases
Provides easily markable milestones in the
development process.
4. "Many times, thinking things out in advance saved us serious
development headaches later on. ... [on making a particular
specification change] ...
Making this change in the spec took an hour or two. If we had
made this change in code, it would have added weeks to the
schedule. I can’t tell you how strongly I believe in Big Design Up
Front, which the proponents of Extreme Programming consider
anathema.
I have consistently saved time and made better products by using
BDUF and I’m proud to use it, no matter what the XP fanatics
claim. They’re just wrong on this point and I can’t be any clearer
than that.“
- Joel Spolsky
5. Software projects that are stable
Unchanging requirements
Where it is possible that designers will be
able to fully predict problems
Where it is possible that designers produce a
correct design
6.
7. A bug found in the early stages is cheaper in
money, effort, and time, to fix than the same
bug found later on in the process.
An early defect that is left undetected until
development or maintenance is estimated to
cost 50 to 200 times as much to fix as it
would have cost to fix at requirements time
8. BDUF is poorly adaptable to changing requirements
BDUF assumes that designers are able to foresee
problems without extensive prototyping.
There is an overhead to be balanced between the time
spent planning and the time that fixing a defect would
actually cost.
In most projects there is a significant lack of
comprehensive written requirements.
In BDUF a lot of assumptions are made that later
prove to be false
e.g. The program's design should be perfect
before people begin to implement the design
9. Doesn’t handle change very well
Requirements specifications are an abstraction
and can be interpreted differently
Business engagement is high at the start of the
project but then tapers off
Insufficient testing during development
Late integration
QA is trailer-hitched, so quality isn’t baked in
and testing gets crunched at the end
Progress measured by task % complete
Often don’t know until it’s too late
Whole project planned up-front
10.
11. 16.1 % of projects as successful
31.1% of software development projects get cancelled
52.7% do not meet their original cost
Conclusion:
The organization is immature and to aim for more
maturity
More requirements documentation, more analysis,
more planning and tracking
12. "The Roman bridges of antiquity were very
inefficient structures.
By modern standards, they used too much
stone, and as a result, far too much labour to
build.
Over the years we have learned to build
bridges more efficiently, using fewer
materials and less labour to perform the
same task.―
-Tom Clancy (The Sum of All Fears)
17. Adaptive, empirical process
Small repeating cycles
Short-term planning with constant feedback,
inspection and adaptation
Fail-early lifecycle
18. Breaks complex projects down into simpler mini-projects
Accommodates change easily
Improves ROI
Increased business involvement and satisfaction
Increased visibility
Lower development risk, higher quality, less defects
Produce incremental product quickly
Progress measured by running tested software
Early and regular process improvement
19. 35 % of projects as successful
19% of software development projects get
cancelled
46% do not meet their original cost
three reasons for the improvement in
software quality—better project management,
iterative development and the emerging Web
infrastructure.
20.
21.
22.
23. Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
24. 1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, co-operation between business people and developers
7. Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be
trusted
8. Continuous attention to technical excellence and good design
9. Simplicity
10. Self-organizing teams
11. Regular adaptation to changing circumstances
25. Agile Modeling
Agile Unified Process (AUP)
Dynamic Systems Development Method
(DSDM)
Essential Unified Process (EssUP)
Extreme Programming (XP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Scrum
Velocity tracking
27. Simple and scaleable
Empirical process
Short-term detailed planning with constant feedback
provides simple inspect and adapt cycle
Simple techniques and work artifacts
Requirements are captured as user stories in a list of
product backlog
Progress is made in Sprints
Teams collaborating with the Product Owner
Optimises working environment
Reduces organisational overhead
Detects everything that gets in the way of delivery
Fosters openness and demands visibility
28. Contains all potential features, prioritized as an
absolute ordering by business value.
It is therefore the ―What‖ that will be built, sorted
by importance.
It contains rough estimates of both business
value and development effort.
Those estimates help the Product Owner to
gauge the timeline and, to a limited extent
prioritize.
29. Captures Product Vision
Represents the voice of the customer
Creates initial Product Backlog
Writes customer-centric items
Helps set the direction of the product
Accountable for ensuring that the Team delivers value to the
business
Responsible for:
◦ Product Backlog
◦ Prioritization
30. Using story points instead of hours
numeric sizing (1 through 10)
t-shirt sizes (XS, S, M, L, XL, XXL, XXXL)
Powers-of-2 (1,2,4,8...)
the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
Planning Poker
Basing on historical trends
The best people to make the estimates are the people who build the
product.
31. These are the people who build products,
make estimates
Scrum recommends team sizes of 7
The teams are cross functional
32. Combination of Coach, Fixer and Gatekeeper.
Make sure the project is progressing
smoothly
Every team member has the tool they need to
get the job done
Sets meetings
Monitors the work done
Facilitates release planning
to protect the team and keep them focused
on the tasks at hand
servant-leader
33. Three core roles and a range of ancillary roles
Core Scrum roles:
◦ Product Owner
◦ Team
◦ Scrum Master
Ancillary roles:
◦ Stakeholders (customers, vendors)
◦ Managers (including Project Managers)
34.
35. Start with the Product Backlog items
Identify features to put into release
Team prioritizes the features
36. Is an iteration
Can have 1 day of sprint planning, 4 days of work
and 1 day of sprint review
Sprints are short duration milestones
Sprints range from a couple of days to 30 days
Need atleast 4 to a dozen sprints to get to the
release
37. Break Release backlog items into several
tasks
each sprint should deliver a fully tested
product with all the features of that sprint
backlog 100% complete
late finish of the sprint is a great indicator
that the project is not on schedule
38.
39. Actual estimates for each
feature in the backlog
during the initial planning
process
40. Actual estimates for each
feature in the backlog
during the initial planning
process
Daily progress on one
ore more features is
updated by team
member by updating the
amount of time
remaining for each of
their items
41.
42. Tracks bugs separately from features in their
own Defect Backlog
Any bug found relating to the feature should
be dealt with immediately before marking the
feature complete
Plan for 1-2 sprints focused only on Defect
backlogs
43. Should not last more than 15 minutes.
The meeting starts precisely on time.
Every team member has to answer 3
questions –
◦ What have I done since last meeting?
◦ What will I do until next meeting?
◦ What problems do I have?
ScrumMaster to facilitate resolution of these
impediments
resolution should occur outside the Daily
Scrum itself to keep it under 15 minutes
46. Preliminary project stage or evaluation phase
◦ essentially R&D costs, and are charged to opex
Software development or application
configuration phase.
◦ Capex, because the end result is an asset.
Post implementation or production phase
◦ This is opex because these are day-to-day running
costs
47. Enterprise software licenses are capex, but the
corresponding annual maintenance costs are opex.
Functional design is opex and technical design is capex,
but the border between the two can be blurred when done
by collaborative teams.
Production upgrades or enhancements are capitalizable,
whereas maintenance and bug fixing are not, even though
they both have development costs.
An ERP-to-CRM order entry interface is a capital cost,
whereas a one-time ERP-to-CRM data migration interface
is an expense.
Software as a Service or SaaS is pure opex. Even if you end
up customizing a SaaS application, the development costs
will still be opex because you are renting.
48. it is not the activity in itself that is
capitalizable, but rather the outcome of that
activity and the ownership of the resulting
asset.
49. According to FASB, technological feasibility can be
based on either a detailed design or a working
product:
◦ Detailed design: ―The detail design of a computer software
product that takes product function, feature, and technical
requirements to their most detailed, logical form and is
ready for coding‖.
◦ Working model (or prototype): ―An operative version of the
computer software product that is completed in the same
software language as the product to be ultimately
marketed, performs all the major functions planned for the
product, and is ready for initial customer testing (usually
identified as beta testing)‖
50. In Scrum, technological feasibility is reached after
a number of iterations after which capitalization
can start
Amount of development costs which can be
capitalized is less as compared to waterfall’s
detailed design up-front approach
Iterative development generally requires far less
time to reach technological feasibility compared
to waterfall, which is heavily front-loaded with
opex prior to the start of development.
51. A waterfall or an agile project can be developed and run
either on-premises or in the cloud
For IaaS and PaaS
◦ Capex vs opex rules apply when developing the software using
agile or waterfall.
For Saas,
◦ There is no software assets created by the client
◦ So, even if you end up customizing your SaaS CRM application, for
example, the development costs will still be opex because you are
renting. You don’t own the asset, ie it doesn’t sit on your
company’s balance sheet.
Public SaaS is therefore pure opex, and the capex vs opex
rules for waterfall and agile do not apply.
52. Lean startup solutions
We help you answer the question-‖Can a sustainable business be
built around this set of products and services?‖ and ―How can
we raise investment to do so?‖ We help startups follow the lean
startup approach by providing tools to test a vision
continuously.
We help you right from building each component of a sustainable
business model to weaving a financial model based on
extensive market research to producing VC-friendly attractive
data driven business plans.
We strictly follow the Lean Startup methodologies and tools
throughout our approach to help you solve real problems and
provide detailed specifications of what needs to be done to
build solution.
53. ValueFacture Lean Startup Consultant
http://www.valuefacture.in
Email me at
◦ Mohan@valuefacture.com
◦ Mohan.Late@gmail.com
Skype me at
◦ mohan.late
Disclaimer : No animals (pigs/chickens) were harmed in the making of this presentation.
