AP-1 5. Project Management

AP-2 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

AP-3 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

AP-4 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

AP-5 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

AP-6 Project Planning What is planning? Deciding on a course of action Considering the strengths and risks Estimating and projecting the path of action

AP-7 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?

AP-8 What do you plan for? You have to plan for –Staffing –Standards and procedures –Quality Assurance & System Validation –Configuration management –Maintenance

AP-9 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

AP-10 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?

AP-11 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

AP-12 Problem with planning? “Plans are nothing. Planning is everything,” Dwight D. Eisenhower “No plan survives contact with the enemy,” Helmuth von Moltke

AP-13 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

AP-14 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

AP-15 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

AP-16 Development Process time User Stories Significant ones

AP-17 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

AP-18 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

AP-19 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 Business Decision Velocity Business value of a story Priority of a story Selection of Stories to be done first

AP-20 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 Enhancements from last iteration

AP-21 Iteration Planning… Build Product and demo Do not build “for” demo Iteration ends on specified date –Even if some stories are not done

AP-22 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

AP-23 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

AP-24 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

AP-25 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

AP-26 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

AP-27 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