Metodologias Ágeis de Projetos

Prévia do material em texto

AULA 5 
 
 
 
 
 
 
 
 
 
 
DIFERENTES METODOLOGIAS 
ÁGEIS DE PROJETOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Profª Ana Paula Costacurta 
 
 
2 
TEMA 1 – REGRAS DA XP 
As regras da programação extrema são muito similares a um quebra-
cabeça, com muitas peças pequenas que, combinadas, criam uma visão 
completa. Neste tema, falaremos sobre as regras simples da programação 
extrema. 
1.1 Planejamento 
Na fase de planejamento com base nas funcionalidades desejadas, os 
clientes escreverão as histórias de usuários e uma reunião é realizada com a 
equipe de desenvolvimento para: 
• Criar o planejamento de liberação; 
• Dividir as interações e realizar os lançamentos frequentes. 
Planejar cada interação e definir o início das interações. 
1.2 Gerenciamento 
Na fase de gerenciamento, será definida a equipe e algumas ações são 
definidas: 
• Espaço de trabalho aberto dedicado para equipe; 
• Definição de ritmo sustentável; 
• Reuniões diárias em pé; 
• Realizar a medição da velocidade dos projetos; 
• Movimento das pessoas. 
Corrigir o XP quando necessário. 
1.2.1 Espaço de trabalho aberto dedicado 
É importante para uma equipe na XP realizar a comunicação; por isso, 
remover as barreiras que dificultam a comunicação é essencial. 
Algumas atitudes na hora de montar a área de trabalho da equipe podem 
facilitar a comunicação, como: 
• Incentivar pessoas a trabalhar em pares, colocando computadores em uma 
área central; 
 
 
3 
• Lugar para pessoas trabalharem sozinhas sem desconectar da equipe, 
colocando meses ao redor do perímetro; 
• Grande área de reunião para reuniões diárias em pé; 
• Mesa para realizar discussões em grupo, para a equipe ouvir ou participar; 
• Quadros brancos para notas importantes ou esboços, quadro de atividades 
com os cartões de histórias de forma visível; 
• Disponibilização de gráficos para melhoria do processo ou visualização do 
progresso do projeto. 
1.2.2 Ritmo sustentável 
É importante realizar um planejamento realista e não colocar a equipe em 
horas extras ou estresses desnecessários. Caso, após realizar o planejamento da 
interação, seja verificado que a equipe não conseguirá entregar tudo o planejado, 
é melhor realizar uma nova reunião de planejamento de interação para alterar o 
escopo ou rever o tempo do projeto. 
Não é uma boa ideia solicitar que a equipe aumente a velocidade. O 
importante é realizar o planejamento e encontrar uma velocidade perfeita que a 
equipe continue constante em todo o projeto. 
1.2.3 Movimento das pessoas 
Ter uma pessoa com um conhecimento que não tenha ninguém para 
substituir é um risco para o projeto. Por isso, é importante realizar o treinamento 
cruzado movendo as pessoas pela base do código combinado com a 
programação em pares. 
É importante incentivar todos a tentarem trabalhar em uma nova seção, 
pelo menos uma parte em cada interação. Com a programação em pares, isso é 
possível sem impactar na produtividade, visto que um realiza a programação 
enquanto o outro fica observando. 
1.2.4 Corrigir o XP 
É importante ter em mente as regras do XP, porém, se não estiver 
funcionando para o projeto, não hesite em mudar o que deve ser mudado. A 
equipe não pode fazer o que quiser; as regras devem ser seguidas até que se 
decida realizar as mudanças. 
 
 
4 
As reuniões de retrospectivas podem ser uteis e os membros da equipe 
podem falar o que está funcionando e o que poderia ser melhorado no XP. 
1.3 Projetando 
Nesta fase de projeção, são realizados: 
• Design Simples; 
• Metáfora do sistema; 
• Cartões CRC para sessões de projeto; 
• Solução de Pico (Spike), para redução do risco; 
• Refatoração sempre que possível. 
Não adicionar funcionalidade cedo demais. 
1.3.1 Design simples 
A equipe deve sempre prezar pela simplicidade. Como a simplicidade é 
muito subjetiva, de forma conjunta, a equipe decidirá o que é simples e a 
recomendação é que se tenha quatro qualidades: 
• Testável: é possível escrever testes de unidade e testes de aceitação para 
verificar se há problema; 
• Compreensível: é fácil de compreender; 
• Navegável: é capaz de encontrar o que você quer quando quiser; 
• Explicável: é fácil mostrar para as outras pessoas como funciona. 
1.3.2 Cartões CRC 
Os Cartões CRC (Classe, Responsabilidade e Colaboração) permite que a 
equipe inteira contribua com o projeto e são utilizados para representar os objetos. 
Podemos ver um exemplo de Cartão CRC na figura 1. 
É realizada uma sessão de CRC. Alguém fala sobre quais objetos enviam 
mensagens para outros objetos, percorrendo o processo para descoberta das 
fraquezas e problemas. 
 
 
 
5 
Figura 1 – Exemplo de CRC (autor) 
Classe: Conta Corrente 
Responsabilidade Colaboração (Classes 
Colaboradoras) 
Consultar Saldo Cliente 
Consultar o número da conta Histórico de transações 
Consultar o nome cliente da conta 
Realizar Saque 
Realizar Depósito 
Consultar Histórico de transações 
1.3.3 Não adicionar funcionalidade cedo demais 
Não adicione funcionalidades extras, porque já sabemos exatamente incluí-
las, ou pela impressão, que seria muito melhor que a funcionalidade fosse incluída 
no sistema agora. Lembre que a inclusão dessas funcionalidades poderá deixar o 
projeto complexo. 
Manter o código simples e pronto para mudanças é uma questão da técnica 
de design simples. É importante se concentrar no que foi programado para não 
adicionar um risco desnecessário ao projeto. 
1.4 Codificação 
Nesta fase, é realizada a implementação do código do software. Para isso, 
é preciso realizar as seguintes atividades: 
• O cliente sempre presente; 
• Padrão de codificação; 
• Desenvolvimento Orientado a Testes (TDD); 
• Programação em pares; 
• Integração Sequencial; 
• Integração frequentemente; 
• Computador de integração dedicado; 
• Propriedade Coletiva. 
 
 
6 
1.4.1 Integração 
Vários desenvolvedores trabalhando realizam a integração do seu código 
e realizam a integração confiando que está tudo bem. Quando um programador 
pega uma classe, cria a propriedade de classe específica que está se trabalhando; 
porém, mesmo assim, as dependências podem estar erradas. 
A integração frequente ou contínua evita e detecta problemas 
antecipadamente em relação à compatibilidade dos códigos, em que, sempre que 
possível, os desenvolvedores devem realizar a integração e confirmação do 
código no repositório. 
A integração sequencial apenas em um par de desenvolvedor realiza a 
integração, testa e confirma a alteração em determinado momento. 
Para realizar a integração sequencial, um mecanismo é necessário: um 
computador de integração dedicado. Esse computador funciona como local para 
controlar a liberação e nele devem estar os testes unitários sempre atualizados. 
Nenhuma alteração é liberada sem passar por esse computador e ter a 
estabilidade garantida. 
1.4.2 Dia de um desenvolvedor XP 
Na Figura 2, podemos ver um exemplo de um dia típico de um 
desenvolvedor, em que, após a reunião diária em pé, formam pares, começando 
com uma rápida sessão de design para formular uma estratégia inicial no que 
estiverem trabalhando. 
Realiza a criação dos testes, codifica e refatora. A equipe de qualidade 
deve ter um contato frequente com a equipe de desenvolvimento. A integração 
deve ser realizada antes finalizar o dia de trabalho ou, caso tenha finalizado a 
atividade antes do fim do dia, inicia uma nova tarefa e realiza uma nova seção 
rápida de design para nova tarefa. 
 
 
 
7 
Figura 2 – Dia típico de um desenvolvedor 
 
Fonte: Agile Modeling, 2022. 
1.5 Teste 
Nesta fase, os testes precisam ser realizados pela equipe para evitar erros 
(bugs) antes de realizar a liberação. Para isso, algumas atividades são realizadas: 
• Teste de unidade; 
• Criação de testes ao encontrar erro; 
• Testes de aceitação. 
1.5.1 Teste de Unidade 
Primeiro, é necessário criar ou baixar uma estruturade teste de unidade 
para criação de conjunto de testes automatizados. As estruturas de testes de 
 
 
8 
unidade, além da realização de testes, auxiliam na formalização de requisitos, 
esclarecimento de arquitetura, codificação, depuração, integração e otimização. 
A maioria das linguagens possui uma estrutura de testes de unidades, 
como, por exemplo, JUnit para Java. 
Saiba mais 
Conheça mais sobre o XP no link: 
<https://wiki.c2.com/?ExtremeProgrammingRoadmap>. Acesso em: 4 mar. 2022. 
TEMA 2 – VANTAGENS E DESVANTAGENS DA XP 
A abordagem e métodos da programação extrema podem ser considerados 
por muitos bastante controversos e não podem ser aplicados a todos os projetos. 
Neste tema, tentaremos demonstrar as vantagens e desvantagens da abordagem 
Programação Extrema. 
2.1 Vantagens 
Com a utilização do XP, podemos auxiliar na redução do tempo e custos 
do desenvolvimento, e os motivos são: 
• Sistemas estáveis: as práticas de testes frequentes e refatoração ajudam 
a estabilizar o sistema; 
• Código claro e conciso: seguindo o valor da simplicidade os códigos, são 
criados de forma a facilitar a leitura e manutenção no futuro; 
• Entrega rápida de mínimo produto viável (MVP): apenas os recursos 
necessários, utilizando uma abordagem minimalista; 
• Documentação reduzida: são criadas histórias de usuários com 
informações suficientes para compreensão para o desenvolvimento; 
• Sem horas extras: caso seja percebido que não será possível realizar as 
entregas no tempo estimado, deve ser realizada uma revisão e novo 
planejamento; 
• Grande visibilidade do projeto: com constante comunicação, possibilita 
que todos os membros da equipe tenham uma visão do progresso do 
projeto; 
• Colaboração em time: a programação em pares gera um produto com alta 
qualidade e menos erros (bugs); 
 
 
9 
• Satisfação do cliente: o cliente está sempre presente e participando de 
todo o processo de desenvolvimento e testes, influenciando diretamente no 
resultado; isso garante sua satisfação por receber exatamente o que 
desejavam. 
2.2 Desvantagens 
Algumas desvantagens podem ser listadas quando utilizamos XP que 
devemos levar em consideração, sendo elas: 
• Estimativa irreal: sem uma visão clara do cliente, acaba tornando difícil 
realizar uma estimativa real de escopo, custo e tempo; 
• Perda de tempo: gastar mais tempo com reuniões frequentes do que 
desenvolvimento; 
• Pouca documentação: a falta de documentação pode produzir a falta de 
requisitos e especificações claras e gerar desvio do escopo do projeto; 
• Grandes mundanas culturais: a adoção do XP exige uma transição dos 
métodos tradicionais para ágil e, consequentemente, mudanças 
significativas de cultura e estruturas; 
• Maior tempo em programação em pares: pode existir problemas de 
compatibilidade entre membros e, consequentemente, pode levar mais 
tempo e não funcionar adequadamente; 
• Dificuldades com equipes distribuídas: as reuniões são realizadas 
presencialmente; por isso, o XP funciona melhor em equipes alocadas em 
um mesmo local fisicamente; 
• Estresse: por existirem prazos apertados, isso pode ser um pouco 
estressante, pois, às vezes, o cliente pode não estar disponível para 
realizar o feedback necessário e com valor; 
• Foco excessivo no código: pelo foco não estar no design pode gerar 
duplicação de código, falta de garantia de qualidade e resultados ruins 
quando os desenvolvedores não possuem muita experiência. 
TEMA 3 – MAPA DO PROCESSO DA XP 
Na figura 3, podemos ver o mapa do processo da XP. Neste tema, veremos 
uma breve explicação sobre os cinco principais itens do processo: Histórias de 
 
 
10 
usuários, Pico arquitetônico, Planejamento do Lançamento, Interação e Teste de 
Aceitação. 
Figura 3 – Ciclo de vida de Projeto de Programação Extrema 
 
Fonte: Wells, 2022. 
3.1 Histórias de Usuários 
Após os levantamentos das funcionalidades desejadas pela área de 
negócio, é o momento de realizar a transformação em histórias de usuários para 
que a equipe de desenvolvimento tenha um melhor entendimento do que é 
desejado. 
As histórias de usuários possuem o mesmo propósito de casos de usos, 
mas não é a mesma coisa. Elas são escritas pelos clientes com informações do 
que o sistema precisa fazer e são utilizadas para realizar as estimativas para 
reunião de planejamento de Lançamento. Elas também vão orientar a criação dos 
testes de aceitação. 
É importante lembrar que as histórias de usuários devem conter apenas 
detalhes suficientes para possibilitar a estimativa de risco e tempo. Somente na 
fase de interação é que os desenvolvedores conversarão como cliente para 
detalhar melhor os requisitos. 
 
 
 
11 
3.2 Solução Pico ou Pico Arquitetônico 
Quando é necessário descobrir respostas para problemas técnicos ou 
planejamento que sejam de difícil entendimento, é criada uma solução de Pico. 
Para a solução de pico (Architectural Spike), ou fase de exploração, será 
desenvolvido um programa bem simples com objetivo de explorar possíveis 
soluções. O XP prefere essa prática a protótipos, pois protótipos são apenas para 
demostrar visualmente a funcionalidade; já a solução de pico auxilia da 
identificação de áreas de risco para começar a ter uma estimativa mais realista. 
3.3 Planejamento do Lançamento 
Para criar o plano de lançamento (Release Planning), é realizada uma 
reunião em que o cliente e a equipe de desenvolvimento possam tomar as 
decisões necessárias. O principal objetivo da reunião de lançamento é a equipe 
de desenvolvimento realizar a estimativa das histórias e o cliente decidirá então 
qual história é a mais importante ou com maior prioridade de conclusão. 
Para realizar a estimativa das histórias, a equipe de desenvolvimento pode 
colocar as histórias de usuários em cartões, em que esses cartões vão se 
movendo em grupos para criar o conjunto para interação, sempre pensando na 
entrega que possa ser testada e utilizada pelo cliente. 
A reunião de planejamento do lançamento também é chamada de jogo do 
planejamento (Game Planning) com regras específicas. 
Saiba mais 
Veja as regras do Jogo do planejamento no link disponível em: 
<http://c2.com/cgi/wiki?PlanningGame>. Acesso em: 4 mar. 2022. 
3.4 Planejamento da Interação 
A reunião de planejamento da interação (Interation Planning) é realizada 
no início de cada interação para criação do plano de tarefas do desenvolvimento 
da interação. 
As interações têm duração de uma a três semanas. Para isso, são 
escolhidas as histórias de usuários para a interação pelo cliente, na ordem de 
maior valor para o cliente. 
 
 
12 
As histórias de usuários e erros encontrados são divididos em tarefas e os 
desenvolvedores se inscrevem para trabalharem nas tarefas. O desenvolvedor 
que aceitou a tarefa realiza a estimativa de tempo para finalizá-la, que deve ser 
estimada em dias ideais. 
Se a interação tiver muitas ou poucas histórias para interação, deve ser 
realizado o ajuste, colocando ou tirando histórias de usuários. Histórias de 
usuários com menos de um dia de trabalho devem ser agrupadas com outras. 
3.5 Testes de aceitação 
Com base nas histórias de usuários, são criados os testes de aceitação 
(Acceptance Tests), em que o cliente define os cenários para teste. Serão criados 
um ou mais testes de aceitação, para garantir que foi realizada a implementação 
correta e que a funcionalidade está operacional. 
Os testes de aceitação ou funcionais são utilizados também como testes 
de regressão, antes de uma versão ser implementada no ambiente de quente ou 
de produção. O controle de qualidade no XP é realizado por uma equipe separada 
e o relacionamento com o desenvolvimento deve ser muito próximo. 
Saiba mais 
Veja um exemplo de caso de uso do xp no link disponível em: 
<http://agilemodeling.com/essays/agilemodelingxplifecycle.htm>. Acesso em: 4 
mar. 2022. 
TEMA 4 – ETAPA DE INTERAÇÃO DA XP 
Na Figura 4, veremoso mapa do processo da etapa de interação do XP. 
Neste tema, iremos ver em detalhes os três principais itens: erros, 
desenvolvimento, novas histórias de usuários e velocidade de projeto. 
4.1 Erros (Bugs) 
Quando um erro (bug) é encontrado, precisa ser criado um teste de 
aceitação para avisar aos desenvolvedores sobre o problema e saber se foi 
corrigido. 
Primeiro, é executado o teste unitário para mostrar o defeito do ponto de 
vista técnico do código fonte; quando for executado sem erros nos testes de 
unidade, passa-se para os testes de aceitação para verificar se o erro foi corrigido. 
 
 
13 
 
4.2 Desenvolvimento 
Na XP, os programadores trabalham em pares no código, para que seja 
possível o gerenciamento de código por toda a equipe. Utiliza-se o 
desenvolvimento orientado a testes para escrever os testes unitários. 
A programação em pares leva à propriedade coletiva do código, em que 
deve ser seguidas as convenções de codificação. Veremos a etapa de 
desenvolvimento em detalhes no próximo tema. 
4.3 Velocidade do Projeto 
A velocidade do projeto ou apenas velocidade é a medida que indica a 
soma das estimativas das histórias dos usuários que foram concluídas na 
interação. A medida de velocidade e a totalização das estimativas serão utilizadas 
no planejamento das próximas interações. 
É na reunião de planejamento da interação que o cliente decide se irá 
escolher o mesmo número de histórias de usuário que a velocidade medida de na 
última interação. A velocidade aumentará caso o desenvolvedor solicite novas 
tarefas quando o trabalho for concluído antecipadamente. Caso a velocidade 
mude drasticamente, podem ser realizadas novas estimativas e pode se 
renegociar o plano de lançamento. 
O problema de qualquer projeto é a estimativa inicial. Mesmo com muitos 
detalhes, tudo não passará de um palpite, pois ainda não teremos dados históricos 
suficientes para uma boa estimativa. A estimativa vai melhorando durante as 
explorações iniciais de cada interação, utilizando os dados históricos das 
interações anteriores. 
 
 
14 
TEMA 5 – ETAPA DE DESENVOLVIMENTO 
Na Figura 5, podemos ver o mapa do processo da etapa de 
desenvolvimento. Neste tema, veremos em detalhes os dois processos principais: 
Reuniões diárias em pé e Propriedade coletiva do código. 
5.1 Reuniões diárias em pé 
Nas reuniões diárias em pé, há a possibilidade de comunicação com toda 
a equipe. Deve ser realizada no início do expediente e deve ser utilizada para 
comunicar problemas, soluções e prover foco da equipe. 
 As reuniões devem ser realizadas em pé com tempo limitado para manter 
o foco e não desperdiçar o tempo da equipe de desenvolvimento. Caso seja 
necessário, podem ser agendada outras reuniões específicas com apenas as 
pessoas envolvidas. 
 Os desenvolvedores vão relatar o que foi realizado ontem, o que está 
planejado para ser realizado hoje e quais problemas estão enfrentando que 
podem causar atrasos ou estão causando atraso. 
Figura 5 – Mapa do processo da etapa de desenvolvimento 
 
Fonte: Wells, 2022. 
5.2 Propriedade Coletiva do código 
Na Figura 6, podemos ver o mapa do processo da propriedade coletiva do 
código (Colletive Code Ownership). 
 
 
 
 
15 
Figura 6 – Mapa do Processo da Propriedade Coletiva do Códig 
 
Fonte: Wells, 2022. 
A propriedade coletiva de código é uma alternativa ao Gerenciamento de 
código (CodeStewardship). O Gerenciamento de código e a propriedade coletiva 
do código consideram que o código pertence ao projeto e não a uma única pessoa, 
como na Propriedade de Código (CodeOwnership). 
No Gerenciamento de código, existe um mordomo que é responsável 
principal pela verificação das alterações realizadas pelos outros membros. 
Comparando com a propriedade de código, é uma nomenclatura diferente, porque 
nenhuma alteração é realizada no gerenciamento de código sem passar pela 
verificação do mordomo, criando assim uma propriedade de código ao mordomo. 
Na propriedade coletiva de código, os programadores trabalham em pares 
e movem pessoas para pulverização do conhecimento entre todas da equipe. 
Caso alguém quebre o código, é sua responsabilidade realizar a correção até que 
passe 100% no teste unitário. 
 
 
 
16 
REFERÊNCIAS 
ALTEXSOFT. Extreme Programming: Values, Principles, and Practices. 
Disponível em: <https://www.altexsoft.com/blog/business/extreme-programming-
values-principles-and-practices/>. Acesso em: 3 mar. 2022. 
WELLS, D. Extreme Programming: A gentle introduction. Disponível em: 
<http://www.extremeprogramming.org/>. Acesso em: 3 mar. 2022. 
BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace Change. 2. 
ed. USA: Person Education, 2005. 
AGILE MODELING. AM Throughout the XP Lifecycle. Disponível em: 
<http://agilemodeling.com/essays/agileModelingXPLifecycle.htm>. Acesso em: 3 
mar. 2022.