Example: bachelor of science

TALKING POINTS Quality in an Agile World - …

TALKING POINTS . Quality is an inherent aspect of true Agile software development. The majority of agilists take a test-driven approach to development where they write a unit test Quality in an Agile World before they write the domain code to fulfill that unit test, with the end result being that they have a regression unit test suite at all times. They also consider acceptance tests as first-class requirements artifact, not only promoting regular stakeholder validation of BY SCOTT AMBLER. their work but also their active inclusion in Ambysoft, Inc. the modeling effort itself. Agilists refactor their source code and database schema to keep their work at the highest possible qual- ity at all times.

Quality in an Agile World software. In short, the bureaucrats have taken over in many traditional information technology (IT) organiza-tions. Something has to give.

Tags:

  Quality, World, Agile, Software, Quality in an agile world, Quality in an agile world software

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of TALKING POINTS Quality in an Agile World - …

1 TALKING POINTS . Quality is an inherent aspect of true Agile software development. The majority of agilists take a test-driven approach to development where they write a unit test Quality in an Agile World before they write the domain code to fulfill that unit test, with the end result being that they have a regression unit test suite at all times. They also consider acceptance tests as first-class requirements artifact, not only promoting regular stakeholder validation of BY SCOTT AMBLER. their work but also their active inclusion in Ambysoft, Inc. the modeling effort itself. Agilists refactor their source code and database schema to keep their work at the highest possible qual- ity at all times.

2 The challenge for Quality professionals is that agilists work in a highly INTRODUCTION. collaborative and evolutionary (iterative and Modern software processes are evolutionary, iterative, and incremental) manner, often requiring tradi- incremental in nature. This includes processes such as Rational tional Quality professionals to change their Unified Process (RUP) (Kruchten 2004), Extreme Programming approach. (XP) (Beck 2000), Enterprise Unified Process (EUP) (Ambler, Key words: Agile model driven development, Nalbone, and Vizdos 2005), and rapid application development Agile software development, collaborative (RAD), to name a few. Furthermore, many modern processes development, evolutionary, incremental development, iterative development, refac- are Agile , which for the sake of simplicity I will characterize as toring, software processes, test-driven both evolutionary and highly collaborative in nature.

3 The fun- development damental nature of software development is changing, and qual- ity professionals must change with it. In this article I introduce SQP References readers to common Agile software development techniques and The Role of Testers in the Agile Methods argue that they lead to software that proves in practice to be of much higher Quality than what traditional software teams usu- vol. 7, issue 3. Alan S. Koch ally deliver. It is common to say that agilists are Quality infected, and that the greater emphasis on Quality implies a Extreme Programming Series changed and perhaps even smaller role for Quality professionals vol. 5, issue 1. Pieter Botman and Ray Schneider on Agile software development projects.

4 Why are developers adopting evolutionary, and more often, Agile software processes? Over the years developers have dis- covered that traditional software development processes, in par- ticular the well-defined prescriptive processes, work poorly in practice (Larman 2004). First, the Chaos report, published by the Standish Group ( ), still shows a significant failure rate within the industry, indicating that pre- scriptive processes simply aren't fulfilling their promise. Second, it appears that most developers do not want to adopt prescriptive processes and will find ways to undermine efforts to adopt them, either consciously or subconsciously. Third, the big design up front (BDUF) approaches to software develop- ment, where significant modeling and documentation occurs before a single line of code is written, are incredibly risky in practice because they don't easily support change or feedback.

5 For example, one might build what was defined in the specifica- tions, but if the specifications don't reflect what people actually require then there is serious trouble. This risk is often ignored, if it is recognized at all, by the people promoting these approaches. Fourth, most prescriptive processes promote activi- ties that are only slightly related to the actual development of 34 SQP VOL. 7, NO. 4/ 2005, ASQ. Quality in an Agile World software . In short, the bureaucrats have taken over in many traditional information technology (IT) organiza- tions. Something has to give. Some Definitions This article uses the terms collaborative, incre- mental, and iterative development, and it is THE Agile MOVEMENT important to understand how each term is To address the challenges inherent to traditional used: development a group of 17 methodologists formed the 1.

6 Collaborative development. When a team Agile software Development Alliance (http:// takes a collaborative approach they ), often referred to simply as the actively strive to find ways to work Agile Alliance, in February 2001. Although all mem- together effectively; teams should even try bers of this group came from different backgrounds to ensure that project stakeholders such as they were able to come to an agreement on issues that business customers are active team mem- methodologists typically do not agree upon. They con- bers. They should strive to adopt the hottest communication technique appli- cluded that to succeed at software development one cable to their situation: prefer face-to- must focus on people-oriented issues and follow devel- face conversation around a whiteboard to opment techniques that readily support change.

7 A telephone call, prefer a telephone call to The Agile movement started when they published sending an e-mail, and prefer an e-mail to their manifesto of four values and 12 principles (see sending someone a detailed document. sidebar, The Values and Principles of the Agile The better the communication and collab- Alliance ). A software process is considered Agile oration within a software development when it conforms to these values and principles. Agile team, the greater its chance of success software processes include XP, Scrum, dynamic sys- (Cockburn 2002). tem development method (DSDM), the Crystal family, 2. Incremental development. With an incre- feature-driven development (FDD), Agile modeling mental approach a team organizes its sys- (AM), and the Agile data (AD) method.

8 Although XP is tem into a series of releases instead of one clearly the most popular Agile process, there are a big one. variety to choose from. 3. Iterative development. Working itera- tively, a team does a little bit of an activity Just as there are common development techniques such as modeling, testing, coding, or and concepts, such as code inspections and data mod- deployment at a time, and then does eling, within the traditional World , there are also com- another little bit, then another, and so on. mon development techniques within the Agile World . This is different than a serial approach Interestingly, many of these techniques are focused on where they identify all of the requirements the creation and delivery of high- Quality software .

9 They are going to implement, create a These Agile techniques and concepts include: detailed design, implement to that design, Refactoring test and, finally, deploy the system. Test-driven development (TDD). Tests replace traditional artifacts the getPersons() operation to getPeople(). To imple- Agile model driven development (AMDD) ment this refactoring they must change the operation definition and then change every invocation of this operation throughout the application code. A refactor- Refactoring ing isn't complete until the code runs again as before. Refactoring (Fowler 1999) is a disciplined way to Similarly, a database refactoring (Ambler 2003a). make small changes to source code to improve its design, making it easier to work with.

10 A critical aspect is a simple change to a database schema that of a refactoring is that it retains the behavioral seman- improves its design while retaining both its behav- tics of the code developers neither add nor remove ioral and informational semantics. Developers could anything when they refactor, they merely improve its refactor either structural aspects of the database Quality . An example refactoring would be to rename schema, such as table and view definitions, or func- 35. Quality in an Agile World tional aspects, such as stored procedures and triggers. FIGURE 1 Test-driven development When they refactor their database schema, not only must they rework the schema itself but also the external systems, such as business applications or data extracts, which are coupled to their schema.


Related search queries