This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: The Roles of Role based development
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
To extend the previous post, in the software process direction you can download the MSF (Microsoft Solutions Framework) for Agile Software Development here.
There is also a blog from Randy Miller [MSFT] on the subject.
I have included the role definitions that are defined within it at the bottom of this post.
Within a small development team or department, we find that the roles of [Architect/Developer/Tester] and [Project Manager/Business Analyst/Release Manager] are more likely to be merged and/or mixed.
In effect only two main roles are probably prevalent, developers and co-ordinators, Co-ordination is usually done by a single person who communicates with the client, but who may also have a hand in testing or development.
It can never truly be clear cut in a small environment.
In a medium sized company experience, there may be more cross-over than what one wants with confusing entangled decisions.
A larger role-based environment may require a further break-down with developers having specialities.
One can see the ideal for the distinct roles, but this is far from reality for the smaller business.
At the end, the responsibility has to lie somewhere and that responsibility good or bad, has to be clear-cut.
I personally dont feel that pushing roles within a software package like Visual Studio is going to help the business processes of companies.
Should a scenario ever exist where a developer could not perform a function within the life-cycle just because they had a different role-based development environment, would create a silly scenario.
Thats perhaps not the case, but with setting this trend, even in name, creates unwanted complexity.
All roles should see and be aware of designs, architecture, tests, progress, releases, and everything that goes on within the development.
The big picture is key and I hope that (although roles are needed) we will not be pigeon-holed.
Architect
The architect's main goal is to ensure success of the project by
designing the foundations of the application. This includes defining both the
organizational structure of the application and the physical structure of its
deployment. In these endeavors, the architect's goal is to reduce complexity by
dividing the system into clean and simple partitions. The resulting architecture
is extremely important since it not only dictates how the system will be built
going forward but also establishes whether the application will exhibit the many
traits that are essential for a successful project. These include its usability,
whether it is reliable and maintainable, whether it meets performance and
security standards and whether it can be evolved easily in the face of changing
requirements.
Business Analyst
The Business Analyst's main goal is to define the business
opportunity and the application that will serve it. The business analyst works
with the customers and other stakeholders to understand their needs and goals
and translate those into persona definitions, a , scenarios, and quality of
service requirements that the development team will use to build the
application. The business analyst provides subject matter expertise to the
team.
Project Manager
The project manager's main goal is to the delivery of business value
within the agreed schedule and budget. The project manager is charged with
planning and scheduling duties including developing project and iteration plans,
monitoring and reporting status, and identifying and mitigating risk. The
project manager is also expected to consult with business analysts to plan
scenarios and quality of service requirements for an iteration, consult with
architects and developers to estimate work, consult with testers to plan
testing, and facilitate communication within the team.
Tester
The tester's main goal is to discover and communicate problems with
the product that could adversely impact its value. The tester must understand
the context for the project and help others to make informed decisions based on
this context. A key goal for the tester is to find and report the significant
bugs in the product by testing the product. Once a bug is found, it is also the
tester's job to accurately communicate its impact and describe any work-around
solutions that could lessen its impact. The tester makes bug descriptions and
steps to recreate bugs easy to understand and follow. The tester participates
with the entire team in setting the quality standards for the product. The
purpose of testing to prove known functions and discover new product issues.
Developer
The developer's main goal is to implement the application as
specified within the planned time. The developer is also expected to help
specify the features of physical design, estimate time and effort to complete
each feature, build or supervise implementation of features, prepare product for
deployment, and provide technology subject matter expertise to the team.
Release Manager
The release manager is the role that is responsible for managing the
rollout of the product. The release manager coordinates the release with
operations or media control. They create a rollout plan and certify release
candidates for shipment or deployment.
Previous Topic
