We are a multidisciplinary team: developers, analysts, user interaction designer and researcher working on a common goal.
We learn from each other, we help each other to fulfill their potential.
We are a team! So we have rules further than process.
The tools are important, but we are convinced that they are the people to solve the problems with the way they think, interact, collaborate.
We believe in that which supports the agile manifesto and make our own its principles.
To satisfy our customers and ourselves, producing high quality software, in everyday life we practice a series of activities and processes
with the help of some tools
It ‘a process in which software development is preceded by the preparation of the test machines. These tests can identify with precision the specific code, and thus its behavior according to the situations in which it will be subjected. http://it.wikipedia.org/wiki/Test_Driven_Development
The process is broken down on the repetition of short courses of development and testing:
It ‘a development technique that involves two programmers working together on a single task. This technique allows you to maintain
a high level of code quality as well as a broad perspective of problem solving. The pair programming can dramatically reduce defects or
interventions on the code refactoring lowering total cost of development and maintenance.
It ‘a practice for software development where the members of a development team integrate their daily work. Each integration is subjected to build and automated tests that ensure the rapid detection of integration errors, resulting in increased productivity.
The code review process has the purpose of identifying defects, problems or inefficiencies within the source code. It represents one of the most important steps for application development and improves the quality and maintainability of the code. It also helps the team to grow, thanks to feedback constantly communicated.
The code review does not guarantee the resolution of all problems but catching most of them in the initial stage, when it is less expensive to solve them.
Allows you to determine the proportion of source code covered by automated tests. A low score could mean probably a low quality of the code, even if a high score is not necessarily comparable to a high code quality.