Large Scale Testing In Agile Time – Experience Report, Thanou Thirakul, 2009
What do you do if you have over 1200 integration tests and over 8000 unit tests that takes over 11 hours to run on a single machine? What’s worse, these tests are fragile which caused many build failures. Change is not simple when there are over 1 million lines of code, over 300 database entities and feature rich. Converting integration tests to fast unit tests is a long term objective (in years) and there is resistance to this idea because of the conversion cost and many developers and clients are not convinced that unit tests can replace these tests.
How Did We Adapt Agile Processes to Our Distributed Development?, Cynick Young and Hiroki Terashima, 2008
Today, many software projects are being developed by collaborating programmers working across multiple locations. Whatever the reason may be, outsourcing, organizational structure, or external collaboration, these projects often suffer from the physical separation of developing across the city, across the country, or around the world. Such distances intensify challenges such as peer communications, shared understanding between teams, and systems integration. This paper describes how three organizations adapted agile processes to overcome barriers such as multiple time zones, mixed cultures, mismatched schedules, and limited travel budget to frequently deliver successful software releases.
How Our Agile Practices Have Evolved Over the Last 8 Years, Lawrence Ludlow, 2008
Intelliware has focused exclusively on Agile since 2000, we were one of the earliest adopters of Extreme Programming (XP). Our methodology has evolved, we call our approach i-Proving, essentially Extreme Programming with elements of Lean Development added. There are many examples of how our Agile development practices have evolved over the years, but three particular areas include how we work together, knowledge management and continuous improvement.
Fast Feedback Loop: Unit Testing Strategies for Tapestry, BC Holmes, 2007
This paper focuses on how to test Tapestry pages outside of the web container to obtain better tests and better Tapestry applications.
The Application of User Stories for Strategic Planning, Lawrence Ludlow, 2007
In agile development stories are typically used to define small, independent pieces of functionality that have value for the customer. They are most often used to define requirements for future development. This paper describes a project where stories were used on a much broader scale as part of a strategic planning exercise to identify a long-term development roadmap for a new system. Stories were used not only to define what needed to be built but also to document existing functionality and gaps with current systems. This resulted in the generation of a large number of stories, which created challenges with managing and keeping the stories up to date as the project proceeded.
Data Mining, BC Holmes, 2007
Data Mining can be described, simply, as the extraction of useful information from large amounts of data. Many large companies are looking for more ways to mine their sales data, product data or even web site traffic data to find information that will allow them to become more profitable or maybe even just better at what they do.
Improving Quality Together, David Jones and Gordon Cameron, 2007
One recent change in software development is developers starting to take responsibility for the quality of their work by writing and executing automated tests. As with any new activity, there is a wide range of ways to perform this task. DevCreek collects, aggregates, and displays testing activity for individuals, teams, and the developer community as a whole. The goal is to provide individuals with global norms with which they can compare their testing. We currently have twenty person-years worth of data, with the
goal of collecting thousands more from a variety of languages, tools, and domains.
From 0 to 1,169,600 in 3 minutes: nine months of testing by the DevCreek team, David Jones, 2007
One recent change in software development is developers starting to take responsibility for the quality of their work by writing and executing automated tests. As with any new activity, there is a wide range of ways to perform this task. DevCreek helps illuminate the testing process and present a visual representation of the underlying rhythms.
This filmpresents nine months of testing and development activity on the DevCreek tool itself in an animated form. We attempt to reveal, warts and all, the effort expended running tests, the test methods exercised, and the added test methods.
Using Agile Practices in a Maintenance Environment, Steve Shaw, 2007
Who Needs a Relational Database Anyway, Kevin Allen, 2007
Who needs a relational database anyway? This is not just a theoretical question but the key question we had to consider when building our application. An assumption when architecting a new application is that you need a relational database to persist data. What if we revisited that assumption?
Using Ant To Solve Problems Posed by Frequent Deployments, Steve Shaw, 2002
Deploying a system in an agile development environment presents its own set of challenges. If it is true that development cycles are short and that every release is as small as possible, then we are going to be releasing software much more frequently than with other
methodologies. Related to this is the concept that the system is never finished, and deployments have to occur throughout the lifetime of the system. This paper examines some of the problems posed by this type of deployment environment
and suggests how Ant can be used to solve them. An appendix describes concrete solutions to problems encountered on a real-life medium-sized project.
Towards An Effective Onsite Customer Practice, Cesar Farell, Rekha Narang, Shelley Kapitan, Heather Webber, 2002
This paper describes the experience of process refinement on a long running XP project. At the end of the first release of this project, the team took the time to review and critique their current practices. The outcome of this review was a concrete set of recommendations that were put into practice in later releases to address the problems identified in the first. Of these recommendations, the ones that had the greatest impact on process improvement were those pertaining to the refinement of the onsite customer practice. This paper discusses in detail the improvements experienced as the result of a more effective onsite customer practice.