Enter SCRUM

6,574 views

Published on

Uma introdução ao SCRUM, palestra nível iniciante que apresenta o framework, seus atores, artefatos e cerimônias.
Sinta-se a vontade para baixar, copiar e distribuir. Apenas cite a fonte.
Palestra apresentada em faculdades por volta de 2012.

PS: Sobre a diferença entre entre Scrum Master e Gerente de Projetos, amadureci muito minha visão sobre isso, se quiser bater um papo, entre em contato.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,574
On SlideShare
0
From Embeds
0
Number of Embeds
4,580
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Enter SCRUM

  1. 1. ENTER SCRUM Breno Campos
  2. 2. TaSafo.org Safos@yahoogrupos.com.br
  3. 3. TaSafo.org Quem Somos? Comunidade de profissionais e estudantes de Tecnologia da Informação.
  4. 4. TaSafo.org Como ser um Safo? Entre na lista de discussão. Participe dos eventos. Venha pra frente. Compartilhe algo.
  5. 5. Quem é Breno Campos? • Bacharel em Sistemas de Informação – UFPa; • Especialista em Gerência de Projetos de Software – UFPa; • CSM – Certified SCRUM Master; • Membro do PMI – SP; • Trabalha a 4 anos com metodologias ágeis, principalmente SCRUM; • Não é desenvolvedor; • Aficionado por Gestão de TI; • Atualmente auxilia na Coordenação de uma Equipe de Desenvolvimento e presta consultoria de Gestão de Projetos;
  6. 6. ENTER SCRUM Breno Campos
  7. 7. • Intro • Pilares • Papéis • Cerimônias • Artefatos • Definição de Pronto • Considerações Finais
  8. 8. MANIFESTO ÁGIL Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo.
  9. 9. Nossos Valores: • Indivíduos e interação entre eles mais que processos e ferramentas • Software em funcionamento mais que documentação abrangente • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um plano
  10. 10. Nossos Princípios: • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. • Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  11. 11. Nossos Princípios: • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. • Software funcional é a medida primária de progresso. • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  12. 12. Nossos Princípios: • Contínua atenção à excelência técnica e bom design, aumenta a agilidade. • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. • As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.
  13. 13. Os pais da criança Ken Schwaber Jeff Sutherland
  14. 14. Origem do nome
  15. 15. O SCRUM NÃO É! Ferramenta Técnica Processo
  16. 16. Então, o que é?
  17. 17. É uma “fusão”!
  18. 18. Beleza, mas como o SCRUM roda?
  19. 19. De forma Iterativa
  20. 20. e Incremental...
  21. 21. O SCRUM é sustentado por 3 pilares.
  22. 22. Transparência Inspeção Adaptação
  23. 23. Pra quem não entendeu... << Patrícia Pilar
  24. 24. Transparência Os aspectos mais significativos do projeto devem estar visíveis para todos os envolvidos. Deixando claro o que está sendo feito, o que ainda será feito, e o que está pronto.
  25. 25. Inspeção Os envolvidos devem inspecionar os artefatos gerados, para verificar se o projeto está seguindo de acordo com o planejado, detectando variações de desempenho. Deve-se tomar cuidado com a frequência das inspeções para que não chegue ao ponto de atrapalhar o andamento do desenvolvimento;
  26. 26. Baseado nos resultados obtidos da inspeção, a adaptação realiza as alterações necessárias para que o projeto continue seu bom andamento, ou para consertar falhas; Adaptação
  27. 27. O SCRUM possui 3 papéis.
  28. 28. Equipe de Desenvolvimento • Auto gerenciáveis; • “Sem títulos” definidos; • TODOS são desenvolvedores;
  29. 29. Product Owner • • • • Responsável por Maximizar o ROI; Gerencia as demandas; Prioriza as tarefas; Garante que a E.D. entenda as tarefas; • Apenas UMA pessoa;
  30. 30. SCRUM Master • Líder Servidor; • Remover impedimentos; • Proteger a equipe;
  31. 31. SCRUM Master NÃO É Gerente de Projetos
  32. 32. Não delega tarefas; Não define responsabilidades;
  33. 33. Cerimônias
  34. 34. Objetivos • Criar rotinas; • Diminuir a quantidade de reuniões desnecessárias;
  35. 35. Time-Boxed Tempo limite definido!
  36. 36. Sprint • Principal cerimônia do SCRUM; • Todas as outras estão contidas nela; • Time-Boxing de 1 a 4 semanas; • Durante essa iteração (Sprint), é gerada uma release (uma versão utilizável do produto);
  37. 37. Sprint • A Sprint é blindada, o que foi planejado deve ser executado! • A Sprint pode ser cancelada, mas somente o Product Owner tem poder para isso. Seus motivos podem variar, como o cancelamento do projeto, mudança de tecnologia ou outros.
  38. 38. Sprint Planning • Reunião onde é Planejado o que será executado na Sprint; • Time-Box: 8 horas para uma sprint de quatro semanas e deve ser proporcional para sprints menores; • O time tenta prever o que ocorrerá durante a sprint (feriados, faltas, etc); • A equipe deve estimar as tarefas priorizadas pelo PO, e alocá-las na sprint, obedecendo a quantidade de esforço estimada.
  39. 39. Daily Meeting • Também conhecida como Stand up meeting é feita para sincronizar a equipe, deixar todos a par dos acontecimentos, e dos avanços de cada um; • Time-Box: 15 minutos, o motivo de ser uma “reunião em pé”, é para durar mais do que o necessário;
  40. 40. Daily Meeting • Três perguntas: • “O que você fez até aqui?”; • “O que você pretende fazer até a próxima daily meeting?”; • “Quais impedimentos você está tendo?”
  41. 41. Sprint Review • Os participantes dela são os integrantes do time Scrum (time de desenvolvimento, SM e PO); • Time-Box: 4 horas para uma sprint de 4 semanas e deve ser proporcional para sprints menores; • O P.O. verifica o que está pronto, e o que não está, é apresentado as tarefas realizadas;
  42. 42. Sprint Retrospective • É realizada para que o time possa se inspecionar, encontrar acertos e falhas, e pensar em meios de tentar corrigir o que não saiu como o esperado; • Ocorre entre a Sprint Review e o Sprint Planning; • Time-Box: 3 horas para uma sprint de um mês e deve ser proporcional para sprints menores;
  43. 43. Artefatos
  44. 44. Objetivo • Maximizar a transparência das informações.
  45. 45. Product Backlog • É o ‘container’ que guarda todas as tarefas definidas pelo PO; • É o PO que mantém o backlog, ou seja, ele inclui tarefas, retira tarefas e as ordena de acordo com suas prioridades; • Um backlog de produto dificilmente está completo, as primeiras iterações estabelecem requisitos iniciais, e com o passar dos ciclos o número de requisitos tende a aumentar;
  46. 46. Product Backlog • Vale lembrar, que o backlog de produto é dinâmico, o PO pode alterá-lo em qualquer parte do ciclo, pode adicionar tarefas, retirá-las, mudar prioridade de acordo com sua necessidade. Os itens de maior prioridade, devem ser melhor detalhados, visando manter a agilidade. Itens mais abaixo na lista de prioridade, não precisam estar tão detalhados, visto que ainda não entrarão na iteração.
  47. 47. Sprint Backlog • É o ‘container’ que recebe todas as tarefas que foram priorizadas e estimadas para a iteração corrente; • Deve estar visível para todos, afim de manter a transparência e mostrar a todos o que a equipe está realizando;
  48. 48. Sprint Backlog • Ao contrário do backlog do produto, este não é dinâmico. As tarefas que foram alocadas para uma sprint não podem ser retiradas, adicionadas ou trocadas; • O sprint backlog deve ser atualizado a medida que as tarefas forem sendo concluídas, para que toda a equipe possa ver o andamento dos trabalhos.
  49. 49. Gráfico Burndown • Tem por objetivo manter transparente o progresso da equipe. Demonstrando a “queima” das tarefas pelo tempo. • Começa no topo, indicando o total de pontos de esforço da sprint, e vai descendo com o passar do tempo (e da realização das tarefas).
  50. 50. Definição de Pronto • Esta definição deve ser válida para toda a equipe; • O que o time define como pronto? Um código que foi escrito? Escrito e testado? Escrito, testado e documentado?; • Resumindo, se alguém disser que o trabalho está Pronto, todos do time devem saber o que Pronto significa;
  51. 51. Finalizando “Papéis, artefatos, eventos e regras do Scrum são imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é Scrum. Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas.”
  52. 52. Tá Safo?
  53. 53. Obrigado! brenobcampos@gmail.com http://www.linkedin.com/in/brenobcampos http://www.coyoti.com.br/blog
  54. 54. Fontes: http://www.scrum.org/Scrum-Guides http://manifestoagil.com.br/ http://coyoti.com.br/blog/scrum-para-iniciantes-parte-1-de-2

×