O desperdício de projetos de software está custando $1bn por dia em empresas e governos em todo o mundo realizando trabalhos que são completamente desnecessários.
Todos os dias, equipes de software em todo o mundo desperdiçam 30-60% do seu tempo (e o tempo e o dinheiro dos empregadores) devido a práticas ineficientes. A maior parte deste desperdício é evitável. A qualquer momento, cada membro da equipe pode estar fazendo um trabalho útil, mas, o trabalho que estão fazendo poderia ter sido evitado. Na maioria dos casos, os gestores não têm consciência de que isto está a acontecer.
Este artigo analisa algumas das principais causas de desperdício no trabalho de software. Vamos começar examinando as atividades das equipes de software que são um desperdício. Todos que trabalharam em um projeto de software terão experimentado vários deles.
Esforço e tempo são frequentemente desperdiçados pelas equipes de software:
- revisitando recursos mal projetados de sprints anteriores,
- compreender e retrabalhar códigos mal estruturados de outros desenvolvedores em sprints anteriores,
- abordar mal-entendidos porque o autor do requisito não garantiu que os requisitos fossem claros de modo que todos os leitores (usuários, arquitetos, desenvolvedores, testadores) chegassem a um entendimento comum,
- fazendo retrabalho porque o autor do requisito entendeu mal o que era realmente necessário,
- escrever testes manuais ou automatizados contra requisitos que mais tarde se revelam incorretos,
- alterar ou eliminar código incorreto porque os requisitos eram ruins,
- retrabalho ou trabalho extra porque uma estrutura de dados ruim foi escolhida, talvez porque os requisitos eram inconsistentes,
- implementação de requisitos de baixa prioridade porque uma imagem mais completa de todo o conjunto de requisitos não estava sendo considerada ou não estava disponível.
- retrabalhar o código devido ao uso de linguagem inconsistente e não estruturada nos requisitos,
- corrigir e testar novamente bugs que seriam evitáveis se os requisitos e projetos tivessem sido mais claros,
- escrever critérios de aceitação detalhados e inadequados de requisitos que não possuem uma descrição básica,
- troca de tarefas causada por retrabalho devido a requisitos ou projetos inadequados. (o oposto de “faça bem e faça uma vez”)
- participar de reuniões de estimativa (ponto de história) que são principalmente dedicadas a descobrir o significado dos requisitos, porque os requisitos não são claros,
- trabalhar em projetos que são posteriormente cancelados porque o projeto excedeu o orçamento e o cronograma, porque o conhecimento do escopo geral era fraco ou incompleto no início
Muito se fala sobre práticas lean por equipes de software, que tem tudo a ver com eliminação de desperdícios. No entanto, é raro encontrar equipas que examinem cuidadosamente a origem e a magnitude reais dos resíduos, determinem o seu impacto no progresso e determinem como poderão ser evitados no futuro. A maioria das equipes está incorrendo em algumas ou muitas das atividades dispendiosas acima. O impacto acumulado gira em torno de 40-50% de todo o trabalho realizado pelas equipes de software. E a maior parte disso é evitável.
Esforço desperdiçado no trabalho do conhecimento
O esforço desperdiçado em conhecimento é comum e substancial. Por exemplo, alterar um código que já é estável é muito caro porque ele e todos os recursos ao seu redor precisam ser reconsiderados e testados novamente. O novo teste é necessário para garantir que a mudança não introduziu algum efeito adverso. Uma alteração de código de uma linha pode exigir um novo teste de milhares de linhas de código relacionado. O desenvolvimento orientado a testes (TDD) é uma técnica que ajuda a aliviar esse problema, mas não evita o problema, nem detecta todos os defeitos possíveis.
Em projetos com equipes maiores, o trabalho de uma pessoa depende do trabalho anterior de outra pessoa. Antes de fazer uma alteração em algum código, um desenvolvedor precisa entender o que seu antecessor escreveu, depois descobrir onde mais ele estava sendo usado e, finalmente, começar a fazer as alterações desejadas. O mesmo se aplica a requisitos, projetos e testes. O pré-mudança aprendizado pode levar horas ou até dias. O que parece ser uma pequena modificação pode tornar-se desproporcionalmente muito caro.
Pular de um trecho de código para outro envolve mudança de contexto. Para que o conhecimento funcione bem, precisamos nos concentrar e evitar a mudança de contexto. A correção de bugs envolve mais mudança de contexto do que escrever o código em primeiro lugar. A troca de contexto é um desperdício total. A combinação de reaprendizagem e mudança de contexto explica de alguma forma como uma pequena mudança de código pode ser extraordinariamente cara. Idealmente, queremos modificar um método o menor número de vezes possível além do sprint em que ele foi criado.
As equipes medem o desperdício real?
Em geral, não, não. É isso mesmo, $1Bn por dia estão a ser desperdiçados por empresas e governos em todo o mundo e muito poucos estão a medi-lo. Este desperdício não irá reduzir ou desaparecer magicamente por si só; é necessário um trabalho pró-ativo.
A análise da causa raiz pode ser útil para identificar onde, por que e quanto desperdício está sendo gerado. Antes de considerar um trabalho de software futuro que exija uma alteração ou correção no código existente, devemos nos fazer algumas perguntas importantes. Aqui está uma lista não exaustiva:
- Este requisito ou alteração poderia ter sido previsto ou razoavelmente antecipado?
- Como poderíamos saber disso antes para evitar a necessidade de alterar o código existente? Essa mudança poderia ter sido totalmente evitada?
- Quanto esforço extra e duração prolongada são causados por fazer essa alteração agora em comparação com se tivéssemos resolvido isso quando o código foi escrito pela primeira vez.
- Quanto tempo e esforço extras estão sendo dedicados aos testes de regressão como resultado dessa mudança?
- Qual é o efeito indireto de fazer essa mudança agora em comparação com se tivéssemos feito isso antes.
- Essa alteração introduz novos riscos de desempenho ou de segurança no código implantado anteriormente (ela introduz uma correção incorreta)?
- Esta mudança é expressa em termos inequívocos, de modo que qualquer leitor a compreenda?
A causa raiz mais comum
A causa raiz da maior parte desse desperdício é o mau trabalho nas primeiras partes do ciclo de vida do software. Trabalho de requisitos deficiente, decisões de arquitetura apressadas, opções de solução desleixadas ou trabalho de design.
A maioria das equipes de software raramente considera o impacto real dos defeitos de requisitos em sua produtividade e o desperdício causado por eles. Além disso, eles podem ignorar o custo de más decisões de projeto até muito depois de o projeto ter sido implementado. Isso é rotulado como dívida técnica.
Requisitos pouco claros que são implementados com um design pobre e inflexível podem levar a custos extraordinários de retrabalho. Esse custo de retrabalho pode então ser ainda maior se causar atraso em outros trabalhos relacionados e não relacionados. Em alguns casos, e com bastante frequência em projetos maiores, requisitos inadequados e decisões de projeto iniciais inadequadas podem levar ao desmantelamento de um projeto inteiro.
Defeitos de requisitos descobertos tardiamente são geralmente o tipo de defeito mais caro para corrigir.
Cerca de $720Bn são gastos globalmente em trabalho de software empresarial. Cerca de metade disso é retrabalho que é evitável e é causado por requisitos inadequados, decisões de projeto inadequadas e pelas consequências de ambos. Globalmente, isso representa cerca de $360 bilhões por ano ou cerca de $1 bilhões por dia.
E quanto ao Ágil
O Agile não cura o desperdício que descrevemos aqui. O principal benefício das metodologias ágeis de desenvolvimento de software é um rápido ciclo de feedback entre usuários e desenvolvedores. Vemos que, em muitos casos, a adoção do Agile traz consigo uma queda na qualidade e na diligência dos requisitos e de outros trabalhos de pré-codificação. As organizações estão com pressa para fornecer novos recursos baseados em software. Os envolvidos na execução do trabalho apresentam uma abordagem de “adaptar à medida que avançamos”, o que parece atraente. Se bem executadas, as práticas Agile ajudam a garantir que o cliente obtenha algo que deseja, mas quando acompanhadas de um trabalho de pré-codificação desleixado, os resultados são níveis significativos de retrabalho durante o projeto e maior desperdício de esforço.
Dados de milhares de projetos mostram que há tantos defeitos introduzidos antes da codificação quanto durante a codificação.[eu] Isso é conhecido como potencial de defeito. 16% – 35% de todos os defeitos de produção são causados por requisitos inadequados ou incompletos.[ii]
Poucas equipes de software consideram cuidadosamente que os requisitos e os defeitos de projeto são a causa raiz de tanto esforço desperdiçado. Você não pode desenvolver até ter alguma ideia dos requisitos. Em outras palavras, o desenvolvimento segue os requisitos. Um requisito mal pesquisado ou mal expresso pode levar uma equipe inteira a desperdiçar dias ou semanas de trabalho. Freqüentemente, esse tipo de desperdício é considerado “aprendizado” ou “evolução dos requisitos do usuário”, quando na verdade não é nenhum dos dois, é um trabalho com requisitos abaixo do padrão. Existem vários motivos pelos quais o funcionamento dos requisitos pode ser ruim. Uma razão é que muitas organizações não conseguem garantir que a equipe que redige os requisitos seja adequadamente treinada e experiente para realizar um trabalho de requisitos de alta qualidade. Outra razão é que há pouco acordo e consistência em toda a indústria sobre o que constitui um bom requisito.
Outras causas comuns de desperdício de projetos de software
Mencionamos o trabalho anterior deficiente e a mudança de contexto como as principais causas de desperdício. Algumas outras causas comuns incluem:
- desperdício causado por má liderança,
- desperdício causado por baixos níveis de habilidade, levando ao aumento de retrabalho e bugs
- desperdício de seguir processos que parecem agregar valor, mas não o fazem,
- não seguir bons processos que agregam valor, mas talvez não estejam na moda,
- desperdício em sobrecarga de comunicação devido ao tamanho excessivo da equipe,
Os requisitos de software costumam ser de baixa qualidade
Os requisitos de software e as histórias de usuários costumam ser de baixa qualidade. Talvez o autor não seja suficientemente qualificado ou experiente. Talvez eles não tenham acesso às informações de que necessitam. O problema com quase todos os requisitos é que eles são escritos em linguagem natural sem restrições. Geralmente os autores não possuem treinamento formal sobre requisitos de qualidade de redação. A linguagem natural irrestrita não é o meio ideal de comunicar requisitos de software, mas é o que mais usamos. A maioria das organizações não gerencia a qualidade dos requisitos.
Na Scopemaster, analisamos mais de 300.000 requisitos de centenas de projetos de software em diferentes países e indústrias. O que descobrimos é que:
- Em média, um requisito (ou história de usuário) consiste em 12 palavras (excluindo os critérios de aceitação). E em média cada palavra corresponderá a 125 palavras codificadas, ou tokens sendo escritos. Assim, podemos dizer que um erro com uma única palavra de um requisito pode levar à necessidade de reescrever 125 palavras de codificação. Esses números não devem ser usados como base para estimativas, mas indicam a importância de cada palavra de um requisito.
- Em média, vemos de 4 a 8 problemas em cada requisito. Esses problemas variam em gravidade, mas, a menos que sejam corrigidos antecipadamente, cada um causará, ou provavelmente causará, um bug de software.
Defeitos de requisitos comuns incluem:
- Não orientado ao usuário
- Inconsistente
- Não está claro
- Não testável
- Não dimensionável
- Conteúdo técnico excessivo
- Duplicado
- Ausente
- Não é valioso
- Muito detalhado
A maioria dos leitores interpretará um requisito escrito de maneira diferente. Se a diferença na interpretação não for trivial, é provável que leve a um bug de software. Se esse bug não for identificado até mais tarde, muito trabalho poderá ter sido feito e precisará ser refeito para corrigi-lo. Acertar na primeira vez ou encontrar defeitos precocemente é realmente importante.
Atributos de qualidade de bons requisitos de software
Existem várias fontes e opiniões sobre o que constitui um requisito de boa qualidade. Há um ótimo trabalho do IEEE e eles revisitam regularmente este tópico. Existe uma lista de atributos comumente adotada, embora a nosso ver deficiente, que é frequentemente promovida por vários treinadores ágeis, encapsulada na pneumônica INVEST.
Aqui está nossa lista de atributos de qualidade exigidos.
A verificação de cada requisito atende bem a todos os itens acima, é um trabalho um tanto tedioso, mas necessário se você deseja minimizar o desperdício. Felizmente, ferramentas como o ScopeMaster agora podem fazer a maior parte da garantia de qualidade desses requisitos para você.
Outras formas de desperdício de projetos de software
Obrigado a Todd Sedano por sua imagem muito útil no início deste artigo, que mostra as formas comuns de desperdício de projetos de software. Abordamos os três primeiros com algum detalhe agora, pois são as principais causas do desperdício de projetos. Vejamos os outros:
Soluções desnecessariamente complexas
Dívida técnica, integrações complexas, mistura de linguagens, regras de negócios complexas e arquiteturas de software deficientes levam a soluções excessivamente complexas, que levam à perda de tempo no retrabalho, na descoberta de como os sistemas estão funcionando e na garantia de que a introdução de mudanças não causa resultados indesejados. ou seja, uma boa arquitetura leva a uma flexibilidade eficiente.
Carga cognitiva estranha
O desperdício de projetos de software às vezes é causado por distrações e restrições adicionais aos desenvolvedores e designers. Projetos bem-sucedidos protegerão os desenvolvedores, testadores e designers de qualquer coisa com a qual eles não precisem se preocupar.
Estresse psicológico
Esta causa de desperdício tende a ser menos comum ou causada por pressões externas ou, em alguns casos raros, por uma gestão muito deficiente.
Perda de conhecimento
Em ambientes de sistemas grandes ou complexos, a continuidade do pessoal ajuda a reter o conhecimento. Se os especialistas saírem, poderá levar semanas ou meses de aprendizado para alcançar o nível do pessoal que está saindo.
Multitarefa/espera
Os projetos de software desperdiçam tempo e esforço na alternância de tarefas (resultado da multitarefa). Muitas vezes, pode levar de 20 a 50 minutos para um desenvolvedor voltar ao ponto em que estava antes que uma distração interrompesse uma linha de pensamento.
Comunicação ineficaz
Em grande parte, cobrimos isso com requisitos inadequados. Mas, por vezes, outras comunicações do projeto são mal geridas, por exemplo, se os executivos não conseguem dar orientações claras sobre o que é importante para o negócio.
Evitando o Desperdício
Para evitar esse desperdício, precisamos apenas de um melhor trabalho de requisitos e de design. É tão simples? Sim.
Se você escrever requisitos melhores que se comuniquem de forma clara e consistente a todos os leitores e, em seguida, dedicar tempo suficiente para garantir que as opções de projetos sejam cuidadosamente consideradas, os projetos sejam revisados e otimizados antes da codificação, coisas boas acontecerão e o desperdício será mínimo.
Raramente há foco adequado na qualidade dos requisitos. Além disso, muitas abordagens, estruturas e tendências Ágeis estão minando formas comprovadas e eficientes de fornecer software de alta qualidade na primeira utilização. Qualidade dos requisitos e qualidade do design pode ser medidos, acompanhados e melhorados, mas raramente o são.
As equipes precisam de ajuda para resolver este problema
Escrever bons requisitos não é fácil, requer treinamento e experiência. Muitas equipes têm um proprietário de produto que é um especialista no assunto ou um bacharel experiente. Eles podem conhecer o negócio, mas não sabem redigir requisitos de boa qualidade. Aqui estão algumas razões pelas quais este problema permanece em grande parte sem solução:
1. Há pouca recompensa no trabalho por desafiar os requisitos de qualidade
2. Se o requisito for ruim e você tiver que construí-lo duas vezes, você receberá mais
3. Os autores de requisitos raramente têm conhecimento profundo das necessidades do usuário, dos sistemas existentes e de como escrever bons requisitos.
4. Freqüentemente, os autores de requisitos são os desenvolvedores que escrevem tarefas de desenvolvimento ricas em jargões, requisitos do usuário não facilmente compreensíveis e que podem ser compreendidos por todos.
5. As equipes raramente restringem a linguagem dos requisitos àquela que alcança entendimentos comuns consistentemente claros.
6. A equipe confia na discussão como forma de esclarecer mal-entendidos. As discussões muitas vezes ficam sem documentação.
7. Existe uma grande variabilidade nas opiniões sobre o que constitui requisitos de boa qualidade.
2022 e a automação/IA vem ao resgate
Estão surgindo ferramentas que podem ajudar na garantia de qualidade (QA) dos requisitos. Os fornecedores de ferramentas de gerenciamento de requisitos estão trabalhando em novos recursos para ajudar em alguns aspectos do controle de qualidade de requisitos. IBM Doors, Jama Connect, Visuresolutions e ScopeMaster são exemplos. Nossa própria ferramenta EscopoMaster é a ferramenta mais avançada disponível para resolver os problemas descritos neste artigo. Ele automatiza o controle de qualidade de requisitos no início do ciclo de vida do software. É como um analisador estático de requisitos; faz para os requisitos o que SonarQube faz para o código.
O ScopeMaster e algumas outras ferramentas usam Processamento de Linguagem Natural e outras técnicas analíticas para interpretar e testar requisitos. O ScopeMaster orienta o autor dos requisitos a melhorar a qualidade dos requisitos com velocidade e meticulosidade que até então eram impossíveis. (O ScopeMaster realizará em média 100.000 testes em um conjunto de 100 histórias de usuários em 4 minutos). O ScopeMaster normalmente encontra de 2 a 4 defeitos por requisito em apenas alguns segundos.
O ScopeMaster encontrará cerca de metade de todos os defeitos latentes em um conjunto de requisitos. Os tipos de defeito abrangem 9 dos 10 atributos de qualidade mostrados acima. Isso pode ajudar as equipes a elevar a qualidade de um conjunto de requisitos para um padrão muito mais alto muito rapidamente, ajudando a aliviar esse problema do $360Bn pa.
Conclusão
Se você estiver envolvido em projetos de software em um setor corporativo ou governamental, poderá estar desperdiçando até 50% do seu orçamento em trabalhos evitáveis. A causa raiz de grande parte desse desperdício são requisitos inadequados e trabalho de design de sistema. Reconhecer que existe um problema e que esta é a provável causa raiz é o primeiro passo para poder resolvê-lo. O próximo passo é introduzir uma iniciativa de melhoria da qualidade que aborde o início do ciclo de vida de desenvolvimento: objetivos, requisitos, arquitetura e design. Comece a medir os defeitos nos requisitos e o impacto que eles estão causando no seu progresso. Reconheça potenciais defeitos e introduza iniciativas para encontrar e corrigir esses defeitos o mais cedo possível. Ferramentas como o ScopeMaster são uma virada de jogo para a segurança do software.
Escrito por Colin Hammond, veterano de TI com 37 anos e fundador da EscopoMaster.
[eu] Fontes de defeitos Defeitos por ponto de função Defeitos de requisitos 0,75 Defeitos de arquitetura 0,15 Defeitos de design 1,00 Defeitos de código 1,25 Defeitos de documento 0,20 Defeitos de correção incorreta 0,15 Potencial total de defeito 3,65
https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf
[ii] Capers Jones e Accenture, janeiro de 2021
Economia da Qualidade de Software, por C Jones e Olivier Bonsignour.
