1. What are the key characteristics of agile testing methodology?
When adopting agile methods for testing, we ensure that the tests are done over every simple and small unit of code that is being developed. This type of testing has lot of advantages in the management and technical aspects of the project. With greater control over the progress that is being made in the development and a demonstratable code at hand every time, the agile methods of testing can prove very useful. The requirements if complex, can be easily matched up at every stage of development by having agile methods of testing over units of code. This will avoid the possibilities of facing requirement conformance mismatches.
2. What are the changes that a development team has to accept if agile testing is on the cards?
The adaptive nature of the development teams play a major role if we have to successfully implement a agile method of testing for the project.
The agile methods of testing can be a very good way of developing a project which has to have a periodic deliverable and which has a very few members in the team with fixed resources. In such scenarios, the Agile methods can help to get the maximum efficiency and stability in the products under development. In such cases the requirements are not so varied and remain quite constant.
On the other hand, if we consider a very large organization which is developing a software or any other product which has lot of modules and lot of functional requirements (business logics) then agile methods may just prove to be a hurdle in the development of different modules. So it is not a good idea to adopt agile testing methods in large projects with a wider scope of operations.
4. How can agile methods help in marketing and business aspects of a product?
The agile methods help in churning out workable code at every stage of development. So marketing of a product can be really effective as the updates to the software/product can come in handy in promotions. The Inspect and adapt approach that agile implements can help the product developers to change/add new functionalities over the previously developed layers. This adaptive approach again can help in keeping the product up-to-date in the market.
5. How can it be advantageous to the developers?
Technically the agile methods implement a iterative and incremental development phase in the project. This means the developers have higher control over the design/code that is under development. This can be helpful in maintaining a confident mindset among the team members. Also the smaller units of development can bring in the much needed modularity in the product, making it more reusable than the traditional methods can offer.
5Qs on Agile with Steve McConnell
Readers of Software Development magazine once named Steve McConnell one of the three most influential people in the software industry. The CEO and Chief Software Engineer at Construx Software, Steve has generously agreed to kick off our "5Qs on Agile" feature by answering the following five often-asked questions about Agile development.
Q1: Why use Agile methods?
Agile methods focus on shorter iterations, in which the software is brought to a releasable level of quality fairly often, usually somewhere between weekly and monthly. Short iterations provide numerous technical and management benefits. On the technical side, the main benefit is reduced integration risk because the amount of software being integrated is kept small. Short iterations also help to keep quality under control by driving to a releasable state frequently, which prevents a project from accumulating a large backlog of defect correction work. On the management side, the frequent iterations provide frequent evidence of progress, which tends to lead to good status visibility, good customer relations, and good team morale.
Agile methods also usually treat requirements as more dynamic than traditional methods do. For some environments that's a plus and for some it's a minus. If you're working in an environment that doesn't need a lot of long range predictability in its feature set, treating requirements dynamically can save a lot of detailed requirements specification work and avoid the "requirements spoilage" that often goes along with working through a lengthy backlog of detailed requirements.
Q2: What is the biggest challenge when implementing Agile methods? The biggest challenge we see in our consulting and training business is walking the walk. You can't just say you're doing Agile. You have to follow through with specific actions. Of course that's the same problem we saw years ago with object oriented methods, and before that with structured methods, so that problem isn't unique to Agile.
The most common specific challenges we see are simply the challenges of "turning the battleship" in a large organization to overcome the inertia of entrenched work practices and expectations and getting reoriented to do things in a different way. You have to muster the resolve to actually work in short iterations. You have to build frequently, at least every day, and you have to develop the discipline to keep the build healthy. You have to push each iteration to a releasable level of quality even if that's hard to do at first. As before, this problem isn't unique to Agile. If we're working with an organization and find that their biggest need is to do a better job of defining requirements up front (which isn't very agile), "turning the battleship" to define better requirements up front will be just as hard.
Q3: In what environments will Agile be most successful? Full-blown Agile seems to me to be best suited for environments in which the budget is fixed on an annual basis, team sizes are fixed on an annual basis (because of the budget), and the project staff's mission is to deliver the most valuable business functionality that they can deliver in a year's time with a fixed team size. This mostly describes in-house, business systems dev organizations.
Full-blown agile (especially the flexible requirements part) is less-well suited to companies that sell software, because maintaining a lot of requirements flexibility runs counter to the goal of providing mid-term and long-term predictability. We've found that many organizations value predictability more than they value requirements flexibility. That is, they value the ability to make commitments to key customers or to the marketplace more than they value the ability to "respond to change."
For anything less than full-blown Agile, however, we find that many agile practices are well-suited to the vast majority of environments. Short development iterations are nearly always valuable, regardless of whether you define 5% of your requirements up front or 95% up front. Keeping the software close to a releasable level of quality at all times is virtually always valuable. Scrum as a management style and discipline seems to be very broadly applicable. Small, empowered teams are nearly always useful. I go into more detail on the detailed strengths and weaknesses of specific agile development practices in my executive presentation on The Legacy of Agile Development.
Q4: What is the future of Agile? Agile has largely become a synonym for "modern software practices that work," so I think the future of Agile with a capital "A" is the same as the past of Object Oriented or Structured. We rarely talk about Object Oriented programming anymore; it's just programming. Similarly, I think Agile has worked its way into the mainstream such that within the next few years we won't talk about Agile much anymore; we'll just talk about programming, and it will be assumed that everyone means Agile whenever that's appropriate.
Q5: Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now? I'm most excited about the Software Development Best Practices discussion forum that we launched a few weeks ago. That's at http://forums.construx.com/ . I also started blogging recently, and you can read my blog at http://blogs.construx.com/blogs/stevemcc/default.aspx . Feel free to contact me by e-mail at stevemcc@construx.com.
When adopting agile methods for testing, we ensure that the tests are done over every simple and small unit of code that is being developed. This type of testing has lot of advantages in the management and technical aspects of the project. With greater control over the progress that is being made in the development and a demonstratable code at hand every time, the agile methods of testing can prove very useful. The requirements if complex, can be easily matched up at every stage of development by having agile methods of testing over units of code. This will avoid the possibilities of facing requirement conformance mismatches.
2. What are the changes that a development team has to accept if agile testing is on the cards?
The adaptive nature of the development teams play a major role if we have to successfully implement a agile method of testing for the project.
- Every small change that is being made has to be done in a completely testable form. This means the development of even a very large concept has to be broken up accordingly to facilitate periodic testing.
- The short iterations of test cycles also would mean that the development team has to come up with frequent builds and versions.
- When a project is already being tested with other long term methods of testing, a sudden change can be very difficult to be brought in.
- Unit testing will in turn be a major test of integration for each developer and one has to cautiously integrate the smaller pieces of the unit that have already been tested.
The agile methods of testing can be a very good way of developing a project which has to have a periodic deliverable and which has a very few members in the team with fixed resources. In such scenarios, the Agile methods can help to get the maximum efficiency and stability in the products under development. In such cases the requirements are not so varied and remain quite constant.
On the other hand, if we consider a very large organization which is developing a software or any other product which has lot of modules and lot of functional requirements (business logics) then agile methods may just prove to be a hurdle in the development of different modules. So it is not a good idea to adopt agile testing methods in large projects with a wider scope of operations.
4. How can agile methods help in marketing and business aspects of a product?
The agile methods help in churning out workable code at every stage of development. So marketing of a product can be really effective as the updates to the software/product can come in handy in promotions. The Inspect and adapt approach that agile implements can help the product developers to change/add new functionalities over the previously developed layers. This adaptive approach again can help in keeping the product up-to-date in the market.
5. How can it be advantageous to the developers?
Technically the agile methods implement a iterative and incremental development phase in the project. This means the developers have higher control over the design/code that is under development. This can be helpful in maintaining a confident mindset among the team members. Also the smaller units of development can bring in the much needed modularity in the product, making it more reusable than the traditional methods can offer.
5Qs on Agile with Steve McConnell
Readers of Software Development magazine once named Steve McConnell one of the three most influential people in the software industry. The CEO and Chief Software Engineer at Construx Software, Steve has generously agreed to kick off our "5Qs on Agile" feature by answering the following five often-asked questions about Agile development.
Q1: Why use Agile methods?
Agile methods focus on shorter iterations, in which the software is brought to a releasable level of quality fairly often, usually somewhere between weekly and monthly. Short iterations provide numerous technical and management benefits. On the technical side, the main benefit is reduced integration risk because the amount of software being integrated is kept small. Short iterations also help to keep quality under control by driving to a releasable state frequently, which prevents a project from accumulating a large backlog of defect correction work. On the management side, the frequent iterations provide frequent evidence of progress, which tends to lead to good status visibility, good customer relations, and good team morale.
Agile methods also usually treat requirements as more dynamic than traditional methods do. For some environments that's a plus and for some it's a minus. If you're working in an environment that doesn't need a lot of long range predictability in its feature set, treating requirements dynamically can save a lot of detailed requirements specification work and avoid the "requirements spoilage" that often goes along with working through a lengthy backlog of detailed requirements.
Q2: What is the biggest challenge when implementing Agile methods? The biggest challenge we see in our consulting and training business is walking the walk. You can't just say you're doing Agile. You have to follow through with specific actions. Of course that's the same problem we saw years ago with object oriented methods, and before that with structured methods, so that problem isn't unique to Agile.
The most common specific challenges we see are simply the challenges of "turning the battleship" in a large organization to overcome the inertia of entrenched work practices and expectations and getting reoriented to do things in a different way. You have to muster the resolve to actually work in short iterations. You have to build frequently, at least every day, and you have to develop the discipline to keep the build healthy. You have to push each iteration to a releasable level of quality even if that's hard to do at first. As before, this problem isn't unique to Agile. If we're working with an organization and find that their biggest need is to do a better job of defining requirements up front (which isn't very agile), "turning the battleship" to define better requirements up front will be just as hard.
Q3: In what environments will Agile be most successful? Full-blown Agile seems to me to be best suited for environments in which the budget is fixed on an annual basis, team sizes are fixed on an annual basis (because of the budget), and the project staff's mission is to deliver the most valuable business functionality that they can deliver in a year's time with a fixed team size. This mostly describes in-house, business systems dev organizations.
Full-blown agile (especially the flexible requirements part) is less-well suited to companies that sell software, because maintaining a lot of requirements flexibility runs counter to the goal of providing mid-term and long-term predictability. We've found that many organizations value predictability more than they value requirements flexibility. That is, they value the ability to make commitments to key customers or to the marketplace more than they value the ability to "respond to change."
For anything less than full-blown Agile, however, we find that many agile practices are well-suited to the vast majority of environments. Short development iterations are nearly always valuable, regardless of whether you define 5% of your requirements up front or 95% up front. Keeping the software close to a releasable level of quality at all times is virtually always valuable. Scrum as a management style and discipline seems to be very broadly applicable. Small, empowered teams are nearly always useful. I go into more detail on the detailed strengths and weaknesses of specific agile development practices in my executive presentation on The Legacy of Agile Development.
Q4: What is the future of Agile? Agile has largely become a synonym for "modern software practices that work," so I think the future of Agile with a capital "A" is the same as the past of Object Oriented or Structured. We rarely talk about Object Oriented programming anymore; it's just programming. Similarly, I think Agile has worked its way into the mainstream such that within the next few years we won't talk about Agile much anymore; we'll just talk about programming, and it will be assumed that everyone means Agile whenever that's appropriate.
Q5: Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now? I'm most excited about the Software Development Best Practices discussion forum that we launched a few weeks ago. That's at http://forums.construx.com/ . I also started blogging recently, and you can read my blog at http://blogs.construx.com/blogs/stevemcc/default.aspx . Feel free to contact me by e-mail at stevemcc@construx.com.
No comments:
Post a Comment