Extreme Programming - Dicas: Parte 3 de 4

Extreme Programming – Dicas: Parte 3 de 4

Extreme Programming - Dicas: Parte 3 de 4Quase chegando ao fim da nossa sequencia de dicas sobre Extreme Programming, chegou a hora de se aprofundar no XP.

Princípios

Os princípios que formam a essência do XP são baseados nos valores já citados e existem a fim de fomentar decisões em um projeto de desenvolvimento de software. Os princípios são mais concretos que valores e mais facilmente traduzido em questões práticas:

Feedback

Extreme Programming enxerga o feedback como realmente eficaz quando aplicado no momento em que é crítico ter acesso a informações, ou seja, durante o desenvolvimento. Diferentemente de outras metodologias, no XP o contato com o cliente é e deve ser feito em iterações mais frequentes. O cliente tem uma visão clara do sistema que está sendo desenvolvido.
Carreiras Site Campus

Incorporando a Simplicidade

Incorporar a simplicidade é tratar qualquer problema como se a solução fosse extremamente simples. Relembra o Keep it Simple, Stupid (KISS). As metodologias tradicionais tentam prever o futuro e buscam programar para reutilizar. O XP não admite este conceito.

Extreme Programming - Dicas: Parte 3 de 4

Fazer mudanças radicais em uma só vez não funciona. Por isso é que XP trabalha com mudanças incrementais.

Abraçar a mudança

Este princípio prega que não se deve trabalhar contra a mudança, mas trabalhar com ela, como parte do processo. Se em uma reunião com o cliente ficar definido que o sistema terá de ser alterado drasticamente, os programadores devem imediatamente aceitar a ideia e planejar o trabalho.

Papéis e Práticas do XP

Membros de uma mesma equipe podem representar mais de um dos papéis a serem listados a seguir. O projeto e o desenvolvimento, assim como a modelagem, são feitos por todos e a todo instante. Diferente dos métodos tradicionais, onde encontramos papéis rígidos, o analista de sistemas e o engenheiro de software são incorporados por todos os membros da equipe. É preciso compreender os papéis sugeridos pela metodologia para melhor compreender a aplicação de suas práticas.

  • Customer (cliente) – O cliente participa de maneira ativa do projeto. Ele é quem fornece o feedback mais importante do desenvolvimento. É ele, também, quem testa o software através de acceptance tests e descreve os requisitos e o escopo de cada iteração (preferencialmente). Além disso, é sua a aprovação e a aceitação do resultado de cada iteração. É comum haver mais de um customer, sendo um deles o responsável exclusivo pelos acceptance tests, sendo conhecido como o acceptance tester.
  • Programmer (programador) – Responsável pela implementação do sistema, assim como por fornecer estimativas para user stories, definir engeneering tasks, testar o sistema (através de unit tests), implementar o programa e garantir que o mesmo passará por todos os testes e será aprovado.
  • Coach (técnico/gerente) – É quem motiva a equipe e gerencia o trabalho. Garante que a equipe seguirá os princípios, valores e práticas do Extreme Programming durante o ciclo de vida do desenvolvimento. Ele é o responsável pela negociação do escopo e das iterações com o cliente.
  • Tracker (batedor) –  Monitora e acompanha o desenvolvimento do projeto a fim de medir o andamento de tarefas sendo implementadas, assim como é o responsável pelas métricas. Ele deve publicar e coletar os dados para toda a equipe e repassar qualquer problema imediatamente para o Coach. Este papel é geralmente alternado entre os membros da equipe e requer que o membro que execute esta função não esteja intimamente relacionado com a implementação do sistema.

Release Plan

O Release Plan é o plano de desenvolvimento gerado a partir das sessões de planning game. Neste plano estão definidas quais as stories farão parte de cada iteração dentro da release, qual o desenvolvedor responsável por cada storye a estimativa de prazo.
Um termo importante dentro do planejamento de projetos XP é velocity. A velocity é a relação entre funcionalidades entregues e as funcionalidades planejadas por cada desenvolvedor. Para medir a velocityde cada desenvolvedor, deve ser feita a medição em uma iteração. Se um desenvolvedor não teve tempo suficiente, seu load factor foi estimado muito baixo para aquele período. Por outro lado, se ele não teve tarefas suficientes seu load factor estimado foi muito alto. Combinando o load factor de todos os desenvolvedores se obtém a velocity.
.
Como a medição da velocity requer que pelo menos uma iteração esteja concluída, o planejamento feito para a primeira iteração é o mais sujeito a erros e não deve jamais servir como um compromisso de entrega junto ao cliente.

Quer aprender Scrum sem Lero Lero?

CLIQUE AQUI E CONFIRA O CURSO COMPLETO!

#
Compartilhe!
Fale com o Site Campus!

Tags: , , , ,