Home
407-909-0930
skip to the main content area of this page
Bayside Incubator Blog
Sharing Ideas on Collaboration and Innovation

Bayside Technology, LLC

Technology solutions to help your business succeed.

Phone:
407-909-0930

Email:
info@baysidetech.com

Spec’ing the specs: Keeping a project on track

May 18, 2010 @ 10:56 am
by Dave Konopka
Filed under: software process,team work

In two other posts we’ve covered both how to craft and how to capture a plan when approaching a software project. In this third and final post of the series we’ll talk a bit about our approach to following that plan when it comes time to execute it.

Collaboration has emerged as the common theme for us in designing and developing software. For any plan to have a chance at successful execution, the people charged with building it, the people who will use it, and the people who have expert knowledge about the business behind it need to work together from start to finish.

Collaboration certainly shouldn’t stop once developers start writing code.

Determine features, schedule priorities

During the planning process your team will have defined what the new application should do. The next step is identifying chunks of releasable features. Rolling out useable pieces of your new application over time will encourage your team to exchange feedback while changes are still reasonable.

For example, if you are building a member restricted web application, the first releasable feature would probably be a landing screen restricted by a username and password login. The next logical piece might be a screen to add and edit system users. Almost immediately business experts and end users can begin to interact with the system they helped plan.

Once you have a rough outline of features determine which features take the highest priority and which fall towards the lower end. A schedule of priorities gives everyone a clear idea of what to expect as the project proceeds.

The schedule doesn’t have to include exact delivery dates to work. But staying on top of a rough estimate of delivery dates for features can be very helpful as you have to make priority decisions deeper into a project.

Continuous integration

In order to participate your team members will need access to the project as it evolves. If your project is web based that means having a beta server with the most up to date web site on it. If your project is a desktop app that means having an easily installable and updatable beta application.

Continuous integration is a software development practice that aims to automate merging of features into a single deployable software update regularly. As your developers write code they should be committing it to a source control system. Whenever a feature is ready for beta they can flag it for release. When this happens a continuous integration system automatically assembles a new beta version of the application. Most systems will notify team members when there’s something new to review.

Automating the deployment process removes a process hurdle and makes it much more likely that features will be deployed for review.

Business experts need to see test results

From the very start of your project business experts should be involved with crafting tests. They should also be able to access test results. Your team should use a testing approach that is accessible to technical and nontechnical team members alike.

In our second post we mentioned Behavior Driven Development practices. The frameworks we mentioned (JBehave, NBehave, RSpec, Cucumber) push tests away from techno-speak and towards plain English. This can make it easier for business experts to understand the results of tests written by programmers.

Whatever testing platform you use, get your business experts writing test cases. Having test plans written by business experts is better than leaving testing to programmers alone.

Before you do anything else, start an issue list

Create an issue list at the very start of construction. Make it writable by all team members. As issues or new features come up, enter them on the issue list. Allowing business experts to enter tickets will alleviate some of the interruption that can encroach on developers while ensuring all ideas/issues are captured.

From time to time, everyone should revisit and refine the issue list. As tickets are addressed and released, close them. Look through the list often and look for misplaced items. Recategorize and reprioritize tickets regularly.

Any decent ticket system will allow for notifications. A well used ticket system can serve as a central notification clearing house and historical record for project progress.

Wrapping Up

Once coding starts communication, issue tracking, and testing are the keys to a successful project. Consistent participation from technical and expert team members is the surest way to keep a project on track. More importantly this kind of cooperation will enable your team to adjust to changes because new issues will always come up.

Hopefully this series has given you some ideas on how to improve your team’s process of developing software. None of our suggestions are miracle fixes. And most can be tested out separately from the rest. So jump in and give one or two a try. See what works in your organization.

Anything you can do to foster an environment of collaboration will increase the quality of your end product.

  • Zack Burruel

    Great article.. I enjoyed stumbling upon it. I work over at Axosoft.com, and although you list some great examples of ticket/issue systems that are very good products, I would like to suggest OnTime. I would love to hear any feedback that you might have.

blog comments powered by Disqus