Best Practices

1
Best Practices

• CS4320
• Fall 2002

2
A technology digression
The space shuttle
3
What are best practices?

• Good practice comes from experience, and
  experience comes from bad practice.
• Fred Brooks

a technique or methodology that, through
experience and research, has proven to reliably
lead to a desired result.
4
Rational Best Practices

• http//www.rational.com/media/whitepapers/rup_best
  practices.pdf
• Develop software iteratively
• Mange Requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software

5
Evaluate Best Practices

• Potential reduction of schedule
• Improvement of project visibility
• Effect on development risk
• Improved use of resources
• Improvement in quality
• Chance of success

6
Some best practices we already discussed.

• Change Board (Configuration Control Board) 17
• Evolutionary Delivery 20
• Evolutionary Prototyping 21
• Inspections 23
• Joint Application Development 24
• Lifecycle Model Selection 25
• Spiral Lifecycle Model 35
• Theory-W Management 37
• Throwaway Prototyping 38
• Top Ten Risk List 41

7
Daily Build and Smoke Test

• Build product every day
• Smoke test each build (fry when turned on?)
• Reduces Risks
• Integration
• Low quality
• Poor visibility (90 done problem)
• Improves
• Morale
• Visibilty
• Customer relations

8
D-B-S Process

• Create build group
• Add code to build when it makes sense
• Make developers responsible for own smoke test
• Keep holding area for code added to build
• Create penalty for breaking build
• Release builds each morning
• Build and smoke even under pressure

9
Miniature Milestones

• Fine-grained project tracking
• Useful for project recovery activities
• Useful with daily build and smoke
• Trades more project tracking for more visibility
  and control
• Think of pioneers going west using landmarks

10
M-M Process

• Start early
• Let developers create own milestones
• Keep them mini (1-2 days)
• Make them binary
• Make them exhaustive
• Use only for short-term planning
• Assess progress and recalibrate

11
Signing Up

• Tries to increase motivation of developers
• Makes it their project (module, class )
• Risks
• Increase inefficiency
• Reduce visibility
• Reduce talent pool
• Burnout

12
Sign Up Process

• Frame a vision
• Give developers a choice
• Sign up at team level
• Empower team
• Dont use if requirements shaky
• Monitor mistakes
• Watch developer workload

13
Timebox Development

• Create a sense of urgency during coding
• Redefine product to fit schedule
• Usually for in-house software
• Have to be willing to cut features
• Risks
• Sacrifice quality instead of features
• Use on inappropriate projects
• Need to use with prototyping
• Clarify feature priorities

14
Timebox Process

• Create prioritized list of features
• Create realistic schedule
• Map features to schedule
• Select right kind of project (60-120 days)
• Get end-user involved