Testado versus requisitos de negócios em constante mudança

Um dos novos requisitos da nossa equipe de desenvolvimento definida pelo CTO / CIO é tornar-se um desenvolvimento orientado a testes, no entanto, acho que o restante dos negócios não ajudará porque eles não têm noção do ciclo de vida do desenvolvimento e os requisitos são atendidos. mudou o tempo todo em um único sprint. O que me deixa frustrado por perder tempo escrevendo 10 casos de teste e se tornará inútil amanhã.

Sugerimos a criação de processos para evitar essas mudanças de requisitos e educar os negócios sobre os ciclos de vida do desenvolvimento. E se a empresa não conseguir entender a idéia? O que você faria?

Sua pergunta parece sugerir que o TDD está vinculado aos ciclos de vida de desenvolvimento. Não tenho certeza se concordo.

A resposta para requisitos flexíveis e variáveis ​​é o desenvolvimento iterativo. O TDD não tem nada a dizer sobre isso ou sobre programações de software; é uma ferramenta para desenvolver software dentro dos requisitos e cronograma que você possui. Se os requisitos mudarem, o software também mudará. Isso vale para os testes de unidade também.

O TDD não desenvolve requisitos, embora alguns proponentes sugiram que sim. Em vez disso, os requisitos conduzem os testes de unidades, que, por sua vez, controlam o código que está escrito. Você não desenvolve uma arquitetura a partir de testes, nem desenvolve requisitos com testes. Em vez disso, os testes são um resultado da arquitetura e dos requisitos designados.

Se os requisitos estão mudando no nível atômico (método / teste de unidade) de desenvolvimento de software, sugiro que seus requisitos sejam muito granulares. Os requisitos devem especificar o que o software faz, não como ele faz. Como o software atende aos requisitos é de domínio e responsabilidade dos desenvolvedores de software, não das principais partes interessadas.

Em outras palavras, não digo ao cliente ou proprietário da empresa como administrar sua empresa e ele não me diz como criar minhas aulas.

Mudar requisitos é algo normal, mas quando eles mudam diariamente e mudam os requisitos no meio de um sprint, esse não é um ambiente propício ao desenvolvimento de software de maneira significativa e qualitativa. Em outras palavras, o TDD é o menor dos seus problemas aqui, eles são mais fundamentais.

Você menciona sprints, o que significa que você está executando algum tipo de desenvolvimento Agile, o que é uma coisa boa. Lidar com o desenvolvimento em breves sprints rápidos funciona bem em projetos para quando as prioridades e os requisitos são voláteis e podem mudar no meio do projeto. O problema sério é que você tem requisitos que mudam drasticamente em suas equipes de desenvolvimento e teste no meio de um sprint.

As prioridades do sprint não devem mudar após o início do sprint. O sprint deve ser um acordo entre as partes interessadas e a equipe de desenvolvimento de que os seguintes recursos e histórias de usuários acordados serão entregues e testados em uma data específica. As partes interessadas não confirmam o final do contrato quando começam a mudar suas expectativas para o sprint após o início do desenvolvimento.

Portanto, as partes interessadas não estavam sendo cuidadosas ou atenciosas com o que estavam pedindo, para que mudassem suas expectativas imediatamente. Os desenvolvedores têm o luxo de adiar a data de entrega dos recursos? Freqüentemente não. Na melhor das hipóteses, as partes interessadas estavam sendo negligentes ou incompetentes e os desenvolvedores pagam o preço em horas extras para cumprir a data de qualquer maneira. Às vezes, até as partes interessadas fazem isso de propósito, sabendo que podem obter mais trabalho de seus desenvolvedores assalariados.

O que deveria acontecer honestamente quando os requisitos principais mudam para o ponto em que o trabalho atual para o sprint seria inútil é interromper imediatamente o desenvolvimento do sprint até que um novo sprint possa ser planejado com base nos novos requisitos. Certamente, não há razão para continuar na próxima semana e meia desenvolvendo software que a empresa já lhe disse que não seria de todo útil para eles.

O que realmente está acontecendo é que as partes interessadas do negócio estão falhando com a equipe de desenvolvimento por não manter ou cumprir o compromisso do sprint. Eles demonstram completa falta de competência na determinação do que desejam em software ou têm total falta de respeito pela equipe de desenvolvimento e como o software de qualidade é produzido.

A única maneira de grupos de negócios como esse ganharem respeito por como o desenvolvimento de software realmente funciona é contratar uma empresa de consultoria externa ou fornecedor de software para desenvolver software para eles e pagar por sprint. Uma vez que eles perdem dinheiro com alguns sprints de desenvolvimento que não podem usar, eles começarão a apreciar o quanto é importante manter seu compromisso como partes interessadas e ser muito cuidadoso e específico com seus recursos e requisitos.

Sem entrar em uma terminologia ágil específica, parece que o problema fundamental é a falta de entendimento e / ou compromisso com a responsabilidade do cliente durante uma iteração: uma vez que o conjunto de itens implementáveis ​​é escolhido (pelo cliente, acordado pelos desenvolvedores) para um iteração, o cliente concorda em não mudar de idéia até o final da iteração.

Isso fornece aos desenvolvedores um alvo fixo por um curto período de tempo.

Se os requisitos são tão instáveis ​​que não podem sobreviver um dia sozinhos, o projeto apresenta problemas muito além da metodologia ... Nesse caso, volte para os objetivos do projeto e reconsidere os recursos propostos.

Não acho que o restante dos negócios ajude, porque eles não têm noção do ciclo de vida do desenvolvimento e os requisitos são alterados o tempo todo em um único sprint.

Uma coisa que os negócios geralmente ouvem é qualquer coisa que tenha impacto no orçamento. Se os requisitos em constante mudança estão sendo feitos frivolamente, convém criar um argumento com exemplos detalhados para mostrar como essa mudança afeta a eficiência da equipe, cria trabalho sobreposto e custa o dinheiro da empresa. Se, por outro lado, as alterações forem necessárias e puderem resultar em uma perda para a empresa, se não for feito, você poderá simplesmente usá-lo e encontrar uma maneira de lidar com os requisitos em constante mudança.

Minha experiência, no entanto, é que, quando as coisas estão mudando a uma taxa tão alta como você sugeriu, pode ser pelos seguintes motivos:

• O conceito é experimental; nesse caso, você pode querer aplicar todas essas alterações em vez de implementá-las diretamente no código de produção.
• O conceito não foi completamente analisado, o que sugere que o produto não foi realmente pensado e o requisito é codificá-lo enquanto estiver sendo pensado.
• Mercado constante e pressões competitivas resultam em mudanças bruscas
• Um relacionamento ruim entre os motivadores do projeto, os gerentes e a equipe de implementação, em termos da capacidade de todas as partes interessadas se comunicarem livremente sobre a necessidade de mudança.
• Priorização deficiente de tarefas, e isso pode ser uma falha da equipe de gerenciamento e implementação.

Às vezes, os proprietários do projeto não sabem realmente como o produto deve funcionar, porque eles têm um conceito básico em mente, mas sentem que precisam ver como ele funciona primeiro antes de se decidirem. Isso pode ocorrer porque o domínio do problema não é muito bem compreendido ou porque eles realmente não pensaram sobre como uma função comercial se traduzirá em uma solução baseada em software. A prototipagem pode ser benéfica nesses casos. Você pode criar protótipos de GUIs facilmente com objetos simulados se as alterações forem cosméticas ou usar testes de unidade como um meio para testar e ajustar as alterações algorítmicas. A chave, porém, é garantir que as mudanças sejam aplicadas da forma mais sistemática possível, a fim de manter o processo relativamente enxuto e menos dispendioso.

Sugerimos a criação de processos para evitar essas mudanças de requisitos e educar os negócios sobre os ciclos de vida do desenvolvimento.

Este é um bom começo e permite que você se envolva com a gerência para tentar obter resultados positivos de uma maneira medida e estruturada. A educação é o método mais eficaz para lidar com problemas em que os desenvolvedores e o gerenciamento estão fora de sincronia ideológica. No entanto, para obter o maior benefício, a educação precisa ser de mão dupla, assim como a comunicação. Você precisa ensinar a si mesmo e à gerência a comunicar suas necessidades e ajudar-se mutuamente a entender as motivações que direcionam essas necessidades. Dizer que é "muito difícil" ou "muito trabalho" ou "uma perda de tempo" só parecerá reclamar e ser "preguiçoso". Seu raciocínio precisa ser claro, e em um idioma que mostrará que você está trabalhando para alcançar resultados positivos para a empresa e o produto em que está trabalhando, e que seus motivos estão com esses melhores interesses em mente. Da mesma forma, talvez você precise aprender a aceitar os motivos que os fatos lhe dão, por que eles sentem a necessidade de mudar as coisas tão rapidamente. Talvez entre vocês consiga encontrar um bom meio termo viável quando os dois lados conseguirem entender o ponto de vista um do outro.

E se a empresa não conseguir entender a idéia? O que você faria?

Se você não alcançar o resultado esperado, talvez o momento não esteja certo. Talvez seus argumentos precisem ser feitos de maneira diferente. Talvez você tenha entendido tudo errado e precise aprender mais sobre o que o outro lado está pensando. Por fim, se sua abordagem específica falhar, você decide como é importante lidar com isso. No entanto, em vez de se preocupar com o que pode ou não acontecer, pense positivamente e simplesmente decida o que você pode fazer hoje. Os problemas de amanhã não são necessariamente garantidos e não valem o estresse de se preocupar até que realmente ocorram.

Um último ponto a considerar. Seu CTO está possivelmente preocupado com muitos dos mesmos problemas que você. Certamente, ter um decreto para adotar o TDD me sugere que esse pode ser o caso, já que o TDD é altamente eficaz em situações em que o código geralmente está sujeito a alterações. Em um cenário de primeiro teste, os testes não se tornam inúteis no dia seguinte, porque fornecem uma rede de segurança para você trabalhar, permitindo aplicar alterações com rapidez e confiança. No entanto, você ainda precisará encontrar uma maneira de gerenciar as expectativas das pessoas que solicitam alterações, a fim de ajudar a gerenciar as alterações com eficiência.

Para tornar mais claro, um requisito exige que o site possa fazer upload de uma imagem e redimensionar para menos de 500 kb se o tamanho real for superior a 500 kb.

A alteração de requisitos pode ser que esse recurso não seja necessário (na maioria das vezes é após eles o terem visto, eles perceberam que realmente não precisam dele)

Sugerimos a criação de processos para evitar essas mudanças de requisitos e educar os negócios sobre os ciclos de vida do desenvolvimento. E se a empresa não conseguir entender a idéia?

Primeiro, parece que você precisará fazer mais protótipos fictícios. Ou seja, maquetes clicáveis ​​e funcionais, que não armazenam ou recuperam dados reais, mas simulam como seria o software. Portanto, para aplicativos da web, isso significaria HTML / CSS / JavaScript completo, que permite ao usuário clicar no software, mesmo que você tenha muito pouco código feito. Talvez isso possa ajudar os usuários a ver o que eles estão pedindo antes de investir o trabalho na codificação.

Em seguida, não cabe ao departamento de TI decidir como o negócio funciona. E pode ser que os negócios valorizem a agilidade acima da confiabilidade para suas necessidades de software. Portanto, mudar alguma coisa HOJE é mais valioso do que garantir que um determinado recurso funcione 100% do tempo, em oposição a 95,5% do tempo. Somente a própria empresa pode decidir isso. A menos que seu departamento seja criticado por questões de qualidade, talvez você deva considerar que a empresa está totalmente bem com os requisitos de mudança e o código não orientado a testes. Seu CTO / CIO diz que deseja que você seja "orientado a testes", mas se os requisitos de negócios são rotineiramente "faça essa alteração às 16h", você simplesmente não poderá ter os dois.