Lessons Learned from Release 0.3

Aperi Wiki Home Aperi Process Lessons Learned

• • Lessons Learned for release 0.3:
    • Freeform discussion to understand what worked well and what areas we can improve for the future. Topics to include, but are not limited to:
      • requirements and planning
      • implementation / code
      • information development
      • third party components
      • integration / build
      • test
      • availability
      • tools; cvs, bugzilla, etc.
    • Items already suggested:
      • IDVT Build process: During IDVT, we need to have one person responsible for the builds and a quick ‘acceptance’ test needs to be done for each platform.
      • Review the IDVT reporting charts after R0.3 to make sure they are conveying the needed information.
      • Make use of Bugzilla version field
    • New items from this meeting:
      1. We need to look at the process we use to look at requirements for releases and how we analyze them. (Dave)
      2. We also need a similar process once the content of release has been determined. How to define the content of each milestone, how we determine testing, etc. (Dave)
      3. Need to give ourselves more time for testing at the end of the process (Tom)
      4. We need an established procedure (checkbox) for the final build and test. (Dave)
      5. From the IDVT standpoint we were very late in the game for code integration and final build. We need to plan a two to three week buffer to absorb problems. This issue has been consistent for the last couple of releases. (Hans)
      6. Since we are line item driven, what does it mean to be complete with a line item? Need to define this. (Todd)
      7. We need someone dedicated to reviewing or answering questions for release notes or install instructions. (Chris)
      8. We need to identify any third party code we are using as part of the DCUT exit so that CQ’s can be investigated and submitted early. (Tom)
      9. Automated build and test process: We need to put together a self contained test system. Every night the build runs, it gets copied to a location, installed on all platfroms, and basic operational tests are run to indicate build is worthy.
      10. (related to previous one) We should test builds with the new SAN simulator to know the build is decent. (Dave)
      11. Risk reduction of new technology – what can we do to help prevent finding issues late in the cycle? We always have a risk with early adoption of a technology. A factor to consider at planning time is the complexity of what we are doing. We need to plan appropriate timing based on complexity into the schedule / risk plan. Identify ‘at-risk’ items up front and have a mitigation plan for them if we run into sever problems. (Tom/Dave)
      12. We need to distinguish between the core functionality of our offering and the new things in our planning. (Dave)
      13. SNIA 2006 end user council report - Utilize this to answer some of our questions. Put a link in Aperi Dev (if this is a SNIA item for general consumption) or have someone review and talk to it. (Javier)
          • Javier volunteered to take this on.