Moving past quick scripts, ElasticDiscovery creates applications empowering client’s to automate their processes.
We follow the 12 principles of Agile to satisfy our clients with early and continuous delivery of valuable software.
Our project management and source code is shared online at every stage to help deliver on these principles. Our software is developed following many of the practices of Extreme Programming:
Does discovery require extreme programming?
We think so, clients have great ideas about they want to accomplish. Reducing those ideas to technical requirements could end a project before it begins. We strive to minimize up-front planning and maximize flexibility. Our practices allows us to define requirements as we develop.
Test-first programming helps define requirements and specify the expected results. Evaluating the results of the complex functions required in discovery can be challenging. We run every test on every build of our software, to insure that results only change when we wanted them to.
If you want to know more about the extreme programming practices we follow, just read below or contact us.
Stories
Describe what the product should do in terms meaningful to customers and users. These stories are intended to be short descriptions of things users want to be able to do with the product that can be used for planning and serve as reminders for more detailed conversations when the team gets around to realizing that particular story.
Weekly Cycle
The Weekly Cycle is synonymous to an iteration. In the case of XP, the team meets on the first day of the week to reflect on progress to date, the customer picks the stories they would like delivered in that week, and the team determines how they will approach those stories. The goal by the end of the week is to have running tested features that realize the selected stories.
The intent behind the time boxed delivery period is to produce something to show to the customer for feedback.
Quarterly Cycle
The Quarterly Cycle is synonymous to a release. The purpose is to keep the detailed work of each weekly cycle in context of the overall project. The customer lays out the overall plan for the team in terms of features desired within a particular quarter, which provides the team with a view of the forest while they are in the trees, and it also helps the customer to work with other stakeholders who may need some idea of when features will be available.
Remember when planning a quarterly cycle the information about any particular story is at a relatively high level, the order of story delivery within a Quarterly Cycle can change and the stories included in the Quarterly Cycle may change. If you are able to revisit the plan on a weekly basis following each weekly cycle, you can keep everyone informed as soon as those changes become apparent to keep surprises to a minimum.
Ten-Minute Build
The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes. The founders of XP suggested a 10 minute time frame because if a team has a build that takes longer than that, it is less likely to be run on a frequent basis, thus introducing longer time between errors.
This practice encourages your team to automate your build process so that you are more likely to do it on a regular basis and to use that automated build process to run all of your tests.
This practice supports the practice of Continuous Integration and is supported by the practice of Test First Development.
Continuous Integration
Continuous Integration is a practice where code changes are immediately tested when they are added to a larger code base. The benefit of this practice is you can catch and fix integration issues sooner.
Most teams dread the code integration step because of the inherent discovery of conflicts and issues that result. Most teams take the approach “If it hurts, avoid it as long as possible”.
Practitioners of XP suggest “if it hurts, do it more often”.
The reasoning behind that approach is that if you experience problems every time you integrate code, and it takes a while to find where the problems are, perhaps you should integrate more often so that if there are problems, they are much easier to find because there are fewer changes incorporated into the build.
This practice requires some extra discipline and is highly dependent on Ten Minute Build and Test First Development.
Test-First Programming
Instead of following the normal path of:
develop code -> write tests -> run tests
The practice of Test-First Programming follows the path of:
Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat
As with Continuous Integration, Test-First Programming reduces the feedback cycle for developers to identify and resolve issues, thereby decreasing the number of bugs that get introduced into production.
Incremental Design
The practice of Incremental Design suggests that you do a little bit of work up front to understand the proper breadth-wise perspective of the system design, and then dive into the details of a particular aspect of that design when you deliver specific features. This approach reduces the cost of changes and allows you to make design decisions when necessary based on the most current information available.
