No mês de maio de 2009 o Brasil vai receber uma edição do Scrum Gathering. O Scrum Gathering é o principal evento de Scrum no mundo sendo organizado pela própria Scrum Alliance, provavelmente Ken Schwaber, Jeff Sutherland, Mike Cohn e outros grandes nomes da comunidade mundial estarão aportando em terras brasileiras. No momento 2 cidades estão sendo consideradas para receber o evento, Recife e São Paulo. O Alexandro Magno,CST faz parte do comitê organizador do evento e criou na página do grupo Scrum-Brasil uma enquete para que possamos opinar sobre qual cidade deve sediar evento. Lembrando que o resultado da enquete não é o único critério para a decisão final e sim apenas uma consulta a comunidade brasileira. Quem ainda não faz parte da lista Scrum-Brasil segue o endereço para se cadastrar e ter acesso a enquete: http://br.groups.yahoo.com/group/scrum-brasil.
Como eu nasci, moro e trabalho em Recife , gostaria muito que o Scrum Gathering acontecesse aqui. A cidade tem total capacidade para abrigar o evento, temos um do maiores polós de tecnologia no país com o potencial de se tornar um enorme case de adoção do Scrum, temos treinamentos surgindo, temos pessoas interessadas, temos um momento muito propício para a realização do Scrum Gathering em Recife. Se você também quer dar sua opinião, entre na lista e vote!
Pessoal, estou inagurando uma nova seção aqui no códigoÁgil, o Boris Gloger me deu a idéia de responder, pelo blog, perguntas que surgem durante meus treinamentos de Scrum pela Especializa, assim criei a seção QuickScrum, onde vou tentar responder de forma concisa essas dúvidas, espero que gostem.
O que está pronto no fim da sprint é para ser mostrado ou entregue ao cliente ?
Recife – Out/2008
Na reunião de Sprint Review o trabalho realizado pela equipe é demonstrado para o Product Owner, cliente e outros interessados no projeto. Mas a questão é diferenciar o que é o fim de uma Sprint e um Release. Dizemos sempre que a equipe deve produzir a cada Sprint um incremento de software potencialmente “entregável”, isso quer dizer o que o produto deve estar funcionando corretamente de acordo com as expectativas, mas por diversos motivos esse incremento pode não ser o suficiente para que o produto entre em produção, ou seja, gere um Release.
Gosto de citar o exemplo da indústria de vídeo games. Um jogo de Nintendo Wii, por exemplo, não pode ser lançado no mercado em pequenos pedaços, só faz sentido lançá-lo quando o mesmo estiver completamente pronto, mas isso não quer dizer que o seu desenvolvimento não possa ser feito em iterações de 2-4 semanas, sempre produzindo algo funcional para que o Product Owner possa validar, mesmo que não possa lançar nada ainda. Resumindo, o produto de uma sprint pode ser mostrado e entregue ao cliente, ele deverá decidir se o que recebeu já está maduro o suficiente para entrar em produção.
No último fim de semana realizamos nossa primeira turma do curso de Gestão Ágil de Projetos com Scrum, pela Especializa Treinamentos. Foram 2 dias bem divertidos, a turma parecia bastante interessada e perguntava bastante o que enriqueceu muito o curso. Alguns já estavam utilizando Scrum e puderam expor as dúvidas e problemas que enfrentavam no dia-a-dia da empresa.
Algumas semanas atrás coincidentemente apareceram em várias listas e sites, discussões sobre a utilidade e validade da polêmica Sprint Zero. Para começar a falar sobre isso, vou traduzir 3 opiniões sobre o tema de pessoas que respeito muito.
Alistair Cockburn:
“Tenho a impressão que alguém foi questionado sobre sua aplicação do Scrum enquanto fazia algo que não tinha valor de negócio no começo do projeto e inventou “Ah, isso é a Sprint Zero!” para manter os raivosos camponeses com machados longe da sua porta”.
Ken Schawber:
“Sprint Zero tornou-se uma expressão indevidamente utilizada para descrever o planejamento, que ocorre antes da primeira sprint”.
Boris Gloger:
“Meu comentário sobre isso é: Esqueça! Isso não tem fundamentos no Scrum. Construa algo, crie dados, uma Sprint Zero não cria dados, apenas uma outra nuvem de conceitos”.
Bem, já deu para perceber qual é a minha opinião sobre o assunto.
Uma Sprint Zero representa zero de avanço real do projeto (software funcionando), demonstra zero de funcionalidades prontas, acrescenta zero de dados sobre a velocidade do time e gera zero de informações sobre como o time trabalha.
Na maioria das equipes em que o gerente, ou chefe, atribue e direciona o trabalho do time, nomalmente o que vemos é o chamado “trabalho em paralelo” em que cada membro do time desenvolve sozinho uma funcionalidade prevista no escopo do projeto. Esse tipo de organização dá ao gerente a sensação de que várias funcionalidades estão sendo desenvolvidas ao mesmo tempo, o que deve garantir que o projeto não atrase. Bem, se analisarmos esse arranjo com um pouco mais de cuidado veremos que o que ocorre é exatamente o contrário.
Veja a figura:
Quando cada membro do time recebe uma funcionalidade para desenvolver sozinho, o trabalho na verdade será serializado e não paralelizado como se acredita, uma tarefa será executada após outra ser concluída e assim por diante, esse modelo, como vemos na figura, aumenta o risco de não termos nada de fato pronto para entregar e sim uma coleção de funcionalidades quase prontas. O que acontece é que quanto mais a data da entrega se aproxima, cada membro do time começa a trabalhar de forma apressada, sem preocupação com a qualidade, apenas com o objetivo de entregar a “sua parte” pronta. Além disso esse tipo de organização acaba com a colaboração dentro do time, já que o que interessa para cada um é entregar o que lhe foi passado, por que assim é que ele será cobrado.
Vamos analisar essa outra figura:
Aqui o time inteiro trabalha em conjunto na mesma funcionalidade e quando esta é completada o time passa a trabalhar na funcionalidade seguinte. Serialização!! Dirão alguns, nada mais incorreto. Desse jeito, todas as tarefas necessárias para concluir o item serão desenvolvidas de fato em paralelo pela equipe, e aí sim, estaremos diminuindo muito o risco do item não ser entregue. Além do que, esse modelo privilegia a colaboração e a comunicação do time, todos tem o mesmo objetivo, todos estão alinhados e o cliente receberá funcionalidades que estão verdadeiramente prontas.
De agora em diante, quando o seu gerente quiser “paralelizar” o trabalho do seu time, desenhe essas figuras para ele.
Na última quarta feira (15/10/2008) foi lançado o Scrum User Group de Recife. O lançamento aconteceu na nova sede da SWQuality no Porto Digital e contou com uma palestra do Boris Gloger sobre as dificuldades da adoção do Scrum e também com a presença do professor Sílvio Meira que falou um pouco sobre a importância do Scrum e de uma iniciativa como essa para o polo de tecnologia do estado, na ocasião também festejamos a inauguração da sede da SWQuality.
Inicialmente o grupo deve ser reunir na primeira quarta feira de cada mês às 17:00 também na sede da SWQuality, precisamos da ajuda de todos para fazer esse grupo um sucesso !!
Como eu disse no último post, durante o treinamento de CSM puder apresentar o case de implantação do Scrum na Solver, coloquei a apresentação no Slideshare e compartilho aqui com vocês.
Mais uma vez tive a oportunidade de participar, como assistente do Boris Gloger, num treinamento de CSM aqui em Recife, mesmo assistindo o treinamento pela terceira vez, sempre aprendo coisas novas. Como sempre a turma foi muito divertida e realmente interessada em aprender e aplicar na prática o conteúdo do treinamento, aproveito para agradecer a Ana Rouiller por permitir a minha participação.
Dessa vez puder apresentar um pouco mais do conteúdo do treinamento, além de apresentar o case de implantação do Scrum na Solver. Quem estava presente no treinamento, por favor, escrevam comentários sobre o que vocês acharam.