Feeds:
Posts
Comentários

Archive for setembro \23\+00:00 2011

Quadro de tarefas

Obs.: Backlog é uma lista de itens priorizados a serem desenvolvidos para um software.

No projeto que estou, colocamos um quadro com post its para o acompanhamento das tarefas. A prática é do Scrum: acompanhar as tarefas que precisam ser feitas (“backlog”), as tarefas em execução e as terminadas. Simples assim já está ajudando muito a equipe toda visualizar o andamento do projeto, a qualquer momento. A divisão de tarefas ficou muito mais fácil, assim como a discussão sobre cada uma delas. Nos reunimos ao redor do quadro e movemos as tarefas “pra lá e pra cá”.

Bom, vamos deixar de lado por enquanto todos os valores e práticas do Scrum e vamos falar apenas do “quadro de tarefas”, de uma forma bem simples, para que leitores que nunca ouviram falar de Scrum possam entender.

Colocar algumas tarefas do projeto no Backlog, discutir todos os dias sobre as tarefas com a equipe e acompanhar o status de cada uma, não responde algumas questões muito importantes para o Projeto, como:

– Estamos dentro do prazo?

– Quantas tarefas faltam para a primeira entrega?

– Qual nossa meta de tarefas para esta semana (poderia ser “duas” ou “três” semanas)?

Para isso, alguns passos devem acontecer antes das tarefas chegarem no quadro; são eles:

– Defina o tamanho do “ciclo do projeto” (lembrando que o projeto pode ter vários ciclos, claro). Vamos chamar este ciclo de Time Box. O Time Box é um período fixo de dias (por exemplo, uma semana) que seja possível entregar um valor para o Cliente. O que quero dizer é que se o projeto é muito longo e o Time Box é de uma semana, talvez uma semana não seja o suficiente para “produzir alguma entrega possível de ser testada”.

– Divida as funcionalidades do projeto em pequenas tarefas. A tarefa não pode durar mais que o tamanho do Time Box, claro, se não, não é possível de concluí-la no tempo determinado. Se ela estiver muito grande, quebre-a em tarefas menores;

– Estime o tempo de cada tarefa. Existem práticas para isso, como Planning Poker, por exemplo, mas a ideia não é entrar em detalhes neste post. O tempo precisa ser estimado para conseguir identificar “quantas tarefas cabem em cada Time Box” (considerando o tamanho da equipe, claro);

– Defina por fim as tarefas que serão feitas em cada Time Box. Com isso têm-se um objetivo traçado, uma meta, um prazo para toda a equipe;

– Acompanhe diariamente as atividades da equipe, fazendo três perguntinhas famosas:

 – O que você tem feito desde ontem?

– O que você está planejando fazer hoje?

– Você tem algum problema impedindo você de realizar seu objetivo?

Com isso é possível responder aquelas três perguntas anteriores:

– Estamos dentro do prazo?

– Quantas tarefas faltam para a primeira entrega?

– Qual nossa meta de tarefas para esta semana (poderia ser “duas” ou “três” semanas)?

Somente com algumas tarefas no quadro e o  “move pra cá move pra lá” não é possível ter essa visão 🙂 É preciso definir quantas tarefas serão entregues num tempo “x” determinado.

Por isso, não achem que um quadro com post its basta para dizer que estamos usando Scrum. Tem muito para evoluir,
mas é importante começar… Um passo de cada vez 🙂

Tem um post que eu falo sobre este assunto, que pode ser interessante ler: Você usa esmo Scrum?”

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 »