Feeds:
Posts
Comentários

Posts Tagged ‘Scrum’

Conheço a prática Planing Poker faz um tempo, porém não tinha tido a oportunidade de aplicar e desfrutar dos ótimos resultados, como tive há alguns dias atrás.

Na empresa onde trabalho ainda não temos aplicado o Scrum propriamente dito, mas trabalho com muitas práticas da metodologia [método, framework, seja o que for, rsrs] e estamos tendo ótimos resultados! O Planning Poker foi uma delas!

O Planning Poker é uma prática de estimativa de tarefas bem simples e inclusive divertida, mas muito eficiente. Muito utilizada no SCRUM, esta prática funciona da seguinte forma:

– Ao invés de estimar horas exatas estima-se em pontos;

– Os pontos utilizados no ‘jogo’ são parecidos com a sequencia do Fibonacci, ou seja, o próximo número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, … Para simplificar é muito utilizada esta sequencia: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Mas vai de cada um; eu por exemplo não chegaria até o 100 porque prefiro trabalhar com tarefas menores;

– Porque números tão distante entre si? Porque quanto maior uma tarefa, mais difícil de prever com precisão quantos pontos a mesma terá (e muito menos horas). Isso significa que uma estimativa de 13 pode estar entre 8 e 21… Por isso que quanto menor as tarefas, melhor para serem estimadas e a variação de pontos é melhor administrada. Sempre procure chegar no menor nível de granularidade, evitando tarefas muito grandes;

– O time do projeto se reúne com o responsável pelas regras de negócio (Analista, PO, Gerente, Cliente…) e cada um recebe as cartas do Planning Poker. Mas que isso não seja um impedimento! Se não tem cartas, improvise com os dedos (foi o que fiz, rsrs);

– As funcionalidades/tarefas são apresentadas, uma a uma e as dúvidas do time são sanadas;

– Atribui-se o peso 2 para a menor tarefa, para que esta sirva de comparativo para as demais (ex: uma laranja é maior que um morango? E que uma manga? E assim as tarefas são comparadas tendo essa de peso 2 como parâmetro);

– Inicia-se com uma atividade (pode ser por ordem de prioridade), e todos jogam a carta ao mesmo tempo;

– A ideia é discutir a variação de estimativa; porque Fulano estimou X e Ciclano estimou Y… e aí… só fazendo para ver o que acontece; a discussão que é gerada em torno das estimativas e diferentes concepções é sensacional!

– No final a equipe chega a um consenso e define o peso da tarefa, partindo para a estimativa das demais, até que todas estejam estimadas;

Bom, quando apliquei esta prática foi com um time de  8 desenvolvedores que estavam atuando diretamente no projeto e 1 desenvolvedor Sênior, fora do projeto, que participou apenas para observar a equipe e tirar eventuais dúvidas. Acabei não envolvendo quem participou da criação do layout e testes, mas seria o ideal.

O objetivo da reunião, utilizando ou não os pontos depois, foi de colaborar com o entendimento e concepção que cada um têm sobre determinada funcionalidade. Isso foi muito bom! As opiniões eram diferentes, enquanto um achava que a funcionalidade era fácil por determinados fatores, outro achava que já era complicada por outros motivos… E nessa dinâmica de cada um expor sua opinião e justificar os pontos estimados, houve uma troca de conhecimento, um amadurecimento muito interessante! Tenho certeza que cada um saiu da reunião com uma ideia diferente sobre as tarefas!

Ah mas não quero usar cartas e quero que cada um fale a estimativa que achar que seja! Não vai dar certo, sabe porque? Faça um teste. Se um falar 5, por exemplo, o restante das estimativas sempre será o mais próxima de 5 possível; as pessoas são influenciadas e com o jogo de cartas, cada um estima o que realmente acha que é. 🙂

Tem um artigo muito bom do Ramon Durães “O efeito do Planning Poker na prática“, que também vale ler.

Para quem já utilizou o Planning Poker, comente e compartilhe essa experiência!! 🙂

Read Full Post »

Alguns meses atrás enviei um e-mail com algumas dúvidas sobre Scrum para o Ramon Durães. Quem não o conhece o site dele é http://www.ramonduraes.net/. E ele acabou fazendo um post sobre as respostas. MUITO OBRIGADA PELA ATENÇÃO e pelas respostas que foram muito esclarecedoras!

Para quem quiser saber mais sobre Scrum ele tem váaarios posts ótimos!! Vale a pena visitar seu site.

Bom, como minhas dúvidas podem ser também as suas, vou dar um CTRL+C, CTLR+V no Post dele rsrs.., que se encontra em http://www.ramonduraes.net/2011/06/02/duvidas-sobre-scrum/.

O Scrum é um framework interativo e incremental utilizado para gestão ágil de projetos de software e vem conquistando um grande número de adeptos em todo o Brasil. Com poucas regras focando no resultado e colaboração entre as pessoas tem atraído a atenção dos profissionais pela simplicdade e transparência que se conquista já nos primeiros Sprints. O Scrum acaba mostrando problemas que antes ficavam escondidos dentro dos famosos cronogramas, documentos e processos intermináveis.

Hoje recebi um e-mail com algumas dúvidas de quem está iniciando no estudo do SCRUM e estarei comentando juntamente com vocês. A minha ideia não é resolver as mesmas e sim contribuir para que juntos possamos conversar sobre cada questão e criar um entendimento usando nosso principal principio que é justamente formar um time. Ter uma cultura forte nos projetos é o maior fator de sucesso nos projetos e é algo que deve nascer e circular por toda a organização.

1) Pelo que entendo cada projeto novo tem as suas Sprints. Como Scrum trabalha com a necessidade de um dos integrantes do time precisar resolver situações de outros projetos (pontuais)? Colocam essas estórias na Sprint do projeto atual como “impedimentos”, “outras atividades”?

Com o fim da era ‘recurso’ onde você é encarado como um equipamento que tira e pluga em qualquer lugar prejudicando todos os projetos e a sua expectativa de entrega nós entramos no conceito de ‘Time” onde o seu trabalho é importante para o resultado do projeto que está participando e sua saída para fazer qualquer outra atividade seja qual for vai prejudicar a entrega do Sprint e todo esforço dos seus colegas. Estou levando em consideração que você é um membro do time. Dentro do Scrum nós trabalhamos dedicados a entregar ao final do Sprint todos os itens que assumimos como Sprint Backlog. O Sprint segue o conceito de indivisível. Portanto por padrão não deve sofrer interferências senão você quebra as expectativas e volta ao ciclo tradicional em cascata.

2) O integrante de um time pode participar de mais de um projeto ao mesmo tempo (as vezes para apoio em determinadas funcionalidades)?

O membro do time é dedicado a entregar aquele determinado Sprint. Se uma pessoa está participando de vários estará ferindo o principal principio do comprometimento por que inevitavelmente terá conflitos e ira prejudicar todos os times. A ideia de Sprint curtos de 2-4 semanas permite justamente ter entregas rápidas e contornar esse tipo de necessidade.

3) Quando o time não tem nenhum projeto novo mas está trabalhando em diversas manutenções… É criada uma “Sprint geral” do trabalho do time (envolvendo todas essas solicitações)? (Neste caso as estórias podem ser de PO’s diferentes… )

O ciclo do Scrum se repente enquanto tiver itens no backlog do PO. Cabe o mesmo adicionar mais itens e priorizar para o próximo Sprint conforme seu entendimento de valor de negócios. Em um caso de ter vários os mesmos vão organizar o backlog geral. Lebrando que toda e qualquer decisão de negócio é sempre com o Product Owner.

4) O Scrum Master pode desenvolver também?

Segundo o Scrum ele pode participar sim, porém corre um grave risco devido a função de Scrum Master ter que resolver outras questões externas e prejudicar o time deixando de contribuir como desenvolvedor do mesmo. Outro ponto importante é direto ao Scrum Master que deve está atento a deixar claro que ele não tem autoridade sobre o time e deve atuar como qualquer membro.

5) Como o cliente contrata projetos longos que usam Scrum? Por “pacote de horas”? Ou a empresa faz análise (GAPS), levanta requisitos macro, fecha ume escopo e estima um tempo?

O primeiro caminho é estimar o backlog e a depender do tamanho e das características do mesmo vocês vão decidir a profundidade dessa estimativa. Depois disso usando a experiência de vocês em Sprints anteriores terão a velocidade do time que indica quantos pontos de complexidade conseguem se comprometer e com isso podem estimar o número de sprints necessários. Com os Sprints e quantidade de pessoas que participam vocês terão uma estimativa de custo e previsão. Depois de anos de crises o mercado esta aberto a outras abordagens e uma delas é justamente o cliente contratar por Sprint e pagar até o momento que ele fique satisfeito com o valor de negócio entregue e não necessariamente o projeto completo.

Em resumo eu sempre me divirto conversando sobre Scrum principalmente por que para min ‘e uma oportunidade de crescimento constante entendo as mais variadas visões e abordagens. O Scrum ‘e tão simples que pode-se resumir a uma pagina e esse ‘justamente o objetivo de sua criação reunindo as melhores praticas e somente o necessário para você ter um norte. Com a evolução dos ciclos de Sprint vocês terão a oportunidade de reavaliar e ir adaptando conforme as necessidades que forem aparecendo. O mais importante ‘e ter em mente que a melhoria será continua e nunca terá um processo definido.

[],

Ramon Durães

Especialista em desenvolvimento de software

MVP, Visual Studio ALM

PSM, Professional Scrum Master

PSD, Professional Scrum Developer

CSM, Certified ScrumMaster

Read Full Post »

Porque é difícil dizer quando um projeto de software vai acabar? Essa é uma pergunta que se repete estranhamente, porque quem pergunta sabe que terá uma resposta furada e quem responde, sabe que quem perguntou não vai acreditar. Então… Porque perguntam sempre a mesma coisa?

Quando você termina isso? Quando se tratam de tarefas pontuais (e não muito grandes), não é muito difícil, até porque seria como estimar o peso de uma estória; mas e quando se tratar de um projeto? Me sentiria estranha se precisasse desprender grandes esforços para planejar tarefa por tarefa para enfim, entregar o “cronograma tão solicitado”. Bonito é, mas pode não ser eficiente. Então, é hora de pensar diferente!

Por um lado eu gosto de “datas”. Mas acho que “data” não é a melhor palavra… O que preciso é da ideia da complexidade do que foi solicitado e uma meta para alcançar. Ter uma entrega planejada motiva a equipe, evita que percam o foco e é possível analisar o andamento das atividades. Realmente é importante.

Mas venhamos e convenhamos, um projeto inteiro, do início ao fim, dentro de um cronograma? Atenção! Este projeto poderá sofrer alguns efeitos colaterais: Cliente insatisfeito, escopo com colesterol alto (muito gordo), risco de mudanças e “cronograma” atrasado. Não é o que buscamos.

Se metas são importantes, mas não é saudável travar o projeto e chutar datas, o que podemos fazer? SCRUM!

  1. Descobrir a velocidade da equipe (se não conhece, levará algumas Sprints até calibrar suas estimativas), estimar as estórias para saber quantas podem ser entregues no final de cada Sprint;
  2. Priorizar as estórias juntamente com o PO (“Solicitante”, digamos assim);
  3. Planejar as estórias da próxima Sprint (conforme o máximo de estórias que o time suporta para aquele período);
  4. Acompanhar as atividades da equipe através de reuniões diárias;
  5. Entregar valor no final de cada Sprint;
  6. Acompanhar as atividades do projeto através do gráfico BurnDown.
  7. […]

Tem-se muito mais que um cronograma totalmente “justificado”, alterado e em vermelho, através de metas, datas e planejamento de cada Sprint do Projeto.

Podemos ter informações (confiáveis) sobre:

  • Impedimentos do projeto;
  • Reais estimativas;
  • O que foi realizado até o momento;
  • Qual será a próxima entrega de valor;
  • COMO o projeto está ficando (na prática mesmo);
  • Status de cada Sprint;
  • […]

É possível entregar frequentemente aos que precisam dessas datas, Status Report detalhados e completos,…E impressionar pela transparência, informações confiáveis e VALOR sendo gerado sem grandes esperas.

Read Full Post »

Construir um produto de software é diferente de qualquer outro tipo de produto. A abstração é muito grande. E todo projeto de software sofre dos mesmos problemas: Escopo e cronograma extrapolado, usuários insatisfeitos e implementação de funcionalidades desnecessárias. E qual o primeiro e talvez único que culpamos nesta história toda? O usuário, que muda de ideia o tempo todo e não consegue manter o escopo original, causando todo atraso.

Bom, se nenhum projeto é igual ao outro (escopo, usuários, requisitos, forma de desenvolver), mas todos sofrem dos mesmos problemas, será que o problema está mesmo no usuário ou em nossa forma de desenvolver software? “Se você acha que o problema está fora, esse pensamento é o problema!”. Vamos refletir.

Adepta a métodos ágeis há muito tempo (o muito tempo são 4 anos, desde do final da faculdade), onde naquela época me apaixonei por Extremme Programming (XP) e Scrum na teoria (não trabalhava com desenvolvimento ainda), sempre busquei ler muitas experiências relatadas na internet da aplicação destas práticas ágeis, em blogs, palestras, artigos, etc. Encontrei recentemente uma palestra que relatou exatamente o que enxerguei no Scrum. Uma maneira óbvia de desenvolver software, que poucas pessoas enxergam e têm a coragem de aplicar (porque “ninguém” gosta de mudança). Mas mesmo pensando desta maneira “ágil”, cometemos de vez em quando os mesmos erros: Culpamos os usuários dos atrasos e mudanças, ou, fazemos “cara feia” para as mudanças, como se fosse proibido acontecer.

Vamos nos colocar como usuários em outras situações. Quando você vai comprar uma roupa, você simplesmente explica o estilo, cor, tamanho, detalhes, espera a vendedora achar algo que se encaixe nesses “requisitos”, leva a roupa embalada e ao tirar da sacola para usar, tem uma surpresa!? Não, nós compramos roupa vendo, provando, e às vezes até levando pra casa pra combinar com outras peças do guarda-roupa, não é mesmo?

Vamos pensar em outra situação, a de aproveitar a oportunidade. Sua loja preferida de calçados  (ou de sua esposa)  entra em uma mega liquidação com descontos de até 70%. Ela compra vários como se fosse a última oportunidade! Se ela soubesse que essa promoção é mensal ou semanal, não compraria menos? Rs… Sim! É o que acontece: Fechamento do escopo no início do projeto vs Priorização de estórias à cada Sprint.

Esta palestra e alguns exemplos que foram dados me fizeram pensar nisso: “É verdade. A hora do planejamento do escopo é a única oportunidade que o usuário tem de pedir o que ele precisa. E exigimos que ele nos conte tudo, com detalhes, sem conhecer de software, sem conseguir imaginar o resultado final, sem “provar” nada! Tudo para evitar atrasos”.

Você sabia que 7 entre 10 projetos de software atrasam 200%? E que 80% das funcionalidades do software não são utilizadas?

Bom e aí, é hora de começar a pensar no óbvio: Se o usuário tivesse mais oportunidades para solicitar novos requisitos e a possibilidade de ir provado de pouquinho o software, este cenário não poderia ser diferente?

O Scrum propõe exatamente isto: Resposta rápida às necessidades de negócio, menor impacto das mudanças no projeto, entregas frequentes de software funcionando, priorização dos requisitos a cada “timebox” (entrega), etc.

Vale a pena ouvir a palestra.

Num próximo post explico o Scrum e como essas ideias podem ser aplicadas.

Read Full Post »

Você usa mesmo Scrum?

Ao escrever o post me deparei com uma dificuldade. Como tratar de Scrum? Metodologia, Método, Modelo ou Framework?!

Gostaria muito de me aprofundar nesta questão e levantar debates, encontrar definições, mas procurando discussões e definições na internet, encontrei muito debate sem fim. Como não quero nem tenho propriedade para bater o martelo em relação a este assunto, vamos deixar o debate para quem possui mais argumentos. Para mim, método ou framework não mudam meu conceito de Scrum. O importante é entender Scrum, estudar Scrum. O que o defini vamos deixar para depois.

Então, vou chamar de simplesmente “O [coloquem o que quiser aqui] SCRUM”.

Bom, o Scrum não nos ensina uma receita exata de como fazer as coisas (receitas vocês vão encontrar em panelasnovas.wordpress.com, rsrsrs). O que devemos fazer é adaptar suas práticas à cultura da empresa. Muitos não entendem isso e interpretam Scrum de maneira errada. Outros aplicam mais ou menos, as coisas não vão bem e então, “o Scrum não funciona”. Será que usamos mesmo Scrum?

Encontrei uma entrevista com o Jeff Sutherland (um dos inventores do Scrum), dizendo que aplica um teste às equipes (Nokia Test) para verificar se estão mesmo usando Scrum. Para acompanhar a entrevista, clique aqui. O teste se resume basicamente nas premissas abaixo:

As iterações devem ter um tempo menor do que quatro semanas.
-O software deve estar testado e funcionando ao fim de cada iteração.
-A iteração deve começar antes que toda a especificação esteja pronta.

A segunda parte foca no Scrum propriamente dito. As perguntas são:

– Existe um Product Owner definido?
– Existe um Product Backlog priorizado por valor de negócio?
– O Product Backlog tem estimativas criadas pela equipe?
– A equipe gera gráficos de burndown e sabe a sua velocidade?
– Não existem gerentes atrapalhando e interrompendo o trabalho da equipe?

E você, usa Scrum? O que você aplica no dia-a-dia do seu trabalho?

Read Full Post »