Gestão de projetos de Software GTI-16

Apresentação em tema: "Gestão de projetos de Software GTI-16"— Transcrição da apresentação:

1 Gestão de projetos de Software GTI-16
Aula 4 Metodologias ágeis

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? Ger. Proj. de Software GTI - 16

3 Agilidade O que é agilidade? “Linha de pensamento” revolucionária
“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 Ger. Proj. de Software GTI - 16

4 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 Ger. Proj. de Software GTI - 16

5 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 Ger. Proj. de Software GTI - 16

6 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.) Ger. Proj. de Software GTI - 16

7 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 Ger. Proj. de Software GTI - 16

8 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 Ger. Proj. de Software GTI - 16

9 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 Ger. Proj. de Software GTI - 16

10 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. Ger. Proj. de Software GTI - 16

11 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 Ger. Proj. de Software GTI - 16

12 Conceitos básicos Papéis “Fases”
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 Ger. Proj. de Software GTI - 16

13 O processo Scrum Ger. Proj. de Software GTI - 16

14 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 Ger. Proj. de Software GTI - 16

15 Backlog do produto Ger. Proj. de Software GTI - 16

16 Backlog do Sprint Ger. Proj. de Software GTI - 16

17 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 Ger. Proj. de Software GTI - 16

18 Atualização do Sprint backlog
O ScrumMaster atualiza diariamente o backlog Ger. Proj. de Software GTI - 16

19 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 Ger. Proj. de Software GTI - 16

20 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. Ger. Proj. de Software GTI - 16

21 Práticas do XP Retorno detalhado Processo contínuo
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) Ger. Proj. de Software GTI - 16

22 Papéis “Dono da grana” (GoldOwner) “Dono dos objetivos” (GoalOwner)
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. Ger. Proj. de Software GTI - 16

23 Atividades Implementação Teste Escuta Projeto
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 Ger. Proj. de Software GTI - 16

24 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 Exploração: de requisitos a tarefas Aceitação: tarefas atribuídas e estimadas Ajuste: Tarefas são realizadas e a performance medida Ger. Proj. de Software GTI - 16

25 Atividade em grupo Ger. Proj. de Software GTI - 16