EPF F2F Meeting - Boulder, CO by qfc10548

VIEWS: 9 PAGES: 6

									                                EPF F2F Meeting - Boulder, CO
                                     December 6-7 2007


1 Attendees:
  Kurt Sand (Telelogic, day 1)
  Chris Sibbald (Telelogic)
  Per Kroll (IBM/Rational)
  Ricardo Balduino (IBM/Rational)
  Ana Paula Valente Pereira (Whatever Consulting)
  Nate Oster (Number Six)
  Ken Clyne (Number Six)
  Bjorn Gustafsson (GoodSoftware)
  Steve Adolph
  Ryan Martens (Rally Software, day 1)
  Dean Leffingwell (Leffingwell LLC, day 2)

2 Agenda as planned
  1) Thursday December 6, 2007
                  OpenUP planning (what will be in next release) (Nate) 8:30 – 9:30
                  Scrum planning (what will be in next release) (Lyndon TBD) 9:30 – 10:30
                  Discuss practice library (Per, Bruce Macisaac-remotely) 10:30 – 12:00
                  ProjectKoach Presentation (Bjorn) 13:00 – 14:00
                  Update on translation efforts (Ricardo) 14:30 – 15:00
                  Discuss how to grow the community (Steve) 15:00 – 17:00
                  Team dinner 6:30 pm
  2) Friday December 7, 2007
                  EPF Wiki Training (Onno) 8:30 – 10:00
                  Discuss Enablement (Steve) 10:00 – 12:00
                  Release Planning (Per) 1:00 – 3:00



3 Update on Translation Effort (Ricardo) 9:15 – 9:45
       Ricardo presented the attached slides.


 Translation


       There are 6 – 10 people (depending on availability) working on the Portuguese
        translation. This effort is about 90% complete (based on OpenUP/Basic V0.9).
       There are ~three people working on the Russian translation (at Luxsoft via Steve
        Adolph). Per noted that if they have not done much, perhaps we should get them to start
        working on the V1.0 release (vs. V0.9). Steve to look into this.
       EPF Composer does some translation when publishing in a particular language (structural
        information such as element types).
   Per noted that IBM should have language specific glossaries that may help with
    translation efforts. Ricardo will look into the possibility of making these glossaries
    available.
   It would be nice if there was a diff tool for EPF Composer that would, for example, tell
    us all the differences between OpenUP/Basic V0.9 and OpenUP V1.0. This would also
    be useful for users when new versions of OpenUP are released.
   How do we ensure translation is complete and of acceptable quality. There are two
    possible approaches identified by Ricardo (see slide 5). Per noted that only approach b)
    will comply with Eclipse rules. In the case of the Portuguese translation there is an
    individual that has been active and reliable that would be a good candidate to make a
    committer (Paulo Moreira) Ricardo to look into this.
   Steve noted that for the French translation effort, Universities in Quebec may be
    interested and able to get a grant to perform this work. Steve will look into this.
   The other issue to address is the promotion of translated content and due diligence to
    meet Eclipse Legal requirements. Per noted that translated content should be moved to
    CVS incrementally, rather than one big bang migration when complete. The standard
    process is to track contributor, Bugzilla and committer for each contribution. Do we need
    multiple Bugzilla’s or many smaller bugzilla’s? We need to ask Onno what reports we
    can get from EPFWiki that lists all changes. This report could then be attached to a
    single Bugzilla to provide more detailed auditing. Ricardo will check with Onno to see if
    the EPFWiki reports have all the required information (who contributed what).

3) Scrum Planning (Ken Clyne) 9:45 – 10:45
   Ana, Lyndon, Ricardo and Ken are the “Scrum Team”. Ken did recruit four people from
    Number Six to help out as well.
   Content is still a bit immature with some translation, accuracy, completeness and depth
    issues.
   We need to get more participation from the Scrum community.
   Rough assessment is 50% complete.
   Mike Cohn has given consent to re-using some of his material. Ken will provide a list of
    items that he would like to get permission from Mike to re-use. Per will contact Mike to
    see it is ok to use this information and to see if he is interested in becoming more
    involved in EPF in general.
   Ryan Martens joined the meeting. He outlined Rally’s interest/plans regarding EPF.
           Rally did not build a workflow engine into the Rally Dev product. Rally uses a
             programmable state-machine in the tool to manage the lifecycle of work items.
             The product is more of a decision support system for overall project health than a
             process management tool. It is highly focused on the “project” level versus the
             Portfolio or development level.
           They are very interested in Best-practices at Rally but not interested in EPF
             creating or driving an automated process. Ryan says they provide guidelines and
             best practice mentoring, but are only asked for end-end process by their largest
                  customers. Their customers are typical program managers that have to coordinate
                  multiple Scrum/XP teams.
         Per outlined the method/process pattern/delivery process hierarchy in EPF.
         We discussed that best-practice is easier to “sell” than end-end process. Many people
          agree on best-practice, but the larger the building block (ex. a full end-end process) the
          more violent the process wars.
         As the discussion has turned to best-practice vs. full lifecycle process, this seemed like a
          reasonable point to transition to the practice library discussion.


    4) Practice Library (Per, Bruce, Ricardo) 11:00 – 12:00, 12:45 –
       13:30

         Per set the context for the discussion with the presentation “EPF Practice Library
          Proposal” (see attached slides)


  EPF Practice
Library Proposal


         How to adopt a process? How to avoid the process wars and build a community and
          library of best practice?
         Current practices in OpenUP:
             1. Management Practices
                     a. Iterative Development
                     b. UP Lifecycle
                     c. Self organization
             2. Technical Practices
                     a. Use-Case driven
                     b. Shared Vision
                     c. Basic Architecture
                     d. Basic Software Design
                     e. Test-driven development
                     f. Agile Testing
                     g. Continuous integration
         Bruce Macisaac then presented a prototype library structure. (See attached presentation
          “OpenUP Practice Library Structure”)


OpenUP Practice
Library Structure
      Currently we can accommodate the proposed structure, however due to tool limitations it
       is rather complex. In order to simplify library management and process definition there
       are some additional features that could be added to EPF Composer. Bruce outlined a
       proposed set of EPF Composer features to support a practice library. See attached
       presentation “EPF Features”.


EPF Features




      Ricardo presented a demo of the prototype library. Ricardo will provide a copy of the
       prototype library.
      The plan is to create a separate best practice library. The current plug-ins for OpenUP,
       Scrum, DSDM, XP content that currently exists will continue to exist in their current
       form.


  5) ProjectKoach (Bjorn) 13:30 – 14:10
      Bjorn delivered a presentation on ProjectCoach. (Slides Attached).


ProjectKoach




      Bjorn introduced himself as “a programmer”. He was a member of the RUP team from
       1998-2003.
      Bjorn is here to introduce ProjectKoach (an agile project management tool) and to get
       involved in EPF.
      Demo showed ability of ProjectKoach to:
       1.      Create project plan and integrate with Mylyn (work items) in standalone model
       2.      Import an EPF process configuration and create a project plan (instantiate
               process). Add resources, and make work items from process tasks. The process
               tasks maintain links back to the process website.

  6) Growing the Community (Per) 14:20 – 15:15
      Per outlined the sweet-spot for EPF Composer (i.e. larger groups with traditional
       processes). OpenUP (content) has been targeting small agile groups.
      Some perceived motivation for adoption by various groups:
               1. SEPG – EPF Composer is the best tool available
               2. Bus Manager/Dev. Executive – Best solution for incremental improvement in
                  performance.
               3. Agile Practioner – OK if it can help me convince management that agile is
                  good/acceptable
            4. Dev/Project Manager – Good if I get the practices I need for better
               performance.
   Kurt noted that we have been very focused on promoting OpenUP, and have not been
    very active at promoting EPF Composer in its own right. Chris noted that there is also
    opportunity to expand the community outside of the software development domain.
   Per noted that a shift to practices vs. processes should also expand the audience since we
    will appeal to a broader audience and avoid the process wars.
   More university involvement will lend credibility and re-useable content (Ana noted an
    example of a University in Portugal that is using EPF Composer to document their co-op
    program).
   Ryan said a contest to find the “nicest” EPF Composer generated web site could create
    some buzz.
   More Standards body involvement would also lend credibility. It would be a great coup
    if Carnage Mellon adopted EPF Composer.


7) OpenUP planning 15:30 – 16:30

   Current plan is to have a minor release of the current OpenUP plugin that addresses
    defects only. We will also begin work on the EPF Practice Library in parallel.

8) Enablement (Steve) 16:30 – 17:00

   Chris quickly walked through the Introduction to EPF course (~4 hrs including hands-on
    exercises) that Telelogic will donate to the EPF project. Chris gave Ricardo a copy of the
    preso to add to CVS.
l

9) Enablement (Steve) 9:00 – 14:00

   Steve asked if we should have a certification program. There is no huge demand for
    certification at this point. It may be a barrier more than an enabler.
   Three “brands”
          1. EPF Composer: Effectively manage your enterprise practices
          2. OpenUP: Start small and grow
          3. Practice Library: the tool box for incremental adoption.
   Nate got involved in EPF because he would get to work with thought leaders to get a
    minimal package that can be used as a starting point in consulting engagements and to
    leverage the brand to generate demand.
   Steve got involved because he felt the practices and light-weight nature of OpenUP
    matched the needs of his target market and it would help his business. Also his
    participation in the project would enhance his personal credibility.
   Ana is in a market where Scrum and RUP are not that well known. But her target market
    is looking for more agility, so she sees that EPF/OpenUP will help her deliver agility to
    her customers.
   Bjorn consults with organizations that are adopting/using RUP but having problems. He
    saw EPF as a means to simplify tailoring/right-sizing process.
   Telelogic got involved because they saw the project as a means to ease tool adoption and
    to provide a more efficient service delivery.
   Dean said there are two ways to drive demand and adoptions: 1) Top-down via thought
    leadership, 2) Bottom-up by solving grass-roots problem (demand from the desktop).
   “Agility that Scales” is a tag line that has been used since about May (for RUP and
    OpenUP) and has resonated in the market place. There has been some resurgence in
    interest in RUP of late.
   The names “StartUP”, “StepUP” or “ScaleUP” had some traction with the group since it
    captured the minimal, complete, extensible message and avoids the “this is THE
    process”. The “StepUP” (or “ScaleUP”) may be different for every organization,
    drawing on the practice library as required. The following draft list of practices would be
    part of StartUP (immutable, must do):
                       1. Iterative (plan, assess)
                       2. Continuous Integration
                       3. Concurrent Testing (Developer test, system test)
                       4. Two levels of planning
                       5. Agile Team (Define, Build, Test; Self-organize)
   It was proposed that we call this base configuration “The Agile Kernel”. The additional
    practices added to get OpenUP could be called ScaleUP. So, OpenUP is:
                       1. Agile Kernel
                       2. StepUP which includes the following practices:
                                a. Evolutionary Architecture
                                b. Evolutionary Design
                                c. Use-Case Driven
                                d. Shared Vision
                                e. Practice Authoring Guidelines
   Other ScaleUP practices could include:
                       1. Portfolio Management
                       2. Program Management
                       3. Integration/synchronization of multiple teams
   Messaging on OpenUP would have to change: OpenUP is a software development
    process that consists of a minimal, extensible kernel of agile practices and a set of
    additional practices (StepUP) that are added to provide some scaling.
   The book on OpenUP would consist of two parts: Part I – The Agile Kernel; Part II –
    Scaling UP. The second part would also contain a section on adoption which discusses
    tailoring.
ailoring.

								
To top