Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

In This Issue:

• The Manifesto for Software Craftsmanship
• Book Review: Perfect Software
• Hot Links

The Manifesto for Software Craftsmanship

In the Spring of 2001, 17 software development experts got together to discuss successful approaches to software development. One result of that effort was the Agile Manifesto which defines what has become known as the four agile values. Each value is worded in the format X over Y, and although both X and Y are important agile developers have found that X in general is more important than Y.

Value #1: Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively. This includes -- but is not limited to -- programmers, testers, project managers, modelers, and your customers. Just as Walker Royce revealed a few years earlier in his book Software Project Management, the Agilists had discovered that the primary determinant of success on software development projects was the way that people work together.

Value #2: Working software over comprehensive documentation. Documentation has its place, written properly it is a valuable guide for people to understand how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents "- otherwise it would be called documentation development wouldn't it?

Value#3: Customer collaboration over contract negotiation. Only your customer can tell you what they want. Having a contract with your customers is but it isn't a substitute for communication. Agile teams promote the practice active stakeholder participation where stakeholders, or their representative(s), interact with the team on a daily basis, they are responsible for providing information to the team in a timely manner, for making decisions in a timely manner, and for prioritizing requirements.

Value #4: Responding to change over following a plan. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a project plan, in fact the vast majority of agile teams develop and maintain a high-level release plan. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.

The Agile Manifesto is a great start, but it's only a start. Recently a group of people have collaborated to write what they are calling The Manifesto for Software Craftsmanship which extends the Agile Manifesto. The values of this manifesto is in the format X but also Y, where in pursuit of X they have found that Y is indispensable.

p>Value #1: Not only working software, but also well-crafted software. Although the principles behind the agile manifesto discussed the importance of quality, the values never did. Disciplined agile developers know that well-crafted software is loosely coupled, highly cohesive, easy to understand, and easy to extend and actively seek to write such software.

p>Value #2: Not only responding to change, but also steadily adding value. Agile developers embrace the concept that stakeholder requirements and priorities change over time, but that doesn't mean the change should occur in a haphazard manner. They invest time to analyze the business environment and to work with stakeholders to synthesize a productive vision for supporting and enhancing their organization.

p>Value #3: Not only individuals and interactions, but also a community of professionals. Disciplined agile developers work closely with one another, sharing their skills with one another and thereby learning together. They do this within the organizations that they work and in the larger overall IT community.

p>Value #4: Not only customer collaboration, but also productive partnerships. Disciplined agile developers work closely with stakeholders to understand their environment and over time become trusted advisors to them.

I view this manifesto as an important step in the maturation of software development. I see it as a sign that we're moving away from the rhetoric of Level 1 agile software processes on the Agile Project Maturity Model (APMM) such as Scrum and Extreme Programming (XP) to the more disciplined mindset that we see with Level 2 processes such as Open Unified Process (OpenUP) and Dynamic System Development Method (DSDM).

Book Review

Gerry Weinberg wrote this, 'nuff said! Seriously though, Perfect Software and other Illusions about Testing is great book for anyone directly involved with testing systems or who manage people who test systems. Weinberg has been involved with testing since the late 1950s, and this book shows it. The book is concise, at 182 pages, yet it contains wisdom rarely found in books five times that size. A lot of the book focuses on the people side of things, such as why defects occur, why we struggle to understand them, and why we often deny that they are even there. It also covers a lot of the misunderstandings about testing, such as belief in the ability to find all defects (instead you need to test to the risk), to do 100% path testing (path testing is exponential), that testing results in quality (fixing improves quality), and that anyone can test (testing takes skill).

Each chapter ends with a list of common mistakes, which is important because if you're not aware of your mistakes you can't possibly correct them. For example, common mistakes people make when trying to determine the significance of a defect is to confuse the difficulty of addressing the defect with its importance, misjudging the time it took to find a defect with the level of its significance (sometimes you can find really serious problems quickly), failing to realize that defect significance can be mostly political, and failing to reassess significance as new information becomes available (to list but a few).

Hot Links

The Manifesto for Software Craftsmanship

The article Examining the Agile Manifesto explores in detail tha values and principles of the Agile Manifesto.

The article Active Stakeholder Participation overviews why and how stakeholders can become valuable members of software development teams.

For more information about agile approaches to requirements, read this paper.

The Agile Process Maturity Model (APMM) is described here.

My Agility@Scale blog is where I discuss strategies for adopting and applying agile strategies in the complex environments.

RELATED ARTICLES Securing the Java Core Petascale Tools and Genomic Evolution Legal Compliance: Open Source and Quality Assurance SEI, Army Team Up on Software Testing Nozzle: Counteracting Memory Exploits		TOP 5 ARTICLES No Top Articles.