Como iniciar com Scrum - Bate papo com um futuro Scrum Master

Oi pessoal,

eu comecei a orientar uma pequena empresa parceira em como iniciar a implantação do Scrum. Abaixo reproduzo meu e-mail para o membro da equipe q será o Scrum Master. Comentários? Aguardo contribuições....tenho muito interesse em conhecer diferentes realidades....
Um abraço

--------------------
Minhas sugestões:
1) Você deve ser o Scrum Master da equipe
2) Estudar um pouco de scrum para entender o linguajar, e os conceitos.
a) o que é e qual é o papel do Scrum Master ( http://blog.eof.com.br/2008/03/06/qual-e-o-papel-do-scrum-master/ )
b) entender os principais conceitos: Product Backlog, Sprint Backlog. Sprint Planning Meeting, Sprint Review, Planning Pocker

3) Criar o Product Backlog. Para isso, você deve interagir com o cliente. Ele é o Product Owner, e é ele quem sabe como gerar o Product Backlog, e é ele quem sabe priorizar este backlog. Sugiro, se necessário, criar um product backlog para cada produto do projeto ( Admin, Carrinho de Compras, Barramento SOA, etc).

4) Criar um release Backlog para o release 1. Definir releases, junto com o cliente. Pegue o Product Backlog e quebre ele em dois ou três releases. Esses passos 3 e 4 são trabalhosos, e depende do seu esforço e do esforço do cliente. Você provavelmente vai ter umas 3 reuniões DE TRABALHO com ele, cada uma de umas 4 horas de trabalho. Diga a ele que é isso que você quer, que a empresa precisa: de uns 3 dias, de 4 hs, de trabalho conjunto seu e dele para gerar Product Backlogs e Releases Backlogs.

5) Crie um conjunto de cartas de baralho para cada integrante da equipe. Cada um tem que ter um jogo completo dessas cartas. Sugiro comprar uma cartolina mais grossa e fazer as cartas. Tipo isso aqui: http://www.flickr.com/photos/tlaukkanen/488795952/sizes/m/ ...... os números das cartas são esses mesmos: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, e ?.

6) Junte toda a equipe e, juntos, façam um Planning Pocker, usando as cartas. Estimem cada item do backlog do Release 1. Como funciona este pocker:
- coloca-se no meio da mesa o item de backlog (ou fala-se o item).
- quem tiver dúvidas a respeito do item, pergunta, e as duvidas devem ser tiradas ali na hora. Todos devem entender o item de backlog.
- cada desenvolvedor escolhe uma carta. A carta representa os pontos de dificuldade de implementar o item de backlog. Um item muito facil de fazer é a carta 2. Um item dificílimo é a carta 40. As cartas menores que 2 e maior que 40 são para as exceções. Um item já feito recebe a carta ZERO.
- Após todos escolherem suas cartas, sem mostrar aos demais, todos juntos abrem suas cartas.
- Geralmente tem uma pessoa que escolhe uma carta de menor valor, e um outro que escolhe uma carta de valor mais alto. Por exemplo, um escolhe a carta 5 e outr escolhe a carta 20.
- O que escolheu o menor valor deve justificar porque escolheu um valor tao baixo. O que escolheu o maior valor deve fazer o mesmo: justificar.
- Após as justificativas, todos recolhem suas cartas e escolhem novamente outra carta (ou a mesma).
- Todos abrem suas novas cartas. Desta vez deve haver um consenso maior entre os participantes.
- Determine, finalmente, o valor de pontos deste item de backlog. O consenso é que determina. Se 4 escolheram a carta 13 e 1 escolheu a carta 20, 13 é o vencedor.
- E assim vai para todos os itens do backlog da Release 1. Faça na ordem de prioridade do backlog.

7) Marque um Sprint Meeting. Uma reunião com todos da equipe, você e o Product Owner (cliente).
a) a reunião é de 4hs de duração. Não mais do que isso. Se ela começar a passar de 4hs, interrompa a reunião. Uma das características do Scrum é o conceito de janela de tempo. O tempo é fixo. O que der pra fazer é feito, o que não der, não deu. Tanto para as reuniões, quanto para o tempo do Sprint (2 semanas).
b) O cliente pode repriorizar os itens do backlog, pois esses agora já estão estimados, e o cliente pode mudar a prioridade. O cliente deve determinar a ordem de prioridade dos itens deste backlog.
c) Nesta reunião apresenta-se a lista de itens do Release 1 Backlog para todos. Caso haja alguma dúvida por parte dos desenvolvedores, este é o momento de perguntar as dúvidas ao Owner. Pode-se até mudar as estimativas de pontos do item devido ao melhor entendimento do item. É importante a equipe perguntar TUDO: testes de aceitação, comportamento de tela, requisitos técnicos, etc). Você como Scrum Master tem o papel de provocar a equipe para perguntar e ter certeza de que a equipe está entendendo.
d) A partir desses, que já estão priorizados, a EQUIPE escolhe os itens que conseguirá se comprometer para a entrega ao final do Sprint. Quem diz o quanto consegue entregar é a equipe. Neste momento a equipe está se comprometendo a entregar aqueles itens de backlog. Com isso, criou-se o Sprint Backlog. A equipe deve considerar a completude da entrega: implementação, testes, documentação.
e) Pronto. Aqui então a equipe tem o Sprint Backlog. São os items que serão desenvolvidos no Sprint que se inicia.
f) Outro ponto importate é você, Scrum Master, não permitir que o cliente induza a equipe a aceitar mais itens do que conseguiria.
g) E finalmente: o Product Owner tem que se comprometer a não alterar o Sprint Backlog durante o sprint. Nessas 2 semanas que se iniciam, o Sprint Backlog NÃO muda.

8) Iniciar o Sprint de 2 semanas. Durante este período, seria bom a visita do Product Owner (cliente) regularmente. De 3 em 3 dias, ou algo assim. Desta forma a equipe tem a oportunidade de tirar dúvidas.

9) O Sprint se inicia com uma reunião da EQUIPE, sem cliente. Nesta reunião, o objetivo é quebrar cada item de backlog em Tarefas técnicas:
a) Modelagem
b) Criação de scripts de Banco de Dados
c) Implementação de Regras de Negócio
d) Estudo e avaliação de tecnologia
e) Implementação de testes unitários
f) Implementação de testes de integração
g) documentação
h) Implementação de Telas (html, css, javascript)
etc
- Cada item do Sprint Backlog deve ser quebrado em Tarefas.
- esta reunião pode ser logo em seguida da reunião de Sprint Planning Meeting que ocorreu com o Owner. Pode marcar o Meeting de manhã, e a reunião da equipe para quebrar em tarefas a tarde.

10) Primeiro dia do Sprint:
a) Você, Scrum Master, promove o Daily Meeting, que é a reunião diária de 15 min, em pé! Tem que ser rápida. Aqui, cada um diz o que fez ontem, os problemas que está enfrentando, e o que fará hoje (ou amanhã). A própria equipe se organiza em dizer quem fará quais tarefas. Sempre em ordem de prioridade dos itens do backlog.

11) Você, Scrum Master, deve deixar visível o Burn Down Chart. Desenhe ele no quadro para todos verem. Atualize diariamente, assim todos acompanharão o andamento do Sprint. Veja um exemplo aqui http://www.mountaingoatsoftware.com/system/hidden_asset/file/53/BurndownBarchart.xls
- Neste gráfico, a barra representa o total de pontos que ainda faltam no Sprint.
- É importante diferenciar entre os pontos planejados do Sprint (que foram escolhidos pela equipe para formar o Sprint backlog), e os pontos que surgiram ao longo do Sprint. Coisas imprevistas que apareceram e tiveram que ser feitas. Essas, devem entrar como tarefas extras, e devem ficar evidente, para que o cliente entenda qualquer atraso ou não entrega do que foi acordado.

12) Diariamente faça o Daily meeting, com todos da equipe, em pé. 15 min. Se houver algum problema, algum impedimento, que esteja causando paralisia da equipe, você como Scrum Master deve solucionar isso.

13) Durante o Sprint de duas semanas, você poderia atuar como um projetista de Protótipo de Telas. Sente com o cliente, entenda os itens do backlog do Release 1 que não fazem parte do Sprint 1 (ou seja, vc estará planejando o sprint seguinte, enquanto a equipe trabalha no sprint atual). Você poderia ir criando protótipo de telas que seriam aceitos pelo cliente, e direcionariam o desenvolvimento da equipe. Power point é uma ferramenta simples e eficiente para isso. Mando um exemplo em anexo.

O que todos deveriam saber sobre Mysql

Nestes tempos de desenvolvimento com frameworks que tentam (e conseguem) facilitar muito nossa vida abstraindo detalhes de baixo nível, muitas vezes deixamos de nos preocupar com o que se passa lá por baixo.


Mas, em aplicações que tendem a crescer, que com o tempo vão deteriorando em performance, muitas vezes os problemas estão no banco de dados, na forma como acessamos o banco, em como construímos nossas queries...

Esta apresentação aqui, apresentada no Sun Tech Days 2009, é muito boa para quem usa Mysql.

Abcs

Grails e Cloud: desenvolvimento, deploy, execução e monitoramento. Ciclo completo com Grails na Nuvem.

No início havia muitas dúvidas se o Grails iria ser útil para aplicações grandes, ou de grande porte. Mas peraí, o que é uma aplicação grande? eBay é gigante. Se considerarmos uma medida, aí acho que podemos definir grande. Page-views por mês, por exemplo, pode ser uma medida, já que é fácil de saber, de monitorar, etc.

Um eBay tem algo em torno de 15 bilhões de page-views por mês. A globo.com tem uns 2 bilhões de page-views/mês. Um Peladeiro.com.br tem 1,2 milhão de page-views/mês. O Peladeiro é pequeno, Globo.com é grande, eBay é gigante. Pelo menos na minha opinião, sem muito exercício científico.

Além da medida de grande número de acessos, há também: grande volume de dados, necessidade de alta disponibilidade e redundância, escalabilidade, hot swap, cluster failover, etc, etc....

Aí voltamos a pergunta original: o Grails é bom para isso? Dá pra confiar que uma aplicação grails serve para uma demanda de uma aplicação de grande porte?


Alguns casos reais confirmam que a resposta é sim. Por exemplo, o Linkedin.com usa Grails para algumas partes. Este site tem as seguintes características: 22 milhões de membros, 1,2 milhão de novos membros por mês. Acho que o site mesmo, quando vc acessa linkedin.com, não é em grails, apesar de ser em java. Mas há partes feitas em Grails.

Onde eu quero chegar afinal? Meu ponto é que acho que atualmente o Grails chegou aonde queríamos que ele chegasse: está maduro o suficiente, estável, performance boa o suficiente, há ferramentas para desenvolvimento, e agora há serviços prestados por fornecedores que dão suporte ao deploy, execução e monitoramento de uma aplicação grails na Nuvem (Cloud).

Um grande player neste mundo de Cloud é a Amazon, com seu AWS . Mas como desenvolver uma aplicação Grails para rodar neste ambiente virtual? A nuvem está lá, mas você não vê. Tem solução poder computacional escalável, solução de storage, de banco de dados relacional na nuvem, e muito mais....
Mas como usar isso tudo? Como fazer uma aplicação Grails rodar nesta infra poderosa, mas complexa?

Aí que eu acho que a SpringSource está dando um show! Primeiro os caras inventam o Spring, que é solução para DESENVOLVIMENTO. Depois começam a expandir para servidores, que é solução para EXECUÇÃO. Depois fornecem solução para ferramentas ajudando mais ainda no quesito DESENVOLVIMENTO. Aí lançam produtos para gerenciar e monitorar (MONITORAMENTO). Por último, lançam um serviço que te ajuda executar aplicações java na infra de Cloud da Amazon: Cloud Foundry.

E por último, os caras compraram a G2One, que era a empresa responsável por Groovy e Grails. O resultado é: Grails tá pronto para rodar em tudo isso citado aí em cima.

Portanto, no momento presente, você pode desenvolver uma aplicação Grails usando tudo que este excelente framework oferece, pode usar os plugins de eclipse para Groovy e Grails que a SpringSource está desenvolvendo, pode fazer deploy, execução e monitoramento da applicação na nuvem da Amazon usando o CloudFoundry (ou o Cloud Foundry Plugin pra grails). Isso é excelente!!! Sua aplicação grails fica escalável, podendo usar instâncias com balanceamento de carga (load-balance) em diferentes zonas de disponibilidade, pode usar replicação master-slave para seu Mysql, pode usar SSL no apache, monitoramento e restart automático de servidores que falham, auto-escala de instâncias do EC2 da Amazon (pagando apenas pelo o que usa), pode usar backup automático de dados com snapshots.......... tudo isso para uma aplicação grails rodando na nuvem, e você gerenciando via Web.

Na teoria é lindo. Temos que ver na prática agora.
t+