•
Realizaremos na quinta-feira, dia 18/06/2009, o 7º encontro do Scrum user-group de Recife, das 19:00 às 20:30, na sede da SWQuality, no Porto Digital, Recife Antigo. Nesse encontro, Eric Cavalcanti do C.E.S.A.R. apresentará o FireScrum, ferramenta para gestão ágil de projetos.
Se você deseja participar da organização ou assistir as conversas que os organizadores vêm tendo, se cadastre em nossa lista aqui. Contribua, exponha suas idéias, nos ajude a tornar esse user-group cada vez melhor!
Conto com a presença de vocês!
Quando? Quinta-feira, 18/06/2009, a partir das 19:00
Onde? Na sede da SWQuality, no Recife Antigo, Porto Digital.
Endereço SWQuality: Av. Barbosa Lima,149 Sala 106 – Edf. Alfredo Fernandes
Mapa aqui, ou abaixo:
Av. Barbosa Lima – Recife, Recife – PE, 50030-330, BRA
•
No mês de Janeiro, o Luciano Félix, um dos coordenadores do grupo de usuarios de Scrum de Recife, e instrutor do curso de Gestão Ágil de Projetos com Scrum da Especializa Treinamentos, foi aprovado pela Scrum Alliance no processo seletivo para Certified Scrum Pratictioner, tornando-se o primeiro CSP da região Nordeste.
Luciano também faz parte do programa de mentoring do Boris Gloger com o objetivo de tornar-se um CST (Certified Scrum Trainer), meta que fica cada vez mais próxima, visto que ser CSP é pré-requisito para ser elegível para se tornar um CST. Para saber mais detalhes sobre o processo de certificação da ScrumAlliance, conheça os detalhes aqui.
•
O pessoal do InfoQ Brasil traduziu recentemente um artigo muito bom do Mark Levinson, sobre como melhorar retrospectivas (original em inglês aqui). O artigo detalha algumas técnicas e dá várias recomendações sobre como conduzir retrospectivas eficientes e proveitosas – e não correr o risco de fazer uma retrospectiva morosa e monótona.
Esther Derby, co-autora do “Agile Retrospectives: Making Good Teams Great”, escreveu recentemente sobre algumas técnicas para melhorar as retrospectivas:
- Deixar os membros da equipe trabalharem - ficar em frente da sala e fazer todo o trabalho de escrever desencoraja os mebros da equipe de tomarem a iniciativa das idéias. Em vez disso faça-os escrevem tudo grandes post-it (usando marcadores escuros) – isso mantém todos envolvidos e encoraja ainda mais as pessoas quietas a participarem.
- Anotar fielmente – um facilitador (ou ScrumMaster) está aí para capturar idéias do grupo e não filtrar ou injetar sua própria idéia.
- Usar processamento paralelo – quando houver mais que uma ou duas áreas problemáticas para debater, quebre o grupo em dois ou três e faça uma análise das causas. Além de acelerar as coisas isso reduz a influência de uma ou duas vozes barulhentas na equipe.
- Deixar os membros da equipe tirarem conclusões – ocasionalmente os facilitadores (ou ScrumMaster) vão olhar para os dados brutos gerados pela equipe e dizer quais são suas conclusões sem permitir que a equipe faça seu próprio trabalho. Na verdade o facilitador está dizendo que não valoriza o feedback da equipe. Apesar de que pode levar algum tempo para que a equipe analise os dados por si só, eles chegam a melhores conclusões e tomam posse dos resultados e das ações a serem executadas.
- Teste de entendimento – após um curto período de debate é útil testar para ver se a equipe alcançou um entendimento comum (nem sempre na decisão final, algumas vezes apenas em algum ponto no meio do caminho). Uma decisão deve ser proposta e uma vez que todos tenham feito perguntas esclarecedoras, nós testamos isso usando o “Fist of Five“. Com esta técnica o número de dedos indica o grau de apoio: Cinco – eu gostaria que essa idéia fosse minha pois vou ajudar a mudar; Três – eu posso viver com isso. É a vontade da equipe; Um – existem questões que eu preciso discutir; Mão fechada – Ausência de voto, eu quero impedir o consenso e forçar mais discussão.
Para ver o artigo completo, clique aqui.
•
Introduzir uma nova metodologia de desenvolvimento de software tem seu próprio conjunto de desafios que podem ir de ‘resistência a mudança’ a ‘técnicas de adoção falhas’ resultando então em fracasso. Em uma série de artigos no Agile Journal, Cesário Ramos e Eelco Gravendeel falam sobre os desafios que eles vivenciaram enquanto trabalhavam com Scrum e suas observações, quando introduziram Scrum em várias organizações. Os autores sugerem que o conhecimento desses desafios e uma estratégia para superá-los faria o processo de adoção mais fácil para organizações planejando adotar Scrum.
Veja o artigo completo no InfoQ Brasil.
Esse post foi feito originalmente no InfoQ USA, e traduzido para português pela equipe do InfoQ Brasil.
•
A empresa de consultoria SWQuality inicia programa inovador em Maringa/PR. Ana Rouiller e Boris Gloger desenvolveram em conjunto uma metodologia para auxiliar o aumento da capacidade das empresas usando CMMI/MPS.BR e SCRUM que promete revolucionar os atuais processos da industria nacional, principalmente nas pequenas organizações de software.
No inicio de Dezembro, duas empresas de Maringá (SG Sitemas e DB1) começaram a receber orientações, e segundo os patrocinadores do projeto em menos de 2 semanas já começam a observar os resultados. As outras 8 empresas de Maringá iniciarão os trabalhos em Janeiro de 2009.
A SWQuality estará durante o mês de Janeiro/2009 visitando empresas situadas no Porto Digital e região, que estejam interessadas no mesmo programa. Segundo Ana Rouiller, a idéia é iniciar a orientação de um grupo de 10 empresas no inicio de Fevereiro. A metodologia que está sendo adotada não está focada em certificação, mas sim em aumentar a qualidade e produtividade da organização. A avaliação MPS.BR ou CMMI será conseqüência de um trabalho desenvolvido com foco principalmente no desenvolvimento da empresa de software.
Após o início dos trabalhos, Boris Gloger comentou:
O Brasil realmente me impressiona. Nesta última semana, iniciamos trabalhos de consultoria mesclando SCRUM e CMMI em um grupo de empresas no interior do Paraná, na cidade de Maringá. O mais incrível foi que após apenas 8 horas de consultoria nas empresas elas já começaram a utilizar SCRUM. Hoje Ana Rouiller, minha parceira neste trabalho, ligou para as empresas em busca de entender o andamento do projeto e segundo ela, wow! – Acreditem, já temos os primeiros bons resultados. Fico impressionado com a facilidade das empresas brasileiras de aceitarem novas idéias e realizar a mudança cultural necessária para seu desenvolvimento e crescimento. Realmente, o Brasil me impressona. (Boris Gloger)
•
Tradução do post original “Can Product Owner and Scrum Master be combined?“, no InfoQ USA, por Mark Levison.
Muitos times e organizações pequenas consideram em combinar os papéis de Product Owner (PO) e Scrum Master (SM) em uma única pessoa. É recomendável? Outras pessoas já fizeram isso? Quais são as opções?
De acordo com o Mike Cohn, autor do livro “Agile Estimating and Planning”, o Scrum Master é:
…responsável por garantir que o time Scrum vivencia os valores e práticas do Scrum. O ScrumMaster protege o time, se certificando que eles não se comprometam com mais itens de backlog do que eles podem entregar em uma Sprint. O ScrumMaster facilita a reunião de Daily Scrum, e é responsável por remover quaisquer obstáculos que são levantados pelo time durante essas reuniões. O papel de ScrumMaster é tipicamente preenchido por um gerente de projetos ou líder técnico, mas pode ser qualquer pessoa.
Em adição, o Scrum Master é responsável pela qualidade do trabalho do time.
Em tempo, o Product Owner é:
… (tipicamente alguém da área de Marketing ou um usuário chave no desenvolvimento interno) responsável por priorizar o Product Backlog. O time Scrum olha para o product backlog priorizado, e puxa as fatias mais altas do mesmo, os itens mais prioritários, e se compromete à entregar os mesmos durante uma Sprint. Estes itens viram o Sprint Backlog. Em retorno pelo seu comprometimento em entregar as tarefas selecionadas completas (as quais, por definição, são as mais importantes para o Product Owner), o P.O. se compromete que ele ou ela não vai trazer novos requisitos para o time durante a Sprint. Requisitos podem mudar (e a mudança é encorajada) mas somente os requisitos do product backlog, que não estão na Sprint. Uma vez que o time começou numa Sprint, ele se mantém completamente focado em entregar o objetivo daquela Sprint.
Como Matt Gelbwaks apontou, o P.O. é responsável por conceitos e idéias (ex: o backlog), enquanto o Scrum Master é responsável pela sua execução e qualidade. Então o P.O. quer mais funcionalidades, enquanto o Scrum Master está focado na execução e conclusão, em fazer as coisas acontecerem.
Tomek Wlodarek explica que os diferentes pontos de vista são somente metade do problema. A outra metade é o comprometimento com o tempo: “Aprendi que, em um ambiente corporativo, preencher o papel de S.M. é um trabalho full time para um time de 5 a 6 pessoas … e o papel de P.O. para aquele mesmo time exige 60% a 100% do tempo do P.O.”
Dan Rawsthorne, coach da Danube Technologies, escreveu:
Eu fiz, numa época passada onde eu não sabia fazer melhor… combinei os papéis de P.O., S.M. e arquiteto-chefe. Para manter o time auto-organizado, eu contava com a colaboração deles: “por este ponto de vista… mas por outro lado… o que eu deveria fazer?”. Funcionava, mas era muito, muito difícil, e eu jamais quero fazer isso novamente, e não vejo razões para outras pessoas tentarem também.
Tom Mellor também já viu essa combinação de papéis funcionar, mas chamou a atenção que era necessário ter uma pessoa com habilidades muito únicas, e que essa pessoa hoje é um coach em tempo integral.
Steve Eichert teve a resposta mais otimista, dizendo: “Assumindo que uma única pessoa é capaz de preencher ambos os papéis sem misturar e se confundir, me parece possível que ambos os papéis sejam assumidos por uma única pessoa, mas somente se isso for absolutamente requerido”. Entretanto, mesmo ele recomenda manter os papéis separados.
Por fim, Ken Schwaber chamou a atenção (em um treinamento CSM) que um ScrumMaster com muita experiência poderia cobrir as bases para o Product Owner, até que um P.O. apropriado pudesse ser identificado e treinado.
•
Essa dica eu peguei do Google Reader, a partir do BLOG do Grupo de usuários de métodos ágeis do RS. Vale muito à pena dar uma olhada, tanto no artigo publicado por eles como no site indicado. Confiram o post aqui, mas segue sua reprodução na íntegra abaixo:
Quando se fala em User Stories o assunto sempre parece simples. Ah, é apenas um texto pequeno sobre uma funcionalidade. Barbada!
Depois se começa a ver que existe livro sobre o assunto, que existem indicações como INVEST para garantir a uma boa qualidade de escrita e agora o Mike Cohn reativou um site sobre o livro. Lá você pode encontrar outros recursos como palestras e artigos.
Fora isto, uma coisa que achei legal, uma lista de ferramentas relacionadas a Metodologias Ágeis, para gestão de projetos, onde você pode escrever revisões sobre as mesmas!
Dúvidas sobre User Stories? Mande ela para a lista de discussão!
•
Recentemente, saiu no site da ScrumAlliance uma dica a respeito da ferramenta criada pela TangyOrange. A ferramenta é simples, e não tem pretensões: a idéia é ser um ScrumBoard para times distribuídos. Sem muitos enfeites, a ferramenta cumpre muito bem o seu papel: ser um ScrumBoard totalmente online. Simples assim! O custo da ferramenta é US$ 5.00 a cada 40 dias (não entendi essa de 40 dias…), um preço bastante justo.
Vale à pena conferir, para ver o site da ferramenta, clique aqui. Para testar e brincar num demo, clique aqui.
Dica: abra duas máquinas (ou dois browsers) lado a lado e mova um post-it de uma área à outra do quadro para ver a interação. Muito bom!
Tenho certeza que isso vai deixar muito ScrumMaster na vontade de colocar um monitor de 42″ na sala do time!
•
Uma pergunta recorrente, tanto na comunidade scrum-brasil como na minha atuação como agilista é a origem do nome do Scrum. Recentemente, houve essa discussão na lista, e o Pedro Reys explicou muito bem para todo mundo a origem do nome. Vou pegar algumas das palavras do Pedro emprestadas:
O termo Scrum é o nome de um tipo de jogada que acontece no jogo de rugby.
O termo foi utilizado pela primeira vez, no contexto de processo de desenvolvimento ou manufatura, por Ikujiro Nonaka e Hirotaka Takeuchi em um artigo chamado “The New New Product Development Game” publicado na Harvard Business Review em 1986. Este artigo está disponível na página da lista no yahoo-groups.
Dá uma olhada nesta apresentação feita em 2005 pelo Jeff Sutherland, um dos criadores do Scrum (modelo Agile neste caso
), sobre a sua origem:
http://www.infoq.com/presentations/The-Roots-of-Scrum