apresentando conceitos de scrum

Scrum

Friday, November 5, 2010

Quem eu sou?

• BCC na UFSCar de 92 a 95 - Moitta

• Automação e IA de 95 a 97 - IBM/Villares

• Software de Controle de trens em 97 - Alstom

• Internet a partir de 97 - UOL–e-mail–autenticação–gestão de times de mídias digitais e BD


Agenda

• O que é o Scrum e por que o escolhemos?

• Intervalo

• Como foi a transição? Como convencer a alguém mudar?


Processo antigo no UOL

• Variação do RUP• Criado por 3 pessoas influentes em

desenvolvimento entre 80 e 90• Contexto:

–um dos criadores trabalhou na Ericsson entre 67 e 87

–criou diagramas e reforçou iteratividade–grande evolução–modelagem muito detalhada antes de iniciar

• Visão, casos de uso e diagrama de deploy


Processo Antigo no UOL


Proposta

SCRUM


Scrum – de onde veio isso?


Scrum pelado ?


Por que Scrum?


Por que Scrum?

Curso+

Livro+

Relatório do Y!


Motivações do Scrum

Desconfiança mútua

Falta de integração

Software não se fabrica


Como é o Scrum?

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas

SPRINT Demo release Next

Sprint

SprintRetro


Scrum – mudança da cultura para todos nós

Pior para gerir mudanças

Melhor para gerir mudanças e menos insatisfação


Definição detalhada, profunda e prévia

Estoque


Risco de aprofundar e detalhar rapidamente

Descarte


Como saber mais do produto?

• Aos poucos, mas de maneira estruturada

• Escrita de documento de visão com uma ou duas páginas – sem requisitos na visão – somente idéias

• Escopo e estratégia do produto precisam estar definidas

• Kick off para apresentar ao UOL

• Escrita dos primeiros itens do roadmap


Como saber mais do produto?

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas


Sprint

SprintRetro


Sprint planning

Cliente no controle da definição

Clarificação de requisitos do roadmap – prioridade definida

pelo cliente

Cada membro é independente do outro

Não deixe as perguntas para mais o experiente

Todos os participantes do projeto escutam e perguntam


Sprint Planning TodaOferta (17/03/2008)


Sprint Planning TodaOferta


Momento de realizar

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas


Sprint

SprintRetro


Momento de realizar - Sprint

Implementar o que foi detalhado

Desenvolvimento vertical

Comprometimento

Reunião diária de 15 minutos para verificar

Time tem autonomia


Scrum team

Multidisciplinar (progamador java, programador C++, webmaster,

AD, QA, implantação, DBA, segurança, redes, etc.)

Tem que encadear a sequência de atividades definidas no sprint

planning sozinho

Tem que assumir responsabilidades sem

precisar do gestor funcional


Autonomia do time

Usar plataformas homologadas

Respeitar o trabalho e regras

de cada um

Quer mudar? Fale antes de iniciar


Monitorando o Sprint

Chegar ao 0


Sprint Review

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas


Sprint

SprintRetro


Sprint Review

Hora de mostrar o que foi feito

Escutar as opiniões

Investigar o que faltou


Sprint Retrospective

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas


Sprint

SprintRetro


Sprint Retrospective

Falar dos problemas

Falar dos acertos

Planejar ajustes rapidamente


Scrum revisão

Roadmap or Backlog

SprintBacklog

SprintPlanning

DailyScrum

Sprint SprintReview

3 semanas


Sprint

SprintRetro


Papéis no Scrum

Time


Papéis no Scrum

• Scrum master

– Proteger o time das interferências

– Tirar impedimentos

– Facilitar o trabalho

– Questionar o time

– Zelar pelo processo


Papéis no Scrum

• Gestor do produto (representante do cliente ou o próprio cliente)

– Gere o roadmap com a área de negócio e demais envolvidos

– Pertence ao “product owner team”


Scrum – Prazos


36

Como fazer funcionar no UOL?


O que mudou no nosso dia-a-dia?

• Teste de aceitação (funcional) automatizado

• Escrita de regras de negócios em wiki

• Questionar se o bug/ajuste em produção pode ser colocado no roadmap ou se o time tem de parar já

• Aprender a fazer o refactoring

• Questionar se um requisito de grande trabalho de desenvolvimento está bem estruturado e estável

• Parar de escrever casos de uso – pelo menos para sistemas novos

• Não agendar mais pessoal de webmaster e QA

• Entender o que o produto precisa, ao invés de perguntar pelo trabalho a ser feito


O que NÃO mudou no nosso dia-a-dia?

• Compromisso e vontade de aprender

• Pensar em – Escalabilidade

– Manutebilidade

– Custo no médio prazo da decisão de hoje

– Estratégia do produto versus a tecnologia a ser utilizada

• Entregar – DAP

– FTS

– Plano de teste do sistema

• Kick-off


Perguntas?

[email protected]

@alexmoitta

http://uol.com/trabalhe


mailto:[email protected]

mailto:[email protected]

apresentando conceitos de scrum

Technology

como saber

scrum prazos

processo antigo

nosso dia

scrum

friday

uol

dia