CS/EE/ME 75aWeek 4: Status Charts and Bugzilla

Richard M. MurrayControl and Dynamical Systems

California Institute of Technology

http://team.caltech.edu

Team Caltech, 18 Oct 04 Richard Murray, Caltech CDS 2

Meeting Goals and Agenda

Goals Review GOTChA charts from each team and look for gapsIntroduce status charts and Bugzilla

Agenda 7:30 Goals, Agenda, Notetaker7:35 Team GOTChA charts 8:00 Status charts and Bugzilla8:20 Discussion: vehicle selection 8:30 Adjourn

Notetaker: ______________________Record notes and action items from meeting; post on wiki

7:30-7:35

Team Caltech, 18 Oct 04 Richard Murray, Caltech CDS 3

Status ChartsUsed to track progress during term

Create box for each component that team is responsible forAssign individual(s) to each componentUse (and update) charts at each team meeting to keep track of project status

InterfacesExplicitly list interfaces between components and other teamsTypically one of the trickiest parts of large system design

8:00-8:05

Team Caltech, 18 Oct 04 Richard Murray, Caltech CDS 4

Status Chart NotationChart:

Team name, current spiral, date updated at top of chart

ComponentsEach component should have box with name, status (color) + owner initials

InterfacesEach interface should have a block arrow with statusIdentify owner if not component owners

8:05-8:10

Working, specs met

Usable, but not up to spec

Not working (blocker)

Belongs to different team

Not req’d for current spiral

Not yet defined

Team Caltech, 18 Oct 04 Richard Murray, Caltech CDS 5

BugzillaBug/task tracking tool

Keeps track of all open tasksSends e-mail to reporter, owner, CCs when changedCan set severity, depend bugs, current status, etc

Current usage806 bugs in database103 currently active63 marked new (unassigned)

Planned usageUse to keep track of all open bugs/times for Team CaltechAll team members need accounts + familiarity

http://gc.caltech.edu/bugzilla

Team Caltech, 18 Oct 04 Richard Murray, Caltech CDS 6

Discussion: Vehicle Selection

IssueSpent too long discussing choices instead of picking one and moving on

CausesOverly ambitious goals sometimes led to choices that didn’t need to be madeDidn’t have deadlines for when we needed to make decisionsDidn’t have a good sense of when things needed to be completed and realistic amount of time requiredSometimes looked too closely at monetary issues; tried to over optimizeFocus on the key goals that must get done first and put other goals further out.

Once all of the issues have been discussed, need benevolant dicatator to decide and move on

ActionsMake sure that everyone who needs to be involved in a decision is represented when decision is requiredMake individuals responsible for getting subsystem working; present alternatives (incl. cost) to “stakeholders” before deciding (use status charts for interfaces); document issues and decisionsBetter match of team talents to tasksPut together a prioritized list of things that we need to solve, focused on DGCUse status charts early on to document architecture and owners

2004 Lesson Learned: Discussing Versus Deciding