Agile2008
Come see one of my sessions at Agile2008, SD Best Practices, or Agile Development Practices!
Showing posts with label AccuRev. Show all posts
Showing posts with label AccuRev. Show all posts
Friday, May 25, 2007
Podcast: Winning the Jolt Award Using Hyper Agile Development
Here are some thoughts about winning the Jolt Award as well as a discussion of Hyper Agile, the new methodology that enabled AccuRev to deliver AccuWorkflow on time with high quality.
Labels:
AccuRev,
Agile,
Hyper Agile
Sunday, December 17, 2006
SCM vs Software Development
I came to the realization a while back that I'm not really an SCM person. In fact, I'm a software development process person who has been focusing on SCM. That's probably why most of my posts lately can't be directly linked to SCM. I've been working on broadening my thinking. As a result, I've decided to change the focus and title of this blog from SCM to Agile Software Development.
I think there's a lot of value to be realized using top-notch SCM tools like AccuRev, ClearCase, Perforce, and others. But I've come to the conclusion lately that a lot of the value of these tools either sits on the shelf as potential value or goes unrecognized and unappreciated. I think there are two reasons for this. First, I think that most people think of SCM tools as a repository and nothing more. Second, most SCM tools are optimized for being repositories and nothing more.
To put it another way, I've decided to turn my emphasis upside down. I don't think that most developers show up for work thinking about how best to optimize their branching and merging. So, instead of starting there and ending up at the developer benefit only to find that the audience has surfed to another page, I've decided to always start from the developer's point of view and link the discussion back to SCM only when necessary.
This also gets to another point. SCM folks by and large already recognize most of the value of SCM tools. That's what they do all day! Whereas, developers prefer to just write code all day and keep their interaction with an SCM tool to a minimum. That is as it should be. As a result though, I don't think that developers are getting the full value out of their SCM tools. I'm not saying that developers are thick, just that their focus is on writing code, not playing with SCM tools on the off chance that they might stumble across something that will increase their productivity.
Thus, it is up to folks that do think all day about how to improve developer productivity through better SCM tools to make the extra effort to pitch things from a developer's point of view so that when a developer does come up for air they see right away that they are being offered a lifeline and not a lead weight.
I think there's a lot of value to be realized using top-notch SCM tools like AccuRev, ClearCase, Perforce, and others. But I've come to the conclusion lately that a lot of the value of these tools either sits on the shelf as potential value or goes unrecognized and unappreciated. I think there are two reasons for this. First, I think that most people think of SCM tools as a repository and nothing more. Second, most SCM tools are optimized for being repositories and nothing more.
To put it another way, I've decided to turn my emphasis upside down. I don't think that most developers show up for work thinking about how best to optimize their branching and merging. So, instead of starting there and ending up at the developer benefit only to find that the audience has surfed to another page, I've decided to always start from the developer's point of view and link the discussion back to SCM only when necessary.
This also gets to another point. SCM folks by and large already recognize most of the value of SCM tools. That's what they do all day! Whereas, developers prefer to just write code all day and keep their interaction with an SCM tool to a minimum. That is as it should be. As a result though, I don't think that developers are getting the full value out of their SCM tools. I'm not saying that developers are thick, just that their focus is on writing code, not playing with SCM tools on the off chance that they might stumble across something that will increase their productivity.
Thus, it is up to folks that do think all day about how to improve developer productivity through better SCM tools to make the extra effort to pitch things from a developer's point of view so that when a developer does come up for air they see right away that they are being offered a lifeline and not a lead weight.
Thursday, December 14, 2006
First Hyper Agile Project is Now Complete
The project that I mentioned back in October, now called AccuWorkflow, has just been announced this week! You can also learn more about it here. While the connection to Agile Development may not be that clear yet, this is just the first release.
I believe that for Agile to succeed it must be supported by more tools and it must scale to larger teams. Further, short iterations will actually require much better defined and much more automated process. To that end, AccuWorkflow, a new add-on to AccuRev makes it much easier for teams to establish and automate their desired process across the entire software development life cycle regardless of methodology.
For this project we used an Agile methodology that I call "Hyper Agile." The key ingredients of Hyper are:
Short Iterations
Automate Everything
Virtual Pipelining
Requirements
Source Control
Issue Tracking
Development Hierarchy
Estimation
Transparency
Meritocracy
Ranking
Quality Quotient
For more information on the role of short iterations in Hyper see this article. In future updates I'll elaborate on other aspects of Hyper and the experience of using it in the development of AccuWorkflow.
I believe that for Agile to succeed it must be supported by more tools and it must scale to larger teams. Further, short iterations will actually require much better defined and much more automated process. To that end, AccuWorkflow, a new add-on to AccuRev makes it much easier for teams to establish and automate their desired process across the entire software development life cycle regardless of methodology.
For this project we used an Agile methodology that I call "Hyper Agile." The key ingredients of Hyper are:
Short Iterations
Automate Everything
Virtual Pipelining
Requirements
Source Control
Issue Tracking
Development Hierarchy
Estimation
Transparency
Meritocracy
Ranking
Quality Quotient
For more information on the role of short iterations in Hyper see this article. In future updates I'll elaborate on other aspects of Hyper and the experience of using it in the development of AccuWorkflow.
Labels:
AccuRev,
Agile,
Hyper Agile
Streams for Large Scale Development Projects
Joel Spolsky recently did a posting on large scale development and mentioned AccuRev!
Labels:
AccuRev
Wednesday, October 04, 2006
A Big Bang AccuRev Release
Some of my more recent thinking on software development, especially in regards to Agile Development, is in an article in the October issue of Queue Magazine, entitled "Breaking the Major Release Habit."
With that in mind I would like to mention that AccuRev 4.5 is now available. While it is called 4.5, it is actually one of our biggest releases ever. Here's a blog that mentions it. So why didn't we call it 5.0? Thankfully, that's not my department. :-) Anyway, my point is that while I believe very strongly in short iterations and more frequent releases, organizational change takes time and is hard to do.
To that end, I am currently working on a new project and piloting a new Agile methodology to develop it called Hyper Agile. The goal of the new project is to take AccuRev, which is already well suited to Agile projects, to the next level of Agile functionality. The aim of Hyper is to take a fresh look at Agile Development and scale it beyond small co-located teams. A preview of the Hyper methodology will appear in an upcoming issue of Dr. Dobb's, stay tuned!
With that in mind I would like to mention that AccuRev 4.5 is now available. While it is called 4.5, it is actually one of our biggest releases ever. Here's a blog that mentions it. So why didn't we call it 5.0? Thankfully, that's not my department. :-) Anyway, my point is that while I believe very strongly in short iterations and more frequent releases, organizational change takes time and is hard to do.
To that end, I am currently working on a new project and piloting a new Agile methodology to develop it called Hyper Agile. The goal of the new project is to take AccuRev, which is already well suited to Agile projects, to the next level of Agile functionality. The aim of Hyper is to take a fresh look at Agile Development and scale it beyond small co-located teams. A preview of the Hyper methodology will appear in an upcoming issue of Dr. Dobb's, stay tuned!
Labels:
AccuRev
Friday, January 27, 2006
What Exactly is a Stream Anyway?
From time to time, people ask "what is a Stream?" At this point pretty much anybody associated with software development has heard of branches, but streams are a relatively new concept which is similar to but at a higher level than branches.
Here's my .02 on streams, coming from the AccuRev point of view. First, I think that at some level the various SCM systems which talk about "streams" are probably all trying to achieve something fairly similar. That is, a "stream of development."
My initial exposure to "streams" was from hearing folks talk about "streams of development" independent of the SCM system that they were using (which did not have such a concept). The idea was that you had work which was towards a particular purpose, such as new development, maintenance, a team working together on a sub-project, etc. Each of these was a "stream of development".
I have also heard the terms "codeline", "development effort", and "line of development" used in the same context. At the end of the day, the folks which initiate these things (managers, business people, etc) don't really care how they are implemented, they just want to ask questions like "how is 4.0 coming along" and "are all of the fixes from maintenance in the latest release?" Somebody else then translates that into the appropriate queries, which may be in terms of branches, scripts, streams, or something else.
Prior to AccuRev, I found the need to tranlate somewhat mystifying. Why should there be any difference between the mental model of "streams" and the implementation model?
Thus, in AccuRev, the mental model and the implementation model are the same. Streams are the basic building block of the architecture. There are no branches or labels, just streams. There are streams for releases, streams for active development, streams for end users, etc. Each stream except the root stream is defined in terms of a parent stream and inherits everything from the parent (recursively).
So, if you want to do maintenance on the 4.0 release, you would create a new stream based on 4.0 . Through inheritance, it is the same as 4.0. The definition itself is all that is required. The definition is simply "4.0_maint" is everything in "4.0" plus all of the changes in "4.0_maint".
Since streams are first class objects, you can act on them directly. You can assign security attributes, lock them, define other streams in terms of them, compare them directly, do queries on them without having to understand how the streams themselves are composed, etc.
For the curious, I've written a whitepaper which describes AccuRev's stream architecture at an even deeper level:
http://accurev.com/product/docs/AccuRev_Streams.pdf
And if you want to go even deeper than that, the basis of AccuRev's streams is TimeSafe:
http://accurev.com/accurev/info/timesafe.html
Here's my .02 on streams, coming from the AccuRev point of view. First, I think that at some level the various SCM systems which talk about "streams" are probably all trying to achieve something fairly similar. That is, a "stream of development."
My initial exposure to "streams" was from hearing folks talk about "streams of development" independent of the SCM system that they were using (which did not have such a concept). The idea was that you had work which was towards a particular purpose, such as new development, maintenance, a team working together on a sub-project, etc. Each of these was a "stream of development".
I have also heard the terms "codeline", "development effort", and "line of development" used in the same context. At the end of the day, the folks which initiate these things (managers, business people, etc) don't really care how they are implemented, they just want to ask questions like "how is 4.0 coming along" and "are all of the fixes from maintenance in the latest release?" Somebody else then translates that into the appropriate queries, which may be in terms of branches, scripts, streams, or something else.
Prior to AccuRev, I found the need to tranlate somewhat mystifying. Why should there be any difference between the mental model of "streams" and the implementation model?
Thus, in AccuRev, the mental model and the implementation model are the same. Streams are the basic building block of the architecture. There are no branches or labels, just streams. There are streams for releases, streams for active development, streams for end users, etc. Each stream except the root stream is defined in terms of a parent stream and inherits everything from the parent (recursively).
So, if you want to do maintenance on the 4.0 release, you would create a new stream based on 4.0 . Through inheritance, it is the same as 4.0. The definition itself is all that is required. The definition is simply "4.0_maint" is everything in "4.0" plus all of the changes in "4.0_maint".
Since streams are first class objects, you can act on them directly. You can assign security attributes, lock them, define other streams in terms of them, compare them directly, do queries on them without having to understand how the streams themselves are composed, etc.
For the curious, I've written a whitepaper which describes AccuRev's stream architecture at an even deeper level:
http://accurev.com/product/docs/AccuRev_Streams.pdf
And if you want to go even deeper than that, the basis of AccuRev's streams is TimeSafe:
http://accurev.com/accurev/info/timesafe.html
Labels:
AccuRev
Wednesday, July 27, 2005
Source Control Using CVS, Subversion, and AccuRev
A couple of weeks back, Robert Warner, of Availity gave a presentation to The Jacksonville Developers User Group titled "Source Control Using CVS, Subversion and AccuRev."
The link to his presentation can be found here.
He also, in one of his subsequent blog entries, addressed the audience's question of the criteria against which he and his company had evaluated the tools. The blog entry is simply titled "Source Control."
His is a great overview of the major features and functionallity of some of the SCM product solutions out there.
Enjoy.
The link to his presentation can be found here.
He also, in one of his subsequent blog entries, addressed the audience's question of the criteria against which he and his company had evaluated the tools. The blog entry is simply titled "Source Control."
His is a great overview of the major features and functionallity of some of the SCM product solutions out there.
Enjoy.
Labels:
AccuRev,
Software Configuration Management
Subscribe to:
Posts (Atom)

