Just spotted an excellent article about Rational Team Concert (RTC) and Rational Requirements Composer (RRC), which actually fills a gap to my knowledge.
Article is on devworks, a favorite place to look for interesting stuff. It touches a few points, go have a read.
From some time I've been using RTC quite extensively, handling the process / workitems definition, together with its source control system. The point is that the more I know, the more I do understand that a tool isn't enough.
I also came to understand that while tooling isn't enough, adoption is what counts in the evolution of the project.
As the PM or Architect, you can define for the project:
- template for deliverables
- process and roles in project area
- source control process for streams/components
- development conventions
- architectural decisions
- (...) add here countless items from any imaginable methodology
If your team does not adopt above items (which btw, should be tailored to suit the project needs), you're doomed to fail.
What a great PM/Architect does (I haven't seen many ... ), is convince the team that their additional work (like filling fields in workitems, write according to templates) is needed because .... (give the reasoning). And if you manage to convince that stubborn smart team member so that he freely complies and adopt your things, you're on the right track.
Development in small team of friends is one thing. Development in international teams of people only familiar to eachother over the phone, is another.
No comments:
Post a Comment