Como você lida com os custos de mudanças muito rápidas?

Como a maioria dos desenvolvedores modernos, eu valorizo ​​os principais do Agile, como a colaboração do cliente e a resposta à mudança, mas o que acontece quando um proprietário do produto (ou quem determina requisitos e prioridades) altera os requisitos e as prioridades com muita frequência? Como várias vezes ao dia?

Recentemente, herdei uma base de código pequena que estava com erros, incompleta e nem conseguia lidar com o cenário mais simples que deveria. Eu posso lidar com os problemas técnicos, mas recebo vários e-mails, textos ou telefonemas por dia dizendo "OMG, você DEVE trabalhar neste AGORA! PRIORIDADE SUPERIOR! Essa é uma obrigação !!!" (isso é apenas um pequeno exagero) O que torna ainda pior é que a maioria das coisas são pequenos detalhes que nem são relevantes para o que o software realmente deve fazer e levaria dias para ser implementado de qualquer maneira. Tentei explicar que há muito tempo e que devemos nos concentrar primeiro nas coisas mais importantes, mas algo parece se perder na tradução porque a mesma coisa acontece um ou dois dias depois.

Existe algum tipo de função de Product Owner Owner Handler, estudo aprofundado, metáfora ou citação que pode me ajudar a reduzir a quantidade de esforço desperdiçado ou pelo menos explicar os custos desse comportamento caótico?

É para isso que serve o backlog. Novas solicitações são colocadas na lista de pendências e as prioridades só podem mudar nos limites da iteração. Uma demora média de uma semana (metade de uma corrida de duas semanas) é bastante ágil o suficiente para lidar com todas as emergências, exceto as mais terríveis.

Aqui está como eu lidei com um problema semelhante. Nos tempos em que éramos ágeis antes do Agile.

Para qualquer solicitação de alteração, o cliente define a prioridade. O desenvolvedor pode apenas e deve interromper o trabalho em uma tarefa para trabalhar em uma tarefa de prioridade mais alta. Tarefas de prioridade igual são agendas em ordem de chegada. (A prioridade da tarefa não pode ser alterada após o início do trabalho.)

Vai doer quando você diz ao cliente que não pode trabalhar em sua tarefa porque está trabalhando na tarefa X sem importância que tem a mesma prioridade que sua solicitação mais recente. Você então diz a ele que, nesse nível de prioridade, há 50 tarefas triviais e sem importância antes do último pedido. Agora, o verdadeiro problema - todas essas tarefas estão no nível de prioridade 1 (o mais alto), definido por ... ELE ... Portanto, ele não pode impedir você da tarefa que está realizando. Agora, quando você terminar de mover o quadro da janela 3 pixels para a esquerda, deixe espaço para a palavra mais longa na tradução islandesa na opção de configuração raramente usada .....

Também fecho a porta do escritório da SD, tranquei e tirei os telefones do gancho. Os e-mails foram ignorados até às 10h, 12h e 14h. Apesar do que as pessoas pensavam e sentiam, o mundo ainda girava em torno do sol, realizamos nosso trabalho e os "Clientes" enviaram o software a eles mais rápido e melhor do que em qualquer outro momento do passado.

Demorou algumas semanas para as prioridades chegarem a algo mais realista, fomos capazes de abrir a porta, etc ... Mas o sistema permaneceu por um longo tempo. Talvez você não precise ser tão extremo (como fizemos) e precisará do apoio da gerência sênior. Mas vai funcionar ....

SOP. Procedimento operacional padrão (ou pelo menos um protocolo solto assinado pela sua equipe de gerenciamento). Seu departamento precisa desenvolver um ou trabalhar com sua equipe de gerenciamento para desenvolver um. As pessoas com quem você precisa conversar estão acima do proprietário do produto / gerente da conta.

Alguns exemplos do que seu POP deve definir.

• Quais procedimentos devem ser seguidos quando um cliente ou entidade interna solicita uma alteração
• Quais são as implicações e / ou impacto no controle ou verificação da qualidade deste produto?
• Qual é o método para determinar razoavelmente um prazo para entrega? Esta iteração? Próxima versão?

Sem esses procedimentos, todo mundo vai correr para você como se estivesse sendo perseguido por zumbis e esperar tudo AGORA AGORA AGORA. Pessoas assim não respeitarão seu educado "não" ou "por favor, espere". Com uma política firme em vigor, esses mutantes que desejam adivinhar o código entenderão que estão errados ao pedir coisas de maneira tão vaga.

O resultado final é infeliz para você e isso não é do seu interesse.

Em uma nota lateral, você pode ter herdado a bagunça de alguém causada por um desrespeito flagrante por sua posição e dever. As pessoas nessa situação tendem a achar difícil produzir produtos de qualidade. Não é de admirar? Engenharia de software 101.

É muito difícil trabalhar nessas condições de "pronto, disparar, apontar". Parece-me que você está recebendo requisitos de uma pessoa muito insegura, cuja opinião muda cada vez que uma pessoa superior sugere uma idéia conceitual.

Nesses tipos de situações, achei valioso esperar PELO MENOS uma hora antes de responder aos e-mails. (Eu ignoraria os textos, a menos que os textos substituíssem amplamente o email da sua organização como um todo.) Leia-os, talvez, mas não responda. Dessa forma, você pode gastar seu tempo concentrando-se no trabalho real que precisa realizar, e não na discussão de urgências aleatórias que podem se tornar irrelevantes amanhã ou até dois ou três e-mails depois. No meu último trabalho, se algo fosse realmente urgente, alguém viria falar comigo pessoalmente, assumindo que eu ainda não tinha visto os e-mails (se você trabalha remotamente, uma ligação com uma conversa real de duas vias pode ser a equivalente).

Quando você tem uma conversa cara a cara ou por telefone, é útil repetir o que a pessoa está pedindo com suas próprias palavras e depois fazer suas perguntas sobre os novos requisitos e prioridades. "Se eu entendi direito, você está dizendo que devemos parar de trabalhar na atual prioridade máxima X e agora focar na prioridade do minuto Y. Essa é uma grande mudança. Você pode explicar a mudança nos negócios? Talvez seja necessário fazer mais informações funciona do que apenas alterar a interface do usuário. Haverá alterações em outros processos de negócios, como cobrança ou inventário (por exemplo)? Você espera que esses novos elementos de dados apareçam em todos os relatórios mensais? " Também é útil dizer algo no sentido de "Você entende que, se prosseguirmos com esse novo esforço, atrasará o lançamento da prioridade máxima atual X em pelo menos uma (semana, mês,

Se for uma emergência real, o solicitante deve poder responder a esse tipo de perguntas ou encaminhá-lo imediatamente para alguém que possa. Se não for uma emergência real, esse tipo de conversa forçará o solicitante a desacelerar e determinar a importância da mudança, já que eles precisam obter mais informações. Muitas vezes, eles verão que o que já está no canal é mais importante, ou pelo menos não vale a pena parar, e a nova solicitação pode entrar na lista.

Se as alterações forem determinadas como necessárias, achei útil anotar o que foi solicitado e seu entendimento das alterações em um email e enviá-lo ao solicitante original, perguntando se eles concordam com o escopo da alteração, novamente, como esclarecimento. Dessa forma, você escreveu a documentação do que precisa ser feito e por que ela foi solicitada, caso ocorra alguma reviravolta no motivo pelo qual você não está mais trabalhando no Current Top Priority X, ou precise explicar por que os prazos originais não estão indo a ser cumprido.

Esperamos que isso melhore o seu relacionamento com o solicitante, pois você está demonstrando seu conhecimento e se certificando de que está trabalhando no que ele deseja, mas sendo honesto com o que é preciso para fazer alterações. Ao perguntar sobre a solicitação em detalhes, eles veem que você pensa no futuro e consideram coisas que talvez não tenham originalmente.

Parece que ninguém o mencionou ainda, o Sprint e suas histórias de usuário ideally should be locked till the next sprint(o sprint típico leva de 2 a 4 semanas). Ao bloquear - quero dizer que nenhuma tarefa adicional deve ser adicionada ao Sprint já iniciado.

Se a história do usuário for grande o suficiente para não caber no sprint, reduza-o a tarefas menores e viáveis ​​durante o sprint. Além disso, como mencionado até mesmo tarefas priorizadas precisa ser espera no backlog , e durante o próximo planejamento do sprint de alta prioridade, uma vez chegar a bandeira up :)

Editar: apenas pequenas alterações podem ser introduzidas durante a primavera. se eles carregam estado de emergência. No entanto, se sempre houver algumas emergências durante o sprint, algo precisa ser alterado no próprio planejamento do Sprint.

O Scrum tem a função Scrum Master, que seria a pessoa que deveria resolver os problemas mencionados.

Se houver alguém como um líder de equipe, gerente de projetos, scrum master etc. que seja responsável, eu conversaria com essa pessoa.

Tentei explicar que há tanto tempo e que devemos nos concentrar primeiro nas coisas mais importantes, mas algo parece se perder na tradução porque a mesma coisa acontece um ou dois dias depois.

Eu acho que você terá que continuar explicando isso de novo e de novo e de novo. Parece que você pode precisar aceitar que certas pessoas com quem trabalha têm hábitos inúteis. Se você tiver sorte, verá uma mudança eventualmente.

O Manifesto Ágil diz que um dos princípios mais fundamentais é:

Bem-vindo, alterando os requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.

No entanto, não acredito que eles significassem mudanças diariamente. Pode ser necessário alterar o preço base de um produto várias vezes ao dia, mas não alterar a forma como esse produto pode ser vendido várias vezes ao dia. Em vez disso, o fluxo de trabalho das vendas de um produto pode mudar semanalmente (em empresas altamente responsivas e dinâmicas).

Novamente, enquanto o fluxo de trabalho de vendas de um produto pode mudar a cada semana, acho que o produto geral não será alterado a cada semana. Não consigo imaginar uma Microsoft que hoje nos dê o Office, mas amanhã nos dará Offooose, e uma semana depois Offasooooooooooos.

Não, não é isso que ágil significa mudança. Eu acredito que vem de más visões e de um grande mal-entendido profundo do conceito de mudança.

Muito menos mencionar que a mudança não é bem-vinda em um sprint, onde os desenvolvedores vão para suas cavernas e precisam se concentrar no que estão fazendo. Em vez disso, as alterações devem ser adicionadas ao Backlog do Produto e analisadas e priorizadas antes de serem entregues nas mãos da equipe de scrum. Em outras palavras, um Sprint Backlog não é imutável. Deve-se buscar mais agilidade usando sprints mais curtos, não injetando alterações diretamente nas salas dos desenvolvedores, muitas vezes ao dia.