FDV Metodología

Trabalhamos com projetos Fix Price e Time & Materials. O planejamento de todo o projeto pode chegar a ser diferente em cada caso, mas os seguintes documentos serão sempre utilizados:

1) NNDA que garanta o compromisso em manter a confidencialidade sobre código, clientes e pessoal envolvido no projeto.

2) Proposta ou Contrato, segundo a formalidade do acordo, sempre definindo responsabilidades, calendário, alcance, preço, plano de pagamentos junto com a tecnologia e a metodologia a utilizar.

3) Plano de Comunicações do projeto no qual são definidos explicitamente os papéis e as responsabilidades, inclusive comerciais (account manager) e de pagamentos por parte do cliente.

Fix Price
Os projetos trabalhados dentro desta modalidade deverão sempre contemplar um risco funcional, já que inevitavelmente e por mais que o processo de administração de mudanças seja definido com antecipação, existem riscos inerentes à construção de software.
Todos os projetos contratados nesta modalidade deverão ter horas para os papéis de coordenação, definições funcionais e controle da qualidade, além de desenvolvimento. A FDV não trabalha com equipes incompletas nesta modalidade.
O plano de aprovações deve estar definido na hora de assinar o contrato ou pelo menos validado entre as partes e escrito parcialmente no contrato/proposta.

Time & Materials
A FDV garante, por meio de processos definidos e claramente documentados, os mecanismos para dar visibilidade ao cliente sobre a utilização do tempo de parte da equipe.
O cliente recebe um relatório diário com as atribuições e a utilização das horas por parte da sua equipe de trabalho, garantindo a transparência e o compromisso com o correto uso de cada minuto investido por parte do cliente.

Execução do projeto
Durante a execução, o projeto será levado adiante como qualquer outro projeto Scrum remoto. A equipe de trabalho entrará em acordo sobre o horário para as Daily Meetings e o planejamento de Sprints. Se for necessário, também poderão ser coordenadas reuniões do tipo Scrum of Scrums para a interação com outras equipes de trabalho.

As reuniões semanais ou de fechamento de Sprints (review ou retrospective meetings) podem ser realizadas de forma presencial, no escritório do cliente (o mais recomendável) ou na FDV, conforme o combinado durante a execução.
Uma das atividades fundamentais que devem ser levadas em consideração entre Sprints é o bugfixing. Para isso se propõe entre Sprints realizar a avaliação e estimação de bugs que se encontram no sistema, incluído como mais uma atividade do seguinte Sprint.

Por outro lado, dado que o Backlog pode estar aberto a mudanças de alcance ou features incluídos, propomos uma gestão de mudanças dinâmica. Neste caso, o Backlog inicial utilizado para montar o contrato foi apenas um marco de referência para comprometer o orçamento inicial. À medida que o projeto avança, o Backlog muda, são incluídos e retirados features.
O único controle estrito sobre o contrato será o de não ultrapassar o orçamento combinado, independentemente dos features incluídos. Desta forma o controle de mudanças fica totalmente aberto e os processos complexos de gestão de mudanças são evitados.

Propomos a utilização da reunião de planejamento de Sprints como ponto de verificação sobre a performance da equipe de desenvolvimento, a equipe do negócio ou a interação com outras equipes. Desta forma, as providências corretivas correspondentes poderão ser tomadas previamente.

Aceitação de entregas
Cada Sprint terá incluída uma atividade de testing funcional e bugfixing. Isso é pensado com Sprints de 3 semanas, no qual parte da última é utilizada para fazer o testing funcional e bugfixing. Ao mesmo tempo, os releases deveriam estar sujeitos a testes de regressão e serem revisados e aceitos pelos líderes funcionais (Produto Owner). Estas atividades podem ser planejadas paralelamente ao desenvolvimento de outros Sprints para que a velocidade de desenvolvimento de novas funcionalidades não se veja prejudicada.

Fechamento do contrato
Finalizados los Sprints acordados inicialmente y una vez realizados los delivery correspondientes, se procederá a dar por cerrado el contrato. Se realizará una evaluación de resultados y del proceso en general. Se revisará el estado del Backlog y se plantearán los próximos pasos impulsando nuevos proyectos de desarrollo con esta misma metodología.

Consideraciones Generales

- Discovery
Caso em uma primeira instância o Backlog inicial não fique claro, pode ser realizada uma etapa de Discovery. Durante esta etapa, um analista funcional da FDV trabalhará em conjunto com o Product Owner e os Key Users na definição de features iniciais com o objetivo de estabelecer uma primeira definição do produto a construir.
- Catch-up
É razoável que durante os primeiros Sprints - ou inclusive antes de começar o desenvolvimento - tenhamos que considerar atividades de capacitação de todos os envolvidos nos aspectos tecnológicos ou de negócio particulares ao cliente.
Neste caso, e sempre apostando nas relações de longo prazo, tomamos uma postura de custo compartilhado: a FDV se compromete a colocar à disposição os recursos necessários para cursos ou jornadas de capacitação formais prévios ao começo do trabalho, enquanto que o cliente aceitará que existe uma curva de aprendizagem e rendimento dos recursos que afetará os primeiros Sprints.
Durante este período de catch-up, o cliente colocará à disposição da FDV os recursos técnicos e funcionais necessários para resolver qualquer inquietação ou inconveniente de modo eficiente.

Análise funcional
Apesar de que as metodologias ágeis estejam focadas na proximidade física dos integrantes da equipe, incluindo os Key Users ou qualquer outro representante funcional, somos conscientes de que, em muitos casos, especialmente nos projetos de terceirização, é muito difícil cumpri-lo de forma permanente.
Para cobrir este gap, propomos incluir atividades de análise funcional específicas ao longo do projeto e que serão cobertas por algum integrante da equipe. Estas atividades, idealmente, deveriam estar um Sprint defasadas em relação às de desenvolvimento, e assim garantir que sejam encontradas a maior quantidade de informação disponível para o desenvolvedor no momento de construir uma funcionalidade.
Estas especificações poderão ser documentadas em forma de User Stories, MockUps ou no formato considerado mais conveniente.

Ferramentas de desenvolvimento e suporte ao processo
Atualmente, na FDV são utilizadas ferramentas, propostas como base tecnológica de qualquer desenvolvimento. Da mesma forma, a decisão final da utilização destas ou de outras ferramentas será responsabilidade do cliente, de acordo com as suas necessidades particulares.

IDE de trabalho
Trabalhamos com Eclipse ou IntelliJ Idea, dois dos ambientes integrados de desenvolvimento mais populares e eficazes do mercado..

Ferramenta de build
Os projetos são desenvolvidos de maneira agnóstica às ferramentas de desenvolvimento/Guild, de modo de que o código fonte não fique preso a elas, garantindo a portabilidade do projeto a outras possíveis equipes de trabalho que utilizem outras ferramentas.
A ferramenta escolhida pela FDVS é a Apache Maven 2, utilizada para realizar os builds da aplicação, controle de dependências e inclusive para auto-documentação..

Versionamento
A Subversion é utilizada como ferramenta de versionamento (SCM) e desenvolvimento colaborativo, o que permite ter um controle sobre o código fonte, documentação e qualquer outro artefato, garantindo o acompanhamento e controle de versões.

Base de conhecimento
É fundamental contar com uma base de conhecimento na qual a equipe de desenvolvimento possa plasmar a informação gerada como qualquer outro tipo de documentação técnica, funcional, etc. que ajude na documentação do projeto e na colaboração entre pares. Para isso, a FDVS conta com a ferramenta Confluence (wiki da Atlassian) e a integra com sua solução Project Guide (link) de forma tal a otimizar a geração e difusão do conhecimento.

Registro de incidências interno
O controle de incidências durante a vida de um projeto é feito mediante a JIRA. Esta ferramenta permite fazer o acompanhamento de qualquer tipo de atividade (tarefa de desenvolvimento, bugs, melhorias, etc.). Ao mesmo tempo, para os projetos ágeis conta com o GrassHopper, um plugin que inclui características particulares de um projeto Scrum (Epics, Stories, um Planning Board e gráficos de BurnOut, entre outras características).

Integração contínua
A integração contínua é uma prática que ajuda a detectar com antecedência possíveis problemas no código fonte armazenado na Subversion, já que periodicamente, a ferramenta de integração descarrega as atualizações, executa uma compilação do código e a execução dos tests unitários que se encontram disponíveis. Se alguma coisa falha, a equipe de trabalho é notificada para que possa tomar uma providência corretiva. O mesmo poderá identificar e corrigir os problemas surgidos em um menor tempo do que se fossem detectados em etapas posteriores ao processo de desenvolvimento..

Esta prática também colabora em melhorar a qualidade do produto final.
A integração contínua é realizada utilizando a ferramenta Bamboo (da Atlassian). A mesma se integra com a Maven2 e com a Sonar aportando um interessante valor agregado ao processo de desenvolvimento, já que permite executar tarefas de análise de código fonte que garantam os padrões definidos pelo cliente.

Análise de qualidade do código
Esta é uma prática encarregada de reforçar boas práticas de programação e algumas de desenvolvimento de software. Ajuda a reforçar o acompanhamento das “coding conventions” e outras tantas regras e verificações que, se não fossem feitas, poderiam gerar futuros bugs na aplicação e que se respeitadas, não somente favorecem a qualidade do produto final, mas também simplificam os processos de indução de novos membros à equipe e as modificações do código de forma cruzada.
Utilizamos a Apache Sonar para realizar esta tarefa, que se integra com a Maven2 e Bamboo, sendo este o que coordena sua execução durante o processo de build.

Tests de regressão
Na FDV impulsionamos a utilização de tests de regressão automáticos. Para estes desenvolvimentos propomos utilizar o Cacique recentemente adotado, e que, pouco a pouco, vamos estendendo a todos os desenvolvimentos web da FDV. Esta ferramenta foi desenvolvida pela equipe do MercadoLibre (cliente da FDV, versão argentina do Mercado Livre) e recentemente liberada em forma Open Source.

Time Tracking
Na FDV desenvolvemos Project Guide, com o objetivo de otimizar o acompanhamento das nossas equipes de trabalho, conhecendo seus esforços diários, medindo o clima de trabalho de cada equipe e projeto, além de fortalecer o compartilhamento de conhecimentos adquiridos.

Mediante a utilização de um assistente virtual via GTalk, a coleta da informações é realizada diariamente de forma oportuna. Isso nos permite não apenas registrar o acompanhamento de horas, mas também incorporar elementos de Knowledge Management e Mood Management.