Melhor maneira de lidar "Então, quando isso será feito?"
Durante a reunião stand-up diária no meio de um sprint, o gerente de projeto / scrum master de fato geralmente pergunta aos desenvolvedores uma versão do:
"Então, quando isso será feito?"
"Então você pode se comprometer em fazer essa tarefa hoje às 16:00?"
"Quantas horas você resta nesta subtarefa?"
Isso é francamente muito irritante e não torna as coisas mais rápidas. O resultado é que os desenvolvedores geralmente se sentem sob muita pressão e as empresas de stand-up parecem mais um campo de batalha do que uma colaboração.
Como desenvolvedor, qual é uma maneira sólida de lidar com isso?
Você tem gerentes de projeto tentando "fazer agilidade"? Isso soa como uma estupidez típica da boca de um gerente de projetos. Você precisa aumentar a espessura da pele e preencher todas as estimativas, como sempre fizemos com todos os outros estilos de desenvolvimento.
Possível duplicata de Por que usamos pontos de história em vez de dias de trabalho ao estimar histórias de usuários?
Você tem um gerente de projeto / scrum master? Você deve ter um gerente de projeto e um scrum master, e eles não devem ser a mesma pessoa.
Possível duplicata de Como responder quando você é solicitado para uma estimativa?
"Eu não sei" é uma resposta perfeitamente aceitável, se você não souber.
"No final do sprint".
Sei que é uma resposta sarcástica, mas há alguma verdade escondida lá. Depende de quem está fazendo a pergunta e por que eles estão fazendo essa pergunta.
O gerente de projeto realmente não tem negócios a fazer essas perguntas - eles devem perguntar ao mestre de scrum se precisam de informações detalhadas sobre tarefas em andamento e devem fazê-lo fora da rotina diária.
Se é o scrum master quem está perguntando, talvez eles estejam perguntando para que possam estar preparados para os próximos bloqueios de estradas. Se for esse o caso, seja honesto.
No scrum, a equipe não tem obrigação de terminar nenhuma tarefa ou história em particular até o final do sprint, supondo que eles estejam perguntando sobre uma história relacionada ao sprint atual (versus um hotfix fora da banda). Os prazos para as tarefas em uma história são de propriedade da equipe e não devem ser pressionados por um gerente de projeto.
No entanto , o desenvolvimento de software é um processo colaborativo, portanto, é razoável acomodar essas perguntas, dentro do razoável.
A solução? Da sua perspectiva: responda o mais honestamente possível, o mais breve possível, se for durante o stand-up. Se você está trabalhando ativamente na tarefa que está sendo perguntada, sempre pode dizer algo como "estima-se que demore algumas horas, para que eu possa concluí-la hoje". Se você não está trabalhando nisso, um simples "não sei, ainda não comecei a trabalhar. Acho que a estimativa ainda parece bastante precisa".
Da perspectiva deles: eles precisam aceitar sua resposta.
A resposta para isso quase sempre deve ser "não". Simplesmente não há necessidade de se comprometer com um produto final do dia para uma tarefa no meio de um sprint. Se a tarefa está concluída às 16h de hoje ou às 9h de amanhã, é irrelevante, desde que a história como um todo esteja concluída no final do sprint.
Essa é uma pergunta razoável a ser feita. Apenas responda honestamente. Eu percebo que isso é muito difícil de fazer. Eu estive lá. Eu acho que os desenvolvedores são inerentemente otimistas. Examinaremos uma tarefa e pensaremos "isso só vai demorar algumas horas" e antes que você perceba o dia inteiro passou. É por isso que o Agile funciona - admitimos nossas limitações na estimativa e fazemos o possível para dividir as coisas nos menores pedaços possíveis.
Peça ao Scrum Master que esclareça o objetivo de uma Sprint e Stand Up Meeting. Quase todo mundo que trabalha com o Scrum diria que o objetivo de um Sprint é decidir o que é feito durante a duração do Sprint e eu nunca ouvi falar de nada devido durante um sprint.
Talvez você tenha emergências para atender que realmente não têm nada a ver com um sprint. As equipes / desenvolvedores que têm essas tarefas fora do sprint, precisam garantir que não incluam tempo para fazer isso como parte do planejamento do sprint. Talvez você tenha um dia útil de 8 horas, mas se você estiver gastando uma ou duas horas apagando incêndios, não poderá incluir isso como parte da estimativa.
No que diz respeito às reuniões de pé, você pode sugerir algum outro sistema para rastrear quando determinadas tarefas imediatas serão executadas, como algum tipo de sistema de tíquete de suporte. Isso nem deveria ser discutido durante o standup.
Parece que seu scrum master precisa ser treinado novamente ou repensado por que você está fazendo Scrum em primeiro lugar. Não é adequado para todos os grupos e situações. Alguém no topo não comprou nada.
"o objetivo de um Sprint é decidir o que é feito durante a duração do Sprint": E mesmo esse objetivo pode não ser alcançado devido a estimativas erradas, por exemplo, quando detalhes extras da implementação ficam claros durante a própria implementação.
@ Giorgio - eu diria que o objetivo de um sprint é decidir o que você "tenta" fazer. Se você ficar aquém, use isso para planejar o próximo sprint. Esse é o benefício de um processo iterativo. se for uma falha total, basta desfazer o sprint e iniciar um novo. Não há nada a ser ganho para o planejamento futuro quando você cometer um erro de cálculo drástico que não cometa o mesmo erro.
Eu experimentei um microgerenciamento como esse e a maneira como lidei com sucesso é sendo muito transparente e comunicativa. Não demora muito para ganhar a confiança do gerente; você constrói confiança e eles recuam. Às vezes até dando a você mais espaço e latitude. Seu gerente pode estar se sentindo inseguro ou descontrolado, então isso facilita o processo para eles. Obviamente, não é o ideal, mas você é uma equipe e todos devem ter o mesmo resultado. Boa sorte.
Empatia. Essa é uma habilidade poderosa que nem todo mundo domina :-). No entanto, é bom entender por que o gerente coloca tanta ênfase no planejamento, quando no Agile, a ênfase é focada nas pessoas. Compreender as dores do gerente pode ajudar a conextualizar os porquês da pressão. No entanto, o gerente e a empresa devem estar cientes de que as estimativas são exatamente isso. Premissas. Não é matemática, então eles devem praticar empatia também com os desenvolvedores e dar-lhes crédito.
"Isso será feito quando terminar."
Não vale a pena tentar obter estimativas de conclusão dos desenvolvedores. As estimativas são imprecisas, especialmente se forem baseadas no tempo. Além disso, as pessoas em funções gerenciais tendem a interpretar essas estimativas como compromissos, resultando nos efeitos prejudiciais que seus desenvolvedores estão sentindo.
Uma opção seria evitar responder à pergunta em termos de compromissos de tempo.
"Esta tarefa será concluída depois que eu fizer as coisas A, B e C."
"Tudo bem. E quanto tempo isso vai levar?"
"Veremos no final do dia."
Mudar a conversa dos compromissos de tempo para o que precisa ser feito pode ajudar a mostrar a vantagem e mostrar que "quanto tempo levará para ser realizado" é menos importante do que "o que é preciso para ser feito".
— binskits
Concordo que geralmente é inútil fornecer estimativas até a hora, especialmente para algo criativo como programação que requer grandes quantidades de trabalho ininterrupto. Mas outras pessoas legitimamente precisam saber quando estaremos prontos; portanto, são necessárias estimativas em uma escala de dias ou semanas. Se o "scrum" atrapalhar isso, então o scrum e não a estimativa são o problema. A boa notícia: as estimativas melhoram à medida que você as pratica e podem ser protegidas: "há uma chance de 50 a 50 de que eu esteja pronta hoje, caso contrário amanhã de manhã". Eu também tive boas experiências com técnicas como o planejamento de pôquer.
Concordo que as estimativas podem ser úteis para pessoas de fora da equipe, mas minha resposta foi específica para a pergunta do OP sobre como lidar com o microgerenciamento durante standups.
Não se deixe intimidar pelo scrum master. Fale abertamente e francamente sobre o trabalho que está por vir. Faça perguntas dela como qual é a urgência. Por que tem que ser feito por 4? Se realmente precisa ser feito, outras tarefas podem precisar ser executadas até mais tarde. É sua oportunidade de construir treliça. As respostas de Frank são melhores antes do que desculpas depois.
— Randy Moulton
Quanto mais "micro" for a gerência, mais difícil será fazer uma previsão precisa. Se eu tiver 20 tarefas de oito horas, ou seja, tarefas que são razoavelmente estimadas em oito horas cada, devem ser realizadas em quatro semanas, ou talvez em alguns dias mais ou menos. Se eu tiver uma dessas tarefas, há muito mais variabilidade.
Essa tarefa pode levar 10 minutos se o problema a ser resolvido for muito mais fácil do que eu pensava. (Aconteceu comigo, calculei que precisava escrever bastante código, e acabou que alguém já havia escrito exatamente o que eu precisava). Ou pode demorar uma semana (meu código não funciona por causa de um bug em uma biblioteca que precisa ser corrigida e, em seguida, tem todo o tipo de consequências ruins). Para vinte tarefas, essas coisas se equilibram. Não é para uma tarefa.
Alguém está pedindo para você prever o futuro. Você não pode fazer isso. E, solicitando a previsão de um único evento, as estatísticas não ajudam. O tipo de pessoa que faz essas perguntas não entende o significado de "estimativa". Portanto, se você for perguntado "isso será feito em quatro horas", as possíveis respostas serão "muito prováveis", "talvez, talvez não" e "muito improvável".
Essa é uma boa pergunta. Responderei da perspectiva de alguém com 30 anos de experiência em uma década como gerente de projetos dedicado em todas as áreas, exceto no desenvolvimento de software, mas recentemente tropeçou na área de desenvolvimento de software sem querer. Independentemente da metodologia que está sendo usada em sua equipe e como ela é chamada, no final do dia, os projetos de desenvolvimento são os mesmos que qualquer outro no sentido comercial, de que os objetivos devem ser alcançados dentro de restrições concorrentes de tempo, orçamento e qualidade - - e enquanto os projetos são executados, o negócio continua a se mover e evoluir e tem uma boa chance de injetar mudanças em seu projeto. Portanto, é necessário definir e comprometer-se com objetivos e prazos e poder fornecer atualizações com frequência e quando solicitado. Eu não'
Dito isto, na minha experiência, o que torna as estimativas de tempo no desenvolvimento de software particularmente desafiador é que os projetos de desenvolvimento envolvem muitos territórios desconhecidos. A definição técnica de um "projeto", de acordo com o Conhecimento em Gerenciamento de Projetos do Project Management Institute, é que um projeto deve ser único. No entanto, a grande maioria dos "projetos" em TI são meras reexecuções de projetos e projetos criados anteriormente e livros de execução de implementação. No desenvolvimento de software, temos estruturas e vários padrões de design genéricos que reutilizam grande parte do desenvolvimento, mas ainda assim, o núcleo de cada projeto é completamente único.
Além disso, a maioria dos projetos de desenvolvimento envolve a integração com outros sistemas e a rapidez com que isso pode ser feito é um grande palpite. No momento, estou trabalhando em um projeto em que minhas estimativas de tempo originais se baseavam na suposição de que os 4 sistemas com os quais eu preciso interagir programaticamente teriam APIs, e não há nenhum. Além disso, um dos sistemas é hospedado em nuvem e minha organização possui políticas que proíbem o trabalho que está sendo realizado. Quem poderia ter previsto isso?
À medida que são feitas descobertas que colocam os prazos em risco, é importante comunicar bem por que o atraso surgiu, por que não poderia ser previsto etc.
Também já me disseram que o prazo dado não funcionaria e faria com que isso acontecesse muito "mais rápido". Outra variação está sendo dada uma carga de mudanças para injetar no desenvolvimento, sem também ter tempo adicional. Existe uma lei na física que diz que a matéria não pode ser criada ou destruída, e isso me vem à mente porque parece-me que o tempo também não pode ser criado do nada. A aceleração do desenvolvimento provavelmente terá um impacto negativo na qualidade do lançamento, na capacidade de suporte do produto e / ou na evolução futura do produto.
Solicitações sobre o cronograma devem ser respondidas em termos comerciais gerais. "Sim, estamos no caminho certo para cumprir os prazos comprometidos anteriormente, e não há problemas em preparação que ponham isso em risco". Solicitações para adicionar um escopo significativo sem mais tempo, ou simplesmente acelerar a entrega, devem ser alguma forma de "podemos fazer isso, mas todos sabemos que carregam riscos inerentemente de bugs, porque grande parte do tempo de desenvolvimento é feito para ser proativo, portanto para não introduzir bugs e também para testar de forma abrangente ". Quando eles respondem com "apenas teste mais rápido", obtém uma resposta que explica o teste de desenvolvimento não implica tempo ocioso e pode ser acelerado sem a introdução de algum risco de defeitos ausentes.
Em resumo, estou simplesmente sugerindo que todos os desenvolvedores - não apenas os líderes, o scrum master ou o gerente de projetos, estejam preparados para discutir suas tarefas em um contexto de negócios e ter discussões sobre a alteração dos parâmetros do projeto, tomando conhecimento das vantagens e desvantagens que resultaria.
Esta é uma resposta intimidadora. Não é até o sexto parágrafo que vejo algo parecido com uma resposta acionável e quase parei de ler antes de chegar lá. Convém reescrevê-lo para liderar com a resposta final ("Solicitações sobre a programação devem ser respondidas em termos comerciais gerais") e, em seguida, siga a explicação.
À medida que o trabalho é executado ou concluído, o trabalho restante estimado é atualizado.
- Guia Scrum , página 15
Cada desenvolvedor deve atualizar o status da tarefa e estimar as horas restantes todos os dias em qualquer ferramenta de produtividade que sua equipe use (por exemplo, TFS).
Portanto, a resposta simples para o seu gerente é direcioná-lo para a coluna "horas restantes" na lista de tarefas. Espero que ele saiba que pode acessar esses números pessoalmente e parar de fazer perguntas estúpidas.
O guia Scrum não diz nada sobre como o trabalho é estimado. Pode muito bem ser que o trabalho seja dividido em tarefas e que a atualização seja baseada na conclusão e nas tarefas restantes.
Se uma tarefa for dividida em várias subtarefas, o scrum master ainda poderá ver como estão as estimativas atuais.
Ao fazer qualquer uma das perguntas acima, o que o scrum master está tentando decidir é se estamos no caminho certo para este sprint e se há algum problema de bloqueio para que você possa competir nessa tarefa.
Os pontos da história não se correlacionam com o horário de trabalho, eles não devem, mas perguntando se você pode fazer algo até uma data, ele está realmente perguntando o que está impedindo você de competir nessa tarefa? Se você precisar de alguma coisa, em minha opinião, o papel dele é garantir que você possa competir no sprint, é isso que ele está realmente perguntando ...