...
- 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
- SPH, DJC 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.
- [SPH Use our process, it's there to help, but we often stray far from it. For example, most of us have far too many scheduled tickets at one time, and many were not aware of P1 items that were supposed to be completed by release just days before critical release milestones. The work that the team and CCB sees and the what individuals see, can be confused because we aren't using the same filters/dashboards, and they aren't being groomed regularly. I propose a simple solution. Everyone is responsible for creating their own backlog dashboard like this one. The scheduled list should ONLY have tickets that have been addressed in the last week or that can reasonably expected receive attention in the next week. All P1 tickets must have estimates. During weekly meetingings and CCB we go through these dashboards so we're all seeing and discussing the same work.
- SPH We're still over committing. This is not an easy problem to solve because we're always trying to accomplish as much a possible, and we have to balance responses to new ideas and needs, with commitments to existing projects/proposals. Having estimates against all P1 work will go a long way towards helping us triage incoming work against previous commitments. Having short scheduled lists, and bringing work to completion before adding new scheduled work will help make sure that the most important work gets done. The idea here is that we only make major changes in what were are currently working on if it warrants major redirection, otherwise, finish the current scheduled work, then look at all critical work and see what rises to the top next.
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.
- SPH Consider making catch all tickets for minor tasks like doc issues etc. There are lots of times when something is so small we don't need to track using the sub-tasks approach, but doc updates etc. then get lost. Keeping a master ticket for minor wrap up would help here.