ap-1 5. project management. ap-2 software failure software fails at a significant rate what is...

AP-1Venkat SubramaniamVenkat Subramaniam

5. Project Management


Software Failure• Software fails at a significant rate

• What is failure?

• Not delivering it on time is an estimation failure

• Delivering a program that does not meet the customers needs is a project failure


Why such a high failure rate?• Is software development really software

engineering?• Do the estimation and planning from

engineering really apply to SW development

• Craig Larman talks about Inventive projects vs. predictive manufacturing


Goals in project management• Deliver high quality software, within

budget, on time, meeting the customers requirements

• There are a few ways to succeed; many ways to fail


Software Manager• Often a thankless job!• You are responsible for

– Writing proposals– Estimating cost– Getting funding– Planning and scheduling– Monitoring progress– Select and retain talented workers– Report progress and make presentations


Project Planning• What is planning?

• Deciding on a course of action

• Considering the strengths and risks

• Estimating and projecting the path of action


Critical Planning?• Planning is important• You have to anticipate problems and

prepare for those in advance• You are relying on what you know initially

to come up with the best plan you can• You are then using this plan to drive your

efforts

• What’s wrong with that?– How will you address that concern?


What do you plan for?• You have to plan for

– Staffing

– Standards and procedures

– Quality Assurance & System Validation

– Configuration management

– Maintenance


Milestones• Each stage of the project needs to be

monitored• Milestones can help measure the

progress• Where do you stand with project

development?• Logical, measurable results need to be

presented• Deliverables are what you give your

customers at the end of a major phase


Software Estimation• How do you estimate?

• What influences your ability to estimate?

• What affects your ability to estimate?

• So, how can we be effective in estimation?


Scheduling• Estimates vary between projects, unless

projects are very similar• How true are the timesheets, if you decide to

rely on them?• Contingency planning is needed – there will be

unexpected tasks, be ready to handle them• Need to update the schedule continually• The finer the granularity of the task you

measure, the closer you may get to the reality – plan for a couple of weeks to a few months, not any more


Problem with planning?

“Plans are nothing. Planning is everything,” Dwight D. Eisenhower

“No plan survives contact with the enemy,” Helmuth von Moltke


Agile Planning• It is more important to be successful in a

project than staying with a plan

• Agile Software Practices focus on changing to suite the needs than sticking with a plan that has been developed


Requirements: Why is it hard?• Interesting we use the word “capture”

with requirements• How can you get a good understanding

on requirements?• Users do not want to give it, we do not

get it• How can we then succeed with

understanding requirements and delivering it


Minimizing Risk• Let’s see how to increase risk, then we

can avoid those– Keep the product away from eyes of

customer– Long time between getting requirements and

seeking feedback– Jump into implementing a concept without

understanding the consequences– We can make decisions along the way if we

do not know what it means– Consult the manager to make a business

decision


Development Process

time

User Stories

Significantones


Exploration and Scoping• During project initiation, exploration helps

in understanding the depth of involvement

• Duration often few weeks• How much will it cost?• How big is the project?• Should we proceed or not?• May be write some prototypes, identify

risks, get a better understanding


Estimation• Accurate estimation is hard• Estimation comes from

– Experience– Understanding the problem– Comfort with technology– Productivity

• Too big a story – harder it is to estimate• May need to split it into more manageable

pieces• Velocity is the rate at which stories are

implemented• Spiking – Development of prototypes to get a

feel for the velocity of the team


Release Planning

• Can’t choose more stories than allowed by velocity– Based on velocity that is not accurate in the

beginning

• As velocity is varied, this will vary as well

BusinessDecision

Velocity

Business valueof a story

Priority of astory

Selection ofStories to be

done first


Iteration Planning• Typically two weeks long

– Personally I follow one week iteration

• Customer (and team) choose stories to be implemented for that iteration– based on velocity

Iteration

New Stories Code Deliverable

Demo/Discussions

Update Velocity

feedback

Enhancementsfrom last iteration


Iteration Planning…

• Build Product and demo

• Do not build “for” demo

• Iteration ends on specified date– Even if some stories are not done


Task Planning• Beginning of iteration

– Developers and customer decide on stories to implement

• Developer breaks stories into tasks– Tasks typically take 4 to 16 hours to

implement

• Developers take task from task list for completion


Task Assignment and Planning• Developers may sign up for any task• Tasks are picked up based on what each

one wants to implement• Team as a whole is involved with different

tasks– Important to have all members of team get

an overall expertise on different parts of the system

– Collective ownership is critical


Task Assignment and Time• What if

– Still tasks are left after each task member has picked up enough tasks• Negotiate task reassignment based on skill level• Still more tasks are left?

– Ask customer to remove tasks from iteration

– Still have time for more tasks• Ask customer for more stories


Halfway Point/ Slippage• Feedback, Communication are key

– Can’t be overemphasized

• During the course of progress of an iteration customer kept informed

• At half time, half the stories scheduled for iteration must have been completed

• If not– Team must reapportion tasks among members to

ensure completion– If not possible to still complete, customer is informed– Customer may decide to pull task or stories form the

current iteration– Customer will help name lowest priority tasks


Measuring Progress• Backlog

– A project backlog is the tasks that need to be completed

• Sprint or iteration backlog is tasks to be completed during this iteration

• Each developer, on a daily basis, reports the estimated number of hours needed to complete each task they have been assigned to

• You plan using these backlog schedule


Measuring slippage• Take a month long iteration• You have 160 hours, a team of four

means 640 hours• You can take a backlog of 640 hours• Two weeks into the project

– Your backlog shows 300 hours• You can take up additional task for remaining 20

hours

– Your backlog shows 400 hours• You need to take out 80 hours of work. You may

trade some tasks with customer approval from the next iteration, but you can’t continue at the current rate

ap-1 5. project management. ap-2 software failure software fails at a significant rate what is...

Documents