Soa Projects Introduction Agile Testing

My name is Greg Hodgkinson and I work for Prolifics, where one of my roles has been to provide leadership in software development process. It has to be said that I started with a love–hate relationship with agile methods born out of many years’ experience of seeing them both being successfully used, but also(sometimes)abused;let me explain:

  • I love some of the techniques that agile methods champion as I truly believe that they have, in their own way, had a revolutionary impact on the way the industry approaches software engineering.
  • At the same time though, I hate seeing them being abused to excuse bad practices, or even worse as a political tool to bash other valuable practices.

So, taking a step back, it’s not the methods themselves I have a problem with–far from it– ut rather the blind faith from those who have jumped on the agile bandwagon without proper consideration for what they are trying to achieve.

And who hasn’t jumped on a bandwagon at some stage or other? In fact I’d suggest that one of the best things about the emergence of agile methods is that it has stirred up passions for the use of software development processes as a way of improving the lot of the IT professional–fantastic!

But blindly applying agile methods without really trying to understand what problems you’re trying to solve with them, and also which problems you’re not relying on them for solution, can cause unnecessary problems. I’d like to start by observing three reasons why adopting methodologies sometimes goes wrong:

  • Good method, wrong type of project – Some methods just do not suit certain styles of projects–period. Good luck trying to use XP(Extreme Programming “out of the box” to deliver a “system of systems”[90] style of project covering hardware and software, involving multiple large teams who are distributed around the world. No use blaming Kent Beck if it goes wrong–XP itself describes the class of projects for which it is intended.
  • Good method, overrelied on –Make sure you understand the limits of the method that you are using. Scrum is not going to tell you the form that your architecture needs to take. But then, it doesn’t profess to provide method support for architecture. If you need architectural guidance then you shouldn’t be relying on Scrum to provide it. Some people fall into the trap of overrelying on a method to cover all their method needs. You need to have a clear idea as to what you want out of a method, and then choose the best bits from those methods that meet your needs.
  • Good method, misunderstood –To illustrate, a fictitious but yet not unrealistic quote from a project manager–“I bought a really good book on Rational Unified Process and I’ve made sure that we are applying all of its roles, work products, and tasks, and yet the team hate it and my projects are not delivering. I thought the three amigos were supposed to be process gurus!” Erm, do you know that RUP is a process framework and not a process? Guess maybe you aren’t applying all of the roles, especially not the process engineer, whose role responsibilities include “tailoring the process to match the specific needs of the project” and “assisting the project manager in planning the project”.

So building on this, for anyone who has spent any amount of time thinking long and hard about software development methodologies, the inevitable and oft-written conclusion is that the best thing to do is to customize your own–consider the types of projects you need to run in your organization and then take the best bits of the various methods out there(as applicable) and combine them to “grow your own!”

Apply care and attention, prune where required, and over time you will end up with a mature method that perfectly fits the needs of your organization. It also helps to start with the right seeds(base methods)and cuttings(customizations). Don’t get me wrong–there is no reason for the average organization to have to build a custom method from scratch. The exercise should be one of assembly rather than of build. If you’re building your own from the ground up then you’re doing it the hard(and expensive!) way.

This case study focuses on methods to support a specific class of project–those that produce SOA solutions. To support these projects requires “special tactics” over and above what is covered by “out-of-the-box” agile methods. This is the raison d’ˆetre for me growing my own method–AgileSOA, which, as the name suggests, combines the best of two classes of methods: agile methods and methods used to produce SOAsolutions.

This case study is based on my experiences in applying this method to a number of significant customer projects over the years at Prolifics and at my previous company, 7irene, where this method was first formed. Any method should be judged by its performance, and we have yet to have a project use this method that has not been a success(although we have learned along the way!). I hope you find some parts of this case study useful to your own efforts to “grow your own” method!


Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Agile Testing Topics