How can Bridgeall ensure that the ideas you have for a new IT development are understood and implemented, while delivering on time to budget?
It’s already been well documented that IT projects can and do often go horribly wrong, particularly when the initial systems specification isn’t written in concrete. My own experiences of being responsible for implementing new systems in a traditional, waterfall style have been fraught with setbacks. Essentially, projects suffered badly when client specifications were loosely defined and costs spiralled.
Enter Agile. Nowadays everyone says “we’re agile” but what does it mean, what actions should I take and more importantly how will that benefit you, our prospective customer.
Fundamentally I believe that being Agile means delivering business value frequently and consistently while adapting to changing business needs.
Translating this statement into action, this means that when my company Bridgeall delivers an agile project, we focus on four fundamental drivers:
We adopt a Test Driven Development (TDD) approach centred on automated testing and once source code is checked-in it undergoes immediate unit testing as part of our continuous integration (CI) builds. Full system test builds that include all UI tests are triggered automatically if all unit tests pass. This avoids last minute and expensive bug fixing at a time when you should be going live.
TDD is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfil that test and refactoring. TDD, when carried out properly and with rigour, results in higher quality software. In test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through use cases, user stories and screen mock-ups that cover the requirements and exception conditions.
This is a differentiating feature of TDD versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference. Any code checked in must adhere to our check-in policy before it will be accepted by Team Foundation Server (TFS) source control.
CI is a software development practice that requires team members to integrate their work frequently. Every person integrates at least daily, which leads to multiple integrations each day. Integrations are verified by an automated build that runs regression tests to detect integration errors as quickly as possible. We find that this approach leads to significantly fewer integration problems and enables development of cohesive software more rapidly.
To manage our Systems Development process we use Visual Studio ALM (formerly branded as Visual Studio Team System) for all development projects. ALM is a top-end environment for professional application development and Bridgeall has used this since 2006 for all development projects.
Team Foundation Server (TFS) is the collaboration platform at the core of the Visual Studio ALM providing fundamental services such as version control, work item and bug tracking, build automation, and a data warehouse.
With our agile approach to development our customers benefit from incremental and regular releases of high quality features that match their requirements. Our close and regular communication avoids unwelcome surprises and sustains long term and effective relationships.
Photo courtesy of Sarabbit