|
 What does it mean to be process oriented? I have had many times when a colleague patiently explained to me that his group's process is to do one thing or another. The only problem is that I quickly ascertained that there really was no "process" in place at all. My colleague was really trying to tell me how his team was working. Now defining a process is not always necessary or even valuable at times. I shocked a colleague recently when I argued that a checklist was better than defining a process for some tasks. His expression of shock and dismay indicated that I had suddenly become a heretic in his eyes. Read on if you would like to understand what processes are all about and when it is appropriate to use them.
Do you need repeatable? A process is a clearly defined way of completing one or more tasks that includes inputs/outputs, roles and responsibilities and a clearly defined milestone or test to indicate when the process is completed. Processes, by definition are repeatable - which means that you should get the same results when any qualified resources complete the process according to the specification. Being process oriented means that you have the ability to get the job done without having to play hero on regular basis. Visibility A well defined process includes support for communicating what has been completed and exactly what remains to be done. Processes should always have a mechanism for providing visibility to those authorized to see them. In CM we usually talk about repeatable processes to support tasks such as automated build and deploy. Imagine if you could not rely upon your build procedures to produce the same executable from one day to another. I have worked in places who had exactly that problem - which was usually my job to fix. The best way to approach defining a process is to list the exact tasks that need to be completed - so far you just have a checklist. Next you define who is responsible for each step and also what goes and in and what comes out of each step (e.g. inputs and outputs). Most importantly, processes should be testable. You should be able to specify exactly how you can tell if the process was completed successfully. I have often watched developers troubleshoot a build and then capture their tests making my builds more reliable and repeatable. Now we have a process! Bob Aiello is the Editor-in-Chief for CM Crossroads and an independent consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him via LinkedIn http://www.linkedin.com/in/bobaiello
Set as favorite
Bookmark
Email this
Hits: 8146 Trackback(0)Comments (11)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Bhano - can you elaborate a little more on that. I sense that you are making a good point, but I am not sure that I fully understand what you are suggesting. Even better friend me online at and we can chat about getting your thoughts into a blog posting (hint - I will help you - and that goes for anyone else as well). Bob |
Bhanu Rao
said:
 |
... Would like to share my thoughts ... though a little late in the trail. Agree with Bob that process is not opposite development. And that 22 processes in CMMI 'Do Not' require 22 processes to be defined and maintained. An organization can have and must have a process for the project, tailored from the org's std process. However detailing process elements ETVX (entry, task, validation, exit)and defining in-detail check-list and guidelines makes more sense than purely adding a CM process. |
Nice Article......
Frank Schophuizen
said:
|
... A common pitfall is that CM is defined as a separate process, as if it can be dealt with independent of project management, requirement management, test management or other management disciplines. This approach is encouraged by the way CMMI treats CM: a separate process area and no information about CM (only about how it should be organized). For example, CMMI defines that you need to have a CM plan, you need to identify your work products and that you should to define how you control your work products. There is no clue that "work products" should be ALL deliverables (that are of business value) that ALL processes produce, including both engineering deliverables and management deliverables. And there is no clue that "work product" may be a file, a document, a component but also an individual requirement or an individual test case (or any other 'record' in a database, that never occurs as an individual file or document). But worse, there is no clue that CM is tightly connected to project management (e.g. identification of releases is closely related to definition of milestones), to requirement management (e.g. versioning and baselining of requirements), test management, architecture (e.g. reusable components, interface control). If you want to define a "process for CM", don't bother. Better define a "process for the project" (or the organization, or an iteration, or what ever) and don't bother which parts are project management, configuration management, requirement management, test management, release management, build management, etcetera. The process is a single system, and should be treated as a single system. |
Bob Aiello
said:
|
... Of course!! In my Behaviorally Speaking column http://www.cmcrossroads.com/co...0298/135/ and also in our Compliance Zone http://www.cmcrossroads.com/content/view/11068/673/ and there's more where that came from! Bob Aiello Editor in Chief |
DeepVerma
said:
 |
... Thanks for giving insight of a so called thing "Process". Indeed, we need to have "Entry Criteria", "Process Criteria" and "Exit Criteria" defined for a process. But now the question is of Governance / Assurance i.e process being followed. Is there any thing on that? |
Bill Langston
said:
|
... Good article, Bob, and good response, Ben. To expand on Ben's comment, I'd like to insert this sentence after the start point and end point are identified, but before concentrating on the forms, systems, etc. needed to capture the information: "Identify the steps (or tasks) needed to get from the start point to the end point." In other words, identify start point and end point, steps, tools (spreadsheets, templates, etc.), who does each step, where, etc. |
Alfred
said:
|
... Thank you for your reply! I think a development is not repeatable - you always get different results. A development effort means the concrete time period (iteration) with hopefully a (partially) product as the result. A process stores the insights (and results) you got from the development activity (iteration) and provides an outlook for what could be developped next - based on your stored knowledge. I aggree with you that the process must be in harmony with development. But they are different activities which can't be done in parallel. regards Alfred |
Bob Aiello
said:
 |
... I don't understand your point. I do not believe that process is the opposite party to development at all. I believe that process improvement should be built into the development effort (just as testing should be). I also advocate that process improvement folks should ideally be technical and hands-on so that they really understand the development process first-hand! So I would view process as being in harmony with development. I would really like to understand what you were suggesting so please explain your point a little bit more :-) Feel free to contact me offline at raiello[at]acm.org or via linkedin http://www.linkedin.com/in/BobAiello |
Alfred
said:
|
... So process is the opposite party to development. Perhaps this is the cause of my problems with understanding development processes  |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
