The biggest challenge to effective agile development in a distributed environment lies in maintaining the same level of communication and the same level of access to your Subversion repositories that’s possible when everyone works from one location. The implementation architecture and the tools you choose to support distributed development can either help or hurt.
I’m a agile software developer who uses SCM to help teams be more effective, and more agile I've worked with distributed teams since I started my career, and almost every project I have worked on has involved collaborating with a development team in another city, or even another timezone. My first development project involved teams in two different cities collaborating on a product, and it was the SCM and build practices that helped enable us to work effectively and to overcome the communications barriers that distance can cause. Because we thought about how we could use our SCM and build practices as a way to communicate, the teams worked together very well, in spite of the distance, the poor network connections, and in spite of the lack of good web-tools. It was working on that team as an engineer where I started thinking about the impact that collaboration and SCM can have on project success, and where I started thinking about what later became SCM patterns. 02/17/10
The Agile Manifesto is are principles that guided the development of Agile Methods. Here is how they relate to SCM Individuals and Interactions over Processes and Tools SCM Tools should support the way that you work, not the other way around Working Software over Comprehensive Documentation SCM can automate development policies & processes: Executable Knowledge over Documented Knowledge Customer Collaboration over Contract Negotiation SCM should facilitate communication among stakeholders and help manage expectations Responding to Change over Following a Plan SCM is about facilitating change, not preventing it WHILE GOOD SCM IS ESSENTIAL Bad SCM can make it difficult to be agile. Tools are complicated, code is complicated and teams are complicated. Agile Methods emphasize: Feedback Communication Process that adds value Agile SCM Simple and effective SCM Enables development Not only for agile teams Balance Feedback and Stability 02/17/10
So, what’s agile? If you pick up a book on agile, you’ll hear about principles and practices. You’ve probably heard this story before: “ you talk to someone who’s claiming to be agile, and you ask: do you do unit testing? NO, do you do pair programming? NO. Continuous integration? NO. Frequent releases? NO. How can you claim that you are doing agile? WE DON’T DO SPECS or DOCUMENTATION,” So, practices are important… but each team might apply practices slightly differently, so what are the key aspects of agile? Incremental: Small (or at least discrete) steps. Iterative: Adjust and adapt Self Organizing Teams: Agile teams decide how to get the work done and learn from it. Rather than assuming a lot of control (which can slow things down), you’re setting some guidelines and metrics – based on results that the customer cares about, but letting the team work out the details. Because the team is responsible for how they work, they can COMMIT. Self imposed commitment works well. Feedback and Adapt: At the end of each iteration team looks at how well they did against the goal. Some of the issues can involve Requirements, development process, infrastructure… The metric for an agile team is “did they deliver what the customer wants at the end of an iteration?” NOTE: Agile requires lots of discipline. The steps may be fewer, but they must be done well Let’s look at one process briefly: Scrum Agile software development works well in environments where requirement change, where there is uncertainty) SCM processes can support or hinder both incremental and interative approaches. (Talk thorugh scrum diagram. There is testing and CI throughout) 02/17/10
START SCM -- Intro to SCM Concepts Module I was speaking to some people at a conference last year about SCM and agile teams. When I reviewed the feedback (in person and forms) I had a couple of reactions: They found the talk useful and they were disappointed that there wasn’t more on branching. The other thing people ask about is Tools. SCM is more than just branching. SCM might not even involve branching at all. SCM is about more than tools. So, we’ll talk about what SCM is, why you (as testers and QA managers) should care, what challenges there are, And also how agile teams might take a different approach to SCM. Agile teams use all of the same tools and concepts, but in a different way. 02/17/10
SCM is NOT just branching (Maybe do some effects to reveal each bullet in turn?) Identification: an identification scheme is needed to reflect the structure of the product. This involves identifying the structure and kinds of components, making them unique and accessible in some form by giving each component a name, a version identification, and a configuration identification. For example, this addresses the question, "What version of the file is this?" Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product. For example, this addresses the question, "How many changes went into the latest version of this product?" Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product. For example, this addresses the question, "How many files were affected by fixing this one bug?" Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that components are in an appropriate state throughout the entire project life cycle and that the product is a well-defined collection of components. For example, this addresses the question, "Are all the correct versions of files used in this current release?" The difference is the focus on what you want to do, versus what you are doing. SCM is about putting things together and change management. Version Management is basic, but you also need build management, testing, etc. Branching and Merging are means to an end, but there are many ways to build a tool 02/17/10
02/17/10
What this means for agile teams: SCM processes enable you to coordinate, among your team mates, among various sites, between you and your customers. Version Management is a subset of SCM. The most visible one. Build management: Not a typical SCM function, but without the build you don’t know where you are.
MODULE START: SCM IN CONTEXT Different SCM for Different teams. Different approaches to solve the problem. For example, a startup team in one room with a shared vision needs less SCM coordination than a team spread across different time zones. A team with one customer, or a software as service provider who controls when updates happen will need less branching than a team with many. The mode modular your architecture, the less variation you need to manage with codelines. Here’s a quick example of modularity using spring 02/17/10
Another part of your context is tools. Story: Often people ask me “What SCM Tool should I use.” I can’t give a good answer to that without an understanding of your work style and constraints. Some tools do some things better than others, but you can have an effective process with almost any tool. Here are some things to consider when looking at tools: Start with an understanding of what workflow makes sense for your team. You can be effective with any tool. Don’t put off version control tooling because you can’t get the right too (Skyva Story about not getting Clear Case but being frustrated with current tools.) Qualities: Fast. You want people too commit regularly and not break flow. Transparent: IDE integration Traceability: Integration with issue tracking systems. END CONTEXT ---- End CONTEXT module Photo: Bell Aircraft Corporation, Niagara Falls, New York. Employees must buy their own tools. Many women are learning the use of tools for the first time. Collins, Marjory, 1912-1985, photographer. 02/17/10
02/17/10
This slide provides a sampling of the customers who’ve implemented this technology to take advantage of the kinds of benefits and costs savings that it can offer. In fact you can download a Forrester Research report from WANdisco’s website that revealed that customers can expect on average to achieve a 167% return on investment with a 9 month payback period after implementing Subversion MulitSite.