[Owasp-cert] Good bye.

Kamal Wickramanayake kwickramanayake at gmail.com
Tue Aug 12 00:55:52 EDT 2008


Food for thought here. I am collecting some resources that I found
useful:

1) Agile Manifesto
Sets the orientation for all the agile processes
http://agilemanifesto.org

2) Agile Principles
Describes the foundation stones of agile processes
http://agilemanifesto.org/principles.html

3) Declaration of Interdependence for Modern Management
Provides a management side perspective
http://alistair.cockburn.us/index.php/The_declaration_of_interdependence_for_modern_management

Once the above are read, you understand that it's impossible to write
something and call it "THE Agile Book". Hence, you acknowledge the value
of a multitude of processes that have sprung. Within the perimeters of
the above, you can choose to follow one specific agile process or use a
mixture of techniques coming from a number of known agile processes. You
select based on the value the specific process/technique brings to your
project according to the context. Your process is adaptive, but
principle driven.

Some notable processes (not all!):

1. Scrum
The life cycle described in Scrum is fixed and explains a valuable
working model. I don't mind about the certification.
http://www.scrumalliance.org/pages/what_is_scrum

2. OpenUP
In case you like to read in detail, this is the one. Download the OpenUP
published web site and unzip.
http://www.eclipse.org/epf/

3. Extreme Programming
Site has full details. A zip download is also available.
http://www.extremeprogramming.org/

5. Agile Model Driven Development
Yum, yum! Full details are available. This page links to other pages
within the site.
http://www.agilemodeling.com/essays/amdd.htm

As said, followers of agile principles don't have to stick with any
specific process above.

But agile processes don't mean loose or undisciplined. Agile processes
demand more discipline than heavy weight alternatives like RUP,...

Agile processes are not documented with bells and whistles. Following
agile principles, they have been documented to the just sufficient
degree. Hence, there's little chance to find a comprehensive rigid body
of knowledge coming from one source - not required, not valued by agile
practitioners. OpenUP has been documented more than other processes
which has derived its flavors from both agile principles and Unified
Process. Furthermore, OpenUP documentation comes with bells and whistles
due to the process editor used (Eclipse Process Composer).

Agile processes are being practiced by small and big companies alike.
For example, IBM is known to have agile projects with team size even
reaching the order of 500-600 people. (Source:
http://www.ddj.com/architect/208700162)

Many folks still do not know about this specific meaning of "Agile".
They think it describes a sloppy process (or no precess at all), can do
whatever they want and call what they have done falls under an agile
process - which is wrong. Such folks should at least visit the first
three URLs provided in this mail and start understanding what this
flavor of "Agile" is (other than the plain dictionary meaning).

Kamal

On Mon, 2008-08-11 at 14:04 -0400, McGovern, James F (HTSC, IT) wrote: 
> My thought says that there are most certainly better ways to develop
> software and that agile approaches need to be encouraged throughout. The
> key challenge for an exam is to make sure that there is a body of
> knowledge that exam takers can read and I don't believe that one exists
> for the subject areas mentioned.
> 
> I could be wrong, but would certainly like to know. We can't really base
> an exam on presentations and tribal knowledge... 

-- 
Kamal Wickramanayake
IT/Software Architect & Trainer
Software View - http://www.swview.org/
World Quality Trainings!



More information about the Owasp-cert mailing list