Caso Prático: Java como ferramenta de suporte a um ambiente

Caso Prático: Java como ferramenta
de suporte a um ambiente realmente
colaborativo no método Scrum de
trabalho
UOL Produtos – Rádio
UOL
Julho 2008
André Piza
Certified Scrum Master
Diretoria de Produtos - 7/21/2008
Agenda
•
•
•
•
•
•
Scrum como método de trabalho
A velocidade das mudanças
Ambiente colaborativo
Ambiente colaborativo e Java
Scrum no UOL
Resultado de negócios
Diretoria de Produtos - 7/21/2008
2
Scrum como método de trabalho
Diretoria de Produtos - 7/21/2008
3
Scrum como método de trabalho
Diretoria de Produtos - 7/21/2008
4
Scrum como método de trabalho
Imagem:http://tsuchong.blogspot.com/2008/01/oppressor-and-oppressed.html
•
A visão:
– Alguém, que possui um budget para investir, quer desenvolver um produto, ainda
sem forma: uma visão, um sonho.
– Este Investidor é chamado de Product Owner.
– Nem sempre o Product Owner é o cliente do produto, mas ele deve ser alguém que
sabe medir a eficácia de seu investimento e as devidas reações do mercado.
Diretoria de Produtos - 7/21/2008
5
Scrum como método de trabalho
imagem: http://www.agile-software-development.com
•
Product Backlog:
– Desta visão, o Product Owner elabora, coleta e prioriza uma série de requisitos que
geram valor para o seu negócio.
Diretoria de Produtos - 7/21/2008
6
Scrum como método de trabalho
•
Selected Product Backlog:
– O Time então escolhe o que quer fazer, baseado no tamanho de cada atividade e
na prioridade do P.O. tentando sempre, maximizar o Retorno de Investimento por
entrega.
– Pull Principle, o time escolhe o que consegue fazer !
Diretoria de Produtos - 7/21/2008
7
Scrum como método de trabalho
•
Planejamento da Entrega:
– O time então faz uma reunião técnica e faz um planejamento fino de todas as
atividades necessárias para entregar o selected product backlog.
– O time reafirma o compromisso e faz de tudo para entregá-lo no prazo.
Diretoria de Produtos - 7/21/2008
8
Scrum como método de trabalho
•
Daily Meeting:
– O time sincroniza suas atividades diariamente.
• O que eu fiz ontem ?
• O que estou fazendo ?
• O que farei amanhã ?
– Somente no Daily Meeting movem-se ou criam-se novas atividades, atualiza-se o
progresso das atividades e há o reporte do que foi finalizado.
– O que considera finalizado ?
• Testado no servidor de desenvolvimento (qualquer pessoa pode testar)
• Testes auditados pelo analista de qualidade.
Diretoria de Produtos - 7/21/2008
9
Scrum como método de trabalho
•
Review:
– O P.O. revisa item por item e aprova, ou pede mudanças no que foi entregue.
– As mudanças entram como novos itens de backlog e devem ser priorizadas.
Diretoria de Produtos - 7/21/2008
10
Scrum como método de trabalho
•
Retrospective:
– Momento para *o time* revisar tudo o que aconteceu e melhorar o processo e ações
individuais para os próximos Sprints.
•
•
•
•
•
Os principais eventos
O que foi bom
O que foi ruim
O que o próprio time pode melhorar
O que a organização pode melhorar
Diretoria de Produtos - 7/21/2008
11
A velocidade das mudanças
•
Contribuições:
– Qualquer pessoa da empresa (ou não) é encorajada a contribuir com novas idéias a
qualquer tempo e com qualquer necessidade que julgue necessário.
– O Product Owner (dono do budget) prioriza constantemente o backlog do produto
de acordo com sua análise de Retorno de Investimento.
– Nenhuma idéia fica sem análise !
Diretoria de Produtos - 7/21/2008
12
Ambiente colaborativo
•
Criando o ambiente colaborativo
– Facilitar a comunicação verbal e espontânea entre as pessoas.
– O ambiente deve ser multi-disciplinar.
– Todo valor de negócios é vertical, ou seja, todo o time participa igualmente da
entrega.
– Pull Principle, o time escolhe quais funcionalidades serão implementadas no tempo
de sprint e assume um compromisso de entrega para o *time*.
– Proteger o compromisso do time a qualquer custo, removendo impedimentos.
Diretoria de Produtos - 7/21/2008
13
Ambiente colaborativo
•
O compromisso:
–
–
–
–
–
–
Uma vez que o time firma o compromisso do que será entregue no sprint, o escopo não é
alterado.
Apenas Product Owner pode priorizar o backlog.
Apenas o time estima o tamanho das funcionalidades.
Não há discussões, quando há divergências, quem tem o token faz uma análise técnica do
problema e, depois de explicada, o time todo vota qual a decisão a ser tomada.
Nos Daily Meetings somente quem está com o token pode falar !
Somente o time pode pegar o token ;-)
Diretoria de Produtos - 7/21/2008
14
Ambiente colaborativo
•
Build Contínua:
– Você sabe exatamente onde está pisando !
– É mais do que uma simples ferramenta, é uma forma de organização das atividades
para o trabalho.
– Oráculo para saber o que foi terminado com sucesso.
– Avisa rapidamente em caso de falhas.
Diretoria de Produtos - 7/21/2008
15
Ambiente colaborativo
•
Build Contínua:
–
–
–
–
O time sabe quando terminou uma atividade, pois os relatórios quantificam esta informação. Eu
sei exatamente o que dizer na Daily Meeting.
Todos os testes são reaplicados a cada build de forma regressiva. Se eu quebrar a build em
qualquer ponto,então o que eu fiz não está pronto!
Todas as pessoas que precisam serão notificadas no menor tempo possível do estado da build.
Vai funcionar em QA e produção, as diferenças de ambiente são apenas de ambiente, se o
processo for seguido o deployer saberá o que fazer.
Diretoria de Produtos - 7/21/2008
16
Ambiente colaborativo e Java
•
•
Para implementar os conceitos de build contínua é preciso suporte de
ferramentas.
A plataforma Java possui ferramentas open-source maduras para
organizar sua build contínua.
Diretoria de Produtos - 7/21/2008
17
Ambiente colaborativo e Java
•
O que nós utilizamos:
– Continuum como gerenciador de build.
– Maven 2 como padrão de projeto.
– Relatórios de acompanhamento:
• Jdepend – Visão geral da arquitetura e existência de
dependências cíclicas
• Cobertura – Quantos % do código está coberto por testes
• Findbugs – Ótima ferramenta para evitar futuros problemas
• Changelog – Quem fez o que no SCM
• Changes – Visão de alto nível do release notes de versões.
Diretoria de Produtos - 7/21/2008
18
Ambiente colaborativo e Java
•
Maven 2:
–
–
–
–
–
–
–
Centralização das informações gerais do projeto.
Processo de controle: Site do Projeto.
Portabilidade entre ambientes: Filtros e Profiles.
Garantias de entrega: Execução de Testes.
Empacotamento da aplicação: Assembly e Archetype.
Fechamento da release integrada com ferramenta scm.
Gerenciamento de dependências.
Diretoria de Produtos - 7/21/2008
19
Scrum no UOL
•
Vantagens observadas:
–
–
–
–
–
–
–
–
Menos artefatos de meio do processo.
O planejamento é curto e eficaz: 2 horas de SP2 para 2 semanas de atividades, com todos os
comprometidos participando.
O próprio time se monitora e consegue ser pró-ativo quando percebe que está fora do prazo.
A monitoração é diária e detalhada (task-a-task)
Menos insumos materiais para iniciar. O planejamento só alcança as próximas 2 semanas.
Menos documentação, porém, mais assertiva e focada na entrega.
Entregas curtas com maior previsibilidade e melhor cálculo de riscos.
As pessoas não trabalham mais rápido, mas erram menos e focam mais nos resultados, já que
as entregas são mais específicas.
Diretoria de Produtos - 7/21/2008
20
Scrum no UOL
•
Desvantagens:
–
–
–
–
–
–
Dimensione: mais gente para compor os times ou menos projetos simultâneos.
Faça o planejamento na utilização de salas de reunião, estarão sempre ocupadas.
A implantação do processo costuma ter resistência, por tirar as pessoas de sua zona de
conforto.
Pode ser difícil equalizar o conceito de atividade pronta, inicialmente.
Cuidado para não sobrepor os interesses de um projeto à estratégia global da empresa.
Difícil compatibilidade com modelos organizacionais funcionais/ matriciais fracas.
Diretoria de Produtos - 7/21/2008
21
Resultado de negócios
•
Negócio sempre ganha
•
Processos que resistem à mudança
do negócio fracassam no médio
prazo
•
Entregas do scrum são pequenas
funcionalidades – cliente decide e
prioriza
•
Tempo menor para ter algum
benefício avaliado ou em produção
Diretoria de Produtos - 7/21/2008
22
Fim
Perguntas?
Diretoria de Produtos - 7/21/2008
23