gestão de projetos de software gti-16 aula 4 metodologias ágeis

Gestão de projetosde Software

GTI-16Aula 4

Metodologias ágeis

Ger. Proj. de Software GTI - 16 2

Metodologias tradicionais

• Fluxo do processo– Organização e sequenciamento de atividades gerando ou

atualizando artefatos até se atingir o objetivo do projeto.

• Idéia inicial: receita de bolo– “Se seguirmos todos os passos, o projeto terá sucesso”– FOCO PROCESSO

• Hoje– Tem-se mudado o foco para pessoas (áreas criativas)

• Ex: Documentação para comunicação (100 páginas)

– Tem-se dado atenção às mudanças• Ex. Quando documentação com 100 páginas será atualizada?


Agilidade

• O que é agilidade?– “Habilidade de criar e responder a mudanças do maneira

a aproveitar as mudanças no ambiente” (Highsmith)

• “Linha de pensamento” revolucionária– Precisamos parar de tentar evitar mudanças

• Metodologias ágeis– Coleção de práticas organizadas para modelagem e

desenvolvimento de software– “Filosofia” onde muitas “metodologias” se encaixam

• Definem um conjunto de atitudes e não processo prescritivo

– Completam alguns métodos existentes


Metodologias ágeis

• Reação às metodologias tradicionais• “Manifesto ágil“ (2001)

– Agile Alliance– Princípios

• Indivíduos e interações são mais importantes que processos e ferramentas

• Software funcionando é mais importante que documentação completa

• Colaboração com o cliente é mais importante que negociação com contratos

• Adaptação às mudanças é mais importante que seguir um plano


Características gerais

• Procuram minimizar riscos desenvolvendo software em pequenos espaços de tempo (iterações)

• Cada iteração é como um pequeno projeto– Planejamento, requisitos, projeto, codificação, testes...

• Objetivo de cada iteração– produzir componentes de software– Arquitetura vai sendo desenhada a partir da refatoração

dos componentes

• Enfatizam comunicação “cara a cara” em relação à documentação


Comparação com outras abordagens

• Métodos Preditivos vs. Adaptativos– Preditivos

• Enfatiza o planejamento de ações em detalhe• A equipe pode saber que funcionalidade e tarefas farão nas etapas

seguintes no processo de desenvolvimento• Mudanças podem obrigar a refazer todo o planejamento

– Adaptativos• Enfatiza as mudanças e suas conseqüentes adaptações• A equipe não sabe o que irá fazer a médio e longo prazo• Problemas são encarados a medida que eles chegam

• Métodos ágeis vs. Outros métodos iterativos– Iterativos

• Em geral, a iteração é definida por objetivo– Ágeis

• Iteração curta, em um tempo fixo, de algumas semanas (2-4 sem.)


Conceitos equivocados

• Métodos ágeis são geralmente comparados a metodologias orientadas ao “planejamento”– Não são orientadas à predição, porém há planejamento

• Geralmente associado ao estilo “cowboy”– Em geral, requer mais disciplina que metodologias

preditivas

• É uma metodologia a parte– Descrevem práticas, “atitudes” e princípios– Pode ser combinado a outros métodos

• AgileUP


Críticas

• Não provê documentação necessária– Dificuldades “após o projeto”

• Funciona apenas para equipes experientes– Práticas disciplinadas e rigorosas

• Pouca atenção ao projeto de software (arquitetura)– Em geral, a arquitetura é definida “de baixo pra cima”

• Requer uma grande mudança cultural na organização para ser adotado– Ex.1: necessidade do cliente fazer parte da equipe– Ex.2: Patrocinadores do projeto querem saber

exatamente o que será feito e quando


Quando usar o quê?

Metodologias ágeis Metodologias preditivas

Projetos pouco críticos Projetos altamente crítico

Equipe experiente Equipe iniciante

Com mudanças constantes Com poucas mudanças

Pequena equipe (≤ 10 ) Equipes maiores ( ≥ 20)

Equipe co-localizada Equipe distribuída

Cultura de adaptação Cultura de controle


Métodos ágeis em grande empresas

• “Microsoft Lauds 'Scrum' for Software Development Projects”, by David K. Taft. eWeek, 11 Nov. 2005– When Microsoft launched its long-awaited database and

tools products last week, the company acknowledged it would have to act faster to revise its products faster as customer needs grow.One way Microsoft's development teams intend to deliver on this is through the use of agile development methodologies, such as extreme programming and Scrum, company officials said.


Scrum

• Proposto por Ken Schwaber em 1996– “Controlled Chaos: Living on the Edge”. Cutter IT Journal– Especialista em metodologias orientadas a processo 80´s– Defende que desenvolvimento de software deve ser

“empírico”• Cada caso é diferente e deve ser adaptado

– “Gerentes de projeto são forçados a viver uma mentira – eles devem achar que são capazes de planejar, fazer predições e entregar os produtos (conforme planejado)”

• Scrum tem como premissa mudanças constantes• Define um framework p/ gerenciamento de projetos


Conceitos básicos

• Papéis– Proprietário do produto (gerente de produtos, cliente interno, etc)– ScrumMaster (Líder do projeto. Facilitador)– Equipe do projeto (Programadores, QA, Designer de interface, etc)

• “Fases”– Pre-sprint (reunião de planejamento do Sprint)

• Identificação de funcionalidades• Planejamento para o próximo Sprint

– Sprint• Período de desenvolvimento• Período fixo de 30 dias

– Pos-Sprint (reunião de avaliação do Sprint)• Rever o progresso do projeto• Mostrar o estado de funcionalidades para os clientes• Rever o projeto do ponto de vista técnico


O processo Scrum


Reunião de planejamento

• Proprietário do produto descreve as features prioritárias– Definição do Backlog do produto

• Equipe do projeto escolhe as features do backlog do produto para o backlog do próximo Sprint

• Ambos definem o objetivo do Sprint– Breve descrição do que seria sucesso ao final do Sprint

• Equipe pode se reunir para definir até onde podem ir no Sprint e negociar com o Proprietário do produto


Backlog do produto


Backlog do Sprint


Scrum diário

• Reunião rápida de acompanhamento diário• Não tem como objetivo em resolver problemas, mas

responder as questões– O que foi feito ontem?– O que será feito hoje?– Há algum impedimento no caminho?

• Não é uma atribuição de tarefas!!!• Dizer o que será feito de forma precisa

– Ex: “vou continuar trabalhando no portal” não diz NADA!

• Impedimentos sob a responsabilidade do ScrumMaster


Atualização do Sprint backlog

• O ScrumMaster atualiza diariamente o backlog


Reunião de revisão

• Reunião ao final de cada Sprint (30 dias)• Participantes

– Proprietário do projeto– Equipe do projeto– Clientes

• Equipe mostra o que eles alcançaram• O que oi alcançado é comparado ao objetivo do

Sprint (definido na reunião inicial)– É mais importante fechar o objetivo que as tarefas

individuais


XP – eXtreme Programming

• Criada por Kent Beck– Projeto da Daimler-Chrysler (de 1997 a 1999)

• Valores– Simplicidade

• Tente sempre desenvolver a solução mais simples possível• Soluções devem responder aos requisitos, e nada mais que isso

– Comunicação• Comunicação “cara-a-cara”; cliente na equipe

– Coragem• Colocar o cliente (chefe) a par de tudo• Fazer o que precisa ser feito (exemplo: jogar fora código ruim)

– Retorno• Dê retorno cedo, concreto (através de testes) e constantemente

– Respeito• Evite complicar o trabalho dos demais. Preserve a qualidade do código, do design.


Práticas do XP

• Retorno detalhado– Jogo do planejamento– Desenvolvimento dirigido a testes– Equipe completa (cliente sempre disponível)– Programação em pares

• Processo contínuo– Evolução do design (refatoramento)– Integração contínua– Pequenas releases

• Compreensão compartilhada– Projeto simples– Uso de metáforas– Padrões e convenções de código– Propriedade coletiva

• Bem estar da equipe– Desenvolvimento sustentável (40-horas / semana)


Papéis

• “Dono da grana” (GoldOwner)– Patrocinador (quem paga pelo software)

• “Dono dos objetivos” (GoalOwner)– Quem define os requisitos (em geral, um usuário)

• Gerente– Facilitador do projeto

• Testador de aceitação– Define os critérios de aceitação junto ao cliente

• Programador– Responsável pela implementação

• Rastreador– Coleta sinais do projeto (métricas). Avalia desempenho

• Técnico– Especialista do processo. Dá suporte à equipe que está mudando.


Atividades

• Implementação– Código é o item mais importante para o XP– Diagramação em ferramentas que geram automaticamente código,

também é considerado codificação

• Teste– Teste de código (testes unitários)– Testes de aceitação (se o que você fez corresponde aos requisitos)

• Escuta– Atividade realizada durante o “aprendizado” com o usuário

• Projeto– A medida que o sistema vai ficando complexo, mudanças no projeto

do software precisam ser adotadas


Jogo do Planejamento

• Planejamento de uma release– Determinar quais requisitos devem ser levados em conta para a

próxima release– Fases

• Exploração: requisitos do sistema

• Aceitação: concordância com os requisitos e a data da próxima release

• Ajuste: plano pode ser alterado e requisitos modificados

• Planejamento de uma iteração– Planeja as atividades e tarefas para os desenvolvimento– Fases

• Exploração: de requisitos a tarefas

• Aceitação: tarefas atribuídas e estimadas

• Ajuste: Tarefas são realizadas e a performance medida


Atividade em grupo

gestão de projetos de software gti-16 aula 4 metodologias ágeis

Documents