| Autor |
Mensagem |
|
|
Opa Junior, sempre que possível, e tendo um tempinho, a gente procura ajudar! 
Sobre as suas dúvidas:
1 - aopalliance.jar o spring usa para aop. Quando subi aqui, simplesmente deu class not found e eu adicionei, se não te fez falta não tem problema, se for necessário você vai saber rapidamente.
2 - o meu exemplo usa o maven, como você não usa, achei importante apontar essa diferença.
3 - Aqui tenho duas observações importantes:
A primeira é que você não deve injetar o objeto diretamente na classe, pois o Spring simplesmente injeta o valor do campo passando por cima de qualquer outra prática ou princípio, o que dificultaria um teste unitário. Use o construtor, essa é a forma mais adequada, pois assim fica evidente que a classe depende do dao, garantindo programaticamente que ela não possa ser instanciada sem ele. O erro é dado por causa disso também.
A segunda é que você não deve ter uma referência à implementação na sua classe, mas à interface. Ao invés de HibernateUsuarioDao mantenha a referência a UsuarioDao:
Dessa forma, o design da sua classe fica muito melhor!
Qualquer dúvida é só perguntar!
Flw! 
|
 |
|
|
Oi juniordocpd, baixei sua sua aplicação pra ver e encontrei alguns pequenos erros:
- No applicationConfig.xml faltam os class dos beans dataSource e sessionFactory.
- Pela estrutura do seu projeto, o configLocation da sessionFactory deve ser WEB-INF/hibernate.cfg.xml.
- O HibernateUsuarioDao não deve estar no xml, não é necessário para as classes anotadas.
- Faltam os jars spring-jdbc-3.0.6.jar e aopalliance-1.0.jar
Como já fiz aqui, segue o applicationContext.xml alterado:
Feito isso, vai funcionar!
Blz? Flw!
|
|
|
|
"Várias" é dificil de acreditar, ou você se refere à empresas sem cmmi, iso, etc. Já trabalhou para algum banco? Nada nunca muda.
O modelo hierárquico é baseado no medo, pois se você contraria um superior pode ser mandado pra rua. Quem lida muito com o medo, acaba sofrendo muito com ele, de forma que os processos burocráticos se tornam uma "proteção" para essas pessoas.
Modelo "tradicional" nem existe na literatura, mas ficou difundido dessa forma. Acaba sendo usado para se referir ao comando-controle.
|
|
|
|
|
@marcosalex você conhece alguma empresa que segue um modelo de hierarquia tradicional que estabeleceu seus processos, e que permite mudanças constantes neles?
|
|
|
|
YvGa wrote:O problema nao esta no avaliador, a empresa cumpriu exatamente aquilo que se propos a cumprir. O problema esta no modelo de avaliacao que nao gatante nada.
Eu concordo. Trabalhei em uma empresa que tinha certificação iso, mas nunca vi nenhuma melhoria vinda daí. Só duas coisas mudaram: passamos a preencher mais documentos, e passaram a "disseminar o conhecimento" usando um sistema colocando uns documentos que ninguém lia.
@felipefranz aqui aponto novamente o tópico pessoas mais que processos, pois esse processo de "disseminação do conhecimento" não funciona, não é assim que as pessoas aprendem.
felipefranz wrote:A métrica não é feita para você, é feita para quem toma decisão, para ele é importante saber se o projeto está só 40% pronto quando deveria estar 70% para poder tomar alguma ação, não tem a haver com as funcionalidades, tem mais a haver com a gestão de portfólio, que está diretamente ligada a mercado e dinheiro, e é fonte de informação para o dono do negócio.
Discutimos isso antes, então aproveito pra te perguntar: uma equipe precisa de alguém não poderia tomar essa ação? Ela tem conhecimento do andamento melhor do que qualquer um, não poderia então ser ela a passar essas informações para o dono do negócio?
[quote=YvGa wrote:]Ops, um leve indicio do velho conceito "peao nao sabe de nada" aqui?
Eu nao disse nada contra a metrica, eu nao sou contra a metrica. Em nenhum momento eu disse que ninguem precisa saber o quanto do projeto esta pronto. O que eu disse foi que a unica metrica confiavel que existe em desenvolvimento de software é software funcionando. Se voce nao ve software funcionando, aquele monte de papel dizendo que tem 40 ou 90% prontos nao serve pra nada.
Se voce acredita quando um desenvolvedor te fala que o projeto esta 50% pronto e toma decisoes baseadas nisso (seja la de que forma ele te disser, falando, por email, ou por um milhao de fontes de dados de origens diferentes todas convergindo num relatorio maravilhoso), voce muito provavelmente vai tomar decisoes erradas.
So software funcionando te da nocao do que esta pronto e do que nao esta. Qualquer outra forma de medir cedo ou tarde vai cobrar seu preco.
Ao meu ver, as métricas de uma equipe só podem se basear no que a equipe já realizou, não no que ela "previu" que poderia fazer, então você consegue medir como a equipe anda após algumas iterações, apenas considerando como ela foi nas anteriores.
|
|
|
|
felipefranz wrote:Mas isto é bastante óbvio, já que são as pessoas que usam as ferramentas e os processos. Mas uma empresa deveria se preocupar em ter bons processos e tecnologia também, quando eu digo que o pilar é formado pelos três é o cenário ideal, na maior parte das empresas são as pessoas que tem que cobrir tudo.
Mas o problema é que na maioria das vezes é estabelecido um processo rígido que deve ser seguido à risca, e isso por si só se torna problemático, pois acaba que as pessoas tem de se encaixar nos papéis do processo, quando ele deveria ser uma ferramenta para ajudar as pessoas. Sem contar que um processo engessado não é "alterável" (e quando é, demora eras), o que impede sugestões para melhorias, tentativas e experimentações, já que essas estão fora do processo.
Talvez você me diga que onde trabalha o processo seja possivelmente alterado, mas quando é o caso, quanto tempo demora para isso acontecer? Um processo assim geralmente leva muito tempo para ser estabelecido, e não sei se as pessoas que o conceberam o vêem como um filho ou como "a solução perfeita" que custou uma fortuna, pq muitas delas não querem que ele seja mudado. Eu vejo um processo assim como um elefante branco.
|
|
|
|
felipefranz wrote:Com certeza, sempre bom poder conversar com quem tenha uma visão diferente. Vou mandar e-mail por mensagem privada.
Fico aguardando! 
|
|
|
|
marcosalex wrote:Errado, pessoas são parte do processo. Querer separar os dois é uma distorção que você está fazendo, e que agile ou não-agile não defendem isso.
Dá uma olhada no http://agilemanifesto.org/ e você vai ver como primeiro valor: Individuals and interactions over processes and tools, o que quer dizer que as pessoas e as interações entre elas são mais importantes do que processos e ferramentas. Se não estiver claro o suficiente, é só falar.
|
|
|
|
@felipefranz ... especialmente porque isto normalmente significa redução de salário ...
Essa é outra grande diferença entre o gerente e o SM - e que de mais uma forma, afasta o gerente do time. E se torna um problema sério quando o gerente não ajuda e só cobra, por ganhar mais e não fazer nada.
Entendo que seja preciso alguem que faça alguns serviços mais burocráticos, mas usando um dos exemplos que você deu, eu creio que a equipe deve ser responsável por selecionar novos membros (selecionar, não fazer os trâmites da contratação). Não faz sentido o gerente selecionar é mais adequado para trabalhar com aquela equipe, quando a própria sabe melhor do que ele que tipo de talento eles precisam.
Quando você diz questões gerenciais, quais você acha que uma equipe ágil não daria conta sem um gerente? As que você disse que precisam de conhecimentos e habilidades específicas?
@marcosalex a discussão é sobre uma possível forma de trabalho e se é possível alcançá-la. Todos sabemos como são as coisas hoje, e tudo o que você levantou são os pontos que o Agile foi concebido para combater. Claro que não funciona para todos, e mesmo métodos ageis falham, mas se ninguém tentar mudar, tudo o que está errado permanece.
@felipefranz Isto me lembra aquela velha máxima de que toda metodologia é composta por processos, pessoas e tecnologia, quanto pior uma estiver as outras terão mais trabalho para garantir a entrega do projeto. Se você não tem processos bem definidos, você está colocando tudo na mão das pessoas e da tecnologia. Aí vem aquela velha história da dependência dos heróis que sustentam a empresa nos ombros.
O processo serve justamente para salvaguardar a pessoa em momentos de tensão e pressão do cliente, se a empresa cede o processo em virtude da pressão, ou a metodolgia não está funcionando por disfunção burocrática e neste caso devem ser feitos ajustes ou a empresa não tem maturidade para seguir uma metodologia.
Acho que temos visões completamente opostas sobre esse ponto. A primeira "lei" de Agile diz que pessoas são mais importantes do que processos, e repare que desde que começamos a discussão eu defendo esse lado. Esse seu ultimo post, me leva a crer que a empresa onde você trabalha é bastante conservadora e deve seguir métodos bastante rígidos, e se for isso mesmo, entendo como e porque defende esse lado. Eu levaria muito tempo escrevendo sobre o que penso sobre isso, então te convido a conversarmos sobre isso por email, acho que temos muito a aprender um com o outro.
|
|
|
|
@felipefranz, então você tem uma visão semelhante a minha quanto ao gerente, mas concorda que falando de "gerentes tradicionais" essa é uma raridade? A própria estrutura hierárquica não permite que o gerente esteja lado a lado da equipe 100% do tempo. Repare que o problema é o controle, não um líder. E isso leva à uma indicação clara da diferença entre o SM e o gerente: você conhece algum gerente que foi "eleito" para o papel de líder pela própria equipe?
Sobre os demais afazeres do gerente que você citou, não há porque a comunicação com o cliente não ser feita pelo próprio time, incluindo os assuntos financeiros (trabalho do Product Owner, que também é parte do time), então o time não precisa do gerente fazendo o papel de intermediário.
Entendo que nossa discussão aqui não vai fazer as empresas mudarem sua estrutura da noite para o dia, mas podemos levantar: esse modelo hierárquico baseado em comando controle é uma boa opção? Pra quem? Como você disse, ele vem de muitos anos atrás, mas será esse o melhor modelo? Até quando? É complicado conceber um modelo muito diferente ao qual estamos acostumados, mas quando ele começa a incomodar, levantamos possibilidades que ontem eram inconcebíveis, e hoje são malucas, mas o que serão amanhã?
Essa resistência por parte dos programadores acontece porque muitas vezes quem dá a ordem nem ao menos considera a opinião do programador. O caso é que há muitas formas de lidar com a pessoas, e pessoas que trabalham com conhecimento são diferenciadas. Um bom desenvolvedor não faz por fazer (o famoso "code monkey"), ele quer aprender sobre o negócio, e então cruzar o conhecimento adquirido com o técnico e daí propor a melhor solução. Uma ordem vinda de uma pessoa que não tem todo esse conhecimento bate de frente com essa visão, o que pode gerar muitos conflitos e insatisfação. Nesse caso, deixar a equipe coordenar o próprio trabalho não pode ser a melhor opção?
|
|
|
|
|
Ah sim, algumas equipes ágeis, após um certo tempo chegam a abolir o Scrum Master, quando a equipe chega a um ponto que leva os valores do scrum com grande facilidade. No cenário que você citou, em que o gerente "é" o SM, ele poderia ter seu cargo removido? Se é a mesma coisa, não vejo pra que mantê-lo nesse caso.
|
|
|
|
@felipefranz, creio que você seja gerente de projeto, o que me leva a crer que tenha maior resistência para considerar a possibilidade de uma equipe sem um gerente.
Basicamente, o SM não está hierarquicamente acima do time, como é um gerente tradicional, e quem já passou por um ambiente assim sabe que é uma situação completamente diferente, já que a hierarquia leva ao comando-controle. Vou deixar para o Alexandre Magno explicar.
O texto é uma visão de quem já está há um bom tempo na area, e que já foi gerente de projetos por muitos anos e hoje não é mais. Sugiro que quando poder abri-lo aproveite a oportunidade de entrar na discussão, e dizer ao próprio criador do post que é a visão de um fanboy, ele tem muita disposição pra defender seu ponto de vista.
|
|
|
|
Sobre quem associa Scrum Master ao gerente de projeto, me abstenho de explicar a diferença, pois falta muito conhecimento para afirmar que é o mesmo papel.
Voltando ao tópico, encontrei um post muito interessante sobre o que está em discussão, denominado Fire all the managers, escrito pelo Giovanni Bassi, uma conhecida figura do meio ágil, o qual recomendo a leitura inclusive dos comentários, que está gerando uma discussão muito semelhante ao desse tópico.
|
|
|
|
Existe sim, e essa é uma função bem trivial do framework. Veja um exemplo aqui.
Flw!
|
|
|
|
felipefranz wrote:Uma visão unilateral. Burocracia não atrapalha, senão não faria sentido, é a mesma coisa que dizer que lei não serve pra nada e só atrapalha, a burocracia se assemelha muito às leis, burocracia burra, ou seja, disfunção burocrática sim é ruim.
O problema é que forçam burocracia onde não é necessário, o que acontece sempre. Um exemplo é a forma como "administram" bugs. O bug é informado, cadastrado, ae escolhem alguém para resolver, a pessoa vai e resolve e depois anida tem que provar que resolveu, quando o importante aqui é resolver, e garantir que não aconteça de novo. Cadastrar o bug é realmente necessário? Toda essa administração é?
felipefranz wrote:E você que está enganado se acha que a função do gerente de projetos não deveria ser "facilitador" da equipe para que o projeto seja entregue no prazo, custo e escopo prometidos, você só confirmou o que eu constatei.
Acho que não fui claro, mas o SM tem que cuidar para que o scrum flua bem, lidando com o que dificulta a vida do time. Ele é o cara que pára pra resolver os problemas do time. Ele NÃO tem que GARANTIR a entrega no prazo (já que pode surgir algo que impeça isso, e problema acontecem), ele não lida com custo, e trabalha com escopo aberto como os demais. Além do que, um membro do time não É SM, ele ESTÁ SM, é um papel, não um cargo.
felipefranz wrote:O que tem a haver falta de comando-controle com retorno antes?
Falei para exemplificar que os ganhos dessa abordagem são para todos, não só para um dos lados.
Por ser nova, a gestão na área de ti não tem nenhum padrão definido, então são experimentados os mais variados modelos pré-existentes, como modelo de fábrica, que não serve pra software. Como esse, muitos modelos falham, mas ainda sim continuam sendo adotados - a fábrica de software tá aí - o que não quer dizer que seja uma boa opção. Qualquer um que estudou um mínimo sobre projetos de software já viu os gráficos que indicam a grande quantidade de projetos de software que falham fazendo uso de tais métodos - e que continuam em uso. Quando diz melhores práticas, não são melhores práticas pra um projeto de software, já que elas não existiam, então como pode assumir que práticas de tantos anos, as quais não foram feitas para lidar com esse tipo de projeto, são "as melhores práticas"? Por experimentação, o que não trouxe um resultado tão bom assim.
Falando de Software, agile é o melhor que temos hoje, o que também foi experimentado, trouxe resultados melhores e está constantemente evoluindo. O ponto é que muitas vezes é escolhido manter um modelo pobre com resultados medíocres, ao arriscar um que pode trazer resultados melhores. É claro que agile não é modelo para tudo, mas tem se mostrado a melhor opção para desenvolvimento de software - vide o destaque que empresas que o adotam conseguem - comparado à outros modelos.
|
|
|
|
|
|