Table Contents
How Lessons Learned are Managed
GMAT lessons learned include things that we did well and should keep doing, and large scale things we should be doing to improve the software or our project. Lessons learned are each discussed by the team and if we decide there is a real issue, we require a plan for improvement. To make sure we are efficiently handling lessons learned, here are some high level guidelines for creating them.
What is a Lesson Learned
Lessons learned are issues that cause significant problems or could have caused significant problems, or are issues where we did something that significantly improved the software or our project. Lessons learned require group discussion and probably a change in team habits, process or strategy.
Lessons learned satisfy one the following criteria:
- Issue that is putting the project at greater risk than necessary
- Issue that is causing significant inefficiency
- Issue that is significantly lowering quality
What is Not a Lesson Learned
A lesson learned is not a minor annoyance, a tweak to an existing process, or something that can be resolved between team members in the everyday process of getting work done. Team members should bring these types of issues up at meetings, or work them among the team members involved.
A minor issue, (i.e. not a lessons learned), satisfies one of these criteria:
- Tweak to an existing process
- Minor annoyance or gripe
- Can be resolved by just picking up the phone, or discussing via email, or weekly meeting
- Does not require significant change in habits or processes
Original Release Schedule
This is saved so we can compare with how the process actually went.
For QA Complete (Sept. 16)
For Visual Freeze (Sept. 30)
For Code Freeze (Sept. 30)
For App Freeze (Oct 7)
Testing of Release Candidate 1 (Oct 8 - Oct. 26 )
Stage Release (Oct 28)
Release Day (Oct 30)
Things We Should Keep Doing
Things We Should Change
Do Better
- Test system stability: The test system needs to be reliable the last month before code freeze, and reports need to be generated for every build. If it does not run on a given night, the comparison with previous data needs to compare with a run that did reach completion.
Start Doing
- [SPH,DJC,JJKP]: Determine how we can release nightly builds or production builds more frequently and how this would work from a CM perspective, NASA process perspective (civil servants and contractor contributions).
- [SPH] For critical (i.e. customer promises, key goals, difficult features) the PDL needs to enforce deadlines. Currently milestones are treated as soft, desirable dates. Leads of those areas must report status at monthly BSR.
- [SPH] We need to be much more careful with the "90%" rule. If a features is "almost" done for a long time, then smaller milestones need to be defined and they are either done or not done.