stand alone. The set of Updates for the Feature implement the feature. In our own shop at Neuma, we often use multiple Updates across a release development stream to implement a feature. It's important that your CM tool clearly distinguishes between the Update (Change Package) and the Feature (Activity/Task), and that it permits a series of changes for implementation of a feature.
3. Peer Reviews and Unit Testing
Even if you're using a buddy system, in fact, especially if you're using a buddy system, you've got to make peer reviews easy to do. Not one time per Update, but frequently during an Update as well. Good delta reports are the best way to keep on top of what is being done, and to review and re-review an Update. But if somebody's changing a dozen files, it can't be 12 times as much work to do the peer review. It's got to be easy to do. There are two parts: what you review, and your comments. Your CM tool should allow you to look at the entire set of changes in an Update with a single click or two. It should allow you to add context to the differences. It should use color to highlight the changes. And it should give you a choice of format, or even the choice of difference engines. It should also let you record comments, at least for formal reviews.
I don't mind reviewing someone's code if they simply give me an Update id, and from there I can do a one-click operation to see the changes, the activity description and even the test cases that have been tried. If I have to look at files individually, and then call up the activity description, and then look around somewhere for the unit test cases that the developer performed - well, it's not really too much, but it's certainly enough for me to put off doing it until I really have to. CM tools must make this whole process easy, and fast.
4. Automatic Update Generation
A developer makes the changes in his/her workspace, without doing any check-out operations. The changes work. Now what. Put it into the CM tool, says the team - but I've done my part of the work, says the developer. Whether or not you agree that changes can be done without first checking out files and tracking the Update to the reasons for the change, it's a fact of life that some people on your project are going to work that way.
An Agile CM tool could help if it could simply say: Press this button and I'll create the update for you - you can press a button to review it, and press another to check it in. Some CM tools allow precisely that - they will build an Update for you based on the differences between your repository context and your workspace. I recently talked with someone who had multiple typos trying to convert the workspace changes into a real Update that would be successfully checked in. With all of the long names, etc., it was taking hours with multiple tries. I recommended (s)he use a feature that would automatically create the Update, ready for review and checkin. It took a few minutes - and that person was happy. Agile CM removes all such overhead.
5. Minimize Branching
Some Agile teams mandate no branching. OK, I can live with that for a while. Why? Because branching typically implies merging and labelling. Merging implies identifying responsibility for the merge, and for the retesting that has to be done. Labelling means those
About the author
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
