In the last post I defined two Agile software development best practices I believe provide value to a wide variety of development teams.   Here I define three more practices that I believe are also important when transitioning to Agile Software Development; collocation, unit testing, and refactoring.

Best Practice for Agile Software Development: Collocation

Collocation is simply having everybody on a cross functional team in close proximity to each other. This compounds the coordination benefit of cross functional teams. This is orthogonal to outsourcing. Whether you are outsourcing or not, collocation only refers to whether a particular cross functional team is sitting near each other.

Best Practice for Agile Software Development: Unit Testing

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

Best Practice for Agile Software Development: Refactoring

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don’t have adequate testing in place. That’s why refactoring is usually paired up with unit testing and together these are frequently combined with continuous integration.

One of the cornerstones of any successful organization is communication. On Agile teams, we often meet to share information, update one another on progress, to reflect on that progress and discuss how the process can be improved. These interactions, be they stand-up or retrospective meetings, provide this information at regular intervals. But what if you need “real-time”  information sharing?

Consider the concept of “one piece flow”, often treated as the holy grail of engineering process purists. Lean/Kanban fan boys live to talk about this at conferences, and in the isle outside my cube. The idea is that a single “workpiece” at a time moves through the workflow. In the software development process, this is rarely limited to a single item, but instead is throttled by WIP limits to minimize the bottlenecks in the process. For example, the number of items worked on by developers is limited so that the count of items designated “ready for test” is kept at a manageable level. As a tester on an agile team, I’d like to know as soon as an item is moved from the “wip/development” phase to the “test/validation” phase.

Consider the following basic stream structure -

In an ideal model, testers would be notified as soon as an issue is promoted from the WIP stream to the Validation stream. This model assumes that the project is utilizing AccuRev change packages to track work items as issues. Having a distinct stream for validation purposes simplifies the job of the tester. All issues that exist in this stream have been unit tested by developers, passed basic regression tests, and are ready to be explored, validated, and promoted to the next stage in the workflow.

So, how can this level of communication be achieved? AccuRev triggers! The rest of this post will demonstrate how the server post-promote trigger could be used to provide updates using arguably the king of “What’s Happening?” – Twitter.

Why use Twitter in your Backing Stream?

Why not? Sure, you could use e-mail. But who wants more e-mail? Tweet it, and let them aggregate the information for you. Team members can follow the account, or not. Pointy-haired managers that dream of pie charts and love visibility can subscribe to an RSS feed, that you don’t have to manage. Lastly, if you’re an agilista, you’re already hip and trendy, (and let’s face it, you probably  already tweeted about the awesome presentation on Lean that you saw at the latest Agile conference).

The Server Post-Promote Trigger

I am not going to go into the gory details of the AccuRev trigger system. Here’s what you need to know.

1. The trigger can be written in whatever language you like. In this example, I use Ruby.
2. The trigger needs to be registered with the AccuRev server, and associated with the depot for your software project.

For this exercise, I wrote a quick script called tweet_post_promote.rb. The first step is to register this script with AccuRev.

>accurev mktrig -p SoftwareProject server-post-promote-trig ~/dev/ruby/tweet_post_promote.rb

Once registered, the trigger will now fire for all promotes in the SoftwareProject depot. Let’s take a look at the contents of the script.

#!/usr/bin/env ruby

require ‘rubygems’

require ‘crack’

require ‘twitter’

ACCUREV_DIR = “/sandbox/amonty/accurev/”

ACCUREV_STORAGE = “#{ACCUREV_DIR}storage/”

ACCUREV_SITE_SLICE = “#{ACCUREV_STORAGE}site_slice/”

USER = ‘ValidationBot’

PASS = ‘password’

def load_trigger_data(file)

xml = ”

File.open(“#{ACCUREV_SITE_SLICE}#{file}”) do |f|

xml = f.read

end

Crack::XML.parse(xml)

end

def twitter_get_auth(user, pass)

httpauth = Twitter::HTTPAuth.new(user, pass)

Twitter::Base.new(httpauth)

end

def main()

hash = load_trigger_data ARGV[1]

if hash["triggerInput"]["stream1"] == “Validation” then

changePackageIssue = hash["triggerInput"]["changePackages"]["changePackageID"]

update_string = “Issue #{changePackageIssue} just promoted to stream #{hash["triggerInput"]["stream1"]}”

twitter = twitter_get_auth(USER, PASS)

twitter.update update_string

end

end

main if __FILE__ == $0

This script is very simple. It makes use of the Ruby gems crack and Twitter. Essentially, the script takes the XML trigger file (provided as ARGV[1]) and loads it into a hash. Then the script checks to see if the stream being promoted to is our Validation stream. If so, it uses the twitter gem to update the status on our ValidationBot account.

A more useful example is to provide a link to the AccuRev Web UI Issue screen.

This way, anyone subscribing to the feed can click on the link and open the issue in the AccuRev Web UI.

This is a small example of how AccuRev triggers can be used to increase communication on your team. Testers can follow the ValidationBot account and be notified via their favorite Twitter client whenever an issue is promoted to the validation stream and they need to begin work on it. This could obviously be extended to include additional information (actual file changes, for example). That is, of course, if you can fit it into 140 characters.

For more information on AccuRev triggers, please see the Administrator’s Guide.

While many experts push for Agile adoption throughout organizations, a different trend within organizations is emerging.  Organizations are taking smaller steps towards Agile by focusing on specific Agile techniques and applying them to their individual development processes. By adopting certain techniques, organizations still receive some benefits of Agile without “going Agile”.  After all, it is possible to do Continuous Integration without time-boxing and still reduce integration problems.

Getting Benefits of Agile Software Development

For those interested in gaining the benefits of Agile through smaller and more targeted techniques, there are a number of possibilities.  Below are recommended readings on Agile techniques, each focusing on one specific area, while detailing the processes and outlining the benefits.  Here is a great place to start when looking to gain the benefits of Agile software development.

User Stories Applied: For Agile Software Development, by Mike Cohn.

The Agile equivalent of requirements is User Stories, and this book is the definitive guide to creating and using them.  Readers will not be disappointed with Mike Cohn’s practical advice on User Stories, as the information offered is easy to read and apply. Valuable topics discussed include why to use User Stories, when they are appropriate, and how to monitor progress.

Continuous Integration: Improving Software Quality and Reducing Risk, by Paul M. Duvall, Steve Matyas and Andrew Glover.

This is a great resource for Continuous Integration. The authors stress the importance of integrating early and often using CI practices and provide detailed results of a successful CI implementation (including reducing risks, better visibility and reducing repetitive manual processes). Another important element of this book is its companion Web site, www.integratebutton.com, which provides updates and code examples.

The Art of Unit Testing: With Examples in .Net, by Roy Osherove.

This is one of the best on the topic of Unit Testing, partly because of RoyOsherove’s experience and passion about the subject, and partly because of his practical delivery. His book covers important areas of Unit Testing, including writing maintainable test code, code review and adopting Unit Testing in an organization.

Refactoring: Improving the Design of Existing Code, by Martin Fowler, Kent Beck, John Brant, & William Opdyke

This book offers important technical insight into the process of changing code to improve internal structures without changing external behavior and is a highly recommended resource on refactoring and improving design of existing code.

To get more benefits of Agile without going Agile, try JUnit Recipes: Practical Methods for Programmer Testing by J.B. Rainsberger, and Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck or visit AccuRev’s Agile Resource Center.

There are a variety of testing methods: White Box. TDD. Mocks. Unit. Stress. Functional. Taste. Flight. Load. and more…

It’s Friday… Here’s my favorite test courtesy of Boeing… check out the 777 Wing Force Test.

/happy testing/ – dave

I recently consulted with a company that had a requirement to version control their test results because generating the results took
hours and, in some cases, days to produce. Having the ability to compare results between specific source configurations over time was critical. However, the engineers found it cumbersome (and ultimately unnecessary) to include the vast amounts of test output within the actual release configuration.

Lets consider a typical development scenario that includes both nightly unit testing and scheduled system testing. This first picture is a screenshot of an AccuRev stream structure showing the streams involved in the workflow. Nightly testing of new development is captured by creating snapshots from Integration. Each snapshot then serves as a new root of development for committing the subsequent test results. A Nightly_Testing stream is created from the snapshot to store the test results. After promoting the test results, a new Nightly_Results snapshot is created to capture both the source code and test results. A similar pattern is (re)used for managing test results from SystemTest.

This second picture is the same picture but annotated to describe how to version control the transient test results. One way to absolutely prevent test results from being promoted higher up is to set incl/excl rules for the results directory. In this example, the SystemTest stream sets an incldo \.\test\results to exclude any relative files or subdirectories for the entire stream hierarchy (due to rule inheritance). However, each NightlyTesting stream sets incl \.\test\results so the results can be stored locally. Setting these incl/excl rules is an easy way to control the visibility and location of code throughout the stream structure.

Storing transient test results in isolated sub-stream hierarchies provides the ability to do stream-diff comparisons of test results. Furthermore, the golden Release snapshots are not cluttered with interstitial test results. In fact, if you need to backtrace the test results, you have them… afterall, they are now safely organized in CM.

/happy testing/ – dave