Menu

Samuel Cavalcante – Saímos do SCRUM e sobrevivemos a Agilidade – Conversa Rápida MS

outubro 7, 2014 - 3º Conversa Rápida MS
Samuel Cavalcante – Saímos do SCRUM e sobrevivemos a Agilidade – Conversa Rápida MS

2 opiniões sobre “Samuel Cavalcante – Saímos do SCRUM e sobrevivemos a Agilidade – Conversa Rápida MS

Felipe Ribeiro

Olá Samuel, nós também nos questionamos sobre algum desses pontos, então gostaria de saber:
– Como vocês fazem pra saber se as historias vão caber dentro da sprint sem a estimativa das tarefas?
– Como o time faz para saber se estão atrasados ou não?
– Aqui na empresa a gente extrai algumas métricas (produtividade do time, velocidade, qualidade, desvio, etc.) de cada sprint, para analisar a evolução durante o projeto, mas alguma delas são feitas com base nas estimativas das histórias, você acha que a falta desses dados pode levar a perda dessas métricas?

[]’s

Resposta
    Samuel Cavalcante

    Oi Felipe,
    – Quanto as histórias caberem na Sprint: Fazemos as estimativas de História/Pontos e mantemos o um limite que o time sente confortável para fazer (entre 20 e 23 pontos). Sinto que quando o time divide a história em tarefas ao decorrer da Sprint, ele está mais concentrado e os devs podem olhar o código e discutir arquitetura, isto tem permitido um detalhamento melhor e aumentado a assertividade na quantidade de tarefas a serem desenvolvidas.
    – Atrasos: Quando o time quebra as tarefas ao decorrer da Sprint, automaticamente olha para o que ainda tem que ser feito e consegue se reorganizar para a entrega.
    – Métricas: Isso não é um problema grande para nós. Nosso medida de progresso normalmente é a satisfação do cliente. Porem em um dos times que trabalho (o case deste post). Eu mantive uma coleta enorme de dados, Tarefas estimadas/executadas, horas estimadas/executadas … um monte mesmo. Recentemente descobri que os dados mais validos a serem coletados para analise do “Processo” e evolução do processo são: Pontos por História, Horas gastas da Tarefa, quantidade de tarefas executadas, tempo de sprint e quantidade de desenvolvedores no time. A partir destas consigo métricas para auxiliar o time e PO na tomada de decisão, focando no aprendizado. Aonde podemos melhorar.
    Ainda quanto a métricas, os times da DígithoBrasil, chegaram a um consenso quanto a qualidade de código e métricas a serem acompanhadas, para isso estão usando o SONAR.

    Abraços,
    Samuel Cavalcante.

    Resposta

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *