Agile software development is touted as offering a faster, less-risky path to the creation of bespoke applications.
Yesterday, our primer on agile for CIOs covered:
Getting started: How to transition to agile
Benefits of agile development
Problems with agile development
Agile project management methodologies
Agile tools
Today, we complete the tutorial with a look at:
Agile development requirements gathering
Testing in an agile environment
More agile issues, considerations
Agile development requirements gathering
The rise of agile development processes has changed requirements as much as any other part of development. Agile-based principles are more open to adding and refining requirements later in the development process and to having as thin a level of document detail as possible -- less detail than was common in requirements gathering for traditional software processes. The agile approach to software requirements embraces change, flexibility and face-to-face communication in a just-in-time manner. This method can help bridge the communications gap between developers and users that has been a longstanding pain point in software projects.
So what are some approaches to defining requirements within agile teams? Agile development methods focus on defining "just enough" requirements detail for the next sprint. In other words, don't produce any requirements specifications that are not absolutely critical to getting the point across to the rest of the team. So how do you decide what is "just enough," and who makes this decision? What happens when the team is colocated or distributed? How do you deal with changes to these requirements details and their priorities?
According to Martin Crisp, CTO of Blueprint Systems, more detail in your requirements artifacts is a good idea when you're working with a new system, offshore or distributed teams, a newly formed team or a large, complex solution. You can get away with less detail in requirements if you're dealing with a simple or moderate addition to an existing system, a colocated team that has been working together for a while, and a small or simple solution.
What about verbal versus written requirements? Verbal communications with a whiteboard session are typically the fastest way to convey a requirement. According to James Shore, consultant and co-author of The Art of Agile Development, "In the agile world, we believe documents are one of the least effective ways of communicating -- you don't see nuances, tone, facial expressions." So communicating better around requirements requires cross-functional teams that meet together, Shore said. "Agile recognizes that the creation of software is a team activity, and that alone helps bridge the communications gap."
But the verbal-only approach doesn't ensure that all stakeholders are in the loop. It is all too easy for people to have different recollections of details discussed two weeks ago let alone two months ago. This can lead to misunderstanding of requirements during development, testing, writing product user guides and training material. So you may have saved time initially, but wasted more time in the long run. Capturing meeting minutes or taking photos of whiteboards is a starting point for communicating all stakeholders' issues. And whatever techniques you decide to use to document requirements, keeping these requirements details in a central repository and linking them to each other in an organized manner is critical to the collective success of your agile team.
Watch the below video for SearchSOA.com editor in chief Jack Vaughan's insights on the difficulty of requirements gathering as well as the goals and evolution of agile development and how agile and SOA interact.
With the agile development movement has come an upsurge in the use of user stories to gather requirements -- user stories being seen as a more agile way to elicit user needs. But the user story, cited as a requirements gathering technique by 26% of our 2008 agile survey respondents, remains just one of many requirements techniques. Other agile requirements gathering techniques include user requirements models, focus groups and the ubiquitous spreadsheet.
How do user stories stack up against use cases? The use case may be thought of as preceding the user story in the annals of requirements jargon. Use cases have been described as a series of events told from the point of view of a system user. Use cases were part and parcel of UML, used as a notation to achieve better development outcomes. The use case was also associated with RUP, which many developers judged to be too complex. RUP and other processes led in turn to counter trends Extreme Programming (XP) and its slightly more subdued sibling, agile development.
Meanwhile, user stories have been described as system requirements formed in just a few sentences that use the language of the user. The user story's drive for brevity plays to the widespread desire to streamline the requirements task. As part of traditional processes, requirements gathering often seemed to result in voluminous documents that did not lead to successful final systems. And those requirements were not visible to the whole team during the life of the entire project.
Clearly, use case techniques may be influenced by the user story, and vice versa. Use cases in agile-style development can succeed, said David West, managing director at Ivar Jacobson Consulting, if teams focus on specifying only things that will actually get implemented, and if these things are specified at the appropriate level of detail.
 |
|
 |
|
| Betty Luedke | |
|
|
What about Scrum and requirements gathering? One user interested in agile and Scrum wrote to us with the following complaint: "Requirements gathering has been a sticky point for us, with some people feeling that … we have some communication issues with requirements (groups not talking with/understanding each other and so forth)." According to requirements expert Betty Luedke, lingering "communication issues" and "sticky points" are usually symptoms of a project environment that is not fully functioning with the commitment, focus, openness, respect and courage that Scrum require. Taking the leap to Scrum means that everyone on the team will need to have (at a minimum):
- An understanding of basic principles and practices.
- A commitment to working differently.
- Roles assigned and accepted.
- Financial and moral support for learning and transitioning to a new approach (training, coaching).
Testing in an agile environment
Increasingly people are talking and asking questions about testing on agile projects -- what does it take to be a successful tester in agile? To answer this question, we need to know how agile projects are different from "traditional" software projects. They're faster (short iterations, working software sooner, and a sense of urgency in the entire team from the first day), but they still have many of the same problems as some traditional project lifecycles: bad requirements, communications issues, lack of documentation.
For testers, the biggest challenge of being on an agile project team is that the software is always changing. With new code being pushed into the test environment daily or even hourly, the system you're testing becomes a moving target. Dealing with that kind of change can require different approaches to testing, with different skills, tactics and tools. There are certain aspects of testing software that don't change just because the project team is using an agile approach to implement software, particularly in the mechanics of test execution, but some testers may need to make significant changes to their testing approach if they are going to add value on an agile software project. Agile testers will need to become versed in techniques like chartering (making decisions about what work you will do next, how you will do it, and how you will make it meaningful to your client) and touring (exercising the application in different ways to improve your understanding about how things work and where risk might be).
Your test development can be agile, too. According to Hans Buwalda, CTO at LogiGear Corp., testing in an agile environment is different than agile test development. With agile test development, similar to agile system development, face-to-face communication and frequent communication among team members is important, as is breaking down testing into smaller chunks with more frequent iterations, he said. With agile test development, tests are developed in small units, independent from the system and each other. Test development needs to be sensitive to the overall planning, and it needs to be flexible. In addition, it requires management buy-in to allow testers to be creative. Buwalda claims that tests are a natural means of communication with users and stakeholders to capture agreement and meaning on the specs, as well as the business and functional requirements.
Where does quality assurance fit in agile development and how are QA goals reached? According to David Christiansen, agile software development projects typically don't use a formal "quality assurance" process. That's not to say that agile projects produce inferior products, although QA proponents in your organization will probably use that argument to resist agile project management techniques. Instead, agile methodologies such as Scrum and XP rely on less formal approaches for ensuring that the application does what it is supposed to do and doesn't have bugs. These include letting users see the application as early and often as possible; using automated tests; and employing motivated generalists (i.e., developers who are competent not just at coding, but also at analysis, testing, communication, etc.) rather than specialists to eliminate "hand-offs" in the development process. The net effect of these agile approaches is a high-quality application.
|
|
 |
|
| Michael Kelly | |
|
|
There are also clear benefits to using exploratory testing in agile environments. According to Michael Kelly, testing expert and director of application development for Interactions Inc., the real-time nature of exploratory testing can help software testers deal with the constant changes on an agile project, as well as the time pressures of agile projects. Exploratory testers need to work to make the testing relevant and coherent to their project team. That means they need to understand which risks are important to the team. They need to understand where they should focus test coverage and work with the team to make daily decisions about what they will work on and how they will structure that work.
Exploratory testers are also skilled at controlling how they interact with the world. They know that collaboration can be more productive than working in isolation. They are good at obtaining the tools and information needed to support their testing efforts. Above all, they are continually focused on improving their ability to interact with the software they test: understanding its business purpose, the technology and how it's configured, and establishing procedures for better control of experimental conditions. They collect different kinds of data and look at different aspects of the software than the programming staff might.
More agile development issues and considerations
There are a few more things you'll need to consider when you fully embrace agile software development. For example, what is the role of architecture in agile development? Coming up with an agile architecture is not about making fixed predictions of the future, said independent consultant and trainer Kevlin Henney; a lot of considerations that make working in the here and now easier also have long-term benefits. Much of what makes an architecture agile is the ability to isolate dependencies and change, following the time-honored (but often breached) qualities of low coupling and high cohesion. Code that is sufficient rather than speculative, that communicates clearly, and that has low technical debt contributes to the habitability and ease of working within an architecture. An integral part of what makes an architecture agile is the process surrounding it.
What about cloud computing and agile? For information on how the emerging wave of cloud computing will affect agile development practices and testing, listen to this podcast interview with Craig Balding, a security practitioner at a Fortune 500 company and operator of the Cloud Security blog.
Also check out this book excerpt from The Software Project Manager's Bridge to Agility on the agile approach to scope creep, which is quite different from waterfall scope management.