3

Prévia do material em texto

ENGENHARIA DE SOFTWARE 
Prof. Emerson Antonio Klisiewicz 
AULA 3
 
 
2 
CONVERSA INICIAL 
Olá! Nesta aula, vamos estudar sobre as metodologias ágeis e seus tipos, 
pois elas também fazem parte do processo de engenharia de software. 
TEMA 1 – PROCESSOS ÁGEIS 
 No fim da década de 90, novos modelos começaram a surgir, assumindo 
que, com as ferramentas e práticas adequadas, era simplesmente mais rentável 
escrever o código rapidamente, avaliá-lo com o usuário e, em caso de erros, 
arrumá-lo rapidamente, que tentar antecipar e documentar todos os requisitos 
primeiro. Nesse contexto, surgem os processos ágeis. 
1.1 Criação do manifesto ágil 
O manifesto ágil foi redigido em uma reunião por um grupo de 17 
indivíduos, todos criadores de diversas metodologias: Kent Beck (XP), Mike 
Beedle, Arie van Bennekum, Alistair Cockburn (Cristal/Clear), Ward Cunningham 
(XP), Martin Fowler, James Grenning, Jim Highsmith (ASD), Andrew Hunt, Ron 
Jeffries (XP), Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken 
Schwaber (SCRUM), Jeff Sutherland (SCRUM) e Dave Thomas. Nessa reunião, 
foram discutidos temas relacionados à metodologia para o desenvolvimento de 
software. 
1.2 O manifesto ágil 
1.2.1 Valores 
Estamos descobrindo maneiras melhores de desenvolver software 
fazendo-o e ajudando os outros fazê-lo. Por meio deste trabalho, concluímos os 
seguintes valores: 
 os indivíduos na equipe e as interações no desenvolvimento são mais 
importantes que processos e ferramentas; 
 software entregue e funcionando é mais importante que ter uma 
documentação completa e totalmente detalhada; 
 a colaboração com o cliente naquilo que ele necessita é mais 
importante que a realização da negociação de contratos; 
 
 
3 
 a adaptação a mudanças do sistema tem uma maior importância que 
seguir um plano inicial. 
1.2.2 Princípios 
 A maior prioridade sempre é satisfazer o cliente por meio da entrega 
antecipada e contínua de software. 
 As mudanças nos requisitos não são problemas, mesmo no final do 
desenvolvimento. Os processos ágeis asseguram que a mudança gerará 
vantagem competitiva para o cliente. 
 As entregas do software funcionando devem ser realizadas com maior 
frequência, a partir de um par de semanas ou meses, com preferência em 
uma escala curta de tempo. 
 Equipes de negócios e desenvolvedores trabalhando juntos diariamente 
durante o desenvolvimento do projeto. 
 A construção de projetos com equipes motivadas. Fornecer o ambiente e 
o apoio de que necessitam, além da confiança necessária para fazer o 
trabalho. 
 O Ágil é um método eficiente e eficaz para transmitir informações para 
dentro da equipe de desenvolvimento. Usa-se a conversa face a face. 
 Ter o software funcionando é a principal forma de se medir o progresso. 
 Os processos ágeis têm um desenvolvimento sustentável. 
Patrocinadores, desenvolvedores e usuários devem ser capazes de 
manter o ritmo constante e de forma indefinida. 
 Sempre deve possuir atenção máxima a excelência técnica e a um bom 
design, aumentando, assim, a agilidade. 
 Ser simples, ou seja, maximizar a importância do trabalho não feito. 
 Possuir equipes auto-organizadas. 
 A equipe de desenvolvimento deve parar e refletir de tempos em tempos 
sobre como se tornar mais eficaz e sintonizar e ajustar seu 
comportamento de acordo com essa reflexão. 
 
 
 
4 
 
Leitura obrigatória 
 Para ampliar seus estudos, leia o capítulo 5, itens 1 a 3 do livro: 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
TEMA 2 – EXTREME PROGRAMMING 
 Nos anos 1990, o engenheiro Kent Beck, ao procurar formas mais 
simples e eficientes para o desenvolvimento de software, identificou o que o 
tornava simples e o que dificultava no desenvolvimento de software. Nesse 
caminho, iniciou a eXtreme Programmin, uma metodologia ágil muito 
utilizada na atualidade. 
 Essa metodologia foi desenvolvida para ser utilizada em equipes 
médias e pequenas (2 a 12 pessoas) e para trabalhar com requisitos vagos 
e em constante evolução. Também tem um conjunto de valores e práticas 
para nortear o desenvolvimento de software. 
2.1 Princípios 
2.1.1 Comunicação 
 Todos os membros da equipe, sejam clientes, sejam gerentes, sejam 
programadores, devem se relacionar pessoalmente uns com os outros, 
agilizando a comunicação. Se possível, devem trabalhar em um mesmo 
ambiente para se reunirem pessoalmente. 
2.1.2 Simplicidade 
 O projeto do software é simplificado continuamente e o processo de 
desenvolvimento deve ser adaptado, caso essa situação não esteja 
ocorrendo. 
2.1.3 Feedback 
 O cliente deverá estar presente no desenvolvimento do sistema. 
 Testes unitários e de homologação devem fornecer o entendimento sobre 
o desenvolvimento do software. 
 
 
5 
 Questões de oportunidades ou aquelas relacionadas a problemas do 
desenvolvimento devem ser informadas o mais rápido possível. 
2.1.4 Coragem 
 Os membros da equipe de desenvolvimento devem ter coragem para 
indicar situações de problemas encontrados no projeto e para solicitar 
ajuda quando necessário. 
 Informar ao cliente – o mais rápido possível – que não será possível 
implementar um requisito no prazo estimado. 
2.2 O processo 
Figura 1 – Desenvolvimento de software 
 
 Dessa forma, tem-se uma metodologia interessante para usar no 
desenvolvimento de software, porém pode haver possíveis barreiras para o 
sucesso de um projeto XP, como: 
 cultura – pode ser que a organização tenha uma cultura fortemente 
tradicional, com ênfase em metodologias clássicas, muita documentação, 
modelagem etc.; 
 tamanho das equipes – as equipes devem ser pequenas, com no máximo 
12 pessoas, mas nem sempre isso é possível; 
 espaço físico – o local de trabalho deve servir para aproximar as equipes, 
facilitando a comunicação; 
 
 
6 
 cliente: no XP, o cliente deve trabalhar ou estar com equipe de 
desenvolvimento. 
 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 5, item 4. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
TEMA 3 – SCRUM 
Trata-se de um framework utilizado para organizar times e entregar 
resultados de maneira mais produtiva e com alta qualidade. O Scrum foi 
fundamentado no empirismo, com o emprego de um desenvolvimento iterativo e 
incremental para otimizar a previsibilidade e também controlar os riscos. 
É uma alternativa para utilizar métodos ágeis na gerência de projetos, 
sendo aplicável a qualquer tipo de projeto. Trabalha de forma simples com 
processo, artefatos e regras, que são poucas e fácil entendimento. 
É fundamentado em 3 pilares: 
1. Transparência – A equipe de desenvolvimento deverá ter uma visão clara 
e objetiva de todo o processo. Para isso, o fundamental será a 
comunicação; 
2. Inspeção – Com frequência, os artefatos (backlog do produto, backlog do 
sprint, burndown…) deverão ser verificados, sendo informado assim os 
progressos do projeto; 
3. Adaptação – Se o responsável pela verificação identificar que algum 
processo não está de acordo com o planejado e que o resultado não será 
favorável ao produto, deverá relatar e realizar o ajuste o mais rápido 
possível, a fim de que não haja mais desvios. 
No Scrum, temos 3 papéis de trabalho dentro da equipe: 
I. Product owner – É a pessoa responsável por apresentar os interesses 
de todos os stakeholders. Definirá os planos iniciais do projeto, os 
objetivos e o que será entregue na versão a ser desenvolvida. É 
responsável pela lista de requisitos(product backlog) e por verificar se 
as atividades com maior valor para o negócio serão desenvolvidas 
primeiramente. 
 
 
7 
II. Scrum master – É o responsável pelo sucesso do Scrum, ensinando-o 
para a equipe de projeto. Deverá verificar se cada pessoa envolvida no 
projeto está seguindo os papéis e as regras do Scrum, a fim de garantir 
que aquelas não responsáveis pelo processo interfiram no 
desenvolvimento. 
III. Time – É a equipe. Serão os responsáveis por escolher as 
funcionalidades a serem desenvolvidas em cada interação e 
desenvolvê-las. A equipe de se autogerenciar. Todos os membros são 
coletivamente responsáveis pelo sucesso de cada entrega do 
desenvolvimento. 
3.1 O processo 
Figura 2 – SCRUM 
 
Fonte: Elaborado com base em Agile Software Development with Scrum (Schraber & Beedle). 
 
Beedle citou que “O Scrum pressupõe o caos...”, mas, na verdade, 
capacita as equipes de desenvolvimento a trabalhar em processos que 
normalmente não são livres da incerteza. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 5, item 2. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
 
 
8 
TEMA 4 – ESTIMATIVAS 
Nas metodologias ágeis, estimativas de esforço e tempo são calculadas a 
partir de estórias (requisitos). Essa atividade é de responsabilidade de toda a 
equipe técnica, e isso por alguns motivos, alguns dos quais são citados a seguir. 
 Quando se está planejando o desenvolvimento, normalmente não se sabe 
exatamente quem vai implementar quais partes dos requisitos. 
 Estórias normalmente envolvem diversas pessoas com diferentes 
conhecimentos (design de interface de usuário, codificação, teste etc.). 
 Para realizar uma estimativa, a equipe precisa de algum tipo de 
compreensão de cada estória. Um maior entendimento do contexto 
aumenta as chances dos membros da equipe se ajudarem durante a 
iteração. Isso também ajuda a aumentar a probabilidade de que questões 
importantes sobre a estória/requisito surjam cedo. 
 Quando todos da equipe estimam uma estória/requerimento, é frequente 
que se encontrem desconexões onde mais de um membro da equipe 
tenha estimativa bastante diferente para a mesma estória/requerimento. 
É necessário discutir essas situações antes do início da iteração. 
Nas metodologias ágeis, as estimativas seguem um questionamento 
relacionado a uma grandeza, e não especificamente a um número, como no 
exemplo abaixo. 
Figura 3 – Tamanhos/estimativas 
 
Os tamanhos/estimativas estão sendo dados por uma grandeza, e não 
por um número/valor. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 33, item 9. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
 
 
9 
TEMA 5 – PLANNING POKER 
É uma técnica de estimativa que busca o consenso. Apesar de 
usualmente ser utilizada no processo de planejamento ágil, não se trata da única. 
No Scrum, o planning poker é realizado durante o sprint planning metting. Nessa 
forma de estimativa, cada integrante tem à sua disposição um baralho de 13 
cartas, numeradas em uma sequência encontrada nos números de Fibonacci. 
Figura 4 – Planning poker 
 
 
O objetivo de utilizar esses números não lineares é que o intervalo entre os 
valores permite visualizar melhor as diferenças de complexidade entre as 
funcionalidades sugeridas pelo requisito/estória dessa forma, evitando a 
impressão falsa de precisão na estimativa. Exemplo: se para um item foi dada 
uma estimativa de 20 pontos, não faz muita diferença se pudesse ser dado um 
valor próximo. Portanto, esse valor trata-se de um palpite aproximado. 
Valores acima de 20 são considerados altos e, portanto, trata-se de uma 
estória/requerimento com um tamanho maior, que pode não ser completamente 
finalizada numa única iteração. 
O recomendável é que, ao final da estimativa, usando o planning poker, seja 
possível fazer com que as estórias/requerimentos da iteração tenham algum 
valor no intervalo de 1∕2 a 13. 
No baralho do planning poker, podemos encontrar algumas cartas com 
propósitos especiais: 
 carta com valor 0 (zero), indicando que uma estória está finalizada ou é 
muito pequena, podendo ser resolvida rapidamente; 
 
 
10 
 carta com ? (interrogação), indicando que o membro da equipe não tem o 
conhecimento apropriado para estimar/opinar sobre o esforço necessário 
para a estória/requerimento. 
Durante o planning poker, devem ser realizadas rodadas para obter a 
estimativa da estória/requerimento com base nesses valores. As diferenças que 
surgirem durante essas rodadas deverão ser mediadas por um coordenador. No 
Scrum, esse papel é de responsabilidade do scrum master. 
5.1 Planning poker – Jogando 
As estórias/requerimentos são apresentadas uma por vez. O product 
owner as descreve para a equipe Scrum de desenvolvimento e fornece 
informações a respeito do seu valor de negócio. A seguir, o coordenador 
pergunta aos membros da equipe o esforço necessário para desenvolvê-la. 
Cada membro da equipe reflete a respeito do tempo e do esforço 
necessários para implementar a estória/requerimento apresentado. 
 
Os membros da equipe estimam considerando todas as tarefas 
envolvidas no desenvolver (testar, criar design etc.). Então, o membro da equipe 
escolhe uma carta no baralho correspondente ao valor dessa estimativa e 
coloca-a virada para baixo. Quando todos fizerem o procedimento acima, 
revelam-se as cartas escolhidas simultaneamente. 
 
 
 
 
 
 
 
 
 
11 
Isso faz com que cada membro da equipe pense por si próprio na hora de 
uma decisão da estimativa. Todos avaliam os resultados e verificam se houve 
convergência entre as cartas mostradas, ou seja, todas as estimativas têm 
valores aproximados para a mesma estória/requerimento. 
Se não houver essa convergência, o scrum master solicita aos membros 
que mostraram o menor e o maior valor que expliquem o motivo que os levou a 
tal decisão. Isso faz com que os integrantes reflitam sobre alguns pontos da 
estória/requerimento, o que pode fazer com que mudem os valores propostos 
para as estimativas. Então, uma nova rodada é realizada até que as estimativas 
cheguem a uma convergência. 
 
A estimativa final será o valor que tiver maior ocorrência ou a média entre 
as estimativas informadas. Então, começa uma nova rodada com a leitura da 
próxima estória/requerimento pelo product owner. O processo se repete até que 
tenha sido concluída a estimativa das estórias dos itens do product backlog. 
Leitura obrigatória 
Para ampliar seus estudos, leia o capítulo 33, item 9. 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016. 
FINALIZANDO 
As metodologias ágeis seguem o parâmetro de sempre ter equipes de 
desenvolvimento que se autogerenciem, que tenham controle sobre o que estão 
desenvolvendo e tenham uma grande comunicação não só entre os membros 
das equipes para também com os clientes que recebem o produto desenvolvido, 
pois a ênfase aqui é que o cliente esteja recebendo constantemente entregas do 
desenvolvimento que agreguem ao seu negócio, trazendo, assim, sua 
satisfação. 
 
 
12 
REFERÊNCIAS 
PRESSMAN, R.; MAXIM, B. Engenharia de software – uma abordagem 
profissional. 8. ed. Porto Alegre: Amgh Editora, 2016.