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
Things We Should Keep Doing
- (SPH) New sub-task approach seems to work very well.
- (JJKP) I enjoyed sitting in B23 one day/week. It led to some good working discussions.
Things We Should Change
- (SPH) We are letting too many open tickets get scheduled simultaneously. Lot's of task switching as a result. Our process is designed to have a few weeks of work on anyone's plate at any given time and to discuss/track progress on those items weekly. By letting upwards of 30 tickets on any one persons plate at a time, it breaks how we work.
- (SPH) Use Git as it was designed. Some of us missed the push step, most don't create separate repos for different work areas. The benefit if Git is not realized without the philosophy/approach change.
- (JJKP) We need a task-master during the release process.
- (SPH) Need CCSDS TDM and SPK comparators for regression testing Ephemeris files. This is essential.
- (SPH) Consider refactoring Ephemeris component.
- (SPH) Nav development branching/testing needs to follow same process as the rest of our development.
- (JJKP) We find issues late and miss others that would have been found earlier by actual mission users. But mission users can't use a version that's changing rapidly. Two options:
- beta period before release
- more rapid releases
- Keep test system configured for release. Some last minute issues were found because test system did not run in release config until after code freeze.