|
Original Broadcast Date : Wednesday, June 8, 2011
Time: 2:30 PM PT / 4:30 PM CT / 5:30 PM ET
Speakers:
Randy DeFauw, Technical Marketing Manager, Perforce
In this presentation, learn how to use Perforce to help implement an Agile workflow in teams across the enterprise. Common challenges that occur when deploying Agile across large teams and projects are discussed in detail, along with solutions based on Perforce’s powerful branching model and new streams feature.
The presentation also includes a discussion of how Perforce’s version control tools improve collaboration and transparency. Perforce puts powerful tools in the developer’s hands in IDEs like Eclipse, and integrates with leading continuous integration, project management, and code review tools to round out the Agile tool set.
-
Build scalable agile processes with Perforce's version management system.
-
Increase productivity integrating Perforce with leading agile workflow tools.
-
Achieve greater transparency using Perforce's fast branching and visualization tools.
About the Presenter:
Randall DeFauw,
Technical Marketing Manager,
Perforce Software
Randall (“Randy”) has over 7 years of experience in software configuration management using a variety of products in addition to Perforce. He has been a certified Perforce Consulting Partner since 2006, a Certified Perforce Trainer since 2007. Randy is presently Perforce’s Technical Marketing Manager. He has extensive experience with Perforce configuration, administration, and integrations. Randy also has a background in SEI/CMMI Level 5 software engineering practices. Learn more about Perforce at www.perforce.com.
Presentation Transcript:
Hi, good afternoon and welcome to our talk today on Scaling Agile for the enterprise. I'd like to welcome those of you attending in person and also those of you attending on the visual show. Before I begin, just a little background on me. My name is Randy DeFauw. I'm currently the technical marketing manager at Perforce Software. I also work part-time in the consulting team. Prior to joining Perforce, my background was in software development. I've seen software development both from a really small scale at a startup, where we really didn't have a lot formal processes or tools and I've seen it all the way up to the other extreme in the defense industry, where I was involved in SEI CMMi level 5 development processes that were very heavy on processes and tools.
And just a little bit of background on Perforce.
Perforce software makes a version control and software configuration management tool.
Perforce was really founded in order to be a fast scalable version control system. It was founded about 15 years ago. The owner of Perforce made Perforce the version control tool because he felt all the existing tools back then were, either, didn't have enough features or were really complex and cumbersome, so he always wanted a tool that would give him what he needed to get the job done quickly without getting in his way.
And so that's one of the reasons why I think Perforce is always fit well into the Agile philosophy. Perforce is available on pretty much every platform out there.
And probably more importantly it can version just about any kind of data.
So not just traditional software assets but also binary files, for instance PIXAR puts all of their movie assets into a Perforce depository. And that's also a key consideration for Agile. So as you are trying to make your whole development process more productive, you want a version control tool that can handle pretty much anything you throw at it.
So my talk today, I'm going to focus really on how to scale up Agile for the Enterprise and how an effective, powerful version control tool can help you do that.
Of course the whole goal with Agile, the key philosophy behind it, favors individuals and interactions over processes and tools, so we're trying to enable people to more rapidly deliver productive software that actually works and gets the job done.
And again, Perforce, because our whole philosophy is about providing a fast, powerful tool that doesn't get in the way, I think really fits in well to those Agile processes. So again, the whole goal of using Agile and how Perforce tries to help you is rapid change to deliver more business value on time.
So the three things I'm going to focus on today are scalability. So, some of the challenges that are faced as you grow Agile processes and teams from, say, a small pilot team up through a large enterprise with complex development processes.
And then I'm also going to focus a little bit on some of the productivity improvements that Perforce as the strong version control provider brings to you and then I'll wrap up by talking a little bit more about transparency and, again, given my background in the defense industry where I've seen transparency break down, I think transparency is another one of those key Agile philosophies and tenets that it's important to consider.
So first let's talk a little bit about scalability. And we'll talk about going from a very simple, maybe small team, working on a simple product to a much more realistic complex example. And the two pictures I have up on the slides are actually a couple of screen shots from Perforce's stream graph and I'll be kind of referring back to these visual tools as I go through the talk because they represent a branching model, a development model, and they make for, some nice examples.
So, many people who are new to Agile, even if they're in a large company, again they'll roll out Agile for a very small team, originally, just to see how it goes. So, a small team may be working on a simple product.
In this small pilot team, the team lead can really manage a lot of the release management, really provide a lot of manual assistance to everybody else on the team. And typically, the small pilot project might be something that doesn't have a lot of complex dependency. So it might be a small, fairly isolated project.
So, some of the collaboration activity that the team lead can manage manually. In the simple examples, things like at the end of the sprint to make sure any bug fixes from older releases have been merged down into the active development code line or stream. And then when the sprint has completely finished, making sure that that work is promoted back up to the main line, handed off to, say, a QA team for integration work and testing.
And again, we might have very minimal dependencies, so either a project that really is standalone or has just a handful of external libraries and components that it needs. And the product manager, the team lead may simply import those dependencies as needed.
But again, as we roll out Agile to bigger teams and more complex development efforts, it's really a challenge to replicate that initial success, that feeling of having more transparency, having faster iterations, having more productive teams. It's really hard to maintain that initial success if you're talking about a team of 500 people scattered across offices in 3 countries.
And you're talking about a very complex software product that has a lot of dependencies and is maintained over several years. So we wanted to bring all the benefits of Agile to those larger teams across the enterprise, and to do that we need to make sure that we're maintaining that rapid flow of change.
So all the challenges that come with rolling out Agile to bigger teams, we need to make sure that we overcome those. The two problems I'll focus on specifically are concurrent development and managing dependencies. So in most realistic software, particularly if you are working in the embedded industry or the gaming industry or any situation where, for a variety of reasons, software development has moved to a much more component based model or a much more modular development model.
We have a much more complex concurrent development scenario. So we may be maintaining several older versions of the product. For instance, if you're a company like Microsoft, you have to maintain every version of Windows for something like 10 to 12 years. As you try to roll out Agile, you may have several active development streams going out at the same time.
So if you have team of fifty, you may split them up into three smaller teams, have them work on three separate feature sets at the same time, so you have different feature branches for different teams or even individual developers. And you also have to have, then, an integration layer, where all of that work comes together before it becomes an official release.
So, as we move to this more realistic, this more complex, concurrent development model, there's some overhead that we incur. And, of course, the benefit to moving to this more complex model is it lets us have the entire team be agile. So different teams can work on different sets of features concurrently .
We're not holding people up waiting for every team to finish at the same time. But, of course, those advantages do incur some overhead. And one of the pieces of overhead is making sure that we are not letting technical debt build up in all of these different concurrent development streams or branches.
So, by technical debt, I'm really talking about a change that's made in one of those branches or streams, and that change has to be merged to one or several other active streams. For instance, if you have a bug fix that's made on an older release, that has to be very quickly merged down to active development branches so that we don't encounter that same bug in a newer release.
So, there's a lot of overhead involved, and for the rest of the example I'm just going to walk through some typical code line maintenance or release maintenance activities that happens as we reach the ending point of a sprint. So we have several older releases being maintained. There's bug fixes being done there.
We have to, in the proper order, merge all those bug fixes down first to newer releases, then into our main line, onwards to integration streams, and finally down to all of our active development streams. And at every point we want to make sure that we're rebuilding and retesting the code to make sure that that bug fix didn't actually introduce a new problem and make sure that that bug stays fixed in all of our new development work.
So that, obviously, is some code line maintenance work in terms of branching and merging. It's also some work in terms of actually running those builds and running those tests. And that bit, making sure that the entire cycle of build and test, that's something I'll come back to little bit later on. So, after we go through that process of making sure we've accounted for all those old bug fixes, we then need to take our finished development work, say the first team finished their sprint and they're ready to share their work, we then need to move that work up to an integration area where QA can look at it and the other development teams can have access to it.
And finally, of course, any other teams that are still working on their sprints, maybe they're working on a slightly slower iteration schedule, they then need to merge all that work down into their development stream as well. So just these routine activities are some overhead that we've incurred and we have to manage.
And we want to make sure that we have a proper software configuration management tool and processes in place, so that all these routine activities can be done quickly. There's nothing worse than being a developer and you've hit Friday afternoon, you've checked in, you're feeling good and you realize that your work isn't going to hit QA because that whole process of merging and making sure bug fixes are accounted for takes three or four days.
And believe me that can happen. In the defense industry I was working in, our merge activity when our six month software iteration completed was about three weeks. And that's about three weeks where you pretty much show up late, go home early because other than the SCM gurus, not a lot is going on. So, we want to make sure that we are not halting Agile productivity by letting all these routine code line maintenance activities overwhelm us. So, we want to make sure that all of this routine code line maintenance work that facilitates the current development is fast, easy and automated.
And again, that's where we have to make sure that our version control tool is helping us out and not getting in the way. Now, of course, Agile doesn't...is pretty agnostic about tools, so we never want to change the way we work in order to mesh with the way our version control tool is designed to work.
But, that being said, we want to make sure that our version control tool is helping us out and reducing that overhead. And that's where a powerful version control tool like Perforce can really help keep us productive.
So all of those routine merging activities, branching and merging. Perforce is able to handle all of those very quickly and in a fairly automated fashion. So, most of the common merges...activities can be done by individual developers, so the tool is very accessible. And they could be done very quickly.
So, merging isn't an activity that takes hours. Most of the time we calculate that it is going to take a few seconds or at most a few minutes.
One of the other things that we're rolling out this year to try to help Agile development is a streams feature, which will make all of the powerful branching and merging tools even more accessible. So again, you don't have to be an SCM guru. You don't have to rely on another team for all of these common types of activities.
Every individual developer or every release manager has easy access to all of these tools. So, again, looking at some pictures of the stream graph tool, for one thing, the stream graph gives you a merge notification. So, I'll also talk about this in the context of facilitating transparency, but it's very important to know in advance if there are, say, bug fixes in an older release that you have to merge.
You don't want to hit Friday afternoon, when you're ready to check in, and then realize that there's 17 bug fixes that you haven't accounted for yet. And so, the stream graph gives you an easy visual indicator that there are changes that have to be merged, and that is just a little visual cue that you should do that sooner rather than later.
And by doing those merges sooner in the process, you make sure that the mechanics of the merger are kept simpler, and it also means that you tackle it earlier in the development cycle when it's less risky. The stream graph and the other tools that go with it also facilitate fast context switching so easily being able to do in-place branching or move your focus of work from one of these streams to another.
And if you're a release manager, that 's the type of tool you need to let you easily manage all of these code line maintenance activities.
So if you find out that there's a critical bug that's made it in an older release, you may want to switch over to that stream quickly to have a look at it, and switch to other streams so that you can actually do the merges and do some local building and testing work.
And, again, all of the branching and merging tools are going to be very accessible. So, again, you don't have to rely on the SCM gurus in order to do this.
So we're not saying that there's some lag time because you need a team of experts to do your branching and merging.
So, just in the stream graph through context menus, all the tools you need to do these common activities are available easily, and most of these activities can be completed with just a few mouse clicks.
So, again, in terms of moving from the three week lag that I saw in the defense industry, in most cases these types of routine activities can be done in a few minutes. So, you're chopping off quite a bit of overhead. And, of course, if there are conflicts, two people working on the same part of the same file, Perforce, of course, like, like any good SCM tool, gives you all the tools you need to understand where that conflict occurred, trace back why that conflict was introduced, and figure out how to resolve that conflict.
Automation is, I think, a really important area to focus on in Agile. Again, you never want to waste time working with tools, whether it's for branching and merging, code review or anything else. And, so, we really encourage people to take advantage of automation as much as possible. Now, if you have background in the kind of SCM tools that were available 10 to 15 years ago, automated merging may sound like kind of a scary concept.
But, in reality, these days the tools have advanced to the point where your routine activities, like making sure that all bug fixes are merged in from old releases, that's something that in a lot of cases can safely be automated, so it can happen every night. And in some cases, if there are no conflicts, you can actually submit those merges automatically.
So, again, that's one less thing that the average developer or the average release manager has to worry about themselves.
The second problem in scalability I'd like to talk about is the dependency management problem. And dependency management is a problem, no matter what your development methodologies are, but they become particularly acute when you're talking about Agile development methodologies. That's because in Agile, again, we're trying to reduce overhead.
We want to let every individual team work at the pace that best suits them without interfering with one another. So, again, going back to my time in the defense industry - it wasn't all bad, I'm just picking on them a little bit today - we were working monolithically as a single team for 6 months. And, in reality, you know, we had this logical picture of the different pieces of of our product, but just for various reasons we didn't let those different teams work independently.
So, obviously that wasn't very efficient. The team working on one component may finish after three months, and then for the next three months they're kind of sitting around and maybe doing some testing and thinking about the next iteration, but they were really constrained by inefficient processes and inefficient tools.
And again, if you're working in an industry like the embedded industry or the gaming industry, this is a very complex problem to tackle. I visited a gaming company last fall, and just a single product of theirs, a single game, is composed of over 200 different modules. And, in total, in the entire company, they manage 500 different modules.
These modules are worked on by different teams at different paces. And again, to really facilitate agile development, we need a version control tool that let's us handle the situation smoothly. So in the example that I'm going to talk about today, we have a product that's put together with five different pieces.
And in the team that I'm working on, we only work on two of those and in the particular sprint that I'm planning now, only one of those, the one that I'm calling the active module, is actually going to be worked on. The other module we don't plan to touch, so I call that the read-only module for this sprint and this team works at four to six week iterations.
We have another module that's developed by another team. They actually work at much shorter iterations; they're in two week sprints. There's a web module and that evolves nightly, just as new web pages are updated or introduced. And, finally, there's a legacy component that we need, and that's in a kind of a long-term maintenance mode, so it evolves at six month maintenance cycles. So, the challenge here is putting all of these five components together in a way that lets us easily do our local building and testing.
But we also want all of these different teams to be able to work at the pace that suits them best. So the team that's working at two week cycles should be able to produce a new version every two weeks and not worry about destabilizing the work that my team is doing. So, what this looks like is on the server, in the repository, there's these different components that live in different areas, they might have their own branching structure, again, their own release processes. But if I'm a developer, I need a working local copy of all of these modules put together in such a way that I can do my building and testing easily.
So, the product architect has to understand how these five pieces fit together. But if I'm an average developer, I may be aware that there's all these different pieces, but I don't really need to worry about it. I just need a local copy that I can do my work against. So, Perforce has always had the tools that facilitate this, and with the new streams feature that's coming out this year, it's going to become a lot easier to manage.
So, the project architect, the person who really understands how these pieces fit together, they can define, in what we call a "stream view," what pieces are being actively worked on; what pieces should be read only; and what pieces are imported from other parts of the repository. And that information is just inherited by all the other users who are working in that stream.
So they get a working copy, a workspace that's set up correctly, without any kind of configuration work on their part.
This visual is actually just a little screen shot. It's a little java script applet I put together just to visualize how this looks to the average developer. So, you have a single stream, in this case it's just the main line on the far left of that picture. There is all the different pieces. And then with this stream view, if I want to, I can trace back and see where all those pieces are actually coming from.
And that may actually be useful. I don't normally care about that, but if I find a bug, say, in that legacy component, I may be curious where it comes from, what version of it I'm using, so that I and let that other team know that there, there's a problem they need to look at. And, again, by putting in place the proper version control tools and procedures to help us manage complex dependencies, we're letting every team, these four teams working on these different parts of the system, work at their own pace efficiently but still being able to collaborate.
So, the version control tool provides the framework where these teams can work independently on their own projects and all this information can still be used to collaborate effectively. So, just to sum up on scalability which again I think is one of the key challenges when you're adopting Agile development methodologies in a large organization.
Version control really facilitates Agile development because it makes it possible to manage complex concurrent development and dependency management issues. And, if you don't have the right tools and procedures in place to manage these types of problems, what you'll find is that as you roll out Agile to bigger teams, that you start running into a lot of those overhead problems that really slows people down.
So the second major area I'd like to talk about is kind of taking a step back and talking about more general productivity issues.
So, again, Agile doesn't really, Agile is fairly agnostic about what tools we use.
But at Perforce we think that having the right tools, can offer a lot of value to developers in terms of letting them work more efficiently and have a better understanding of the product that they're working on.
And the key, really, is putting those tools in the right place.
So, some of the reason why Agile is always agnostic about tools is that if you came from a background like I did in the defense industry where some of the tools were really mandated by contractual obligations or, you know, kind of a heavy process, that could be very inefficient.
And so a lot of developers have this backlash, saying, you know, don't force me to use a set of tools that are going to slow me down and that don't really fit the way I work. And part of the problem is having tools that have different views of the data that aren't really coherent and don't mesh well together.
Again, that really caused a lot of inefficiency. So I think one of the key things, if you're going to be using the right tools, is making sure those tools are available in the right place, which for the average developer is the place where they spend the most time, the development IDE.
So, first I'm just going to cover what some of these important tools are in the context of version control, and then I'll talk a little bit more about that goal of making these tools available in the right place. So, to facilitate collaboration, again particularly on larger teams, it's important to be able to easily access the history of a file, how it's evolved over time, and particularly how other teams are using that file.
So of course, in most SCM tools, you can access the detailed file history, all the revisions, when they were checked in. But again, to facilitate collaboration with other teams, it's very important to be able to visualize the branch history of a file, so you can see how a file has evolved over time, how new development features are impacting that file, how maintenance work on older releases is...are impacting that file as well.
As part of that process of understanding the evolution of a file, which, again, I think is kind of key to developers being able to be productive and efficient, of course, you want to be able to compare any two copies of a file to see how it's evolved over time. And another thing that's also very important is being able to have easy access to the history of the entire repository.
So, Perforce offers tools that let you easily search for key words or text strings in any part of the repository, even part that you don't normally work with. And that's a really powerful tool. If you're working in a repository that's fairly substantial - so, tens or hundreds of thousands of files with a very rich history - if you're trying to trace down where a bug was originally introduced, that ability to easily search through any part of the repository even if it's an old part that's not actively used anymore, that can really give you a powerful analysis capability.
And, of course, there's a lot of other visual tools that we provide that help you understand how a file has evolved over time.
This particular screenshot was one of my favorites when I was the day-to-day release manager.
It's sometimes called the "blame tool".
It lets you easily trace down a bug and figure out who introduced it.
Another tool that I think is becoming increasingly important is shelving.
Shelving is really the ability to stash work in progress on the server.
And I think the reason it's really important is that a lot of developers these days are switching to a very task-focused method of working. There's some other tools I'll talk about later, like Mylyn and the Eclipse framework that also facilitate this, but in this task-focused mindset, we don't really say that we're working on a branch and we have a set of files we're going to check in, we have a set of tasks that we need to work on, so these are the stories and the derived tasks that are scheduled during the sprint. And that's what we really want to keep people focused on. So, while we're working, of course, we may have to switch quickly from one task to another and shelving is just one of the tools that lets you do that.
So again, shelving is a tool that lets you easily put work in progress up on the server. From there, other users can access it for code review, you can pass work to another user. Or, if you are sidelined by something else, you can simply store your work in progress, start working on something else, and then retrieve your work later.
So again that really facilitates that task focused method of working. And, of course, the stream graph and some of the other visualization tools also give you kind of a bird's eye of how the entire project is structured. So, if you're a developer, kind of in the weeds, working on the development stream, sometimes it is refreshing to have a view of how the particular feature branch you're working on fits into the bigger picture.
And like I mentioned before, it's not just having the right tools, it's having the tools in the right place that's really critical to helping developers be more productive and efficient.
So, all of these tools I've mentioned, you know, Perforce as your version control tool, if you have code review tools, project management tools, defect tracking tools, they all offer valuable information.
There is a reason we have these tools.
But where some of the efficiency, the inefficiency creeps in and we where sometimes developers have a little bit of backlash, is if they have tools that don't communicate well with one another.
So, they have tools where they have to constantly switch back and forth between the defect tracking tool to look at the bug report, switching back to their version control tool to do their check ins and check outs, the IDE where they actually work, and so on. And, again, I'm very familiar with that from my own experience as a developer.
And having the right tools in the right place is really key to helping people be more efficient.
So, the solution we recommend, again, is putting all these tools in the developer's preferred working environment and facilitating that very task centric view.
So, people are focused not on the tools they are using but the task they're working on.
Perforce has always believed in this philosophy of integrating with other tools and making a version control accessible.
Perforce has a lot of open API's that facilitate that. We integrate with some of the best IDEs out there like Eclipse and Visual Studio and IntelliJ.
But, for the rest of this little section, I'm gonna focus a little bit more on Eclipse and how some of these tools being put into Eclipse helps people be more efficient.
One of the other features of Eclipse that, again, really facilitates this task focused method of working is called the Mylyn framework.
Mylyn was developed by a company called Tasktop. Mylyn itself is open-source. And Mylyn puts that task focused view directly into Eclipse. So it lets you establish an easy link between Changeless and Perforce, which is the set of files you're actually working on, and the task we're storing that's actually causing you to do that work.
And of course, there's a lot of other features in Eclipse that leverage the power of Perforce to give you some great features like Language Aware, visual tools, and a merge quest tool.
But again, in terms of task management, keeping people focused on the tasks, and stories they're working on, our integration with that Mylyn framework I think is really key.
So the Mylyn framework lets you have a task view directly in Eclipse. You can pull those tasks directly from Perforce or from a system like Quality Center or JIRA. But the important thing is it lets you build up a customized task view that you can work with. It has a lot of other features like notifications when new tasks come in, or when a task that somebody else is working on has been fixed.
And it also give you a private scratch area, and it gives you some task searching capabilities as well.
The really neat thing about working with Mylyn is that it allows you, as you're working on a task, to start building up a task context. So, that includes the files you're working with, what views or perspectives you had open in Eclipse, and a lot of other information. And as you're building up this task context, if you switch from one task to another, it basically saves that context, everything you were working on, what you were looking at.
So it really lets you switch between two tasks very easily. So you can put one task off to the side, start working on another one, and if you switch back to your original task, it restores everything you were doing. So again, it helps people easily switch back and forth between different activities.
And what that looks like in Eclipse is task activation. So, you have your task list, which is customizable, and you can pick a task, and switch back and forth between them very quickly. With some systems on the back end, like JIRA, in the process of activating a task you can actually retrieve a task context that somebody else had built up for you.
So, again, that's a really handy collaboration tool. So, in the context of productivity, again, we're not focused on using tools for their own sake we're focused on what tools can give us to let us be more productive, be more efficient, and maintain that rapid flow of change which lets us deliver business value more quickly.
The final topic I'd like to talk about today is transparency, and how a version control tool and some of the other Agile tools can help with that. And transparency is another topic that's pretty near and dear to my own heart because in some of the companies I've worked at there was this huge disconnect or communication gap between the people who defined what we had to work on and the people actually doing the work.
So, I I've seen cases where, when requirements were coming from the customer, say in the form of a contract, you would have a team of requirements engineers, requirements analysts. They would go off in a room for six months, and they'd break down what the customer wanted into a set of tech, requirement specifications.
And I'd say, "Well, can I look at that?" "Well, no, no, no, no, no.
There's another team that does that, and they use a different system that you don't have access to." And, then the project managers and the architects would take the business requirements
and they would decompose those into technical requirements and specifications. And I'd say, "Well, can I see that?"
"Well, no, no, no. That's in a different system and you don't need to look at that."
And so what I would get is my boss telling me, "Oh, go work on this," and, you know, in some sense day to day, you may not really care that much. But, that communication gap, I think actually causes a lot of problems. If, as a developer, you don't have a clear sense of the business case for working on something, it can lead you down a lot of wrong paths.
Without that understanding of why you're doing something, it can be really, really difficult to choose the best implementation. And, so, it can cause a lot of inefficiencies. So, one of the key parts of Agile is trying to break down some of those communication walls, and really focus on transparency.
And that's one of the reasons behind having some of the daily stand up meetings. Get the people who understand the business value in the same room as the people who are going to be doing the work, the people who are going to be testing the work, the people who understand the cost of doing things, and you'll find you end up with a much more productive system.
And, of course, that transparency lets you answer all sorts of interesting questions like, are we actually meeting our deadlines? What's the actual cost of implementing something? That can be an important consideration in your spring planning. And, again, if you're working in a large team environment, is some other team working on the same problem?
Maybe that means we need to collaborate with them on implementing that particular feature. So, the three particular pieces of transparency I'd like to talk a little bit about. The first is looking at the status of the project, the Second is looking at the status of the sprint as a whole. And the third is focusing, again, on the cost of tasks.
So in the context of looking at project status, being able to easily understand what other people on your own team and what other teams are doing, again, really helps out with productivity with Agile processes. So Perforce as the version control tool can certainly help with that. So, Perforce always gives you the ability to know what files other people have checked out.
So, in this example, if EBolt.Java was a really critical Java interface file and I saw that somebody else on my team had that same file checked out, that's a really good indication that I need to go and talk to that person. So, just these kind of simple, visual indicators can really facilitate transparency and help make sure that I'm not wasting effort or that I'm not going to be stepping on somebody else 's work.
From a slightly higher level, again, to see what other teams are doing, some of the other visual tools like the revision graph and the stream graph lets you easily see when merges are pending. So, again, if you have several teams working on new features and there's a lot of integration activity going on, a lot of merging work, having those visual indicators, again, can really help you keep on top of what the other teams are doing.
Now where some of the other Agile tools come into play, tools like Code Review, for instance, are also great for facilitating transparency at the project level. Code Review, and again, when Code Review first became a popular concept the tooling hadn't really caught up with the ideas. And for a long time Code Review meant stick four people in a room with some printouts, red pens and a box of cookies for two hours, and hope something good happens in those two hours.
Well, all that really meant is people ate too many cookies and not a lot of work actually got done. But these days, again, the tools have really caught up, and Code Review can be done asynchronously, which means you do it on your own time and your own pace, it becomes a lot more efficient and, perhaps more importantly, the tools capture all that information.
So popular code review tools like Codestriker, Code Collaborator, and Crucible, they'll capture all of that conversation, which is pretty important information. And Code Review can be an optional part of the work flow.
It can be something you enforce with your project management tool, but the real benefit in terms of transparency is is that you're bringing more sets of eyes on to code that is changing.
So you're taking advantage of more of the expertise that you have in your own team, you're improving code quality and helping eliminate some of those pitfalls and bugs.
Looking now at more of the transparency from the sprint level, I think, again, what's really handy is facilitating this task focus method of working.
So we have the sprint planning, and hopefully we're capturing that information in a good project management tool.
Now I know that sometimes when you're just starting out with Agile, there's this temptation to really fall back on the whiteboard with a bunch of sticky notes routine. I think that is a little ineffective for a couple of reasons. One is, obviously, it's challenging if you have big teams or teams that are geographically distributed. But I think there's a lot of information you're letting slip through the cracks if you're not capturing it in an effective tool. So what's really valuable information to a developer, again, is this "why" they're working on a task.
So, being able to tie check in activity, development work, back to an issue in a defect tracking system or project management tool is really going to increase transparency and really help developers be more productive. And that rich context of the links between stories and tasks and the work that's actually being done, again, I think that is something that we don't want to sacrifice.
And again, you know, Perforce integrates with a lot of the popular issue tracking and project management tools like Version One, Hansoft, you know, some folks that are out in the Expo hall, ticketing systems like JIRA and Redmine. And not only do we integrate with them, but we can actually feed task completion information back to those tools. So, as developers complete their activities, they do their check ins in Perforce, we can automatically feed that information back to those project management tools, back to those defect trackers, which eliminates a lot of the manual work that's kind of tedious.
And more importantly if you're the release manager or the Scrum master, you get kind of near real time information feed about what's happening in your sprint. So you don't have to wait for a daily meeting to figure out if you're falling behind. You can pretty much at any time have a look at a dashboard tool in one of these project management systems and have a pretty good sense of how your sprint is going.
And that kind of real time status information is incredibly valuable if you're the person who has to make sure that things get done on time.
And, of course, continuous integration is another favorite tool set of mine. Continuous integration, of course, I think is becoming a must have tool these days. And, it really lets you have a quick status check on the health of a branch.
So, it really does facilitate transparency.
You can look at a CI dashboard and see which branches maybe are not building even, if there's broken code and hopefully you're able to take it a step beyond that.
I 'm really a fan of test driven development.
And if you focus on those types of methodologies, if you can integrate the test suite into the CI system,
that means that not only are you seeing if the code builds, you're seeing if things are actually working the way you expect them to, pretty much on a nightly basis or maybe even on every check in.
That 's incredibly valuable information, both for the person who's managing the sprint and for individual developers.
Taking it one step further, if you can actually have some of that testing work being done and those continuous builds being done in the pre-flight stage, so maybe in in a local development branch, in a feature branch, before it's even hit the official integration stage, you're just going to make things that much easier for the entire development team.
And, finally I'll talk a little bit now about the costs of tasks which really ties back into the whole sprint planning phase So, of course, during the sprint planning, you are supposed to be assessing the business value of the tasks that you, and the stories that you may be able to work on for the next sprint.
And that's part of how you determine what issues you work on, what capacities do you have, what with the limited resources you have is going to deliver the most value? But, the flip side of that question, of course, is how much do all of these stories and tasks cost us to implement, in terms of man hours, development resources, things that cost us basically money to provide to the team.
And so if you have two stories or tasks that are of equal business value, and you know somehow that one of them costs twice as much to implement, that makes your decision making, pretty easy. Now, where Perforce can help with that, and of course there are a lot project management tools that really help me manage that whole sprint planning process. But , Perforce's database, as you use it, is accumulating an incredible amount of useful information.
Like, for a particular product, a particular branch, how much work is actually being done on average to fix a bug or implement a task? So, again by linking to the systems that are tracking the tasks, we can provide that type of information.
You can look in our database and see for a particular bug fix, on a particular, say, the database module. How many files were modified? How many people had to work on that task? How many lines of code change? How many change lists or check ins were actually submitted? So that's incredibly valuable information because we can translate things like that, that low level information, like number of check ins.
We can probably translate that, at least at a coarse level, to time and money, which is really the, the cost of implementing something. Now, any SCM system is going to have this type of rich information, at least at some level in its database. But I think where Perforce really shines is we make it really accessible.
So with the P4ToDB tool, you can replicate Perforce's metadata in near real time into a relational database like Sql Server or My SQL. And from that point, you can either run ad hoc queries or, better yet, you can hook up a reporting tool like Birge or Crystal Reports and you can make all this information accessible through a web interface and just make it part of your regular planning process.
So again, I think transparency is one of those key Agile tenants that it's worth its wait in gold if you can hit that goal of having a transparent flow of communication.
So, just to wrap up, you know, Perforce, as the version control system, provides really powerful tools and techniques to help you manage Agile processes and scale them out to larger teams and complex development models across an enterprise.
And it does that through some of our co line management tools, some of the other productivity tools we have, and by virtue of the fact that Perforce has a lot of information.
And we try to make that information as accessible as we can, which really helps with transparency.
We 've just about hit the end of the time I had planned for, so I do want to have time for Q & A. But I just want to mention if you'd like more information, there's some links on the slides for our website. Michael Alessio and I are out at the booth in the expo hall, so if you're here in person, feel free to stop by and chat.
Or we can show you a Q & A of some of the things I've been talking about.
And, of course, if you're into Twitter and you just want to pop open a quick question, feel free to do that as well.
So with that, I'm happy to take any questions, either from the folks here or from the folks in the virtual audience.
Yes?
When is the stream view coming?
The stream view is hitting beta next month and it'll be released officially in the fall. If you'd like an early preview, we have a lot of information up on the Perforce blog, including some screen shots.
And Visual Studio integration?
Visual Studio, we have an existing SCC based integration. We're writing a new integration this year that will be out by the end of this year that's going to offer a lot of the same things that you saw in our Eclipse plug-in.
Yes.
We have some from the virtual audience. And I don't if you can repeat if you can so that they can hear your question
Sure.
The first one is, What are the top three differentiating features of Perforce that contribute to collaboration and velocity?
Okay, so the question was, What are the top three features of Perforce that facilitate, I think, collaboration and velocity?
That's correct.
Yep. So, I think there's probably more than three. I think the top three if I had to pick right now would be the code line management tools, including the streams feature. And I think that really facilitates collaboration because it lets the product architect type of people manage the complexity of software development and use their knowledge to make things much easier for the average developer.
And, of course, all of the branching and merging becomes quite easy as well. Shelving, I think, is another really powerful collaboration tool. Again, it lets you switch tasks easily, get other users in the loop, to hand off a task to them, or do informal code reviews. The third thing, I think, is all of the powerful integrations that Perforce has, some of which we've written ourselves, some of which were written by some of our integration partners.
So again, if you have really powerful tools like Version One or Hansoft for project management, you have a build tool like Electric Cloud, it's really incredibly powerful to have these tools talk well with each other. That makes more information available to the entire team and it lets everybody work more productively.
Thanks, Randy, we have one more.
Okay.
How does Perforce worldwide distribute in groups that in part become a natural team
So the question was, how does Perforce, I think, I wasn't quite clear on the exact wording, but I think the question was, how does Perforce facilitate collaboration and Agile development for teams that are distributed worldwide. So, part of that is really simply kind of a performance and connectivity issue in terms of you may have a Perforce server here in the States, you have development teams in Europe and maybe over in Asia.
And from that aspect, Perforce has a lot of architectural components that facilitate that. We have proxy servers, replicated servers, we're introducing a local branching tool this year. That helps alleviate some of the lag in terms of just, you know, physical communication between a server and a local workstation.
And so that means that people are able to, you know, take advantage of everything that Perforce offers, even if they are overseas. But, again I think some of it is really more of a work flow issue and from that context the local branching tool that we're rolling out is certainly going to let people be productive even if they are remote from the server.
And, our integrations with some other tools that help big remote teams collaborate, I think is also really key.
OK, if there's no other questions, if anything else comes up, feel free to drop me a line on Twitter or email and if you're here in person, drop by the booth.
Thank you very much.
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form
thanks,