Agile Software Process Improvement

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Agile Software Process Improvement

  • 1. There is No Mystery (From Methodologies as Swimsuits by Alistair Cockburn)
    • Projectscome in different shapes and sizes.
    • Methodologiescome in different shapes and sizes.
    • Peoplecome in different shapes and sizes.
    • Thepeoplemay not fit themethodology .
    Thepeopleare the more important.

2. (Software) DevelopmentProcess Improvement By:Joshua Klein Agile More about the lecturer 3. You dream of being more efficient 4. Youmustbe more efficient! 5. But you cant afford the improvement methodologies CMMI ISO Competitive 6. Process Improvement should be:

  • Evolutionary
  • Scalable
  • Pragmatic
  • Flexible
  • Motivating
  • Creative
  • Assertive

Agile 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 7. The motivation cycleOpenness Change Improved process Motivation Success Failure Poor process Sponsorship 8. Success criteria

  • 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 managements 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)

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. 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 10. The Improvement Leader

  • The Improvement Leaders role expands the Lead Assessors 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

11. The Improvement Leaders role Improvement Implementation Improvement Plan Assessment 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

13. CMM (with some CMMI) Individual Heroes 1 Initial / Incomplete Requirements Management Software Project Planning SW Project Tracking & Oversight Measurement and Analysis Software Quality Assurance Software Configuration Management Project Management 2 Repeatable / Managed Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Risk Management Decision Analysis and Resolution Peer Reviews Technical Engineering Processes 3 Defined Quantitative Process Management Software Quality Management Measurement & Process Control 4 Quantitatively Managed Defect Prevention Technology Change Management Process Change Management Continuous Improvement 5 Optimizing Key Process Areas Focus Level 14. Open benchmark Where are we standing now ? Where could we be ? How to get there ? 15. Objectivity and normalization

  • Outputs ofOpenAssessment 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

16. Plan

  • Prioritization
  • Broad acceptance
  • Available solutions
  • Short term
  • Criticality

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 / September October November December Assessment findings 17. SW manufacturing processes Supporting process Production process Concept Design Implementation Validation Maintenance Disposal Requirements Documentation Configuration management Quality assurance Organizational process Management Infrastructure Improvement Human resources Planning Product Inspired from ISO 15288 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 19. Focused assessments 20. The Roadmap Require- ments Design Developertest Coding Practices Require- ments Design Require -ments Design Require- ments Design Require- ments Design SPI Planning Require- ments Design SPI Bodies Training Reasess- ment Tools 1 Assimilation Deployment Training Methods & Procedures Pilot Assessment Infrastructure J u l y 0 2 A u g u s t 0 2 S e p t e m b e r 0 2 N o v e m b e r 0 2 D e c e m b e r 0 2 J a n u a r y 0 3 F e b r u a r y 0 3 O c t o b e r 0 2 Measu- rement Measu- rement Debrie- fing March 03 Developertest Developertest Developertest Developertest Developertest Coding Practices Coding Practices Coding Practices Coding Practices Coding Practices Ramp up MSC Assessment MSC Assessment MSC Assessment 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 22. SEPG charter

  • The LAD SWSoftware Engineering Process Group (SEPG) isthe 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 .

23. SPI Organization Policy + resources Reports each ~ 5 weeks + discussion LAD SWGL LAD SW Staff LAD SWSPI SEPG Pilot(s) Procedures & methods SQA Manages Controls & tracks Consults, coaches, writes reports, etc Intel Quality Bodies 24. The Coding Rules Intranet page 25. SPI problem solving 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

27. Questions & Answers

  • Q & A

Joshua Klein Consultant in Process Improvement of Software / Systems Development 6 Michlin street, Jerusalem 96430, Israel Cell: 972-55-665247 Phone:972-2-6434290 [email_address] 28. The End 29. The Lecturer

  • Joshua Klein
  • Consultant
  • in
  • Process Improvement
  • of
  • Software / Systems Development

6 Michlin street, Jerusalem 96430, Israel Cell: 972-55-665247 Phone:972-2-6434290 [email_address] 30. The Lecturer (ctd.)

  • 20022003 Process Improvement Consultant (Intel)
  • 19932001 NDS Process Group Leader
  • 19901992 Sapiens Methodology Team Leader
  • 19881990 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

W o r k Studies 31. 32. Backup 33. End of backup