Suportar essa caracteristica de nao poder atualizar o sw, concordo que é uma situção diferente do “normal” mas processos podem ser estendidos para atender suas necessidades, dizer que agile nao funciona aqui é desconsiderar varios outros principios que ainda seriam util para o desenvolvimento como todo.
[quote=ViniGodoy]
Ainda não vejo como aplicar métodos ágeis quando o custo de modificar fica exponencialmente mais alto a medida que o produto final aproxima-se do cliente. Embora essa já tenha deixado de ser a realidade da maior parte dos softwares, esse certamente não é o nosso caso, por todos os motivos já citados. Já citando o próprio Kent Beck, no seu livro Extreme Programming Explained: “It is the technical premise of XP. If the cost of change rose slowly over time, you would act completely differently from how you do under the assumption that costs rise exponentially.”
O mesmo foi repetido pelo Craig Larmann numa palestra que ele deu na Nokia Siemens, falando de Agile no geral.
Torno a repetir: Eu não sou contra processos ágeis. E aliás, não só sou completamente a favor como também me empenhei para que ele fosse implantado onde trabalho. Também creio que haja muito mais potencial para ele dentro das empresas, especialmente as grandes. Reconheço que ele é adequado para a absurda maioria dos softwares atuais, especialmente aqueles desenvolvidos no comércio (grandes ou não). No nosso caso, acho que muitos setores ainda poderiam se beneficiar de um método ágil. Mas não creio que ele seja a solução para todos os problemas de TI.[/quote]
Nao é facil introduzir Agile numa organizacao justamente pelo fato de nao haver one-size-fits-all e como disse o Phillip agile nao é velocidade. Se algumas coisas precisam ser de um jeito sera que essa coisa inviabiliza estar sob a influencia do paradigma agil?
Se essa coisa é não poder atualizar o software no cliente eu diria que ainda vale muito a pena agora se estamos falando em equipes de 30 programadores aí nao há como suportar devido ao overhead de comunicacao.
[quote=pcalcado]
Acho que o ponto aqui é ailidade como o que foi definido pleo manifesto ágil, não sobre velocidade. Ainda assim, alternativas de Model Driven Design não dependem de uma linguagem especifica, Microsoft DSL Tools, Metacase, Jetbrains MPS e outros métodos são alternativas. Segundo alguns defensores de MDA nem mesmo este padrão depende de UML -o que eu não concordo.[/quote]
E sendo UML uma GPL é necessário alterar o código gerado para implementar o que nao foi capturado na linguagem de modelagem. Como isso é suportado pelo MDA sem inviabilizar o processo? Esse é o problema que LOP pretende resolver?
Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa.
[/quote]
Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.
Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido. [/quote]
Quando você fala “Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML.”… eu concordo com isso.
Não gosto muito de fazer casos de uso porque tenho a mania de colocar muitos casos de uso no sistema. Não sei se é um problema de iniciante, mas tenho que corrigir isso urgentemente.
Não sou engenheiro (ainda), mas eu usaria casos de uso quando o funcionamento da empresa estivesse complicado de entender. Seria correto fazer isso?
Concordo em grau, número e gênero. É similiar ao diploma: alguns não tem e dão um cacet* em quem tem.
Mesmo quando a UML deixa as coisas mais claras entre os desenvolvedores?
Estou gostando da discussão… aprendo bastante com grandes nomes aqui do Forum.
Abraço.
O último projeto que participei com Casos de Usos era para refazer o sistema das lojas de uma Telco. Isso é complicado? Depois que uma 3 letrinhas foi expulsa do projeto, o pessoal ficou 2 meses tentando “fechar” os 54 Casos de Usos (idéia maldita de outro fornecedor de 3 letrinhas) com os usuários e tivemos 1 semana para fazer o protótipo com o agravante os Casos de Usos estavam muito mal escritos e só criavam “bate-cabeça”. Isso é complicado!!!
A saída foi criar um mapa de navegação (Diagrama de Estados) do projeto para que a equipe pudesse captar a essência do projeto e detectar pontos de sobreposição e oportunidades de reuso.
Ahhh, e CASOS DE USOS SÃO BEM DIFERENTES DE ESTÓRIAS.
Ministrei um treinamento numa empresa que faz o software das centrais telefônicas da Ericsson. O fato é que nesses ambientes o nível de incerteza é menor: requisitos estáveis e arquitetura estática. Esse tipo de software tem uma grande porcentagem de sucesso usando Waterfall (mas sempre tem aquela correria no fim do projeto). Porém, creio que eles também poderiam se beneficiar muito de um modelo iterativo.
De fato o modelo MDA não presume o uso da UML, porém, por força do mercado, a transformação de modelos das ferramentas que temos hoje se baseiam na UML. De qualquer forma, não creio que só a UML seja suficiente para uma transformação eficiente.
A questão é que o custo de manutenção de um modelo não vale a pena. Geralmente usamos a UML para discutir dentro da equipe. Esses diagramas na maioria das vezes são feitos no papel e depois que as coisas “ficaram claras” o diagrama vai pro lixo.
Eu também uso a UML na concepção ágil. Também são diagramas feitos no papel e servem para que fique claro o tamanho funcional do software, aliado a histórias (também conhecidas como Casos de Uso - tinha que dar o troco né Taz :lol: ) capturadas em Index Cards e também protótipos visuais.
[quote=rodrigoy]
De fato o modelo MDA não presume o uso da UML, porém, por força do mercado, a transformação de modelos das ferramentas que temos hoje se baseiam na UML. De qualquer forma, não creio que só a UML seja suficiente para uma transformação eficiente.[/quote]
Alguns slides de workshops e outros treinamentos de MDA que eu li recomendam inclusive a criação de um metamodelo intermediario antes do produto final da transformação, para que o processo de transformação não se prenda a um metamodelo especifico.
Se, HOJE, todo mundo chama de estória, pq ser diferente?
Sim, “UC (Use Case) é mais antigo que a UML”. Mas, HOJE, OFICIALMENTE, UC faz parte da UML e é aquilo que está definido na OMG (http://www.omg.org/docs/formal/07-11-02.pdf). Que tal chamarmos de UC o que HOJE, OFICIALMENTE, entende-se como UC!?
Ou vc não ensina para seus pupilos que uma linguagem de domínio não deve ter ambiguidade? Veja que esse tipo de discussão é completamente relevante seja quando falamos de um domínio de negócio, seja quando falamos de processos de software!!
E torna-se ainda mais relevante pq estamos discutindo a utilidade ou não de uma ferramenta em detrimento de outra. Acho que vc não quer admitir que UCs já morreram (saudosismo!?) e chama de “light UC” o que deveria chamar de user story.
Já te falei que a especificação da UML não entra no mérito da narrativa, a parte que você reclama da formalidade (acredite eu conheço um pouquinho dessa especificação). Posso usar UC sem usar o diagrama. A questão é que talvez histórias juntem objetivos dos usuários a features simples, o que não acontece com casos de uso.
Vai falar isso para o Kent Beck!!! Casos de Uso são mais antigos que histórias também!
UCs já morreram?! De onde você tirou essa? Praticamente 90% das empresas que tenho contato usam UCs. Taz, pra mim não interessa o nome. Os dois tem o mesmo objetivo. Se eu gerencio usando Index Cards o que consta nos cartões são funcionalidades que agregam valor aos usuários. Mais uma vez: não vejo diferenças entre UCs e Stories porque UCs não precisam ser formais. A questão não é saudosismo. Pra mim é não se render a essas modinhas. O conceito foi cunhado pelo Jacobson e precisamos dar mérito.
Já te falei que a especificação da UML não entra no mérito da narrativa …
[/quote]
E o que quer dizer isso?
UML - Guia do Usuário (Jacobson, Booch, Rumbaugh) (em português) -pág 222:
quote Você pode especificar o comportamento de um UC pela descrição do fluxo de eventos no texto de maneira suficientemente clara para que alguém de fora possa compreendê-lo facilmente. Ao escrever o fluxo de eventos, você deverá incluir como e quando o UC inicia e termina, quando o UC interage com atores e quais objetos são transferidos e o fluxo básico e fluxo alternativo do comportamento.
Por exemplo, no contexto de um sistema de caixa eletrônico, você poderá descrever o UC ValidateUser da seguinte maneira:
UML - Guia do Usuário (Jacobson, Booch, Rumbaugh) (em português) -pág 222:
(…) Você pode especificar o comportamento de um UC pela descrição do fluxo de eventos[/quote]
Quer dizer que você PODE e não que DEVE SEMPRE usar descrição do fluxo. Infelizmente não estou com meu livro aqui, mas tanto o Jacobson, o Larman e o Cockburn dizem que uma breve descrição pode ser suficiente para um caso de uso.
Não olhe para o conceito do jeito que o mercado aplica. Já ví caso de uso com 167 páginas. Já ví 16 horas para escrita de um caso de uso num cronograma. Não se anime tanto que com as histórias não vai ser diferente. Daqui a pouco teremos templates para escrita de histórias com papel cartão e “campinhos” obrigatórios para preencher com folha de horas anexa.
Amigos, sei que isso não é exatamente o que o tópico trata, mas como citei sobre o assunto neste tópico, escreví sobre esse tal desgraçado ganancioso no meu blog:
Eu encaro o que foi escrito no livro como uma FORTE SUGESTÃO, assim como o “mercado”. Isso é algo parecido com “Se é pra usar UC, faça dessa maneira…”. Mas obviamente, pessoas diferentes podem achar interpretações mais convenientes para as palavras.
[quote=rodrigoy] Daqui a pouco teremos templates para escrita de histórias com papel cartão e “campinhos” obrigatórios para preencher com folha de horas anexa.
[/quote]
Isso parece com algum “template” que contém “campinhos obrigatórios para preencher com folha de horas anexa”? Ou com Casos de Usos de 200 páginas?
Taz, concordo com você que especificar requisitos em artefatos fora do código não é uma boa idéia (ao menos que esses artefatos sejam executáveis como o FIT). Aliás, vejo uma forte tendência para especificar requisitos usando essas ferramentas no lugar dos próprios cards.
Não concordo com seus exemplos pois são projetos internos de tecnologia (frameworks). Nesse tipo de projeto o gap de entendimento é praticamente zero. Além disso, nada me impede de especificar uma história de maneira mais formal também se necessário.
Será que só empresas que desenvolvem frameworks utilizam ferramentas como Jira/Trac/Bugzilla?
Como assim “gap de entendimento”? Explique melhor. IMHO, seja software comercial, seja framework, tudo no fim das contas é software e possui a mesma dinâmica.
Hoje eu uso Trac e sou feliz por me ver livre dos UCs. E é por isso que vc percebe uma tendência na direção de ferramentas de issue tracking.
Eu uso o Trac. Apesar de ser raro às vezes escrevo casos de uso lá em reuniões com o cliente.
Quando alguém abre um bug no Hibernate e cita “Criteria API” tanto o cara que abre o bug como o cara que vai pegar o bug sabe o que é isso. O dia que você pegar uma história ou UC que citar algo como “Puncão de Port - a - cath” você saberá o que é GAP de entendimento. Iria ser muito fácil desenvolver software se tudo possui a mesma dinâmica. Esse software da Punção, se você era um perfil etário numa infusão não é um bug, talvez algumas criancinhas morram. Construir prédio possui tudo a mesma dinâmica. Construir software não.
Exatamente!!! Vc acaba de provar que A DINÂMICA É A MESMA. O “gap de entendimento” existe para um projeto que usa Hibernate ou para um projeto que usa o conceito de “Punção não sei das quantas”. Eu levaria uma ou duas semanas (será?) para entender a terminologia de um sistema hospitalar, assim como uma pessoa que nunca trabalhou com Hibernate demoraria uma ou duas semanas (será?) para entender o que é Criteria e dominar a terminologia . Depois de algum tempo em contato com a terminologia da aplicação e do framework o desenvolvedor pode tanto entender o que o significa uma “Punção de try-catch” no ticket #200 como pode abrir novas requisições de melhorias para equipe do Hibernate.
