Estou aqui usando scrum e acabei ficando com uma sensação ruim de selecionar, no início do sprint, um conjunto de histórias para que sejam desenvolvidas nesse sprint.
Por que eu fiquei com essa sensação?
1 - O Product Owner altera o valor de negócio de uma tarefa fazendo que esta tarefa tenha um valor de custo benefício mais alto que algumas tarefas selecionadas para o sprint corrente. O que impede o Product Owner de substituir uma tarefa de menor custo benefício que foi selecionada para o sprint, porém não esta em andamento e nem foi finalizada, por esta tarefa de maior custo beneficio?
2 - Os desenvolvedores finalizam uma história e constatam que essa história criou a infraestrutura necessária para uma outra história, que não foi selecionada para o sprint corrente, diminuindo seu custo e aumentando seu custo benefício. O que impede os Desenvolvedores de substituir uma tarefa de menor custo benefício que foi selecionada para o sprint, porém não esta em andamento e nem foi finalizada, por esta tarefa de maior custo beneficio?
Por que em vez de selecionar as histórias no início do sprint não selecionamo-as ao longo do sprint, tornando o sprint mais dinâmico e agregando-lhe um custo benefício maior? Acho que assim um sprint deixaria de ser preditivo e se tornaria adaptativo.
Expressem ai suas opiniões para ajudar a clarear as minhas!
Se vc ficou com uma sensação ruim, talvez seja o caso de entender o que esta acontecendo. Sprints não deveriam ser estaticos porem é interessante ter alguma regularidade.
Se dentro de um Sprint ocorrem mudanças de prioridade, custo, etc, talvez seja o caso de encarar mais como fluxo continuo do que em degraus, usando um Kanbam (mesmo que por pouco tempo) por exemplo.
Na minha opinião quando você fica mudando o tamanho Sprint você perde o teor estatístico do processo. Você tendo um Sprint fixo você tem noção se as estimativas estão sendo bem feitas, como a equipe está se adaptando ao processo, se ela está melhorando o desempenho a cada Sprint.
Se você colocar um Sprint mutável fica bem mais difícil fazer estas análises.
Se vc contextualizar cada sprint não fica dificil não. Basta não olhar cegamente para a complexidade das tarefas ou outras métricas. Agora ter um sprint de cada tamanho é abrir margem para um dia alguem dizer que o sprint não termina enquanto não terminarem as estórias e por ai vai. O Sprint precisa atingir um objetivo e alguma flexibilidade é interessante.
Quando é o caso de vc precisar sempre de muita flexibilidade talvez seja a hora de se questionar se não é melhor usar outra coisa (como Kambam).
[quote=peczenyj]
Se dentro de um Sprint ocorrem mudanças de prioridade, custo, etc, talvez seja o caso de encarar mais como fluxo continuo do que em degraus, usando um Kanbam (mesmo que por pouco tempo) por exemplo.[/quote]
O que você quer dizer com fluxo contínuo e fluxo em degraus?
Você me recomenda alguma leitura inicial de Kanban?
Não estou falando para ficar mudando a duração (TAMANHO) do sprint, acho que o sprint deve ter uma duração fixa (No meu caso 1 mês) para que possam pelo menos ocorrer contatos frequentes com o Product Owner. Porém, acho que as histórias que vão ser desenvolvidas em um sprint poderiam ser selecionadas durante o sprint de uma forma mais adaptativa, em vez de serem previamente selecionadas no início de uma forma tão preditiva.
Isto pode ser feito, mas não deve. Por muita razões, tantas que vou esquecer alguma.
Primeiro significa que o PO não priorizou certo. Se a historia nova é tão boa asssim porque não entrou neste sprint ?
Segundo ha uma quebra de compromisso e de foco. Isso em scrum é pecado capital porque vai directamente contra tudo o que o sprint representa (focused timebox)
Este cenário pode acontecer se o sprint é muito grande ( 1 mes ou mais) e o PO começa a ficar desesperado. O Scrum Master tem que ajudar a equipa nestas horas. O ideal seria partir em 2 semanas ou 3 no máximo para que o PO tenha mais oportunidade de priorizar as coisas.
Modificar o sprint log ( que é de tarefas e não estorias) é perigoso, pode levantar custo, etc… e é , em regra contra as regras. Se acontece, então o melhor é modificar os parametros das iterações ( tamano do sprint) para acomar mais alterações dentro das regras.
O problema de jogar fora das regras é que ninguem depois vai saber impor um limite o PO vai querer alterar tudo a toda a hora e isso destroi todo o efeito degrau do sprint. E é uma violação clara da visibilidade.
Em suma, fazer isso, embora possivel, é violação directa da maior parte dos valores Scrum o que significa que vc não estará fazendo scrum. Se acontecer - e é possivel eventualmente - então significa que algo está errado com a forma como vcs estão fazendo scrum. O SM tem que intervir. Tlv o PO não tenha entendido bem a mecanica de priorização ou não tenha ficado consciente do compromisso que significa priorizar.
A equipa a mesma coisa. Ele não compreendeu o que significa foco. E em geral ninguem entendeu o que significa compromisso.
Enfim, se acontecer 1 ou outra vez no ano, tudo bem, mas se acontecer sistemáticamente reveja o processo e altere-o de forma a que não aconteça.
O que impede é o compromisso que fizeram no principio do sprint. O objetivo não é queimar estorias À toa, é queimar com qualidade as que estão no sprint log. Se a infra ficou pronta otimo. Isso não significa nada mais que isso.
Foque em acabar as outras tarefas/estorias. Só então, se sobrar tempo, vc pode pegar outra estoria para o sprint backlog. E ai vc pode escolher essa. MAs apenas quando todo o sprint backlog estiver pronto. E lembre-se que "pronto’ tem um sentido técnico em scrum.
Enfim, vc pode adiconar estorias ao sprint log, mas apenas e só quando todas as que já estavam lá estiverem prontas.
O beneficio existe sem que seja implementado. É por isso que o PO é necessário. É a priorização dele que manda em relação a isso. Se ela está errada o PO tem que aprender a priorizar melhor.
Scrum é baseado em foco. Foco na tarefa, Foco no tempo para a cumprir. E Compromisso. A equipa se compromete no inicio do sprint a fazer o sprint log todo. Portanto qualquer alteração precisaria de um novo compromisso, quebraria o foco nas tarefas que ainda estão por fazer e já pertenciam ao sprint log.
E tudo viraria a casa da mãe joana…
Compromisso,Foco, Abertura, Respeito e Coragem.
Comprometase com uma tarefa, foque-se em completá-la, mostre as suas falhas e progressos e peça ajuda, respeita os compromissos dos outros, os seus, a opiniçao e o foco dos outros e tenha coragem para não sair do caminho.
O caminho é longo e estreito… qualquer deslize e cai do scrum para a m…
Tudo bem, mas se o erro foi encontrado não é melhor corrigi-lo logo do que continuar errado?
A necessidade do mercado mudou, antes ela não era tão importante mas agora ela é!
O software ainda esta em desenvolvimento mas já tem uma parte funcional que esta sendo usada pelo cliente. E pelo fato do cliente estar usando, a cada dia ele solicita uma funcionalidade, um pedido de melhoria ou uma correção. Todos os dias surgem histórias novas!
Acho que é assim que funciona com desenvolvimento ágil: tenho entregas e solicitações frequentes. (Queria eu entregar software para os cliente todos os dias!)
Acho que não há uma quebra de compromisso pois o PO não esta mexendo não historias em andamento nas quais os desenvolvedores estão focados. Ele esta mexendo nas histórias que ainda nem começaram a ser desenvolvidas, não há foco nessas histórias.
Ou pode acontecer porque o sprint é estático!
Mas essa regra (que eu ainda nem sei se existe realmente) do sprint ser intocável é muito ruim, será que não podemos relaxar um pouquinho ela? Tipo você pode mexer no sprint mas não pode mexer em um história em andamento.
Por causa deste compromisso vou deixar de entregar algo de mais valor ao cliente? Acho que tem que ter bom senso!
Isso causaria uma situação assim: Ai PO ninguém mandou você priorizar errado, agora você vai ter que esperar até que o sprint termine! Ve se aprende e prioriza melhor da próxima vez!
Não sei quanto ao Scrum, mas no XP é perfeitamente possivel o cliente alterar os requerimentos, adicionando ou removendo estorias, mudar as prioridades, etc (desde que a estória não esteja em andamento). Sendo Scrum uma metodologia agil ficaria admirado em saber que isto não é possível.
Agora, havendo alterações o programador deve etimar novamente e informar o cliente eventuais impactos no prazo. Caso o prazo não atenda mais as necessidades do cliente ele precisa estar ciente para então acordar uma nova data ou então remover estorias de baixa prioridade.
[quote=brunohansen][quote=sergiotaborda]
Primeiro significa que o PO não priorizou certo.
[/quote]
Tudo bem, mas se o erro foi encontrado não é melhor corrigi-lo logo do que continuar errado?
[/quote]
Vc vai corrigir logo. logo assim que terminar todas as estorias do sprint. Se o sprint foi bem dimencionado
então isso acontecerá só no fim do sprint e vc usarará a reunião de avaliação do fim do sprint para colocar esse problema na mesa.
Se acontecer antes, na boa, vc coloca essa estoria no sprint e pronto. Mas veja bem, ela tem que caber no tempo que falta para o fim do sprint. O tamanho do sprint é intocável. O resto vc muda o que quiser.
O problema vem quando vc muda tudo a toda a hora.
A necessidade do “mercado” mudou em 2 semanas ? Esse mercado é bem rápido.
é mais realista que só agora o PO tenha entendido o que o cliente quer/precisa.
A urgencia dele é artificial, causada pelo seu proprio erro e vontade de alterar antes que alguem se dê conta.
Excelente. Manda para o product backlog, e o PO prioriza. Tão simples assim. Onde está o problema ?
Em scrum não basta ser frequente, tem que estar pronto , tem que acatar os compromissos prévios. Frequente não significa “todos os dias”, significa “no fim de cada sprint”. Mas hei! vc pode pode fazer sprints de um dia. (quero ver só como vc lida com features maiores que 1SP :twisted: )
Está sim. Os desenvolvedores estão focados em todas ashistorias do sprint. houve um palnejamento da equipe para cumprir aquelas tarefas. Aquelas,não outras. Quando vc desenvolve, mesmo focado em uma tarefa vc pensa nas outras durante o resto do tempo.
O scrum define o compometimento da equipa com o sprint , não com a estoria ( como no XP) , logo, quando o sprint tá fechado, ninguem mexe. E é função do SM impedir que isso aconteça.
Como eu falei antes, isso pode acontecer como xceção. Mas não deve acontecer sistemáticamente como regra.
Ha sim. É esse o seu erro. A equipa acha que só porque não está pondo as mãos na massa não está focada. Esse é o erro. E é por isso que o scrum proibe esse tipo de promiscuidade. Porque ela é danosa. Mesmo quando os desenvolvedores não acham. é por isso que tem o SM.
Não. não podemos.
Vc quer relaxar e levar numa boa ? blz. Mas então pare de dizer que está usando scrum.
Como eu já disse: uma vez por outra é perdoável. Instituir a regra de que o PO pode mexer nas historias do sprint é anti-scrum.
O bom senso aqui é usar Scrum. E se vc decidiu usar, vc tem que ter a coragem de usar até ao fim. Tá doendo ? aguenta que vem mais. O bom senso é não se desviar do caminho certo. Não querer ir por atalhos. não ir atrás de casinhas de doce.
Vc vai entregar valor ao PO, não ao cliente. O problema do valor ao cliente é problema do PO.
Exactamente. Vc está começando a entender.
Veja , o PO comprometeu-se com a equipa tb. ele comprometeu-se a não interrompê-la. Logo, se ele viola isso, ele está violando um valor básico do scrum. Se ele insiste, ele não é um bom PO e projeto vai desandar para um processo ad doc.
Existe sim. Com bons PO. Tlv o problema seja o seu PO. ou tlv seja você que está disposto a trair os valores scrum…