Diego Pacheco Tech blog

Estimar não é uma tarefa fácil e muito menos precisa. Se fosse fácil e 100% precisa essa técnica iria ser utilizada sempre por apostadores da Mega-Sena. :) Mas nem por isso podemos simplesmente virar as costas para a questão. Nesse caso não estimar não resolve o problema! Nos posts anteriores: http://diego-pacheco.blogspot.com/2008/11/o-cho-de-um-projeto.html http://diego-pacheco.blogspot.com/2008/08/estimativa-no-exatimativa.html Comentei de uma forma geral como poderíamos estimar utilizando outra abordagem, uma abordagem voltada ao comprometimento! Quais seriam os ganhos se adotarmos essa abordagem? Bom seriam vários mas posso destacar: Mais envolvimento com pessoas do negócio Informações mais realistas para tomadas de decisões Alinhamento total ao Planejamento Estratégico Visão de um horizonte maior facilita muito o planejamento ao curto prazo Melhor desempenho de *previsto* vs *Realizado* Se você não der uma data para o Sponsor ou para o Cliente ele vai pensar em uma para você! Est...

Recentemente a SpringSource os criadores e mantenedores do Spring Framework, adquiriram a Covalent uma empresa especializada em Tomcat, um pouco antes disso o project leader do AspectJ e um dos grandes responsáveis pela parte de Aspectos no Spring começa a se envolver com OSGI, qual é o resultado disso? Spring DM, uma solução que une o contexto do Spring Framework com OSGI. OSGI é um padrão de fato de mercado des de 1999, agora que a coisa está evoluindo para o ServerSide, a SpringSource foi pioneira nisso, logo depois seguida pelo pessoal do Glassfish . Não é modismo, OSGI é uma solução muito robusto que vai resolver diversos problemas que o J2EE não resolveu! O JBoss vai lançar um solção com OSGI, mas até onde eu sei não será com a mesma magnitude da SS/Glassfish, a ideia do JBOSS é o kernel modular com MBeans. Nesses dias vimos que a SpringSource comprou a G2One , empresa que mantinha o Groovy e o Grails . Tanto é que os caras já fizeram um release . O Próprio Rod Johnson disse...

A assunto não é novo. Sempre que vejo na hypermidea e no mercado comentários sobre essa prática vejo sempre o foco em build, abstraindo o máximo possível e fazendo um esforço alguns até enfatizam com foco em gerencia de configurações. Não há dúvidas que Gerencia de Configuração é uma disciplina esquecida aqui no brasil, fora do país até vejo movimentações sobre o assunto mas lá também existe uma grande deficientes de profissionais nessa área. Você conhece alguém que é ou quer ser gerente de configurações? São raros talvez achar um gnomo laranja venha a ser uma tarefa mais fácil do que achar um GC. Isso acaba afetando muito um projeto de software, bom que conhece Casos de uso e utiliza estimativas através do Use Case Point sabe a disciplina de ambiente podem diminuir até 38% da complexidade do projeto. Esse é um número muito alto. Isso se divide em: Planejamento de Release : As trocas de versão são complicadas e se perde muito tempo para colocar uma versão no ar, se acontece algum prob...

Como já disse o Mysnky agentes tem tudo param serem o próximo grande paradigma da computação. A minha idéia nesse post é falar um pouco mais sobre Sistemas Multi Agentes e como podemos utilizar esses conceitos em Java através frameworks especializados em IA como o Jade e utilizando Spring Framework também :) Agentes Não existe muito consenso sobre a definição de agentes para podemos assumir que agente é uma entidade real ou virtual imersa em um ambiente (que também pode se um agente) sobre o qual ele é capaz de agir ou sofrer uma ações do mesmo. Existe apenas uma capacidade parcial de percepção deste ambiente por parte do agente. Os agentes podem se comunicar entre si, seu comportamento é autônomo e decorrente das observações do ambiente e das interações com outros agentes. Os agentes podem ser basicamente Ativos, Reativos ou Híbridos. Agentes híbridos são bem comuns, muitas vezes queremos realizar soluções com agentes reativos mas quando nos tocamos os agentes já começam a ficar cheio...

Todo projeto de software costuma ter alguém como um papel de liderança, essa pessoa pode ser um Gerente de Projetos, Scrum Master, Líder Técnico ou até mesmo um Arquiteto. Essa pessoa por natureza funciona como um grande catalizador na equipe. Essa pessoa tem a capacidade de influenciar muito os desenvolvedores do projeto. Tanto pode ser para o bem como para o mal (risada maligna hahaha :)). Mas existe uma coisa que se essa pessoa faz dá uma enorme diferença no projeto. Um plano! Planejar não é perda de tempo. Com um plano definido as pessoas se sentem seguras, se sentem como se o que elas fazem tem mais sentido, se setem úteis e sentem como parte de algo maior. Como um chão é possível prestar atenção onde se está pisando e podemos ver aonde vamos dar o próximo passo, no meio da jornada ainda é possível mudar de direção. A Documento de Visão de Projeto do RUP ou o Documento de Escopo do PMI dão formas ao produto que será desenvolvido no projeto. Sem esses documentos de visão ficamos ...

Uma imagem fala mais que mil palavras. Muitas vezes usamos essa frase em diversas situações, mas as vezes esquecemos que isso pode ser útil em um projeto de TI Também. O Ron Jeffries um dos criadores do XP dá muito em foque nessa questão de sinalizar o que está acontecendo no projeto. Mas a questão não é apenas sinalizar isto para os stakeholders mas sim para a própria equipe do projeto também. Essa não é mais uma das coisas que vem do *Agile Hype*. Claro os caras fala nisso também, mas isso está ligado com uma questão muito maior e em muitas vezes mais perturbadora o Planejamento Estratégico. O Planejamento estratégico deve vir de cima, ou seja vir da aérea de negócio, assim ele pode ser cascateado para a TI e subseqüentemente cascateado para projetos de software através de uma técnica chamada Balanced Score Card . A partir do ponto que existe um planejamento maior por conta da organização a TI e os projetos derivados dela começam a ganhar sentido, sem esse alinhamento não garantia ...