CSE403 Software Engineering Autumn 2000 Project Management

1
CSE403 Software Engineering Autumn 2000Project
Management

• Gary Kimura
• Lecture 10
• October 16, 2000

2
Today

• Understand that there are different approaches to
  project management for software
• And what several of those are
• Offer alternative and guidelines for your class
  project
• Youve seem to be doing pretty good for the first
  three weeks
• Is this because I pre-suggested a team
  organization or because youre all great
  organizers by nature?
• Managing schedules

3
Project management

• What percentage of the effort to date has been
  spent writing code?
• What percentage has been spend working through
  requirements and design?
• What percentage has been spend in meetings?
• When does the real coding start?

4
Problems with managing projects include

• Figuring out and coordinating schedules
• Handling communication among the team
• The figure shows a rough notion of the cost of
  team communication
• The theory is that about 25 of each group's
  effort is spent in communication, with this cost
  applying recursively
• As Brooks observes, the worst case of this is
  adding people to a late project, which tends to
  make it even later
• Making decisions
• Recording decisions
• Managing egos
• What else?

5
Team structure

• Brooks talks about the desire everyone has for a
  small, sharp team
• 10 or fewer people
• All of them brilliant
• All of them focused on the task at hand
• But he observes that this is too slow a way to
  build a really big system
• And rightly so

6
Why? Time

• Brooks take a 10 person team composed of people
  all 7x better than the worst
• 5x to 25x are within known ranges
• Assume OS/360 was built by the worst
• Assume a small team has a 7x communication
  benefit
• Assume no turnover of the team
• Assume 5000 person-years for OS/360
• ? 10 actual years for the task
• Now, do the same estimates for NT 5.0 with
  60,000,000 lines of code!

7
Chief Programmer Team

• An alternative idea is to restructure a classic
  big team to get the benefits of the small, sharp
  team (ability and focus) with the benefits of a
  bigger team (overall speed)
• The key is to design the positions on the team
  very carefully

8
Y2K

• Most of these specific (lower-level) job
  descriptions are clearly out of date
• a team will rarely need its own machine and
  operating system crew
• All computer input goes to the clerk, who logs
  and keys it
• But the idea of focusing on how to break up the
  team into well-defined jobs is, of course, still
  extremely pertinent

9
Chief Programmer Team

• An underlying theme of this approach is that a
  smart person understands the domain and defines
  an appropriate architecture
• Then the subpieces are spawned off to people who
  are talented programmers but who have little (or
  less) knowledge about the project
• In practice I wonder if this works very well at
  all
• Need commitment and buy-in from all parties
• Need to build team synergy

10
Aside outsourcing

• Over the past years, there has been an increased
  interested in outsourcing significant pieces of
  software projects
• In particular, the interest has been to use
  cheaper labor in places like India, China,
  Ireland, etc.
• There is a big political issue related to this,
  which is the question of granting H1-B visas to
  people from other countries to work in high-tech
  in the U.S.
• This in many ways resembles aspects of the chief
  programmer team Give them the spec and let
  them code!

11
More on outsourcing

• A serious problem with the outsourcing version of
  coding is the increased distance between the
  programmers and the people who own the
  requirements
• Communication is almost entirely by email, travel
  is costly and time consuming, etc.
• I believe this leads to less and less effective
  communication, significantly increasing risks

12
Team structures Ive been involved in

• DECwest Compiler team
• About 6 people
• One language architect and manager
• Two senior developers
• Three junior developers
• Documentation and testing?
• Overall NT team at Microsoft
• When it began in 1988
• When NT first shipped in 1993
• When I left in 2000
• The NT file system team
• In its most productive phase there were 4
  developers, twice as many testers, and everyone
  eating dogfood.
• Later it had over 20 developers (not by choice)

13
Some Microsoft job titles

• Program Manager
• Maintaining the big picture. Weighing risks
  against costs. Understanding many disciplines.
  Keeping a variety of specialists on the same
  page. Sewing all the components of a project
  together to make world-class software projects
  happen on time, on budget.
• Software Design Engineer
• Working with other product team members from the
  beginning of the product cycle through release,
  our SDEs design and implement sophisticated
  products ...
• SDE in Test
• Deeply involved in every phase of the product
  cycle, our SDEs in Test devise and implement test
  plans and strategies. It's a specialized skill
  that requires the ability to effectively
  second-guess our other developers.
• Software Test Engineer
• As the strongest advocate our end-users have,
  Microsoft Test Engineers develop and execute test
  plans and scripts designed to detect problems and
  ensure the quality ...

14
Last years team structure

• Fairly non-hierarchical team structure
• Small teams (5 students)
• Nobody was really the boss
• Everyone can communicate with each other
• Would not scale well to larger teams (even at 10
  people it falls apart)

15
This years team structure

• Hierarchical divided up into specific areas
• One assigned manager (coordinator) for the whole
  team
• Each sub-team works quasi independently of the
  other teams
• But communication and buy-in by everyone is still
  a must
• A way to make decisions needs to be agreed upon
• A very common problem is to fight for a long time
  over decisions for which either alternative is
  adequate often, making a decision is more
  important than which decision is chosen.
• Most often a good manager is the decision maker
  if consensus cannot be reached in sufficient time

16
Decision making

• Making decisions is something we do all the time
  in a project
• The biggest risk, in general, is not that we make
  a bad decision
• It is that we delay making any decision past a
  point of no return
• You should probably spent relatively little time
  deciding between two pretty strong alternatives
• This is perhaps especially true in your project,
  given the incredibly compressed schedule

17
Recording decisions

• In your meetings you will be making a lot of
  decisions
• Some youve probably already made are who will do
  what, what will the requirements be, who will
  write up what, what coding standards (if any)
  will we use, how will we name our variables, etc.
• You might even still have some major design
  decisions to work through.
• You cannot record all your decisions in
  writingbut youd better record the key ones!
  Decide where these are recorded and how.
• How have you been recording and keeping records?

18
Running meetings

• Youve already had a few meeting, let me just
  offer a few tips if I can
• Have an agenda
• Have a person responsible for keeping the meeting
  on the agenda
• Have a person record key decisions
• This person can rotate or can be assigned to
  someone who is good at this by nature
• Show up to the meetings (uh, and classes)
• Start them and end them on time
• It may be that your teams ability to succeed is
  driven as much by things like how your meetings
  run as by how well you cut code

19
Artifacts

• The following are two documented/analyzed ways to
  aid in managing projects
• You may find these artifacts helpful for your
  project management task
• Some, of course, may appear in your actual
  project, as well
• As always, (a) use what you want and (b) don't
  over do anything!

20
The primary example is a Gantt chart to show the
link between tasks and time

• A Gantt Chart maps tasks to dates
• There is a row for each task the columns
  represent dates
• This makes it easy to see the schedule
• So its often a good way to build an initial
  plan, to view the schedule, and to make
  adjustments
• Task linking is a constraint that says, Task x
  cannot start until Task y completes
• I use to use a white board with yellow sticky
  notes for this purpose but also with developers

21
PERT charts

• Displays tasks and task dependencies as a network
  diagram or flowchart
• A node represents each task and a line connecting
  two boxes represents the dependency
• There are some nice software packages that help
  with, but personally, I cant stand them

22
Software engineering is not a mere matter of
programming

• Coming up next
• Individual project reviews
• Testing, testing, and more testing