Hello Everyone:
I'm starting to toss some submissions in for Agile 2009. What I would like to do is create one or more submissions that feature EPF. One that I am starting to work on is a tutorial called "Agile Grows UP" I have a seminar also entitled "Agile Grows UP" which I have already submitted. You can view it by visiting www.agile2009.com I am in the process of designing the material for "Agile Grows UP" because I am hoping that it will be one of WSA's flagship courses in the fall. This is the draft outline for the course is at the bottom of this email. As part of the outreach effort what I want to do is donate my "Agile Grows UP" seminar to EPF. I also want to see if anyone is interested in collaborating on creating a half day "Agile Grows UP" tutorial we can submit to Agile 2009, and then donate to EPF. This half day tutorial would serve as the core content that others (such as myself) could use to build up their proprietary courses, or courses they can donate back to EPF. Of course beside those who are interested in perhaps creating this material, we still need to create a home for it. As you recall, I did reserve a bunch of domain names so all we need now is just a place to stash the bits, and someone who has the talent to organize those bits into a pretty and enaging website. Part of my evil plan is this course (or this course material) would serve as the basis of an EPF certificaton process - knowing how to design and scale an agile software development process use EPF. So anyone interested in contributing? We have to make our decision to submit our proposals before Feb 13. best regards, Steve Agile Grows UP: - Constructing an Agile Software Development Process for Your Project Duration: 2 Days Audience Project Managers, Software Developers, Quality Assurance Pre-requisites familiarity with software development and software development life cycles Essence of Agile Brief Description Constructing an effective software development process for a project. Description: One challenge often facing a project manager is the construction of project's software development process. What work products do we need to create and when? Who should create them? Who should approve them? What should happen when? Sometimes an off the shelf method is simply imposed and ignored. Sometimes no method is officially imposed and the process that emerges is an ad hoc collection of agreements and pacts. The rise of agile software development methods have not help to resolve this problem because few projects fit into the agile sweet spot. Teams cannot be co-located because people are either working on multiple projects or are physically distributed. There is no omniscient onsite customer or product owner available. The development organization works in a regulated environment and evience of specific practices must be produced. The system is part of a large existing enterprise system. Despite these challenges, agile methods have been successfully scaled to satisfy the constraints imposed by these challenges. However there is little specific guidance for how to do this systematically beyond the "Scrum of Scrums" philosophy. There is little advice for how to handle questions such as; if we have fifty engineers in three countries, should we use a longer iteration? Should we incorporate a Business Analyst in the process if we must address the requirements from multiple competing stake holders? How should we review requirements, code? How do we ensure the system is safe? That it will work? What milestones? How do we satisfy with industry regulators? There have been past attempts to create scalable software method but often these methods required a skilled software process engineer intimately familiar with a complex method to "tailor it down". Often those scaling the process were reluctant to throw and practices they might need and the result was often small and medium projects burdened with a method suitable for constructing a national air traffic control system. A better approach may be to start with the simplest process possible for a project and grow and adapt it as the project itself evolves. This course introduces participants to a process for evaluating the risks and context of their project and provides practical guidelines for growing and evolving an effective software process for their project. It clearly distinguishes between practices required for project governance and those required to coordinate teams and team members. Target Audience All Course Pre-requisites Some familiarity with software development and software development life cycles Course Level Beginning Course Pre-requisites None Course Objectives . Learn a set of practical strategies for growing an agile software development process that is appropriate for your project. . Understand the importance of context for your project. . Know how to discover and evaluate the risks associated with our project. . Learn a process for the design and ongoing evolution of a project's software process. . Understand the difference between coordination and governance. . Know how to make effective use of the "two levels" of planning philosophy to satisfy the sometimes divergent needs of stake holders and developers. . Learn how to use the principles of the EPF Kernel and EPF Practice library to support and inform the design of your process. . Learn how to collaboratively design and evolve a project's software development process. . Know when to add a new practice and when to remove a practice. Course Outline . A Process Per Project? . Scaling UP and Tailoring Down . Understanding Risk . Understanding Software Project Governance and Coordination . When the Scrum of Scrums doesn't work anymore . A Pragmatic Approach . Milestones . When a product owner just isn't enough . When refactoring is just not going to cut it . Getting the lay of the land . Understanding the culture . Distribution and Ambassadors . A process design process . Project Scenario: Case Studies
_______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
