Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Floyd Marinescu on May 03, 2007
In this video presentation, Scott Ambler talks to a testing & QA user group (TASSQ in Toronto, Jan 2006) explaining to them how agile software methodologies work and how testing works in an Agile context. Talking to a group that usually does testing as a full time profession, disconnected from the development team, Scott explains how agile developers unit test before writing code, how they treat accpetance tests as full-fledged requirements artifacts and work with stakeholders to acceptance test throughout the development lifecycle. Scott argues that agile methodologies have resulted in significantly higher quality than what traditionalists produce, and that we've achieved this with very little input from the testing community (whom he was addressing). Scott basically concludes that there will be little long term employment opportunities for full time QA or testing people, much to the horror of the audience he was addressing.you'll need to be flexible, work with others, pick up other skills. You're not going to be testing or QAing or whatever constantly. Just like a data person is not going to be doing data modeling constantly, there gonna be doing a little bit of data stuff, coding stuff, requirements stuff, some testing stuff, go back and do some data stuff and so on.I was in attendance at the talk (camera guy) and blogged about it which kicked off a large discussion on TSS. Scott Ambler commented on my blog entry:
You've got to be willing to go back to the diff aspects of software. This is called a generalizing specialist, somebody with one or more specialties, so if you if you wanna be a testing specialist that's great but you've gotta have other skills as well. You've gotta be able to roll up your sleeves and do some progamming, do some coaching, do some modeling, do some deployment, do some build, you've gotta have thse basic skills, plus an understanding of the domain you're working in, and be willing to pick up more skills over time... If you wanna be a specialist that that gets something handed to them, you do your thing and then hand it off to someone else, you can find employment doing that but it will be in these traditional more than likely going towards CMM or CMMI organiations which is great but you're being targetted for being outsourced, because if I can hand off something to you, I can just as easily hand off something to India.
Some of the traditional folks in the audience, and there was clearly some "modern thinking" QA folks in the audience too, didn't like parts of my message. That's a good thing, to paraphrase Martha Stewart, because the should feel threatened by the changes coming there way. Some people in the agile community believe that we don't need traditional QA people at all, although a better way to say that might be that we need flexible QA people who are generalizing specialists instead of the overly specialized traditional QA folks that some organizations still have. Quality is clearly job one within the agile community, it's just that we achieve it using significantly different techniques than traditional QA prefer. QA people are more than welcome on agile projects, the bring significant skills to the table, they just need to be flexible enough to do more than just QA stuff.
Agile Development: A Manager's Roadmap for Success
Right Collaboration Architecture Drives Business Transformation
Design in Agile, Software Craftsmanship, Product Development, Testing @ QCon London in March
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
i can rename column just like that, you just have to rename it in hibernate mapping xml file. people forget that we all are using ORM.
and found the reaction in the audience to be pretty amusing. Heck, it was even brought up at later meetings. Way to make a lasting impression, Scott!
As a person who's been involved in agile projects for several years now, Scott's comments were right on. A friend of mine (who's also been involved in agile projects for years) and I would often have conversations about exactly this topic. Often the discussion would turn to our disappointment at the contributions of the testers to the project. Occasionally, we would work with a tester who "got it" and things would be wonderful, but this was the exception rather than the rule.
Personally, I think "we" (developers) bear part of the blame here. We've treated testers and testing as an afterthought, as second class citizens for so long that perhaps they shouldn't be blamed for sticking to their comfort zones. After all, in a lot of corporate or non-agile shops, being an aggressive, dynamic, flexible tester isn't always a career enhancing thing.
I'm beginning to believe that the only difference between a tester and a developer in an agile team is their mind-set. Developers always tend to be optimists, even on agile teams. Testers are our pessimists. Beyond that, in terms of skills, they really should be identical.
I wonder when IBM will decide if traceability is a good thing to track and measure or not.
Rational RequisitePro
www.ibm.com/software/awdtools/reqpro/
"Provides detailed traceability views that display parent/child relationships and show requirements that may be affected by upstream or downstream change"
Yet, Mr. Ambler of the IBM Methods groups gives thumbs down to traceability.
--
It was really confusing, and mischievously fun, to debate with "IBM Rational tools" believers against Scott's AgileModeling.com concepts. I guess IBM isn't in the business of selling paper and pens and whiteboards and markers.
I hope Ambler wins, with AUP...
www.ambysoft.com/unifiedprocess/agileUP.html
Go,go,go! :)
Raj.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
3 comments
Watch Thread Reply