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.
Pages to are hidden for
"EPF F2F Meeting - Boulder, CO"Please download to view full document