Jump to: navigation, search

Team thoughts on continuous improvement 32

Revision as of 02:35, 24 June 2010 by David williams.acm.org (Talk | contribs) (Things we've done well)

WTP 3.2 Retrospective 06/17/2010


Following every release, we have short retrospective to discuss possible ways our project might improve. This starts with a list of things we like and don't like about how the release went, and will evolve into action items with people assigned to be responsible, where appropriate.

Below are initially notes from our 6/17/2010 status meeting. Overtime the notes will be categorized, organized, collapsed, etc., to make correspondence to actions clear.

Things we've done well

Maintained last year's "good" list!

JUnits have done better (even if not green often, there are fewer intermittent failures).

The graduation and integration of jaxws code went smoothly (thanks to shane and daniel)

jsdt creation went well, good to be "own project", has been getting more visibility, interest, help

WTP is good at meeting deadlines

ian mentioned good patch review and apply responsiveness from source editing team

weekly bug focus quality area ... less "home work" to do week to week. Teams kept up and/or had less backlog to start with.

Things we'd like to improve on

fix more old bugs? track fix rates

junits, more passing builds, less intermittent failures (hard to focus)

performance testing and focus and fixes

[good] welcomed contribution in source editing [good] improved diversity

could do more explicit verification and closing of fixed bugs

documentation -- long planing from everyone would help doc. teams plan what they need.

keep up better with base prereqs more timely

do we care or measure use of non-API use, discouraged access

build improvements (still needed)

[good] breakout meetings still good .. jee team

ian, keeping up with large bug backlogs ... need a system to not let backlog build up or grow.