Hi.
For me "Change Management" is a discipline, but not a practice.
The difference is that change management just implies that a solution
for managing change is needed, but not the concrete set of practices and
procedure that are performed to achieve this need of managing change. The
same with Requirements Management or Project Management: Not practices,
just disciplines. Putting an ambiguous adjective such as Basic or Flexible
in-front of it makes it in IMHO even worse as it even becomes less clear
what it means. There is also no value communicated with these words.
Many of our other practices much better communicate what the practice is
actually about, such as Evolutionary Architecture, i.e. the practice of
not creating an architecture up-front, but evolving it out of the solution
development.
Hence, better names would be "everyone can request change" or
"state-machine driven change tracking" or "attribute-driven
work item list management". If we do not have a practice for actually
managing changes in OpenUP then the name should also reflect that such
as "submitting changes into a work item list" is all I can see
for now.
Thanks and best regards,
Peter Haumer.
______________________________________________________________
PETER HAUMER, Dr. rer. nat.
Rational Method Composer | Eclipse Process Framework
Rational Software | IBM Software Group
Tel.: +1 (408) 463-5096
______________________________________________________________
From:
| "Ken Clyne" <ken.clyne@xxxxxxxxx>
|
To:
| "Eclipse Process Framework Project
Developers List" <epf-dev@xxxxxxxxxxx>
|
Date:
| 08/13/2008 12:51
|
Subject:
| Re: [epf-dev] Renaming "Change
Management" practice to "Basic Change Management" |
Good dialog. Bruce I wasn't inferring we were claiming copyright
on "Change Management" but rather those people challenging your
use of the term were.
I like Ana's suggestion and Maciel's endorsement but also put forward one
of my own that is a bit a narrower but maybe apropos to the limited content
of this practice "Change Request Management".
On Wed, Aug 13, 2008 at 2:08 PM, Maciel, Eduardo (Brazil R&D) <maciel@xxxxxx>
wrote:
Hello all,
I´m not sure if contributions
are expected from non usual contributors, such as me, but I´d like to opine
about this subject.
I agree with Ana Pereira. In
my humble opinion, Scope Management is the best term.
- For most
of people Change Management reminds a very strict and formal process.
- By "managing
the scope" one can understand it comprehends the management of changes
also.
- The type
of change management most of lightweight processes implement is a different
paradigm if compared to traditional change management and usually are nothing
more than keeping the scope under control (tracking, creating or removing
work items).
Regards,
Maciel
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ana Paula Valente Pereira
Sent: quarta-feira, 13 de agosto de 2008 14:09
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] Renaming "Change Management"
practice to "Basic Change Management"
what about Flexible ? ... Flexible Change or Scope Management?
... contrasting with traditional change management that seems to be more
rigid ...
Ana
On Wed, Aug 13, 2008 at 5:20 PM, Bruce Macisaac <bmacisaa@xxxxxxxxxx>
wrote:
Hi Ken,
I think the point is that without the qualifier, it makes it hard to name
alternative change management practices.
In other words, if we have 3 change management practice alternatives, and
one is called change management, it's hard from the name to know what kind
of change management is being described
by the practice. Also, it may seem unfair for us to claim copyright
to "change management" - by adding some kind of qualifier, at
least we are only claiming our brand of change management.
Another suggestion from Per is "Informal Change Management".
Is that better than "Basic"?
Note that this practice, as it stands, just has one task, which is to submit
change requests, and otherwise changes are really being addressed as part
of
work item management done by the iterative development practice. It's
not a traditional formal change management approach with a CCB and unique
states for change requests.
Bruce MacIsaac
Manager - RUP/OpenUP Content
bmacisaa@xxxxxxxxxx
phone: (408)463-5140
I don't know I think you got it right the first time. Firstly, I
don't think its fair for any one group to claim copyright to the term Change
Management. Secondly the term "Basic" is almost pejorative and
somehow diminishes the importance of the practice (think about Basic Project
Management, Basic Architecture etc). Thirdly, I'm not sure we need
a qualifier, one would think the context would be sufficient if we put
"Basic" before one practice what does that mean about the other
practices.
My $0.03
On Tue, Aug 12, 2008 at 3:46 PM, Bruce Macisaac <bmacisaa@xxxxxxxxxx>
wrote:
Chris Sibbald and I would like to make this change to address concerns
raised by reviewers.
The basic concern is that they expected from the name that this would be
a formal change management practice, and it's not.
See bugzilla:
I plan to make this change tomorrow, so if there are any
concerns at all with this, please let me know as soon as possible.
Thanks,
Bruce MacIsaac
Manager - RUP/OpenUP Content
bmacisaa@xxxxxxxxxx
phone: (408)463-5140
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev