Скачать презентацию CS 5150 Software Engineering Lecture 7 Managing Large Скачать презентацию CS 5150 Software Engineering Lecture 7 Managing Large

c6b30552482f3d670e77650d16a79ad2.ppt

  • Количество слайдов: 28

CS 5150 Software Engineering Lecture 7 Managing Large Projects Guest Lecturer: Stephen Purpura CS CS 5150 Software Engineering Lecture 7 Managing Large Projects Guest Lecturer: Stephen Purpura CS 5150 1

Administration Quiz 1 • Quiz 1 has been graded Project Announcements • i. Phone Administration Quiz 1 • Quiz 1 has been graded Project Announcements • i. Phone Apps for CIT Team: please have someone from the team see Stephen Purpura after the lecture. CS 5150 2

Why a T-shirt? Why do software companies make project t-shirts? CS 5150 3 Why a T-shirt? Why do software companies make project t-shirts? CS 5150 3

The T-shirt, Explained Benefits: • • Short “elevator” description. Easy to memorize. Provides a The T-shirt, Explained Benefits: • • Short “elevator” description. Easy to memorize. Provides a reference point to resolve disputes. Visibility. Engineers advertise the goals daily. Rallying point for all project teams to plug into. Project vision statements are cliché but important. The t-shirt is the humanization of a bureaucratic function. CS 5150 4

A Windows XP Desktop T-Shirt Windows Focus Group Results 7 out of 7 Apple A Windows XP Desktop T-Shirt Windows Focus Group Results 7 out of 7 Apple engineers don’t want Windows to: Prevent Internet hackers from stealing my data Support the latest cool hardware and games Auto-configure network settings Run every application Boot faster Or Ship on Time CS 5150 5

The Project Manager • Focuses the team. • Recommends adjustments to the interpretations of: The Project Manager • Focuses the team. • Recommends adjustments to the interpretations of: the vision the schedule the team composition • Facilitates and communicates to provide visibility. The project manager needs support from the client, executive management, the heads of all of the development teams and the confidence of everyone. CS 5150 6

Project Manager vs. Program Manager • Project Manager: single version focus • Program Manager: Project Manager vs. Program Manager • Project Manager: single version focus • Program Manager: multiple version focus Program Managers are frequently “leveled” by the number of versions ahead they can “visualize”. Most program managers have project management responsibility. CS 5150 7

The Schedule Now we have a t-shirt. What’s next? The schedule is built using The Schedule Now we have a t-shirt. What’s next? The schedule is built using milestones, each with its own vision statement. • The beginning is about exploration. • The middle is about determining scope limitations. • The end is about grinding it out. CS 5150 8

Milestones are in approximately 3 month increments. Why? Because no one can reliably estimate Milestones are in approximately 3 month increments. Why? Because no one can reliably estimate the future. CS 5150 9

Common Mistakes Common failures: • Missing tasks (especially cleanup) • Forgetting to include communication Common Mistakes Common failures: • Missing tasks (especially cleanup) • Forgetting to include communication costs • Missing/unknown customer requirements • Understanding the “release process” • Underestimating testing requirements You know you’re in trouble when a software engineer says: “The customer wants it this way. ” CS 5150 10

Interaction Costs Greater in Large Projects When the # of people on a project Interaction Costs Greater in Large Projects When the # of people on a project is 7, the number of possible interactions is 21. At 1, 000 people, the possible interpersonal interactions increases to 499, 500. # of Possible Personal Interactions: CS 5150 11 n(n-1) 2

When do you begin work on the following? • Legal review • Documentation • When do you begin work on the following? • Legal review • Documentation • Support training • Supply chain training Good project/program managers are constantly talking to stakeholders and looking to prevent schedule holes. CS 5150 12

Project Teams Most schedules are built bottom-up to enable buy in. Even with experienced Project Teams Most schedules are built bottom-up to enable buy in. Even with experienced staff, basic mistakes are made every day. To hedge this eventuality, two strategies are employed: • Use a daily routine that encourages catching mistakes • Use a project team with diverse membership and focus • Software engineers, Project Mgrs, Program Mgrs • Architects, Ux, HCIEs, Testers (SDETs, STEs) • Docs, Support, Sales, PR CS 5150 13

Diversity on Project Teams If you’re selling software to Iraqis, it helps to have Diversity on Project Teams If you’re selling software to Iraqis, it helps to have an Iraqi on the project team. Diversity isn’t affirmative action or leveling the playing field. Diversity helps generate better ideas and perspectives which lead to better results. CS 5150 14

Finally … Estimating the Schedule Now that we’ve discussed all of the ways that Finally … Estimating the Schedule Now that we’ve discussed all of the ways that we can’t estimate the future, why do we build a schedule? Answer: It’s a forcing function. CS 5150 15

Example: What does it mean to “boot faster”? In the beginning … we do Example: What does it mean to “boot faster”? In the beginning … we do a feasibility study The goal is determine what needs to be done and the dependencies. We want to boot faster, but we don’t know how. We profile the boot times for each of the components and build a report. We experiment and see where we might get traction. The goal is to produce a report with options for realizing “faster boot” and the costs of the functionality gains. CS 5150 16

Beginning Schedule: Time Constrained Phase I: (Feasibility) May through December Make a list of Beginning Schedule: Time Constrained Phase I: (Feasibility) May through December Make a list of the potential improvements Phase II: (Proving) January through May Phase III: (Release Beta 1) May through December Beta 1 doesn’t hit customers for a year Phase IV: (Release Beta 2) January through March Phase V: (Release Candidate 1) March through June Phase VI: (Release Candidate 2) August Phase VII: (Release to Manufacturing) Aug - Nov CS 5150 17

Beginning Schedule: Risk Constrained Phase I: (Feasibility) May through December Make a list of Beginning Schedule: Risk Constrained Phase I: (Feasibility) May through December Make a list of the potential improvements Slipstream a release to customers Phase II: (Proving) January through May Slipstream a release to customers Phase III: (Release Beta 1) May through December Phase IV: (Release Beta 2) January through March. . . CS 5150 18

Getting Traction on “booting faster”? In the middle … options identified during the previous Getting Traction on “booting faster”? In the middle … options identified during the previous phase are built to 80% functionality. They are shipped to customers for evaluation. The goal is to determine “distance” from finished. Example: PCI bus scanning and “known unknowns vs. unknowns” CS 5150 19

Updating the Schedule: Risk Constrained Phase II: (Proving) January through May This phase now Updating the Schedule: Risk Constrained Phase II: (Proving) January through May This phase now becomes half about responding to the release feedback and half about the original engineering goals. Engineers are segmented appropriately Features are tossed out if a viable plan can’t be developed to resolve customer problems. . CS 5150 20

Tying a Team into the Larger Group More teams means more communication and coordination Tying a Team into the Larger Group More teams means more communication and coordination cost. • “Boot faster” conflicts with “Auto-configure network settings” • “Auto-configure network settings” conflicts with “Prevent Internet Hackers from Stealing my Data” • Kernel changes and user-mode changes are required by all of the project teams. How do you handle source code changes? CS 5150 21

Risk Management Practice releasing a quality product every day. • Build the software • Risk Management Practice releasing a quality product every day. • Build the software • Test it • Report the results • Read the reports • Act like you’re working with a purpose CS 5150 22

The daily build Build the source code from source control every day. Then test The daily build Build the source code from source control every day. Then test it. Hold people accountable. How? • Call out people for build failures. • Call them at home at 3 am. • Bring them into the office. • Use a senior engineer as an example to set the tone. CS 5150 23

Does the build live up to the t-shirt? On large projects, there are typically Does the build live up to the t-shirt? On large projects, there are typically more testers than developers. Why? We’ll discuss this more in my next lecture … CS 5150 24

Don’t Underestimate the Value of Fun • Brian Valentine read the “News of the Don’t Underestimate the Value of Fun • Brian Valentine read the “News of the World” • Some managers pull stunts • “The trebuchet battle” CS 5150 25

Putting it All Together Running a large project is about: • • • CS Putting it All Together Running a large project is about: • • • CS 5150 Focus Fun Visibility Communication Risk management 26

A Day in the Life of a Team Project Manager Risk Mgmt Coordination Morale A Day in the Life of a Team Project Manager Risk Mgmt Coordination Morale CS 5150 7: 00 – Email/daily prep 8: 00 – Review the Daily Build Report 8: 10 – Install the build and exercise it 8: 30 – File bugs 9: 00 – Morning status report 10: 00 – Cross-team coordination meeting 1 11: 00 – Bug triage 12: 00 – Lunch with the team 1: 00 – Cross-team coordination meeting 2 2: 00 – Work (schedule development/spec writing) 3: 30 – Team member visits 5: 00 – Update manager w/visibility 27

The Project Manager Is not “the Decider”. A PM on a power trip generates The Project Manager Is not “the Decider”. A PM on a power trip generates bad results. But good PMs make problems disappear … • Persuade management to make critical decisions • Convince software engineers to avoid escalating CS 5150 28