Our Process

We working with two types of process depending of the project:

SCRUM
Is a “process skeleton,” which contains sets of practices and predefined roles. The main roles in Scrum are:
the “ScrumMaster”, who maintains the processes (typically in lieu of a project manager)
the “Product Owner”, who represents the stakeholders
the “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.
During each “sprint”, typically a two to four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product “backlog,” which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed. The team then determines how much of this they can commit to complete during the next sprint.[1] During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
There are several implementations of systems for managing the Scrum process, which range from yellow stickers and whiteboards, to software packages. One of Scrum’s biggest advantages is that it is very easy to learn and requires little effort to start using.

TSP (Team Software Process)
In combination with the Personal Software Process (PSP), the Team Software Process (TSP) provides a defined operational process framework that is designed to help teams of managers and engineers organize and produce large-scale software projects of sizes beyond several thousands lines of code (KLOC). The TSP is intended to improve the levels of quality and productivity of a team’s software development project, in order to help them better meet the cost and schedule commitments of developing a software system.
The initial version of the TSP was developed by Watts Humphrey in 1996, and the Technical Report for TSP was published in November 2000 and sponsored by the U.S. Department of Defense. The book of Watts Humphrey, “Introduction to the Team Software Process” (Addison Wesley Professional, Massachusetts, 1999), presents the TSP in detail and, in particular, focuses on the process of building a software production team, establishing team goals, distributing team roles, and other teamwork-related activities.