Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).
IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)
Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
Agil só se aplica antes da primeira entrega. Agil só se aplica para desenvolvimento.
Vc pode subverter/modificar para usar depois do desenvolvimento, mas isso não o que estamos falando.
Se está falando nos problemas pós entrega, agil não é para isso.
Se estamos falando dos problemas pré-entrega, então sim.
Agil define “entrega” como meta. Ou seja, não ha nada além disso.
Depois da entrega vc está de volta no mundo “não-agil”
Claro que vc pode até ter um mecanismo agil para toda a empresa (dificil , mas suponhamos que é verdade).
Nesse caso se a placa tiver algum problema será outra equipa a tratar do recall, etc…
A Toyota usa LEAN. E ha pouco tempo fez um recall. Uma coisa não tem nada a ver com a outra. Mas veja que o recal foi devido a um problema nos requisitos do carro (alguma coisa sobre tapetes se ñ me engano) nada em relação à construção do carro. Ou seja, a parte LEAN funcionou. Apenas alguem alimentou o processo com requisitos de má qualidade.
Em Agil não. “Desenvolvimento” é o que acontece até à entrega.
Se houver um ciclo de manutenção, existirá uma nova entrega e portanto um novo “ciclo agil”. Esta nova entrega é diferente da primeira em termos de objetivos, entradas e saidas. Vc pode aplicar agil a entre novo ciclo, mas não é disto que estamos falando quando falamos de agil sem mais adjetivos.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
[/quote]
Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).
IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)
Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
[/quote]
Acho que o vini quis dizer foi o falso positivo. não é questão do teste simplesmente passar, mas a forma como foi elaborado. a forma como o teste se desenrola dentro do código não é preocupação da ferramenta, apenas se deu certo ou não. por isso é importante ter registrado de alguma forma como deve se comportar o teste. Ou seja, o comportamento só pode ser examinado por pessoas. é aí que entra algum wiki ou qualquer outra forma de deixar isso claro para pessoas o enredo.
Certo. E como você garante que os testes foram executados corretamente? Ou como você garante a cobertura dos testes? E como você rastreia os erros reincidentes e localiza suas causas? Ou os evita no futuro?
[/quote]
Humm… vc já ouviu falar em IC ( Integração Continua ) ?
Existem ferramentas que contam a cobertura, etc… E se vc me vier com argumento que isso só existe em java, não é verdade. O pessoal da NASA usa isto em C (nem é C++).
IC implica em testes automáticos e continuos. Isso carante a execução, a cobertura, a localização e evita que aconteça reincidencia.
A rastreabilidade pode ser mantida pelas infos e logs dos executores que apontam onde está o erro (em que classe, linha, etc…)
Não ha nenhuma necessidade de confiar no programador. confie nas ferramentas.
Pode ser um processo totalmente hands off se implementado direito.
[/quote]
Acho que o vini quis dizer foi o falso positivo. não é questão do teste simplesmente passar, mas a forma como foi elaborado. a forma como o teste se desenrola dentro do código não é preocupação da ferramenta, apenas se deu certo ou não.
[/quote]
Isso simplesmente não é verdade. O Cobertura, por exemplo, determina - durante o teste - quais linhas foram executadas e quais não.
Se o seu ferramental não analisa o desenrolar do codigo, então use um que analisa. Se é que realmente precisa disso.
Existe uma coisa chamada Requisito. O testes tem que está em conformidade com o requisito. Realmente o o fato de passar ou não, não signifca que está tudo ok. ( um teste vazio passa). Mas ai entramos no mérito da construção dos testes.
O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.
A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.
não. Esse é o pensamento burucrático de que falei. A documentação deve dizer o que esperar do teste, não como construir o teste. O “como” é capacidade do programador. Se ele não a tem, arranje outro. No máximo existe uma documentação sobre o framework de testes ( como o junit e afins) e como o usar, mas isso não é dizer o que esperar do teste.
Exemplo:
Consistencia: A função de soma deve ser cumutativa.
Como testar isso ? O programador deve saber que deve invocar o método com a ordem a,b dos argumentos e depois com a ordem b,a e o resultado deve ser o mesmo para todos os a,b. Como não pode testar todos os a,b , testa os limites. os menores e maiores valores de a e b. zero e null (se permitido) e um ou dois valores escolhidos aletoriamente.
Ninguem vai documentar o codigo, ou pseudo codigo deste teste. isso é suicídio.
[quote=sergiotaborda]O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.
A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.[/quote]
Espere um pouco, você por acaso pulou essa linha?
Sim, o IC garante, por que as ferramentas do IC geram documentos, descrevendo o resultado dos testes de cobertura e demais testes. E o conjunto de documentos desses ganha o nome de… documentação. Em momento nenhum falei que a documentação, para ser válida, precisa ser feita manualmente. Aliás, acho que o que quote deixa bem claro o contrário.
Manter guardado o relatório do IC é manter documentação. Se algo falhar em campo, você vai querer ver esses dados, para detectar onde a falha ocorreu. E vai ser ainda mais grave se nenhum relatório desse tiver sido gerado, pois indicará que você queimou uma etapa do processo.
Mesmo os processos ágeis guardam documentação além do requisito. Como por exemplo, o javadoc dos principais métodos ou ainda a exigência do uso da tag @author, @version. Nada disso é requisito funcional.
O requisito é a documentação mais importante, de fato. Mas já trabalhei com softwares críticos que seriam muito complexos de entender sem um pouco mais de documentação do que o código fonte, os javadocs e os testes. Em software otimizado, você desconstrói a refatoração em prol de performance, e precisa ter clara as metas de execução de determinadas funções (porque elas tornam-se parte do requisito). Nesse caso, muitas vezes é comum recorrer a diagramas.
Aliás, um diagrama macro, que mostre como as camadas de sua aplicação se organizam também é muito comum.
[quote=ViniGodoy][quote=sergiotaborda]O meu ponto é: dado que o teste está construido, o IC garante as propriedades que o Vini queria garantir via “documentação”.
A unica documentação não codigo que é necessária é o requisito. E até ai, hoje em dia, existem ferramentas que permitem deixar mais fina a fronteira entre requisito e codigo.[/quote]
Espere um pouco, você por acaso pulou essa linha?
Sim, o IC garante, por que as ferramentas do IC geram documentos, descrevendo o resultado dos testes de cobertura e demais testes. E o conjunto de documentos desses ganha o nome de… documentação. Em momento nenhum falei que a documentação, para ser válida, precisa ser feita manualmente. Aliás, acho que o que quote deixa bem claro o contrário.
Manter guardado o relatório do IC é manter documentação. Se algo falhar em campo, você vai querer ver esses dados, para detectar onde a falha ocorreu. E vai ser ainda mais grave se nenhum relatório desse tiver sido gerado, pois indicará que você queimou uma etapa do processo.
[/quote]
Acho que não estou me fazendo entender. Nada vai para campo se aconteceu alguma falha. Se algo foi para campo é porque todos os testes eram verdes. Logo, se aconteceu um problema no campo e foi identificada uma falha só nesse momento, isso não tem nada que ver com IC. O IC não vai descobrir esse erro a menos que um teste seja adicionado que levanta essa falha. mas isso é feito depois que o erro acontece.
O senário seria : 1) o IC está verde. 2) a placa é entregue. 3) um problema aconteceu no campo 4) a placa retorna
5) o problema é identificado 6) um teste é montado para idenificar o problema à priori ( supondo que se pode) 7 ) o teste é adicionado ao IC.
8) o IC é aplicado às novas placas e placa velha é modificada ou destruida e substituida por uma nova devidamente testada com o novo IC.
Não estamos falando da documento gerada como javadoc, relatorios de testes etc… estamos discutindo se o processo agil é aplicado pós deploy ou não. Vc argumentou que num processo com deploy externo como o de uma placa de hardware com firmware não seria possivel aplicar agil porque nao ha como retornar todas as placas para serem corrigidas. Eu argumentei que o processo agil não abrange a fase pós-produção.
Mesmo que o firmware podesse ser atualizado via internet automaticamente esse processo não estaria no ambito do processo agil. O processo agil teria terminado no momento que o patch ficou disponivel para download. É o problema do conceito de entrega.
A documentação que atrapalha não é a automática, nem a de pós-produção é a de pré-produção. É ai que o agil defende a comunicação e não a documentação. Ou seja, nada de criar documentos monstruosos antes do codigo. Documentos só podem ser criados depois do codigo, a menos é claro que sejam codigo em si mesmos (como testes de aceitação automatizados).
Contudo, o scrum em particular , parte do documento de visão que é elaborado antes da construção. Além disso parte do backlog e dos release backlogs que são feitos antes também e do spring backlog que é feito antes. Mas repare que estas coisas são documentos de intensão (são desejos e checklists) não são requisitos e não são documentação ( excepto o documento de visão). são artefatos de controle gerencial e não constituem entregáveis. São, por assim dizer, meta-documentos.
A falha em criar estes artefactos com qualidade leva a um caos igual ou pior que a falha em criar bons documentos de requisitos no modelo classico.
O scrum, tb em particular, sugere que exista um documento não código que é o manual do usuário. Este documento serve tanto como requisitos como check list como documento para ensinar a usar o sistema. E é considerado o alter-ego do código.
Portanto, logo aqui, no scrum vc tem pelo menos 3 documentos : visão, manual de usuário e código.
visão = o que queremos para o futuro / o que queriamos no incio do projeto
manual = o que obtivemos no final
codigo = como obtivemos.
[quote=sergiotaborda]Acho que não estou me fazendo entender. Nada vai para campo se aconteceu alguma falha. Se algo foi para campo é porque todos os testes eram verdes. Logo, se aconteceu um problema no campo e foi identificada uma falha só nesse momento, isso não tem nada que ver com IC. O IC não vai descobrir esse erro a menos que um teste seja adicionado que levanta essa falha. mas isso é feito depois que o erro acontece.
O senário seria : 1) o IC está verde. 2) a placa é entregue. 3) um problema aconteceu no campo 4) a placa retorna
5) o problema é identificado 6) um teste é montado para idenificar o problema à priori ( supondo que se pode) 7 ) o teste é adicionado ao IC.
8) o IC é aplicado às novas placas e placa velha é modificada ou destruida e substituida por uma nova devidamente testada com o novo IC.
[/quote]
Sim, o que estou dizendo é que, quando a falha ocorrer, você precisa ter certeza que a equipe efetivamente fez a integração. Deve ter condições de olhar o relatório do Code Coverage e ver se realmente nada ficou faltando. E isso, só será feito através da documentação gerada pela ferramenta.
Não, não foi isso que argumentei. Eu argumentei que você pode usar processos ágeis até exatamente antes do deploy. Que as indústrias exigirão mais documentos garantindo o processo como um todo, antes de liberar um produto no mercado.
Sim, e foi por isso que fiz questão de frizar a diferença dos dois processos. O processo unificado conta como desenvolvimento as fases que sucedem a manutenção. Para ele, os documentos gerados devem contemplar a fase de manutenção do código, e devem prover os feedbacks necessários para que a manutenção ocorra de maneira suave. Outra coisa é que o Processo Unificado foi idealizado para equipes enormes de desenvolvimento, por isso, acho que não compensa utiliza-lo em equipes menores. Para elas, ele é realmente burocrático demais.
O processo unificado também condena a criação de documentos monstruosos antes do código. É um princípio que você só deve elaborar um documento, caso ele traga valor ao entendimento do sistema. Como eu falei, acho que processo sério nenhum defende a documentação pela documentação.
Um problema sério são os estereótipos vendidos pelos livros por aí. Se você lê um livro ágil, quem usa rup está “num processo em cascata, perdendo tempo com documentos inúteis”. Se você lê um livro sobre o processo unificado, os processos ágeis são “sem metodologia, baseados na bagunça”. Bem, ambas as visões não são verdade.
O que existe, de fato, são empresas que entendem errado o processo unificado e fazem com ele o que outras fazem com o ágil: Não o implementam direito. E aí, culpam o processo. Se você vai usar o processo unificado, você não deve, por exemplo, hierarquizar sua equipe. O processo é bastante firme em defender que o analista não é “chefe” do programador. E que o programador não é um pedreiro. Ambos devem estar em constante comunicação. Ele também defende ciclos bastante curtos, com pouca documentação gerada. Mais do que os processos ágeis, claro, mas para uma equipe maior, uma documentação ainda assim necessária.