Retrabalho em projetos de software

Retrabalho de software explicado

Retrabalho de software é o trabalho consequente que surge da alteração de requisitos, designs, código e testes após algum trabalho já ter sido iniciado. Na maioria dos empreendimentos de software, isso representa 30-50% de todas as atividades. Geralmente excluímos a correção de bugs da categoria de retrabalho de software. O retrabalho geralmente descreve o trabalho extra que é consequência da “mudança de requisitos”.

Retrabalho de software – bom ou ruim

Algum retrabalho pode ser visto como um indicador positivo de que o feedback dos usuários está orientando a mudança na direção do que é necessário. Isto é justo se as mudanças forem imprevisíveis. No entanto, os níveis típicos de retrabalho em projetos de software são teimosos, em torno de 30-50% de todo o esforço. Isso está custando à maioria das organizações substancialmente mais para fornecer software do que deveria.

Como o retrabalho de software faz com que os custos aumentem

Um problema específico com o retrabalho de software é que ele é mais lento ou menos produtivo que o desenvolvimento inicial. Em outras palavras, escrever código pela primeira vez é mais rápido do que alterar esse código para fazer outra coisa. Usando uma abordagem padrão para medição e produtividade de software, podemos acompanhar a produtividade das equipes de software quando elas fazem a construção inicial e para o retrabalho. As taxas típicas de criação de desenvolvedores são em torno de 1 Ponto de função CÓSMICO (CFP) por dia (faixa típica: 0,7-2 CFP/dia), enquanto a produtividade no retrabalho é menor, 0,75 CFP por dia.

Quando o retrabalho é necessário, você se esforça para fazer o trabalho pela primeira vez (1 dia para 1 CFP) e depois (mais 1,5 dias por CFP) para modificá-lo. Portanto, o custo total passa a ser 2,5 dias em vez de 1 dia.

Esta explicação simples mostra como projectos modestos de TI podem tornar-se desastres orçamentais. Ao rastrear antecipadamente a qualidade dos requisitos, a probabilidade do desastre torna-se previsível. Além disso, ao dar mais atenção aos requisitos de qualidade, o retrabalho precoce pode ser reduzido substancialmente.

As causas básicas do retrabalho

Quando tomamos consciência de que alguma característica que estamos construindo, ou construímos, não está certa, deve-se tomar uma decisão entre deixá-la errada ou corrigi-la. Mais tarde no ciclo de vida de desenvolvimento em que essa descoberta é feita, mais retrabalho, interrupções e atrasos são causados. Não importa se o requisito é o resultado de uma conversa, de uma história de usuário escrita ou de um documento escrito mais detalhado. A incorreção ou falha de comunicação é a provável causa raiz do retrabalho. Talvez o requisito original tenha sido mal compreendido, mal interpretado ou mal comunicado, tudo se resume a uma comunicação deficiente. A má comunicação é por vezes rejeitada ou deturpada como “mudança de requisitos”, quando na verdade não era.

A maioria das mudanças não é genuína

Muito ocasionalmente, vemos uma mudança genuína e inesperada nas circunstâncias de negócios durante um projeto que leva a requisitos alterados. No entanto, a maioria dos requisitos são conhecidos ou conhecíveis antecipadamente. Da mesma forma, a maioria das decisões arquitetônicas necessárias para satisfazer esses requisitos são conhecidas (antecipadamente). Às vezes o usuário diz “não sabemos o que precisamos até ver”. Para descobrir esses requisitos, é necessário usar técnicas extras de elicitação, como a prototipagem.

A grande maioria das “mudanças de requisitos” e, portanto, do retrabalho, são causadas por um trabalho de requisitos deficiente ou incompleto.

Algumas causas raízes de retrabalho relacionadas aos requisitos (uma lista incompleta):

• Requisitos mal articulados
• Requisitos conhecidos, mas não declarados (omissões)
• Inconsistências em um conjunto de requisitos.
• Requisitos não declarados que poderiam ter sido descobertos através da prototipagem (ou seja, o usuário precisa ver algo primeiro)
• Requisitos não declarados que poderiam ter sido descobertos por meio de análise
• Confusão entre objetivos de negócio, requisitos funcionais e critérios de aceitação. (má articulação).
• Confusão entre restrições funcionais, não funcionais e tarefas.
• E talvez a única razão legítima para o retrabalho: requisitos desconhecidos e desconhecidos

O retrabalho continua predominante em níveis elevados – Justificativa

A maioria dos estudos mostrará que 30-50% de todo o esforço em projetos de software é gasto em retrabalho. Existem vários motivos pelos quais os níveis de retrabalho permanecem elevados. Algumas das razões raramente são discutidas, pois podem ser verdades incômodas.

Requisitos inconsistentes com padrões de qualidade

A indústria não consegue chegar a acordo sobre o que constitui bons requisitos. Uma organização que tenta promover a qualidade dos requisitos é o IIBA. Para a maioria das pessoas, não existem padrões formais para requisitos de redação e a qualidade geralmente é baixa.

Evitando comunicações importantes

A maioria dos desenvolvedores gosta de escrever código, geralmente são introvertidos e não são grandes comunicadores. A interação humana pode não ser tão fácil para eles e eles ficam mais satisfeitos em refazer o trabalho do que em ter conversas sobre requisitos desafiadores com antecedência.

Freqüentemente, as equipes de desenvolvedores descrevem o retrabalho como “refatoração de código”. Eles podem acomodar requisitos inadequados e usar a desculpa: “somos ágeis, aprendendo à medida que avançamos”. Ou podem dizer que os usuários não sabiam o que queriam até que mostrássemos a eles. A primeira é uma desculpa para “não aprender antes de partir”; o último é um problema superado de forma mais barata com a prototipagem.

Nenhuma responsabilidade por boas histórias de usuários

As histórias de usuários são a base da comunicação de uma equipe ágil sobre o que será construído. Mas quem é o responsável pelas histórias de usuários? Quem é responsável por garantir que eles descrevam corretamente um conjunto holístico de necessidades que proporcionem capacidades valiosas? Equipes diferentes dão respostas diferentes, algumas dizem o proprietário do produto, outras dizem que toda a equipe. A falta de responsabilidade clara pode levar a histórias de usuários de qualidade inferior, o que, por sua vez, leva a mal-entendidos e retrabalho. Quem é responsável pela qualidade das histórias de usuários? Novamente, obtemos respostas inconsistentes a essas perguntas. Revisitar a clareza de uma história de usuário é um trabalho tedioso que envolve pelo menos três membros da equipe (os três amigos). É um trabalho demorado e um tanto enfadonho que muitas vezes acontece de maneira ad hoc, se é que acontece. Idealmente, a necessidade dessas sessões é reduzida com a co-localização da equipe. Com o trabalho remoto, a co-localização é essencialmente impossível. Em alguns casos, o proprietário do produto é um representante proxy do usuário real e verdadeiro especialista no assunto. Todos levam a requisitos de qualidade mais baixos.

Contratos que aumentam os níveis de retrabalho

Quando o desenvolvimento de software é terceirizado. A empresa para a qual o trabalho é terceirizado normalmente é paga com base no valor diário. Para eles quanto mais dias trabalhados, mais dias faturados. Pode haver alguns marcadores contratuais que encorajam superficialmente o trabalho eficiente, mas estes geralmente carecem de força. Em última análise, geralmente é do interesse da organização contratada incorrer em altos níveis de retrabalho. E por isso vemos frequentemente os piores requisitos nos compromissos contratados. Na minha experiência, há uma charada sobre trabalho eficiente; na realidade, a maioria dos empreiteiros são incentivados a estender o projeto e vender mais dias-homem. Com requisitos inadequados, o retrabalho é alto e mais horas faturáveis são inevitáveis. Se você estiver adquirindo desenvolvimento de software contratado, cuidado.

Causas Culturais do Retrabalho

Se um requisito não estiver claro, a equipe deverá verificar seu entendimento antes de iniciar o trabalho. Quaisquer possíveis mal-entendidos provavelmente causarão retrabalho. Em algumas culturas, questionar as necessidades do cliente é uma conversa desconfortável que eles preferem evitar. Em vez disso, a equipe pode trabalhar com base em suposições e desenvolver essas suposições. Isso é particularmente comum em contratos terceirizados. Quando os requisitos são escritos em um idioma que não é a língua materna de todos os membros da equipe, é altamente provável que haja mal-entendidos (e, portanto, retrabalho).

Reduzindo o retrabalho

Observe e quantifique o problema

No final de cada sprint, pergunte-se quanto trabalho acabamos de fazer que foi retrabalho versus novo trabalho. Em seguida, pergunte-se: como poderíamos ter evitado isso. Por fim, registre o esforço extra (ou seja, o custo) que surgiu porque você teve que fazer o trabalho mais de uma vez.

Abrace padrões para escrever bons requisitos

Nossa lista recomendada de atributos de qualidade é:

1. Claro
2. Conciso
3. Orientado ao usuário
4. Testável
5. Mensurável
6. Consistente
7. Completo
8. Exclusivo
9. De valor
10. Sem design

Com exceção do #9 nesta lista, o ScopeMaster verifica automaticamente seus requisitos quanto à aderência a esses atributos de qualidade, para que você não precise verificá-los manualmente. (Não recomendamos a lista INVEST porque ela não cobre todas as características acima que consideramos importantes.)

Use ferramentas que melhoram os requisitos

OK, então construímos o ScopeMaster exatamente para esse propósito. Usando o ScopeMaster você irá expor e resolver 9/10 dos tipos de qualidade comuns listados acima e a uma taxa cerca de 10x mais rápida do que fazê-lo manualmente. Resumindo, você pode esperar uma redução drástica do retrabalho usando o ScopeMaster para ajudá-lo a avaliar e refinar seus requisitos. Existem outras ferramentas do QVScribe e até do IBM Doors, mas elas apenas arranham a superfície do que o ScopeMaster faz.

Escreva contratos que incentivem baixo retrabalho

Existem várias maneiras de lidar com esse problema. Primeiro, é estar ciente de que isso é uma preocupação. Lembre-se de que a maior parte do retrabalho é evitável. Temos um pacote de recomendações contratuais que podem ajudá-lo a moldar seus contratos de desenvolvimento terceirizados para minimizar a probabilidade de retrabalho.

Quantificando o Retrabalho

Vimos que o retrabalho causado por requisitos inadequados faz com que o esforço aumente de 1x para 2,5x. Na verdade, esta é uma estimativa modesta, porque quando você muda de direção, a interrupção de um bloco de código pode ter um impacto negativo em outras partes da base de código, causando ainda mais retrabalho.

Prevendo Defeitos – Usando números para reduzir retrabalho

Estudos reuniram dados sobre a criação e também a remoção de defeitos. Estes mostraram que potenciais defeitos ocorrem em cada um dos principais artefatos de desenvolvimento de software: requisitos, design, código, testes. A consequência é que conhecemos os potenciais de defeitos de cada um e, portanto, quantos defeitos precisamos remover até atingirmos uma qualidade satisfatória. Novamente, usando o dimensionamento padrão, sabemos que os potenciais de defeitos típicos são de aproximadamente 5 defeitos por CFP, dos quais 1 provavelmente está nos requisitos. Também sabemos que o tamanho médio de uma história de usuário é 5,5 CFP e, portanto, temos um potencial de defeitos de requisitos de 5,5 por história de usuário. Isso significa que, a menos que sejamos proativos, esses defeitos 5,5 permanecerão e se transformarão em retrabalho mais tarde. Ferramentas como o ScopeMaster podem encontrar cerca de 50% de defeitos nos requisitos, ou seja, 2 a 3 por história de usuário. Isso reduz pela metade a provável causa do retrabalho.

Escrito por Colin Hammond, 35 anos de experiência em TI e fundador da ScopeMaster.