1 / 30

There is No Mystery (From “Methodologies as Swimsuits” by Alistair Cockburn)

There is No Mystery (From “Methodologies as Swimsuits” by Alistair Cockburn). Projects come in different shapes and sizes. Methodologies come in different shapes and sizes. People come in different shapes and sizes. The people may not fit the methodology.

manasa
Download Presentation

There is No Mystery (From “Methodologies as Swimsuits” by Alistair Cockburn)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. There is No Mystery(From “Methodologies as Swimsuits” by Alistair Cockburn) Projects come in different shapes and sizes. Methodologies come in different shapes and sizes. People come in different shapes and sizes. The people may not fit the methodology. The people are the more important. Agile Process Improvement

  2. Agile (Software) Development Process Improvement By: Joshua Klein More aboutthe lecturer Agile Process Improvement

  3. You dream of being more efficient Agile Process Improvement

  4. You must be more efficient! Agile Process Improvement

  5. Competitive But you can’t afford the improvement methodologies CMMI ISO Agile Process Improvement

  6. Process Improvement should be: • Evolutionary • Scalable • Pragmatic • Flexible • Motivating • Creative • Assertive Step by step, check & go on Grows or shrinks per case Always refer to constraints Change methods / timescale Persistently feed the sponsorship Invent original solutions Obstinately coach Agile Agile Process Improvement

  7. Sponsorship The motivation cycle Change Improvedprocess Poorprocess Failure Openness Success Motivation Agile Process Improvement

  8. Success criteria The following criteria are used to determine how successful the SPI initiative has been. They address how effective the process used for SPI has been. • Fewer complaints on stress • More focus on engineering, less on collecting and checking information • Software more effective • Lower frequency of emergencies • Less misses (e.g. last minute missing or failing feature) • Better compliance to plans • Better management’s control (e.g. outcomes more expectable) • Less redoing • More efficient testing (it may paradoxically result in more bugs detected) • More consistency on the development chain • Reduced and easier turnover • Easier changes • Smoother communication with other Intel groups (e.g. US) Agile Process Improvement

  9. Conditions for Change If D * V * F > R then “change will occur” where D = Dissatisfaction with status quo V = Vision of a future state F = First steps towards the vision R = Resistance to change Actually: Permission to try Agile Process Improvement

  10. The “Improvement Leader” • The Improvement Leader’s role expands the Lead Assessor’s role from inspection to execution • The internal "assessment" is integrated with the improvement process • The Improvement Leader leads the improvement activities that derives from the assessment • The Improvement Leader reports to the management • The Improvement Leader show improvement results at short intervals Agile Process Improvement

  11. Improvement Implementation Improvement Plan Assessment The Improvement Leader’s role Agile Process Improvement

  12. Open Assessment • Internal assessment, not disclosed • No checklist but flexible guidelines • Opportunity to hear the practitioners • Enlightens from numerous sides • Brings everyone involved • Reveals unexpected practice effects • Spreads motivation Agile Process Improvement

  13. CMM (with some CMMI) Agile Process Improvement

  14. Where could we be ? How to get there ? Open benchmark Where are we standing now ? Agile Process Improvement

  15. Objectivity and normalization • Outputs of Open Assessment include: • Subjective feelings • Personal frustrations • Actual process clues from 1 point of view • In order to reach objective findings: • Compare interviews data, find similarities • Ask clarification questions • Analyze until finding the roots Agile Process Improvement

  16. September October November December 08 / 09 15 / 09 22 / 09 29 / 09 06 / 10 13 / 10 20 / 10 27 / 10 03 / 11 10 / 11 17 / 11 24 / 11 01 / 12 08 / Assessmentfindings Plan • Prioritization • Broad acceptance • Available solutions • Short term • Criticality Agile Process Improvement

  17. SW manufacturing processes Organizationalprocess Supportingprocess Productionprocess Concept Disposal Product Requirements Maintenance Design Validation Implementation Configurationmanagement Qualityassurance Documentation Planning Humanresources Management Infrastructure Improvement Inspired from ISO 15288 Agile Process Improvement

  18. Improvement mini-cycle • KPA assessment • Methods & Procedures • Pilot • Training • Deployment • Assimilation I n f r a s t r u c t u r e Agile Process Improvement

  19. Focused assessments Agile Process Improvement

  20. The Roadmap CodingPractices Developer test Require-ments Assimilation Design MSC Assessment Measu-rement CodingPractices Developer test Require-ments Deployment Design Ramp up CodingPractices Developer test Require-ments Training Design Require-ments CodingPractices Developer test Pilot Design Methods &Procedures Debrie-fing Developer test Require-ments CodingPractices Design MSC Assessment MSC Assessment CodingPractices Developer test Require-ments Assessment Design Tools 1 Reasess-ment SPI SPIPlanning Measu-rement Infrastructure Training Bodies J J F A S N D O u a e u e o e c l n t b g p y v c o r u t u e e 0 u e b a March 03 s m m r 2 a e t m y r r b b 0 b y e e 0 0 2 e r r 0 2 3 r 3 0 0 0 2 2 2 Agile Process Improvement

  21. Software Product Engineering • The purpose of Software Product Engineering is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently. • Software Product Engineering describes the technical activities of the project, e.g., requirements analysis, design, code, and test. • Knowledge areas: • Software Requirements Engineering • Software Design • Software Coding • Software Testing • Software Operation and Maintenance http://computing.db.erau.edu/SEERS/2-x.html#1 Agile Process Improvement

  22. SEPG charter The LAD SW Software Engineering Process Group (SEPG) is the focal point for software process improvement activities. The SEPG coordinate the implementation of improvement plans, and track the effectiveness of these efforts. Example: The SEPG coordinates, tracks and promote, the SEPG does not develop technical guidelines but asks for experts. Agile Process Improvement

  23. SPI Organization LAD SW GL Manages Reports each ~ 5 weeks + discussion LAD SW Staff Policy + resources Consults, coaches, writes reports, etc… SQA Intel Quality Bodies LAD SW SPI SEPG Controls & tracks Pilot(s) Procedures& methods Agile Process Improvement

  24. The Coding Rules Intranet page Agile Process Improvement

  25. SPI problem solving Agile Process Improvement

  26. Conclusion • You can do it • You must do it, engineer or manager! • The Process Improvement methodologists did a great work; we just have to adapt the models • Unfortunately, “Process Improvement” is still unknown around. It will soon be popular like compilers. • Start tomorrow  Agile Process Improvement

  27. Questions & Answers Q & A Joshua Klein Consultant in Process Improvement of Software / Systems Development 6 Michlin street, Jerusalem 96430, IsraelCell: 972-55-665247 Phone:972-2-6434290j.h.klein@ieee.orghttp://www.yedidia.net/jklein Agile Process Improvement

  28. The End

  29. The Lecturer Joshua Klein Consultant in Process Improvement of Software / Systems Development 6 Michlin street, Jerusalem 96430, IsraelCell: 972-55-665247 Phone:972-2-6434290j.h.klein@ieee.orghttp://www.yedidia.net/jklein Agile Process Improvement

  30. The Lecturer (ctd.) • 2002–2003 Process Improvement Consultant (Intel) • 1993–2001 NDS Process Group Leader • 1990–1992 Sapiens Methodology Team Leader • 1988–1990 Sapiens France Directeur Technique • 1980-1988 Ministry of Housing DBA • 2002 Honourcode Eng. of complex systems • 1998 Standards Institute Lead quality auditor • 1987-1988 Inst. of Productivity Project Manager • 1972-1975 Hebrew Univ. of J-lem Mathematics, Physics, Computers • 1969-1971 Yeshivat Hanegev Talmud studies • Born in Neuilly, France, 1951 Work Studies Agile Process Improvement

More Related