ti-enxame.com

Como você lida com as mudanças nos requisitos?

No meu trabalho atual, parece que temos muitas mudanças de requisitos. Somos uma loja "Ágil", então entendo que devemos ajustar e o que não, mas às vezes a mudança é grande e nada trivial.

Minha pergunta é: como você comunica efetivamente o custo da mudança? Por ser ágil, se uma mudança for grande o suficiente, alguma coisa será descartada do sprint atual, mas geralmente será adicionada na próxima vez. Como nosso modelo é SaaS, o cliente final é efetivamente o próprio negócio e eles sabem que obterão o recurso de corte n semanas depois.

Eu acho que o que estou tentando entender é que a remoção de um recurso não é realmente algo para usar na comunicação, pois foi adiada por n semanas. Que outras maneiras você tem para que a empresa entenda quanto custa uma mudança?

14
user81

@ Joe "Somos uma loja" Agile ", então entendo que devemos ajustar o que não é, mas às vezes a mudança é grande e nada trivial".

Se o seu processo não permitir que você controle a taxa de alteração nos requisitos, ele não será ágil, mas aleatório. Agile não significa "pegar qualquer coisa que aparecer no meu caminho".

Para controlar a mudança/fluência de requisitos, você pode adotar - em seu processo - a noção de que um requisito não muda (uma noção de que está no coração do Scrum.) Trate uma alteração de requisito como substituindo um requisito antigo por um novo. Você precisa ter uma lista de requisitos, e o usuário deve escolher quais deseja implementar.

Você queria X e Y em duas semanas, mas de repente você quer Z. Bem, então eu posso entregar todos os três em quatro semanas. Ou posso dar um par (X e Z) ou (X e Y) ou (Y e Z) em duas semanas e entregue o restante mais tarde. Escolha.

É assim que você negocia com os clientes. É assim que você comunica o custo da mudança de requisitos. Se o seu grupo não tem esse poder, você não está em uma loja ágil e não há nada que possa fazer. É péssimo, mas é verdade.

Caso você possa negociar, é necessário rastrear (com precisão) o tempo necessário para implementar requisitos e alterações de requisitos. Ou seja, você precisa coletar esses dados de projetos passados ​​e presentes.

Você coleta a estimativa de tempo original e o tempo real de conclusão (além de recursos como a contagem de desenvolvedores) por solicitação (ou módulo afetado por N solicitações). Melhor ainda, estimar o tamanho da solicitação/alteração de solicitação (em termos de linhas de código ou pontos de função em projetos e solicitações anteriores).

Digamos que você tenha uma métrica com a qual possa conversar com o usuário. Você sabe que uma nova solicitação terá, digamos, 1K linhas de código ou 10 páginas da Web com uma média de 5 campos de entrada cada (50 pontos de função).

Depois, analisando dados históricos específico para seus projetos anteriores (alguns por linhas de códigos, alguns por páginas da Web, outros por pontos de função reais), e você pode estimar como cada um deles custa em termos de valor absoluto. tempo de conclusão. Para aqueles com dados suficientes, você também pode identificar os requisitos que acompanham uma contagem real de desenvolvedores.

Então você usa isso e diz ao seu cliente que, com base em dados históricos; você argumenta que as falhas do projeto tendem a seguir uma distribuição exponencial; e então você está armado com o seguinte argumento para seu cliente:

Com base nos dados de nossos projetos anteriores e atuais e nos recursos disponíveis, o requisito que você está solicitando terá

  1. X tempo para concluir com uma probabilidade de falha de 25% (ou 75% de sucesso)

  2. 1,5 * X quantidade de tempo para concluir com 5% de falha (ou 95% de sucesso)

  3. 0,5 * X quantidade de tempo para concluir, com 95% de falha (ou 5% de sucesso)

A probabilidade de falha em função da quantidade de tempo que os recursos costumam atingir 95%, 25% e 5% (semelhante a uma distribuição exponencial). Você transmite a mensagem de que uma certa quantia da linha de base oferece uma chance um tanto decente de sucesso (mas com riscos reais ) 1,5 disso pode dar quase uma certa chance de sucesso com risco mínimo, mas muito menos que isso (0,5 do original garante quase certa falha).

Você deixa eles digerirem isso. Se eles ainda optarem pela proposição arriscada (feita ontem!) pelo menos você tem por escrito que disse isso a eles. Se houver esperança de que seu grupo não seja apenas ágil, mas de engenharia, o cliente poderá considerar seriamente seus números e agendar essas e futuras solicitações de acordo.

É seu trabalho como engenheiro explicar em termos engenheiro, verificáveis ​​e claros que solicitam alterações não são refeições gratuitas.

15
luis.espinal

Pelo que você descreveu, você não tem um problema. Eles pedem uma alteração e estão dispostos a esperar até que você diga que pode ser feito ou adiam outro recurso. Parece um equilíbrio entre: tempo, recursos e requisitos.

8
JeffO

Você pode tentar definir a idade mínima para uma nova adição/alteração (não aplicável a correções de bugs). Por exemplo, nenhuma nova alteração pode ser trabalhada até os 3 semanas de idade.

Ter uma idade mínima para uma tarefa é bom porque, no início, todas as tarefas parecem extremamente importantes, mas se você esperar um pouco, sua importância geralmente cairá significativamente. Dependendo do seu intervalo de tempo, você terá pelo menos esse período de estabilidade nas tarefas em que está trabalhando.

Para rastrear a idade, você permitiria que as tarefas fossem adicionadas a alguma lista, mas elas não seriam consideradas tarefas a serem trabalhadas até que esse período expire.

4
Brian R. Bondy

Esse é um problema muito comum, não importa a rapidez com que um projeto avance em termos técnicos, o cliente o percebe como muito mais lento e fica à vontade para alterar os requisitos, pois gosta de pensar que os desenvolvedores não devem estar fazendo muito.

Essa percepção falha vem de três grandes tarefas de desenvolvimento que consomem tempo e nunca serão contabilizadas adequadamente pelos clientes:

  1. Revisões/limpeza de código: o código antigo fica inchado e bagunçado e precisa de revisões e limpezas regulares, isso leva muito tempo e o cliente nunca acreditará.
  2. Auditoria e correções de segurança: Especialmente se você tiver membros juniores da equipe, terá muitos problemas de segurança relacionados ao código e desejará revisar regularmente todo o novo código que foi escrito e reescrever coisas que não parecem boas em uma segurança perspectiva, o cliente nunca saberá ou responderá por esse tempo.
  3. Alterações relacionadas à arquitetura: Uma base de código crescente pode (e provavelmente exigirá) em vários pontos exigir repensar e refatorar estrutural, isso pode envolver: A - Alterações/otimizações relacionadas ao desempenho (alterações de algoritmo, substituições de bibliotecas, mecanismos de cache, etc.) ou: B - Alterações/otimizações relacionadas à produtividade (legibilidade, reutilização de código, facilidade de entendimento, novas convenções de codificação, uma nova estrutura, ... etc).

Nenhuma das opções acima será entendida e contabilizada adequadamente pelos clientes finais.

Basicamente, o que não tem "visualizações" (elementos da GUI) não foi feito.

Vamos chamar isso de teorema do projenix, haha ​​não é brincadeira: D

1
Projenix