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

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

  • View
    221

  • Download
    0

Embed Size (px)

Citation preview

CS 5150 1

CS 5150 Software Engineering

Lecture 7

Managing Large Projects

Guest Lecturer: Stephen Purpura

CS 5150 2

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 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 Results7 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 settingsRun every application

Boot faster

Or

Ship on Time

CS 5150 5

The Project Manager

• Focuses the team. • Recommends adjustments to the interpretations of:

the visionthe schedulethe 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: 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

What does it mean to visualize a product release?

• Answer the question: “why does the customer/user need this?”

• Then answer the more important question:

– what will excite the customer to overcome inertia and buy?

• Other important issues:

– Positioning in the supply chain

– Positioning in the evolution of the industry

– Estimated revenue versus cost

– Organizational capabilities

– Political trades (don’t underestimate the number)

CS 5150 8

Starting Point: Visualizing a Feature in a Release

• Discussion: HTML standards in a browser

• Imagine yourself working on a browser. How do you choose whether to support the HTML5 Video tag <video src …> in a browser that releases in 2009?

Hint (IE8 HTML5 features supported): • cross-document messaging• a client-side storage API• network connection awareness• window location hash and tag

CS 5150 9

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 10

Milestones

Milestones are in approximately 3 month increments.

Why?

Because no one can reliably estimate the future.

CS 5150 11

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 12

Interaction Costs Greater in Large Projects

n(n-1)

2

# of Possible Personal Interactions:

When the # of people on a project is 7, the number of possible interactions is 21. At 1,000 people, the possibleinterpersonal interactions increases to 499,500.

CS 5150 13

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 14

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 15

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 16

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 17

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.

IMPORTANT: the schedule is modified by the risks

CS 5150 18

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 19

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 20

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 21

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 22

Don’t Underestimate the Value of Fun

• Brian Valentine read the “News of the World”

• Some managers pull stunts

• “The trebuchet battle”

CS 5150 23

Putting it All Together

Running a large project is about:

• Focus

• Fun

• Visibility

• Communication

• Risk management

The project manager needs, at minimum, to be respected by everyone. Being liked is sometimes useful. But being tough is also essential.

CS 5150 24

A Day in the Life of a Team Project Manager

7:00 – Email/daily prep8:00 – Review the Daily Build Report8:10 – Install the build and exercise it8:30 – File bugs9:00 – Morning status report10:00 – Cross-team coordination meeting 111:00 – Bug triage12:00 – Lunch with the team1:00 – Cross-team coordination meeting 22:00 – Work (schedule development/spec writing)3:30 – Team member visits5:00 – Update manager w/visibility

Coordination

Risk Mgmt

Morale

CS 5150 25

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