Process that Works: liberating software projects

Size: px

Start display at page:

Download "Process that Works: liberating software projects"

Lionel Gregory
5 years ago
Views:

1 Process that Works: liberating software projects Gerry de Koning November 4, Gerry de Koning Gerry de Koning 1

2 A process specification is not a process Gerry de Koning 2

3 A process specification is not a plan Gerry de Koning 3

4 A process specification should stabilize and improve process capability Gerry de Koning 4

5 A process specification places constraints on the process Gerry de Koning 5

6 The commandments Specify a process if you will do it at least three times. Don t confuse a process specification with the process. Seek to stabilize and improve the process capability. Don t place unnecessary constraints on the people who do the activities Gerry de Koning 6

7 Order Users want to feel good discipline knowing what to expect coordination Freedom flexibility no micro-management Simplicity Gerry de Koning 8

8 Users want a conscience We ought to do this, so make it a rule. Do not agree to add conscience items. It guarantees the users will feel guilty and inadequate. Never give an order that will not be obeyed Gerry de Koning 9

9 Users want usable process specifications for coordination plans, agreements, expectations for education but don t audit me to this! for discipline the rules & policies for the organization for remembering don t accidentally forget anything Gerry de Koning 10

10 The commandments Don t constrain people unnecessarily. Base the process specification on risks projects really face. Do not specify things people ought to do, but won t Never give an order that won t be obeyed. Select techniques adapted to how your process specification will be used Gerry de Koning 11

11 Traditional techniques Big binders Process overview Detailed descriptions of activities Educational and prescriptive material Diagrams Structured text Tailoring instructions Gerry de Koning 12

12 Graphic techniques Boxes and arrows Order T-shirts Write software Announce Product Product Pricing Product specs Ship Product Naming Write manual Test Gerry de Koning 13

13 Graphics techniques Roles and phases Opportunity Develop Launch Manufacturing Engineering Marketing Gerry de Koning 14

14 Graphics techniques Advanced modeling methods Petri nets requires high level of completeness good for dynamic modeling of a process good analytical tool Harel statecharts models several dimensions of a process can be used for simulations good tool for process understanding Gerry de Koning 15

15 Graphics techniques Summary good for discussions about process good for presenting a process overview for simplicity, the diagram must be kept at a high level needs to be supplemented by text well-defined boxes, ambiguous arrows hard to show options on a diagram ambiguities resolved by adding complexity may miss the critical factors for stabilizing process capability focuses attention on the handoffs; encourages design by sequence of handoffs Gerry de Koning 16

16 The commandments Use graphic techniques for discussions about process. Be clear about what your arrows mean. Reduce handoffs Don t give up flexibility just because it s hard to show in a diagram. Don t use graphics techniques to specify rules for your process Gerry de Koning 17

17 Textual techniques ETVX E T Task X Entry Criteria V Validation Exit Criteria Gerry de Koning 18

18 Textual techniques CMM inputs entry criteria activities roles measures verification steps outputs exit criteria Gerry de Koning 19

19 Textual techniques Summary Strong temptation to include unnecessary material Tends to micro-manage developers Tends to get large and boring. someone will have to maintain it users don t want to be intimidated A good framework for systematically asking questions about an activity Gerry de Koning 20

20 The commandments Don t be complete. Specify only the things that matter. Don t focus on form Don t be afraid of not specifying something Keep it simple. Use ETVX, or CMM, as a checklist for activity descriptions. Useful in a process asset database Useful in education Gerry de Koning 21

21 A new architecture for process specifications Process rules Checklists The process rules Processes Tools Examples Guides Presentations Gerry de Koning 23

22 The process rules layered apply uniformly to everyone Configuration Management. Configuration Management includes version control, the build process and change management. Each project must describe what documents, deliverables, tools and other materials will be placed under configuration management. Each project must describe how it meets the following: Version Control. A project must be able to retrieve any version of a specific configuration item. A project must describe the procedures used to check configuration items in and out of the managed repository. Build Process. A project must be able to identify which elements under version control are part of specific baselines and builds. A project must be able to recreate a specific build from the elements under version control. Change Control. A project must be able to identify the requests for changes to configuration items (both enhancements and problem reports). A project must describe how decisions are made about allowing or rejecting changes and scheduling them into specific baselines or builds. Change authorisation procedures may become more stringent over time Gerry de Koning 24

23 two kinds: The checklists what will we do? how are we doing? or what s happening? specify content, not documents a list of data items allow projects to specify how to communicate the data a memory aid, not one size fits all updated after each post-mortem Gerry de Koning 25

24 The tools All the processes are available on the web. Checklist viewer create custom views of checklists for reviews and document comparisons Template maker create templates for specific documents user can choose format: MS Word or HTML Gerry de Koning 26

25 The new approach Summary Rules, memory aids, advice, education and tools are separate. Each project has its own needs & risks. Projects can design communication mechanisms to meet their needs. Tools help people use the process specification. Everything is on the web Gerry de Koning 27

26 The commandments Use different specifications for different audiences. Separate the rules from the checklists. Use checklists for memory aids. Use tools to make the process easy to do and to manage. Keep educational materials away from the auditor Gerry de Koning 28

27 The commandments Understand the process before you specify it. Make sure the process can be monitored. Don t be complete only specify things that matter work with your users to to determine what matters and what doesn t Gerry de Koning 29

28 The commandments Reduce handoffs handoffs destroy knowledge. Put everything on the web Put tools into the managers hands for checklist tailoring for using checklists for creating artifacts for managing communications Gerry de Koning 30

29 Thank you! Gerry de Koning 31

Web Evaluation Report Guidelines

Web Evaluation Report Guidelines Graduate Students: You are required to conduct a usability test for your final project in this course. Please review the project description and the evaluation rubric on