Agile vs Waterfall

[Maurício Linhares]

http://br.youtube.com/watch?v=gDDO3ob-4ZY

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

[Guilherme Germoglio]

Food for thought: Será que isso funciona para o desenvolvimento de um sistema de controle de tráfego aéreo?

--
Guilherme

msn: guiger...@hotmail.com
homepage: http://germoglio.googlepages.com

[Maurício Linhares]

Por que não?

As maiores vantagens do desenvolvimento ágil se apresentam exatamente
quando você está escrevendo sistemas de alta criticidade, como a
facilidade de se pegar uma regressão graças a uma massa de testes dos
vários tipos.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

2008/11/10 Guilherme Germoglio <germ...@gmail.com>:

[Guilherme Germoglio]

Pergunta por informação (ou seja, pergunta não retórica): algum daqui já leu sobre/participou de desenvolvimento ágil em sistemas de alta criticidade?

Eu não procurei, é verdade, mas toda informação que eu já li sobre desenvolvimento grandes sistemas (controle de tráfego aéreo, sistemas de controle de armamento de navios de guerra, simuladores de vôo, etc.) não envolve qualquer tipo de agilidade. Normalmente não são bem waterfall, uma vez que há algum grau de iteração entre fases de desenvolvimento, mas também não são nada ágeis (há um trabalho da peste em projetar o sistema antes de codificar). O exemplo que me lembro agora é o da Praxis, com seu processo peso-pesadíssimo - eles usam até métodos formais! ( http://www.spectrum.ieee.org/sep05/1454 ). 

Minha experiência, que não é lá essas coisas, me sugere que métodos ágeis funcionam sim, mas, em algum momento quando o time cresce demais (que algumas vezes é necessário), a comunicação e a integridade conceitual ruem justamente pela forma que se tentam manter isso íntegro.

--
Guilherme

msn: guiger...@hotmail.com
homepage: http://germoglio.googlepages.com

2008/11/10 Maurício Linhares <mauricio...@gmail.com>

[Maurício Linhares]

Eu, pessoalmente, nunca tive a oportunidade de trabalhar num sistema
assim mas acho que "agilidade de caixinha" dificilmente poderia ser
aplicada, mas diversas práticas, especialmente nas relacionadas a
testes poderiam ser aplicadas pra ajudar no desenvolvimento.

Eu acho que a idéia em si de se preocupar demais com o projeto
inicial, procurando planejar tudo antes de começar, é mais um sinal de
que as pessoas tem medo da mudança e querem evitá-la do que uma
necessidade real. Eles sabem que o projeto vai ser levado sem testes
automatizados e que falhas são catastróficas, então em vez de tentar
montar um porto seguro evitando regressões com uma suíte de testes,
preferem confiar em não mudar nada que funcione. Afinal, em time que
está ganhando, não se mexe :)

Sobre os problemas de comunicação, o waterfall também não vai
enfrentar os mesmos problemas?

Mesmo que o design saia da cabeça de alguns poucos projetistas, os
executores sempre vão dar o seu "toque" no que for produzido. De
qualquer forma, o design interno dos componentes que formam o sistema
não deveria ser importante, cada equipe deveria ser responsável por
sua parte, o modo como eles expõem essa funcionalidade pros outros
componentes é que tem que ser homogeneizada, pra que todas as
interfaces públicas tenham um mesmo "feeling". Acho que todo bom
projeto de software "grande" segue o mesmo caminho de módulos
independentes que se comunicam através de "boundaries" bem definidas,
que é simplesmente levar a mesma prática que nós aplicanos nos módulos
de código fonte a níveis mais altos do sistema.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

2008/11/10 Guilherme Germoglio <germ...@gmail.com>:

[Tiago Torres]

Concordo com o Guilherme... mas acredito que algumas praticas da metologia agil possam ser usadas nesses projetos e serão bem vindas... como a propria daily meeting.

Usar uma metodologia agil "pura" nesses grandes projetos de alto criticidade... acredito que não é uma boa, apesar dessas equipes possuírem uma maturidade grande na maioria das vezes...

Um dos pontos que destoaria seria a documentação que nesses tipos de projetos devem ser extensas e de extrema importância...

Essa semana fui para um congresso de gestão de projetos aqui em Recife e um gerente de projetos do UOL que usa SCRUM em quases todos os projetos do UOL falou que a equipe guarda os "post-its" como documentação!! putz... imagina ter que procurar a atividade 128 da SPRINT 35... ahahahaha (brincadeira)

IMAGINA ISSO NUM CONTROLADOR DE VÔOS!! rs...

Abraço,
Tiago Torres
Recife-PE

2008/11/10 Guilherme Germoglio <germ...@gmail.com>

--
Abraço,
----------------------------------------------------------
Tiago Torres
81.88056594
tiago...@gmail.com
tiag...@hotmail.com

"O certo não é priorizar o que está em sua agenda, mas agendar suas prioridades"
John David Wright

[Maurício Linhares]

2008/11/10 Tiago Torres <tiago...@gmail.com>:

>
> Um dos pontos que destoaria seria a documentação que nesses tipos de
> projetos devem ser extensas e de extrema importância...

Não se esqueça que o problema da documentação não é o tamanho, é a utilidade :)

Se a documentação é de valor pro cliente, seja ela muita ou pouca,
deve ser produzida. A questão é que você não deveria gerar documentos
que ninguém vai se interessar em ler ou que vão estar obsoletos em
alguns instantes.

[Tiago Torres]

Exatamente, toquei nesse assunto da  consulta dos "post-its" porque num proximo projeto que a equipe vai precisar estimar, consequentemente consultar um banco de dados de lições aprendidas... uma documentação "util" e bem "organizada" é de extrema importancia.

Por falar nisso vocês conhecem algum "sistema" eficiente para trabalhar com um banco de dados de lições aprendidas de um projeto?

Abraço,
Tiago Torres

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

[Maurício Linhares]

Wiki :)

Tem gente que também gosta de usar fóruns internos.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

2008/11/11 Tiago Torres <tiago...@gmail.com>:

[Guilherme Germoglio]

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

Eu, pessoalmente, nunca tive a oportunidade de trabalhar num sistema
assim mas acho que "agilidade de caixinha" dificilmente poderia ser
aplicada, mas diversas práticas, especialmente nas relacionadas a
testes poderiam ser aplicadas pra ajudar no desenvolvimento.

Estamos falando de extremos (de um lado waterfall e do outro agile) que contêm práticas úteis e que devem ser aproveitadas.
 

Eu acho que a idéia em si de se preocupar demais com o projeto
inicial, procurando planejar tudo antes de começar, é mais um sinal de
que as pessoas tem medo da mudança e querem evitá-la do que uma
necessidade real. Eles sabem que o projeto vai ser levado sem testes
automatizados e que falhas são catastróficas, então em vez de tentar
montar um porto seguro evitando regressões com uma suíte de testes,
preferem confiar em não mudar nada que funcione. Afinal, em time que
está ganhando, não se mexe :)

Sobre os problemas de comunicação, o waterfall também não vai
enfrentar os mesmos problemas?

Sim, tem. O que estou dizendo é que a abordagem para comunicação no waterfall é diferente do ágil e (**talvez**) funcione melhor em maiores times, uma vez que não se espera todos se comuniquem com todos.
 

Mesmo que o design saia da cabeça de alguns poucos projetistas, os
executores sempre vão dar o seu "toque" no que for produzido. De
qualquer forma, o design interno dos componentes que formam o sistema
não deveria ser importante, cada equipe deveria ser responsável por
sua parte, o modo como eles expõem essa funcionalidade pros outros
componentes é que tem que ser homogeneizada, pra que todas as
interfaces públicas tenham um mesmo "feeling".

Isso é bem utópico, mas algumas restrições e sugestões dos poucos projetistas podem/devem afetar o design interno dos componentes. Além disso, a medida de quanto o(s) projetista(s) vai(vão) engessar as decisões do design interno vai ser muito dependente de quanto ele(s) confia(m) na equipe em questão (ou dependente da capacidade dessa equipe).
 

Acho que todo bom
projeto de software "grande" segue o mesmo caminho de módulos
independentes que se comunicam através de "boundaries" bem definidas,
que é simplesmente levar a mesma prática que nós aplicanos nos módulos
de código fonte a níveis mais altos do sistema.

 

Sim, mas bem definir esses limites não é uma tarefa trivial. Além disso, a integração entre esses módulos pode ser a peste, dependendo do nível "independência" entre os times de desenvolvimento.
 

[Rodrigo Rebouças de Almeida]

Opa Mauricio!

    Agile para sistemas críticos? Que conversa é essa? Você está bem? hehe

    Só precisamos ser ágeis quando não conhecemos o futuro... Não sabemos quais são as próximas funcionalidades a serem implementadas. O ideal para desenvolvermos software é termos todos os requisitos nas mãos, prazos definidos, custo definido. Esse é o cenário "nirvana" para se gerenciar um projeto e um processo de desenvolvimento.
    Agile existe para a maioria dos contextos onde essas três coisas não são claras: quando escopo muda, prazo muda, custo muda. Daí voce precisa se adaptar rapidamente.

   Para controlar um avião, preciso conhecer em detalhes tudo o que está envolvido. Não posso estar mudando requisitos. Tenho que formalizar tudo, testar formalmente o modelo do sistema antes mesmo de pensar em escrever uma linha de código. Não consigo ver a menor hipótese prática de ser ágil desenvolvendo software crítico.

Abraço,

Rodrigo

2008/11/10 Maurício Linhares <mauricio...@gmail.com>

--
Rodrigo Rebouças de Almeida
http://rodrigor.com - rodr...@rodrigor.com - +55 83 8780 1552
______________________________________________________
Já ajudou alguém hoje? http://www.meninosdarede.org.br

[Alan Kelon Oliveira de Moraes]

Olá,

Err... Desde quando processos iterativos e incrementais tornaram-se sinônimos de processos ágeis? Quando foi que boas práticas de testes tornaram-se exclusivas das "metodologias" ágeis? Penso estarmos confundo alguns conceitos, por exemplo, iterativo e incremental com evolucionário.

Veja o artigo Iterative and Incremental Development: A Brief History para uma introdução decente ao tema. Um bom livro sobre é Agile-Iterative-Development-Managers-Software, também de Larman (http://www.amazon.com/Agile-Iterative-Development-Managers-Software/dp/0131111558). Há vários outros papers na minha página: http://www.di.ufpb.br/~alan/es/20082/

Abraços,

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

--
Alan Kelon Oliveira de Moraes
"Vem, vamos embora, que esperar não é saber. Quem sabe faz a hora, não espera acontecer." (Geraldo Vandré)

[CMilfont]

Quais as boas práticas de testes que eram executadas antes do surgimento das metodologias ágeis?

2008/11/11 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>

--
http://www.milfont.org

[CMilfont]

Depende e muito Rodrigo, por incríviel que pareça a influência do Beck para o TDD surgiu desse ramo chamado de "crítico" como o controle de um avião [que na verdade é um conjunto de softwares, cada dispositivos tem até sistema operacional próprio]. 

Eles não usam Waterfall nisso, na verdade a prática de testes surgiu fortemente nessa área, primeiro eles criam uma base considerável de testes [pelo menos o planejamento] e depois saem criando o código para passar nesses testes, claro que não é no esqueminha RED-GREEN-RED popularizado, mas isso influenciou demais o TDD.

Construir sistemas críticos está mais ligado a modelos "ágeis" do que a UPs ou Waterfall [que na verdade o paper que o descreveu já alertava para os riscos e o considerava anti-pattern]

O problema é que esse termo de agile está deturpado hoje, seria melhor chamarmos de "better" :)

Ainda há um enorme preconceito sobre o que é agile, como falta de documentação [mito], não planejamento [mito], apenas para sistemas mutáveis [que sistema não é mutável ao longo de seu ciclo de vida], que equipes grandes [o que é grande?] perde-se a comunicação [logo na era da facilidade das comunicações], que sistemas grandes precisam de metodologias burocráticas [mito], etc a dar a pau.

A construção de um controle de mísseis por exemplo precisam de uma bateria de testes gigantesco [as vezes sim de modelo formal] e por isso os mísseis construídos no Brasil apresentavam um erro de cálculo por volta de 400km [não queira estar a menos de mil km numa possível guerra no Brasil por causa do fogo amigo :)] porque o pessoal daqui não testava nada, só na prática [informações de um amigo que trabalhou no projeto].

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>

--
http://www.milfont.org

[CMilfont]

Seus testes são a melhor documentação possível e ainda executam e comprovam se estão corretos.

Mas nada impede que você escreva uma pilha de papéis do jeito que gosta com logomarca bonita da empresa.

2008/11/11 Tiago Torres <tiago...@gmail.com>

--
http://www.milfont.org

[Maurício Linhares]

Ninguém disse que é exclusivo, mas processos ágeis tem isso como
práticas bem definidas, em RUP por exemplo TDD não é uma prática
definida.

Você pode fazer TDD com RUP?

Pode.

Os manuais de RUP incitam você a fazer isso?

Não.

Eu acho que a grande diferença dos processos ágeis (tirando Scrum,
claro) é exatamente o foco em práticas pra se chegar a um resultado
final e não no resultado final em si, que normalmente é o foco dos
outros processos.

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

2008/11/11 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>:

[Rodrigo Rebouças de Almeida]

Opa! vamos lá...

2008/11/11 CMilfont <cmil...@gmail.com>

Depende e muito Rodrigo, por incríviel que pareça a influência do Beck para o TDD surgiu desse ramo chamado de "crítico" como o controle de um avião [que na verdade é um conjunto de softwares, cada dispositivos tem até sistema operacional próprio]. 

Eles não usam Waterfall nisso,

Não digo que eles usam Waterfall. Digo que não usam processos ágeis. A agilidade de um processo está ligada à capacidade do processo suportar muitas mudanças, com alta freqüência. Não é o caso deste tipo de sistema.
 

na verdade a prática de testes surgiu fortemente nessa área, primeiro eles criam uma base considerável de testes [pelo menos o planejamento] e depois saem criando o código para passar nesses testes, claro que não é no esqueminha RED-GREEN-RED popularizado, mas isso influenciou demais o TDD.

Concordo que influenciou, mas não significa que o fato de processos ágeis serem test-driven ou até "orientados a testes" sejam adequados para sistemas críticos.
 

(...)

Ainda há um enorme preconceito sobre o que é agile, como falta de documentação [mito], não planejamento [mito], apenas para sistemas mutáveis [que sistema não é mutável ao longo de seu ciclo de vida],

Sobre a tese de "mudabilidade" do sistema, ou mudança freqüente de requisitos, há sistemas onde os requisitos mudam muito, com muita freqüência, e sistemas onde os requisitos mudam pouco e com pouca freqüência. O primeiro caso exige um processo apto a absorver mudanças sem "traumas" o segundo admite um processo onde temos mais artifícios para planejar e estimar. Todo sistema muda. Alguns mudam muito e outros pouco, para isso temos processos ágeis e processos não-ágeis.

 

que equipes grandes [o que é grande?] perde-se a comunicação [logo na era da facilidade das comunicações], que sistemas grandes precisam de metodologias burocráticas [mito], etc a dar a pau.

Uma equipe espalhada pelo país, onde os requisitos são levantados em Brasília, a análise é feita em Curitiba e o desenvolvimento é feito em João Pessoa não pode estar regida por um processo onde um grupo de pessoas está trabalhando no mesmo ambiente. Para o primeiro caso precisamos de documentação para viabilizar a comunicação entre as equipes, no segundo caso não precisamos.

Simples assim. Há contextos e contextos. Uns onde mudanças são bem vindas e necessárias e outros onde mudanças não são bem vindas e são desnecessárias. (Atenção, falo de muitas mudanças, mudança de rota de projeto, etc. etc. Mudança sempre vai existir.)
 

A construção de um controle de mísseis por exemplo precisam de uma bateria de testes gigantesco [as vezes sim de modelo formal] e por isso os mísseis construídos no Brasil apresentavam um erro de cálculo por volta de 400km [não queira estar a menos de mil km numa possível guerra no Brasil por causa do fogo amigo :)] porque o pessoal daqui não testava nada, só na prática [informações de um amigo que trabalhou no projeto].

Não sei se entendi direito a mensagem deste parágrafo... Os mísseis tinham erro de cálculo por que havia muitos testes?

O fato do pessoal não executar os testes certamente não era por conta do seu volume. Até por que, principalmente no caso da construção de mísseis, volume e qualidade de testes é o mínimo que se espera no processo de desenvolvimento.

Rodrigo

[CMilfont]

Respostas abaixo:

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>

Opa! vamos lá...

2008/11/11 CMilfont <cmil...@gmail.com>

Depende e muito Rodrigo, por incríviel que pareça a influência do Beck para o TDD surgiu desse ramo chamado de "crítico" como o controle de um avião [que na verdade é um conjunto de softwares, cada dispositivos tem até sistema operacional próprio]. 

Eles não usam Waterfall nisso,

Não digo que eles usam Waterfall. Digo que não usam processos ágeis. A agilidade de um processo está ligada à capacidade do processo suportar muitas mudanças, com alta freqüência. Não é o caso deste tipo de sistema.

Agilidade não é isso, isso é um dos benefícios ganhos.
 

 

na verdade a prática de testes surgiu fortemente nessa área, primeiro eles criam uma base considerável de testes [pelo menos o planejamento] e depois saem criando o código para passar nesses testes, claro que não é no esqueminha RED-GREEN-RED popularizado, mas isso influenciou demais o TDD.

Concordo que influenciou, mas não significa que o fato de processos ágeis serem test-driven ou até "orientados a testes" sejam adequados para sistemas críticos.

Sistemas críticos são orientados a testes por natureza, já viu a construção de asas de avião?  Todo o sistema de testes é desenhado antes do desenho da propria asa :)
 

 

(...)

Ainda há um enorme preconceito sobre o que é agile, como falta de documentação [mito], não planejamento [mito], apenas para sistemas mutáveis [que sistema não é mutável ao longo de seu ciclo de vida],

Sobre a tese de "mudabilidade" do sistema, ou mudança freqüente de requisitos, há sistemas onde os requisitos mudam muito, com muita freqüência, e sistemas onde os requisitos mudam pouco e com pouca freqüência. O primeiro caso exige um processo apto a absorver mudanças sem "traumas" o segundo admite um processo onde temos mais artifícios para planejar e estimar. Todo sistema muda. Alguns mudam muito e outros pouco, para isso temos processos ágeis e processos não-ágeis.

os processos conhecidos como não-agil não conseguem absorver mudança alguma, isso vai de encontro com a propria natureza do processo.
 

 

que equipes grandes [o que é grande?] perde-se a comunicação [logo na era da facilidade das comunicações], que sistemas grandes precisam de metodologias burocráticas [mito], etc a dar a pau.

Uma equipe espalhada pelo país, onde os requisitos são levantados em Brasília, a análise é feita em Curitiba e o desenvolvimento é feito em João Pessoa não pode estar regida por um processo onde um grupo de pessoas está trabalhando no mesmo ambiente. Para o primeiro caso precisamos de documentação para viabilizar a comunicação entre as equipes, no segundo caso não precisamos.

Simples assim. Há contextos e contextos. Uns onde mudanças são bem vindas e necessárias e outros onde mudanças não são bem vindas e são desnecessárias. (Atenção, falo de muitas mudanças, mudança de rota de projeto, etc. etc. Mudança sempre vai existir.)

Comunicação [ou qualquer outro princípio ou valor] não depende de estar trabalhando no mesmo ambiente, tudo bem que práticas como Sit together dão resultados melhores, mas comunicação não existe apenas pela fala. Outra coisa é que agiles não dizem para voce não fazer documentos, apenas os documentos necessários. Se voce precisa de um documento para comunicação, tanto faz se é um wiki, um UML, uma foto do quadro ou um guardanapo escaneado, o importante é o que o documento representa. É um mito dizer que agile não tem documentação. Ainda prefiro RSpec a UML.

 

 

A construção de um controle de mísseis por exemplo precisam de uma bateria de testes gigantesco [as vezes sim de modelo formal] e por isso os mísseis construídos no Brasil apresentavam um erro de cálculo por volta de 400km [não queira estar a menos de mil km numa possível guerra no Brasil por causa do fogo amigo :)] porque o pessoal daqui não testava nada, só na prática [informações de um amigo que trabalhou no projeto].

Não sei se entendi direito a mensagem deste parágrafo... Os mísseis tinham erro de cálculo por que havia muitos testes?

Não, porque não havia testes.
 

--
http://www.milfont.org

[Rodrigo Rebouças de Almeida]

O processo de desenvolvimento é composto por, entre outras coisas, práticas de desenvolvimento, como TDD, pair programming, etc.

Eu posso ter um processo ágil com práticas "burocráticas" e vice-versa.
Mas há casos onde não posso atender às premissas dos processos ágeis, simplesmente por quê não é viável. Deixa eu passar rapidinho pelas premissas:

- Indivíduos e interações versus processos e ferramentas
Fato: Há contextos em que preciso suportar a mudança de indivíduos. Simplesmente não posso sustentar o funcionamento da empresa nos indivíduos. Preciso suportar mudança de pessoas sem afetar meus prazos e custos. Infelizmente é assim que o mundo cruel funciona. Em algum momento se meus desenvolvedores resolverem sair, a empresa tem que ser capaz de colocar outros no lugar e nem sentir falta dos que sairam.

- Software funcionando versus documentação
Fato: Nem todas as equipes têm o cliente acessível ou estão localizadas na mesma sala ou no mesmo prédio. A maioria dos projetos têm o cliente longe, têm dificuldade de marcar reuniões, tem vários stakeholders envolvidos e levantando requisitos conflitantes, etc. O software tem que funcionar, mas em vários contextos, para que ele funcione, precisamos de documentação para comunicar e para proteger o cliente, inclusive juridicamente. No mundo cruel as coisas funcionam assim também.

- Colaboração com o cliente versus contrato
Fato: Essa é bem curta. Simplesmente muitos clientes só pagam se existir contrato e muitos não trabalham com desenvolvimento orientado a escopo. Isso não é só governo.


- Resposta à mudança versus seguir planos
Fato: Se estou num contexto onde posso planejar, onde meus requisitos não mudam a ponto de afetar minha estimativa de tempo e custo, por que não planejar? Muitas grandes empresas do mundo, que estão ganhando muito dinheiro mesmo, trabalham todo dia neste contexto onde há subsidios para um planejamento rasoável. Onde um cliente tem um problema com escopo definido, onde se elabora um projeto, o cliente aceita o prazo e escopo e paga pelo desenvolvimento.
 

Atenção: Não estou indo contra métodos ágeis (sou um dos maiores entusiastas desta filosofia de desenvolvimento). Estou apenas mostrando um mundo com duas faces, que exigem abordagens diferentes (e distintas) para desenvolver software.

Rodrigo

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

[Maurício Linhares]

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>
>

> O processo de desenvolvimento é composto por, entre outras coisas, práticas de desenvolvimento, como TDD, pair programming, etc.
>
> Eu posso ter um processo ágil com práticas "burocráticas" e vice-versa.
> Mas há casos onde não posso atender às premissas dos processos ágeis, simplesmente por quê não é viável. Deixa eu passar rapidinho pelas premissas:
>
> - Indivíduos e interações versus processos e ferramentas
> Fato: Há contextos em que preciso suportar a mudança de indivíduos. Simplesmente não posso sustentar o funcionamento da empresa nos indivíduos. Preciso suportar mudança > de pessoas sem afetar meus prazos e custos. Infelizmente é assim que o mundo cruel funciona. Em algum momento se meus desenvolvedores resolverem sair, a empresa tem
> que ser capaz de colocar outros no lugar e nem sentir falta dos que sairam.

Se você pratica agilidade, você:

* faz TDD, o que quer dizer que tem testes que evitam regressões e que
ainda documentam o sistema
* faz pair programming, que garante que o conhecimento dos vários
pedaços de um sistema não vivem da cabeça de uma pessoa, mas de várias
* faz auditoria de código, ainda como consequência de pair
programming, ninguém vai escrever porcarias com um papagaio de pirata
do lado
* faz reuniões diárias e retrospectivas semanais (ou quinzenais) sobre
o estado atual do projeto, levando o status dele a todos os envolvidos

Processos ágeis primam por fazer com que a informação não viva em
silos, mas sim espalhada pela equipe. Eles são bem mais próprios em
ambientes onde a rotatividade é alta.

> - Software funcionando versus documentação
> Fato: Nem todas as equipes têm o cliente acessível ou estão localizadas na mesma sala ou no mesmo prédio. A maioria dos projetos têm o cliente longe, têm dificuldade de
> marcar reuniões, tem vários stakeholders envolvidos e levantando requisitos conflitantes, etc. O software tem que funcionar, mas em vários contextos, para que ele funcione,
> precisamos de documentação para comunicar e para proteger o cliente, inclusive juridicamente. No mundo cruel as coisas funcionam assim também.

Mais uma vez, se a documentação tem valor pro cliente, ela deve ser
feita. Processos ágeis não abominam documentação, abominam
documentação inútil ou que "perde a validade" rápido demais. E se o
cliente quer isso tudo, a equipe pode demonstrar o quanto isso é
nocivo.

Operação padrão neles :D

> - Colaboração com o cliente versus contrato
> Fato: Essa é bem curta. Simplesmente muitos clientes só pagam se existir contrato e muitos não trabalham com desenvolvimento orientado a escopo. Isso não é só governo.
>

Opção deles. Mas eu não acho que um contrato de escopo fechado seja
impossível de se levar em um processo ágel

> - Resposta à mudança versus seguir planos
> Fato: Se estou num contexto onde posso planejar, onde meus requisitos não mudam a ponto de afetar minha estimativa de tempo e custo, por que não planejar? Muitas grandes > empresas do mundo, que estão ganhando muito dinheiro mesmo, trabalham todo dia neste contexto onde há subsidios para um planejamento rasoável. Onde um cliente tem um > problema com escopo definido, onde se elabora um projeto, o cliente aceita o prazo e escopo e paga pelo desenvolvimento.
>

Decidir mais cedo quando você poderia decidir mais tarde, com mais
informação, experiência e embasamento é uma péssima idéia. Mais uma
vez, recomendo fortemente a leitura do "Lean Software Development",
especialmente o capítulo "Decide as late as possible". E da mesma
forma, diversas empresas também ganham muito dinheiro (mais uma vez, a
Toyota, por exemplo) fazendo isso.

[Rodrigo Rebouças de Almeida]

Depende e muito Rodrigo, por incríviel que pareça a influência do Beck para o TDD surgiu desse ramo chamado de "crítico" como o controle de um avião [que na verdade é um conjunto de softwares, cada dispositivos tem até sistema operacional próprio]. 

Eles não usam Waterfall nisso,

Não digo que eles usam Waterfall. Digo que não usam processos ágeis. A agilidade de um processo está ligada à capacidade do processo suportar muitas mudanças, com alta freqüência. Não é o caso deste tipo de sistema.

Agilidade não é isso, isso é um dos benefícios ganhos.

O que é agilidade de um processo se não a capacidade dele absorver mudanças?

 

na verdade a prática de testes surgiu fortemente nessa área, primeiro eles criam uma base considerável de testes [pelo menos o planejamento] e depois saem criando o código para passar nesses testes, claro que não é no esqueminha RED-GREEN-RED popularizado, mas isso influenciou demais o TDD.

Concordo que influenciou, mas não significa que o fato de processos ágeis serem test-driven ou até "orientados a testes" sejam adequados para sistemas críticos.

Sistemas críticos são orientados a testes por natureza, já viu a construção de asas de avião?  Todo o sistema de testes é desenhado antes do desenho da propria asa :)

Não me fiz entender...
Sistemas críticos são orientados a testes sim. Não podem nem precisam ser ágeis. Pronto. Em outras palavras. O fato de processos ágeis serem orientados a teste não os habilitam a serem adequados para produzirmos sistemas críticos. Acho que agora ficou claro.

 

(...)

Ainda há um enorme preconceito sobre o que é agile, como falta de documentação [mito], não planejamento [mito], apenas para sistemas mutáveis [que sistema não é mutável ao longo de seu ciclo de vida],

Sobre a tese de "mudabilidade" do sistema, ou mudança freqüente de requisitos, há sistemas onde os requisitos mudam muito, com muita freqüência, e sistemas onde os requisitos mudam pouco e com pouca freqüência. O primeiro caso exige um processo apto a absorver mudanças sem "traumas" o segundo admite um processo onde temos mais artifícios para planejar e estimar. Todo sistema muda. Alguns mudam muito e outros pouco, para isso temos processos ágeis e processos não-ágeis.

os processos conhecidos como não-agil não conseguem absorver mudança alguma, isso vai de encontro com a propria natureza do processo.

> Discordo. da afirmação "os processos conhecidos como não-agil não conseguem absorver mudança alguma"

Qualquer processo que tenha o conceito de iteração e interaja com o cliente ao longo do desenvolvimento do processo pode absorver mudanças. A quantidade de mudanças, frequencia das mudanças e qualidade das mudanças é que definirão se um processo deve ou não ser ágil.

Numa metáfora barata: Se alguém me contrata para desenvolver um vinho tinto. Eu sei os requisitos do vinho, cor, sabor, aroma, etc. Ao longo do desenvolvimento do vinho eu vou mostrando os resultados intermediários ao meu cliente e ele pode mudar alguns requisitos, para adequar minha solução ao que ele quer... Ele pode pedir para mudar o sabor, alterar a uva, mudar o aroma, etc. Mas o contratado ainda é fazer vinho. Esse tipo de desenvolvimento não precisa ser ágil e absorve mudanças.

A diferença do ágil é que o cliente pode, no meio do desenvolvimento incorporar mudanças como: não quero mais que seja vinho, agora quero Cachaça. :-)

 
Rodrigo

--
http://www.milfont.org

[CMilfont]

Rodrigo, você esqueceu do complemento:

That is, while there is value in the items on
the right, we value the items on the left more. 

De forma alguma, não é que não exista valor nos items a direita, apenas os items a esquerda são mais valorizados.
Respostas abaixo:

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>

O processo de desenvolvimento é composto por, entre outras coisas, práticas de desenvolvimento, como TDD, pair programming, etc.

Em primeiro lugar são os valores, entendendo os valores o resto flui naturalmente, em segundo lugar os princípios que norteiam esses valores, e em ultimo lugar as práticas. Se você observar, as práticas são consequências naturais dos valores e princípios.
 

Eu posso ter um processo ágil com práticas "burocráticas" e vice-versa.

Isso é impossível quando você compreende os valores.
 

Mas há casos onde não posso atender às premissas dos processos ágeis, simplesmente por quê não é viável. Deixa eu passar rapidinho pelas premissas:

- Indivíduos e interações versus processos e ferramentas
Fato: Há contextos em que preciso suportar a mudança de indivíduos. Simplesmente não posso sustentar o funcionamento da empresa nos indivíduos. Preciso suportar mudança de pessoas sem afetar meus prazos e custos. Infelizmente é assim que o mundo cruel funciona. Em algum momento se meus desenvolvedores resolverem sair, a empresa tem que ser capaz de colocar outros no lugar e nem sentir falta dos que sairam.

Em modelos tradicionais, a mudança de pessoal é danosa ao processo porque não estão preparados para suportar o alto turnover de "recursos humanos", para isso burocratizam mais o processo para tentar minimizar esse impacto.
Em modelos agiles, a mudança de pessoal é recebida como uma consequência natural dos desejos das pessoas de saírem a procura de sua felicidade e é enfrentada por práticas como "Collective Code" e "Moving People Around" com e sem Pair Programming onde o conhecimento é disseminado entre todos na equipe, há outras práticas.
Evidente que a saída de uma pessoa [justamente por entendermos que as pessoas é quem são os valores mais importantes no desenvolvimento de um software] de um projeto impacta não só na moral do time como no andamento de qualquer projeto, mas agiles estão melhores preparados.
 

- Software funcionando versus documentação
Fato: Nem todas as equipes têm o cliente acessível ou estão localizadas na mesma sala ou no mesmo prédio. A maioria dos projetos têm o cliente longe, têm dificuldade de marcar reuniões, tem vários stakeholders envolvidos e levantando requisitos conflitantes, etc. O software tem que funcionar, mas em vários contextos, para que ele funcione, precisamos de documentação para comunicar e para proteger o cliente, inclusive juridicamente. No mundo cruel as coisas funcionam assim também.

O principal é ter o software funcionando e conseguir responder as mudanças naturais. Dizer que documentação é mais importante do que o software funcionando é um contrasenso, ainda mais que software funcionando pode existir sem documentação, documentação não faz um software funcionando existir.
Não gosto de falar de ferramentas mas por exemplo, CVS [assuma qualquer SCM] + Mylyn + Trac + Jabber + Skype + wiki + ... são transparentes a qualquer time e você consegue a rastreabilidade desde a prospecção dos requisitos ao produto final [que é o software funcionando] e não enche o saco de ninguém para ficar desenhando esqueletinhos em UML. Eu concordo que documentação é importante, javadocs e comentarios no commit são fundamentais.
 

- Colaboração com o cliente versus contrato
Fato: Essa é bem curta. Simplesmente muitos clientes só pagam se existir contrato e muitos não trabalham com desenvolvimento orientado a escopo. Isso não é só governo.

Não há importância, quem já se viu não ter contrato? o importante aqui é ter colaboração, projeto sem colaboração nunca vai dar certo.
 

- Resposta à mudança versus seguir planos
Fato: Se estou num contexto onde posso planejar, onde meus requisitos não mudam a ponto de afetar minha estimativa de tempo e custo, por que não planejar? Muitas grandes empresas do mundo, que estão ganhando muito dinheiro mesmo, trabalham todo dia neste contexto onde há subsidios para um planejamento rasoável. Onde um cliente tem um problema com escopo definido, onde se elabora um projeto, o cliente aceita o prazo e escopo e paga pelo desenvolvimento.

Rodrigo, dizer que uma empresa ganha dinheiro então inferir que ela está correta com isso é falácia e voce sabe muito bem, não vamos cair nesse tipo de argumentação. Enron neles :)
Esse é o problema de querermos implantar uma metodologia by the book, não conheço nenhum projeto que não se faça planejamento de curto, medio e longo prazo, apenas que ninguem vai comecar o desenvolvimento quando terminar todo o planejamento sequer do curto prazo, para isso dividimos para conquistar e identificar as mudanças necessária o quanto antes.
Estou trabalhando em cliente hoje onde tenho que criar uma camada para abstrair um contrato de escopo fechado com e a equipe e não afetar o processo. Estou vendo que trabalhar com escopo fechado não e bicho de sete cabeças e é possivel.
 

 

Atenção: Não estou indo contra métodos ágeis (sou um dos maiores entusiastas desta filosofia de desenvolvimento). Estou apenas mostrando um mundo com duas faces, que exigem abordagens diferentes (e distintas) para desenvolver software.

Rodrigo

Não concordo, existe a forma certa e a forma errada, seguir um modelo UP ou waterfall [que sempre foi errado] hoje em dia com tanta evolução no desenvolvimento de software é a forma errada.
Temos maturidade hoje para escopos fechados, abertos, equpe remota, local, etc e tal.

Por isso não concordo mais em chamar de Agile, prefiro chamar hoje de Melhor ou Correto.
 

--
http://www.milfont.org

[Rodrigo Rebouças de Almeida]

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

(...)

Processos ágeis primam por fazer com que a informação não viva em
silos, mas sim espalhada pela equipe. Eles são bem mais próprios em
ambientes onde a rotatividade é alta.

Rotatividade alta funciona quando você tem a propriedade coletiva de código, programação em par, etc. etc. o conjunto todo. Se você está num contexto onde essas outras práticas não são possíveis, infelizmente o conhecimento vai junto com o profissional e rotatividade é um problema.
 

Mais uma vez, se a documentação tem valor pro cliente, ela deve ser
feita. Processos ágeis não abominam documentação, abominam
documentação inútil ou que "perde a validade" rápido demais. E se o
cliente quer isso tudo, a equipe pode demonstrar o quanto isso é
nocivo.

Sim. Mas se documentação tem valor para o cliente e ela afeta a agilidade do processo, não pode ser um processo ágil. Se preciso de documentação, não posso aceitar mudanças como num processo onde esta não é necessária ou é transiente. 

> - Colaboração com o cliente versus contrato
> Fato: Essa é bem curta. Simplesmente muitos clientes só pagam se existir contrato e muitos não trabalham com desenvolvimento orientado a escopo. Isso não é só governo.
>

Opção deles. Mas eu não acho que um contrato de escopo fechado seja
impossível de se levar em um processo ágel

Se tenho escopo fechado, não preciso de um processo ágil. Simples assim. Posso planejar, estimar, para o projeto todo.
 

Bem, vou almoçar. :-)

Abraços,

Rodrigo

-
Maurício Linhares
http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en)
João Pessoa, PB, +55 83 8867-7208

[Maurício Linhares]

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>:

>
> O que é agilidade de um processo se não a capacidade dele absorver mudanças?
>

Os requisitos não mudam, mas isso não quer dizer que o código não
mude. Eu nunca vi um software que fosse escrito todo de uma vez, sem
alterações.

A agilidade não suporta apenas as mudanças em alto nível, como também
as de baixo nível.

>
> Não me fiz entender...
> Sistemas críticos são orientados a testes sim. Não podem nem precisam ser
> ágeis. Pronto. Em outras palavras. O fato de processos ágeis serem
> orientados a teste não os habilitam a serem adequados para produzirmos
> sistemas críticos. Acho que agora ficou claro.

Com base no que você afirma que eles "Não podem nem precisam ser ágeis"?

Uma busca rápida no google sobre o assunto vai mostrar diversos
papers, notícias e textos sobre a aplicação de metodologias ágeis em
sistemas de missão crítica.

>
> Numa metáfora barata: Se alguém me contrata para desenvolver um vinho tinto.
> Eu sei os requisitos do vinho, cor, sabor, aroma, etc. Ao longo do
> desenvolvimento do vinho eu vou mostrando os resultados intermediários ao
> meu cliente e ele pode mudar alguns requisitos, para adequar minha solução
> ao que ele quer... Ele pode pedir para mudar o sabor, alterar a uva, mudar o
> aroma, etc. Mas o contratado ainda é fazer vinho. Esse tipo de
> desenvolvimento não precisa ser ágil e absorve mudanças.

Interessante. Só é pouco provável encontrar software assim. Software
que não muda nem evolui é lenda ou obsoleto, ao menos na maior parte
das vezes.

[Maurício Linhares]

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>:

>
> Rotatividade alta funciona quando você tem a propriedade coletiva de código,
> programação em par, etc. etc. o conjunto todo. Se você está num contexto
> onde essas outras práticas não são possíveis, infelizmente o conhecimento
> vai junto com o profissional e rotatividade é um problema.
>

Rodrigo, se você não tem nem propriedade coletiva de código, não
existe agilidade. O seu processo é qualquer coisa, menos ágil.

>
> Sim. Mas se documentação tem valor para o cliente e ela afeta a agilidade do
> processo, não pode ser um processo ágil. Se preciso de documentação, não
> posso aceitar mudanças como num processo onde esta não é necessária ou é
> transiente.
>

Como é que a documentação afeta a agilidade?

Não entendi a relação de uma coisa com a outra. A documentação faz
parte dos entregáveis, ela afeta o projeto tanto quanto o código do
sistema produzido.

>
> Se tenho escopo fechado, não preciso de um processo ágil. Simples assim.
> Posso planejar, estimar, para o projeto todo.
>

Mais uma vez, opção sua. Eu, pessoalmente, prefiro deixar pra decidir
depois e aproveitar as vantagens de fazer isso.

[Rodrigo Rebouças de Almeida]

Acho que chegamos no cerne da questão.

Atenção: Não estou indo contra métodos ágeis (sou um dos maiores entusiastas desta filosofia de desenvolvimento). Estou apenas mostrando um mundo com duas faces, que exigem abordagens diferentes (e distintas) para desenvolver software.

Rodrigo

Não concordo, existe a forma certa e a forma errada, seguir um modelo UP ou waterfall [que sempre foi errado] hoje em dia com tanta evolução no desenvolvimento de software é a forma errada.
Temos maturidade hoje para escopos fechados, abertos, equpe remota, local, etc e tal.

Ótimo! Chegamos num ponto interessante.

Não concordo que haja apenas uma forma de desenvolver software (a correta). Waterfall, RUP, XP, SCRUM, etc. são todos métodos válidos para os contextos onde devem ser aplicados. Waterfall pode ser aplicado hoje. RUP pode ser aplicado hoje. Assim como XP e etc.

Esta diferença de opiniões está norteando todo o argumento ao longo desta thread.

Milfont, podemos trocar mais idéias em Natal, ao vivo. :-)

Bom, vou almoçar,

Rodrigo

[CMilfont]

Waterfall nunca pode ser correto, eu disse: N-U-N-C-A!
O Paper que o descreveu alertava para um convite a riscos e falhas [http://en.wikipedia.org/wiki/Waterfall_model]
RUP até os "Three Amigos" já o desaconselham, o escritor mais conhecido - Craig Larmam - já aposentou o iterativo-incremental UPiano e abraçou os modelos ágeis.

Vamos discutir sim lá em Natal :)

2008/11/11 Rodrigo Rebouças de Almeida <rodr...@rodrigor.com>

Acho que chegamos no cerne da questão.

--
http://www.milfont.org

[Rodrigo Rebouças de Almeida]

Exemplo simples, dentro de casa. Meu tio comprou um software para gerenciar o sistema financeiro da fábrica de tubos de papelão. Contratou uma software house, levantou os requisitos, os caras levaram 4 meses desenvolvendo, entregaram, meu tio pagou, a software house está dando manutenção quando precisam corrigir um bug ou mudar um relatório e pronto. Meu tio satisfeito, a software house ganhou dinheiro. Waterfall bonito, em nosso tempo. :-)

Minha mãe tem uma lojinha e contratou uma empresa pra fazer um sistema de controle de conserto de roupas. Cascata de novo. O sistema está funcionando filet, o cara vem dar manutenção de vez enquando.

Sem usar exemplos como as aplicações do cascata que citei, tenho certeza que dezenas de pessoas aqui na lista podem citar casos de sucesso da aplicação de processos não-ágeis em suas empresas e projetos. Eu conheço empresas que sobrevivem sem agilidade.

Mais um alerta de segurança para os desavisados: Não estamos negando agilidade. Estamos dizendo que nem tudo é agilidade. Só isso.

Teremos mais oportunidade de conversar sobre o assunto.

Abraço,

Rodrigo Rebouças

2008/11/11 CMilfont <cmil...@gmail.com>

[Kiko Barretto]

Vale a pena atentar que as diversas metodologias de desenvolvimento surgiram com finalidades específicas. Uma parte delas, inclusive, surgiu no intuito de superar alguma dificuldade apresentada por outra(s) metodologia(s) anterior(es). Portanto, há casos e casos. 

Sinceramente, acho que para cada caso há uma metodologia (ou combinação delas) mais "adequada", o que não significa que haja apenas uma forma de fazer ou ainda que se fosse feito de outra forma não funcionaria. E, Rodrigo, me corrija se eu estiver errado, mas há casos de sucessos em todos os métodos, correto? 

Quanto à documentação, nada impede que o desenvolvimento ágil gere uma documentação decente (em papel timbrado, como os chefes gostam ehhehe). Isso só depende da necessidade do sistema ser documentado, se agrega ou não valor para o cliente e do bom senso do Team.

A própria história já se encarregou de nos provar que não há verdade absoluta e nada que nao possa ser melhorado, portanto, a metodologia da "moda" de hoje pode nao ser a de amanhã, o que não significa que ela não será mais usada... o que não vale é se apegar a alguma metodologia dizer pra ela que será fiel. :D

Forte abraço,

Fco Barretto.

[Alan Kelon Oliveira de Moraes]

2008/11/11 CMilfont <cmil...@gmail.com>

Quais as boas práticas de testes que eram executadas antes do surgimento das metodologias ágeis?

Milfont, todas que já existem hoje: teste unitário, de integração, de sistema, de carga, etc. Veja o capítulo 5 do SWEBOK. Test-Driven Development foi sim introduzido por Beck, mas não deve ser a única técnica de testes a ser usada.

Penso que você esteja se referindo à automação de testes. Neste ponto, concordo que processos de desenvolvimento ágeis prezam pela devida automação destes processos, mas tais ferramentas também sempre existiram. Consigo encontar relatos de automação de testes desde o ano de 1967 :-)

Abraços,

[Alan Kelon Oliveira de Moraes]

Olá!

2008/11/11 Maurício Linhares <mauricio...@gmail.com>

Ninguém disse que é exclusivo, mas processos ágeis tem isso como
práticas bem definidas, em RUP por exemplo TDD não é uma prática
definida.

Nem no Scrum, FDD, DSDM. Só vi TDD como prática definida no XP. Não sei afirmar sobre Crystal porque nunca li nada mais profundo sobre este processo.

Você pode fazer TDD com RUP?

Pode.

Os manuais de RUP incitam você a fazer isso?

Não.

Cuidado para não queimar a língua :-) A primeira tarefa do projetista dos testes é justamente definir qual será a abordagem de testes, que pode ser, inclusive, TDD.

Eu acho que a grande diferença dos processos ágeis (tirando Scrum,
claro) é exatamente o foco em práticas pra se chegar a um resultado
final e não no resultado final em si, que normalmente é o foco dos
outros processos.

Concordo. Faço uma ressalva sobre o RUP, pois posso afirmar que o ocorre mesmo com ele.

Atenciosamente,

--

Alan Kelon Oliveira de Moraes

[Maurício Linhares]

2008/11/14 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>:

>
> Cuidado para não queimar a língua :-) A primeira tarefa do projetista dos
> testes é justamente definir qual será a abordagem de testes, que pode ser,
> inclusive, TDD.
>

Esse é o pior defeito do RUP, tudo "pode ser", tudo "cabe", é só
tentar com jeitinho :)

RUP é tão personalizável que você dificilmente vai ver duas aparições
dele ao menos parecidas, mesmo que seja no mesmo lugar.

E se o projetista de testes define que "vai usar TDD" nós temos uma
coisa muito errada na história, porque TDD não é pra escrever testes,
é pra guiar o design do sistema, os testes não são o fim, mas o meio,
não acho que seja papel de um projetista de testes (eu nem acho que
isso deveria existir, mas...) definir uma coisa como essa.

[Alan Kelon Oliveira de Moraes]

2008/11/14 Maurício Linhares <mauricio...@gmail.com>

2008/11/14 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>:

>
> Cuidado para não queimar a língua :-) A primeira tarefa do projetista dos
> testes é justamente definir qual será a abordagem de testes, que pode ser,
> inclusive, TDD.
>

Esse é o pior defeito do RUP, tudo "pode ser", tudo "cabe", é só
tentar com jeitinho :)

Argh! Bobagem, porque o mesmo ocorre com os processos ágeis, i.e., se X vai agregar valor então coloca no processo ágil tão logo bloated. É apenas questão de como se vê a adaptação do processo: tailoring (de cima para baixo) ou scaling (de baixo para cima).

 

E se o projetista de testes define que "vai usar TDD" nós temos uma
coisa muito errada na história, porque TDD não é pra escrever testes,
é pra guiar o design do sistema, os testes não são o fim, mas o meio,

Quem falou o contrário?

--

Alan Kelon Oliveira de Moraes

[CMilfont]

Alan, testes unitarios só vieram a tona depois do XP e principalmente se popularizaram depois do TDD, existir o conceito pode ter existido, qual ferramenta voce conhece antes do JUnit?

Sabia que antes do motor a combustão existiam motores elétricos[1]? Carros eco-politicamente-corretos existiam no século 19, só não eram viáveis [como ainda não são], mesma coisa sobre conceitos computacionais, existem conceitos que são de muito tempo atrás, só não são/eram viáveis ou não tinha a cultura adequada para sua utilização, como testes de software.

http://en.wikipedia.org/wiki/Automobile#Electric

2008/11/14 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>

--
http://www.milfont.org

[Alan Kelon Oliveira de Moraes]

Olá, lista,

2008/11/14 CMilfont <cmil...@gmail.com>

Alan, testes unitarios só vieram a tona depois do XP e principalmente se popularizaram depois do TDD, existir o conceito pode ter existido, qual ferramenta voce conhece antes do JUnit?

 

2008/11/14 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>

Milfont, todas que já existem hoje: teste unitário, de integração, de sistema, de carga, etc. Veja o capítulo 5 do SWEBOK. Test-Driven Development foi sim introduzido por Beck, mas não deve ser a única técnica de testes a ser usada.

Milfont, de fato TDD veio junto com XP, como já havia comentado.

Receio que você esteja confundindo testes unitários com execução automática de testes. Teste unitário significa testar a menor unidade do projeto de software, seja ela uma classe, em software OO, um componentes ou um módulo, em sistemas estruturados. Desta forma existe teste unitário em programas escritos em C, que não é orientada a objetos, pois posso testar os módulos escritos individualmente. Ou você não concorda que é possível escrever teste unitário para código não OO? Igualmente, em Java, posso escrever os meus testes unitários dentro da própria classe, no método main e executar a classe. Não considero a melhor abordagem em termos de automação de execução, porém não deixa de ser teste unitário, pois ainda assim estou testando cada classe individualmente.

Sobre ferramentas para automação de execução de testes, JUnit, por ser de código aberto e gratuito, foi responsável sim pela aceleração da adoção de ferramentas desta natureza. Em geral, software de código aberto, quase sempre gratuito, teve - e ainda tem - papel de muito destaque na disseminação de muitas ferramentas da área de qualidade de software, por exemplo, CVS, Ant, JUnit, CruiseControl, Cactus, JMeter, Bugzilla, e mais recentemente Maven, SVN, Trac, Selenium. Entretanto, continuo afirmando que tais ferramentas já existiam antes do JUnit. Cito, por exemplo, IPL AdaTEST 95, software proprietário, que está disponível desde 1991. A grande diferença é que, de uns tempos pra cá, temos vasta disponibilidade de ferramentas gratuitas.

Listar as ferramentas acima fez-me lembrar uma palestra da Neus no auditório do CCEN, na UFPB, pelos idos de 2002 ou 2003, onde um dos donos da empresa citou mais ou menos a mesma lista de ferramentas e falou que a empresa muito possivelmente teria maiores dificuldades de existir caso as ferramentas de código aberto não existissem, pois elas tinham papel fundamental na construção de seus software e demandariam muito tempo para seus colaboradores desenvolverem eles próprios, mais tempo inclusive que o necessário para escrever o software em si que empresa comercializava. Argumento que corrobora meu pensamento acima.

[Maurício Linhares]

2008/11/14 Alan Kelon Oliveira de Moraes <al...@di.ufpb.br>:
> Olá, lista,

>
> Sobre ferramentas para automação de execução de testes, JUnit, por ser de
> código aberto e gratuito, foi responsável sim pela aceleração da adoção de
> ferramentas desta natureza. Em geral, software de código aberto, quase
> sempre gratuito, teve - e ainda tem - papel de muito destaque na
> disseminação de muitas ferramentas da área de qualidade de software, por
> exemplo, CVS, Ant, JUnit, CruiseControl, Cactus, JMeter, Bugzilla, e mais
> recentemente Maven, SVN, Trac, Selenium. Entretanto, continuo afirmando que
> tais ferramentas já existiam antes do JUnit. Cito, por exemplo, IPL AdaTEST
> 95, software proprietário, que está disponível desde 1991. A grande
> diferença é que, de uns tempos pra cá, temos vasta disponibilidade de
> ferramentas gratuitas.
>

As ferramentas de automação e os testes "unitários" já existiam bem
antes disso, em "Mythical Man Month" (no capítulo "Surgical Team")
Brooks já se referia a "testing pieces of work" e também "tests for
the whole thing". A diferença é que nessa época, pela dificuldade de
se disseminar as coisas, cada equipe fazia o seu próprio
"automatizador de testes", o que provavelmente eram apenas um conjunto
de Makefiles.