Requires Free Membership to View
You're right. There are always some people who latch onto any new software development approach with the reaction, "Great! This means now I don't have to do <blank> anymore," where "<blank>" represents whatever they don't like to do on a software project, including requirements. Of course, that's not what any of these new approaches mean; see my article "License to Hack" at http://www.stickyminds.com. Agile development methods do definitely address requirements.
The traditional role of the business analyst has been to facilitate communication between customers who have needs and developers who create solutions. The analyst performs multiple services: bridging, translating, interpreting, documenting, modeling, prototyping and even inventing requirements. Think of the analyst function as being a project role, not necessarily a job title. This role can be performed by various people on the project who have the skills, knowledge and temperament for it. A suggested job description for a requirements analyst is available here.
|
Agile development emphasizes a close collaborative partnership between customer (or, more broadly, stakeholder) representatives and the developers. This is a powerful success enabler for any project. The question, then, is who should perform the central roles in this partnership. For more than 20 years I have advocated a model in which one or more analysts work with one or more key user representatives called "product champions." The product champion concept relates to the "on-site customer" concept in agile development.
One problem with this approach is that it introduces additional communication layers between the voice of the customer and the ear of the developer. You can eliminate some of those layers if the developer has the skills and knowledge to perform the analyst functions, instead of having a separate individual serve as the business analyst. However, that means developers will need training, resources and experience to do a good job when they wear their analyst hat. Not every developer will be comfortable or effective performing that role. So be sure to adequately prepare your developers to grow into the analyst function instead of expecting them to do a great job in this difficult role automatically with no training or guidance.
For more thoughts on this topic, see Scott Ambler's article "Rethinking the Role of Business Analysts."
This was first published in September 2007
Join the conversationComment
Share
Comments
Results
Contribute to the conversation