domingo, 15 de novembro de 2009

XP - Boas Práticas (parte 2)

Este é o quinto artigo de uma série de post sobre "XP - Extreme Programming". Se assim desejar, leia os posts anterior a este:


  • Testes de aceitação
Uma das preocupações da XP é a qualidade do código produzido e nada garante tão bem que um código esteja funcionando corretamente do que um teste. Por isso, os programadores XP escrevem testes automatizados antes mesmos de codificar uma funcionalidade. Dessa forma eles aprofundam o conhecimento da funcionalidade em questão, além de poder sempre contar com testes que validem o sistema em qualquer momento do projeto.


  • Código coletivo
Uma equipe XP trabalha com a prática de propriedade coletiva do código, ou seja, cada membro da equipe pode trabalhar em qualquer parte do sistema a qualquer momento. Caso um desenvolvedor encontre alguma coisa que possa ser melhorada, ele não precisa solicitar que outra pessoa o faça por não ser o “dono” daquele código. Essa prática permite que o sistema evolua mantendo o código o mais simples possível, pois sempre que um membro encontra algo confuso, ele tem a liberdade de aplicar o refactoring.


  • Código padronizado
Como todos os desenvolvedores têm acesso a todo o código, é necessário que se estabeleça um padrão de codificação para tornar o sistema homogêneo e permitir que qualquer um compreenda facilmente o código e não tenha dificuldades para manipulá-lo caso seja necessário.


  • Integração continua
Integração continua é a prática de construir o software várias vezes por dia, o que possibilita uma constante sincronia entre os desenvolvedores. Esta prática é aconselhada para evitar surpresas e assegurar que o sistema esteja sempre funcionando de forma harmoniosa a cada nova integração.


  • Reunião diária
Equipes XP sempre começam um dia de trabalho com uma reunião de no máximo 10 minutos, pois é nesse momento que todos da equipe têm oportunidade de comentar rapidamente sobre o que realizou no dia anterior, e assim conhecer o andamento geral do projeto. Ainda nessa reunião, a equipe aproveita para priorizar as atividades que cada membro da equipe realizará ao longo do dia.


  • Ritmo sustentável
Ritmo sustentável consiste em trabalhar respeitando os limites físicos e demonstrando respeito pela individualidade de cada membro da equipe. Dessa forma, para que uma equipe seja criativa e produza software com qualidade, ela precisa estar saudável do ponto de vista físico e mental. Para que isso acontece, a XP recomenda que a carga horária de trabalho não ultrapasse as 8 horas diárias e 40 horas semanais.

segunda-feira, 9 de novembro de 2009

9º Congresso de Iniciação Científica


O CONIC-SEMESP 2009 (Congresso de Iniciação Científica) já é considerado o maior congresso de iniciação científica do Brasil e este ano será realizado com número recorde de participantes nos dias 13 e 14 de novembro. Organizado pelo SEMESP - Sindicato das Entidades Mantenedoras de Estabelecimentos de Ensino Superior no Estado de São Paulo - o evento será sediado na FMU - Campus Liberdade situada na Av. Liberdade, 749 - Bairro: Liberdade, São Paulo - SP.

O evento é voltado a estudantes de graduação de instituições públicas e particulares do Brasil, visando identificar talentos e estimular a transformação de idéias em realidade, como fator determinante ao exercício da criatividade.


Depois de estudar muito para minha monografia e postar aqui no blog alguns textos sobre a metodologia Extreme Programming, estarei no CONIC 2009 no dia 13/11 às 15:40 apresentando na sala 15 o meu artigo "A Metodologia XP e um Comparativo na Gestão de Riscos entre o Desenvolvimento Tradicional e o Desenvolvimento Ágil".
Interessados pelo assunto... aguardo vocês!

Mais informações sobre o evento: www.semesp.org.br

quarta-feira, 4 de novembro de 2009

XP - Boas práticas (parte 1)

Este é o quarto artigo de uma série de post sobre "XP - Extreme Programming". Se assim desejar, leia os posts anterior a este:

As boas práticas da XP são um conjunto de atividades que as equipes de desenvolvimento de XP utilizam enquanto produzem softwares, elas devem ser aplicadas em conjunto, pois os pontos fortes de uma, compensam os pontos fracos de outras.

  • Cliente presente
Para aplicar os principais valores da XP é essencial que o cliente participe ativamente do desenvolvimento. Sua presença viabiliza a simplicidade dos processos, facilita a comunicação com os desenvolvedores e permite um ciclo continuo e rápido de feedback.

  • Releases
Release é um conjunto de funcionalidades que representa uma pequena versão do sistema. Esta versão é colocada em produção para que o cliente possa usufruir do investimento no software ao mesmo tempo em que avalia e retorna um feedback para os desenvolvedores sobre a release.

  • Jogo do Planejamento
No início de cada release o cliente se reúne com a equipe de desenvolvimento e é estimulado a escrever em pequenos cartões as funcionalidades que deseja no sistema. Após escrevê-las, os desenvolvedores estimam o custo de cada funcionalidade e em seguida pedem para o cliente definir o nível de prioridade de cada funcionalidade descrita.

  • Metáfora
As metáforas têm o poder de transmitir idéias complexas de forma simples e clara. Por isso, a XP as utilizam para criar uma visão comum do projeto entre cliente e desenvolvedores.

  • Programação em par
Na programação em par dois desenvolvedores sentam-se em um único computador para codificar uma determinada funcionalidade. O desenvolvedor com menor experiência tem como responsabilidade gerar o código e conduzir a programação a partir do teclado, enquanto o outro desenvolvedor com maior experiência inspeciona o código constantemente a procura de erros e defeitos, além de pensar estrategicamente em soluções mais simples para o código.


  • Refactoring
Refactoring é o processo de reorganizar o código fonte de um software para melhorar sua qualidade interna, facilitar a leitura do código e diminuir o tempo gasto com manutenção, sem, contudo prejudicar o desempenho e alterar seu comportamento externo. Aplicado em sistemas orientados a objetos, a técnica é fundamental para tornar o código mais legível e encontrar facilmente erros em algoritmos mal escritos.

Leia também o próximo dessa série "XP - Extreme Programming"
 
;