-

R: Sim.

2º Exemplo de contrato com escopo variável?

R: Desculpe-me pela demora na resposta. Em XP não existem modelos fixos para estes artefatos. Inclusive, nem sempre equipes XP chegam ao ponto de usar todos eles. Seja como for, você pode obter uma boa idéia de como criá-los no meu livro http://www.improveit.com.br/livroxp.jsp. Além disso, no que se refere especificamente ao contrato de escopo negociável, dê uma olhada em http://www.improveit.com.br/xp/contrato.jsp.

R: Sobre a questão do design simples, vejamos um pequeno exemplo. Marcelo é um desenvolvedor trabalhando em um projeto de desenvolvimento que envolve inúmeras funcionalidades a serem colocadas em um site. A próxima funcionalidade que ele irá implementar diz o seguinte:

"Mostrar no site uma lista numerada, contendo 10 livros, que encontram-se descritos em anexo".

Marcelo sabe que o cliente vive mudando de idéia, então, decide fazer uma lista flexível com a qual o cliente possa, no futuro, inserir mais livros, mudar a ordem de apresentação, alterar o conteúdo etc. Então ele modela uma tabela no banco de dados, cria um formulário para cadastrar os livros pela web, insere os livros, em seguida cria uma página que mostra o conteúdo da tabela do banco de dados. Além disso, nessa mesma página, ele inclui a possibilidade de alterar a ordenação dos livros, de acordo com os seguintes critérios:

* Por nome do livro

* Por autor

* Por preço

* Por editora

Marcelo é o máximo, certo? Não apenas é um desenvolvedor dedicado, ele também tem iniciativa e consegue antecipar os movimentos do cliente. Pena que algumas mudanças nas prioridades do cliente fizeram com que aquela funcionalidade não fosse mais necessária. Marcelo gastou uma semana de desenvolvimento, enquanto poderia ter gasto apenas uma hora se tivesse escrito a listagem diretamente em um HTML simples.

As pesquisas demonstram que 64% das funcionalidades de um sistema comercial típico nunca ou raramente são usadas (veja a Figura 1 em http://www.improveit.com.br/xp). Portanto, investir em um design além do necessário para o que o cliente solicitou costuma ser bastante perigoso, como o exemplo acima ilustrou. Para ter acesso a um exemplo verdadeiro, bem mais drástico do que o apresentado aqui, acesse a minha dissertação no link http://www.improveit.com.br/xp/ dissertacaoXP.pdf e leia da página 130 à 134.

O XP sugere que a cada iteração, o desenvolvedor se preocupe em implementar apenas o estritamente necessário para que a funcionalidade solicitada pelo usuário fique pronta. Isso é o que chamamos de design simples. Em XP os desenvolvedores evitam antecipar necessidades futuras, pois sabem que raramente acertam com exatidão sobre o que o cliente realmente vai pedir no futuro.

Essa prática é contrária ao que é feito habitualmente em desenvolvimento, chamado de BDUF (big design up front). O BDUF é exatamente o que o Marcelo fez neste exemplo, ele foi além do que precisava ser feito, ou seja, além do design que seria suficiente para a necessidade do cliente.

Na minha dissertação, você também poderá ler mais sobre design simples das páginas 91 a 98.

4º Quando a Improve It desenvolve um sistema a equipe fica no prédio do cliente ou bem próximo a ele como é recomendado no livro?

R: Sim. Às vezes ficamos em um escritório próximo ao cliente, mas na maioria das vezes trabalhamos diretamente no escritório do cliente.

No nosso caso isso é relativo. Atualmente, a maior parte do trabalho que fazemos é mentoring. Portanto, normalmente alocamos um ou mais profissionais, que atuam como mentor, os quais trabalham em conjunto com uma equipe de desenvolvimento do próprio cliente. Em alguns casos ir para o prédio do cliente pode trazer transtornos, sem dúvidas, mas em outros não. Isso naturalmente depende de caso a caso.

6º Na integração não seria mais demorado resolver as colisões do que impedir que um mesmo arquivo fosse modificado ao mesmo tempo?

R: Impedir que um mesmo arquivo seja modificado ao mesmo tempo por diferentes pessoas costuma retardar significativamente o desenvolvimento, porque é comum um desenvolvedor ter que trabalhar com inúmeros arquivos abertos ao mesmo tempo, o que eleva a possibilidade de que um ou vários destes arquivos também tenham que ser usados por outros desenvolvedores ao mesmo tempo. Essa é a alternativa mais segura para se evitar conflitos, mas é também a que mais retarda o trabalho da equipe.

Por sua vez, permitir que várias pessoas editem o mesmo arquivo ao mesmo tempo, embora permita maior agilidade para a equipe, pode gerar conflitos demorados de serem solucionados. O XP resolve isso fazendo com que as integrações ocorram com grande freqüência. Por exemplo, as pessoas tendem a integrar o que estão fazendo a cada 2h no máximo. Como o volume de trabalho em duas horas tende a ser reduzido, o potencial de conflito também se reduz bastante. Na prática, por mais surpreendente que pareça, conflitos de integração são raros em XP. Embora eu nunca tenha medido isso, acredito que tipicamente, a cada 100 integrações, provavelmente temos menos de 5 delas com conflito que necessite ser tratado pelo desenvolvedor. Ainda assim, como o escopo de trabalho é reduzido entre uma integração e outra, eventuais conflitos são resolvidos com bastante rapidez.

R: Um ambiente de desenvolvimento é algo como o Eclipse, IntelliJ, JBuilder, NetBeans etc. Ele possui inúmeras funcionalidades para edição de código, depuração, compilação etc. Mas, um dos aspectos mais marcantes destas ferramentas é a presença de um editor, que cada vez mais possui bastante inteligência, sendo capaz de compilar o código à medida em que escrevemos, coloca cores de acordo com as características do que foi escrito etc.

Uma ferramenta de build, como o Ant, é capaz de automatizar uma infinidade de atividades que, do contrário, teríamos que executar manualmente. No link http://ant.apache.org/manual/coretasklist.html você pode conhecer as inúmeras tarefas que o Ant é capaz de fazer por você, tais como compilar, executar testes de unidade, criar arquivos zip, fazer ftp, telenet, criar e remover diretórios, copiar arquivos etc.

Apenas para dar um exemplo, veja algumas das coisas que o Ant faz para nós quando precisamos atualizar o site da Improve It:

- Compila todos os arquivos

- Cria um arquivo ZIP contendo toda a estrutura do site

- Estabelece uma conexão ftp com nosso servidor

- Envia o ZIP por ftp

- Estabelece uma conexão telnet com nosso servidor

- Executa remotamente um shell script de atualização em nosso servidor, o qual faz backup da versão anterior (para o caso de recovery de falhas) e coloca os novos arquivos em produção

- Executa todos os 940 testes contra os novos arquivos colocados em produção

R: Ele é capaz de executá-los sozinho, sem a presença do Ant. O JUnit já vem integrado ao Eclipse por default

R: Na verdade, nem uma coisa nem outra. Um framework normalmente é um *conjunto* de classes que tende a ser reutilizado em inúmeros projetos diferentes, por ser genérico e fornecer funcionalidades freqüentemente necessárias em diferentes projetos. Por exemplo, quem programa em Java costuma usar o Hibernate, que é um framework para facilitar o acesso a bancos de dados. Tem também o Struts para ajudar no desenvolvimento de aplicações web e o próprio JUnit que ajuda na criação e execução de testes unitários. Aliás, o DUnit é um exemplo de framework desenvolvido para Delphi.

R: Acho que houve um equívoco. A reutilização de código é extremamente recomendável e até mesmo essencial para a utilização do Extreme Programming. Em XP há uma enorme preocupação no sentido de não duplicar código, o que é conseguido, naturalmente, com a reutilização de código tanto quanto possível.

R: Não. Quando me refiro a reutilizar código, não estou pensando em nenhuma hipótese na temível "técnica" de copiar e colar. Essa é uma forma de duplicar código, não de reutilizar.

Reutilizar significa escrever o código em um único lugar e permitir que ele seja acessado diversas vezes, por inúmeros clientes. É possível reutilizar código de várias formas, tais como se usando constantes, variáveis, métodos, superclasses etc.

R: Ainda tímida, já que em grande parte das organizações ainda é desconhecido. Porém isso vem mudando. Há uns três anos pouquíssima gente tinha sequer ouvido falar de XP no Brasil. Hoje em dia muita gente até já ouviu falar, mas ainda há poucas experiências. Em todo o caso, já existe uma séria de projetos usando e a tendência, na minha opinião, é que isso evolua rapidamente nos próximos anos, da mesma forma que vem ocorrendo no exterior.