FDV Methodology

How to contract:
It can be a "Fix Price" or a "Time & Materials" project, planning can be different, but we'll always use the next documents:

• NDA to ensure commitment to maintain the confidentiality code, clients and the stuff involved in the project.

• Proposal or contract depending on the formality of the agreement, always highlighting responsibilities, calendar, range, price, payment plan with the technology and methodology used.

• Communication Plan for the project in where roles and responsibilities are explicitly defined, including commercial (account manager) and administrative.

Fix Price
Projects done this way must consider a functional risk, defining in advance the Change Management Process and all the risks inherent to the building software process that needs to be assessed.

Every project started this way will have assigned hours for the coordination roles (Tech Leader, Team Leader, Scrum Master depending on the size), functional analysts and quality control personnel as well as development.

Plan approval must be defined at the time of signing the contract or at least validated between the parties and established in the contract or proposal.

T & M
FDV ensures through clearly defined processes and mechanisms documented to give visibility to the customer's use of time from the team. The client will receive a daily or weekly report with the allocation of the hours used from their staff giving full transparency and commitment to the proper use of every minute spent by the customer.

Project execution
During the execution the project will be driven with Scrum. The team will arrange the time for Daily Meetings and Sprint planning. If it's necessary, Scrum of Scrums meetings can be arrange for the interaction between different work teams.
Weekly meetings or Sprints closure (review o retrospective meetings) can be conducted either in the offices of the client or in FDV, as agreed during planning.

One of the fundamental activities that must been taken in account between Sprints is bugfixing. We propose to perform the evaluation and assessment of bugs found in the system between Sprints and including them as an activity over the next Sprint.

On the other side, given that the backlog may be open to changes in scope or features included, we propose a dynamic Change Management. In this case the initial Backlog defined at contract signing was only a framework for the initial budget compromise. As the project goes on, the backlog changes and features are added or removed. The only strict control against the contract is that it shall not exceed the agreed budget, regardless of the features included. Thus, the exchange of features is fully open and avoids the complex and strict processes of change management.

We propose the use of Sprint planning meeting as a check on the performance of the development team, business team or interaction with other teams. This gives us the opportunity to take corrective actions early in the project.

Acceptance of deliveries
Each Sprint will include a functional testing activity and bugfixing. That will take approximately 3 weeks Sprints where a part of the last week will be used for doing the functional testing and bugfixing. At the same time, the releases must be subject to regression testing and review and acceptance by the functional leaders (Product Owner). These activities can be planned in parallel with the development of other Sprints to not affect the development speed of new features.

Contract closure
Once all the Sprints are finished and once the corresponding deliveries are done, we will close the contract. An evaluation of results and the overall process. Will review the status of backlog and raise the next steps in driving new development projects with the same methodology.

General consideration

Discovery
Just in case that at first the initial Blacklog is not clear, we can carry out a Discovery stage. For it, a functional analyst from FDV work side by side with the Product Owner and Key Users in the definition of initial features in order to establish an initial definition of the product to build.

Catch-up
It is reasonable that during the first sprints or even before starting development, we have to consider training in all technological aspects involved in private business or customer.
In that case and always betting on long-term relationships, we take a position of cost sharing: FDV is committed to assign the resources required to take courses or formal training sessions prior to the beginning of work, and the client will accept that there is a learning curve and resource efficiency will affect the first Sprints.
During this catch-up period, the client will place at FDV's reach the technical and functional resources necessary to solve any concern or inconvenience efficiently.

Functional analysis
While agile methods are focused on the physical proximity of team members, including the Key Users or any other representative functional, we are aware that in many cases, especially in outsourcing projects, it is very difficult to comply and permanent.

To cover this gap, we proposed to include specific functional analysis activities throughout the project and will be covered by any team member. These activities ideally should be a sprint out of step with the development, thereby ensuring that is the greatest amount of information available to the developer when building functionality.

These specifications can be documented in the form of User Stories, mockups or format that is most convenient.

Development tools and process suport
Actually, in FDV we use tools that are proposed as the technological base of any development. Similarly, the final decision on the use of these or other tools run by the client according to their particular needs.

IDE of work
We will work with Eclipse or IntelliJ Idea that are two of integrated development environments most popular and effective market.

Continues integration
Continues integration is a practice that helps finding many problems before even the code is tested. This tool downloads the last version, executes a compilation and integration of the code and executes the unit tests available.
If something goes wrong, is reported to the team so that they can take corrective action. The same can identify and correct problems that arise in a shorter time than if they were detected at later stages of the development process.

This practice is also working on improving the quality of the final product.

Continues integration is done using the Atlassian's Bamboo. This is integrated with Sonar and Maven2, brings added value to the development process because it allows to execute tasks of source code analysis to ensure the standards defined by the customer.

Code Quality Analysis
This is a practice in charge of reinforce good programming and some design software. Help to improve its monitoring of the "coding conventions" and as many rules and checks that are not followed, could lead to future bugs in the application and observed that not only enhance the quality of the final product, but to simplify the processes of induction of new team members and changes in cross-code.

We use Apache Sonar to do this work, which is integrated with Maven2 and Bamboo being the coordinating its execution during the build process.

Regression Tests
From FDV we promote the use of automated regression tests. For these developments we propose to use recently adopted Cacique, which are doing little by little extended to all web development carried out by FDV. This tool was developed by staff of MercadoLibre (FDV client) and was recently released as Open Source.

Time Tracking
In FDV we have developed Project Guide to optimize the monitoring of our teams, knowing their daily efforts, measuring the work environment of each team and project, and strengthen the burden of knowledge.

Using a virtual assistant via GTalk, collection of information is made daily in a timely manner. In turn, not only allows us to record the track of hours, but we have incorporated elements of Knowledge Management and Mood Management.