Todo ano a VersionOne realiza uma pesquisa em nível mundial sobre o estado do desenvolvimento ágil. É disso que falaremos no post de hoje.

Para fins de comparação, eu já fiz um post como esse retratando dados da pesquisa anterior. Você pode acessar esse post através deste link e conferir as sutis mudanças que ocorreram durante o intervalo de um ano. Mas não se preocupe, vou destaca-las aqui.

Para elaborar essa pesquisa foram entrevistados 3501 profissionais de TI. Destes, cerca de 88% possuem conhecimentos de práticas ágeis, refletindo num aumento de 7% em relação à pesquisa anterior.

A maioria dos entrevistados afirmou que utilizam técnicas ágeis há aproximadamente 2 a 5 anos. Os mais experientes, com tempo de agilidade acima de 5 anos, corresponderam a 19% dos entrevistados. Um aumento de 9% em relação a pesquisa realizada 2 anos antes.

Dentre os entrevistados, a maioria eram gerentes de projeto, scrum master e líder de equipe, seguido por membro de equipe de desenvolvimento. O gráfico a seguir ilustra esses perfis.

Vamos agora a outros gráficos interessantes dessa pesquisa!

A seguir, o percentual de projetos da organização que adotam métodos ágeis. Essa medida nos permite visualizar o quanto as empresas do mercado que trabalham com agilidade estão conseguindo empregar essas técnicas em todos os seus projetos.

A faixa de 0% – 25% aparece na pesquisa anterior com 31%. Atualmente esse número baixou para 27%, tendo esses pontos percentuais divididos entre as outras faixas. Uma pequena mudança, mas na direção desejada. 

O Scrum continua sendo a metodologia mais utilizada, seguido pelo híbrido de XP/Scrum, com porcentagens parecidas com a outra pesquisa. Por aqui o cenário permanece inalterado.

O gráfico acima corresponde à quantidade de entrevistados que afirmou utilizar ou não cada uma das técnicas ágeis mencionadas. Comparando com a pesquisa anterior, a maioria das técnicas teve uma pequena melhora, algumas poucas uma leve queda. O destaque fica por conta do Kanban (de 32% para 39%) e uso do Quadro de Tarefas Digital (de 39% para 45%). A melhoria do número de pessoas que utilizam o Quadro de Tarefas Digital provavelmente está relacionada a queda de 24% para 22% no uso do Quadro de Tarefas Não-Digital.

Esse crescente uso de ferramentas para apoio a agilidade é para nós um incentivo a continuar com o bom trabalho para continuarmos aprimorando o Scrumhalf.

Por fim, cada entrevistado respondeu as principais razões para adoção de métodos ágeis na sua equipe ou organização. Os números são bem parecidos com o da pesquisa anterior, não havendo nenhuma mudança em destaque.

As 3 respostas mais abaixo no gráfico acima foram as consideradas mais importantes. Notamos que a maioria das respostas está centrada em aprimorar o foco no cliente.

As pesquisas completas (em inglês) estão disponíveis no site da VersionOne, ou você pode acessá-la diretamente através deste link.

Um abraço e até o próximo post.

The post O Estado do Desenvolvimento Ágil appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Fim do ano chegando. Acredito que muitas pessoas já devem estar começando a rever como foi seu ano, se as metas feitas no ano passado se cumpriram, que objetivos conseguiram atingir. Por isso, no post de hoje falaremos sobre retrospectiva.

Ao longo do tempo já tivemos aqui no blog algumas postagens sobre retrospectiva. Seguem alguns links úteis:

– Retrospectiva fim de ano

– Retrospectiva Ágil

– Técnicas para fazer uma reunião de retrospectiva no Scrum

Apresento a seguir um compilado de dicas do que fazer e do que não fazer para ajudar no sucesso da reunião de retrospectiva:

ISSO SIM

Deixar todos os participantes bem à vontade para expressarem os problemas que possam estar acontecendo. Sabemos também, que em todo grupo existem aqueles que são mais tímidos e introvertidos. Vale a pena dar uma "mãozinha" para que estes se soltem e também contribuam com a retrospectiva. Se estas pessoas não se manifestarem um "Fulano, o que você acha? Concorda?" já os colocará na discussão.

Não intimidar na hora de perguntar. Por exemplo: Perguntar “O quê mais?” é mais amigável e menos intimidador do que perguntar "Tem mais alguma coisa?". Essas pequenas atitudes contribuem para a participação.

Levar joguinhos, afinal todos gostam de joguinhos! Na internet é possível encontrar diferentes maneiras de realizar uma retrospectiva. Pesquise, experimente, com certeza existe alguma dinâmica que irá se encaixar com o momento do seu projeto.

Mostrar os resultados positivos, as conquistas de retrospectivas anteriores é sempre uma boa maneira de fazer com que a equipe veja a importância da reunião de retrospectiva e, consequentemente, aumentar a motivação.

ISSO NÃO 

Frases desmotivadoras como “Estamos perdendo muito tempo” não agregam valor. Se realmente o tempo estiver sendo perdido o ideal é mudar o foco/rumo sem jogar a estima lá embaixo. Experimente introduzir direto o novo assunto, como “Vamos agora falar de _____________________”.

Perder o foco. Mesmo que a retrospectiva esteja bem animada e descontraída, com todos participando, isso pode ser um perigo. Mantenha o foco para que toda essa energia e vontade de contribuir sejam direcionadas para o que realmente irá trazer valor.

Procurar o culpado não traz ganho algum. Se algum problema aconteceu, ou algo não saiu como esperado, o problema é da equipe inteira e não de uma pessoa. Ao invés de procurar o culpado, a equipe ganha discutindo e criando soluções para prevenção de novos problemas.

Espero que essas dicas possam contribuir para que a retrospectiva seja um sucesso. Conforme uma das dicas, não se sinta acanhado/a e nem tímido/a. Aproveite a área dos comentários para dizer se gostou ou não do post e que outras dicas você tem a acrescentar.

Um abraço e até o próximo post.

Fontes:

• https://www.scrumalliance.org/community/articles/2014/july/dos-and-don-ts-of-agile-retrospectives
• http://intland.com/blog/project-management-en/tips-and-tricks-to-make-the-most-of-your-retrospectives/

The post Dicas para Retrospectiva appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No post de hoje eu comento e dou algumas dicas do que podemos fazer quando o Scrum Master está de férias. Sintam-se a vontade para comentar e contribuir com novas opiniões e ideias.

No início do ano passado, Ester escreveu um post sobre cuidados que devemos ter ao acumular papéis no Scrum. Em outro post ela nos apresenta algumas dicas para o Scrum Master que está prestes a sair de férias. No post de hoje iremos ver algumas dicas a partir do ponto de vista da equipe de desenvolvimento.

Scrum Master é um papel e não uma pessoa específica. Quando o Scrum Master sai de férias é uma boa oportunidade para a equipe melhorar sua auto-organização. Se o período de férias for grande (maior que duas Sprints) acredito que o papel poderia sofrer um rodízio e ser ocupado temporariamente por duas pessoas diferentes da própria equipe de desenvolvimento.

No projeto em que trabalho, nosso time passou recentemente por essa situação. O período de férias do Scrum Master foi apenas duas Sprints e, durante esse período, somente uma pessoa assumiu o seu papel.

Uma outra abordagem seria a equipe de desenvolvimento convidar um Scrum Master de fora do projeto para assumir o papel durante esse período. Porém, percebemos algumas possíveis falhas nessa abordagem. Vejamos a seguir.

Por que não chamar temporariamente um Scrum Master de fora do projeto?

O novo Scrum Master…

… não tem o contexto do projeto e nem da atual situação;

… não sabe a fundo os problemas e impedimentos;

… não conhece o time tão bem quanto o próprio time.

Sendo assim, suas ações provavelmente iriam limitar-se a se inteirar sobre o status do projeto, estar presente nas reuniões que precisa estar presente e tentar resolver alguns impedimentos, mas sem conhecer tão bem o contexto do projeto.

Na minha opinião, quando a equipe é madura o ideal é que um membro assuma o papel de Scrum Master, na ausência do mesmo. Mas para isso cabe ficar atento a questão do acúmulo de papéis. Abaixo algumas dicas.

Dicas ao acumular papel de desenvolvedor e Scrum Master

Aqui vão algumas dicas que acredito que possam contribuir para esse acúmulo de papéis:

1) O time e o PO devem estar cientes de que, durante essas Sprints, a velocidade do time provavelmente irá diminuir. É claro, afinal um dos desenvolvedores irá desempenhar também o papel de Scrum Master.

2) Durante as estimativas de pontos das histórias, o time deve ter cuidado para não supervalorizar a pontuação das histórias, com receio de que a Sprint será mais "trabalhosa" por ter uma pessoa empregando menos tempo no desenvolvimento, por estar também com responsabilidades de Scrum Master. As histórias devem continuar sendo estimada da mesma maneira.

3) O Scrum Master pode precisar resolver algum impedimento e por conta disso ele pode acabar deixando uma tarefa que ele estava desenvolvendo em andamento por muito tempo. Para evitar que isso aconteça é necessário orientar o restante da equipe de que o impedimento pode levar mais tempo do que o previsto e então algum outro desenvolvedor continua a tarefa de onde ela parou. Esse motivo ressalta a importância da realização das reuniões diárias, pois é o momento em que toda a equipe sabe o que cada um está desenvolvendo e pode traçar a estratégia para o dia.

Conclusão

Em minha opinião, se o Scrum Master saiu de férias e sua equipe é pequena e/ou experiente com Scrum, dê uma chance para o time suprir essa falta!!!

Se a equipe está nessas condições, provavelmente eles não irão precisar do papel de Scrum Master o tempo inteiro. Nesse caso, dependendo do contexto, uma pessoa, ou talvez qualquer uma, poderá atender às demandas de Scrum Master conforme elas vão surgindo.

Vamos nos lembrar que Scrum é inspeção e adaptação. Eis aí uma ótima oportunidade de colocarmos isso em prática.

Até o próximo post!

The post O que fazer quando o Scrum Master sai de férias? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Olá pessoal,

o post que trago hoje é adaptado do original "Five Things a Product Owner Needs to Know", disponível nesse link.

Muitas vezes a importância do papel do Product Owner (PO) pode acabar sendo menosprezada em relação aos outros atores presentes em um projeto Scrum. Se isso acontecer, é certo que o projeto não terá o sucesso esperado, por isso esse papel é tão importante quanto os demais e é preciso que o profissional esteja apto a desempenhá-lo.

Todo o texto desse post é direcionado para o PO e traz 5 dicas que com certeza irão contribuir para o sucesso no desempenho de seu papel em projetos Scrum. Vamos direto a essas dicas!

1. Confiança é a chave

o PO detém o conhecimento das regras de negócios das histórias do backlog. Porém, por não possuir experiência de desenvolvimento, pode ser que existam histórias no backlog com conhecimentos técnicos que sejam difíceis de entender. A dica aqui é contar com o apoio da equipe de desenvolvimento para explicar os detalhes técnicos de tais histórias, para que o PO possa priorizá-las corretamente.

E mais, se a equipe de desenvolvimento (a partir daqui irei chamar de “time”) sugerir mudanças que o PO pode não ter pensado, provavelmente elas trarão benefícios que podem acelerar o desenvolvimento, tornar o código mais confiável, aumentar a performance do produto. Ou seja, ouvir o feedback do seu time, pois ele pode ser um complemento valioso para o produto.

2. O trabalho do PO é servir o time

O objetivo final do desenvolvimento é lançar um excelente produto em tempo. O PO deve tentar estar disponível e responder o quanto antes às dúvidas da equipe.

Se o time está trabalhando com Sprints de 2 semanas (10 dias de trabalho), imagine que se houver um impedimento que paralise o trabalho por 1 dia pode significar que 10% do tempo disponível para o trabalho foi jogado fora.

3.    Perspectivas de usuário são essenciais

É essencial para o PO entender as pessoas que irão usar o produto. Quanto melhor for o entendimento do usuário final, melhor poderá ser o direcionamento do produto, suas funcionalidades e regras de negócio. Nada é mais importante do que o tempo gasto entendendo o usuário final.

Embora pareça difícil, o objetivo é conseguir atingir o melhor equilíbrio entre o que você sabe que o produto precisa e o que é valor para os usuários.

4.    Às vezes o time falha

Mesmo que o time seja muito produtivo em uma Sprint e esta seja um sucesso, isso não significa necessariamente que a próxima também será. Os altos e baixos do processo de desenvolvimento são normais, imprevisíveis e podem ocorrer devido a diversos fatores internos e externos.

A verdade é que o sucesso ou falha da Sprint não é tão importante quanto à capacidade do time de entregar valor. Portanto, não há porque se desesperar se nem todas as histórias forem aprovadas ao final de uma Sprint.

Equipes Scrum estão sempre tentando melhorar a cada Sprint. O PO deve confiar no seu time e ter consciência que eventualmente as falhas podem ocorrer porque eles resolveram testar novas técnicas, ou definiram uma meta muito ambiciosa.

5.    PO é diferente de gerente de projeto

Essa dica é para que o PO não queira tentar abraçar o mundo todo com seus braços. Isso é impossível!

O PO não precisa e não deve se preocupar com o calendário do time, como eles alocam seus trabalhos, ou como planejam as Sprints. Seu trabalho é somente definir as prioridades e prover feedback as necessidades do time.

Somente os desenvolvedores entendem completamente os detalhes de seu trabalho. Se o PO tentar controlar aspectos do desenvolvimento além dos que foram aqui mencionados, então o projeto pode estar fadado a um alto nível frustração e infelicidade.

Deixar o time ser auto-organizável e confiar em sua maneira de trabalhar irão poupar tempo e tornar mais fácil a vida e o trabalho de todos.

Gostou das dicas? Discorda de alguma? Tem mais alguma a acrescentar? Sinta-se convidado a comentar e compartilhar seus pensamentos e ideias conosco.

Até o próximo post!

The post O que o Product Owner precisa saber appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

no post de hoje eu abordo alguns detalhes sobre o momento em que estamos planejando a Sprint, mais precisamente na etapa do processo Scrum conhecida como Reunião de Planejamento.

Nesse post aqui eu já falei sobre o planejamento da Sprint e procurei responder à pergunta "Quantas histórias minha equipe é capaz de desenvolver?". Nele, eu falo sobre a utilização da velocidade da equipe como medida para auxiliar nessa seleção.

No post de hoje quero mostrar que essa medida está em constante mudança e, por isso, é importante estarmos sempre atentos e atualizando a velocidade da equipe a cada Sprint.

Podemos notar isso analisando a quantidade de pontos que são entregues no final de Sprints sucessivas. Essa quantidade está sempre mudando e, portanto, a velocidade também. Os motivos dessa mudança podem ser vários:

• Ausência de algum membro da equipe
• Feriados durante a Sprint
• Subestimação/Superestimação de histórias
• Histórias urgentes e imprevistas que entram na Sprint
• Outros

No projeto em que faço parte utilizamos o Planning Poker para estimar os pontos das histórias (mais informações sobre como fazer isso aqui, aqui e aqui), mas também temos guardados quanto tempo (em horas) cada história levou para ficar pronta. Com isso podemos pegar, por exemplo, as histórias que pontuamos com 3 pontos, ver o total de horas consumidas, dividir pela quantidade de histórias e aí teremos uma relação de quanto tempo, em média, a equipe leva para finalizar uma história de 3 pontos.

Na tabela a seguir podemos observar que recentemente houve uma mudança na quantidade de horas que levamos para finalizar histórias de 3, 5 e 8 pontos. As duas últimas tiveram uma mudança sutil, mas a história de 3 pontos passou a ser finalizada em 75% do tempo anterior. Não devemos entender que essa diminuição do tempo significa necessariamente que a equipe passou a ser mais eficiente, mas devemos encarar como uma mudança natural, já que os pontos são baseados em estimativas.

Ainda analisando a tabela, podemos fugir um pouco do tema velocidade e entrar na discussão pontos vs horas, que já foi abordado nesse post aqui.

Olhando os dados da tabela percebemos claramente que pontos e horas não formam uma função linear. Ou seja, não é porque para finalizar a história de 1 ponto leva 2h que a história de 2 pontos deveria levar 4h, e a de 5 pontos levar 10h. Não é bem por aí, afinal estamos lidando com incerteza e nossos pontos de estimativa são fuzzy (mais informações sobre fuzzy você encontra aqui).

E você leitor, anda medindo frequentemente a velocidade da sua equipe? Faz de outro jeito? Sinta-se convidado a compartilhar conosco um pouco da sua experiência.

Até o próximo post!

The post Planejando a Sprint: Velocidade e estimativa appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.