Desmistificando o scrum

Preview:

DESCRIPTION

 

Citation preview

Desmistificando o ScrumAlison Rodrigues de Souza

ABOUT ME!Alison Rodrigues de Souza:● Motociclista● Programador JAVA● Agilista ● Certificado Scrum Master.

CONTATOS

Site/Blog: alisonsouza.com.brTwitter: @AlisonRSouzaGitHub: AlisonSouza

VAMOS FALAR UM POUCO SOBRE HISTÓRIA...

VAMOS FALAR UM POUCO SOBRE HISTÓRIA...

O caos predominava.

NOS ANOS 60...

NOS ANOS 60...

Não tinham a menor idéia de como fazer um software.

NOS ANOS 60...

Mais da metade dos projetos falhavam.

NOS ANOS 60...

Eram superestimados.

NOS ANOS 60...

Não eram entregues e não se tinha previsão dequanto tempo levaria para desenvolver e entregar

ENTÃO...

Caos

NOS ANOS 80...

Com base em todos as dificuldades encontradas na construção de software, surgiu a necessidade de mudar...

Com a “Crise do software” - o Departamento da Defesa norte-americano patrocinou a criação do SEI - Software Engineering Institute, em 1984.

NOS ANOS 80...

O Departamento tinha como objetivo alcançar o mesmo nível de repetibilidade e controle dos setores industriais.

O SEI tinha como desafio criar condições para a evolução da boas práticas da engenharia de software.

NOS ANOS 80...

NOS ANOS 80...

O SEI selecionou profissionais das áreas

de gestão e engenharia para criar um modelo de engenharia onde fosse

possível entregar software.

NOS ANOS 80...

Modelos de gestão definiam que para gerir um projeto é preciso dividir a equipe em:

* Profissionais do conhecimento;

* Profissionais de execução.

NOS ANOS 80...

Conhecimento:

NOS ANOS 80...

Execução:

NOS ANOS 80...

NOS ANOS 80...

Com base nas Engenharias Tradicionais foi definido que para entregar projetos

no tempo planejado era preciso de um processo bem

definido como linha de montagem ou linha de produção.

NOS ANOS 80...

Linha de Montagem:

NOS ANOS 80...

Assim nasceu a Engenharia de Software.

ENTÃO...

Caos Engenharia de Software

NOS ANOS 2000...Desenvolvimento de Software se parece com isso?

NOS ANOS 2000...

... ou isso?

NOS ANOS 2000...

Desenvolvimento de software é um trabalho intelectual, onde ações externas impactam na produtividade e no resultado final.

NOS ANOS 2000...

Algo estava errado, precisávamos mudar!

NOS ANOS 2000...

Em 2001, um grupo de profissionais e pensadores se reuniu para conversar sobre metodologias e práticas que vinham utilizando no gerenciamento de projetos de software.

NOS ANOS 2000...

Esse grupo, de comum acordo, criou o “The Agile Manifesto”, com 12 princípios que norteiam todos os métodos ágeis.Ainda hoje estes princípios servem como parâmetro para testar novos métodos ágeis e “agilistas” (praticantes de métodos ágeis).

NOS ANOS 2000...

NOS ANOS 2000...

Assim nasceu o movimento ágil!!!O movimento ágil surgiu de uma

ruptura do modelo da engenharia de software.

ENTÃO...

Caos Engenharia de Software Agile

AGILE

AGILE

Rápido:"Que se move depressa, com muita

velocidade"X

Ágil:"Que se move ou age com muita facilidade , destreza e rapidez"

Fonte: Dicionario Aulete / http://aulete.uol.com.br/

AGILE

OS 12 PRINCÍPIOS!!!

1. Satisfazer o cliente, através da entrega adiantada e contínua de

software de valor.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.

3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos

mais curtos.

OS 12 PRINCÍPIOS!!!

4. Pessoas relacionadas à negócios e desenvolvedores trabalharem em conjunto e diariamente, durante todo o curso do projeto.

5. Construir projetos ao redor de indivíduos motivados.

OS 12 PRINCÍPIOS!!!

6. Por mais conversa cara a cara.7. Por mais Software funcional. 8. Processos ágeis promovem um

ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

OS 12 PRINCÍPIOS!!!

9. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

10. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

OS 12 PRINCÍPIOS!!!

11. As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12. O time refletir em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

OS 12 PRINCÍPIOS!!!

Mas o desenvolvimento de software ainda apresentava muitos problemas...

TEORIA DA COMPLEXIDADE

SCRUM

SCRUM

SCRUM

Framework com o qual as pessoas podem resolver problemas

complexos e adaptáveis enquanto entregam produtos de forma produtiva e criativa com

maior valor possível.

SCRUM

...é leve, simples de entender, mas difícil de aplicar.

Quais as principais dificuldades para colocar scrum na prática?

● [ 51% ] Habilidade para mudar a cultura organizacional

● [ 40% ] Resistência geral a mudança● [ 40% ] Disponibilidades das pessoas com as

habilidades necessárias● [ 34% ] Suporte da Gestão● [ 31% ] Complexidade ou tamanho do

projetoFonte http://www.adaptworks.com.br/blog/2012/01/11/o-dilema-do-scrummaster/

SCRUM

● [ 29% ] Colaboração do Cliente● [ 21% ] Confiança na habilidade para escalar

Agile● [ 19% ] Tempo percebido para transição● [ 13% ] Restrições de orçamento● [ 12% ] Nenhum● [ 06% ] Outros

Fonte http://www.adaptworks.com.br/blog/2012/01/11/o-dilema-do-scrummaster/

SCRUMQuais as principais dificuldades para colocar scrum na prática?

SCRUM

SCRUM

Ken Schwaber Jeff Sutherland

SCRUM

● Transparência: todo processo visível a todos que estão envolvidos na criação do produto.

● Inspeção: o processo deve ser inspecionado regularmente para detectar problemas.

● Adaptação: Caso existam problemas, adaptações devem ser feitas.

O Scrum pode ser analisado por um conjunto de:● Papeis● Cerimonias/Eventos● Artefatos

SCRUM

EVENTOS DO SCRUM

● Sprint.● Reunião de Planejamento da Sprint

(Sprint planning meeting).● Scrum Diário.● Revisão da Sprint.● Retrospectiva da Sprint.

EVENTOS DO SCRUM

SPRINT

DAILY SCRUM

Eventos do Scrum

ARTEFATOS DO SCRUM

● Backlog do produto.● Backlog da sprint.

ARTEFATOS DO SCRUM

SPRINT BACKLOG

BURNDOWN

SCRUMBUT

Ken fala sobre o que significa adotar "Scrum ... mas", ou ScrumBut:● "(Nós usamos o Scrum, mas) (fazer

Daily Scrum é muito em cima), (por isso só temos uma por semana)."

● "(Nós usamos o Scrum, mas) (não podemos construir um pedaço de funcionalidade em um mês), (por isso nossas Sprints são de 6 semanas de duração)."

SCRUMBUT

● "(Nós usamos o Scrum, mas) (Retrospectivas são um desperdício de tempo,) (de modo que não vamos fazê-las.)"

SCRUMBUT

O QUE NÃO É SCRUM

● Scrum não é um método da engenharia de software.

● Scrum não é um método da engenharia de software.

● Scrum não cuidará da qualidade do seu projeto.

O QUE NÃO É SCRUM

● Scrum não é um método da engenharia de software.

● Scrum não cuidará da qualidade do seu projeto.

● Scrum não fornece templates para Gerenciar Tarefas, Relatórios, Estimar ou para Coletar Requisitos.

O QUE NÃO É SCRUM

● Jogam baralho durante o trabalho.

MITOS SOBRE AGILE E SCRUM

● Não precisa planejar.

MITOS SOBRE AGILE E SCRUM

● Se eu usar Agile não posso ter CMMI ou outras certificações.

MITOS SOBRE AGILE E SCRUM

MITOS SOBRE AGILE E SCRUM

QUEM UTILIZA SCRUM?

MAIS INFORMAÇÕES

MAIS INFORMAÇÕES

PERGUNTAS?

Contatos: Site/Blog: alisonsouza.com.brTwitter: @AlisonRSouzaGitHub: AlisonSouza

OBRIGADO!