Agile CMM

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

Andei cozinhando uma idéia sobre a aplicação de princípios ágeis para trabalhar com níveis altos de CMM.
Minha conclusão é que apesar de parecer o contrário, os métodos ágeis são bastante formais. Tanto, que talvez seja o suficiente para as necessidades burocráticas de uma estrutura CMM 5.

A base da minha hipótese é que não existe nada mais formal que um teste. Então em vez dos analistas gastarem um tempão escrevendo documentos de especificação e desenhos de alto e baixo nível, eles gastam um tempão escrevendo testes. E veja: um caso de uso por mais formal e complexo que seja, ele não pode ser mais específico e formal que um teste unitário.

Aliás, dá até para entender porque o pessoal do XP só quer um cartãozinho para descrição de funcionalidades do sistema. A especificação ultradetalhada do que deve acontecer ficará no teste unitário mesmo... pra que caso de uso?

Tenho a impressão que é possível atender a todas as KPAs do CMM nível 5 com uma implementação de metodologia ágil. Uma das minhas dúvidas é como estimar o tamanho de um projeto? Será que depois de escrever todos os testes unitários de aceitação é possível fazer previsões seguras (dentro de uma margem de erro conhecida)?

Olá Rodrigo,

Os testes unitários garantem que teu software funciona. Ainda, te dá confiança para mudar, visto que, em um projeto de grande escopo, ele te alerta sobre falha em supostas dependências.

Estimativas são feitas quebrando teu sistema em diversos pedaços, adiando decisões mais críticas e entregando sempre releases funcionais. Isto garante boa relação com teu cliente. Ele está vendo que o sistema tá andando e se tiver algo para mudar ele vai se sentir muito a vontade para falar com você (até diretamente)

Testes podem ser gerados muito rapidamente, vide TestNG ou Junit4. Muito mais rápido do que balões e bonecos que eu fazia no jardim da infãncia que descrevem os atores.

O conhecimento é adquirido ao longo do projeto, não através de documentos, pois ele é disseminado entre a equipe constantemente através de conversas informais entre os programados, e ainda vários outros tipos de informação, através do famigerado tracker

Bem, é bom ressaltar que adotar 100% XP não é viável em projetos enormes e equipes muito numerosas.

Cara, na real mesmo, ter o espírito XP te faz um profissional melhor. Se a empresa não adota formalmente, você assumindo atitudes XP naturalmente te fará despontar na empresa onde você trabalha.

Ah, não consegui ver a relação dos testes com casos de uso. Também não vi como comparar CMM5 com XP, Scrum ou Crystal, que seja

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

Seguinte....
Quando estava falando da relação entre casos de uso (e não do diagrama de caso de uso) e testes unitários, estava falando sobre uma maneira rigorosa de levantar requisitos do sistema.

Acho joinha ter uma documentação do escopo do projeto isto é particularmente importante em contratos fechados onde o valor já está fechado mas os custos não.

Escrever testes unitários é uma forma de escrever requisitos do sistema (o que o sistema deve fazer, e não como).

Assim como nos processos tradicionais, nos processos ágeis a especificação vem antes da programação mas através de artefatos diferentes: story case e testes. O fato do XP (e outros processos ágeis) ser(em) interativo incremental não significa que processos tradicionais também não sejam (ex: RUP).

Uma questão difícil é: como é possível orçar um projeto grande usando processos interativos, incrementais e adaptativos como os processos ágeis? Será que isto é possível?

JavaBaby Membro desde: 22/08/2005 19:01:35 Mensagens: 94 Offline

Hum, boa pergunta. Eu não acho que isso seja possível com métodos ágeis. Aliás, eu não acho que isso seja possível.

O cone de incerteza é um fato da vida, que independe do processo de desenvolvimento. Meu entendimento é que a única diferença com o processo ágil é que você não tenta prever o futuro, então você limita a incerteza àquela de uma iteração.

Rodrigo, um teste unitário tem nenhuma relação com um caso de uso. O teste unitário verifica se o teu código faz aquilo que você quer, o caso de uso diz o que o cliente deseja que o sistema faça.

Seria possivel sim expecificar boa parte da documentação que processos tradicionais pedem em termos de testes funcionais, porém não é possivel se livrar de toda documentação.

Calcular o tamanho de um sistema dado que os casos de uso já existem é muito mais facil que com testes funcionais, que ninguém sabe se funcionam, pois eles ainda não tem um sistema para testar.

JavaEvangelist Membro desde: 09/10/2003 14:23:31 Mensagens: 379 Offline

Louds,

Pense aqui em testes de uma forma mais geral como uma especificação de testes de aceitação.

Acho que você, de certa forma, concorda que casos de uso e testes mantém estreita relação entre si. Ambos especificam o que o sistema deve fazer. Em cada caso de uso existe uma especificação implícita de um teste de aceitação (e talvez valha a recíproca).

Aliás: acho que não é possível implementar aquilo que não possa ser verificado (testado).

Como observado, um efeito de se especificar (a funcionalidade do sistema) em termos de testes é que ele pode ser refinado até chegar a uma "suite" de testes unitários que poderão verificar automaticamente o funcionamento do sistema.

Hum, boa pergunta. Eu não acho que isso seja possível com métodos ágeis. Aliás, eu não acho que isso seja possível.

Deixando de lado a discussão religiosa, acredito que SE é possível fazer estimativas sobre o tamanho de um sistema pela especificação de casos de uso, então também é possível fazer tais estimativas com a especificação de testes.

Calcular o tamanho de um sistema dado que os casos de uso já existem é muito mais facil que com testes funcionais, que ninguém sabe se funcionam, pois eles ainda não tem um sistema para testar.

ACHO que isto não faz muito sentido... Quando você escreve casos de uso, você não tem nenhum "sistema" para verificar se o que foi implementado está de acordo com o que foi escrito. A especificação não pressupõe implementação alguma. Idêntico à especificação por teste.

Trazendo de volta a discussão religiosa: acho que os métodos ágeis tem várias outras diferenças com os métodos tradicionais além do mero fato de preferir não fazer grandes estimativas. Uma delas é justamente a especificação de caso de uso, documentação totalmente ostensiva e supérflua uma vez que se tenha um bom teste de aceitação.

rodrigousp wrote:Louds,

Pense aqui em testes de uma forma mais geral como uma especificação de testes de aceitação.

Então pare de falar de testes unitários! Testes unitário tem ZERO de valor para definir se o sistema está adequado às necedidades do usuário. Testes unitários são uma ferramenta para o desenvolvedor produzir código de melhor qualidade apenas.

rodrigousp wrote:
Acho que você, de certa forma, concorda que casos de uso e testes mantém estreita relação entre si. Ambos especificam o que o sistema deve fazer. Em cada caso de uso existe uma especificação implícita de um teste de aceitação (e talvez valha a recíproca).

Aliás: acho que não é possível implementar aquilo que não possa ser verificado (testado).

Epa epa epa. Falo pela minha experiência com casos de uso e interação com o planejamento dos testes. Casos de uso definem em alto nível como o sistema funciona, mas de forma alguma definem os testes que devem ser executados. É necessário um analista de testes capacitado para projetar os testes necessários a um sistema.

Já ví isso acontecer muito, no qual o sistema é testado estritamente baseado nos casos de uso e a qualidade final ficou a desejar pois não preveram nenhum dos cenários não funcionais ou extrapolaram as variântes de cada cenário.

Quanto a não ser possivel implementar algo que não seja verificavel. Existe, com muito mais freqüência que você pode imaginar. Todo sistema que possui mais de um tier operam sob o princípio da incerteza de Heisenberg. Toda falha, e seu tratamento, em um sistema distribuído não é passivel de teste determinístico, não completo e correto, dado que não é factivel, ou até possivel, testar todas interações de falha que podem acontecer.

rodrigousp wrote:
Como observado, um efeito de se especificar (a funcionalidade do sistema) em termos de testes é que ele pode ser refinado até chegar a uma "suite" de testes unitários que poderão verificar automaticamente o funcionamento do sistema.

Testes precisam de algum alvo para serem úteis, posso não estar entendendo como você pretende especificar estes testes. Mas no final das contas especificar uma enorme quantidade de testes não vai ser simplesmente uma linearização do fluxo dos casos de uso ou user stories? Qual seria o ganho em linearizar tudo isso?

Documentação em excesso é tão ruim quanto falta de documentação. Cara, o maior problema de CMM é que os processos são rígidos e você acaba por não poder adaptar para suas necessidades. Você não pode dizer, por exemplo, que "serão escritos a visão, os casos de uso e, opcionalmente, demais documentos que a equipe julgar necessário".

Em projeto anterior meu, tinhamos apenas os casos de uso, a equipe de qualidade não conseguiu dar conta da carga cognitiva deles pois foram especificados com muitos termos do negócio. Criamos um glossário de termos. Depois disso reparamos que tinhamos um ENORME conjunto de invariantes e regras que todos casos de uso deveriam respeitar, então tiramos isso dos casos de uso e criamos um documento com estas invariantes e regras.

Metodologia agil preve também que o processo de documentação tem que ser dinâmico, customizavel, e feito em interações pequenas. Não queira produzir uma especificação enorme (mesmo que necessária) logo no início.

O fato é, em cada interação o processo tem que ser ajustado para ser mais eficiente que na anterior. Seja Lean.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

Métodos ágeis e RUP defendem uma abordagem ITERATIVA de projeto.

louds wrote:Metodologia agil preve também que o processo de documentação tem que ser dinâmico, customizavel, e feito em interações pequenas. Não queira produzir uma especificação enorme (mesmo que necessária) logo no início.

O fato é, em cada interação o processo tem que ser ajustado para ser mais eficiente que na anterior. Seja Lean.

Isso tem cara de "modelo espiral", não?

dreamspeaker wrote:

louds wrote:Metodologia agil preve também que o processo de documentação tem que ser dinâmico, customizavel, e feito em interações pequenas. Não queira produzir uma especificação enorme (mesmo que necessária) logo no início.

O fato é, em cada interação o processo tem que ser ajustado para ser mais eficiente que na anterior. Seja Lean.

Isso tem cara de "modelo espiral", não?

Processos iterativos e incrementais são uma instância do modelo espiral. A diferença principal, do que eu entendo, é usar um processo mais formal.

louds wrote:...A diferença principal, do que eu entendo, é usar um processo mais formal.

Talvez a "formalidade" seja uma palavra, não tenho certeza.

Eu fiz o comentário do modelo espiral porque eu tenho a impressão que, no fim, tudo é muito parecido. No RUP você também ouve muito falar de "processo iterativo e incremental", e não tem nada de ágil (no conceito de metodologia ágil).

Eu ainda acho que o diferencial de um projeto dar certo não está no processo, e sim nas pessoas.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

Dois tópicos bons e polêmicos sobre CMM e Agile Methods. Um na comunidade XP e outro na CMM.

http://www.orkut.com/CommMsgs.aspx?cmm=45580&tid=19772774

http://www.orkut.com/CommMsgs.aspx?cmm=38240&tid=2432506164619479527

Quem contrata uma empresa que usa XP, pensa na qualidade e, ainda, paga por UM SERVIÇO, não por UM PRODUTO.

De qualquer modo, quanto aos prazos, planejamento, etc.. Deve-se perceber que a relação com o cliente é outra! Existe um bom senso, claro, mas se teu cliente tá acompanhando o andamento do projeto, recebendo releases funcionais constantemente, está sempre conversando e adaptando o que foi definido no início, etc. Ele estará muito mais propenso a elastecer o prazo de entrega(caso esteja bem definido). É muito normal iniciar um projeto e, ao chegar no fim, o cliente ver que não era bem isso. Quem paga o pato ($$) ? A empresa? Ou deixamos o cliente insatisfeito, um fod@-se literalmente?!!

Quem contrata empresas com tal metodologia deve ter isso em mente.

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

seufagner wrote:Quem contrata uma empresa que usa XP, pensa na qualidade e, ainda, paga por UM SERVIÇO, não por UM PRODUTO.

De qualquer modo, quanto aos prazos, planejamento, etc.. Deve-se perceber que a relação com o cliente é outra! Existe um bom senso, claro, mas se teu cliente tá acompanhando o andamento do projeto, recebendo releases funcionais constantemente, está sempre conversando e adaptando o que foi definido no início, etc. Ele estará muito mais propenso a elastecer o prazo de entrega(caso esteja bem definido). É muito normal iniciar um projeto e, ao chegar no fim, o cliente ver que não era bem isso. Quem paga o pato ($$) ? A empresa? Ou deixamos o cliente insatisfeito, um fod@-se literalmente?!!

Quem contrata empresas com tal metodologia deve ter isso em mente.

Sim.

Tem mais esse ("Contrato de escopo variável"):

http://www.orkut.com/CommMsgs.aspx?cmm=45580&tid=2459245739803377491

This message was edited 1 time. Last update was at 24/11/2007 00:32:27

Primeiramente, valeu a todos pelos comentários.

Segundo ... deixei para responder isso com a cabeça mais fria...

louds wrote:
Então pare de falar de testes unitários! Testes unitário tem ZERO de valor para definir se o sistema está adequado às necedidades do usuário. Testes unitários são uma ferramenta para o desenvolvedor produzir código de melhor qualidade apenas.

Bom, estava pensando em escrever ou esmiuçar a especificação do sistema utilizando arcabouços de testes unitários...
Relendo os meus dois primeiros posts, acho que eu tentei explicar mais ou menos isso:

O caso de uso diz o que o sistema deveria fazer.
o teste verifica se o sistema faz aquilo que ele deveria fazer. Bom, então de alguma forma, o teste diz aquilo que o sistema deveria fazer. Por transitividade ele também faz o que o caso de uso se propõe a fazer. ;)

louds wrote:
Epa epa epa. Falo pela minha experiência com casos de uso e interação com o planejamento dos testes. Casos de uso definem em alto nível como o sistema funciona, mas de forma alguma definem os testes que devem ser executados. É necessário um analista de testes capacitado para projetar os testes necessários a um sistema.

100% verdade.. Escrever testes é realmente mais "complicado" do que escrever casos de uso. Eu estava imaginando um cara capacitado para redigir os testes de aceitação de acordo com a histórinha do usuário. Talvez usando algo como fitnesse:
http://fitnesse.org/
Por outro lado, é possível escrever testes para muitos requisitos não funcionais. Mas eu repenso no que eu disse.... Requisitos de usabilidade, por exemplo, seriam difíceis, senão impossíveis, de serem codificados em testes. Mesmo assim, eu considero os testes uma excelente ferramenta para especificação de requisitos (quando aplicáveis... mesmo para casos não determinísticos ou que não seja possível testar todas interações de falha _ aplique-se aceitação por freqüência se for o caso).

louds wrote:
Testes precisam de algum alvo para serem úteis, posso não estar entendendo como você pretende especificar estes testes. Mas no final das contas especificar uma enorme quantidade de testes não vai ser simplesmente uma linearização do fluxo dos casos de uso ou user stories? Qual seria o ganho em linearizar tudo isso?

1) Ao invés de ter uma especificação que simplesmente descreve o sistema, a especificação que eu propus verifica o sistema. Isso cria uma "relação bem direta" entre aquilo que foi desenvolvido e aquilo que foi requisitado (entre outras coisas, ajuda manter a sincronia entre a doc e código).
2) Pode eliminar um passo desnecessário (seja a descrição das especificações por si, seja um teste de aceitação que não seja a especificação do sistema).
3) Acho que não é tão custoso "escrever" os testes com ferramentas como o fitnesse e o selenium.

louds wrote:
Metodologia agil preve também que o processo de documentação tem que ser dinâmico, customizavel, e feito em interações pequenas. Não queira produzir uma especificação enorme (mesmo que necessária) logo no início.
O fato é, em cada interação o processo tem que ser ajustado para ser mais eficiente que na anterior. Seja Lean.

Concordo completamente. Acho que seria possível transformar ou refinar uma especificação em testes iterativamente. Mas acho legal imaginar que a especificação será escrita com o cuidado para que possa verificar o funcionamento do sistema. Além disso, mesmo as metodologias tradicionais não descartam o desenvolvimento iterativo.

Adicionalmente, acho que várias ferramentas que temos hoje podem ser utilizadas na resolução de problemas que complicados processos de desenvolvimento se propõe a resolver. Ex:
Rastreabilidade : utilizar controle de versão como subversion. Emails também são ferramentas incríveis para apontar quem solicitou o que.
Especificação de requisitos: utilizar testes (especialmente de aceitação) e arcabouços como fitnesse,selenium, junit, etc.
e assim por diante.

Notícias, artigos e o maior fórum brasileiro sobre Java