Gerenciamento e desenvolvimento ágil de software

1,072 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,072
On SlideShare
0
From Embeds
0
Number of Embeds
38
Actions
Shares
0
Downloads
59
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • 04/22/10
  • Gerenciamento e desenvolvimento ágil de software

    1. 1. Erick Herdy SCRUM M étodo ágil para gestão de projetos
    2. 2. Criação do modelo SCRUM <ul><li>Janeiro-Fevereiro de 1986; </li></ul><ul><li>Takeuchi e Nokana lançam “The New Product development Game” </li></ul><ul><li>Inicialmente, concebido para fábricas de autos e bens de consumo; </li></ul><ul><li>Equipes cross-functional ; </li></ul><ul><li>Scrum no Rugby; </li></ul><ul><li>Onze anos depois, Ken Schwaber formalizou a definição de Scrum e ajudou a implementá-lo em desenvolvimento de software em todo o mundo. </li></ul>
    3. 3. Introdução <ul><li>O que é metodologia? </li></ul>
    4. 4. Introdução <ul><li>Metodologia , é o estudo dos métodos ou os passos em um determinado processo . </li></ul><ul><li>A finalidade de uma metodologia, é captar e analisa r as características dos vários métodos disponíveis, avaliar suas capacidades , potencialidades , limitações , distorções e criticar os pressupostos ou limitações das mesmas. </li></ul><ul><li>Além de ser uma disciplina que estuda métodos, a metodologia é também considerada uma forma de conduzir a pesquisa. (pesquisa acadêmica) </li></ul>
    5. 5. Porque estudar métodos? <ul><li>Pesquisas indicam pouca ou quase nenhuma qualidade em softwares desenvolvidos; </li></ul><ul><ul><li>Cronogramas estourados, custos nas alturas....prejuizo...e prejuizo... </li></ul></ul><ul><ul><li>A necessidade dos clientes não são alcançadas ; </li></ul></ul><ul><ul><li>Má , péssima ou nenhuma comunicação com o cliente; </li></ul></ul><ul><li>A procura pela “ bala de prata ” (BROOKS – 1987) </li></ul><ul><ul><li>Problemas citados : Complexidade , Conformidade , Mutabilidade e Invisibilidade ; </li></ul></ul><ul><ul><li>Soluções : Linguagens de alto-nivel, Prototipação, Desenvolvimento incremental, bons desenvolvedores, bons projetistas ...... </li></ul></ul>
    6. 6. Heavyweight vs Ligthweight <ul><li>Heavyweigth (Plan-driven) </li></ul><ul><ul><li>Planejamento extensivo, processos bem definidos, reuso, visando produção eficiente e previsvel; </li></ul></ul><ul><ul><li>Aos poucos atingir a perfeição. </li></ul></ul><ul><li>Ligthweight (Agile Metods) </li></ul><ul><ul><li>Planeje , documente somente o suficiente ; </li></ul></ul><ul><ul><li>Individualidade e satisfação momentânea do cliente; </li></ul></ul><ul><ul><li>Ser bom o suficiente ; </li></ul></ul>
    7. 7. Valores e Diferenciais <ul><li>Nós estamos descobrindo melhores maneiras de desenvolver software, criando-o e ajudando outros a criar. Através desse trabalho, passamos a valorizar: </li></ul><ul><ul><li>Individuos e interações vs processos e ferramentas ; </li></ul></ul><ul><ul><li>Software operante mais do que documentações completas ; </li></ul></ul><ul><ul><li>Colaboração do cliente vs negociações contratuais ; </li></ul></ul><ul><ul><li>Responder e estar aptos a mudanças do que seguir um planejamento </li></ul></ul>
    8. 8. O que são metodologias ágeis? <ul><li>Desenvolvimento ágil de software (do inglês Agile software development ) ou Método ágil é um conjunto de metodologias de desenvolvimento de software . O desenvolvimento ágil, tal como qualquer metodologia de software , providencia uma estrutura conceitual para reger projetos de engenharia de software . </li></ul>
    9. 9. Para que? Qual a motivação? <ul><li>Minimizar o risco de desenvolvimento de software em prazos muito curtos; </li></ul><ul><li>Prover uma melhor comunicação entre os integrantes do projeto; </li></ul><ul><li>Entregar partes funcionais; </li></ul><ul><li>Alcançar o “suficiente” </li></ul>
    10. 10. Características de um AM (Agile model) <ul><li>É um modelo bom o suficiente, nada mais que isso, e que exibe as seguintes características: </li></ul><ul><ul><li>Atende ao seu propósito; </li></ul></ul><ul><ul><li>É inteligível; </li></ul></ul><ul><ul><li>É suficientemente preciso; </li></ul></ul><ul><ul><li>É suficientemente detalhado; </li></ul></ul><ul><ul><li>É suficientemente consistente; </li></ul></ul><ul><ul><li>Provê um valor positivo; </li></ul></ul><ul><ul><li>É tão simples quando possível. </li></ul></ul>
    11. 11. <ul><li>Pensem em AM não como ciência, mas sim como arte. </li></ul>
    12. 12. O que é uma AM ? <ul><li>Atitude, não processo prescritivo; </li></ul><ul><li>Suplemento aos métodos existentes. Ele não é uma metodologia completa; </li></ul><ul><li>É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades dos stakeholders do projeto; </li></ul><ul><li>É efetivo e é sobre ser efetivo; </li></ul><ul><li>É uma coisa que funciona na prática, não é uma teoria acadêmica; </li></ul><ul><li>É para desenvolvedores médios, mas não substitui pessoas competentes. </li></ul>
    13. 13. O que não é uma AM ? <ul><li>Não é uma bala de prata; </li></ul><ul><li>Não é um ataque à documentação, pelo contrário, AM aconselha a criação de documentos de valor para o projeto; </li></ul><ul><li>Não é um ataque as ferramentas CASE; </li></ul><ul><li>Não é para todo mundo. </li></ul>
    14. 14. Objetivos / Funções do SCRUM <ul><li>A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. </li></ul><ul><li>Teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum ; </li></ul><ul><li>Iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento. </li></ul>
    15. 15. Características do SCRUM <ul><li>Backlog vivo e ativo de todas as tarefas a serem feitas; </li></ul><ul><li>Sprint é a entrega de um conjunto fixo de itens em um determinado período de tempo. </li></ul><ul><li>Backlog de produto é mantido pelo “Product Owner” e é uma lista de requisitos que vêm do cliente; </li></ul><ul><li>Backlog de sprint é uma interpretação do backlog do produto e contém tarefas que serão realizadas durante o próximo sprint para implementar os principais itens no backlog do produto. </li></ul>
    16. 16. Como funciona?
    17. 17. Integrantes <ul><li>O SCRUM possui três figuras: </li></ul><ul><ul><li>Product Owner; </li></ul></ul><ul><ul><li>SCRUM Master; </li></ul></ul><ul><ul><li>SCRUM TEAM; </li></ul></ul>
    18. 18. Product Owner <ul><li>Define as funcionalidades do produto; </li></ul><ul><li>Decide sobre as entregas e o conteúdo; </li></ul><ul><li>É responsável pelo ROI (lucratividade); </li></ul><ul><li>Prioriza as funcionalidades de acordo com o mercado; </li></ul><ul><li>Ajusta as funcionalidades e prioridades com cada iteração, conforme necessário; </li></ul><ul><li>Aceita ou rejeita o entregável; </li></ul>
    19. 19. SCRUM TEAM <ul><li>Basicamente, consiste em uma equipe de 5 a 12 pessoas; </li></ul><ul><li>Durante a discução com o Product Owner, o objetivo do sprint é determinado e priorizado, e explorado minuciosamente, determinando pequenas tarefas; </li></ul><ul><li>O time se auto-organiza e os membros trabalham juntos para a entrega do delivery, sendo todos responsáveis pelo resultado; </li></ul><ul><li>É quem decide qual trabalho será feito e quais serão as responsabilidades atribuidas. Não existe uma pré-definição de responsabilidades: Todos devem estar aptos a trocar de papel com outro membro do time; </li></ul>
    20. 20. SCRUM MASTER <ul><li>Coach do scrum team; </li></ul><ul><li>Remove todos os impedimentos para que uma determinada tarefa seja realizada; </li></ul><ul><li>Trabalha constantemente procurando maximizar toda a eficiencia do time, e da condições que eles deem o melhor de si; </li></ul><ul><li>Esta sempre atento para as tarefas que deverão ser entregues no final de cada sprint; </li></ul><ul><li>Treinador, fixer e gatekeeper. Ele é o responsável por organizar as reuniões diárias; </li></ul><ul><li>Isola a equipe de interferências externas; </li></ul><ul><li>Sempre adota o “aqui-agora”; </li></ul><ul><li>Ele fica responsável por administrar as reuniões de retrospectiva do projeto, onde todas as decisões são revistas; </li></ul>
    21. 21. Iniciando um processo:Sprint Planning <ul><li>Product owner cria a lista com todas as requisições e especificações do produto; </li></ul><ul><li>SCRUM TEAM seleciona itens a partir do Product backlog que eles possam se comprometer a entregar; </li></ul><ul><li>Tarefas são identificadas; </li></ul><ul><li>É feito por toda equipe, e não apenas pelo SCRUM Master; </li></ul>
    22. 22. Reunião diária <ul><li>Todos os dias, no mesmo horário, o Scrum Master se reúne com todos os membros do time, e faz três perguntas básicas: </li></ul><ul><ul><li>O que eu fiz desde ontem? </li></ul></ul><ul><ul><li>O que eu irei fazer até amanhã? </li></ul></ul><ul><ul><li>O que me impede de ir adiante? </li></ul></ul><ul><li>Reuniões duram no máximo 15 minutos; </li></ul><ul><li>Preferencialmente, de pé =) </li></ul>
    23. 23. Sprint review <ul><li>A equipe apresenta o que atingiu durante o sprint </li></ul><ul><li>Tipicamente, toma forma de apresentação de um demo do produto funcional; </li></ul><ul><li>Informal; </li></ul><ul><li>Sem powerpoint; </li></ul><ul><li>A equipe inteira participa. </li></ul>
    24. 24. Entrega / Delivery´s <ul><li>Após a fase do sprint, cada entregável é entregue ao cliente, para ser testado e analisado; </li></ul><ul><li>Após o cliente validar os entregáveis, é criado um novo sprint backlog; </li></ul><ul><li>Uma nova fase se inicia, novos entregáveis a caminho. </li></ul>
    25. 25. Sprint Retrospective <ul><li>Periodicamente olhar o que funciona e o que não funciona; </li></ul><ul><li>Tipicamente de 15 a 30 minutos; </li></ul><ul><li>Feito no final de cada Sprint; </li></ul><ul><li>A equipe inteira participa e discute o que gostariam de: Começar / Parar / Continuar </li></ul>
    26. 26. Conclusões <ul><li>SCRUM pode ser aplicado em qualquer situação; </li></ul><ul><li>Metodologias ágeis tendem a se aproximar da realidade dos times de trabalho; </li></ul><ul><li>Não existe solução mágica, apenas times bem organizados e sincronizado; </li></ul><ul><li>Um time é diferente de uma equipe. No time, todos tem o mesmo objetivo final, todos são responsáveis </li></ul>
    27. 27. Riscos e Mitos no Desenvolvimento de soluções Web <ul><li>Riscos </li></ul><ul><ul><li>Atraso no cronograma; </li></ul></ul><ul><ul><li>Cancelamento do projeto; </li></ul></ul><ul><ul><li>Entropia de sistemas de produção; </li></ul></ul><ul><ul><li>Taxa de defeitos; </li></ul></ul><ul><ul><li>Incompreensão dos requisitos de negócios e sistemas; </li></ul></ul><ul><ul><li>Mudanças Constantes; </li></ul></ul><ul><ul><li>“ Scoope Scrip” (Invasão de requisitos) </li></ul></ul><ul><ul><li>Alta taxa de evasão de desenvolvedores. </li></ul></ul><ul><li>Mitos : </li></ul><ul><ul><li>Podemos coletar todos os requisitos de uma vez só; </li></ul></ul><ul><ul><li>Podemos antecipar todas as mudanças; </li></ul></ul><ul><ul><li>Podemos controlar completamente todo o projeto do software; </li></ul></ul><ul><ul><li>Custo de mudança é por natureza, maior a medida que o projeto avança; </li></ul></ul>
    28. 28. Exemplo <ul><li>A ponte mais alta do mundo </li></ul>
    29. 29. Obrigado <ul><li>Dúvidas? </li></ul><ul><li>Perguntas ? </li></ul><ul><li>[email_address] </li></ul>

    ×