erir Título Aqui Modelagem de Sistemas Orientada a Objetos part 4

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Modelagem de Sistemas 
Orientada a Objetos
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Responsável pelo Conteúdo:
Prof. Me. Artur Ubaldo Marques Júnior
Revisão Textual:
Prof.ª Me. Sandra Regina F. Moreira
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução às Estimativas Ágeis e aos Padrões de Projeto;
• Planning Poker;
• Estratégias de Organização de Código. Fonte: iStock/Getty Im
ages
Objetivos
• Introduzir a técnica de estimativa ágil baseada no método planning poker;
• Apresentar a necessidade da entrega contínua ágil em projetos de sistemas OO.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o 
último momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Introdução às Estimativas Ágeis 
e aos Padrões de Projeto
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Contextualização
Se há uma coisa que deixa todo mundo que desenvolve sistemas meio irritado é a 
necessidade de se passar ao gerente de projetos e partes interessadas a estimativa de 
esforço de uma funcionalidade, baseada em uma ou mais estórias e/ou requisitos levan-
tados a partir de conversas com usuários.
Isso acontece porque todos os sistemas são diferentes e há desafios não tão aparentes 
assim para levar em consideração, além disso, a estimativa normalmente é uma jornada 
solitária, bem como sua culpa pelo atraso.
Dessa maneira, o pessoal que trabalha com desenvolvimento e modelagem de siste-
mas ágeis pensou bastante e criou uma forma de estimativa em grupo, extremamente 
funcional e prática, baseada em consenso. Assim, ela é muito mais coesa e leva em 
conta a opinião do grupo e não do indivíduo.
Trata-se do planning poker. 
Sim, isso mesmo, um jogo com cartas e tudo o mais que revolucionou a forma de esti-
mar rapidamente em nível geral uma funcionalidade, ou até mesmo um backlog inteiro, 
quebrando-o em partes atômicas, mais fáceis de estimar.
É isso que vamos ver nesta unidade!
Vamos conhecer esse método?!
6
7
Introdução às Estimativas 
Ágeis e aos Padrões de Projeto
Métodos ou processos ágeis referem-se a um conjunto de metodologias de criação 
de software baseadas no desenvolvimento Iterativo em que os requisitos e as soluções 
evoluem por meio da colaboração entre equipes multifuncionais auto organizadas. 
Eles normalmente promovem um processo disciplinado de gerenciamento e desenvol-
vimento de projetos de software que incentiva a inspeção de código e adaptações frequen-
tes baseadas na mudança, uma filosofia de liderança que incentiva o trabalho em equipe, 
a auto-organização e responsabilidade. Além disso, um conjunto de melhores práticas de 
engenharia destinadas a permitir a entrega rápida (ágil) de software de alta qualidade. 
Também, trata de uma abordagem de negócios (que busca participação do cliente, 
alinhamento de ideias e entendimento de necessidades) que deixa em sinergia o 
desenvolvimento dirigido às necessidades do cliente e aos objetivos da empresa. Por 
fim, o projeto e o desenvolvimento ágil referem-se a qualquer processo de confecção de 
software que esteja alinhado com as considerações do Manifesto Ágil. 
Esse Manifesto foi criado e escrito por 14 importantes membros da indústria de desen-
volvimento de software na década de 90 do século XX, e seu foco é fazer frente à crise de 
desenvolvimento de software e mostrar o que funciona para criar software com qualidade.
Nós vamos explorar exatamente os métodos ágeis de modelagem de software 
orientados a objetos e , para tanto, vamos conhecer UML como linguagem para 
modelagem e SCRUM/XP com técnicas de gestão e desenvolvimento de software.
Durante nossa jornada, vamos nos deparar com alguns termos relacionados a 
SCRUM, Sprint e Backlog.
Nesse momento, devemos apenas entender, básica e conceitualmente, o que eles 
representam na modelagem, porque utilizaremos um pouco desses conceitos para 
estimar o esforço das histórias dos usuários, bem como dos requisitos funcionais e regras 
de negócios associadas a eles.
Assim, definimos SCRUM como pertencente a um subconjunto dos Métodos e Pro-
cessos Ágeis. Além de representar uma estrutura de processo leve para o desenvolvi-
mento, é atualmente a mais utilizada em todo o mundo.
Uma “estrutura de processo” é um conjunto particular de práticas que devem ser 
seguidas para que suas etapas sejam consistentes com a estrutura proposta.
Nesse caso, a estrutura do processo Scrum requer o uso de ciclos de desenvolvimento 
chamados Sprints, a estrutura do XP requer programação em pares, por exemplo.
Quando usamos expressões como “leve” ou “ágil”, queremos dizer que a sobrecarga do 
processo é mantida tão pequena quanto possível (por exemplo: o esforço de desenvolver 
não ultrapasse 16h por programador por item), para maximizar a quantidade de tempo 
produtivo disponível para a realização do que os métodos ágeis chamam de trabalhos 
úteis. O Scrum é mais usado para gerenciar softwares complexos e desenvolvimento de 
produtos, usando práticas iterativas e incrementais de desenvolvimento. 
7
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
O SCRUM é muito organizado, de tal forma que todo o trabalho a ser desenvolvido 
de programação, por exemplo, é acondicionado num artefato chamado de BACKLOG. E 
devemos entender backlog conforme a definição da própria Agile Alliance, como sendo: 
Um backlog é uma lista de recursos ou tarefas técnicas que a equipe 
mantém e que, em determinado momento, são necessários e suficientes 
para concluir um projeto ou uma liberação:
• se um item no backlog não contribuir para o objetivo do projeto, 
ele deve ser removido;
• por outro lado, se a qualquer momento uma tarefa ou recurso 
tornar-se conhecido e considerado necessário para o projeto, ele 
deverá ser adicionado ao backlog.
Essas propriedades “necessárias e suficientes” são avaliadas em rela-
ção ao estado de conhecimento da equipe em um determinado mo-
mento. Espera-se que o backlog mude ao longo da duração do projeto 
à medida que a equipe ganha conhecimento.
O backlog é o principal ponto de entrada para o conhecimento sobre 
os requisitos e a única fonte autorizada que define o trabalho a ser 
executado. (AGILE ALLIANCE, 2018)
Portanto, não confunda BACKLOG com uma simples lista ou documento de requi-
sitos, pois não é isso!
Além do mais, há no SCRUM uma série de backlogs (Sprint, Equipe, Fluxo de Valor, 
Portfólio, entre outros), não apenas esse (Backlog de Produto), mas, nesse caso, ele é o 
mais importante porque contém tudo o que precisa ser feito.
Os Backlogs são quebrados em unidades de desenvolvimento menores chamados de 
SPRINTS. Ele é um período de tempo definido durante o qual o trabalho específico deve 
ser concluído e preparado para revisão.
Figura 1– Representação de um BACKLOG, dividido em SPRINTS (itens em cada chave).
Fonte: scrum.org
8
9
As cores azul escuro e azul claro servem apenas para designar requisitos ou fun-
cionalidades de alta prioridade e de grande valor comercial para serem entregues, 
sendo que as azuis claras têm prioridade meno
Independentementede utilizarmos metodologias ágeis para desenvolvimento, análise 
ou modelagem de sistemas, não percamos de vista que a estimativa de esforço ainda é 
uma prática muito valiosa. 
As equipes de desenvolvimento tendem a ser excessivamente otimistas em suas estimativas. 
Elas não reavaliam quando algo muda, e as estimativas pontuais são feitas e perma-
necem estáticas, sendo que deveriam ser revistas de tempos em tempos e informadas.
Existem várias práticas recomendadas que as partes interessadas podem usar para 
colocar seus processos de estimativa de software no caminho certo para agregar valor 
as suas organizações.
A estimativa de software não precisa ser difícil, onerosa ou ineficaz. Feita corretamente, 
pode ser uma ferramenta altamente eficaz que pode ajudar os gerentes de projeto, scrum 
master, product owner, entre tantos outros, a fornecer valor as suas organizações.
Dessa maneira, propomos a utilização de uma técnica muito difundida no mundo 
atualmente, chamada Planning Poker, que se adapta perfeitamente a um gerenciamento 
ágil, por exemplo, utilizando Scrum como gerenciamento e XP como desenvolvimento.
Todavia, lembre-se que estimativa é apenas isso: uma estimativa. Não é um juramento 
de sangue.
Planning Poker
No desenvolvimento ágil, o proprietário do produto é encarregado de priorizar o 
backlog (lista ordenada de trabalho que contém descrições curtas de todos os recursos 
e correções desejadas para um produto). Os proprietários de produtos capturam os 
requisitos dos negócios, mas nem sempre entendem os detalhes da implementação.
Quando a equipe de engenharia inicia seu processo de estimativa, geralmente surgem 
questões sobre requisitos e histórias de usuários.
Para os proprietários de produtos, especificamente, dividir os itens de trabalho em 
peças e estimativas granulares ajuda a priorizar todas as áreas de trabalho.
Envolver todos (desenvolvedores, designers, testadores, implantadores) é fundamental 
para elaborar as estimativas. Cada um traz uma perspectiva diferente sobre o produto e 
o trabalho necessário para entregar uma história do usuário.
RADIGAN comenta que, da mesma forma, as mudanças no design exigem não 
apenas a entrada da equipe de projeto, mas também o desenvolvimento e o controle de 
qualidade. Deixar parte da equipe fora do processo gerará estimativas de baixa qualidade, 
reduzirá o moral, porque, às vezes, os principais contribuintes não se sentem incluídos e 
comprometerão a qualidade do software.
9
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
As equipes de software tradicionais fornecem estimativas em um formato de horas, 
dias, semanas ou meses. Os times ágeis, porém, usam pontos de história!
Eles são classificados de forma relativa ao esforço para realizar o trabalho. Para isso, 
podemos recorrer aos mais diversos formatos, ainda que, aparentemente, o preferido 
do pessoal ágil é Fibonacci, ainda que com algumas modificações.
Veja essa classificação:
• 0; • 13;
• 1; • 20;
• 2; • 40;
• 3; • 70;
• 5; • 100.
• 8;
Se fôssemos seguir à risca Fibonacci, teríamos 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 
144, porém, geraria uma complexidade numérica desnecessária.
RADIGAN enumera algumas razões para que adotemos pontos de história, a saber:
• As datas não explicam o trabalho não relacionado ao projeto que 
inevitavelmente se insinua em nossos dias: e-mails, reuniões e 
entrevistas em que um membro da equipe pode estar envolvido.
• As datas têm uma ligação emocional com elas. A estimativa 
relativa remove o apego emocional.
• Cada equipe estimará o trabalho em uma escala ligeiramente 
diferente, o que significa que sua velocidade (medida em pontos) 
será naturalmente diferente. Isso, por sua vez, torna impossível 
jogar política usando a velocidade como arma. 
É aí que entra nosso amigo, o Planning Poker. De maneira simples, a equipe pegará 
um item do backlog, discutirá brevemente e cada membro fará uma estimativa mental-
mente. Todos pegam uma carta com o número da sua estimativa (0, 1, 2, 3, 5, 8, 13, 
20, 40, 100). Se todos estiverem de acordo, OK, vá para o próximo item. Caso con-
trário, verifique as lógicas por trás dos números que as pessoas deram e reestime. Não 
perca de vista que a estimativa deve ser uma atividade de alto nível.
Há algumas dicas que o gerenciamento de projeto ágil segue como boas práticas 
de estimativa:
• Nenhuma tarefa individual deve ter mais do que 16 horas de trabalho.
Você precisa escolher qual a carta que representará esse limite. Vamos supor, no 
nosso exemplo, que essa carta seja a que possui o número 40.
Portanto, qualquer coisa que ultrapasse 40, no nosso exemplo, precisa ser dividida 
em 2 ou mais, dependendo de sua complexidade. Claro, você deverá, junto ao seu time 
de desenvolvimento, reestimar após a divisão.
Uma base de estimativas realizadas anteriormente para outros sistemas é muito útil e 
deve ser utilizada sem pudor. Conhecimento e vivência são importantes nesse momento.
10
11
KOUZINA (2014) coloca uma opinião bastante interessante sobre estimativas em 
softwares ágeis, incluindo a máxima de que é difícil estimar o que nunca se fez, mas, 
apesar disso, a maior parte dos sistemas desenvolvidos comercialmente hoje em dia se 
baseia em coisas já feitas e isso facilita nossa vida, porque estimamos sobre algo que 
alguém já fez. Vejamos o que ela nos escreve para reflexão:
Algumas pessoas, que provavelmente não são instruídas em teoria 
ágil, consideram ágil a próxima melhor solução para concluir projetos 
a tempo e podem erroneamente considerar as estimativas como uma 
promessa disso. 
Acreditam genuinamente que as estimativas ágeis lhes darão um ponto 
de referência confiável sobre o tempo de conclusão. Vamos chamá-las 
de primeiro grupo.
O segundo grupo de pessoas aceita conscientemente que a estimativa 
é uma discussão de chances, uma previsão de probabilidade. 
O gráfico burndown fornece essa previsão com base na velocidade. 
Vamos atualizar a definição clássica de velocidade em nossa memó-
ria, citando que: “A ideia principal por trás da velocidade é ajudar as 
equipes a estimar quanto trabalho elas podem completar em um de-
terminado período de tempo, com base na rapidez com que o trabalho 
semelhante foi concluído anteriormente “”
Porém, se você não precisar do recurso que desenvolveu antes, nova-
mente, por que a previsão baseada em velocidade deve ser confiada? 
“Em geral, isso vale para todas as técnicas de previsão baseadas em de-
sempenho passado, incluindo modelos de previsão. (KOUZINA, 2014)
Esse excerto traz à tona um contraponto importante para jogarmos planning poker 
de maneira correta para estimarmos, ou se preferir, darmos um bom palpite com um 
desvio decente, mais ou menos uns 20%. Sim, isso numa estimativa é bastante decente.
A dica para evitar constrangimentos da natureza acima escrita é usar gente de 
desenvolvimento para estimar. Evite gerentes estimando, ou gente que nunca escreveu 
uma linha de código na vida, pois eles não saberão de verdade as armadilhas escondidas 
num requisito aparentemente inocente.
E isso não é um demérito, apenas a máxima “cada um tem a sua especialidade”.
Quando uma equipe de desenvolvedores lê uma história, eles formam conclusões 
independentes do esforço e da complexidade envolvidos.
Quando as estimativas estão distantes, ou seja, os membros do time colocam cartas 
com uma variação muito grande, isso sinaliza que a equipe entende o problema de 
maneira diferente. 
Um desenvolvedor com uma estimativa baixa pode conhecer uma biblioteca ou uma 
ferramenta que pode acelerar as coisas. 
Um desenvolvedor com uma estimativa alta pode saber de uma armadilha que os 
outros esqueceram.
11
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Quando todo o time estima que uma história seja grande, isso define complexidade alta.
O que aconselha dividir a história em outras menores ou também sinalizar que mais 
pesquisas e levantamentos são necessários. 
Por outro lado, quando temos a equipecolocando cartas com números baixos e 
próximos, isso nos mostra que o problema é bem entendido pela equipe.
Mas há uma série de motivos que nos fazem ir adiante com as estimativas, segundo 
MERCIECA (2016), são elas:
• Estimativas nos permitem falhar precocemente;
• Estimativas nos ajudam a gerenciar a incerteza (riscos);
• Estimativas ajudam o time a falar sobre o planejamento;
• Estimativas nos ajudam a ajustar o planejamento;
• Estimativas nos ajudam a perceber que o ótimo é inimigo do bom.
Já vimos que os pontos de história são parecidos com a escala crescente de Fibonacci. 
Também já vimos a importância de desenvolvedores com experiência na fase de 
estimativas, e já conhecemos algumas dicas, mas como seguir adiante com as histórias 
a serem codificadas dentro do primeiro sprint, por exemplo, e, principalmente, se a 
equipe é nova e nunca passou pela metodologia Planning Poker antes?
Não há um caminho fácil ou seguro, e não há padrões, mas podemos dizer que uma 
boa prática seria ter sempre em mente que não existe um ponto de história correto. É o 
que a equipe quer que seja. 
Os pontos da história simplesmente representam categorias de esforço. 
Uma história “13” é maior que uma história “3”, mas é menor que uma história 
“20”. Uma forma útil é fazer a equipe começar com uma história de tamanho médio e 
todos deverão concordar com o valor que ela representa. A partir daí, o time inicia os 
trabalhos para estimar a primeira história.
É crítico, depois de alguns sprints, fazer com que a equipe repita brevemente suas 
estimativas anteriores para reforçar a compreensão da equipe sobre o que é um “20” ou 
de um “13”, por exemplo.
Para o primeiro sprint, faça a estimativa da equipe nos pontos da história, mas não 
os use para determinar quanto trabalho deve ser aceito. 
Simplesmente trabalhe com a equipe para que eles julguem coletivamente quantas 
histórias eles acham que podem terminar (desenvolver) no primeiro sprint.
O time poderá então usar sua velocidade como um guia de quanto trabalho pode 
aceitar confortavelmente a cada sprint.
Então, como você percebeu, o primeiro sprint de uma equipe que estiver iniciando 
a jornada no mundo ágil é de aprendizagem. A cada sprint feito, a equipe acumula 
conhecimento e as estimativas tendem a melhorar muito.
12
13
TIAGY (2017) nos diz que o dimensionamento é feito levando-se em conta:
• A quantidade de trabalho a ser feito; 
• A complexidade do trabalho; 
• Risco ou incerteza ao realizar o trabalho; 
• Tempo / Duração.
Diferentemente dos métodos tradicionais, é um pouco mais complexo calcular tempo 
(duração), porque isso depende de muitos fatores para trazer esse dimensionamento de 
forma direta. Dessa maneira, TIAGY (2017) trata disso na forma de um dimensionamento 
relativo, e leva em consideração algumas etapas:
1. Liste todas as histórias para serem dimensionadas.
2. Coloque-as em ordem da menor para a maior.
• Pegue a primeira história de usuário. 
• Então pegue a segunda história de usuário. 
• Decida qual é maior e coloque a maior acima. 
• Então pegue a próxima e decida onde ela se encaixa relativamente às 
outras duas. 
• Então pegue a próxima e faça o mesmo. 
• Repita o processo até que todas as histórias estejam agora na lista (em 
uma sequência do menor para o maior). Você pode utilizar cartões, 
post-its, lousa, etc., para fazer esse trabalho.
• 3. Dimensione as histórias.
• Comece da parte inferior e dê a essa história 2 pontos. Dar “2” 
fornece a você o espaço para dar um número menor “1” se descobrir 
algo menor depois.
• Veja a próxima história e decida qual é o tamanho dessa história em 
comparação com a primeira.
• Continue até ter o tamanho de cada história.
Use este conjunto de números (influenciado por Fibonacci) enquanto 
dimensiona: 1, 2, 3, 5, 8, 13, 20... (TIAGY,2017)
A estimativa baseada em horas deve ser usada quando as estimativas da tarefa são 
fornecidas em horas.
Recomendamos que você não enfatize os pontos da história durante o planejamento 
do sprint e se concentre mais em estimar o tempo necessário para concluir todas as 
tarefas envolvidas na história do usuário.
Portanto, estimativa de pontos de história é alto nível, enquanto estimativas baseadas 
em horas já são de baixo nível, sendo utilizadas para representar o esforço real para a 
conclusão das tarefas.
13
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Pre-Planning
User Story Story Point
Story Point
User Story 1
UI Design 
Development Task 1
User Story 1
5
3
8
Tasks Hours
User Story
Tasks
Sprint Planning
Story Points and taks hour estimation process
Figura 2 – Processo de estimativa de pontos de histórias e horas de tarefas. TIAGY, 2017
Vamos às regras para iniciar uma sessão agora?!
1. Cada estimador recebe um conjunto de cartas;
2. Todos os estimadores selecionam itens de backlog, discutem recursos e fazem 
perguntas;
3. Quando um recurso for totalmente discutido, cada estimador em particular 
escolhe um cartão para representar sua estimativa;
4. Quando todos os estimadores fizerem suas estimativas, eles revelam suas cartas 
ao mesmo tempo. Se todas as estimativas corresponderem, os estimadores 
selecionarão outro item de lista de pendências e repetirão o mesmo processo. 
Quando as estimativas diferirem, os estimadores discutem a questão para chegar 
a um consenso;
5. As tarefas são divididas em linhas pelo número de pontos de história ne-
cessários para implementá-las, depois, colocamos cada item de backlog na 
linha apropriada.
STORY CARD, disponivel em: https://goo.gl/FJSqLX
Figura 3 – após a estimativa de todos os story cards, devemos transcrever para uma matriz,
de forma que cada história dimensionada fi que na linha referente aos seus pontos
14
15
Agora, veja que interessante, como convertemos esses tamanhos (1,2,3,5,8...) em 
estimativas de hora do homem. 
Não podemos fazer isso até que o primeiro sprint seja concluído. 
Enquanto o primeiro sprint está em andamento, podemos rastrear a velocidade da 
equipe, assim, somente quando o sprint número 1 terminar é que saberemos quantos 
Story Points um time pode completar por sprint. Usamos esses números para prever o 
desempenho da equipe para os próximos sprints.
Portanto, você deve tomar muito cuidado. Quando usamos metodologias ágeis, não 
podemos ficar estimando horas no princípio, pois é necessário o desenvolvimento e 
evolução da equipe fazendo software ágil. Essa é a ideia.
Então, se de cara você for traduzir Pontos de História para horas, você deixa de se 
beneficiar da velocidade da estimativa relativa. Você começa a trabalhar em horas e 
corre o risco de criar um compromisso que nessa fase é desnecessário.
 Ele fornece uma falsa sensação de precisão à medida que você reduz um ponto de 
história com um intervalo de tempo de 10 a 20 horas para, por exemplo, 15 horas. 
Será mais difícil chegar a um acordo nas estimativas quando você começar a trabalhar 
no domínio exato do tempo.
Quando temos todas as tarefas do backlog estimadas em termos de Story Points, 
podemos entender quantos sprints precisaremos para concluir o projeto. E, finalmente, 
podemos converter essas unidades abstratas em linhas do tempo reais do calendário.
0
0 0
0 0
8
8 8
8 8
13
13 13
13 13
20
20 20
20 20
40
40 40
4040
100
100 100
100 100
?
??
??
1
1 1
1 1
2
2 2
2 2
3
3 3
3 3
5
5 5
5 5
1
2
1
2
1
2
1
2
1
2
Figura 4 – Exemplo de baralho de cartas para entregar aos desenvolvedores para o jogo Planning Poker
Estratégias de Organização de Código
Refatoração
FOWLER (1999) define da seguinte maneira: “A refatoração é o processo de mudar 
um sistema de software de tal maneira que ele não altera o comportamento externo do 
código, mas melhora sua estrutura interna.”
15
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
A refatoração é tipicamente feita em pequenos passos. Após cada pequeno passo, 
você fica com um sistema funcionalmente inalterado. 
Praticantes normalmente intercalamcorreções de bugs e acrescentam adições entre 
essas etapas, de tal forma que ela não impede a alteração da funcionalidade. Trata-se 
apenas de uma reorganização de código.
Refatoração implica em equivalência: os produtos inicial e final devem ser funcional-
mente idênticos, tornando o código mais claro, mais limpo, mais simples e elegante.
Cuidado, não estamos falando de correção de bugs, mas sim de melhoria de código, 
executando a mesma coisa, melhor e mais rápido certo?!
Evite armadilhas, e não faça isso:
• Reescrever código;
• consertar bugs;
• melhorar aspectos observáveis de software como, por exemplo, sua interface;
• não coloque defeitos onde antes havia código funcional.
Benefícios que podemos colher do uso da refatoração:
• Melhora os atributos objetivos do código que se correlacionam com a facilidade de 
manutenção;
• ajuda a compreensão do código;
• incentiva o desenvolvedor a pensar e entender as decisões de design, em particular 
no contexto de propriedade coletiva de código;
• favorece o surgimento de elementos de design reutilizáveis e módulos de código.
FOWLLER (1999) distingue modificação de código para preservação de comporta-
mento e modificação de código para mudança de comportamento, e reforça a necessi-
dade dos testes da seguinte maneira:
Se estivermos fazendo uma modificação de código de refatoração ou 
preservação de comportamento:
• todos os nossos testes de unidade devem passar antes e depois da 
modificação;
• não precisamos modificar nenhum teste ou escrever novos;
• esperamos um código mais limpo quando terminarmos;
• nós não esperamos novo comportamento.
• Se estamos fazendo uma modificação de código de mudança de com-
portamento:
• esperamos novo comportamento;
16
17
• devemos escrever novos testes;
• podemos obter um código mais sujo quando terminarmos (e então 
refatorá-lo).
Se perdermos de vista essa distinção, então nossas expectativas para 
qualquer tarefa de modificação de código são confusas e complexas, 
ou de qualquer forma mais confusas e complexas do que se estivés-
semos atentos a isso. É por isso que a palavra e seu significado são 
importantes. (FOWLER,1999)
Figura 5 – Código Legado, mau escrito. 
Os erros e vícios estão apontados nos balões e destacados em letras de diversas cores. 
“O código se torna código legado no momento em que ele é muito intimidante para 
ser alterado. Não importa qual seja o motivo. Se você escreveu um novo recurso hoje, 
o que levou muita energia mental e tempo, e amanhã você terá medo de mudá-lo, 
então eu tenho novidades, você tem um código legado. Portanto, o conceito não diz 
respeito apenas a programas de computador antigos ou em tecnologia ultrapassada.”
Reusabilidade
Reuso de código refere-se ao uso de código básico em um programa, seus componentes 
ou código-fonte, para criar novos programas. A reutilização do código depende muito do 
conceito estereotipado. A reutilização de código não é um padrão e nem um princípio de 
design, é uma boa prática de programação que evita, dentre outras coisas, a redundância.
KUMBHAR (2017) coloca alguns princípios para a execução do reuso de código, a saber:
Princípios de design sólido são bem conhecidos entre os programadores. 
Eles têm uma relação muito próxima com a reutilização de código.
17
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Princípio de Responsabilidade Única: Isso significa que nossos compo-
nentes (especialmente as classes) devem ter uma única responsabilida-
de. Este princípio leva a classes de peso leve bem projetadas. Quando 
seguimos esse princípio, acabamos em componentes reutilizáveis.
Princípio de abertura fechada: Este princípio de projeto determina 
que nossos componentes (incluindo classes e métodos) devem estar 
abertos para extensão e fechados para modificações. Quando seguido 
completamente, esse método leva a métodos e classes limpos, peque-
nos e reutilizáveis.
Princípio de substituição de Libskov: funções devem ser capazes de 
usar métodos de classes derivadas sem realmente conhecê-los. Isso 
nos força a criar interfaces reutilizáveis.
Segregação de interface. Melhor os separamos, mais elas são reutilizáveis.
Inversão de dependência: as classes concretas devem ser derivadas de 
interfaces bem projetadas. (KUMBHAR, 2017).
Extensibilidade
O software deve permanecer flexível e maleável. A extensibilidade é a ferramenta 
que melhor nos ajuda a alcançar isso.
Refere-se à capacidade de um software de se adaptar a uma alteração na amplitude 
da aplicação, em particular a sua capacidade em manter sua funcionalidade e desempe-
nho em caso de alta demanda.
Qualquer que seja o tamanho e a complexidade de um software, sua funcionalidade, 
desempenho, escalabilidade e custo devem corresponder às expectativas do usuário final.
Vejamos dois tipos de falta de extensibilidade:
• Tipo 1, quando o desempenho se deteriora rapidamente com o aumento da de-
manda antes de atingir o nível nominal e a falha pode ser corrigida pelas operações 
de definição e otimização de parâmetros do sistema;
• Tipo 2, quando o desempenho se deteriora para inaceitável, e nenhuma melhora 
pode ser feita, nem mesmo a substituição de hardware. A única maneira de corrigir 
esse defeito requer um questionamento caro da arquitetura do software.
O uso de filas, a arquitetura orientada a serviços SOA, utilizando serviços web e 
sistemas de gerenciamento de banco de dados, influenciam a escalabilidade do software.
Robustez
Significa que seu programa leva em conta todas as possibilidades, e que não existe erro 
não tratado, ou seja, todas as situações são tratadas pelo código e resultam em estado válido.
Isso significa que você deve projetar seu software de maneira robusta. O seu programa 
não só deve funcionar de forma correta em cada situação, mas também deve resistir a qual-
quer possível mau comportamento ou erro do usuário em seus arredores. Isso implica que 
você sempre deve verificar as suposições feitas durante o processo de desenvolvimento.
18
19
Portanto, é um estilo de programação que impede a finalização anormal ou ações 
inesperadas. Basicamente, requer código para lidar com entradas inválidas e absurdas de 
uma maneira razoável. Se ocorrer um erro interno, o programa ou biblioteca terminará 
normalmente e fornecerá informações suficientes para que o programador possa 
depurar o programa ou a rotina na retaguarda, todavia, não sairá para um prompt de 
comando, deixando o usuário na mão literalmente.
Existem alguns princípios a serem seguidos para criarmos robustez no software, 
conforme BISHOP:
• Paranoia: Não confie em nada que você não tenha gerado de código! 
Sempre que alguém usa sua rotina de programa ou biblioteca, supo-
nha que eles tentem quebrá-lo. Quando você chamar outra função, 
verifique se ela foi bem-sucedida. Mais importante ainda, assuma que 
seu próprio código terá problemas e o programe defensivamente, para 
que esses problemas possam ser detectados o mais rápido possível.
• Estupidez: Suponha que o usuário não possa ler páginas de manual ou 
documentação. Programe para que o código que você escreve manipule 
entradas e parâmetros incorretos, falsos e malformados de uma forma 
razoável, sendo “razoável”, definido pelo ambiente. Por exemplo, se você 
imprimir uma mensagem de erro, a mensagem deve ser autoexplicativa e 
não exigir que o usuário procure códigos de erro em um manual. 
• Implementos perigosos: Um “implemento perigoso” é qualquer coisa 
que suas rotinas esperem permanecer consistentes entre as chamadas. 
Por exemplo, na biblioteca de E/S padrão, espera-se que o conteúdo 
da estrutura FILE dos arquivos alocados permaneça fixo nas chamadas 
à biblioteca de E/S padrão. Isso faz com que seja um “implemento 
perigoso”. Não permita que os usuários tenham acesso a eles! Eles 
podem acidentalmente (ou deliberadamente) modificar os dados nessa 
estrutura de dados, causando falhas nas funções da biblioteca. Nunca 
retorne ponteiros ou índices em matrizes; sempre esconda os endere-ços verdadeiros (ou índices) usando “token”.
• Ocultar estruturas de dados: torna seu programa ou biblioteca mais 
modular. Por exemplo, o gerenciador de filas usa matrizes para repre-
sentar filas. Isso lhes dá um tamanho máximo. Você pode decidir que as 
listas vinculadas seriam mais adequadas e desejar reescrever as rotinas. 
Se você projetou adequadamente a interface e ocultou o máximo pos-
sível de informações e dados, o programa de chamada não precisa ser 
alterado; no entanto, se você negligenciar esse estilo de ocultação de 
informações e abstração de informações, os programas que funcionam 
corretamente com a representação atual poderão ser interrompidos se 
você alterar essa representação (porque o chamador assumiu que os ele-
mentos da fila estão em localizações inteiras sequenciais, por exemplo).
• Não pode acontecer: Como diz a velha frase: “nunca diga nunca”. 
Casos impossíveis raramente são assim; na maioria das vezes, são 
apenas altamente improváveis. Pense em como esses casos devem ser 
tratados e implemente esse tipo de tratamento. Na pior das hipóteses, 
verifique o que você acha que é impossível e imprima uma mensagem 
de erro, se ocorrer. Afinal, se você modificar o código repetidamente, 
é muito provável que uma modificação afete outras partes do código 
e cause efeitos inconsistentes, o que pode levar à ocorrência de casos 
“impossíveis”. (BISHOP, 2002)
19
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Padrões de Desenho
Um padrão de projeto é uma solução geral repetível para um problema que ocorre 
com frequência no design de software. 
Um padrão de design não é um design acabado que pode ser transformado diretamente 
em código, mas descrição ou modelo de como resolver um problema que pode ser usado 
em muitas situações diferentes.
Padrões Criacionais
Os padrões de design criativos são padrões de design que lidam com mecanismos 
de criação de objetos, tentando criar objetos de maneira adequada à situação. A forma 
básica de criação de objetos pode resultar em problemas de design ou adicionar comple-
xidade ao design. Padrões de design criativos resolvem esse problema controlando de 
alguma forma a criação desse objeto.
• Abstract Factory: Cria uma instância de várias famílias de classes;
• Builder: Separa a construção de objetos de sua representação;
• Factory Method: Cria uma instância de várias classes derivadas;
• Object Pool: Evita aquisições caras e liberação de recursos pela reciclagem de 
objetos que não estão mais em uso;
• Prototype: Uma instância totalmente inicializada para ser copiada ou clonada;
• Singleton: Uma classe da qual apenas uma única instância pode existir.
Padrão Estrutural
Esses padrões de design são todos sobre a composição de Classes e Objetos. Padrões 
estruturais de criação de classes usam herança para compor interfaces. Padrões estruturais 
de objetos definem maneiras de compor objetos para obter novas funcionalidades:
• Adapter: faz a correspondência de diferentes classes.
• Bridge: Separa a interface de um objeto de sua implementação;
• Composite: Uma estrutura de árvore de objetos simples e compostos;
• Decorator: Adicionar responsabilidades aos objetos dinamicamente;
• Facade: Uma única classe que representa um subsistema inteiro;
• Flyweight: Uma instância refinada usada para compartilhamento eficiente;
Private Class Data: Restringe o acesso do aaccessor/mutator;
• Proxy: Um objeto representando outro objeto.
20
21
Padrão Comportamental
Esses padrões de design são todos sobre comunicação de objetos da classe. Padrões 
comportamentais são aqueles padrões que estão mais especificamente relacionados à 
comunicação entre objetos.
• Chain of rresponsability: Uma maneira de passar um pedido entre uma cadeia 
de objetos.
• Command: Encapsula uma solicitação de comando como um objeto.
• Interpreter: Uma maneira de incluir elementos de linguagem em um programa.
• Iterator: Acessa sequencialmente os elementos de uma coleção.
• Mediator: Define a comunicação simplificada entre classes.
• Memento: Captura e restaura o estado interno de um objeto.
• Null Object: Projetado para agir como um valor padrão de um objeto.
• Observer: Uma maneira de notificar a mudança para várias classes.
• State: Altera o comportamento de um objeto quando seu estado muda.
• Estrategy: Encapsula um algoritmo dentro de uma classe.
• Template Method: Adia as etapas exatas de um algoritmo para uma subclasse.
• Visitor: Define uma nova operação para uma classe sem alteração.
21
UNIDADE 
Introdução às Estimativas Ágeis e aos Padrões de Projeto
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Agile in Practice: Planning Poker – Agile Academy
https://youtu.be/0FbnCWWg_NY
Agile Estimating and Planning: Planning Poker - Mike Cohn
https://youtu.be/MrIZMuvjTws
Estimation - Black Pepper Software Limited
https://youtu.be/7nTxdl29ePY
Design Patterns - Como surgiram os padrões de projeto? – 4WHILE
https://youtu.be/sUyTKDHGCtA
22
23
Referências
AGILE ALLIANCE, Agile 101, 2018. Disponível em: https://www.agilealliance.
org/glossary/backlog/#q=~(filters~(postType~(~’page~’post~’aa_book~’aa_event_
session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’bac
klog))~searchTerm~’~sort~false~sortDirection~’asc~page~1) . Acessado em 10/05/2018.
BISHOP, M. Robust Programming, 2002, University of California at Davis. Disponível 
em: http://nob.cs.ucdavis.edu/bishop/secprog/robust.html. Acessado em: 05/05/2018.
FOWLER, M. et Ali. Refactoring Improving the design of existing code, 1ª Addison 
Wesley Longmann, California EUA, 1999.
KOUZINA, O. Why Agile Estimates Don’t Work, 2014, TARGET PROCESS. Dis-
ponível em: https://www.targetprocess.com/blog/2014/07/why-agile-estimates-dont-
-work-part-2/. Acessado em 2/5/2018.
KUMBHAR, N. What is code reusability? 2017. Disponível em: https://www.
quora.com/What-is-code-reusability?utm_medium=organic&utm_source=google_rich_
qa&utm_campaign=google_rich_qa. Acessado em: 4/5/2018.
MERCIECA, M. Why You Should Do Software Estimates, 2016, MUTUALLY HU-
MAN. Disponível em: https://www.mutuallyhuman.com/blog/2016/09/09/why-you-
-should-do-software-estimates acessado em 3/5/2018.
RADIGAN, D. The secrets behind story points and agile estimation, ATLASSIAN. 
Disponível em: https://www.atlassian.com/agile/project-management/estimation. Aces-
sado em: 2/5/2018.
23