1 / 44

Enough of Process - Let's Do Practices

Enough of Process - Let's Do Practices. Ivar Jacobson, Pan Wei Ng, Ian Spence Contact: ivar@ivarjacobson.com. CMMI, Spice. Examples:. XP, Scrum. Unified Process. Enough Process – Let’s Do Practices. In the future, an ever present but invisible process.

rafer
Télécharger la présentation

Enough of Process - Let's Do Practices

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. Enough of Process - Let's Do Practices Ivar Jacobson, Pan Wei Ng, Ian Spence Contact: ivar@ivarjacobson.com

  2. CMMI, Spice Examples: XP, Scrum Unified Process Enough Process – Let’s Do Practices In the future, an ever present but invisible process The team’s way-of-working is just a composition of Practices Process becomes second nature Practice is a First Class Citizen the unit of adoption, planning and execution of process We need a new paradigm From the successes in modern software development The Software Engineering Camp Process Maturity Camp Agile Methods Camp

  3. NEW CMMI, Spice Examples: XP, Scrum Unified Process Enough Process – Let’s Do Practices In the future, an ever present but invisible process The team’s way-of-working is just a composition of Practices Process becomes second nature Practice is a First Class Citizen the unit of adoption, planning and execution of process We need a new paradigm From the successes in modern software development The Software Engineering Camp Process Maturity Camp Agile Methods Camp

  4. Agenda • A little bit of history • Thoughts from 40 years of practice development • What makes a good practice? • When is a best practice a well-formed practice? • Harnessing the power of practices • Using practices to get better at requirements • Wrap up

  5. 40 years of process* development * Process, Method, Methodology, whatever... Late ’60s Ericsson Approach CMM ‘87 –’96 Objectory Process SW-CMM XP, SCRUM & “Lightweight Methods” The Unified Process ‘96 –’00 XX-CMM Agile Manifesto IBM RUP CMMI ‘01 –’06 Everyone's Agile EssUP ‘07 –> ? The Rise of Practices ?

  6. ….or from a web-site. What else have we learnt? They’re hard to learn… You can get knowledge from books . . .

  7. …and hard to love • Every process tries to be complete • As a consequence every successful process will grow until it dies under its own weight • Every branded process is just a soup of ideas ”borrowed” from other processes • With some new idea(s) • The process is out of sync with what the team does… • …and the project – process gap get wider and wider • The project has to adopt an entire process • No-one uses an entire process or limits themselves to practices from one process It’s no wonder no-one likes process.

  8. Use-Case Driven Development Paper, OOPSLA, 87 The Objectory Process andObject-Oriented Software Engineering, Addison Wesley, 1992 UML, OOPSLA, 1995 IBM Method, 1996 The Rational Objectory Process, 1997 The Unified Software Development Process, Addison Wesley, 1999 RUP Catalysis, 1998 Company X, Y & ZMethods EssUP Crystal, 2004 More and more methods and processes using use cases. And now a simple practice again… Use-CaseEssentials A different perspective - 40 years of practice development ‘87 –’96 ‘96 –’00 ‘01 –’06 ‘07 –> ?

  9. What can we conclude from all this? • There is no one-true process, … there is no one-true way to manage your requirements. • Processes and practices, like the rest of our industry, never stand still • Good practices stand the test of time • We need a new way to share the knowledge – books and web-sites are not enough A new approach is needed – one that frees the practices from the tyranny of processes.

  10. Agenda • A little bit of history • Thoughts from 40 years of practice development • What makes a good practice? • When is a best practice a well-formed practice? • Harnessing the power of practices • Using practices to get better at requirements • Wrap up

  11. There are 100’s of so-called practices… Business Modeling Test-DrivenDevelopment Aspect Orientation Robustness Analysis PSP User Stories Scrum Product-Line Engineering Risk-DrivenIterativeDevelopment Systems Engineering Retro-spectives Business ProcessRe-Engineering Use-CaseDriven Development Pair Programming SOA Prince2 Use-CaseModeling ProgramManagement …but are really all the same kind of thing?

  12. There are 100’s of so-called practices… Business Modeling Test-DrivenDevelopment Risk-DrivenIterativeDevelopment Aspect Orientation Robustness Analysis Use-CaseDriven Development PSP User Stories Use-CaseModeling Scrum Product-Line Engineering Systems Engineering Retro-spectives Business ProcessRe-Engineering Pair Programming SOA Prince2 ProgramManagement …but are really all the same kind of thing?

  13. We need a shared definition of “practice” Pragmatics • A practice provides a way to systematically and verifiably address a particular aspect of a problem. • A Practice has a clear beginning and an end allowing it to be separately applied • Examples of practices are • Iterative development • Use case driven development • Project management à la Scrum • Team practice incl workshops, war room, pair programming, etc. More precisely • A use-case module in our AOSD book • It has a beginning and an end • It may be a peer practice or extend an existing practice

  14. Key: Peer Practice Extension Practice There are different kinds of practice … UnifiedProcessLifecycle Use-Casesfor ServiceDef’n Model-DrivenArch Comp’sfor Re-Use Comp’sfor .Net Scrum-of-Scrums TechnicalPractices … IterativeEssentials ScrumEssentials Use-CaseEssentials UserStories ArchitectureEssentials ComponentEssentials Test-DrivenDevelop’t … QAEssentials ProcessEssentials AgileModeling TeamEssentials Measurem’tEssentials PSP Cross-CuttingPractices … OrgProcessImp PracticeHarvesting EssentialUML DistributedTeam VirtualTeam

  15. Processes are just collections of practices … UnifiedProcessLifecycle Use-Casesfor ServiceDef’n Model-DrivenArch Comp’sfor Re-Use Comp’sfor .Net Scrum-of-Scrums TechnicalPractices … IterativeEssentials ScrumEssentials Use-CaseEssentials UserStories ArchitectureEssentials ComponentEssentials Test-DrivenDevelop’t … QAEssentials ProcessEssentials AgileModeling TeamEssentials Measurem’tEssentials PSP Cross-CuttingPractices … OrgProcessImp PracticeHarvesting EssentialUML DistributedTeam VirtualTeam Key: Peer Practice Extension Practice

  16. Iteration Use Case Architecture $ Component Product Modeling Team Process The Practices in the Essential Unified Process EssUP Practices TechnicalPractices Cross-Cutting Practices EssUP practices have been successfully applied by many companies in many markets.

  17. Use Case Architecture $ Component Product Modeling Team Process Disciplines and practices – two complementary perspectives EssUP Practices Iteration A process organized as a set of disciplines. Each discipline containing everything from every practice about an area of a process A set of individual practices that can be composed into a process

  18. EssUP Practices Iteration Use Case Architecture Config. / Change Mgt Environment Project Management Requirements Deployment Business Modeling Analysis & Design Implmentation Test $ Component Product Modeling Team Process Practices are ’end-to-end’ aspects of process • Practices cross-cut the traditional software engineering disciplines The 8 Essential Practices describe the essence of the Unified Process

  19. Consider use-case development as a practice Use-case driven development involves • specifying the system as a set of use-cases, • understanding what the elements of the system need to do to enable the use cases, and • verifying that the produced system fulfils the use cases. Use-CasePractice This requires Requirements, Analysis, Design and Test activities to be undertaken.

  20. Find the Practice – The Requirements Discipline

  21. Find the Practice – and Analysis and Design and Test Activities from the Requirements Discipline Activities from Test Activities from Analysis and Design

  22. Requirements Class... Test Case & Test Results Pass Fail Requirements and testing… Requirements define what should be implemented Test Cases verify that the system works as specified by the Requirements Code implements the requirements Implementation …closing the loop and defining what “done” is.

  23. Practice descriptions have many dimensions Weight: Heavy Light Application: General Specific Depth: Essentials Everything Breadth: Many Areas One Area HighlyConstrained Prescription: Unconstrained Ceremony: Low High Flexibility: Open Closed

  24. Practice descriptions have many dimensions Weight: Heavy Light Application: General Specific Depth: Essentials Everything Breadth: Many Areas One Area HighlyConstrained Prescription: Unconstrained Ceremony: Low High Flexibility: Open Closed Start with a lightweight, flexible definitionthat captures the essentials

  25. Practice descriptions have many dimensions Weight: Heavy Light Application: General Specific Depth: Essentials Everything Breadth: Many Areas One Area HighlyConstrained Prescription: Unconstrained Ceremony: Low High Flexibility: Open Closed Add detail, prescription, ceremony, and formality by extension

  26. But don’t go too far I’ve got all this guidance but it doesn’t help me Adding more and more detailed, step-by-step instructions doesn’t help anybody.

  27. Use-CaseEssentials I help with architecture I help with use cases People want smart, interactive practices Smart Practices come with intelligent agents and automated guidance. ArchitectureEssentials IterativeEssentials I help with Iterative planning Add active guidance, review, checking and help by automation.

  28. Practices need to embrace what’s happening Mash Ups Smart Tools Lightweight, composable, sociable, intelligent practices Social Networking

  29. A number of separate but composable, lightweight practices are already available… EssUP Practices OtherPractices Architecture Use Case Iteration …some with intelligent agents… Essential UML Component Product Domain Modeling SCRUM ... Team Process Modeling UP Lifecycle $ Use Cases Rules Engine Test Cases Fact Servers OO Analysis Rules Language J2EE Design Smart Practices IA Platform Game Boards EssWork / EssUP, RUP Rose, XDE, RSX, ReqPro, RMT, Test Manager, etc …and an interactive environment and community have been created. ClearCase, ClearQuest, Word, etc Integrations Eclipse, Web 2.0,VisualStudio ProcessKernel Cards This isn’t just hot air U P Start here Start here Finish here Finish here Start here Finish here

  30. We’ve more than enough best practices… • Separate the practices from one another • Combine them in innovative and exciting new ways • Stop re-inventing the wheel • Learn from the past • Focus on collaboration and improvement • Stop throwing the baby out with the bath water …let’s make them useful.

  31. We’ve more than enough best practices… • Separate the practices from one another • Combine them in innovative and exciting new ways • Stop re-inventing the wheel • Learn from the past • Focus on collaboration and improvement • Stop throwing the baby out with the bath water Free the Practices …let’s make them useful.

  32. Agenda • A little bit of history • Thoughts from 40 years of practice development • What makes a good practice? • When is a best practice a well-formed practice? • Harnessing the power of practices • Using practices to get better at requirements • Wrap up

  33. Forces that drive the practices used… • Stakeholder relationships • Stakeholder access • Number of requirements • Number of usage scenarios • Novelty of the system • Legal requirements • Business domain • Severity of errors (safety criticalness) • Team distribution and communication Select practices based on the nature of the problem not the nature of the process.

  34. Select the right practices for you • Workshops • JAD Sessions • Focus Groups • Questionnaires • Surveys • Observation • Interviews • Role playing • Brain storming • Change Control Boards • Use cases • User stories • Features • Declarative requirements • Scenarios and personas • Business modeling • Story boards • Prototypes Both “technical” practices … … and “social” practices.

  35. Take the right dosage • A practice should not be more sophisticated than you need • Apply the right dosage beginning with essentials. • Add more advanced techniques if your project is complex, to address some risks, or attain better quality and control, etc. Change ControlBoard Storyboards Add more advanced techniques to address risks Personas Workshops … Apply practices as you need them … Product Essentials Use Case Essentials Base Process UP, SCRUM, CMMI Or simply your own

  36. Turn up the level of detail as you need it Always start agile with requirements that are “place holders” for conversations. Evolve the level of detail as and when it is needed.

  37. Test Idea Formulated Briefly Described Scenario Chosen Bulleted Outline Variables Identified Individual flows may have different degrees of elaboration Essential Outline Variables Defined Fully Described Scripted /Automated Balance requirements detail and test detail Use Case Test Case ? Using tests to formalize requirements is a useful technique.

  38. Iteration $ Product Team Team Mix requirements, management and engineering practices A small teamdoing maintenance Major Investment Bank Education services company Scrum Use Case Use Case Iteration Architecture Use Stories Component Component Service Modeling Every team is different.Every practice adoption is different.

  39. Practice separation has many benefits • You can learn practices individually • You can apply practices separately • You can start in a lightweight fashion • You can adopt the practices you want, when you want, and at the pace that suits you • You can mix-and-match practices from any source • You can add ceremony as and when you need it Practice Separation: Empowering the analysts to analyze in the best way for their stakeholders and teams.

  40. Agenda • A little bit of history • Thoughts from 40 years of practice development • What makes a good practice? • When is a best practice a well-formed practice? • Harnessing the power of practices • Using practices to get better at requirements • Wrap up

  41. Lessons Learned Practice separation and incremental practice adoption really work. There is no one-true-way to approach requirements Selecting the right practice is about the problem, the team and the stakeholders not the process Always start from the essentials and only add more when needed Practice separation makes it easy to get started Introduce tools and intelligent agents to support and sustain the change 42

  42. CMMI, Spice Examples: XP, Scrum Unified Process Enough Process – Let’s Do Practices In the future, an ever present but invisible process The team’s way-of-working is just a composition of Practices Process becomes second nature Practice is a First Class Citizen the unit of adoption, planning and execution of process We need a new paradigm From the successes in modern software development The Software Engineering Camp Process Maturity Camp Agile Methods Camp

  43. But we need your help • Don’t be satisfied with brittle closed processes • Don’t be sucked into process wars and process engineering • Don’t close your mind to changes and innovations in the industry • Build on the good practice you use today… • … to create new and exciting ways-of-working • ….and evolve the next generation of truly best practices Let’s capture and share all our practices.

  44. Thank You ivar@ivarjacobson.com

More Related