|
Agile Process Development and the APD Tool-set |
O X F O R D S O F T W A R
E E N G I N E E R I N G C o n s u l t I n g S o f t w a r e E n g I n e e r s |
|
|
|
|
RPI has been renamed: We have renamed the RPI method and toolset
‘Agile Process Development’ because it describes better what RPI is and because,
frankly, the word ‘agile’ gets attention that no other word does in the
software community. We aren’t going to obscure the old name – we are proud of
the work done under the rpi banner – but apparently a rose by any other name
doesn’t smell as sweet.
The approach is
exploratory and structured in small increments, where the work can be readily
co-ordinated and the results evaluated. This type of approach limits risks
and is often far more acceptable than the centralized 'one size fits all'
process improvement initiatives so often imposed on software professionals,
and, ironically, it can achieve the results desired by the corporate
initiatives faster and at lower cost. (The similarity of An early paper on Real improvement is
greatly aided if the right tools are available. We have been collecting and
developing The tools are well
described and teachable to equip process engineers to improve understanding,
and to change intrinsically complex, subtle and often highly coupled software
development and support activities in a controlled and measurable way. They
have been acquired and developed over a number of years and will continue to
be developed and added to. Tools are classified in three main categories;
visibility, construction and infrastructure. A fourth ‘catch all’ category,
‘other’, is used for tools that do not fall readily into one of these
categories. We are keen to develop this classification as a tool in its own
right to enable process engineers to more readily select the right tool for
the job. Any suggestions or pointers to better classification systems would
be very welcome. Why have process improvement tools? The …and if you have tools or assets you are willing to share we are keen to hear from you too. Tools for Visibility: These tools are designed to show how software development and support is performed. They answer the questions: “what is happening?”, “what effect have our process improvement activities or technology introductions had?”. These tools give process engineers data to work with. V - 1 Post Implementation Reviews and Retrospectives: fundamental tools for understanding and improving development and test practice V - 2 Assessments, Appraisals and Audits: potentially powerful diagnostic tools - but often misused or abused V - 3 Focussed Quality Assurance (FQA): A low risk, low cost method for introducing and ramping up a quality assurance capability for non engineering software organizations V - 4 Records: the team, project and organization’s memory – often disregarded or overlooked V - 5 Formal Technical Reviews (FTRs): A fundamental software engineering practice. (Actually a set of practices of variable formality and rigour, from walkthroughs, to inspections, to pairing. V - 6 Defect Models and Defect Tracking: Provide insights into product qualities, process efficiency, and project performance – defects are software development’s lab rats. V - 7 Measurement: Needs and deserves to be treated as a tool in its own right, but is integrated into many of the other tools too, to the extent that RPI could also be called MPI (Measurable Process Improvement) V - 8 Using Performance Targets: a double edged tool V - 9 Cost of Quality (CoQ) V - 10 Visualization: of patterns, processes, products and projects V - 11 External Consultants: getting best value from their knowledge and experience. V - 12 New Hires: for an objective but informed perspective of process performance, development and test capability, and organizational culture. Tools for Construction and Change: Software development is dependent on both technology and the people using it. These tools are designed to aid the change of technology, processes, expectations and behaviour. C - 1 Developing a Process
Improvement Plan (Dev-PIP) C - 2 Process
Definition: A fundamental tool that ensures that process definition work
establishes a genuine and valued process baseline, not shelf-ware. C - 3 Tactical Change Management (TCM): A simple framework for
process improvement that delivers results fast and reduces risk. C - 4 PIR Led Process Improvement (PIRL): Fundamental - start with this. C - 5 Process Improvement Templates: Characterize the types of process improvement, and selects the right process improvement tools. C - 6 Joint Application Development (JAD): It works for software – and software practices and processes too C - 7 Making Checklists: Fast, fun and an effective method of distilling and sharing wisdom. C - 8 Knowledge Transfer: C - 9 Process Workshop (PW): A method for tactical process improvement C - 10 Prefabricated Software Process Components: An approach for the rapid installation of software development capability C - 11 Strategy: Development: (and validation and maintenance)
Infrastructure Tools: These tools are models or templates for robust process infrastructures. They eliminate ambiguity redundancy and contention, and enable effective communications and collaboration. F - 1 Software Process Infrastructure F - 2 Process Improvement Infrastructure F - 3 Software Process Architecture F - 4 Tools Group
The difficult to classify tools: A selection of difficult to classify tools and techniques. T - 1 ‘Upstreaming’ T - 2 Resource Models T - 3 Leverage and ‘Reverse Leverage’ T - 4 Visible Migration (or development) of process and practice assets T - 5 Skills Recognition T - 6 Process Sponsors and Process Champions T - 7 Other Tools (mostly from other disciplines) T - 8 Process Action Teams (PATs)
|
|
|
For data sheets for these tools or further information email: shelley@osel.netkonect.co.uk |
|
|
|
|
|
© Copyright OSEL 2004 - 2012 |
|