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)?
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?
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.
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.
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.
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.
Pense aqui em testes de uma forma mais geral como uma especificação de testes de aceitação.
[/quote]
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.
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.
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.
[quote=louds]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. [/quote]
[quote=dreamspeaker][quote=louds]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. [/quote]
Isso tem cara de “modelo espiral”, não?[/quote]
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.
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.
[quote=seufagner]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.[/quote]
Segundo … deixei para responder isso com a cabeça mais fria…
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.
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).
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).
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).
Acho que não é tão custoso “escrever” os testes com ferramentas como o fitnesse e o selenium.
[quote=louds]
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. [/quote]
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.
[quote=seufagner]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.[/quote]
Bom, acho que podemos e devemos competir com empresas que vendem produtos (e não apenas serviços).
Acho que é legal, para o acionista da empresa, ter a estimativa do custo de um projeto (mesmo que seja em ordem de grandeza). As metodologias tradicionais utilizam a especificação de requisitos para fazer tais estimativas. Mas fazem do jeito delas (caso de uso, etc). Não considero isso nem de longe a maneira mais eficiente (ou precisa) de fazer estimativas.
Não acho que devemos abandonar todas práticas ágeis porque queremos algum tipo de estimativa!
Sei que quem usa as metodologias ágeis vendem PRODUTOS e não serviços. Clientes de software nunca estão interessados em adquirir SERVIÇOS e sim PRODUTOS. O cara te contrata para que você entregue um sistema funcionando e um sistema é um produto.
MAs voltando à questão de Agile com CMM, isso é muito possível sim. A powerlogic, empresa baseada em OpenSource 2.0 utiliza Scrum e conseguiu certificação em MpsBR. Aliás, a Isabella que foi uma das pessoas responsáveis pelo processo de certificação escreveu um artigo que sairá na revista visão ágil agora no início de Dezembro. Acho que vai ajudar bastante nessa questão.
Vale lembrar que o CMM não apenas exige comprovação de qualidade do software como no caso dos testes e sim todo um workflow definido e bem etruturado, combrindo possíveis brechas para bad smells no projeto.
Eu tenho a impressão de que os maiores obstáculos para integrar metodologias ágeis e CMM não são procedurais, e sim culturais e mercadológicos. O cliente que procura uma consultoria com CMM(i) 5 quer um processo de engenharia de software padrão, bem definido, com requisitos entrando de um lado e software saindo do outro. Ele não quer se preocupar se a fábrica de software fica na Birmânia ou na Patagônia, ou se emprega cérebros super-inteligentes em soluções eletrolíticas ou macacos treinados. O selo CMM 5 é a garantia que vai sair software do outro lado nas condições estipuladas.
O cliente que fecha um projeto com uma metodologia ágil, por outro lado, é mais aventureiro. Pra começar, porque em vez de mandar uma RFP e receber uma estimativa de “9 meses, 370 mil reais”, ele trabalha num nível muito maior de imprecisão no começo. Um projeto ágil exige muito mais interação com o cliente, e de novo pode não ser o que alguém que compra uma solução de outsourcing está procurando.
Agora, quanto a outra discussão que se formou, minha posição é que testes não substituem de maneira alguma casos de uso. Casos de uso são ideais para a especificação funcional, porque contam uma história em vez de serem um apanhado de pré e pós condições sem um fio condutor. Unit tests podem ser a especificação técnica, se escritos com esse fim em mente. (e aí BDD e os *Spec ajudam bastante)
Bem, até onde eu sei, os clientes que procuram empresas que utilizam desenvolvimento Ágil também querem funcionalidades entrando de um lado e software saindo de outro (constantemente). Além disso, o processo de desenvolvimento de software Ágil é bem definido, a diferença é que ele não é estático, ele está melhorando continuamente.
O selo é garantia que o software vai sair na condições estipuladas… mas qualquer necessidade fora das estipuladas, não serão garantidas.
Aventureiro é boa
A maior parte dos clientes não gosta de gastar dinheiro em projetos “aventureiros”…
Além disso, porque um projeto Ágil não fornece uma estimativa de “9 meses e 370 mil reais” ? Nem todo projeto Ágil é feito com escopo aberto (IMHO, somente a minoria é). Desenvolvimento Ágil não encontra nenhum problema em estimar e definir um preço e um prazo para um projeto.
E sobre a imprecisão… tem muito projeto preciso por aí que está completamente perdido.
Terminando, as empresas que costumam se adaptar melhor ao desenvolvimento Ágil, são as empresas CMMi nível 5, elas já estão no patamar de melhoria contínua.
A diferença é que o cliente de outsourcing que paga por uma consultoria CMM 5 quer uma caixa preta, e não é isso que, por definição, ele tem num processo ágil. Se você não tem o envolvimento constante do cliente, então não pode dizer que o seu processo é ágil.
O selo é garantia que o software vai sair na condições estipuladas… mas qualquer necessidade fora das estipuladas, não serão garantidas.[/quote]
A bem da verdade, o selo não é nem isso. Ele é como o selo do Ministério da Saúde no seu pacote de salsichas ou na caixinha de leite, um motivo reconfortante para não se preocupar como as coisas são feitas e assumir que estão sendo feitas com um mínimo de qualidade. Só que a verificação é feita periodicamente e por amostragem, e nessas você toma leite com água oxigenada e soda cáustica sem saber.
[quote=mueller]Aventureiro é boa
A maior parte dos clientes não gosta de gastar dinheiro em projetos “aventureiros”… [/quote]
Ok, não foi uma boa escolha de palavra. O que eu quis dizer é que por mais que ágil tenha se tornado uma buzzword, os princípios por trás das metodologias ágeis ainda não são bem difundidos no mercado, então um cliente conservador não vai topar. Aliás, grandes clientes têm suas próprias metodologias, e se você não produz a documentação que eles pedem, não chega nem a concorrer.
Agora, concordo completamente com você quando diz que números precisos não são de maneira alguma necessariamente exatos. Se uma empresa faz uma oferta fixa desse tipo, ou está aceitando um risco calculado, ou está demonstrando que ninguém ali tem a menor idéia do que está fazendo. Esperamos que com CMM 5 trate-se do primeiro caso.
Para terminar, uma idéia que eu deixei de fora do meu primeiro post é essa: eu não vejo esses dois mundos se encontrando tão cedo, porque a ideologia por trás dos dois é completamente oposta. A resposta do movimento de Engenharia de Software para o aumento da complexidade dos projetos é tirar o foco em “heróis”, porque heroísmo não funciona em escala, e criar processos que permitam que uma equipe de 50, 100 pessoas continuem funcionando. A resposta dos movimentos ágeis é quebrar o projeto em ciclos de cerca de um mês, para evitar o overhead de comunicação que um time grande traz.
É verdade. Isso acontece com certeza numa como Petrobras onde se exige que você preencha os documentos do processo dela e inclusive as tarefas de qualidade. Se brincar, exige até que você use os frameworks e classes reutilizáveis dela em dentrimento dos seus.
Não é fácil trabalhar com licitações, embora sejam grandes fontes de renda para empresas de software.
E algumas certezas que tenho: o selo CMMi5 não garante que as funcionalidades contratadas serão entregues no prazo e no custo combinados. Trabalhei numa empresa CMMi5 e eram (ainda são) muito comuns as famosas reuniões para “renegociação de prazo”, “renegociação de escopo” ou “renegociação de custo”. Além disso desagradar demais o cliente, tem que mandar o(s) dono(s) da empresa para reunião. Ao invés dos caras ficarem trabalhando em planos estratégicos e novos negócios para a empresa (tarefas nas quais eles são muito bons, diga-se de passagem) eles têm que perder tempo perdendo os clientes (ou cedendo e arcando com o prejuízo).
Não? Prometa (e cumpra, logicamente) prazos, custos e esforços menores pra ver se ele não topa e beija seus pés. Ofereça a ele time-to-market, ROI, liberdade para mudar de idéia, qualidade, manutebilidade, etc pra ver se ele não solta fogos quando você chegar na empresa dele. Não que isso seja impossível com processos e metodologias engessadas, mas é que é bem mais natural com as ágeis. E não estou querendo dizer de maneira alguma que acho tudo isso uma tarefa fácil; muito pelo contrário. É trabalhoso e pode dar errado se a empresa não estiver preparada. Não tem nada de aventureiro na adoção de metodologias ágeis (muito pelo contrário). Eu estou sentindo isso na pele, agora que estou só tentando falar e disseminar metodologias ágeis aqui na minha empresa (conservadora e tradicionalista).
Acho que aqui as metodologias ágeis ganham ponto. Elas se adaptam, você pode mudar, não está engessado por um monte de burocracias. Coloque no seu processo de desenvolvimento as necessidades do cliente, ora…
Será que é isso mesmo que ele quer? Na minha opinião, na maioria das vezes eles têm um problema e procuram uma solução. A única certeza que eles têm é do problema e não da solução. Acho que um dos papéis principais das empresas de software é ajudar o cliente na busca da solução para os seus problemas. E existe melhor maneira de fazer isso do que aos poucos, mostrando pra ele alguma coisa funcional e recebendo o feedback rapidamente? Ou você acha melhor mostrar tudo daqui a 2 anos e ver que todo o seu trabalho não ajudou o seu cliente em nada?
E sobre o envolvimento do cliente: cara, eu acho que ele está sim muito interessado em acompanhar o projeto. Você investiria R$100K na reforma da sua casa pra ver só daqui a 6 meses? Ou iria toda semana lá pra ver se está do jeito que você quer? Ninguém (a não ser gente doida) gosta de rasgar dinheiro. Se você criar mecanismos de envolvimento do cliente no seu projeto ele vai gostar e participar, pode ter certeza.
Ah… mas na XP é necessário ter o cliente dentro da equipe, o tempo todo. E agora?? Bom, no Scrum existe o papel do Product Owner. Se você só pode usar XP, porque não adaptar e criar uma figura parecida com a do Product Owner no seu time XP? É adaptativo, você pode fazer isso. Você tem liberdade pra customizar e melhorar. Quer coisa melhor?? Ainda não conheço…
