Apesar de presença (justaposição) ser uma das principais recomendações da metodologia Ágil, mais e mais projetos são executados onde os times são distribuídos. Safari Asad iniciou uma interessante discussão no grupo de desenvolvimento Scrum para falar sobre um projeto em crise, em que não há somente o cliente remoto mas também tem desenvolvedores remotos.
Asad, descreve a situação como se ela se degradasse do ruim para o pior. Os problemas começaram quando o time foi movido do ambiente do cliente devido a restrições de orçamento. De acordo com Asad, desde então eles tentam entregar o software mas o cliente continua apresentando uma grande lista de erros e defeitos reabertos. Asad mencionou que um dos maiores problemas no projeto foi o desenvolvimento remoto. Todos os seu desenvolvedores estavam trabalhando de casa e ele não tem certeza se os defeitos em aberto foram resolvidos a cada novo código disponibilizado.
Quando o cliente enviou a lista de defeitos eu a enviei para os desenvolvedores. Os desenvolvedores resolveram (ou ao menos aparentemente) seus defeitos e devolveram um novo código fonte para mim. Eu compilei o código retornado e criei uma versão corrigida.
Apesar de, isso ter sido estabelecido durante a discussão que o time ou não estava seguindo a metodologia Ágil ou a estava seguindo de forma errada, Asad gostaria de ter sugestões de como ele poderia salvar o projeto.
Mark sugeriu que uma maneira para ele salvar o projeto poderia ser escrevendo um conjunto de testes de aceite e executá-los antes de liberar uma versão para o cliente. Isso teria muita dependência técnica no sistema mas seria uma forma perfeita de garantir que o software que está sendo entregue está com a qualidade exigida.
De acordo com Roy Morien, um dos problemas fundamentais nessa situação parecer ser a responsabilidade de testar o software e assegurar que os problemas foram resolvidos. Se os desenvolvedores não eram os responsáveis pelos testes, então eles poderiam devolver um código que não tem nenhuma garantia que está corrigido.
Se você é o responsável pelos testes, então os desenvolvedores não tem nenhum incentivo real de assegurar de que eles trabalharam corretamente. Eles podem, aparentemente, confiar em você para descobrir os erros e simplesmente dizer ‘Droga, eu pensei que estava funcionando. Iriei corrigir isso amanhã!’. Desde quando eles são pagos pelo trabalho de corrigir erros?
Roy também sugeriu que Asad deve preparar uma nova versão do software, testá-lo e demonstrá-lo no ambiente do cliente para ter uma resposta válida e imediata. Bachan Anand enfatizou a importância da comunicação honesta. De acordo com ele, o time de agora em diante tem que agir de maneira positiva caso eles queiram salvar o projeto.
O que aconteceu aconteceu, a única forma eficaz que consigo visualizar é aceitar o que aconteceu e procurar uma solução. Por isso, o primeiro passo seria apresentar uma solução para salvar esse projeto o que é aceitável acima de tudo para o cliente, depois comunicá-lo claramente sobre a situação que o projeto está agora.
Pete Ruth listou uma compreensiva estratégia para o salvar o projeto. De acordo com Pete, o cliente necessitaria ser convencido de que o software pode ser corrigido de uma forma rápida e com baixo custo. Ele sugeriu a seguinte lista de técnicasm estas que foram muito úteis para ele no passado:
- Elencar um "usuário chave" no ambiente do cliente.
- Disponibilizar um meio de acesso remoto, assim você pode ver o que está acontecendo no ambiente do cliente.
- Considere modificar seu software para incluir funções de testes especiais que podem ser executadas via atalhos. Isso ajudaria em identificar problemas caso o acesso remoto não estiver disponível.
- Considere usar acesso remoto entre você e seus desenvolvedores remotos.
- Considere modularizar seu software para isolar funcionalidades importantes.
- Minimize a complexidade do seu software através de reuso sempre que possível.
Jeff sugeriu que colocar tudo sobre clientes e desenvolvedores remotos é simplesmente uma forma de achar desculpas. De acordo com ele, ele fez diversos projetos de forma distribuída e tais projetos tiveram excelentes resultados. A solução real é o comprometimento para o sucesso tanto do time quanto da organização.
Assim, a maioria dos membros da discussão não viram o desenvolvimento distribuído como o problema. Muitos deles foram da opinião que ter um cliente remoto ou fazer um desenvolvimento remoto não é um problema. O medo do desenvolvimento distribuído foi um sintoma de uma execução incorreta. A chave para o sucesso em um projeto remoto é ampliar o uso correto das práticas ágeis com as ferramentas corretas e ter um compromisso com o sucesso.