Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum

508 visualizações

Publicada em

Palestra apresentada no evento "Festival Latino Americano de Software Livre - FLISOL São Carlos"

0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
508
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
17
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum

  1. 1. Thiago Barros thiagosbarros02@gmail.com
  2. 2. Administrador Centro Paula Souza – Etec Pirassununga-SP Analista de Sistemas IFSP – Instituto Federal de São Paulo Mestrando em Ciências da Computação / Engenharia de Software UFSCar – Universidade Federal de São Carlos Professional Scrum Master Certified Scrum.org
  3. 3.  Como surgiu os métodos ágeis. ◦ Tradicional x Ágil  Scrum ◦ Motivação ◦ Papeis ◦ Processo  Ferramentas livre para o uso do Scrum ◦ AgileFant  https://github.com/Agilefant/agilefant ◦ ScrumDO  https://github.com/ScrumDoLLC/ScrumDo ◦ PrimeScrum  https://github.com/Barrostsb/Prj_Prime_Scrum ◦ LibreBoard  http://git.libreboard.com/libreboard/libreboard  Certificações Scrum
  4. 4.  Criados para organizar processos de desenvolvimento de software.  Cliente recebe o produto com 100% do projeto cumprido.  Tarefas divididas para serem realizadas de forma ordenada (Cascata), seguindo um passo a passo.
  5. 5.  São preventivos (Antecipa o erro por meio de documentações, análise e testes antes do código).  Resistente a mudanças.  Foco no processo.
  6. 6.  Standish Group´s 2011 CHAOS Report analisou projetos de desenvolvimento de software entre 2002 e 2010 e identificou que apenas 37% tinham sucesso. Fonte: Software in 30 days Ken Schwaber and Jeff Sutherland
  7. 7.  Projetos falham.  Requisitos mudam.  Funcionalidades que nunca serão utilizadas.  Apenas 42% das funcionalidades previstas no início estavam no produto final. http://www.projectsmart.co.uk/docs/chaos-report.pdf
  8. 8.  Dezessete especialistas em processos de desenvolvimento de software estabeleceram valores e princípios comuns criando o manifesto ágil. “O Manifesto Ágil é uma declaração sobre os princípios que servem como base para o desenvolvimento ágil de software” http://www.agilemanifesto.org/
  9. 9. Indivíduos e interações X Processos e Ferramentas Software funcionando X Documentação Extensa Colaboração com o cliente X Negociação e Contrato Adaptação a mudanças X Seguir Planos Rígidos
  10. 10. Fonte: Software in 30 days Ken Schwaber and Jeff Sutherland
  11. 11.  SCRUM é um modelo ágil de processo que esta de acordo com o manifesto ágil. Sommerville – Eng de Software  SCRUM é um framework estruturado para apoiar o desenvolvimento de produtos complexos. Scrum.org - Scrum Guide  SCRUM destina-se ao GERENCIAMENTO DE PROJETOS ÁGEIS. Wikipedia
  12. 12. AGREGAR VALOR para o cliente aos poucos e efetivamente, através dos REQUISITOS REALMENTE NECESSÁRIOS Fonte: Software in 30 days Ken Schwaber and Jeff Sutherland 35% em média dos requisitos de um projeto de software sofrem alteração durante o desenvolvimento do software. 60% das funcionalidades previamente planejadas e implementadas no software não são utilizadas ou são pouco utilizadas pelos usuários finais.
  13. 13.  Incorpora algumas características do XP.  Processo iterativo e incremental (Sprints).  Processo de gerenciamento e controle empírico (tentativa e erro).  Necessidades de negocio determinam as prioridades (P. O.).
  14. 14.  O cliente é proativo durante o processo.  Equipe focada na entrega do produto no menor tempo.  Inspeção Contínua do produto em intervalos (Sprints) de 2 a 4 semanas.  Equipes pequenas e auto gerenciáveis.
  15. 15. SCRUM se apoia em 3 pilares: 1)Transparência: Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados 2) Inspeção: Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo, para detectar indesejáveis variações. 3) Adaptação: Se a inspeção identificou desvios, o processo deve ser ajustado
  16. 16.  É alguém que CONHECE do produto e SABE como este produto pode AGREGAR VALOR AO NEGÓCIO.  Sabe como e quais funcionalidades podem agregar valor ao produto.  É o responsável pelo ROI do produto. Outras características: Gerenciar o backlog do produto. Priorizar e manter o backlog do produto. Define as requisitos do produto. Prioriza funcionalidades. Ajusta características/funcionalidades.
  17. 17.  É o time que desenvolve o incremento do produto.  É responsável pelo SPRINT BACKLOG.  Não possui gerente e é auto-organizável e tem o poder de organizar o seu próprio trabalho.  Deve ser TRANSFUNCIONAL.  Entre 3 e 9 membros.  Pode haver mudanças.
  18. 18.  É o responsável pela aplicação do Scrum.  Garante que o SCRUM seja entendido por todos e aplicado de forma correta.  É um papel gerencial, mas ele não é o gerente do projeto ou da equipe.  Facilitador (líder servo) que busca garantir que todas as regras e práticas do SCRUM seja seguido pelo time SCRUM.  Comanda o Daily Meeting.  Ele elimina os obstáculos.
  19. 19.  É uma lista contendo todas as funcionalidades, ou requisitos o que pode ser necessário no produto.  É definida e ordenada pelo Product Owner.  É definido no início do projeto, porém pode ser alterado e ter itens adicionados durante todo o projeto.
  20. 20.  Deve conter a descrição, prioridade e estimativa de esforço inicial dos itens. ◦ “Grooming” – trabalho de adicionar detalhes, estimativas e prioridades feita “extra sprint” pelo product owner apoiado pelo development team.
  21. 21.  Sprint Backlog é a escolha das funcionalidades que deverão ser implementadas na próxima Sprint.  Se traduz em uma lista de tarefas que o development team irá executar para contemplar o subconjunto de itens do product backlog selecionado.  O SB pode crescer ou diminuir durante uma SPRINT a medida que o time de desenvolvimento vai entendendo melhor quais atividades são necessárias para realizar a entrega do incremento.
  22. 22.  É o período de 2 ou 4 semanas no qual se realizam as tarefas do Sprint BackLog, e ao termino entrega-se o incremento.  Durante a Sprint acontecem as 4 outras cerimônias/eventos: ◦ Sprint Planning ◦ Dailiy Metting ◦ Sprint Review ◦ Sprint Retrospective
  23. 23.  Reunião que acontece no início de cada Sprint ◦ –É aqui que o trabalho a ser realizado na SPRINT é planejado por todo o time SCRUM.  É dividida em duas partes: ◦ O que será entregue como resultado do incremento da próxima Sprint?  Product Owner ordena o product backlog (antecipadamente).  Development team faz a previsão de esfoços dos itens que entrarão no sprint backlog (Planning Poker)  Scrum Team define o “Objetivo da Sprint” ◦ Como o trabalho necessário para entregar o incremento será realizado?  O time quebra em unidades menores os primeiros itens do sprint backlog.
  24. 24.  É uma reunião em pé de 15 minutos realizada diariamente;  Tem o objetivo de comunicar o andamento dos trabalhos deixando-o transparente para todos da equipe de desenvolvimento. (Kanban Board)  Cada membro responde 3 perguntas.  •O que foi completado desde a última reunião?  •O que será feito até a próxima reunião?  •Quais os impedimentos/obstáculos que estão no caminho?
  25. 25.  Acontece no final da SPRINT ◦ inspecionar o incremento e adaptar o Backlog do Produto (se necessário). ◦ Apresentar o que foi desenvolvido pela equipe durante o sprint: ◦ O Product Owner decide quais itens do backlog foram completados; ◦ Discute a melhor forma de repriorizar o product backlog para a próxima sprint; ◦ A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos; ◦ O Backlog do Produto pode também ser ajustado completamente para atender novas oportunidades.
  26. 26.  Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e ferramentas.  Identificar e ordenar os principais itens que foram bem e as potenciais melhorias.  Verificar desempenho da equipe.  Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho.
  27. 27.  É tudo aquilo que foi desenvolvido durante a sprint somado (integrado) com o que já foi desenvolvido nas sprints anteriores.
  28. 28.  Ferramenta Web para a gestão de desenvolvimento agíl de projetos.  Rica em recursos: Possui, Backlog, planning, burndown e ainda gestão de protifólios.  Desenvolvida em Java
  29. 29.  Ferramenta Web para a gestão de projetos ágeis com Scrum.  Possui, Backlog, planning, Taskboard, burndown.  Foco no Scrum  Desenvolvida em Python
  30. 30.  Ferramenta Web para gestão de projetos Scrum  Possui Gerenciamento de equipe, backlog, planning, taskboard, burndown.  Desenvolvida em Java, com bibliotecas JSF2 – PrimeFaces e JPA Hibernate.  Sistema desenvolvido como trabalho de conclusão de curso.
  31. 31.  Semelhante ao trello  Muito fácil de usar  Pode-se trabalhar em equipes
  32. 32. Criadores do Scrum Ken – Jeff Pioneira
  33. 33. LinkedIn https://br.linkedin.com/pub/thiago-barros-psm/44/996/553 GitHub https://github.com/Barrostsb E-Mail: thiagosbarros02@gmail.com thiago.barros@dc.ufscar.br
  34. 34.  Pressman. “Engenharia de Software” 6 Edição.  Sommerville. “Engenharia de Software” 8 Edição.  Schwaber, Sutherland. “Software in 30 Days: How Agile Managers  “Manifesto for Agile Software Development”. 2001. Disponível em http://www.agilemanifesto.org. Último acesso em 21 de Março de 2015.  Scrum Guide http://www.scrumguides.org/.  Canal IGTI youtube https://www.youtube.com/watch?v=gAGdRGin_tE  http://www.projectbuilder.com.br/

×