Até agora o engine de geração de código do Mono era baseado em uma árvore de representação intermediária (IR) do código. A versão 2.2 possue uma nova engine baseada em uma IR linear, que traz melhorias significativas de velocidade e tamanho de código.

A IR baseada em árvore anterior tornava "difícil melhorar a geração de código e extender o engine JIT de maneira significativa", de acordo com Miguel de Icaza. O novo IR linear ajuda a "melhorar a visibilidade do uso do alocador de registro, assim ele pode fazer melhores escolhas quando produzindo código".

O trabalho na IR linear começou no final de 2005. O trabalho evoluiu mas o time do Mono não queria incluir a nova engine no 2.0 por causa da quatidade de trabalho envolvido. Agora, que a versão 2.2 foi liberada, o Mono tem uma nova engine.

O efeito mais importante da mudança é mostrado pelos resultados de benchmark:

Velocidade: O engine beneficiará código computacionalmente intensivo, normalmente entre 10% e 30% de aumento de performance, with alguns casos chegando a 50% mais rápido.

Tamanho do código: a nova engine gera código menor, tipicamente 12% a 20% menor.

Aqueles interessados nos detalhes da nova engine podem encontrá-los no website do Mono. Os Release Notes para a versão 2.2 mencionam as seguintes melhorias: performance aumentada, suporte para compilação antecipada, suporte para monitoramente através de PerformanceCounters, anexar código ao vivo, suporte a SIMD e outros.

Fonte: InfoQ

O livro “SOA Design Patterns“, do Thomas Erl já estava no forno mais de 1 ano. Finalmente disponível, a publicação é um daqueles “must read” para quem não quer “reinventar a roda” e seguir boas práticas e padrões nas implementações e integrações baseadas em SOA.

O livro foi feito de forma colaborativa. Além do próprio autor, outros 35 especialistas ajudaram na extensa e excelente lista de patterns que o livro apresenta. Nomes como David Chappell (Oracle), Mark Little (Red Hat/JBOSS), Pablo Cibraro (Lagash Systems SA), Nelly Delgado (Microsoft Corporation) etc.

Você pode consultar a lista dos patterns neste link. Adicionalmente, Erl disponibilizou um MS Visio Stencil (template) que você pode baixar aqui e utilizar livremente na representação gráfica dos seus padrões e diagramas (testei no MS Visio, MS Word, MS PowerPoint).

Abaixo o comentário de uma das mais conhecidas analistas, Anne Thomas (Burton Group):

The technical differences between service orientation and object orientation are subtle enough to confuse even the most advanced developers. Thomas Erl’s book provides a great service by clearly articulating SOA design patterns and differentiating them from similar OO design patterns.
- Anne Thomas Manes, VP & Research Director, Burton Group

Fonte: SOA, Simples Assim!

Postado por Chris Sims, traduzido por Paulo R. C. Siqueira em 30 Jan 2009 10:50 AM

Um membro de uma nova equipe ágil perguntou à lista Scrum Development como rastrear o tempo real que os engenheiros gastam em tarefas, e como isso está relacionado ao conceito ágil de velocidade. Velocidade é a medida ágil para rastrear o quão rápido a equipe está implementando funcionalidades, e portanto o quanto demorará para um projeto ser completado. A opinião do grupo foi que rastrear tempo gasto não é nem necessário nem útil.

A pessoa que postou a pergunta explicou que sua equipe estima o tamanho de suas histórias usando pontos de história. Conforme a equipe completa histórias, eles anotam os pontos de história relacionados. Esta anotação é então utilizada para calcular a velocidade da equipe:

…a velocidade é basicamente a quantidade de trabalho que a equipe pode fazer por sprint. Talvez algo como 25 Pontos de História / sprint de 4 semanas. Esse número pode ser utilizado para ajudar a deterninar quanto trabalho pode ser pego em cada sprint sub-sequente.

Até aqui, tudo bem. O autor segue descrevendo como as histórias da equipe são quebradas em tarefas, e essas tarefas são estimadas e rastreadas em termos de horas:

Nós temos usado gráficos burndown, no qual cada membro da equipe escreve o tempo restante por tarefa a cada dia. Isto é inserido em uma planilha de gráficos burndown. Mas, isso apenas captura dados para o burndown, não ajuda com a velocidade.

Esta confusão exemplifica por que alguns agilistas, incluindo Ron Jeffries, recomenda não estimar ou rastrear tarefas de modo algum. George Dinwiddie acrescentou sua visão:

Se você fizer as histórias pequenas, então você não precisa rastrear horas no seu burndown. Eu vejo que as equipe produzem melhor apenas rastreando histórias, e eles não desperdiçam todo aquele tempo re-estimando horas.

Na discussão, Ron e outros apontam que toda a informação necessária para fazer projeções úteis está em "25 Pontos de História / sprint de 4 semanas". Esta é a velocidade da equipe, e é exatamente o que é necessário para prever quantas histórias a equipe provavelmente será capaz de completar no futuro.

Sua equipe rastrea tanto estimativas de tarefas quanto estimativas de histórias? Deixe um comentário e compartilhe o porquê ou o porquê não.

Fonte: InfoQ

São Paulo – Meta é colocar corporações brasileiras entre os players internacionais.

Por Rodrigo Afonso, repórter do COMPUTERWORLD
29 de janeiro de 2009 – 15h22

A Associação Latino Americana de Teste de Software (ALATS) criou uma certificação para empresas que atuam no segmento. O objetivo, segundo a entidade, é fornecer parà¢metros para que as companhias conheçam normas e modelos para esse tipo de controle no ambiente tecnológico.

Em 2007, a ALATS já havia lançado uma certificação para profissionais da área de testes de software.

Dados da associação indicam que hoje o Brasil possui 15 fábricas de teste. Segundo a entidade, este é um número ainda pequeno frente ao potencial de crescimento.

Para Émerson Rios, presidente da ALATS, padronizar e melhorar a qualidade dos testes é fundamental para que as empresas consigam competir no mercado global, principalmente no setor de terceirização. “Hoje, a àndia, alguns países do leste europeu e Irlanda ocupam um mercado de softwares no qual o Brasil tem todo o potencial de entrar, se conseguir padronizar e melhorar o processo de testes”, afirma.

Mais informações sobre as certificações podem ser obtidas no site da ALATS.

Fonte: Computerworld

Postado por Mike Bria, traduzido por Victor Hugo Germano em 29 Jan 2009 09:41 AM

Corey Haines recentemente embarcou em " uma excursão de Pair Programming" de uma única pessoa na região central dos EUA. – Agora, há três semanas nesta viagem inovadora, Haines postou um vídeo de entrevistas revelando muitos dos insights que ele conseguiu sobre pares, testes automatizados e a evolução do “artesão de software” enquanto compartilha o teclado nas casas de Dave Chelimsky, Brian Marick, Uncle Bob Martin entre outros.

Inicialmente inspirado pelo matemático húngaro Paul ErdÅ‘s, Corey Haines embarcou em uma viagem em nome de aumentar a ênfase de industria em software como um artesanato. Assim como fez Erdos em meados do século XX, Haines está atualmente viajando ao redor do centro-oeste norte americano para praticar desenvolvimento de software (ao invés de matemática) com uma ampla gama de seus colegas e mentores. Em “par” com eles. 

Enquanto ele entitulou a viagem de um "Pair Programming Tour" o principal intuito é de alguma forma menos sobre pair programming em si, do que sobre buscar informações do que é necessário para um desenvolvedor de software realmente se tornar bom naquilo que faz. Como o próprio Corey afirmou quando a InfoQ conversou com ele:

A viagem é a primeira iniciativa de prover um mecanismo para a comunidade ganhar os benefícios da mentalidade do journeyman, viajando e trabalhando com diferentes pessoas.

Em sua essência, Haines está atuando em uma interpretação totalmente literal da opinião de que software é um processo artesanal, e ainda que só pode ser apenas dominado através de experiências reais com diferentes problemas e sendo exposto ao aprendizado de outros artesãos.

Em relação a como a viagem o tem pessoalmente ajudado desta forma, Haines apresentou o que tinha a dizer sobre as três semanas que ele tem gasto usando o teclado com outros: 

Uma coisa que se destaca é o benefício que eu ganho por fazer par com uma gama tão vasta de pessoas em projetos diferentes: uma aplicação Ruby Cocoa; um Ruby VM em ActionScript; aplicativos baseado em Merb-, Rails-, Limelight e o bom e velho Ruby. Eu tenho visto um monte de ambientes diferentes, de escritórios a salas de estar que tem me dado uma perspectiva diferente das pessoas também.

Haines capturou vídeo de entrevistas com cada um dos seus hosts e postou no blog monitorando o progresso de sua viagem, permitindo-nos também compartilhar sua "exposição à história de outros artesãos". Nessas entrevistas você vai ouvir várias histórias e pontos de vista de ”Tio” Bob Martin, Brian Marick (Parte 1 e Parte 2), David Chelimsky, Micah Martin, Dave Hoover e Eric Meyer. Cada uma das entrevistas vale a pena ver na íntegra, mas algumas em destaques são:

• Dave Chelimsky em como não existe melhor substitutivo para aprendizagem do nosso artesanato do que trabalhando com os outros (via pares); sobre o beneficio em relação à leitura de um livro ou um blog("você não pode aprender a assar um bolo observando um grande bolo ").
• Brian Marick sobre os problemas e alternativas para desenvolvimento orientado a testes de aceitação, também leva suas "duas telas em par".
• Micah Martin na 8ª Light’s Apprenticeship abordagem do crescimento do artesão de software.
• A Perspectiva de cada pessoa sobre o que Corey está fazendo e suas experiências em par com ele. “‘­

Reserve algum tempo para checar os registros de Corey em sua viagem, compartilhando sua percepção sobre sua iniciativa ao longo das ultimas semanas.

Fonte: InfoQ

Veja os oito aspectos que os executivos precisam considerar antes de ingressar na carreira de consultor

Bart Perkins*
Publicada em 29 de janeiro de 2009 à s 12h08

Como resultado direto das turbulências econômicas, muitos executivos que atuam na área de TI tem perdido empregos estáveis e, ao que tudo indica, essa situação ainda deve piorar nos próximos meses. Sem muita opção de encontrar uma nova vaga nas empresas, muitos profissionais começam a avaliar a possibilidade de montar uma pequena consultoria.
Esse tipo de negócio, no entanto, representa um risco. Isso porque, na maior parte dos casos, as consultorias de pequeno porte não têm estabelecido uma carteira de clientes, metodologias e processos administrativos. Pior, não apresentam recursos necessários para capacitação.

Assim, antes do CIO ou diretor de TI aceitar um convite para trabalhar numa pequena consultoria ou, mesmo, montar um negócio próprio nesse setor, deve considerar os seguintes aspectos:

Oferta de serviços
As pequenas consultorias de sucesso precisam oferecer um pequeno número de serviços, mas de muito alta qualidade. Deve-se focar em um determinado setor ou oferta no qual a equipe tem bastante expertise. Ou seja, vale resistir à  vontade de dizer aos potenciais clientes que sua empresa pode endereçar qualquer necessidade de TI.

Desenvolvimento de negócios
Nenhuma consultoria existe sem clientes. Mas a maioria das empresas de pequeno porte não tem cuidado na hora de analisar o público-alvo. De forma geral, quando um profissional inicia um negócio, os próprios amigos o contratam. Isso até ajuda a dar início à  operação, mas não cria uma companhias sustentável.

As verdadeiras empresas de sucessos precisam identificar oportunidades de negócio e fechar acordos com clientes que elas ainda não conhecem. Assim, se você odeia ser vendedor ou não consegue imaginar a possibilidade de fazer ligações para estranhos, esqueça o trabalho em uma pequena consultoria.

Fique atento à s expectativas
Executivos que viram consultores algumas vezes querem oferecer conselhos baseados na sua própria experiência. Mas as consultorias que vão sobreviver a longo prazo devem trabalhar com uma abordagem verdadeiramente consultiva. Ou seja, até podem usar a experiência dos profissionais, contudo, precisam identificar as necessidades reais dos clientes para criar soluções e recomendações baseadas em análises rigorosas. Isso inclui, principalmente, dar atenção aos detalhes.

Defesa das idéias
Na maior parte das grandes organizações, os gerentes de nível médio se negam a implementar algumas idéias dos seus superiores. Com base nisso, as consultorias pequenas precisam ficar atentas para não impor suas idéias e, sim, vendê-las. Isso exige uma integração com o cliente e flexibilidade para modificar os objetivos iniciais. O ego não pode prevalecer.

Delegar
Pelo fato de uma pequena consultoria trabalhar com uma equipe limitada e, dificilmente, conta com o apoio de consultores menos experientes ou com uma equipe administrativa, delegar pode não ser uma opção viável. Com isso, os consultores precisam ter habilidades com Excel e PowerPoint, bem como devem saber escrever seus próprios relatórios.

Status
As pessoas que escolhem trocar um cargo executivo pelo trabalho em uma pequena consultoria perdem o status e os benefícios de uma grande organização. Assim, na maior parte dos casos, esses profissionais precisam aprender a trabalhar sem um assistente, em um escritório menor e com uma rede de computadores nem tão eficiente. Além disso, os jantares com clientes acabaram.

Na prática, isso pode gerar um desapontamento para os profissionais, os quais precisam adequar suas atitudes e objetivos a esse novo cenário.

Impacto financeiro
Com equipes enxutas, as consultorias menores só conseguem ser rentáveis quando os profissionais estão trabalhando em projetos que vão trazer resultados financeiros. No entanto, essas empresas precisam estar preparadas para enfrentar períodos de poucas demandas e, por consequência, dinheiro limitado para pagar empregados e fornecedores. O que exige estar bem preparado financeiramente.

Estratégia de saída
Consultorias menores, muitas vezes, são organizadas com base no estilo de vida dos proprietários. Com isso, se a empresa é administrada por profissionais jovens, pode ser baseada em oportunidades e desafios. Ou, o contrário, se o sócio for mais conservador, pode representar um lugar mais austero.
Assim, antes de aceitar o convite para trabalhar em uma pequena consultoria, entenda o perfil de quem dirige o negócio e veja se faz sentido, ou não, com seus objetivo.

Bart Perkins é gerente de parcerias da Lousiville, empresa norte-americana especializada em ajudar as organizações a investir melhor na área de TI

Fonte: CIO

Postado por Vikas Hazrati em Jan 27, 2009 11:40 PM. Traduzido por André Dourado

Gerenciamento de risco é uma atividade diretamente ligada ao tratamento, mitigação e monitoração de riscos. Muitos agilistas acreditam que o processo de gerenciamento de risco para projetos ágeis, não é significativamente diferente dos projetos tradicionais. Embora o processo seja um pouco mais simples nos projetos ágeis, os passos de localizar, classificar e criar planos de solução dos riscos, permanecem muito próximos aos projetos tradicionais.

Mike Cottmeyer sugeriu que metodologias ágeis são melhores na identificação e mitigação dos riscos. De acordo com ele,

Agile é tão efetivo no gerenciamento de riscos porque os processos de gerenciamento de riscos são construídos durante a execução dos projetos. Existe um entendimento implícito que o risco está em todos os lugares em um projeto. Riscos não podem constar em uma lista de riscos. Riscos não podem ser mitigados em uma reunião de time ou em sessões periódicas de revisão de riscos. Lidar com o risco tem que ser uma obsessão. Nossas estratégias de mitigação não sobrevivem fora do projeto, mas influenciam na natureza como estruturamos e planejamos nosso trabalho.

Ele também classificou riscos em três categorias:

• Riscos do Negócio – relativos à s entregas do projeto e o valor do negócio prometido.
• Riscos Técnicos – relativos a viabilidade da solução técnica dentro das restrições de prazo e custo.
• Riscos de Logística – relativos a premissas relativas a pessoas e infraestrutura.

De acordo com Mike, em virtude do fato que Agile encoraja entregas frequentes, inspeção constante e adaptação, o gerenciamento de risco é inerente ao processo.

Porém, nem todos concordam que Agile endereça os riscos de forma inerente. Jurgen Appelo sugeriu que frequentemente há uma perda do foco sobre os riscos nos projetos ágeis.

De acordo com ele,

Gerenciamento de projetos faz parte do Prince2, parte do PMBOK e parte do CMMI, mas você não vê tratado explicitamente em livros sobre métodos ágeis. Acho isso estranho.

Ele também mencionou que frequentemente gerentes de projeto mergulham fundo nos projetos e perdem a visão do todo. Isto faz com que haja uma severa perda do foco sobre o gerenciamento de risco.

James Shore complementa que o gerenciamento efetivo de riscos, pode auxiliar o time a ter um sólido comprometimento. Sugere a utilização de ferramentas como o multiplicador de risco e “burn-up charts” para gerenciar riscos específicos do projeto.

Multiplicadores de risco contabilizam riscos comuns, como turnover, mudanças de requisitos, paradas de trabalho etc. Estes multiplicadores posisibilitam que você agende uma data, estime quantos user stories points você terá prontos e em produção.

James sugere os seguintes multiplicadores de risco:

Como funciona? Você toma a velocidade de desenvolvimento de uma iteração e extrapola para a data de entrega. É a melhor estimativa de quantos story points serão finalizados sob circunstà¢ncias ideiais. Então se sua velocidade é 14 e você tem 10 iterações restantes, você prevê que finalizará mais 140 pontos antes do release.

Então você aplica os multiplicadores de risco de acordo com o tipo de processo utilizado. Se você tem uma velocidade contante e tem todas estorias “feito feito” a cada iteração, você pode utilizar a coluna “rigoroso”. Caso não, utilize a coluna “Arriscado”.

Para continuar o exemplo, digamos que seu time tem uma abordagem rigorosa, para conseguir o comprometimento, você aplica os multiplicadores como segue:

De acordo com James,

Isto possibilita que seja conseguido um acordo entre stakeholders e executivos. “Nós estamos certos de finalizar mais de 78 pontos na data do release, então estamos comprometidos na entrega dos recursos A, B e C. Tivemos 50-50% de chance de completar 100 pontos, então estamos planejando os recursos X, Y e Z como objetivo ambicioso.”

Gerenciamento de risco é uma parte de qualquer projeto ágil, assim como nos projetos tradicionais. A chave é dar o foco desejado, mitigá-los eficientemente e fazer acordos baseados no gerenciamento.

Fonte: InfoQ

Scott Guthrie anunciou hoje que o ASP.NET MVC 1.0 Release Candidate, está disponível para download. Este release é o último release público, antes do release final 1.0 planejado para Fevereiro.

Bruno Ferrari, de INFO Online
27/01/2009

SàO PAULO ““ A empresa de consultoria e treinamento Brunise iniciou cursos e exames de certificação ITIL V3 Foundation e ITIL V3 Foundation Bridge em português.

A Brunise acaba de ser homologada pela APMG- US, órgão oficial responsável pela disseminação do ITIL no mundo. Segundo Luis Mathô, responsável pelo desenvolvimento de negócios das Américas na APMG- US, o órgão tem reparado no grande interesse por parte de profissionais e empresas que buscam uma maneira de aplicar boas práticas de TI.

Segundo a Brunise, não existem pré-requisitos para a realização dos exames, salvo a comprovação da certificação ITIL V2 Foundation para a certificação do ITIL V3 Foundation Bridge. Mas a recomendação é que o candidato passe por um treinamento antes de realizar os exames, que podem ser feitos online ou em papel.

Receberão o certificado e o pin emitidos pela APMG-US, os candidatos que obtiverem pelo menos 65% de acertos no exame. Para mais informações, consulte o site da Brunise.

Fonte: Info Corporate

Postado por Chris Sims, traduzido por Douglas Masson em 27 Jan 2009 08:55 AM

Desenvolvedores geralmente quebram a história do usuário em tarefas para facilitar o trabalho de distribuição e implementação em torno da equipe e permitir um acompanhamento dos processos em um nível fino de granularidade. Infelizmente, a estória pode explodir em uma lista de tarefas não triviais tão grandes que a história não é entregue no fim da iteração. Ron Jeffries sugere: fazer estórias como uma unidade, não quebrar em tarefas.

Para que isto funcione, as estórias precisam ser pequenas o suficiente para que a equipe possa entender e estimá-la bem. Uma abordagem para decomposição da estória é listar os critérios de aceitação, e então olhar para cada um deles e encontrar aqueles que podem ser suas próprias estorias. Se aquele critério de aceitação em particular acrescenta algum valor ao produto, é um visível para o usuário, é indepentende e é testável, então é um bom candidato para se tornar a sua própria estória.

Várias equipes tem os especialistas que focam em áreas especificas do produto ou das tecnologias subjacentes, tornando difícil dar uma estória completa para um indivíduo. Uma solução a longo prazo é cruzar os desenvolvedores de forma que possam trabalhar em várias partes do sistema e com todas as tecnologias necessárias. Isto cria uma equipe que é versátil e reduz a perda do risco organizacional ‘a única pessoa’ que é competente para trabalhar em uma determinada área do sistema. Uma forma de ter o trabalho feito agora, enquanto se move nesta direção, é utilizar a programação em par. A pessoa que ‘possui’ a implementação da estória em par com as pessoas que tem a competência necessária, a fim de entregar a estória completa.

Ron recomenda: "Queime as histórias, não as tarefas". Quando monitorando (queima) a nível de tarefas, os desenvolvedores podem ‘fazer sua parte’ finalizando muitas tarefas, sem qualquer funcionalidade do usuário ser entregue. Se a equipe apenas monitora o término das histórias, então os desenvolvedores apenas recebem o calor de finalizar algo quando a história está completa. Isto encoraja uma noção mais valiosa do ‘feito.’

Você concorda com a abordagem do Ron? Deixe um comentário e compartilhe a sua opinião.

Fonte: InfoQ