Normal
0
false
false
false
EN-US
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
I subscribe to the tenets put
forth in the Manifesto for Agile Software
Development - http://agilemanifesto.org. As Oracle's chief methodologist,
that might seem a self-deprecating attitude. After all, the agile manifesto
tells us that we should value "individuals and interactions" over "processes
and tools." My job includes process development.
I also subscribe to ideas put
forth in a number of subsequent works including Balancing Agility and Discipline: A Guide for the Perplexed (Boehm/Turner,
Addison-Wesley) and Agile Project
Management: Creating Innovative Products (Highsmith, Addison-Wesley). Both
of these books talk about finding the right balance between "agility and
discipline" or between a "predictive and adaptive" project approach.
So there still seems to be a
place for us in creating the Oracle Unified Method (OUM) to become the "single
method framework that supports the successful implementation of every Oracle
product." After all, the real idea is to apply just enough ceremony and produce just enough documentation to suit the needs of the particular project
that supports an enterprise in moving toward its desired future state.
The thing I've been struggling
with - and the thing I'd like to hear from you about right now - is the
prevalence of an ongoing obsession with "documents."
OUM provides a comprehensive set
of guidance for an iterative and incremental approach to engineering and implementing
software systems. Our intent is first to support the information technology system
implementation and, as necessary, support the creation of documentation. OUM,
therefore, includes a supporting set of document templates. Our guidance is to
employ those templates, sparingly, as needed; not create piles of documentation
that you're not gonna (sic) need. In other words, don't serve the method, make
the method serve you.
Yet, there seems to be a "gimme"
mentality in some circles that if you give me a sample document - or better yet
- a repository of samples - then I will be able to do anything cheaply and
quickly. The notion is certainly appealing AND reuse can save time. Plus,
documents are a lowest common denominator way of packaging reusable stuff. However,
without sustained investment and management I've seen "reuse repositories" turn
quickly into garbage heaps. So, I remain a skeptic.
I agree that providing document
examples that promote consistency is
helpful. However, there may be too much emphasis on the documents themselves
and not enough on creating a system that meets the evolving needs of the
business.
How can we shift the emphasis
toward working software and away from our dependency on documents - especially on
large, complex implementation projects - while still supporting the need for
documentation? I'd like to hear your thoughts.
