cse senior design i project recovery the slides in this presentation are derived from materials in...
TRANSCRIPT
CSE Senior Design ICSE Senior Design I
Project RecoveryProject Recovery
The slides in this presentation are derived from materials in the textbook used for CSE 4316/4317, Rapid Development: Taming Wild
Software Schedules, by Steve McConnell.
Instructor: Mike O’DellInstructor: Mike O’Dell
8
2
A Project in Trouble (C.S. 16-1)A Project in Trouble (C.S. 16-1)
What was the first indicationfirst indication of trouble?How was the recovery planrecovery plan developed?What was the recovery plan?Mythical man-monthMythical man-month?Signs of denialdenial? DefensivenessDefensiveness?Was the problem that people weren’t
working hardworking hard enough?
8
3
Characteristics of a Project in Need Characteristics of a Project in Need of a Recovery Planof a Recovery Plan
No one knowsNo one knows when they will finish, and can’t even guess
Product quality has plummetedquality has plummeted and defects are on the rise
Everyone is working long, hard hoursworking long, hard hoursPeer-pressure and management
pressure is on the risepressure is on the riseStake holder confidence is low/lostconfidence is low/lost
8
4
Characteristics of a Project in Need Characteristics of a Project in Need of a Recovery Planof a Recovery Plan
Developers become defensivedefensive of their progress
Project team (development, marketing, management, etc.) relationships deteriorate… finger relationships deteriorate… finger pointingpointing
MoraleMorale is at rock bottomCancellationCancellation appears imminentNo one's having any funfun anymore
8
5
How to Get Things Back on How to Get Things Back on TrackTrack
ThreeThree fundamental approaches:1. Increase productivity by focusing on
short-term gains2. Cut the size of the project so it can be
completed within the time and effort planned
3. Face the facts – slip the schedule, do damage control, possibly cancel the project
Or (usually best), combine these threecombine these three: Drop a few featuresfeatures, increase
productivityproductivity when possible, slip the scheduleschedule as necessary
8
6
Recovery Plan BasicsRecovery Plan Basics
One plan does not fit all Adopt a plan that is right for where where
you areyou are on your projectyour projectIt almost never helps to…
Cut corners (“not enough time to…”) Add people (mythical man-month) Rely on silver bullets (there’s no
“magic” )
8
7
First StepsFirst Steps
AssessAssess – figure out where you areRecognize that significant actionsignificant action is
required Same ol’, same ol’ won’t work!
Apply Theory-W analysisTheory-W analysis What do all stakeholders need at this
point? How does everyone win?
8 Theory-W ManagementTheory-W Management
Customers Bosses Developers
End-Users Maintainers
Quick Schedule
No Overruns Interesting Work
Loss of Features
No Defects
Low Budget No Surprises Exploration of New Technology
User-friendly Software
Good Docs.
Meets Requirements
Successful Project
No Grunt Work
Fast Software
Easy Modifiability
A Life Robust Software
8
Everyone Everyone WWinsins
8
9
More First StepsMore First Steps
AskAsk the team what needs to be done Involve everyoneeveryone Evaluate all ideas
Be realistic about your team’s ability to recover Avoid over-committingover-committing (again?) Objectively evaluate your abilityevaluate your ability to
estimate, and adjust accordingly
8
11
A Recovery PlanA Recovery Plan
Three components (the 3 P’s) PeoplePeople… fix these problems and you
will get the most leverage toward getting the project back on track
ProcessProcess… fix these problems or your recovery plan will fail
Product/TechnologyProduct/Technology… getting the feature-set under control and minimized is critical to project/product stability
8
12
Dealing with Dealing with PeoplePeople Problems Problems
Address the moralemorale of the team Critical to productivity Potential Approaches
Sacrifice the sacred cowsTake explicit action that makes the
development team feel importantRemove unreasonable schedule pressureRemove micro-management practices
8
13
Dealing with Dealing with PeoplePeople Problems Problems
Deal with “problem people”“problem people” Recall discussion of “Welch Grid”
Deal with major leadershipleadership problems Is the project leader who got you in
this hole the right one to get you out? Identify where on the team the
leadership is weak
8
14
Dealing with Dealing with PeoplePeople Problems Problems
Add people Add people very carefullyvery carefully, if at all, if at all Brooks’s Law: Adding people to a late
project is like pouring gasoline on fire! Consider adding only if project can be
partitioned to isolate new people Err on the side of NOT adding people
Focus…Focus… Removing distractionsdistractions wherever possible
8
15
Managing the Managing the ProcessProcess
Identify and Fix Classic Mistakes StabilizeStabilize product definition, design Shore up control and trackingcontrol and tracking Validate product qualityquality Verify (and re-verify) the new scheduleschedule Validate your tools tools (any silver-bullets?) Shore up accountabilityaccountability
8
16
Managing the Managing the ProcessProcess
Identify and fix things that are clearly broken or not working Take decisivedecisive action
Create “mini-milestones” Miniature, binary and exhaustive
Miniature- completed in days, not weeksBinary- done or not doneExhaustive- when last is done, project is
done Monitor progress with finer finer
granularitygranularity
Always a Best Practice
8
17
Managing the Managing the ProcessProcess
TrackTrack schedule progress meticulously Make sure “done” is 100% done Ask “the next question” Calibrate and recalibrateCalibrate and recalibrate your schedule Expect additional work (over-time) to
make up slips on a mini-milestoneRecord reasons for missed milestones
Look for and fix underlying causesfix underlying causes
8
18
Managing the Managing the ProcessProcess
RecalibrateRecalibrate the recovery plan after a short time after 1 or 2 weeks Don’t let things get away from you
againMake every recovery schedule a
meaningful one Don’t give in to pressure or create
“off-the-cuff” estimatesPainstakingly manage risksmanage risks
8
19
Reining in the Reining in the ProductProduct
StabilizeStabilize the requirements Unstable, changing requirements may
be the root causeroot cause of all your problems May need to restart requirements restart requirements
phasephase Implement a rigid change evaluationrigid change evaluation
process for any further changes Implement minimum time delayminimum time delay to
even consider further change
8
20
Reining in the Reining in the ProductProduct
TrimTrim the feature set Prioritize/Re-prioritize features Focus on features that create best
possible product at this time Relegate low-priority features to the
next release Minimize, minimize, minimize…
8
21
Reining in the Reining in the ProductProduct
Take out the garbagegarbage Eliminate low quality components…
carefully! Redo them from the beginningfrom the beginning if they
are critically needed Systematic redesign and
implementation will reduce your risk!
8
22
Reining in the Reining in the ProductProduct
Systematically reduce and manageSystematically reduce and manage further defects Track progress dailyTrack progress daily…
#open, #fixed, #resolved Don’t try to take short-cutsshort-cuts… short-
cutting the fix inevitably results in more defects
Use design and code reviews on reviews on every moduleevery module that you touch
8
23
Reining in the Reining in the ProductProduct
Identify a known good stateIdentify a known good state and build on it Use as basebase for further work Daily build and test cycle Make maintaining the buildmaintaining the build each day
a top priority Consider a “developers on call”
approach
8
24
Timing Your Recovery PlanTiming Your Recovery Plan
Need to find right balanceright balance between: Too early – people won’t believe there
is a problem, so they won’t take your plan seriously
Too late – you’re probably already in a recovery mode, having implemented numerous mini-plans, and your credibility will already be damaged