É possível chamar-se corretamente (ou sua equipe) de "Agile" se você não faz TDD (Test-Driven Development)?

Sim, sim, sim, um milhão de vezes sim.

Agile é uma filosofia, TDD é uma metodologia específica.

Se eu quisesse ser realmente exigente, poderia simplesmente apontar que existem algumas variações do xDD - que seus advogados explicarão em profundidade não são TDD - mas essas ainda estão substancialmente ligadas ao teste primeiro, o que seria trapaça.

Então vamos dizer o seguinte - você pode ser ágil sem fazer o desenvolvimento "test first" (veja como o scrum funciona - em nenhum lugar há detalhes sobre como você escreve código). Veja um quadro Kanban, veja todos os tipos de metodologias ágeis.

Você quer testes de unidade? Claro que sim, por todos os tipos de razões - e você pode argumentar que não pode ser ágil sem testes de unidade (embora eu suspeite que seja) - mas você não precisa escrevê-los primeiro para ágil.

E, finalmente, é igualmente verdade que você poderia fazer o Teste Primeiro sem ser argumentos ágeis e fortes para fazer o teste primeiro, independentemente da sua filosofia geral de desenvolvimento.

Parece que outros (com um representante mais SOLID) têm uma opinião semelhante ...

http://www.twitter.com/unclebobmartin/status/208621409663070208

@unclebobmartin: http://t.co/huxAP5cS Embora não seja impossível fazer o Agile sem TDD e OOD, é difícil. Sem TDD, a taxa de iteração de ...

(O link no tweet é para a resposta completa no LinkedIn)

"Ser ágil" significa simplesmente aderir aos valores e princípios do manifesto ágil . Nada nesse documento menciona TDD, ou mesmo testes de unidade para esse assunto.

Então, sim, você pode ser ágil sem fazer testes de TDD ou de unidade.

Eu não recomendaria embora ...

Sim ,

Veja um dos valores ágeis:

Indivíduos e interações sobre processos e ferramentas

Isso já deve responder. TDD é uma certa metodologia, um processo. Na verdade, um processo que poderia ser usado em processos de desenvolvimento ágil, mas nada mais. Eu acho que talvez o TDD seja o estado da arte agora ao ser ágil. Mas acho que o conceito de ágil ainda poderá durar, mesmo que o TDD tenha sido substituído por outras práticas.

Eu resumiria como:

• Hoje o TDD é um padrão padrão por ser ágil

• Pode haver maneiras de ser ágil sem TDD

eu digo

Não [tipo de]

Se você voltar à fonte original, o http://en.wikipedia.org/wiki/Extreme_Programming TDD é fundamental para o processo; os testes substituem as especificações de requisitos e os casos de uso da cascata, servem como documentação viva e exemplos de funcionamento, etc. Eles são indispensáveis.

No entanto, existem tantos sabores diferentes de 'ágil' flutuando agora que é perfeitamente possível que um deles evite o TDD

EDIT: @ A interpretação de Murph da pergunta parece ser a preferida. Caramba, eu até votei, é uma boa resposta. No entanto , mantenho minha posição de que o Manifesto Ágil é um conjunto de princípios, não uma metodologia de desenvolvimento. Não vejo utilidade em dizer "sim, sou ágil" sem realmente implementar as práticas que trazem os benefícios. Em particular:

O software de trabalho é a principal medida de progresso.

e

Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo constante indefinidamente.

Para mim, esses dois princípios implicam se não exigem TDD - pelo menos não conheço outra maneira de alcançá-los sem ele!

EDIT 2: sim, tecnicamente você pode escrever os testes depois; mas ainda considero o teste primeiro / TDD fundamental. Não porque você não pode "ser ágil" sem ele, mas porque você será mais ágil com ele. Testar primeiro / orientado a testes é uma abordagem muito mais eficiente do que testar mais tarde / testar depois. As descrições de teste são os requisitos . Não os adie até mais tarde ;-)

EDIÇÃO 3: Eu finalmente descobri o que me incomoda tanto na resposta muito bem escrita de Murph. É essa noção de que alguém pode "ser ágil" sem realmente fazê-lo . E "fazê-lo" (como mostrado acima) requer praticamente TDD.

Estritamente, você é ágil ao aderir ao manifesto ágil . Na prática, uma base de código não é ágil, a menos que tenha uma boa cobertura de teste. Você pode fazer TDD e escrever os testes antes / durante o desenvolvimento da funcionalidade ou escrever testes para a funcionalidade depois que ela for desenvolvida. Geralmente é mais fácil e mais eficaz fazê-lo da maneira TDD.

Você pode ser ágil, mas provavelmente há espaço para melhorias.

Um dos princípios do Agile é que você deve ser capaz de responder à mudança. Isso significa que você não sabe antecipadamente o que precisa construir. Se você estivesse seguindo um processo em cascata, saberia x meses com antecedência exatamente o que precisa construir e poderia projetar componentes de software individuais para que cada um participasse de um esquema maior, atingindo o produto final (pelo menos você pensaria que foi assim). Porém, como o ágil determina que você não sabe qual é o produto final, nunca sabe para que seu código será usado e, mais importante, quando será alterado.

Portanto, você precisa de um conjunto de testes completo para garantir que os recursos que você já construiu continuem funcionando conforme a base de código é modificada.

Mas isso em si não é TDD. Se você escrever os testes depois de escrever o código, não será TDD. Mas o TDD ajuda com outro aspecto, evita a superprodução.

Na minha própria equipe ágil, tenho lutado com os desenvolvedores que escrevem códigos que eles acreditam que seriam úteis mais tarde no projeto. Se tivesse sido o desenvolvimento em cascata que provavelmente seria bom, porque eles estavam adicionando suporte para algo no plano do projeto para os próximos x meses.

Mas se você estiver seguindo os princípios ágeis, não deverá escrever esse código, porque não tem idéia se isso será necessário. O recurso planejado para a próxima semana pode subitamente ser adiado indefinidamente.

Se você seguir corretamente o princípio TDD, uma única linha de código não poderá existir antes que um teste dite essa linha de código (pessoalmente, eu posso escrever um código trivial sem testar) e, se você começar escrevendo o teste de aceitação, implementará apenas exatamente o que é necessário para fornecer os recursos necessários.

Portanto, o TDD ajuda a evitar a superprodução, permitindo que a equipe seja o mais eficaz possível, o que também é um princípio ágil.

O software de trabalho é a principal medida de progresso

Você pode ser ágil sem fazer TDD (desenvolvimento orientado a teste)?

Resposta curta: Sim.

Resposta mais longa: já existem muitas respostas realmente boas para esta pergunta e muito boas referências. Não tentarei debater esses pontos.

Na minha experiência, o Agile é sobre escolher o nível certo de Lean-ness para o projeto em questão. O que quero dizer com Lean-ness? E, por que eu o incluo nesta resposta?

O Lean não significa cortar todo o possível do seu método. Como observou um de nossos colegas, você não precisa incluir TDD ou teste de unidade em seus comportamentos. No entanto, no contexto do projeto, você se encontra, pode ou não ser benéfico.

Vamos pensar na cadeia de suprimentos de um grande varejista sem nome localizado em AK. Existe o consumidor. Eles vão para a loja. A loja recebe vários produtos via caminhão. Os caminhões, presumivelmente, obtêm esses produtos de um armazém. O armazém é preenchido por remessas de vários fabricantes. Os fabricantes, por sua vez, possuem cadeias inteiras de suprimento.

O que acontece quando o gerente geral de remessa da cadeia de suprimentos acima é informado de que ele receberá um bônus anual de US $ 1 milhão por ano por ter menos de 10 caminhões na frota? Ele cortará imediatamente a frota para 9 caminhões. Nesse cenário "terrível", isso aumentará a quantidade de mercadorias armazenadas no armazém (aumentando o custo nesse nó). E vai "morrer de fome" nas fachadas das lojas.

Portanto, a cadeia de suprimentos geral sofre se a otimização local for permitida sem considerar o todo.

Voltar para TDD e UT. TDD é um mecanismo de expressão de requisitos. O sistema DEVE executar essas restrições. Justo. O TDD pode substituir o comportamento dos requisitos do Use Case Drive Development ou o comportamento dos requisitos do User Story Driven Development. Ele tem o benefício "inclinado" de combinar as cargas de trabalho de teste de unidade e requisitos. É um benefício se a carga de trabalho geral for reduzida. Não é, se a carga de trabalho geral da cadeia de suprimentos for aumentada (vamos corrigir a qualidade).

E então, você perguntou: Você pode ser ágil sem fazer TDD (desenvolvimento orientado a testes)?

Certamente você pode. Uma pergunta diferente, e talvez melhor, é: - Se eu aplicar o TDD a este projeto, isso resultará em uma entrega global mais eficiente de software ou menos eficiente?

Para citar um autor favorito ... JRR Tolkien

Senhor dos Anéis. Irmandade dos Anéis. Pág. 94 'E também é dito', respondeu Frodo: 'Não peça conselho aos elfos, pois ambos não e sim'.

Então, no final, ... depende. Você deve responder a pergunta. Qual caminho o levará com mais eficiência aos seus objetivos desejados.

Para TDD ou não para TDD. Essa permanece a questão. :-)

PS - Também estou publicando esta resposta em outro site. https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/?maxresults=15&sortby=4&lang=pt

Comparando com a engenharia de um castelo.

Castelo ágil

Se você fosse projetar um castelo usando o Agile. Você escreveria partes com funções específicas e incentivaria o usuário a usar as partes funcionais, ajustando o design futuro às reações do usuário. Então, você constrói a masmorra e se comunica com o guardião da masmorra, testando a base fornecida pela terra e pela masmorra. Você construía os parapeitos e perguntava aos vigias noturnos se é bom. Você construiria os muros e os soldados testariam o valor defensivo. Você construía a cozinha e os cozinheiros examinavam. E durante esse processo, todas as partes até o momento funcionariam além da estrutura atual. Então, quando você terminasse a masmorra, poderia mover os prisioneiros. E assim por diante. Mas quando você finalmente termina o castelo, descobre que os prisioneiros escaparam.

Castelo TDD

Com o TDD, você aparece com os prisioneiros e vê se eles escapam. Então você escreve as celas da prisão até que elas não possam escapar. Em seguida, refatoraria o código removendo células desnecessárias de maneira limpa e removendo barras que estão no local errado e testando novamente. Os prisioneiros não escaparam. Você não precisa se comunicar com o carcereiro. E você pode entregar o castelo inteiro assim que terminar tudo. Nesse ponto, o carcereiro diz que a masmorra precisa de mais células, e agora você precisa desenterrar mais da fundação.

Castelo TDD ágil

Se você combinar Agile e TDD. Você veria se os prisioneiros escapavam e perguntaria ao carcereiro o que era necessário. Ele diz que você precisa de mais células. Você pegaria algumas pessoas aleatórias para fingir ser prisioneiro e ver se elas escapavam. Se não, então você mostra ao carcereiro, e ele fica feliz com isso. Então você começa a construir os parapeitos.

Conclusão

Então, ambos resolvem problemas diferentes. O Agile ajuda na mudança de requisitos, com base na descoberta das necessidades dos usuários, à medida que eles veem o produto se desenvolver no ponto do processo em que é mais fácil se adaptar. Envolve liberar adições estáveis, separadas do design geral.

TDD resolve o problema de antecipar falha. Descobrir e corrigir falhas, como ocorre em um ponto do processo em que é mais fácil de corrigir. Isso envolve o teste de unidades de código dissociadas estáveis, separadas do design geral.

É fácil ver o TDD como uma extensão do Agile, porque ambos seguem o mesmo padrão, progresso e revisão orientados pela unidade. A diferença é que as unidades no Agile funcionam externamente até o momento como um todo, enquanto as unidades no TDD funcionam como parte e podem não produzir um produto funcional para revisão externa. E ambos os processos governam diferentes necessidades (usabilidade versus correção). Como ambos funcionam sobre um processo de desenvolvimento em unidades, os dois processos de revisão podem ocorrer em pontos semelhantes, com o TDD sendo dividido de maneira mais precisa.

Notas

• Só ter testes de unidade não significa que você use TDD. TDD significa fazer o teste antes da unidade produzida e usá-lo à medida que você desenvolve para confirmar a unidade. O teste de unidade sem TDD pode ser usado para garantir que você não invalide a funcionalidade criada anteriormente.
• Ter sprints e outras reuniões não o torna ágil. Os objetivos do manifesto tornam você ágil. Você pode dividir as metas em cascata em sprints com unidades de trabalho, sem cumprir o compromisso de favorecer as pessoas sobre os processos.
• Por definição de TDD e Agile. Seus testes de unidade controlarão unidades não entregues e, portanto, o TDD fará um ciclo mais rápido que o Agile. E se você empregar ambos, seus ciclos ágeis conterão um ou mais ciclos TDD (se todas as unidades forem testadas).
• Pelo que entendi: Você falha no Agile ao não desenvolver uma unidade de entrega / significativa para o usuário. A unidade pode ser significativa mesmo que acelere o produto. Mas como o Agile explica a refatoração para facilitar a manutenção? Eu não cobri o suficiente para responder a isso.
• Você falha no TDD ao falhar no teste de unidade. Produzindo código que não produz o recurso corretamente.

O Agile o força a lidar e reduzir os riscos de cronograma e qualidade a cada iteração. ou seja, o TDD não é necessário para ser considerado ágil .

No entanto, o TDD é uma tremenda técnica para mitigar riscos de qualidade, especialmente para um projeto com um grande número de iterações ou pessoas. Nesse projeto, o TDD adicionará algum risco de agendamento nas iterações iniciais, porque você também precisa escrever casos de teste. No entanto, o TDD gera enormes economias de custos em iterações posteriores, pois mitiga continuamente os riscos de qualidade. isto é, TDD é recomendado.