Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho - PDF Download grátis
Download "Caso Prático: Java como ferramenta de suporte a um ambiente realmente colaborativo no método Scrum de trabalho"
Luzia da Cunha Jardim
1 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
2 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 2
3 Scrum como método de trabalho 3
4 Scrum como método de trabalho 4
5 Scrum como método de trabalho A visão: Imagem: 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. 5
6 Scrum como método de trabalho imagem: 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. 6
7 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! 7
8 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. 8
9 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. 9
10 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. 10
11 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 11
12 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! 12
13 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. 13
14 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 ;-) 14
15 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. 15
16 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. 16
17 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. 17
18 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. 18
19 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. 19
20 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. 20
21 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. 21
22 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 22