O documento discute o método ágil SCRUM para gestão de projetos. SCRUM foi criado em 1986 e formalizado em 1997, sendo usado principalmente para desenvolvimento de software. O método envolve sprints curtos, reuniões diárias, feedback contínuo do cliente e equipes cross-funcionais auto-organizadas. O documento também discute outros métodos ágeis e como SCRUM funciona na prática com papéis como Product Owner, Scrum Master e Scrum Team.

1. Erick Herdy SCRUM M étodo ágil para gestão de projetos

2. Criação do modelo SCRUM Janeiro-Fevereiro de 1986; Takeuchi e Nokana lançam “The New Product development Game” Inicialmente, concebido para fábricas de autos e bens de consumo; Equipes cross-functional ; Scrum no Rugby; Onze anos depois, Ken Schwaber formalizou a definição de Scrum e ajudou a implementá-lo em desenvolvimento de software em todo o mundo.

3. Introdução O que é metodologia?

4. Introdução Metodologia , é o estudo dos métodos ou os passos em um determinado processo . 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. Além de ser uma disciplina que estuda métodos, a metodologia é também considerada uma forma de conduzir a pesquisa. (pesquisa acadêmica)

5. Porque estudar métodos? Pesquisas indicam pouca ou quase nenhuma qualidade em softwares desenvolvidos; Cronogramas estourados, custos nas alturas....prejuizo...e prejuizo... A necessidade dos clientes não são alcançadas ; Má , péssima ou nenhuma comunicação com o cliente; A procura pela “ bala de prata ” (BROOKS – 1987) Problemas citados : Complexidade , Conformidade , Mutabilidade e Invisibilidade ; Soluções : Linguagens de alto-nivel, Prototipação, Desenvolvimento incremental, bons desenvolvedores, bons projetistas ......

6. Heavyweight vs Ligthweight Heavyweigth (Plan-driven) Planejamento extensivo, processos bem definidos, reuso, visando produção eficiente e previsvel; Aos poucos atingir a perfeição. Ligthweight (Agile Metods) Planeje , documente somente o suficiente ; Individualidade e satisfação momentânea do cliente; Ser bom o suficiente ;

7. Valores e Diferenciais Nós estamos descobrindo melhores maneiras de desenvolver software, criando-o e ajudando outros a criar. Através desse trabalho, passamos a valorizar: Individuos e interações vs processos e ferramentas ; Software operante mais do que documentações completas ; Colaboração do cliente vs negociações contratuais ; Responder e estar aptos a mudanças do que seguir um planejamento

8. O que são metodologias ágeis? 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 .

9. Para que? Qual a motivação? Minimizar o risco de desenvolvimento de software em prazos muito curtos; Prover uma melhor comunicação entre os integrantes do projeto; Entregar partes funcionais; Alcançar o “suficiente”

10. Características de um AM (Agile model) É um modelo bom o suficiente, nada mais que isso, e que exibe as seguintes características: Atende ao seu propósito; É inteligível; É suficientemente preciso; É suficientemente detalhado; É suficientemente consistente; Provê um valor positivo; É tão simples quando possível.

11. Pensem em AM não como ciência, mas sim como arte.

12. O que é uma AM ? Atitude, não processo prescritivo; Suplemento aos métodos existentes. Ele não é uma metodologia completa; É uma forma efetiva de se trabalhar em conjunto para atingir as necessidades dos stakeholders do projeto; É efetivo e é sobre ser efetivo; É uma coisa que funciona na prática, não é uma teoria acadêmica; É para desenvolvedores médios, mas não substitui pessoas competentes.

13. O que não é uma AM ? Não é uma bala de prata; Não é um ataque à documentação, pelo contrário, AM aconselha a criação de documentos de valor para o projeto; Não é um ataque as ferramentas CASE; Não é para todo mundo.

14. Objetivos / Funções do SCRUM A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum ; Iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

15. Características do SCRUM Backlog vivo e ativo de todas as tarefas a serem feitas; Sprint é a entrega de um conjunto fixo de itens em um determinado período de tempo. Backlog de produto é mantido pelo “Product Owner” e é uma lista de requisitos que vêm do cliente; 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.

16. Como funciona?

17. Integrantes O SCRUM possui três figuras: Product Owner; SCRUM Master; SCRUM TEAM;

18. Product Owner Define as funcionalidades do produto; Decide sobre as entregas e o conteúdo; É responsável pelo ROI (lucratividade); Prioriza as funcionalidades de acordo com o mercado; Ajusta as funcionalidades e prioridades com cada iteração, conforme necessário; Aceita ou rejeita o entregável;

19. SCRUM TEAM Basicamente, consiste em uma equipe de 5 a 12 pessoas; Durante a discução com o Product Owner, o objetivo do sprint é determinado e priorizado, e explorado minuciosamente, determinando pequenas tarefas; O time se auto-organiza e os membros trabalham juntos para a entrega do delivery, sendo todos responsáveis pelo resultado; É 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;

20. SCRUM MASTER Coach do scrum team; Remove todos os impedimentos para que uma determinada tarefa seja realizada; Trabalha constantemente procurando maximizar toda a eficiencia do time, e da condições que eles deem o melhor de si; Esta sempre atento para as tarefas que deverão ser entregues no final de cada sprint; Treinador, fixer e gatekeeper. Ele é o responsável por organizar as reuniões diárias; Isola a equipe de interferências externas; Sempre adota o “aqui-agora”; Ele fica responsável por administrar as reuniões de retrospectiva do projeto, onde todas as decisões são revistas;

21. Iniciando um processo:Sprint Planning Product owner cria a lista com todas as requisições e especificações do produto; SCRUM TEAM seleciona itens a partir do Product backlog que eles possam se comprometer a entregar; Tarefas são identificadas; É feito por toda equipe, e não apenas pelo SCRUM Master;

22. Reunião diária 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: O que eu fiz desde ontem? O que eu irei fazer até amanhã? O que me impede de ir adiante? Reuniões duram no máximo 15 minutos; Preferencialmente, de pé =)

23. Sprint review A equipe apresenta o que atingiu durante o sprint Tipicamente, toma forma de apresentação de um demo do produto funcional; Informal; Sem powerpoint; A equipe inteira participa.

24. Entrega / Delivery´s Após a fase do sprint, cada entregável é entregue ao cliente, para ser testado e analisado; Após o cliente validar os entregáveis, é criado um novo sprint backlog; Uma nova fase se inicia, novos entregáveis a caminho.

25. Sprint Retrospective Periodicamente olhar o que funciona e o que não funciona; Tipicamente de 15 a 30 minutos; Feito no final de cada Sprint; A equipe inteira participa e discute o que gostariam de: Começar / Parar / Continuar

26. Conclusões SCRUM pode ser aplicado em qualquer situação; Metodologias ágeis tendem a se aproximar da realidade dos times de trabalho; Não existe solução mágica, apenas times bem organizados e sincronizado; Um time é diferente de uma equipe. No time, todos tem o mesmo objetivo final, todos são responsáveis

27. Riscos e Mitos no Desenvolvimento de soluções Web Riscos Atraso no cronograma; Cancelamento do projeto; Entropia de sistemas de produção; Taxa de defeitos; Incompreensão dos requisitos de negócios e sistemas; Mudanças Constantes; “ Scoope Scrip” (Invasão de requisitos) Alta taxa de evasão de desenvolvedores. Mitos : Podemos coletar todos os requisitos de uma vez só; Podemos antecipar todas as mudanças; Podemos controlar completamente todo o projeto do software; Custo de mudança é por natureza, maior a medida que o projeto avança;

28. Exemplo A ponte mais alta do mundo

29. Obrigado Dúvidas? Perguntas ? [email_address]