1 Reply Latest reply on Oct 19, 2010 8:06 AM by ilya_shaikovsky

    RichFaces 4.0.M3 Post-Mortem Meeting

    jbalunas
    jbalunas Oct 11, 2010 9:15 AM

      Hello All,

       

      Just like for the M2 release we are going to have our 4.0.0.M3 post-mortem meeting during next weeks team meeting,  I extended the meeting another hour, so two hours total.  We are going to discuss what worked, and what did not in the release.  Including what we can do to improve our process, and environment.

       

      It is open to anyone, but the project team members really need to be there.  If for some reason you can not please leave your comments & answers to the questions below in this thread.  We'll go around the IRC channel and get feedback from everyone.

       

      Please be prepared and ready to provide 2 or 3 points to discuss for each of the questions below.  Please provide bullet points, and comments in this thread so we can get right to meat of the discussion.

       

      1. What worked well in the release?
      2. What did not work well, held you up, or caused blockages?
      3. Several components were postponed - how can we get components out faster with better initial quality?
      4. How can we change M4 to make development easier, faster, more stable?
      5. Planning, prep, and jira updates - where can we improve?

       

      Any other questions?  Feel free to add your own.

       

      Thanks,

      Jay

      • 5138 Views
      • Categories: Build and Release, Quality and Testing
      • Tags:
        • 1. Re: RichFaces 4.0.M3 Post-Mortem Meeting
          ilya_shaikovsky
          ilya_shaikovsky Oct 19, 2010 8:06 AM (in response to jbalunas)
          What worked well in the release?

          migration process in general looks clean, all action items present and assigned in time so for me personally I was really convenient to track current activities and adjust as need according to jira.

          What did not work well, held you up, or caused blockages?

          We just was out most of the iteration so not finalized much of planned work. Not my personal blockage but just common problem : some miscommunication caused tabPanel to be redesigned (UI design) in last days as design was not in sync with requirements(we removed some elements but them was still implemented in HTML markup and get into component template). So need to figure out how to sync-up more. Probably should more carefully notify Lex that some component parts was removed or will not be implemented(at base version) if such cases will be in future.

          Several components were postponed - how can we get components out faster with better initial quality?

          As for posponed components - I believe we just failed to provide right estimations considering vacations of four people. And seems some redesign/refactoring of 3.3.x code was not considered in estimations again.

          How can we change M4 to make development easier, faster, more stable?

          Migrate closer to original 3.3 code and moving refactoring/redesign work as separate features if possible for future releases more often. For sure if such redesign - could be done smooth for end-developer. I'm not about component tags sets or attributes sets there, but for example some markup issues found, or script optimization which should be done. We need to deliver working base component and plan all the remained problems/postponed features/optimizations additionally. In that case we could get better to estimated time.

          Planning, prep, and jira updates - where can we improve?

          I like the component requirements meetings idea much. That really could help all the peoples not involved with component spend less time on that at staff/weekly and will focus involved persons more.

           

          Jira's - I still see Sean moving the issues which I creating for review and promotion to RFPL jira from original RF - looks not convenient to me as it more difficult to track release issues in two jiras. And moreover if he doing commits according to the jiras - it's definitely RF ones.

           

          Plan - still slightly failing to go with originally estimated plan. E.g. original M estimations and proposal was based on idea that Alex works at CSV at most. So Pavel estimated works on tooltip and calendar but then after some discussions - his load on CSV was increased and we was need to readjust the peoples tasks again. I know that now plan looks ok - but we should try to adjust original plan more carefully in order not to loose time on readjustments.

            • Actions