José Papo Weblog

Crescimento do Amazon S3 em 2011

2012-01-31T07:48:00.002-02:00

Vide o post sobre Crescimento do Amazon S3 em 2011

Liberdade com Amazon Web Services

2012-01-30T09:01:00.000-02:00

Escrevi um artigo sobre o principal benefício de usar os serviços e produtos da Amazon Web Services: A Liberdade que se conquista!

Vide os detalhes no artigo Tenha mais liberdade com a Nuvem da Amazon Web Services!

Deck de slides - Introducao a Cloud Computing e Amazon Web Services

2012-01-24T10:08:00.003-02:00

Olá!

Acabei de publicar no slideshare uma apresentação introduzindo Computação em Nuvem e a Amazon Web Services.

Vale a pena conhecer sobre a revolução do Cloud Computing e como a Amazon Web Services pode te ajudar.

Introdução a Cloud Computing com Amazon Web Services

View more presentations from Jose Papo

Blogs da Amazon Web Services em português e espanhol !

2012-01-02T13:14:00.003-02:00

Olá,

Quem costuma acompanhar meu blog pessoal deve ter notado que diminuí muito a frequencia de postagens. Isso aconteceu porque agora me tornei o Technical Evangelist da Amazon Web Services. Nessa função sou responsável por ser a ponte entre as comunidades de desenvolvedores, profissionais de TI, CIOs, clientes e parceiros em relação às soluções de Cloud Computing e Storage da Amazon.

Um dos meus papéis é o de mostrar ao público brasileiro e latino-americano como as soluções da Amazon Web Services auxiliam os negócios com uma solução de computaçao em Nuvem simples, inovadora e de baixo custo. Uma das ferramentas que utilizo para fazer essa divulgação é o blog. Sou o responsável pelo blog da AWS em português e pelo blog da AWS em espanhol. Visite-os para conhecer mais sobre a Amazon Web Services na América do Sul!

Acompanhem também o twitter do José Papo para informações atualizadas sobre a Amazon, sobre a Amazon Web Services e sobre tecnologia em geral!

Cloud Computing e Big Data : A revolução da TI moderna

2011-10-12T09:00:00.005-03:00

Cloud Computing e Big Data são tecnologias que revolucionam completamente a TI. Para mim, são os itens de maior importância e tendência para os próximos anos. E por quê? Porque elas mudam radicalmente os gastos em TI, bem como mudam a forma como armazenamos e tratamos dados.

Com a Computação em Nuvem, empresas podem reduzir seus gastos com a infraestrutura de TI e investir essa quantidade de dinheiro economizado para inovar, construindo ainda mais softwares que melhorem os processos da organização.

Com tecnologias de Big Data as empresas poderão coletar e organizar ainda mais dados sobre seus produtos, serviços e clientes. Isso melhorará as ofertas e o serviço aos clientes. Um grande exemplo do poder dos dados é a Amazon. Ela armaneza os mais diferentes tipos de dados sobre seus clientes e produtos, permitindo direcionar ainda mais ofertas e orientar sua logística e estoques. O nível de recomendações e a forma como a Amazon gera uma plataforma de rede social orientada a seus produtos e serviços a tornam a loja de produtos e livros mais acessada e que mais vende em todo o mundo. Sua capitalização em bolsa é grande porque possui diferencias competitivos enormes, gerados pela sua plataforma computacional e pelos seus algoritmos complexos.

A Computação em Nuvem e Big Data farão com que as organizações que as adotem integralmente fiquem mais lean (enxutas), tenham menos desperdícios e fiquem cada vez mais centradas no cliente.

Portanto, fiquem de olho: pessoas com conhecimentos e experiências para serem "Cloud Architects" e "Big Data Analysts" serão cada vez mais requisitados. Estatística também voltou à moda e está na crista da onda. Pois analisar a vasta quantidade de dados gerados pelas novas plataformas demandará ainda mais conhecimento estatístico e analítico.

A meu ver, a revolução da computação em nuvem e do movimento Big Data só tem a trazer benefícios para nossa área de Tecnologia da Informação. Poderemos mostrar mais resultados com os investimentos de TI (que serão mais direcionados para inovação, devido à economia da Nuvem) e gerar mais informações úteis para a empresa, para parceiros e para clientes.

E que venha para o Brasil e para nossas organizações a revolução "Cloud" e "Big Data"!

Lean Startup e Customer Development: Prepare-se para a nova onda que vai ajudá-lo a acertar em cheio nos produtos e serviços que você desenvolve

2011-09-05T09:43:00.007-03:00

No dia 13 de settembro será lançado o muito esperado livro do autor Eric Ries chamado The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Essa é uma das principais novidades surgindo dentro dos métodos Ágeis e do movimento Lean. Me aprofundei no assunto e realmente vejo como uma nova onda fundamental para melhorar a taxa de sucesso de novas empresas e novos projetos e produtos dentro de empresas já existentes.

O conceito de Lean Startup é a aplicação do "Pensamento Enxuto" aplicado ao processo de empreendedorismo e de criação de produtos. Se baseia em quatro grandes tendências atuais:

- Emergência de novas tecnologias, especialmente Cloud Computing, que facilitam a experimentação de novas ideias com custos extremamente baixos.
- Aplicação de processos Ágeis de desenvolvimento
- Iterações rápidas centradas e com foco total nos clientes, especialmente baseado no processo de Customer Development
- Ferramentas para análise, estatística e métricas de baixo custo e poderosas e que facilitam o entendimento do que está funcionando e do que precisa mudar

Um dos pontos que considero um diferencial no processo de "Lean Startup" é a preocupação em não ter requisitos e sim hipóteses. O termo hipótese reforça que uma funcionalidade só se torna algo realmente útil quando validado e confirmado pelos clientes e usuários do produto. Lean Startup e Customer Development enfatizam bastante a construção e constante refinamento do Product Backlog. Nas primeiras metodologias Ágeis o product backlog é sempre algo nebuloso, que se "materializa" pelas mãos do product owner.

Aproveitei para ler e me aprofundar em diversos livros já lançados e que podem dar um excelente "gostinho" do que está por vir no livro do Eric Ries. Também detalham pontos que devem ser vistos mais brevemente no livro "Lean Startup".

The Four Steps to the Epiphany: Successful Strategies for Products that Win - O livro clássico que criou o conceito de customer Development.

Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers - Um livro que inova na maneira de apresentar um plano de negócios de um novo produto ou serviço. O Business Model Canvas ajuda a focar a empresa em entender problemas e soluções

The Entrepreneur's Guide to Customer Development: A cheat sheet to The Four Steps to the Epiphany - Um livro que resume o processo de Customer Development muito bem e que facilita o entendimento do conceito

Running Lean: Iterate from Plan A to a Plan that Works - Utiliza Customer Development, Lean Startup, Bootstrapping e Business Model Canvas para ajudar empreendedores e empresas a construir um produto com maior probabilidade de sucesso

Start Small, Stay Small: A Developer's Guide to Launching a Startup - Um livro fantástico que foca em micro-empreendedorismo serial e bootstrappers. Dá dicas práticas de como validar hipóteses, testar ideias e validar um mercado.

Nail It then Scale It: The Entrepreneur's Guide to Creating and Managing Breakthrough Innovation - Um livro fantástico que explica como testar ideias e hipóteses sobre um mercado antes de gastar muito dinheiro tentando escalar o produto ou negócio. Define um processo para entender um mercado e seu problema, vlaidar a solução e escalar o negócio.

If You Build It Will They Come?: Three Steps to Test and Validate Any Market Opportunity - Um livro prático que foca no estágio inicial de um produto, negócio ou startup. Ele detalha três passos completos com ferramentas e técnicas práticas para entender e validar hipóteses, problemas e soluções

Crossing the Chasm - Um clássico que explica como cruzar o abismo entre usuários inovadores e a maioria dos consumidores de uma tecnologia

Getting to Plan B: Breaking Through to a Better Business Model - Um livro que mostra como estressar e testar o plano A e como alterá-lo para atingir os objetivos de negócio de uma empresa

Startups Open Sourced - Um livro com entrevistas de diversos fundadores de startups que cresceram utilizando métodos de Lean Startup e Customer Development

Convert!: Designing Web Sites to Increase Traffic and Conversion - Não, não é um mero livro sobre web design! É um livro que explica de forma prática como criar um site web e landing pages com base na análise de mercado, da proposição de valor do produto, na busca de ações concretas, em otimização de páginas e em testes A/B e multivariados.
Boa leitura e boa validação de hipóteses para vocês!!!

Melhorias no Controle de Versões do TFS 2010

2011-09-04T15:08:00.003-03:00

Brian Harry, Microsoft Technical Fellow e Gerente de Produto do Team Foundation Server, está escrevendo diversos posts em seu blog sobre as melhorias que virão na nova versão do TFS no ano que vêm.

Um ponto importante e sempre crítico é o controle de versões. Ele terá tantas melhorias e aprimoramentos que Brian Harry escreveu três blog posts sobre o assunto.

Melhorias no workspace dos desenvolvedores, melhorias no Team Explorer e facilidades para operações assíncronas e offline e as que acho mais importantes: melhorias profundas nas operações de merge.

Para maiores detalhes leiam os posts:

Version Control Workspace Improvements

Version Control Merge Enhancements

Wrapping Up on Version Control Improvements

Visual Studio LightSwitch 2011 chegou ao mercado!

2011-07-28T09:23:00.003-03:00

A Microsoft acaba de lançar o Visual Studio LightSwitch 2011! Esse é um novo produto da família Visual Studio que permite constuir de forma simples, rápida e com pouco cóidigo aplicações de negócio para o desktop e para a Nuvem! É possível também extender o LightSwitch com novos controles e extensões mais poderosas, para facilitar a vida dos desenvolvedores.

O produto pode ser instalado diretamente. Mas caso o Visual Studio 2010 Professional ou superior já esteja instalado na máquina, então o LightSwitch se integrará nessa versão já existente.

Assinantes do MSDN já podem fazer o download da versão final do VS LightSwitch 2011 no site para assinantes MSDN.

E qualquer pessoa pode baixar uma versão de avaliação do Visual Studio LightSwitch 2011 para testar seus recursos e facilidades para criar aplicações rápidas para desktops e para a Internet na Nuvem!

Especificação por exemplos - Minha palestra do TDC 2011

2011-07-08T11:50:00.004-03:00

Publiquei o ppt da minha apresentação sobre Especificação por Exemplos ( Specification by Example ) no Slideshare.

A trilha de testes foi excelente e estava bem lotada! Valeu muito à pena e tenho certeza que levou muitas novas ideias para testers e outros desenvolvedores presentes.

Especificação por Exemplos e Testers

View more presentations from jpapo

TDC 2011 em São Paulo - Eu vou!

2011-07-01T08:54:00.006-03:00

Do dia 06/07 até o dia 10/07 ocorrerá em São Paulo o TDC 2011. É um grande evento e recomendo fortemente a participação. O custo por trilha é baixíssimo e contará com excelentes temas e palestrantes.

Farei uma palestra na trilha de testes no dia 07/07 com o título Especificação por Exemplos - A Agilidade hiperprodutiva com especificações executáveis.

Também farei uma palestra na trilha de ALM no dia 08/07 com o título Melhorando a Colaboração entre testers e desenvolvedores - Dicas e Práticas.

Aproveitem e se inscrevam nesse excelente e muito bem planejado evento! Um custo muito baixo para aprender com pessoas excelentes das comunidades de desenvolvimento de software do Brasil!

SDK de Java para o Team Foundation Server 2010

2011-05-18T09:51:00.000-03:00

A equipe de produtos do TFS 2010 lançou um SDK Java para o Team Foundation Server 2010!

A extensibilidade do TFS sempre foi um princípio arquitetural seguido pela equipe de produtos da Microsoft. A necessidade de customização de um processo de ALM é necessário para diversas empresas. Agora, também é possível extender o TFS programando em Java, através de uma API feita especialmente para isso!

O SDK de Java para TFS inclui:

- um JAR contendo todas as APIs

- As bibliotecas nativas usadas pela API

- Documentação completa no formato JavaDoc

- Exemplos de código

Mais detalhes sobre este anúncio podem ser encontrados no blog do Brian Harry.

Realizando merge no TFS com ferramentas parceiras

2011-04-13T11:11:00.004-03:00

O controle de versões do TFS 2010 possui um controle de versões bem avançado. Possui também uma ferramenta visual para realizar 2-way merges. Porém, muitas pessoas preferem usar outras ferramentas de merge e que também possuam 3 janelas (para realizar 3-way merges).

O TFS 2010 é extensível e maleável o suficiente para permitir o uso de outras ferramentas de merge!

Uma ferramenta que acho bem interessante para realizar merges é o KDiff3.

Vamos então ao passo a passo simples para configurar o uso do KDiff3 com o TFS 2010!

Vá no Visual Studio ou no Team Explorer Client e abra o menu Tools / Options:

A janela de configuração aparecerá. Selecione Source Control / Visual Studio Team Foundation Server. Na janela clique "Configure User Tools...":

A janela "Configure User Tools" aparecerá:

Clique em "Add..."

Preencha com as informações de extensões de arquivos que serão usados pela ferramenta e o tipo de operação que estará associado com a ferramenta (lembre de fazer isso para "Compare" e para "Merge"). Escreva depois o comando e os argumentos da ferramenta. Para o KDiff3 use os seguintes argumentos:

- Para "Compare": %1 --fname %6 %2 --fname %7
- Para "Merge": %3 --fname %8 %2 --fname %7 %1 --fname %6 -o %4

Pronto! Agora você utilizará o KDiff3 para realizar merges e comparações de código-fonte.

Para usar outras ferramentas e todos os comandos e argumentos para cada uma delas recomendo o blog post de James Manning diff/merge configuration in Team Foundation.

Até a próxima e bons merges!

Trabalhando offline com o TFS 2010

2011-04-13T10:07:00.003-03:00

A comunidade do TFS lançou uma ótima extensão para facilitar o suporte para trabalhar offline quando você não estiver conectado ao servidor do TFS 2010.

A extensão GoOffline pode ser baixada do Visual Studio Gallery.

Desenvolva para Android com a plataforma .NET e o Visual Studio!

2011-04-08T08:50:00.004-03:00

Uma novidade muito legal para desenvolvedores da plataforma .NET e que utilizam o Visual Studio como sua ferramenta de produtividade: A Novell acabou de lançar um novo produto chamado Mono for Android.

O Mono for Android permite que desenvolvedores utilizem C# e o framework .NET para criar aplicações para celulares e tablets Android! E o mais importante: está integrado com o ambiente de desenvolvimento do Visual Studio! Aproveite para conhecer mais detalhes no site do Mono for Android.

Com esse lançamento e mais o produto anterior da Novell de nome MonoTouch (que permite desenvolver aplicações .NET para o iPhone, iPad e iPod) o .NET Framework está mais interoperável ainda!

TFS Web Access e Diagrama de Estados do ciclo de vida de itens de trabalho

2011-04-04T14:56:00.007-03:00

O Team Foundation Server ( TFS ) 2010 possui uma interface web que é instalada pelo wizard de instalação e configuração do software. Essa interface é uma visualização do "Team Explorer" na web.

Um dos recursos do Team Web Access é o de ver o diagrama de estados de um item de trabalho (requisitos, tarefas, defeitos, casos de teste, etc). Podemos fazer isso ao clicar no item "State Diagram" dentro do menu "Tools" da página de detalhes de um work item.

O comando mostrará um diagrama com todos os estados e transições do work item relacionado.

Além desse diagrama é possível visualizar todas as transições de estado que aconteceram em um work item específico, inclusive com a data e o nome da pessoa que fez a transição.

Com esses recursos a visualização do ciclo de vida de um item de trabalho fica muito mais simples e funcional!

Como verificar que o TFS 2010 está no ar e funcionando!

2011-04-01T08:20:00.003-03:00

Para verificar se o TFS 2010 está no ar e funcionando em sua completude você pode usar uma ferramenta simples mas bem interessante que faz um ping específico no servidor TFS 2010 e em seus serviços. Lembrando que você pode acessar todos os ativos de ALM do TFS 2010 através de protocolo HTTP ou HTTPS em uma única porta.

O comando:

pingtfs.exe /server:http://myserver:8080/tfs

Faça o download da ferramenta PingTFS.exe (.ZIP, 7,45 KB)

Aprendendo a testar profissionalmente com ambiente inovador de gestão de testes!

2011-03-24T14:28:00.009-03:00

Se você quer saber como testar aplicações e softwares profissionalmente, com uma solução que realmente ajuda na colaboração entre testers e desenvolvedores, então acesse esses recursos fantásticos sobre o Visual Studio Test Professional 2010 (em inglês):

Vídeos de 'Overview':
- Visão Geral do Visual Studio Test Professional
- Planejamento de Testes com VS Test Pro
- Autoria de casos de testes e execução de testes
- Automação de Testes com o VS 2010
- Monitorando a qualidade com o TFS 2010

Vídeos de 'Mão na Massa':

- Planejar testes, Escrever e executar casos de teste, Automatizar testes e Monitorar qualidade de aplicações

Leituras:

- Guia para Avaliadores do VS Test Professional 2010 (Esse guia mostra passo a passo como instalar o TFS 2010, como instalar o VS Test Professional 2010 e contempla uma série de tutoriais passo a passo para conhecer as principais funcionalidades da solução)
- Hands-on-Labs
- 5 capítulos gratuitos (toda a Parte III sobre testes) do livro Professional ALM with Visual Studio 2010

Downloads:

- Trial do Visual Studio Test Professional 2010
- Trial do Team Foundation Server 2010
- Download da máquina virtual pública com TFS 2010, Visual Studio 2010 Ultimate e VS Test Professional 2010 instalados e configurados

Bons estudos e prepare-se para se impressionar com as facilidades do ambiente de testes do Visual Studio ALM!

Como fazer merges entre branches não relacionados com o TFS 2010

2011-03-23T10:50:00.011-03:00

O TFS 2010 é uma solução de Gestão do Ciclo de Vida de Aplicações (ALM - Application Lifecycle Management) completa. Um dos recursos disponíveis é o controle de versões avançado e extremamente poderoso.

O TFS 2010 Source Control permite a criação de branches, inclusive quando necessário com relações e hierarquias pai-filho entre branches. Realizar o merge entre branches relacionados pode ser feito via linha de comando ou diretamente da interface gráfica do Team Explorer.

No exemplo abaixo podemos ver uma hierarquia de branches:
Se pedirmos para realizar um merge a partir do branch HotFix ele abrirá a seguinte janela de wizard:

Notem que não aparece a opção para realizar um merge de HotFix para Dev ou HotFix para Prod. Apenas de HotFix para QA. Isso acontece porque HotFix só está relacionado com o branch QA.

Para fazer um merge entre branches não relacionados, o TFS 2010 dá a opção de realizar um baseless merge. O baseless merge deve inicialmente ser feito via linha de comando (no TFS 2010, mas via interface gráfica já é um pedido de usuários do produto e provavelmente aparecerá em novas versões do Team Foundation Server). O comando para fazer o merge entre HotFix e Dev, sem passar pelo branch QA, seria o seguinte:

tf merge /baseless Hotfix Dev /recursive

Após a realização de um baseless merge, via linha de comando, a interface do Team Explorer já mostra o merge realizado através de uma linha pontilhada ligando os branches não relacionados. E outra vantagem é que nos próximos merges entre esses branches já é possível usar a própria interface gráfica!

Do ponto de vista teórico não é recomendado fazer merges entre branches não relacionados, mas é possível com o TFS 2010! Para mais dicas de estratégias de branching recomendo o Visual Studio TFS Branching Guide 2010.

Novidades do Visual Studio 2010 e TFS 2010 para o carnaval!

2011-03-09T08:32:00.004-03:00

Essa semana temos quatro grandes novidades e anúncios na linha de produtos do Visual Studio e ALM da Microsoft.

1 - Service Pack 1 do Visual Studio 2010 - O SP1 do VS 2010 também inclui recursos e correções para o Microsoft Test Manager (solução de gestão e execução de testes da Microsoft) e para o Lab Manager (gerenciador de máquinas virtuais para laboratórios de testes e homologação). Acesse a descrição detalhada do VS 2010 SP 1 para conhecer tudo que mudou.

2 - Service Pack 1 do Team FoundationServer 2010 (TFS 2010) - O SP1 do TFS 2010 possui uma série de melhorias e também de correções. Acesse a descrição detalhada do TFS 2010SP 1 para saber o que há de novo.

3 - Novo Feature Pack com a integração entre Project Server e TFS - Esse novo pacote é um grande avanço para empresas que querem eliminar o abismo que muitas vezes separa a gesão do ciclo de vida das aplicações e a gestão de portfólio de projetos. Essa integração torna automática e bidirecional o compartilhamento de informações entre o TFS (solução de ALM) e o MS Project Server (solução de gestão de portfólio de projetos). Para conhecer mais detalhes dessa integração vale a pena ler o blog post de Brian Harry sobre a versão beta do TFS-Project Server Integration.

4 - Usuários virtuais ilimitados para testes de carga com o Visual Studio 2010 - Esse foium anúncio fantástico sobre o produto. Anteriormente o VS 2010 Ultimate tinha um limite de 250 usuários virtuais para testes de carga e era necessário comprar pacotes adicionais de 1.000 em1.000 usuários. Agora esse limite acabou :) ! Quem tiver o Visual Studio 2010 Ultimate com assinatura MSDN pode usar a quantidade de usuários virtuais que desejar! O objetivo da Microsoft é democratizar o acesso a esse recurso essencial para melhorar a qualidade de aplicações que terão uma grande quantidade de acessos. Mais detalhes sobre esse assunto podem ser encontrados no anúncio do blog do time de testes do Visual Studio.

Aproveitem as atualizações e correções dos service packs e os novos recursos para melhorar ainda mais a qualidade de suas aplicações e a visibilidade dos projetos nas organizações!

Video e mini curso sobre desenvolvimento em times usando Eclipse e JEE com ALM

2011-01-26T09:50:00.005-02:00

Fiz um webcast muito interessante sobre a importância de soluções para apoiar e potencializar a colaboração e a produtividade do trabalho colaborativo de times. O foco foi mostrar como os principais recursos da solução de ALM da Microsoft atendem ambientes heterogêneos (Linux, MacOS, Java, PHP, Delphi, PowerBuilder, COBOL, Oracle, etc) e não só .NET. Nesse vídeo falei especificamente sobre a integração simples e direta com a plataforma Java Enterprise Edition e com o Eclipse como IDE. Demonstrei as tecnologias Microsoft disponíveis para os desenvolvedores Java gerenciarem todo o ciclo de vida de suas aplicações JEE.

Mostrei como é simples e intuitivo usar a solução de ALM (Application Lifecycle Management) da Microsoft para controlar versões de artefatos, realizar governança do processo de desenvolvimento de forma transparente ao desenvolvedor, facilitar o uso de metodologias Ágeis e realizar builds automatizados avançados. Veja então o vídeo sobre desenvolvimento em times usando Eclipse e JEE com ALM

Aproveitando o assunto: ministrarei um mini-curso gratuito a convite da Globalcode sobre desenvolvimento e testes de aplicações JEE e .NET usando o ALM da Microsoft no da 31 de janeiro de 2011. Será uma apresentação muito mais completa onde também tratarei de soluções de testes manuais e automatizados. Aproveitem porque o curso é gratuito e também será transmitido via webcast. Aguardo vocês lá presencialmente ou via webcast!

Desenvolvendo em Java no Eclipse com o Team Foundation Server (TFS) 2010

2010-12-22T09:36:00.029-02:00

O Team Foundation Server 2010, servidor do Visual Studio 2010 ALM (Application Lifecycle Management), é o responsável por ser o repositório único e centralizado onde são armazenados o controle de versões, os itens de trabalho, requisitos, casos de testes, scripts de testes e os builds automatizados. A Microsoft, para a versão 2010 do seu ALM, investiu fortemente no suporte a ambientes heterogêneos e não só na plataforma Windows e .NET. Esses investimentos se materializaram em diversos recursos, porém o foco nesse artigo é falar sobre a facilidade de usar todos os recursos de controle de versões avançado, gestão automatizada de builds, itens de trabalho e planejamento e relatórios em tempo real para o Eclipse e para desenvolvedores Java, JEE, Ruby, C (entre outras linguagens).

A Microsoft oferece com a versão 2010 do Team Foundation Server um plugin para a IDE Eclipse chamado Team Explorer Everywhere. Não, ninguém está lendo errado :) . Hoje a Microsoft possui uma vasta equipe desenvolvendo software em Java e até mesmo em ambientes Linux. Essas equipe criou o Team Explorer Everywhere para reforçar ainda mais o comprometimento da Microsoft com todas as empresas que desejam usar a solução de ALM com melhor custo/benefício e melhor usabilidade do mercado de desenvolvimento de software.

Desse modo, desenvolvedores podem utilizar todos os recursos do TFS a partir de sua IDE. E um importante reforço: esse plugin funciona em Eclipses instalados em um Linux, Unixes e Macs! Mas e os builds automatizados? Não há problemas: com o TFS Build Extensions Power Tools o TFS 2010 pode executar scripts de build em Maven ou Ant! Inclusive recursos inovadores da Microsoft como o Gated Check-in e o Shelve estão disponíveis para desenvolvedores Java no Eclipse!

Mas vamos mostrar algumas telas para reforçar a facilidade e usabilidade do plugin do Eclipse integrado ao TFS 2010 (comentário interessante: já demonstrei para muitos desenvolvedores e arquitetos Java e eles realmente ficaram impressionados com a facilidade de uso da ferramenta. É a filosofia de usabilidade da Microsoft se incorporando em outras plataformas!).

A figura abaixo mostra a perspectiva "Team Foundation Server Exploring" disponível no Eclipse.

Essa figura apresenta algumas visões interessantes disponíveis para o TFS.

Quando arquivos Java são alterados no Eclipse, automaticamente eles são mostrados na view "Pending Changes". Nessa view é possível fazer um shelve/unshelve e o check-in das alterações. Além disso é possível associar um item de trabalho (como uma tarefa, um defeito, um requisito) a essas mudanças de código, criando assim governança do processo de desenvolvimento de software de uma forma fácil e Ágil para os desenvolvedores.

Essa figura mostra detalhadamente a view de "Pending Changes" em um Eclipse rodando no Ubuntu Linux!
Na perspectiva do TFS podemos visualizar todos os dados do projeto como itens de trabalho, documentos, builds e o controle de versões.

As queries de itens de trabalho podem ser vistas no Eclipse, inclusive, no formato hierárquico que é uma novidade do TFS 2o10.

Todos os relatórios automáticos do TFS (o gráfico abaixo é um dos relatórios do template Scrum) são visíveis através do Eclipse:

E, finalmente, podemos ver criar um novo build automatizado diretamente no Eclipse.

E esse build pode usar como script de build tanto um arquivo Ant como um arquivo Maven. Lembrando: É o TFS 2010 da Microsoft disparando um script de build Java e incorporando seus resultados dentro do Team Foundation Build!

Termino o artigo reiterando que é muito bom ver a evolução da solução de ALM e desenvolvimento de software da Microsoft. Hoje as empresas com ambientes heterogêneos podem utilizar uma solução de ALM com baixo custo, alta escalabilidade, grande usabilidade, suporte da Microsoft e com a solução de testes manuais e qualidade mais inovadora no mercado!

Desenvolvendo em COBOL e Mainframe com TFS 2010 e Visual Studio 2010

2010-12-13T16:07:00.002-02:00

Um dos grandes investimentos da Microsoft, na versão 2010 do Visual Studio e do Team Foundation Server, se voltou para o atendimento a ambientes heterogêneos. Isto é, atender outras plataformas e tecnologias diferentes do .NET. Um dos principais recursos foi a incorporação de plugins para Eclipse e ambiente de linha de comando para ambientes Unix. Isso foi feito com a aquisição da empresa TeamPrise.

Hoje já temos casos de empresas que utilizam todo o ambiente de gestão de configuração, governança e rastreabilidade no ciclo de vida para aplicações COBOL. Um exemplo documentado é o estudo de caso de TFS 2010 para gerenciar aplicações COBOl e PL1 na NRB.

Hoje em dia existem várias soluções que permitem o desenvolvimento COBOL e Mainframe dentro de uma IDE na plataforma Windows. Um exemplo é o Natural for Eclipse. Como ele foi construído na plataforma Eclipse, nosso plugin Visual Studio Team Explorer Everywhere permite que todo o controle de versões do código-fonte e toda a orquestração do processo de desenvolvimento sejam realizados dentro do mesmo ambiente do desenvolvedor.

Esse atendimento a ambientes como o COBOL (entre outros) facilita a gestão unificada das aplicações de uma corporação e melhora a governança de TI e do processo de desenvolvimento de software como um todo.

Além disso, existe uma excelente solução para iniciar a modernização do seu legado que ainda está em Mainframe. A solução se chama Visual COBOL e é uma extensão completa para o Visual Studio 2010. Com ela você consegue baixar fontes feitos em COBOL (inclusive com JCL ou CICS!), compilá-los no framework .NET e fazer interfaces gráficas poderosas usando Windows Presentation Foundation, ASP .NET e Windows Forms. E além disso tudo pode usar recursos avançados do Visual Studio 2010 como análise de impacto de testes, IntelliSense, IntelliTrace e análise arquitetural da aplicação!

Portanto, você pode utilizar a solução de ALM da Microsoft que é robusta,escalável, de fácil utilização e com melhor custo-benefício do mercado também para um ambiente de alta plataforma como o COBOL ou o Natural e também para modernizar o legado de uma forma mais rápida e simples!

Testes Ágeis - Minha palestra no ALM Summit Brasil

2010-11-30T16:11:00.006-02:00

No dia 27 de novembro palestrei no evento ALM Summit Brasil. Foi um evento muito legal e que mostrou com bastante força os recursos inovadores da plataforma de Aplication Lifecycle Management da Microsoft, bem como o nível dos profissionais brasileiros que suportam e apóiam a implantação da solução em clientes por todo o Brasil.

Minha palestra foi sobre Testes em um mundo Ágil. Na primeira parte expliquei como é o processo de testes realmente Ágil (só enfatizando: uma iteração não é uma mini-cascata!). Na segunda parte falei sobre práticas e ferramentas que apóiam testes Ágeis e mostrei os recursos inovadores que a Microsoft lançou para melhorar a produtividade e a qualidade das equipes de testes, bem como aumentar a colaboração entre desenvolvedores e testers.

Segue minha palestra (não tem muito slide, porque a maior parte foi de demos!):

Testes em um mundo ágil

View more presentations from jpapo.

Desenvolvendo uma aplicação para o Windows Phone 7 com o Visual Studio 2010

2010-10-18T10:33:00.018-02:00

Neste domingo aproveitei para me aprofundar e entender melhor como desenvolver aplicativos para o Windows Phone 7. Entendi os aspectos básicos da plataforma, do modelo de desenvolvimento e já criei minha primeira aplicação útil para o Windows Phone 7: uma aplicação que calcula o preço teórico de uma opção através da equação de Balck-Scholes. E detalhe: tudo isso em 4 horas! Fiquei impressionado com a facilidade de desenvolvimento para o Windows Phone 7.

Nesse artigo tenho dois objetivos. O primeiro é explicar alguns conceitos úteis sobre o desenvolvimento com Windows Phone 7 e passar links e referências para materiais. O aegundo objetivo é o de mostrar minha aplicação e dar algumas dicas concretas do que fazer para resolver algumas necessidades que tive para construí-la.

A programação com o Windows Phone 7 é feita com alta produtividade utilizando a solução Microsoft Visual Studio 2010 Express for Windows Phone. Um detalhe muito importante: ela é gratuita! Caso você já possua alguma versão do Visual Studio 2010 em sua máquina, o VS 2010 Express for Windows Phone será instalado como um add-in para a sua versão do Visual Studio 2010. A solução não vem apenas com o clássico ambiente do Visual Studio 2010. Conta também com os seguintes softwares (reforçando... gratuitos também!):

- Windows Phone Emulator: O emulador do Windows Phone 7 para você testar e fazer debug de suas aplicações.
- Expression Blend 4 for Windows Phone: Uma ferramenta completa para os especialistas em interface de usuário. Ela facilita a criação de aplicações com interfaces mais rebuscadas e com mais recursos de animação.

Há duas grandes plataformas de desenvolvimento para o Windows Phone 7: Silverlight e XNA Game Studio. Essas plataformas foram escolhidas porque existem já milhares de desenvolvedores com conhecimento nelas. A escolha é simples: se estiver fazendo uma aplicação então use Silverlight. Se for criar um jogo use XNA (aliás, é a mesma plataforma usada para desenvolver jogos no XBox! ).

Para quem está acostumado a programar com Visual Studio, a experiência é muito similar.

Você encontra uma série de controles prontos para colocar na interface da aplicação Windows Phone, bem como pode alterar diretamente o XAML correspondente e que aparece ao lado da interface.

Antes de mostrar a aplicação vamos para algumas referências importantes para aprofundar:

- Livro Programming Windows Phone 7 de Charles Petzold (ainda em beta mas já tem bastante conteúdo)
- Windows Phone Developer Portal. Você deve se cadastrar para acessar. Para publicar sua aplicação no Market Place do windows Phone é preciso pagar uma taxa de 175 reais (para estudantes é gratuito... aproveitem!)
- Windows Phone Development no MSN
- Windows Phone 7 Developer Training Kit no Channel9

Vamos ao que interessa... ver como fiz minha aplicação para Windows Phone! Fazer só um Hello World não é muito útil, então resolvi criar uma aplicação que seria interessante inclusive para mim (também gosto de estudar sobre finanças e investir na bolsa!). É uma aplicação que calcula o preço teórico de uma opção sobre ação, utilizando a famosa fórmula fechada, baseada em equações diferenciais parciais, de Black-Scholes.

A tela inicial possui dois radio buttons para que o usuário selecione se quer calcular o preço de uma opção de compra (call) ou de uma opção de venda (put). Para realizar o cálculo é preciso colocar cinco parâmetros: preço da ação-objeto, preço de exercício da opção (strike), a taxa de juros anual, o tempo até a opção expirar e a volatilidade da ação-objeto.

Podemos visualizar na tela abaixo os campos preenchidos:

Quando o usuário tocar seu dedo no botão "Calculate!" o cálculo será realizado e a tela abaixo é mostrada para o preço de uma opção de compra:

Para uma opção de venda com os mesmos parâmetros a tela de resultados é essa:

Eu não podia deixar de validar se meus cálculos estavamcorretos, então comparei com uma calculadora on-line de precificação de opções. E estão exatamente iguais! Se não confiar em mim pode entrar na calculadora on-line e fazer o cálculo com os mesmos parâmetros :) !

Explicada a aplicação, vamos a algumas dicas que tive que pesquisar para resolver algumas necessidades.

Dica 1 -> Eu queria que o usuário só digitasse números ou símbolos (para decimais). Porém o teclado do TextBox aparecia com letras primeiro o que consumia um toque a mais. Para resolver isso basta colocar no XAML do textBox o seguinte: InputScope="Number". Assim um dos textBoxes ficou assim:

TextBox Height="70" HorizontalAlignment="Left" Margin="233,113,0,0" Name="X" Text="" VerticalAlignment="Top" Width="180" InputScope="Number" Grid.Row="1"

E pronto! O teclado aparece com os números e símbolos, quando o usuário toca o campo de texto, conforme a figura abaixo:

Dica 2 -> Navegação entre telas. Quando o usuário seleciona o botão "Calculate!" deve navegar para uma outra tela ( Result.xaml ) para mostrar o resultado. Uma navegação simples, sem passagem de parâmetros, é feita dessa forma:

NavigationService.Navigate(new Uri("/Result.xaml", UriKind.Relative));

Para passar parâmetros podemos usar strings (há outros jeitos de fazer, mas para minha aplicação simples com uma única tela e apenas seis parâmetros usei dessa forma), como em uma URI do protocolo HTTP. Exemplo:

NavigationService.Navigate(new Uri("/Result.xaml?optionType=" + optionType + "&stockPrice=" + S.Text + "&strikePrice=" + X.Text + "&time=" + T.Text + "&interestRate=" + R.Text + "&volatility=" + V.Text, UriKind.Relative));

Esse método é chamado dentro do evento de clique do botão Calculate, que se encontra no code-behind da MainPage ( MainPage.xaml.cs ):

private void CalculateBS_Click(object sender, RoutedEventArgs e)
{
string optionType;

if (radioButton1.IsChecked == true)
optionType = "c";
else
optionType = "p";
}

NavigationService.Navigate(new Uri("/Result.xaml?optionType=" + optionType + "&stockPrice=" + S.Text + "&strikePrice=" + X.Text + "&time=" + T.Text + "&interestRate=" + R.Text + "&volatility=" + V.Text, UriKind.Relative));
}

Na tela Result.xaml eu coloquei um botão "Back to Calculator". Só precisei colocar o seguinte para voltar para a página anterior:

private void Back_Click(object sender, RoutedEventArgs e)
{
NavigationService.GoBack();
}

Dica 3 -> Para receber os parâmetros em Result.xaml fiz o seguinte no code-behind do método "OnNavigatedTo" :

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
base.OnNavigatedTo(e);

string optionType;
string stockPrice = "";
string strikePrice = "";
string time = "";
string interestRate = "";
string volatility = "";

NavigationContext.QueryString.TryGetValue("optionType", out optionType);
NavigationContext.QueryString.TryGetValue("stockPrice", out stockPrice);
NavigationContext.QueryString.TryGetValue("strikePrice", out strikePrice);
NavigationContext.QueryString.TryGetValue("time", out time);
NavigationContext.QueryString.TryGetValue("interestRate", out interestRate);
NavigationContext.QueryString.TryGetValue("volatility", out volatility);

...

}

Dica 4 -> Como o meu método que calcula Black-Scholes usa double nos parâmetros monetários usei o conversor do C# para transformar cada string em uma double, conforme exemplo:

double dstockPrice = Convert.ToDouble(stockPrice);

Usei o conversor para transformar o retorno em double para String, de forma a mostrar o resultado em um TextBox:

BSResult.Text = Convert.ToString(optionPrice);

Dica 5 -> Minha solução foi composta de dois projetos: um projeto "Windows Phone Application" e o outro uma "Windows Phone Class Library". Na Class Library coloquei minha classe StockOption.cs. Recomendo fazer esse trabalho de separar os detalhes e validações de interface do seu "código de negócio". Isso o tornará reutilizável e facilitará o entendimento futuro da solução. Isto significa que você pode fazer uma boa arquitetura de aplicação também com um projeto Windows Phone 7, assim como já fazemos hoje para aplicações corporativas!

Para publicar uma aplicação no Market Place (e deixá-la disponível para os Windows Phones diretamente do celular) basta se logar com seu Windows Live ID no Windows Phone Developer Portal.

Aí estão minhas dicas! Essa aplicação que criei já estará disponível gratuitamente no Market Place do Windows Phone 7! Vou posteriormente incrementá-la para calcular as gregas, volatilidade implícita, entre outros recursos. Aí vou cobrar um pequeno valor pela versão mais completa. Desenvolver aplicativos para o windows Phone 7 é mais uma ótima opção para desenvolvedores ganharem um dinheirinho extra :) !!!

Mitos e Verdades sobre o Visual Studio 2010 ALM - Parte 2

2010-10-12T17:06:00.010-03:00

Essa é o segundo artigo da minha série sobre mitos e verdades do Visual Studio ALM. Hoje falarei sobre três pontos: abertura da plataforma, requisitos e controle de versões.

A plataforma de ALM e desenvolvimento da Microsoft é hoje uma das mais abertas do mercado. Prova disso está nos mais de dois mil add-ins e extensões encontrados na Visual Studio Gallery. São extensões gratuitas ou pagas que potencializam ainda mais a plataforma. Além dessa gama de produtos já existentes, a Microsoft fornece uma documentação abrangente e completa da API do TFS 2010, do TFS 2010 SDK e de como extender o Visual Studio 2010. Podemos ainda encontrar centenas de aplicações, documentações e recursos extras disponíveis no CodePlex, a comunidade open source relacionada a produtos Microsoft.

O outro assunto importante e rodeado de mitos é o de Requisitos. Muitos acham que a solução de ALM da Microsoft não possui recursos para o problema de gestão de requisitos. Pois bem, para começar eliminado esse mito aponto para o Visual Studio 2010 Team Foundation Server Requirements Management Guidance. É um guia contendo "apenas" um pouco mais de 150 páginas só sobre como implementar gestão de requisitos de forma completa, tanto de modo Ágil como para atender REQM e RD do CMMI!

O guia explica como implementar a gestão de requisitos, utilizando uma série de recursos disponíveis no VS 2010 ALM. Os work items hierárquicos, que são uma novidade da versão 2010, constituem o ponto central da solução. Com eles podemos criar queries ou relatórios de rastreabilidade utilizando o SQL Server Reporting Services. Recomendo também uma extensão gratuita para o Visual Studio 2010 chamada Work Item Visualizer. Com ela é possível ver graficamente todas a rastreabilidade e dependências de um work item.

Recomendo também olhar uma ferramenta paga de parceiro: O TeamSpec, que permite integração direta entre o Microsoft Word e o Team Foundation Server 2010. Assim obtemos uma solução similar a outras ferramentas de gestão de requisitos do mercado! Não podemos esquecer também dos workbooks, que integram as estórias de usuário ou os requisitos com o Excel. São planilhas especiais que facilitam e potencializam o processo de trabalho de priorização, organização e gestão de requisitos pelos analistas de negócio e product owners. A prototipação da aplicação também é um ponto fortemente atendido na plataforma, através da ferramenta SketchFlow. Recomendo olhar com atenção os recursos e facilidades de prototipação e feedback da prototipação disponíveis.

O terceiro assunto é o de controle de versões. Hoje o TFS 2010 possui todos os recursos de um sistema avançado de controle de versões como activity-based change management (integração de check-in de código com atividades), branches, merges, histórico visual de merges, integração com build automatizado, gated check-ins, entre outras. Para facilitar o trabalho do gerente de configuração recomendo fortemente o Visual Studio TFS Branching Guide 2010, guia completo e avançado sobre controle de versões feito pelos VS ALM Rangers.

Minha lista de eventos em outubro de 2010

2010-10-10T15:53:00.003-03:00

Neste mês de outubro tenho uma agenda razoável de eventos como palestrante! São eventos muito bons e sempre interessantes para aumentar conhecimento em uma série de assuntos.

Dia 16 de outubro: Plataforma Java versus Plataforma .NET, que ocorrerá na UNIP em São Paulo. O evento não tem como objetivo a disputa, mas sim mostrar ambas as plataformas de forma aberta e objetiva. Minha palestra entrou no tema 8, sobre Metodologias e ALM, e será sobre o Team Foundation Server 2010 ( TFS 2010 ) e a solução de Application Lifecycle Management ( ALM ) da Microsoft.

Dia 19 de outubro: Encontro Mensal da ALATS-SP, que ocorrerá na sede da Microsoft. Minha palestra tratará sobre testes e qualidade com o Visual Studio ALM.

Dia 25 de outubro de 2010: Agile Tour São Paulo 2010, que ocorrerá em São Paulo. Minha palestra será sobre Test Driven Development com Visual Studio 2010.

Dia 27 de outubro: Seminário Mineiro de Qualidade de Software, que ocorrerá em Belo Horizonte. Minha palestra tem como título - O fim do 'Mas na minha maquina funciona!' - Melhorando a colaboração e a produtividade de testers e desenvolvedores.

Aproveitem para investir em conhecimento nesse mês. Tem muita coisa boa acontecendo no nosso mundo de engenharia de software!!!

Microsoft TechEd Brasil 2010 - Minha Agenda de Palestras

2010-09-03T11:59:00.004-03:00

Caros,

O Microsoft TechEd Brasil 2010 acontece do dia 13 até o dia 15 de setembro de 2010. Eu estarei lá e resolvi compartilhar aqui a agenda de palestras que assistirei.

Minha Programação do dia 13/09/2010

09:00 - 12:00 Sessão Geral

13:45 - 15:00 Dicas, truques do Visual Studio 2010 e novas funcionalidades do Visual Basic e C#

15:30 - 16:45 Teste de software com o Visual Studio 2010: Parte 1 de 2

17:15 - 18:30 Tudo o que você precisa saber sobre Scrum e Visual Studio ALM em 150 min - Parte 1

18:45 - 20:00 Tudo o que você precisa saber sobre Scrum e Visual Studio ALM em 150 min - Parte 2

Minha Programação do dia 14/09/2010

09:00 - 10:15 Criando Rich Internet Applications (RIA) com ASP.NET AJAX e jQuery

10:45 - 12:00 Teste de software com o Visual Studio 2010: Parte 2 de 2

13:45 - 15:00 Primeiros passos no Team Foundation Server 2010

15:30 - 16:45 Desenvolvimento heterogêneo com o Microsoft Visual Studio 2010 Team Foundation Server: traga seus desenvolvedores Java, Mac, Linux e Eclipse a bordo

17:15 - 18:30 Aumentando a produtividade através da Geração de Código no Visual Studio

Minha Programação do dia 15/09/2010

09:00 - 10:15 Silverlight 4 e Expression Blend 4: Tecnologia e Ferramenta em suas Mãos

10:45 - 12:00 Criando protótipos com o Microsoft Expression Blend + SketchFlow

13:45 - 15:00 Discutindo sobre: Linq to Sql, Entity Framework Versus Stored Procedures

15:30 - 16:45 Entendendo a Plataforma de Aplicações do Windows Phone 7

17:15 - 18:30 Explorando as ferramentas de arquitetura do Visual Studio 2010

Abraços e até lá!

Mitos e Verdades sobre o Visual Studio 2010 ALM - Parte 1

2010-09-01T09:59:00.005-03:00

O Visual Studio 2010 da Microsoft não é mais só uma IDE focada em desenvolvimento de código. Ele é uma plataforma completa para o que se chama no mercado de Application Lifecycle Management (ALM). O ALM é um conjunto de letras que representa uma visão para melhorar todo o processo de produção de sistemas e software. Ele trata desde a requisição feita por um cliente ou stakeolder do projeto até a implantação em produção e manutenção contínua do sistema - passando por gestão de requisitos, planejamento e controle de projetos, arquitetura de software, desenvolvimento profissional, gestão de testes, gestão automatizada de builds e implantacão de sistemas. Também ajuda a solucionar problemas referentes à governança de TI, colaboração entre membros da equipe, desenvolvimento com equipes grandes e/ou distribuídas e orquestração de processos Ágeis ou tradicionais.

Neste primeiro de uma série de artigos vou falar sobre alguns mitos e as verdades relacionadas à plataforma de ALM da Microsoft, composta pela linha de produtos Visual Studio 2010 e pelo servidor Team Foundation Server (TFS) 2010. Existem muitas inverdades acerca dessa solução, muitas vezes até por falta de conhecimento do ecossistema de plugins e pacotes desenvolvidos pela comunidade open source .NET, especialmente no Codeplex e pelos Visual Studio Rangers.

A primeira grande realidade é que, hoje, a minha visão é a de que a solução da Microsoft é a mais completa no mercado de ALM. Ela fornece recursos e funcionalidades inovadoras, não encontradas em outras soluções, que aumentam radicalmente a produtividade da cadeia de produção de sistemas. Em outros artigos falarei em mais detalhes sobre algumas delas, mas só para dar o primeiro gostinho:
- Facilidades para que o arquiteto possa executar uma validação arquitetural da aplicação durante a execução de builds diários ou da integracão contínua. Assim a ferramenta detecta automaticamente se alguém violou alguma regra arquitetural.
- Registro de evidências em vídeo dos testes manuais executados
- Criação de testes funcionais automatizados a partir da execução de testes manuais, de uma maneira muito simples e rápida
- Desenvolvimento Ágil não só para código-fonte mas também para artefatos do banco de dados
- Geração automatizada de dados mascarados para BD de desenvolvimento e homologação
- Gestão real de laboratórios de testes, homologação e produção (Lab Management) - enfatizando a gestão, implantação e criação de snapshots em máquinas virtuais para reduzir o custo de ambientes físicos
- Recursos para o tester associar facilmente a um defeito os logs para que o desenvolvedor reproduza o histórico de debug de um erro encontrado em um teste. Além disso, é possível associar a um defeito um snapshot de uma máquina virtual, para que o desenvolvedor possa ter inclusive o ambiente real onde os testes foram realizados!

Bom, os recursos acima foram apenas um preview do que virá em próximos artigos. Vamos ao objetivo desse primeiro artigo: mostrar as verdades por trás de cada mito comentado no mercado sobre o Visual Studio 2010.

Mito 1 - O Visual Studio ALM é realmente bom, pena que só funciona para plataforma .NET.
Verdade 1 - O TFS 2010, servidor do VS 2010 ALM, é o responsável por ser o repositório único onde são armazenados o controle de versões, os itens de trabalho e requisitos e os builds gerados automaticamente. Hoje a Microsoft já possui uma oferta de um plugin para o Eclipse: o Team Explorer Everywhere. Desse modo, desenvolvedores Java, JEE, Ruby, C (entre outras linguagens) podem utilizar todos os recursos do TFS a partir de sua IDE. E importante: esse plugin funciona em Eclipses instalados em um Linux e Unixes também! Mas e os builds automatizados? Não há problemas: com o Power Tools Build Extension o TFS 2010 pode executar scripts de build em Maven ou Ant.
Mas não é só isso: desenvolvedores que usam outra IDE como PowerBuilder, JDeveloper, NetBeans e etc também podem utilizar nativamente os recursos de controle de versões do TFS 2010! Como? No Codeplex é possível encontrar o SvnBridge. É um software que você instala no servidor TFS 2010. A partir desse momento, ele consegue ler requisições para o Subversion e convertê-las para um check-in/check-out no TFS 2010! Com essa ponte você pode usar qualquer tipo de cliente ou plugin Subversion para acessar o controle de versões do TFS 2010 diretamente de sua IDE preferida. Além disso, os testes automatizados e manuais podem ser executados em uma infinidade de plataformas, não só .NET. Resumindo: Os recursos de colaboração, governança, controle de versões, gestão de incidências e testes funcionam também em ambientes heterogêneos. Uma novidade para muitos que ainda entendem a solução ALM da Microsoft como viável apenas para quem usa .NET.

Mito 2 - O Visual Studio não suporta a UML 2.
Verdade 2 - O Visual Studio 2010 contempla os principais diagramas da UML 2. E não é só isso: usando o Visual Studio Visualization and Modeling Feature Pack você pode fazer engenharia reversa de seu código .NET e criar diagramas de classe e gerar código .NET a partir de seus diagramas de classe. Também permite a geração de gráficos de dependência para ASP .NET, C e C++ ! Resumindo: Hoje o Visual Studio 2010 suporta de maneira robusta a UML.

Mito 3 - O Visual Studio não é Ágil.
Verdade 3- Essa eu ouvi poucas vezes, mas confesso que fiquei impressionado pela falta de informação. Até porque hoje o Visual Studio 2010 é a ferramenta de desenvolvimento e de ALM que mais suporta a Agilidade, tanto nas práticas técnicas quanto nas de gestão. O TFS 2010 possui, além do MSF Agile, um template de Scrum desenvolvido em conjunto com o próprio Ken Schwaber (um dos criadores do Scrum). Além disso, possui recursos para testes de unidade que nenhuma IDE ainda possui. O VS 2010 detecta quais testes de unidade devem ser reexecutados após mudanças de código realizadas pelo desenvolvedor. Desse modo você pode executar só aquele subconjunto de testes de unidade que fazem sentido, diminuindo o tempo de execução de testes de unidade antes de cada check-in.
Outro recurso sensacional é o suporte a desenvolvimento de banco de dados de forma Ágil. O VS 2010 possui recursos para refactoring de bancos de dados, criação de testes de unidade para artefatos de BD, geração de massas de dados de testes no BD, gestão de mudanças e controle de versões do BD e automação do processo de upgrade de um BD em produção a partir das mudanças realizadas em desenvolvimento. Mas isso só deve funcionar com o SQL Server da Microsoft, alguns podem dizer. A grande notícia é que você pode usar grande parte desses recursos também com Oracle, através da ferramenta de parceiro TOAD Extension for Visual Studio (recomendo entrar no site e assistir ao impressionante vídeo!). Resumindo: Além de suportar todas as cerimônias Ágeis e de Scrum, o Visual Studio 2010 ainda suporta todas as práticas técnicas necessárias para se chegar na hiperprodutividade Ágil.

Bom, por hoje é só! Na parte 2 falarei de mais alguns mitos. Também tratarei aos poucos de cada um dos recursos e funcionalidades inovadoras da nova plataforma de desenvolvimento de aplicações e ALM da Microsoft.

Se tiver alguma dúvida ou já ouviu falar de algum mito referente ao Visual Studio pode mandar para mim. Quem sabe ela não entra na minha lista de mitos e verdades da próxima parte dessa série de artigos!

Palestrante no TDC 2010

2010-08-18T10:15:00.003-03:00

Serei um dos debatedores na mesa redonda da trilha de Testes do The Developer's Conference 2010. O TDC 2010 está com um preço simbólico que atraiu milhares de desenvolvedores para suas diversas trilhas de conhecimento. Recomendo fortemente a participação! Aproveite para se inscrever logo, porque as vagas estão no fim.

Para detalhes sobre minha presença acesse a trilha de testes do TDC 2010. A mesa redonda ocorre na sexta, dia 20 de agosto, a partir das 17 e 40.

Veja também o site principal do TDC 2010 para conhecer todas as novidades e palestras!

Palestra Agile Economics, realizada no Agile Brazil 2010, disponível

2010-06-26T08:02:00.004-03:00

No dia 24 de junho ministrei no evento Agile Brazil 2010 a palestra intitulada "It’s the Economy! - Agilidade, Indicadores Financeiros e Criação de Valor". Tive um bom público e creio que a palestra foi interessante, pois tratou de um tema que não é tão comentado, porém é fundamental. Disponibilizei a palestra, pois ela pode ajudar muita gente a demonstrar com mais enbasamento econômico e financeiro a motivação por trás da adoção da Agilidade. Também ajuda a formar bons product owners, que devem sempre buscam a maximização do valor de um projeto para a organização em que trabalha.

Quem quiser pode fazer o download da palestra Agile Economics via slideshare.

Ou então apenas fazer a leitura abaixo.

Agile Economics

View more presentations from jpapo.

Palestrante no Brateste 2010 - Tema sobre Perfil dos Testers em projetos Ágeis

2010-06-10T08:48:00.004-03:00

No dia 17/06 às 16:30 farei uma palestra, no evento BRATESTE 2010, com o tema: "O papel e o perfil dos testers em projetos Ágeis: Um novo paradigma para os analistas de testes no Brasil".

Esse é o 3o. seminário brasileiro sobre testes de software. Já palestrei e assisti às palestras em uma edição anterior e recomendo fortemente para todos os interessados na disciplina de testes de software. Ele ocorrerá em São Paulo, na Alameda Santos e próximo à Avenida Paulista.

Vejam a grade do BRATESTE 2010 e saibam mais sobre a programação completa. Vejos vocês por lá!

Pecado: O culpado da persistência do modelo Waterfall no desenvolvimento de Software?

2010-05-18T08:43:00.005-03:00

Quer entender melhor por que o manifesto Ágil fala em valorizar mais a colaboração com os clientes que a negociação de contratos? Um novo livro de um autor clássico dentro de nossa área de Engenharia de Software pode nos ajudar.

Estou lendo o novo e fantástico livro novo do Frederick Brooks, de título The Design of Design. Para aqueles da nossa área que ainda não o conhecem, Brooks é o autor do clássico livro de engenharia de software The Mythical Man-Month (que considero leitura obrigatória para executivos da área de TI).

Os primeiros capítulos do novo livro de Brooks são os mais interessantes, pois evidenciam claramente os problemas de se tentar realizar o design e construção de um produto seguindo um modelo cascata ( Waterfall ).

O capítulo 3 se chama "What's wrong with this model?" e é focado em explicar porque, nas palavras de Brooks: "o modelo cascata é errado e perigoso; precisamos superá-lo". Ele inclusive mostra como o próprio Winston Royce (suposto inventor do modelo cascata) critica fortemente o modelo cascata no mesmo artigo em que o descreve (Royce apenas o usou como uma referência do que NÃO funciona).

O resultado de um processo de produto Waterfall (onde os requisitos são completamente definidos antes do design e implementação começarem) é um conjunto de requisitos enorme e gigantesco, a união de muitas listas de desejos, levantada sem nenhum tipo de restrição. E, para piorar, a lista não é priorizada ou medida em termos de custo versus benefício. As forças sociais envolvidas acabam proibindo o conflitos dolorosos ocasionais gerados pela priorização.

Nas palavras de Brooks: "a proliferação de requisitos deve ser combatida, através de controle de natalidade e infanticídio destes requisitos". Ele inclusive dá um excelente exemplo de uma pesquisa realizada por um comitê nacional americano em projetos militares dos EUA: "Os projetos extremamente bem sucedidos tem um ou muito poucos objetivos e urgência de cronograma. Esses projetos começam com poucos requisitos de alto nível. Enquanto o desenvolvimento procedia, estes eram quebrados em requisitos mais específicos. Estes requisitos eram controlados e priorizados fortemente por gerentes capazes que continuamente balanceavam funcionalidade em relação a custo e prazo".

Aí vem a grande pergunta de Brooks no capítulo 4, de título "Requirements, Sin and Contracts": como podemos explicar a persistência de um modelo perigoso como o Cascata, quando já sabemos através de evidências maciças levantadas durante quase um quarto de século de que o modelo espiral/iterativo produz melhores resultados?

Antes da resposta, vamos supor o seguinte:
- O cliente ficará feliz em pagar para o seu fornecedor um preço justo pela sua experiência e trabalho.
- Ele conseguiu um fornecedor que age e usa suas habilidades para servir aos interesses reais dos clientes. Este fornecedor também realiza seu trabalho sempre almejando construir produtos com alta qualidade na melhor proporção de custo-benefício, dentro do prazo e orçamento.
- Todos são honestos, verdadeiros e a comunicação entre eles é excelente.

Tendo isso em vista, Brooks nos mostra que:
- Um contrato que pague o custo do fornecedor mais um bônus por metas irá dar ao cliente e ao fornecedor o melhor valor por dólar investido.
- Um modelo de processo espiral e iterativo vai gerar o produto mais apropriado para as necessidades principais do cliente.

Como podemos então explicar a existência de tantos projetos ainda seguindo um processo cascata? A resposta: Pecados... Especialmente Orgulho, Ganância e Preguiça.

Muitos olham as suposições acima e falam: "Essas suposições nunca ocorrem! Os humanos são pecadores e não podemos confiar na motivação do outro. Como os humanos são pecadores, não podemos nos comunicar perfeitamente". Por essa razão que entram contratos escritos. Precisamos de contratos para a proteção de faltas dos outros e para evitar nossa própria tentação de cometer transgressões.

E então, chegamos no ponto de Brooks: "Claramente, é a necessidade por contratos dentro de uma mesma organização ou entre organizações que força a descrição muito precoce de objetivos, requisitos e restrições detalhados". Portanto, segundo Brooks (e concordo com ele!), a necessidade por contratos detalhados melhor explica a persistência de um modelo errado como o cascata para projetar e construir sistemas complexos.

Quer saber mais sobre soluções interessantes para contratos de desenvolvimento de sistemas (ou implantação de ERPs e outros sistemas prontos que necessitam de customização) ? Vide meu artigo e apresentação sobre contratos com o título Contratos e Scrum: The Good, The Bad and the Ugly e também a palestra em vídeo que ministrei sobre contratos no Falando em Agile .

Minha presença no painel WIRE 2010 sobre reuso de software

2010-04-27T08:15:00.004-03:00

Minha presença está confirmada no painel da indústria do evento WIRE (Workshop para Introdução de Reuso em Empresas) 2010. A idéia será discutir o estado atual do reuso de software no Brasil e no mundo. Um momento informal para tirar dúvidas, levantar discussões e comentar cases. Outros profissionais também já confirmaram.

O blog do Rise (Reuse in Software Engineering) fez um post sobre o assunto. Acessem o post sobre a presença de José Papo no painel para obter maiores informações sobre o evento.

Por que Agile e Lean funcionam? Ou como explicar para seus executivos e líderes a hiperprodutividade que esses tais de agilistas conseguem!

2010-03-31T08:29:00.014-03:00

Analisando as pesquisas sobre sucesso de projetos encontramos números interessantes. De acordo com o Chaos Report de 2009, em torno de 30% dos projetos de TI são bem sucedidos. Enquanto isso, surveys sobre Agilidade mostram que em torno de 80% dos projetos Ágeis terminam com sucesso. E mais que isso: empresas como a SalesForce.com obtiveram uma melhoria de quase 400% no valor gerado após a adoção da cultura Ágil, em torno de 70% de redução nos defeitos e 50% de redução no time to market para lançamento de novas versões de seus produtos.

Será mágica? Será Bala de prata? Não. Então como explicar os números impressionantes acima?

Vou tratar um pouco dos 'segredos' do Agile / Lean funcionar tão bem quando ocorre uma mudança de paradigma real dentro da organização.

Os dois pilares do Lean (e que podem ser encontrados também embutidos no Manifesto Ágil) são:
- Respeito pelas pessoas
- Melhoria contínua

Podemos resumir esses dois pontos nessa frase: "A raiz do Lean/Agile é ser um eterno insatisfeito com o status quo. Você tem que se perguntar continuamente: 'Por que estamos fazendo isso?' ". Portanto é possível compreender que o princípio de Eliminar desperdícios do Lean está umbilicalmente relacionado com o pilar positivo da melhoria contínua e da eterna insatisfação com a mesmice.

Mas vocês devem estar se perguntando: Como isso explica a hiperprodutividade Agile? Vamos explicar agora, mas lembre-se de não tirar de sua cabeça os pilares: Respeito pelas pessoas e melhoria contínua com eliminação de desperdícios.

Quando ocorre uma mudança de paradigma para o Lean, as pessoas da organização voltarão seus esforços para eliminar tudo aquilo que não agrega valor na cadeia produtiva. O livro dos Poppendieck levanta uma série de elementos para identificar os geradores de desperdícios na área de desenvolvimento de software. Mas eu vou focar nos dois mais importantes e que geram o maior impacto inicial na produtividade da empresa:

- Projetos desnecessários
- Requisitos desnecessários

A adoção estratégica de Lean deve iniciar pelo esforço de Gestão Ágil de Portfólio de Projetos. Pela elaboração de business cases enxutos e continuamente avaliados para cada projeto da empresa. Conforme descrito por Donald Reinertsen em seu livro Desenvolvendo Produtos na Metade do Tempo: eliminar projetos com baixo retorno vai gerar mais velocidade no time to market dos projetos restantes. Apesar de contra-intuitivo, quando você corta projetos você entrega mais projetos num time to market menor! Esse nível mais estratégico do portfólio de projetos é pouco tratado em processos ágeis como Scrum, XP, OpenUP, etc. Porém é fundamental para a busca da hiperprodutividade.

O próximo nível é o de requisitos desnecessários. É aí em que os processos ágeis possuem práticas e mecanismos orientados para que o desperdício de criar requisitos de pouco valor não ocorra. Aí também entra a necessidade de boas pessoas e bom time. Um bom product owner (desgraçado ganancioso, como meu amigo Yoshima gosta de resumir) é fundamental para que o desperdício (quase uma hemorragia, já que segundo o Chaos Report quase metade dos requisitos não agregam valor maior que o custo para produzí-los) estanque.

Além disso, a filosofia e práticas da Agilidade/Lean focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. Nas palavras do próprio Peter Drucker: "Knowledge workers must take responsibility for managing themselves".

No tocante à gestão de projetos também temos efeitos benéficos. O PMBOK já fala sobre o clássico ou quadrante mágico de variáveis do projeto. Ele é composto por escopo, custo, prazo e qualidade. Há também uma lei em relação a esse quadrante: das quatro variáveis, você só pode fixar três... uma irá variar.

Num projeto tradicional cascata e com preço fixo (ainda no Brasil esse é o modelo mais usado, portanto o chamo de tradicional por causa disso) é fixado o custo, o prazo e o escopo. Acho que é fácil entender agora porque a maioria dos projetos de TI falha do ponto de vista dos stakeholders: o que varia é a qualidade... e ela varia lá pro fundo do buraco!

Uma empresa Ági/Lean, entendendo que defeitos são o terceiro grande gerador de desperdícios, muda isso. Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo. Essa mudança fundamental também ajuda a resolver o segundo desperdício: requisitos desnecessários. Quando o prazo e o custo são fixos, o product owner e os stakeholders terão que se esforçar ao máximo para atingir os objetivos de negócio almejados pelo projeto realizando apenas os requisitos importantes e de maior valor agregado, despriorizando ou eliminado requisitos de baixo valor. Veja como é exatamente isso que o cara que paga (sponsor) e outros stakeholders querem: um resultado (produto) de alta qualidade contendo o mínimo necessário de funcionalidades que resolvam seus problemas e necessidades de negócio, e ainda com a facilidade de mudar de idéia no decorrer do projeto.

Algumas pessoas orientadas ainda pelo paradigma preço fixo costumam imediatamente perguntar o seguinte: isso significa que um projeto Ágil entrega menos escopo que um cascata? E respondo: Muito pelo contrário, ele entrega um escopo de maior qualidade e valor agregado para o negócio. E é isso que o faz ser visto como bem sucedido pela organização.

Em resumo: Por que Agile / Lean funciona? Porque o respeito pelas pessoas e a busca da melhoria contínua levam à hiperprodutividade. Mas como essa hiperprodutividade ocorre quando ocorre a mudança de paradigma? Ela ocorre porque eliminam-se desperdícios das mais variadas formas e devido ao foco no resultado com ritmo sustentável. Os principais itens que geram isso no início são:
- Eliminação ou redução de projetos de baixo valor agregado.
- Eliminação ou redução de requisitos de baixo valor agregado.
- Em relação ao quadrante de variáveis do projeto: fixar custo, prazo e qualidade e deixar variar o escopo.

Não é fácil resumir o segredo do sucesso de algo, mas precisamos tentar. Esses segredos é que explicam a executivos e stakeholders porque adotar a filosofia Ágil os levará a outro patamar e também esclarecerá que só o 'processo' Ágil e suas práticas não resolverão o cerne do problema. A organização precisa de um choque cultural para que a hiperprodutividade se torne uma realidade, assim como ocorreu na Salesforce e em outras empresas que precisam do desenvolvimento de software e sistemas para manter seus negócios.

Um breve pensamento para fechar: "O Modelo tradicional cascata é errado e perigoso. Nós temos que superá-lo." - Frederick Brooks, autor do livro 'The Mythical Man-Month', em seu novo livro 'The Design of design'

Visao: Um ingrediente chave para o sucesso de um projeto de desenvolvimento de produto

2010-03-09T09:05:00.003-03:00

Elaborar um consenso sobre a visão de um produto e de seus objetivos principais é constantemente citado como um dos ingredientes fundamentais para o sucesso de um projeto (que visa a construir um release desse produto). Essa afirmação é citada fortemente por Jim Highsmith em seu excelente livro Agile Project Management: Creating Innovative Products, 2nd edition.

O RUP (Rational Unified Process) já dizia isso claramente também em seu processo. Mas, como inclusive discutimos em uma thread da lista Scrum Brasil, a tendência da maioria das pessoas que adotaram o RUP foi de tranformá-lo em um processo cascata e com foco em artefatos. Vale lembrar que desde o início o RUP define em seus princípios um foco em resultados e em desenvolvimento iterativo com entrega contínua e constante de valor para os clientes. Por causa das deturpações e do foco em artefatos, muita gente "preenche" o documento de Visão. Esse é um erro grave e que não atende o objetivo de definir em colaboração os objetivos do projeto.

Se a Visão é tão importante em qualquer projeto de desenvolvimento de um produto, por que tantos times sofrem com a falta de Visão? A resposta é que criar uma Visão interessante, objetiva, realista e focada é difícil. Ainda mais difícil porque elaborar a Visão de um produto não é "preencher" um documento... é discutir colaborativamente, com TODOS os stakeholders, os porquês, os o quês (o quês de alto nível) e os trade-offs de um produto.

Alguns podem se perguntar: mas se o processo é Ágil/Iterativo e a natureza do desenvolvimento de um produto é algo volátil, como criar uma visão clara e firme? Essa dicotomia se resolve, de acordo com Highsmith, quando você lembra que os detalhes dos requisitos sim são voláteis, mas não a visão geral dos objetivos de negócio que devem ser atingidos.

Projetos que começam com um Visão clara do que precisam construir como produto e dos tradeoffs que enfrentam tem a seguinte vantagem: entregar dentro de um prazo e de um custo fixo. Prazo e custo fizo em processo ágil? Esse Papo tá de papo com a gente... ficou louco! Não... rs. Projetos que usam um processo Ágil podem ter prazo e custo fixo sim. O prazo e o custo podem ser fixos, o que variará é o escopo! E essa variação do escopo é ótima, pois conhecendo os objetivos de negócio do produto fica mais fácil tomar a decisão mais importante em um projeto de desenvolvimento de software: saber o que NÃO construir. A visão nos ajuda a entender o que é menos importante e que em muitas instâncias não irá ajudar a resolver os problemas dos stakeholders do projeto. Ajuda a eliminar ou despriorizar aqueles requisitos que raramente ou nunca serão usados, conforme pesquisa do CHAOS Report.

Não vou dar dicas e técnicas de como criar uma Visão interessante e útil (só uma :-) !). Outros autores já fizeram isso bem melhor do que eu poderia fazer nesse artigo. Recomendo que comecem pelo livro do Jim Highsmith que já citei acima. A dica que vou dar e que parte de diversos autores (Mike Cohn, Scott Ambler, Philipe Kruchten e Jim Highsmith) é: Com o consenso sobre a visão podemos iniciar as iterações do projeto para construir o produto final pedaço a pedaço. Não precisamos esperar TODOS os requisitos detalhados serem definidos. Se o produto é pequeno, uma única reunião com todos os stakeholders pode ser suficiente para elaborar essa Visão. Se o produto é médio ou grande, utilize a idéia da Iteração Zero (o mesmo que a famosa "Fase de Iniciação" do RUP).

Meu foco neste post foi lembrar e reforçar o seguinte: a Visão NÃO é um documento a ser preenchido (só de escrever essa frase me dá arrepios!). Ela é um esforço consensual do time de stakeholders para definir quais problemas precisam resolver, quais objetivos de negócio devem ser atingidos, o que esperam do produto final como solução e os trade-offs que devem ser respeitados. Lembre-se: o sucesso de um projeto de desenvolvimento de um produto depende diretamente do alinhamento da equipe com a Visão e os objetivos de negócio.

Beneficios do uso de processos ágeis no desenvolvimento de software

2010-02-09T14:03:00.003-02:00

Mike Cohn, no primeiro capítulo do seu livro Succeeding with Agile, elencou uma série de pesquisas e dados de teses acadêmicas que descrevem benefícios colhidos pela adoção de processos ágeis no desenvolvimento de software.

Os benefícios estão ligados às seguintes áreas:

- Produtividade e custo

- Engajamento dos funcionários e satisfação no trabalho

- “Time to market”

- Qualidade do Produto

- Satisfação dos Stakeholders

Como a apresentação em inglês dele é Creative Commons, resolvi traduzí-la para o português e disponibilizá-la no SlideShare para leitura e download.

Benefícios Reportados do Desenvolvimento Ágil

View more presentations from jpapo.

Selenium IDE - Dicas para testar aplicações Ajax e Portal

2010-02-08T13:39:00.005-02:00

Estou fazendo alguns trabalhos com o Selenium IDE para automação de testes funcionais de sites WEb. Aí vai uma dica muito interessante para quem trabalha com sites que usam pesadamente AJAX, portlets, javascripts e HTML dinâmico.

Podem-se encontrar em sites que usam AJAX, Portlets e DHTML alguns controles que possuem variação dinâmica em seu identificador. Veja, por exemplo, o ID desse controle gerado pela especificação de portlets Pluto:

id="Pluto_8A828179268FE1FD01268FE6FB8302AE__SELECTED_client_code"

Ao utilizar o Selenium IDE para gerar o script de teste automatizado, obtemos o seguinte comando em Selenese HTML:

type Pluto_8A828179268FE1FD01268FE6FB8302AE__SELECTED_client_code

O grande problema é que esse número muda de forma constante e aleatória. Como podemos tornar nosso teste no Selenium mais estável? Usando o comando contains dentro do XPath !

O comando modificado fica assim:

type //select[contains(@id,"Pluto_") and contains(@id, '_SELECTED_client_code')]

Fazendo essa pequena alteração obtemos scripts que conseguem trabalhar com identificadores dinâmicos que mudam aleatoriamente, algo comum em aplicações AJAX ou de portais . Uma dica fundamental para melhor uso do Selenium IDE.

A criação de valor em projetos de TI: A Agilidade como vantagem competitiva para maximizar o valor da empresa e para os acionistas

2010-01-13T14:54:00.014-02:00

Criação de valor é uma expressão que aparece freqüentemente e em diversos contextos diferentes. O primeiro dos doze princípios do manifesto ágil, por exemplo, diz: “Nossa prioridade principal é satisfazer o cliente através de entrega rápida e contínua de software de valor”. A criação e a gestão do Valor são os fundamentos da administração moderna e do próprio capitalismo. Porém, muita gente (dentro e fora da área de desenvolvimento de software) não entende os detalhes do conceito de criação de valor. Dentro de nossa área é ainda mais clara essa defasagem, considerando as estatísticas que mostrei em um artigo anterior: Mais da metade dos projetos de TI não criam valor (e inclusive destroem valor das empresas) e 84% das organizações não fazem nenhum tipo de business case. Tenho certeza que o presidente da sua empresa gostaria que você entendesse com clareza esse conceito da criação (ou destruição) de valor :-). Porque toda a decisão que gera um desembolso de dinheiro visando ganhos no futuro, isto é, um investimento (como a contratação de um novo profissional, compra de um equipamento, um treinamento dado à equipe pela empresa, etc) visa em última instância sempre a criação de valor para a empresa.

Para explicar a criação de valor vamos partir bem do início e responder à seguinte pergunta: qual o objetivo de uma empresa privada dentro do sistema capitalista? A razão primária é simples e básica: gerar lucros para os donos (acionistas) da empresa. Porém, a simples geração de lucro por si só é necessária, mas não é suficiente e veremos o porquê.

O lucro, no final, precisa agregar valor à empresa.Essa criação de valor só ocorre quando há lucro econômico, conceito já descrito pelo economista Alfred Marshall no século XIX. O lucro econômico é “aquele que resta para os donos do empreendimento, após deduzir os juros sobre o capital de terceiros e o custo de oportunidade empregados”.

Vamos mostrar um rápido exemplo para entender porque o lucro líquido por si só não representa criação de valor para a empresa e o acionista. Vamos supor que um empreendedor invista 100.000 reais em um ano abrindo sua empresa (suponha também que esse investimento foi todo gasto em salários) e consiga no final deste mesmo ano um lucro líquido de 105.000 reais. Isto é, seu investimento no começo do ano de 100.000 reais teve um retorno de 5% em um ano. Do ponto de vista do lucro puro e simples esse investidor obteve 5.000 reais a mais. Mas com a atual taxa de juros básica do Brasil, esse foi um investimento destruidor de valor neste ano específico. Porque se ele investisse em um ativo financeiro livre de risco, como um título público do governo brasileiro, poderia obter em torno de 8% (já sem impostos). Vale lembrar que o título de dívida pública possui um risco extremamente baixo, diferentemente de investir o dinheiro em uma empresa própria que possui um risco muitas vezes maior. Portanto o custo de oportunidade desse investimento teria de ser ainda maior que 8%. Isso explica muito o motivo da economia brasileira crescer tão pouco em períodos de juros altos: Por que vou correr o risco de empreender, se posso investir meu dinheiro no governo e ganhar quase a mesma coisa correndo risco quase zero?

Desse modo, para considerar se uma empresa criou valor em um período de tempo (portanto, criou lucro econômico) temos que descontar seus fluxos de caixa por um determinado custo de capital (às vezes chamado de custo de oportunidade, taxa mínima de atratividade ou taxa de desconto). Na sua essência, a taxa mínima de atratividade deve recompensar pelo valor do dinheiro no tempo, a inflação esperada e o risco associado ao destino desse capital. Portanto, essa taxa é formada em sua essência por: TNLR + PR, isto é, Taxa Nominal Livre de Risco Mais Prêmio pelo Risco. Nesse artigo não vou entrar em muitos detalhes de como calcular o custo de capital (farei isso em outro). O mais importante é entender o conceito de que a empresa só cria valor em um período quando realiza lucro econômico, isto é, levando em conta também o desconto do custo de capital empregado.

Um analista de investimentos usa a teoria de finanças chamada Valuation para precificar empresas e os ativos financeiros (como ações) que representam essas empresas. E essa teoria reconhece que o instrumento mais completo para a precificação de empresas e ativos é o Fluxo de Caixa Descontado. O FCD utiliza uma taxa de desconto para encontrar o valor presente líquido de um ativo ou empresa. Isto é, ela projeta lucros futuros e o valor terminal da empresa e depois soma esses lucros e valor terminal descontados pela taxa de juros para encontrar quanto vale a empresa hoje.

Uma pergunta que vocês devem estar se fazendo (caso tenham lido até aqui!!! he, he) agora: E o que isso tem a ver comigo e com o projeto em que eu estou trabalhando? Tem tudo a ver! Uma empresa nada mais é que o conjunto de decisões de investimento e projetos realizados no passado pela empresa, bem como projetos atuais que gerarão resultados futuros. O projeto em que você está trabalhando imobiliza capital da empresa que poderia ser usado em outro investimento. Portanto, espera-se que ele não só gere lucro, mas sim valor adicional acima do custo de oportunidade do capital empregado.

O método do Valor Presente Líquido também pode ser usado para um projeto específico e é um dos melhores para verificar se um projeto criará valor e também para comparar investimentos em projetos distintos. Um exemplo para entender como se fazem essas comparações:

Assumindo a mesma taxa de desconto de 20% para os três projetos.

Projeto 1:
Período Zero: -100.000,00
Período Um: 50.000,00 / (1 + 0,20) = 41.666,00
Período Dois: 50.000,00 / (1 + 0,20) ao quadrado = 34.722,00
VPL = -23.612,00

Projeto 2:
Período Zero: -100.000,00
Período Um: 100.000,00 / (1 + 0,20) = 83.333,00
Período Dois: 50.000,00 / (1 + 0,20) ao quadrado = 34.722,00
VPL = 18.055,00

Projeto 3:
Período Zero: -100.000,00
Período Um: 50.000,00 / (1 + 0,20) = 41.666,00
Período Dois: 100.000,00 / (1 + 0,20) ao quadrado = 69.444,00
VPL = 11.110,00

O projeto 1 destrói valor e os projetos 2 e 3 criam valor para a empresa. Sendo que o projeto 2 cria mais valor que o projeto 3. Note como a geração de receitas nos primeiros períodos é potencializada devido ao valor do dinheiro no tempo. Isso é muito importante para entender todo o conceito de criação/destruição de valor.

Agora que ficou mais claro o conceito de criação ou destruição de valor, vou aproveitar para mostrar como o processo de desenvolvimento de produtos pode gerar vantagem competitiva e aumento de valor quando bem empregado. Veremos também como o time to market e a gestão de releases de forma iterativa e bem planejada (do ponto de vista financeiro e técnico) se tornam ainda mais importantes quando analisamos um investimento com o ponto de vista do custo de oportunidade.

Primeiro vamos supor um sistema que demorará dois anos para ter todas as funcionalidades criadas (isto é, só será implantado no final do segundo ano. E sim, existem muitos projetos de TI ainda sendo feitos desse jeito, infelizmente) e vamos avaliar um ano de rendimentos desse projeto. Portanto, uma análise de três anos. Vamos usar uma periodicidade semestral para avaliar o fluxo de caixa descontado e definir como 5% a taxa de desconto semestral no período de análise:

Semestre 1: -50.000
Semestre 2: -50.000 / (1 + 0,05) = -47.619
Semestre 3: -50.000 / (1 + 0,05) ao quadrado = -45.351
Semestre 4: -50.000 / (1 + 0,05) ao cubo = -43.192
Semestre 5: 75.000 / (1 + 0,05) a quarta = 61.702
Semestre 6: 100.000 / (1 + 0,05) a quinta = 78.352
VPL em 6 semestres (3 anos): -46.108

Isso significa que nos 3 primeiros anos o projeto destruiu valor da empresa. Espera-se que do semestre 7 em diante isso se reverta. Exemplo:

Semestre 7: 125.000 / (1 + 0,05) a sexta = 93.276
VPL no semestre 7 (3 anos e meio) = 93.276 – 46.108 = 47.168

Agora vamos considerar o mesmo sistema, mas tendo lançamentos em produção a cada seis meses. Segundo Smith e Reinertsen, o lançamento no mercado antes dos concorrentes já gera um efeito de aumento de vendas e na margem de lucro que pode ser considerada. Mas nem vamos considerar esse efeito. Vamos considerar que a primeira versão, com um quarto das funcionalidades, consegue trazer em torno de 25% da receita. E essa receita vai aumentando a cada novo release com mais funcionalidades. Além disso, considerei um ganho um pouco menor nos semestres 5 e 6:

Semestre 1: -50.000
Semestre 2: -50.000 + 20000 / (1 + 0,05) = -28.751
Semestre 3: -50.000 + 35000 / (1 + 0,05) ao quadrado = -13.605
Semestre 4: -50.000 + 45000 / (1 + 0,05) ao cubo = -4.319
Semestre 5: 70.000 / (1 + 0,05) a quarta = 57.589
Semestre 6: 90.000 / (1 + 0,05) a quinta = 70.517
VPL em 6 semestres (3 anos): 31.431

Note que apenas mudando a estratégia da empresa conseguimos já no sexto semestre criar valor para a empresa. Se seguirmos para o semestre 7:
Semestre 7: 125.000 / (1 + 0,05) a sexta = 93.276

VPL no semestre 7 (3 anos e meio) = 93.276 + 31.431 = 125.157

Isso significa que a estratégia de releases curtos gerou 2,65 vezes mais valor que a estratégia de um único release gigantesco. Essa demonstração matemática e financeira explica quantitativamente a intuição de que entregas (releases) curtas em produção tendem, na grande maioria dos casos, a gerar maior valor que uma única entrega big-bang.

Como disse Jim Highsmith: “Métodos ágeis possuem o potencial de realizar uma gigantesca diferença na vantagem competitiva de uma empresa. A fórmula para o sucesso é simples: entregue hoje, adapte amanhã e continuamente. Apesar de este parecer um princípio simples ele precisa ser enfatizado o tempo todo para que os colaboradores da empresa nunca se esqueçam. Quando organizações ficam maiores, quando o compliance toma mais e mais o tempo do time, quando gaps de comunicação entre clientes e o time aumentam e quando os planos de projeto focam mais em artefatos intermediários intermináveis, entregar algo que gera valor para a empresa e para os clientes se perde”.

Essa análise interessante de Jim Highsmith fica mais fácil de compreender com os métodos financeiros quantitativos da medição de valor. Ela pode ser óbvia, mas como o próprio Highsmith comenta, isso muitas vezes se perde no dia a dia.

Como Steve Tockey já havia dito em seu livro “Return on Software”: só evoluiremos para uma verdadeira engenharia de software (e melhoraremos nossos números de sucesso) quando usarmos a engenharia econômica para tomar as decisões do dia a dia dos projetos de TI.

É claro que os números acima são estimativas de um único valor e que não levam em conta a incerteza. Em um próximo artigo vou mostrar algumas ferramentas fundamentais e fantásticas para quantificarmos as incertezas das estimativas, tanto de custos quanto de benefícios. Fiquem ligados... vai ser mind-blowing :-) !

Referências bibliográficas para aprofundamento em Finanças Corporativas e Orçamentação de Capital:

Lapponi - Projetos de Investimento na Empresa
Titman e Martin - Valuation
Póvoa - Como precificar ações
Smith e Reinertsen - Developing Products in half the time
Assaf Neto - Curso de Administração Financeira
Grinblatt e Titman - Mercados Financeiros e Estratégia Corporativa
Highsmith - Agile Project Management, 2nd Edition

Principles of Product Development Flow with Lean Product Development - Resenha

2010-01-06T09:55:00.005-02:00

O novo livro de Donald Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, é uma excelente e importante sequência de outros dois livros seus que considero essenciais a todos aqueles que desenvolvem produtos (desde um software até um produto farmacêutico ou eletrônico): Developing Products in half the time e Managing the Design Factory.

Neste seu mais novo livro, Reinertsen explica de forma rigorosa e utilizando princípios matemáticos, econômicos e financeiros porque o desenvolvimento lean (enxuto) de produtos e o desenvolvimento ágil funcionam.

Para mim, a parte mais importante do livro é o capítulo 2, de título "The Economic View". É aqui que ele descreve o que considero o mais importante objetivo de desenvolvimento de qualquer produto: Nossa meta principal com o desenvolvimento de produtos é realizar boas escolhas econômicas. Todos os outros objetivos (inovação, redução de desperdício, aumento de qualidade, diminuir o ciclo de desenvovlimento, etc) são intermediários para atingir essa meta principal. E a única forma de saber se vale à pena agilizar o ciclo de desenvolvimento, ou investir em qualidade, ou qualquer dessas outras metas é quantificando e entendendo o valor econômico de cada uma dessas decisões.

Recomendo fortemente o livro para aqueles que querem dar um salto gigantesco após compreender e usar Scrum. Scrum apenas otimiza localmente um time. Práticas Lean, Kanban, TOC (Theory of Constraints), Gestão Ágil de Portfólios e a Agility@Scale são os otimizadores globais de uma organização.

Scrum é um pequeno passo (mas importantíssimo) para uma equipe. Lean é o salto gigantesco para o um grande aumento de valor para a empresa como um todo.

Domain Driven Design com Naked Objects em Java - Resenha do Livro

2009-12-23T08:57:00.005-02:00

Um livro recém lançado e que acabei de ler é o Domain Driven Design Using Naked Objects de Dan Haywood.

Muitos acham que Naked Objects é uma tecnologia meramente para aprendizado ou prototipação de conceitos. Podia até ser antigamente, mas esse livro mostra que essa visão está errada hoje. Além dos usos conhecidos de ensinar OO como deve ser e ajudar a prototipar entidades de negócio, hoje Naked Objects pode ser uma excelente forma de construir uma camada de objetos de negócio reutilizáveis dentro de uma corporação.

O livro mostra como aplicar os conceitos de Domain Driven Design e de Ubiquitous Language utilizando Java e Naked Objects. Além de mostrar detalhadamente como construir a camada de entidades de negócio usando Naked Objects, o livro mostra como você pode:

- Integrá-los com bancos de dados
- Integrá-los com uma estratégia SOA expondo-os a um ESB ou como um RESTful Service
- Usá-los a partir de um framework Web (o livro usa como exemplo o Apache Wicket)
- Como usá-los através de clientes GUI
- E também como usar a infraestrutura da própria tecnologia Naked Objects, que gera uma interface gráfica Web automaticamente para uso das entidades de negócio.

Recomendo esse livro para os que querem aprender com mais rapidez e facilidade o que é o Domain Driven Design - DDD - na prática. Também para aqueles que desejam construir aplicações Web e Client/Server de uma forma veloz e que serão usadas internamente em produção dentro de uma organização.

Departamento de Defesa dos EUA indo para o Agile - Ideias para os compradores de TI do governo brasileiro

2009-12-21T09:14:00.005-02:00

Encontrei uma notícia muito interessante e relevante para o mercado de TI do setor público brasileiro. O Departamento de Defesa dos Estados Unidos está indo rumo ao Agile e ao iterativo!

O apresentador Don Johnson, que trabalha para o CIO do departamento de defesa, apresentou os pontos que mostram que a forma de contratação waterfall (cascata) de software por parte do DoD "é a causa raiz para os sistemas adquiridos sob medida não entregarem as capacidades e benefícios prometidos, dentro do prazo e orçamento". Ele explicou que a aquisição atual envolve um ciclo de tempo muito longo dirigido por processos big bang.

Por causa disso, o Congresso Americano respondeu e criou uma lei que permitirá a construção de 10 programas de TI usando um modelo alternativo de aquisição!

Isto é, o governo americano está trabalhando em uma lei para reformar a aquisição ultrapassada baseada em processos cascata, rumando para um modelo iterativo e incremental.

Esse exemplo, vindo do departamento onde "nasceu" o modelo cascata, é mais um indício de que esse debate também precisa entrar no tema de aquisição de software sob medida no governo brasileiro, em órgãos públicos e empresas estatais. O governo americano já está dando um passo inicial para reformular TODAS as compras públicas de software. Quando o Brasil tomará esse mesmo caminho? Espero que seja breve. Só assim teremos melhores sistemas a custos mais baixos, com melhor qualidade e agilidade.

Selenium RC (Remote Control) - Instalação, Configuração e Dicas

2009-12-09T10:10:00.012-02:00

Hoje um artigo mais técnico para quebrar o ritmo do assunto gestão de portfólio de projetos! Vou tratar da instalação e configuração da ferramenta Selenium Remote Control (RC). O Selenium RC permite que scripts de teste desenvolvidos usando a ferramenta Selenium IDE, no browser Firefox, possam ser executados em outros browsers (como Internet Explorer, Safári e Opera). Portanto, assumimos que você já tenha criado os scripts de teste na ferramenta Selenium IDE. Mostro alguns exemplos da execução do Selenium RC com os browsers Firefox e Internet Explorer.

Como pré-requisito, não esqueça de instalar o JDK (Java Development Kit).

Para a instalação você deve:

Realizar o download do arquivo zip no site do Selenium.

Fazer o unzip do conteúdo do arquivo no diretório C:\Selenium.

Para utilizar o Selenium RC no Windows faça o seguinte:

Abrir um Prompt do DOS.

Entrar no diretório C:\Selenium\selenium-server-1.0.1

Digitar o seguinte comando para executar os testes com o browser Internet Explorer: java -jar selenium-server.jar -multiwindow -htmlSuite "*iexplore" "http://www.google.com" "C:\Selenium_Tests\TsTst.html" "C:\Selenium_Tests\results.html" . Não esqueça de substituir o que está entre aspas pelos seus valores específicos.

Digitar o seguinte comando para executar os testes com o browser Firefox: java -jar selenium-server.jar -multiwindow -htmlSuite "*chrome" "http://www.google.com" "C:\Selenium_Tests\TsTst.html" "C:\Selenium_Tests\results.html" . Não esqueça de substituir o que está entre aspas pelos seus valores específicos.

O arquivo results.html conterá o resultado de execução de cada um dos casos de teste. Através dele é possível verificar se algum caso de teste falhou e em que ponto.

Dicas fundamentais:

Criar os casos de teste e a suíte de testes sempre com a extensão .html. Sem essa extensão os casos de teste podem falhar em alguns browsers quando o Selenium RC é utilizado (Acredite em mim... perdi um bom tempo tentando identificar esse problema!!!).

Criar o arquivo de resultados contendo o nome do browser. Exemplo: FFResults.html e IEResults.html.

Algumas telas do uso do Selenium RC:

Sobrecarga de projetos: O inimigo das organizações eficientes

2009-11-25T14:15:00.004-02:00

"Fazer duas coisas de uma vez é não fazer nenhuma delas." - Publilius

"O cérebro é muito parecido com um computador. Você pode ter várias telas abertas em seu desktop, mas só pode pensar nelas uma por vez." - William Stixrud, Phd em Neuropsiquiatria

Continuando a série sobre gestão de portfólio de projetos, neste artigo tratarei de um dos principais impedimentos a uma maior geração de valor por parte de projetos de TI: escassez de profissionais e sobrecarga de pessoas e recursos financeiros.

Um dos problemas sérios em muitas empresas é a multi-tarefa. Quando um indivíduo trabalha em duas tarefas simultaneamente o ciclo de ambas é impactado diretamente. Ainda que não houvesse perda de produtividade, quando um trabalhador divide seu tempo para trabalhar em duas atividades ambas vão levar o dobro do tempo para finalizar. Dividir pessoas entre diversos projetos tende a gerar o mesmo efeito negativo no tempo de entrega. Além do efeito acima, já se comprovou através de pesquisas que a multi-tarefa e a troca constante entre projetos reduz a produtividade de uma pessoa.

De acordo com Smith e Reinertsen, dois mestres da prática e estudo de processos de desenvolvimento de produtos: “Você pode pagar uma pequena penalidade ao dedicar uma pessoa ao projeto do início ao fim. Em retorno por essa penalidade você terá um grande retorno em tempo de entrega, que geralmente vale mais dinheiro. Além disso, caso você tenha especialistas generalistas em sua equipe, essa penalidade será quase insignificante”.

Muitos executivos podem então questionar: mas se eu dedicar cada pessoa a um único projeto até seu fim não conseguirei tocar os X projetos que estão em meu backlog. É por isso que a solução para esse problema é simples, do ponto de vista da gestão de portfólio de projetos: Controle contínuo e religioso da lista de projetos. Conforme vimos no meu artigo anterior, muitas empresas estão trabalhando, investindo e desperdiçando dinheiro e tempo em mais projetos do que deveriam. Vários desses projetos são menos interessantes financeiramente(às vezes gerando até prejuízo, considerando o valor presente líquido) que outros. Porém a mera existência deles acaba drenando o pool de recursos e investimentos da empresa.

Reinertsen e Smith descrevem alguns casos práticos de controle religioso de projetos. Uma empresa diminuiu o número de projetos pela metade. Com isso, ela conseguiu desenvolver os projetos restantes duas vezes mais rápido com o mesmo número de pessoas e recursos financeiros. Outra empresa diminuiu a lista de 114 projetos para 17! Essa empresa conseguiu entregar todos os projetos no prazo, sendo que anteriormente não entregava nenhum deles.

Uma maneira comum nas empresas para alocar pessoas em projetos é analisar os projetos definidos e então dividir as pessoas disponíveis entre eles. Porém, a melhor forma de fazer a alocação de pessoas é através de priorização e ranking de projetos. Nesse outro modelo, primeiro deve-se usar técnicas de priorização de projetos (tema de meu próximo artigo!) para ordenar do mais importante para o menos importante cada um dos projetos. Feito isso você aloca a quantidade necessária de recursos financeiros e pessoas (se possível os mais seniores) para o projeto mais prioritário da lista. Depois passe para o segundo projeto e aloque outros recursos que ainda não tenham sido alocados. Continue fazendo isso até que todos estejam alocados. Qualquer projeto remanescente não é iniciado até que os projetos prioritários se completem e liberem recursos.

É claro que pode-se também recorrer à terceirização e ao outsourcing. Mas é preciso sempre lembrar que essas estratégias também consomem recursos internos da empresa (pessoas para gerenciar e definir requisitos para os terceiros e dinheiro para pagá-los).

Algumas dessas idéias e dicas parecem óbvias. Mas a realidade é que Smith e Reinertsen detectaram que em muitas empresas o que ocorre é a seguinte situação: é mais fácil dizer para o chefe ou para o cliente que você está trabalhando em seu projeto que explicar que você não irá começá-lo até que tenha recursos adequados. E é exatamente esse comportamento disfuncional que incha a empresa de projetos e acaba levando muitas a uma paralisia por sobrecarga.

Bibliografia:

Reinertsen e Smith - Developing Products in half the time, 2nd Edition. Para o assunto específico de sobrecarga de projetos vide especialmente o capítulo 11 “Preventing Overloads”

Cooper e Edgett – Portfolio Management for New Products

Gestão Ágil de Portfólio de Projetos: A nova fronteira da produtividade estratégica nas organizações

2009-11-16T20:18:00.009-02:00

Nós, agilistas e engenheiros de software, estudamos muito acerca de como organizar e gerenciar um projeto, desenvolver o software, testá-lo, implantá-lo, etc. Focamos bastante em como maximizar o retorno e o valor dos requisitos e fuincionalidades geradas em um projeto de software. Mas será que estamos perguntando se o projeto em si gera valor para a organização? E mais que isso: será que esse projeto em particular gera mais valor que um outro projeto, que pode estar sofrendo problemas por falta de recursos?

A próxima fronteira para aumentarmos a otimização de valor para as organizações é subir um degrau acima: tratar sobre a gestão ágil de portfólio de projetos e sua ligação com a estratégia da empresa.

Alguns números muito interessantes (e impressionantes) ajudam a mostrar a realidade do mercado de TI:

- Gastos de TI podem representar até 70% dos investimentos de capital em algumas companhias fortemente dependentes de TI
- 84% das organizações não montam um business case profundo e realista para seus projetos de TI
- 89% das organizações estão voando às escuras, com poucas ou nenhuma métrica financeira relevante e cruzada com aspectos estratégicos
- 83% das organizacões não conseguem ajustar seus orçamentos com as necessidades de negócio em períodos menores que um ano
- 40% dos projetos de software entregues provaram-se não econômicos e não geraram um retorno positivo sobre o investimento. Resumindo: pagaram mais para desenvolver o software que receberam por ele.
- Em torno de 23% dos projetos de software são cancelados sem entregar valor nenhum.
- Segundo Maizlish e Handler, em média apenas 1 dólar de cada 14 dólares gastos pelo orçamento de TI conseguem ser correlacionados com benefícios claros de negócio.
- De acordo com Tockey, 54% de todos os projetos de software são contraprodutivos do ponto de vista financeiro e econômico. Isso significa que em mais da metade do tempo, organizações que pagaram para desenvolver software estariam melhor financeiramente sem eles!

Esses números impressionantes mostram que muitas organizações estão sofrendo uma hemorragia geral em seus gastos de TI. Muito disso se deve a:

- Vários projetos "pessoais" - isto é, realizados porque são favoritos pessoais de alguém e não porque foram analisados e aceitos como importantes dentro de um portfólio
- Relutância em matar projetos iniciados, mas percebidos posteriormente como de valor negativo ou baixo para os acionistas
- Muitos projetos ativos e um backlog gigantesco de projetos
- Miopia e foco na tecnologia pela tecnologia dentro dos departamentos de TI
- Critérios inexistentes, inconsistentes e incompletos para avaliar investimentos em TI
- Falha em estimar o Total Cost of Ownership, entre outras variáveis de custos
- Governança inadequada

Outro dado fundamental, analisado e estudado por Preston Smith no capítulo 11 (Preventing Overloads) do livro "Developing Products in half the time": sobrecarregar o portfólio de projetos dilui diretamente o esforço e cria filas, o que aumenta os prazos e os custos dos projetos. Isso significa que a falta de controle do portfólio de projetos é uma das causas-raiz do estouro de custos e prazos em projetos.

Esses dados e números reforçam um aspecto que muitas vezes negligenciamos: a disciplina da gestão de portfólio de projetos (preferencialmente ágil) é tão ou mais essencial para o sucesso dos projetos de uma organização do que apenas o uso de um processo ágil de desenvolvimento de software focado em melhorar a produtividade e qualidade dentro de um projeto.

Devido à relevância e amplitude do assunto project portfolio management tratarei sobre ele em vários outros artigos nesse blog. Aproveito para conceituar já aqui os objetivos da gestão de portfólio de projetos, alguns temas que apóiam essa disciplina e listar alguns livros iniciais para direcionar aqueles que perceberam a necessidade dessa disciplina em suas organizações.

A gestão de portfólio de projetos é um processo dinâmico de decisão em que a lista de projetos ativos e novos é constantemente revisada. Novos projetos são avaliados, selecionados e priorizados a partir de técnicas, métodos e critérios definidos pela organização. Projetos existentes podem ser acelerados, eliminados ou despriorizados. Recursos podem ser alocados e realocados pelos projetos.

Podemos resumir que a falta da gestão de portfólio de projetos em médias e grandes organizações significa que: há muitos projetos na organização, uma falta de foco, nenhum ou poucos critérios de seleção (projetos são selecionados na emoção ou por jogos políticos) e nenhum critério estratégico para a seleção de projetos. Esses pontos resultam em: maiores taxas de falhas em projetos e prazos mais longos de término de projetos, poucos produtos e softwares vencedores do ponto de vista de valor e falta de alinhamento estratégico nos projetos (o que gera efeito metralhadora: atira-se para todos os lados para ver se alguns dos projetos acertam!).

Algumas das ferramentas que serão tratadas nessa série de artigos:
- Ferramentas financeiras para avaliação de projetos de investimento e orçamentação de capital (capital budgeting)
- Pensamento sistêmico (Systems Thinking)
- Pensamento enxuto (Lean Thinlking)
- Ferramentas de pensamento da Teoria das Restrições (Theory of Constraints)
- Teoria das Filas

Relembrando: o gerenciamento pró-ativo do portfólio de projetos de uma organização pode trazer tantos ou até mais benefícios que apenas focar no processo de desenvolvimento e gestão de um único projeto. A gestão ágil de portfólio de projetos, juntamente com a gestão ágil de projetos com práticas técnicas, maximizará ainda mais o valor de cada dólar ou real investido e trará uma maior produtividade nos projetos certos. Isso transformará a TI da organização num centro de lucros e valor e não em um centro de custos e em uma commodity.

Bibliografia inicial:

Cooper e Edgett - Portfolio Management for New Products, 2nd Edition
Cooper - Winning at New Products
Lapponi - Projetos de Investimento na Empresa
Assaf Neto - Curso de Administração Financeira
Cohn - Agile Estimating and Planning
Maizlish e Handler - IT Portfolio Management Step by Step
Krebs - Agile Portfolio Management
Ward e Daniel - Benefits Management: Delivering Value from IS and IT investments
Tockey - Return on Software: Maximizing the Return on your software investment
Denne e Huang - Software by Numbers: Low-Risk, High-Return Development
Preston Smith e Reinertsen - Developing Products in half the time, 2nd edition
Reinertsen - Managing the design factory
Scheinkopf - Thinking for a change: Putting the TOC Thinking processes to use
Womack - Lean Thinking
Galesne et al - Decisões de Investimentos da Empresa
Reifer - Making the Software Business Case

Benefícios econômicos da automação de testes unitários - Sua suite de testes é tão valiosa quanto seu código!

2009-10-26T08:53:00.005-02:00

Hoje é consenso na engenharia de software e na comunidade ágil que realizar testes unitários automatizados é uma prática técnica fundamental para melhorar a qualidade do produto de software. Além disso, Michael Feathers em seu excelente livro "Working Effectively with Legacy Code" estudou e chegou a uma conclusão muito interessante e fundamental: O que é um sistema legado? É aquele em que o código não possui um conjunto abrangente de testes unitários automatizados.

Apesar das evidências, a maioria dos projetos de software e sistemas no mercado brasileiro e mundial não possuem suites de testes unitários automatizados. Portanto, a maioria dos sistemas já vira legado a partir do momento que entra em produção! As principais justificativas (e veremos que são desculpas, pois não se justificam) ditas por pessoas para não realizar testes unitários automatizados são as seguintes:
- O custo de colocar atividades de testes unitários automatizados encarecerá o projeto
- O cronograma ficará mais longo e, portanto, demorarei mais para entregar.
- Minha equipe não sabe ou não está treinada para realizar testes unitários automatizados

O objetivo deste artigo é justamente desmontar essas desculpas e mostrar os benefícios econômicos de realizar testes unitários automatizados. Os benefícios econômicos do uso de testes unitários evidenciarão que não realizá-los é uma atitude irracional do ponto de vista econômico.

Vamos então primeiro verificar quais são os benefícios de uma suite de testes unitários automatizados:
- Detecção imediata de defeitos em métodos. Estes defeitos costumam ser identificados rapidamente em testes unitários, mas possuem custo maior de análise e correção quando identificados apenas em um teste funcional de sistema.
- Melhor design detalhado e arquitetura, pois os testes unitários forçam os desenvolvedores a melhorar seu design para que ele se torne mais testável (é o famoso design for testability)
- Código mais estruturado e menos complexo.
- Melhor documentação do código. Cada teste unitário conta a estória e os objetivos de um método.
- Maior facilidade para refatorar código, o que diminui o tempo gasto na realização de manutenções evolutivas
- Diminuição do tempo de detecção e correção de manutenções corretivas, pois a suite de testes unitários automatizados garante que uma mudança em um ou mais trechos de código não impacte outras funcionalidades.

Agora vamos analisar os custos. Uma das justificativas para não se usar testes unitários automatizados é o custo de colocar atividades para realizá-los. Vamos então detonar mais uma vez esse mito e falácia. Muitos gerentes de projeto que não conhecem profundamente engenharia de software cometem esse erro de acreditar que o custo aumentará muito. O problema é que eles acreditam que o desenvolvedor apenas codifica, não testa. Essa é um grande erro. Todo desenvolvedor que seja minimamente profissional irá investir tempo testando seu código. Porém,muitos ainda fazem esses "testes" de forma totalmente manual e usando uma ferramenta que deveria ser pouco usada (apenas em casos extremos): o debug de código. Os gerentes acham que os desenvolvedores não testam, porém eles realizam "testes" sim: de forma manual e debugando código. Portanto, os desenvolvedores realizam uma atividade que não possui como saída um artefato evidente. Essa atividade "invisível" no cronograma dos gerentes será em sua maioria substituída por uma atividade com artefatos úteis e evidentes: testes unitários automatizados. Isso detona os dois primeiros mitos que levam as equipes a não fazer testes unitários automatizados: maior custo e maior tempo de cronograma.

Mas vamos considerar que a equipe é inexperiente em relação a automação de testes unitários. Vamos considerar então que o custo do projeto aumente em 10% (esse é um número bem elevado, o que não ocorrerá. Na prática a equipe se tornará mais produtiva realizando a automação). Num projeto de R$ 1.000.000,00 haveria então um gasto adicional de R$ 100.000,00 em treinamentos para a equipe e tempo extra para eles se acostumarem a realizar a automação.

Vamos agora dar números econômicos aos benefícios da automação de testes unitários:

- O melhor design, código estruturado, documentação e detecção imediata de defeitos podem reduzir de 10% a 50% os testes funcionais e especialmente os de aceitação e homologação (reduz a necessidade de dois ou mais ciclos/baterias de testes e diminui o número de defeitos detectados e a corrigir no momento de homologação). Além disso, melhora a percepção e a imagem de qualidade da equipe. Vide Boehm para essa conclusão.
- Durante o período de manutenção evolutiva e corretiva (o período em que o sistema entra em produção e que corresponde em média a 80% do ciclo de vida dessa aplicação) o tempo e custo de desenvolvedores investido para evoluções e correções é diminuído em torno de 10% a 30%. Isso ocorre devido à existência da suite de testes unitários automatizados que serve como documentação, facilita a detecção de defeitos recorrentes e potencializa a refatoração de código para permitir a inclusão de novas funcionalidades sem aumentar a entropia do sistema.

Portanto, vamos considerar que no nosso sistema exemplo de 1.000.000 de reais em torno de 30% do orçamento será para testes funcionais e de sistema (sem uso de automação de testes unitários). Portanto, podemos diminuir até 150.000 reais (no caso pessimista a redução seria de 30.000 reais) dos testes funcionais e gastamos 100.000 reais para realizar testes unitários automatizados (fora a redução dos testes "manuais" e debugs dos desenvolvedores).

Vamos considerar, como um exemplo, que durante a vida desse projeto gastaríamos mais 10.000.000 de reais em manutenções evolutivas e corretivas. Com a suite automatizada de testes unitários esse custo diminuiria entre 1.000.000 a 3.000.000 de reais!

Custo do projeto com automação de testes unitários automatizados: O mesmo, pois você apenas transfere atividades "invisíveis" (como debug e "testes" manuais dos desenvolvedores) e ainda reduz o número de ciclos de testes de sistema e homologação (portanto transfere custos de testes de sistema para testes unitários automatizados).

Benefício durante a manutenção do sistema em produção: Redução de pelo menos um milhão de reais (redução pessimista) em um investimento de 10 milhões durante a vida útil do software.

Resumindo, seu custo durante o projeto praticamente empata se você realizar testes unitários automatizados ou pode até ser menor. Além disso, você ganhará como benefício intangível uma melhor percepção de qualidade, pois os analistas de testes e os clientes encontrarão menos defeitos nos testes de sistemas e na homologação. E seu custo após a implantação em produção será muito menor, o que lhe trará um retorno sobre o investimento excelente sobre os testes unitários automatizados feitos.

A automação de testes unitários é economicamente relevante para o fornecedor (pois tem melhoria de qualidade e imagem), mas ainda mais relevante para o comprador (pois há benefício econômico real). Vai aí a dica para o fornecedor: realize os testes unitários automatizados e entregue como algo de valor agregado no seu serviço. Para o cliente: exija sempre uma suite de testes unitários automatizados junto com o produto de software.

Reforçando: É uma atitude irracional do ponto de vista econômico não criar uma suite abrangente de testes unitários automatizados.

Computação Verde no Google - Blog Action Day 2009: Climate Change

2009-10-15T09:25:00.003-03:00

Para manter a tradição, esse é o terceiro ano consecutivo em que participo do Blog Action Day. O Blog Action Day 2009 tem como tema deste ano o problema da mudança climática. E como é bom mesclar o assunto com o tema deste blog nada mais fácil que eu comentar como o Google realiza sua estratégia de Green Computing.

As iniciativas verdes do Google são extensas e estão disponíveis em um site próprio. Isso pode fornecer idéias a empresas de TI e data centers brasileiros.

Alguns exemplos do Blog do Google:

- Vans para levar os empregados do Google até a empresa. E todos que caminham ou vêm de bicicleta ou transporte público ganham pontos que podem ser convertidos em dinheiro para caridade.

- O Google instalou cerca de 9.000 painéis solares para ajudar na geração de energia limpa para seus escritórios.

-Já possui uma pequena frota de veículos elétricos disponíveis para os empregados.

- Toda a coleta de lixo é feita de maneira seletiva.

- Os prédios foram idealizados para que a luz do Sol entre com mais facilidade e minimize o uso de lampadas acesas no período diurno.

Em suma, nada como fazer nossa parte para reduzir emissões de poluentes e diminuir os impactos das mudanças climáticas em nosso planeta e em nossas vidas. Parabéns ao Google pelas suas iniciativas contínuas nessa área!

O papel do analista de sistemas / negócios / requisitos nos processos ágeis - Introdução

2009-09-30T09:33:00.008-03:00

Em um artigo anterior tratei do papel dos analistas de testes dentro dos processos ágeis. Neste artigo tratarei sobre o papel do analista de sistemas / negócios / requisitos. Lembrando que esse papel pode ser conhecido como analista de requisitos, analista de negócios ou analista de sistemas. Varia de empresa para empresa.

Antes de falar sobre o papel do analista de negócio é importante detonar dois mitos sobre requisitos em projetos ágeis: que projetos ágeis não realizam requisitos e que eles não necessitam de boas práticas e técnicas de requisitos. Esse mito pode ser rebatido quando citamos as diversas práticas de envolvimento da equipe do projeto com stakeholders e usuários: Interação contínua com stakeholders, reuniões para definição do produto, demonstrações de produtos das iterações, Workshops de requisitos, gestão de mudanças e priorizações de requisitos através de um backlog de produto e a aproximação de todos os membros da equipe com o product owner.

Eliminados então esses mitos sobre o processo de requisitos dentro de processos ágeis vamos à pergunta principal: qual o papel do analista de negócios dentro de um processo ágil de desenvolvimento?

Vamos entender primeiro algumas atividades "tradicionais" de um analista de negócio:

- Elaborar uma visão de alto nível do sistema
- Servir de ponte entre os diversos stakeholders de um projeto e a equipe de desenvolvimento
- Modelar e documentar necessidades e requisitos
- Ajudar nos testes e validações conhecidos como testes de aceitação dos usuários
- Representar os stakeholders quando a equipe não possui um cliente sempre presente

O que vejo de problemas e frequentemente explico quando leciono sobre gestão de requisitos é que os analistas de negócio não podem ser meros copiadores de informação e elaboradores de atas de entrevistas. Eles devem colaborar pró-ativamente no entendimento dos problemas e necessidades dos stakeholders e ajudar na proposição de soluções e idéias para o produto final.

Segundo Scott Ambler, nós temos que realizar o processo de requisitos, mas isso não implica obrigatoriamente que em todos os tipos e condições de projetos nós temos que ter analistas de negócio especialistas e só realizando esse papel. Por ajudar na melhoria da comunicação entre stakeholders e equipe, o papel de um analista de negócio ágil vai mudar consideravelmente dependendo da organização e tamanho do time.

Caso 1 - Projeto pequeno com número mínimo de stakeholders. O caso extremo disso é o exemplo do projeto DDWorks feito pelo Rodrigo Yoshima. Ele desenvolveu um site com o cliente (único stakeholder) do lado dele o tempo todo. Era necessário um analista de negócio? Obviamente não. O Scott Ambler vai mais além: em uma equipe pequena, com um cliente treinado como product owner, um desenvolvedor ou analista de testes pode exercer esse papel de analista de negócio. No próprio OpenUP, na descrição do papel de Analista, está escrito que "um membro da equipe pode realizar esse papel e também o papel de testar o software".

Caso 2 - Projeto grande com desenvolvimento geograficamente distribuído. Nesse cenário onde as equipes de desenvolvimento se situam em locais diferentes dos stakeholders e onde há muitos stakeholders você acabará tendo gaps de comunicação. Nesse caso o papel mais "tradicional" dos analistas de negócio será fundamental para reduzir falhas de comunicação.

Um outro ponto importante é: será que um desenvolvedor pode aprender a ser um analista de negócio? E vamos mais além: será que um dos stakeholders ou clientes não podem aprender a como se tornar um analista de negócio? Obviamente que sim. Aliás, em diversos casos, é mais fácil ensinar um cliente ou product owner a ser um melhor analista de negócio que ensinar a um analista de negócio um domínio de negócio complexo. Portanto, o que idealmente devemos ter nas diversas configurações de projetos são especialistas generalistas. A pessoa pode ser especializada em requisitos, mas deve ter outros conhecimentos que ajudam o time em outros aspectos. Um conhecimento que recomendo sempre a analistas de negócio é o de saber realizar testes, especialmente os de aceitação.

Outra situação é tornar um analista de negócio senior o "Product Owner" de um sistema. No RUP esse papel é conhecido como o "Campeão do Produto". O importante é lembrar que nesse cenário o analista de negócio deve focar seus esforços no domínio do negócio e colaborar com o time para atender as necessidades dos stakeholders de forma priorizada. Um analista de negócio pode virar um product owner quando há muitos stakeholders para o projeto e nenhum deles pode ficar o tempo todo com a equipe. Ou então quando o projeto vai desenvolver um produto para um mercado amplo, com milhares de usuários.

Resumindo então: o processo de análise e gestão de requisitos continua existindo e é importantíssimo em processos ágeis. O papel do analista de negócio nesses processos passa a ser muito mais pró-ativo. Como já havia comentado, o analista de negócio não pode ser um passivo receptor e tradutor de informações vindas dos stakeholders para documentos formais. Ele deve fazer outras atividades no projeto, como essas:
- Ele deve entender o negócio a fundo e ajudar na priorização de requisitos com base em números financeiros.
- Deve trabalhar em pares com os membros da equipe de desenvolvimento, para explicar melhor os requisitos enquanto o desenvolvedor faz seu desenvolvimento dirigido por testes.
- Deve criar exemplos e cenários de testes que ajudem a guiar os desenvolvedores e confirmar os requisitos e necessidades dos stakeholders.
- Deve ajudar nos testes do sistema tanto durante as iterações como também junto com os usuários e clientes durante a homologação formal.

Portanto a mensagem para você que é analista de negócio: tenha uma postura mais pró-ativa nos projetos, se envolva com a equipe de desenvolvimento tanto quanto você se envolve com os stakeholders. Nunca esqueça que o processo de gestão de requisitos só existe por um motivo: para mitigar o risco de comunicação entre stakeholders e equipe. O objetivo fim de todo projeto de desenvolvimento de software é criar o software, e não criar uma pilha gigantesca e indecifrável de documentações.

O papel do analista de Testes dentro dos processos ágeis - Uma Introdução

2009-09-22T09:22:00.015-03:00

Ainda há muitas dúvidas no mercado acerca do papel do analista de testes dentro de uma equipe trabalhando em um processo ágil. A definição de papéis no Scrum, por exemplo, posssui apenas três elementos: Product Owner, Scrum Master e time. Isso algumas vezes leva a confusões e a crenças de que não há lugar para um analista de testes especializado num time ágil.

Esse artigo é minha tentativa de introduzir e explicar o papel do analista de testes dentro de um projeto de desenvolvimento ágil e também a mudança paradigmática que um analista de testes "tradicional" (tradicional no sentido de uma pessoa acostumada a trabalhar em equipes de testes apartadas de equipes de desenvolvimento e utilizando um processo Waterfall) deve sofrer para se tornar um bom analista de testes "agilista".

Vamos então entender e elaborar a resposta à seguinte pergunta: como o processo de testes ágil é diferente do processo de testes tradicional (cascata) e qual o papel do analista de testes em cada modelo?

No processo cascata, os testes da aplicação acontecem no final do ciclo de desenvolvimento. Nesse período é onde temos o esforço mais concentrado dos testers. A grande realidade é que o papel do analista de testes nesse modelo é muito mais reativo e não pró-ativo. É claro que existe o famoso modelo em V. Além disso, o correto num processo cascata é que os analistas de testes planejem os casos de teste em paralelo com a fase de codificação. Mas, mesmo assim, o que ocorre na prática é que a equipe de testes vive separada da equipe de desenvolvimento, correndo em linhas paralelas que só se cruzam no momento da verdade da fase de testes do modelo cascata.

E como é então o processo de testes e o papel do analista de testes no desenvovimento ágil? Nesse modelo o analista de testes passa por uma grande transformação. Ele deixa de ser reativo para se tornar um papel fundamental na interação com os desenvolvedores, analistas de negócio e clientes. Para entender melhor como ocorre essa transformação precisamos de uma ajuda do quadrante de testes ágil, do livro de Lisa Crispin e Janet Gregory:

Temos então quatro grandes grupos de testes importantes:

Q1 - Testes que focam na arquitetura e suportam o time: São os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e mentorizar os desenvolvedores sempre que necessário. De preferência isso é feito fazendo "pairing" com o desenvolvedor no momento de elaborar os testes unitários automatizados.

Q2 - Testes que focam no negócio e suportam o time: São testes funcionais diferenciados, que idealmente utilizam a técnica de Behaviour-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos. Além disso, utilizando-se ferramentas adequadas (como o Fitnesse ou o Concordion, por exemplo), uma parte desses testes serão automatizados antes ou em paralelo com o desenvolvimento do cenário. Portanto, o foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entender melhor.

Q3 - Testes que focam no negócio e criticam o produto: esses são o que chamo de testes "clássicos". Os testes de aceitação feitos na homologação do produto ou de suas partes, testes beta e testes exploratórios. São os testes feitos não com o objetivo de dizer que o software funciona mas, pelo contrário, de encontrar defeitos. Essa categoria às vezes é negligenciada por alguns agilistas mais radicais. Mas a verdade é que bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem (até porque o papel do desenvolvedor é construir e o do testador, neste quadrante, é o de destruir!).

Q4 - Testes que focam na arquitetura e criticam o produto: São os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando pedaços da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.

Com a explicação do quadrante é que podemos entender melhor então a transformação crucial do testador num processo ágil. A existência dos quadrantes 1 e 2 no processo ágil (e que inexistem no processo cascata) modificam de maneira fundamental o perfil e o papel do analista de testes numa equipe ágil. Ele deixa de ser reativo para também ser pró-ativo. Ele deve estar dentro do time e não fora dele em uma equipe apartada. Ele alça novos rumos e se torna também um analista de negócios, ao ajudar os clientes a criarem cenários de testes que ajudam no entendimento dos requisitos e facilitam o processo de desenvolvimento da aplicação. A Lisa Crispin aborda isso em seu livro, mas não deixa tão clara assim essa mudança radical e transformadora do papel dos testers dentro de um projeto ágil. Por isso decidi escrever esse artigo para esclarecer ainda mais esse ponto e também para deixar essas informações para aqueles que não tiveram ainda a oportunidade de ler o livro dela.

Recomendo então a todos os analistas de testes: estudem bastante o processo ágil de testes, as novas técnicas de Behaviour Driven Development e as ferramentas automatizadas que as auxiliam. Assim você se tornará um recurso muito mais valioso para sua equipe e para o resultado final dos projetos.

O Segredo Obscuro do Agile: Agile tem tudo a ver com micro-gerenciamento!

2009-09-14T09:13:00.003-03:00

Mike Cohn elaborou uma interessante idéia da qual concordo, mas que pode parecer uma heresia para muitos agilistas: Agile tem tudo a ver com micro-gerenciamento!!!

Sim, isso mesmo, provavelmente alguns devem ter iniciado uma fogueira para queimar os excelentes livros do Mike Cohn sobre gestão e estimativas ágeis em projetos e sobre user stories. Mas antes de riscar o fósforo deixe a idéia ficar mais clara :-) .

Diversas práticas básicas dentro de métodos ágeis estão lá para suportar o micro-gerenciamento das pessoas. Exemplos:

- O Daily Stand-up Meeting (Reunião diária de 15 minutos em pé) é um micro-gerenciamento diário do planejamento da iteração. Ele garante que todos estão fazendo ou farão aquilo que deveriam.

- A Integração Contínua é colocada para que, no instante em que um desenvolvedor cometa um erro e quebre um build, todos fiquem sabendo rapidamente.

- A programação em pares garante que os desenvolvedores não percam o foco, não façam goldplating e que limpem e refatorem continuamente o código.

Mas quem faz esse micro-gerenciamento todo? Aí vem o ponto importante: a equipe faz um auto-microgerenciamento! Isso é bem diferente de um gerente micro-gerenciar. Quando a equipe faz seu próprio micro-gerenciamento ela só tem benefícios e realiza o nirvana da auto-organização.

Agile está morto! D-us salve o Agile!

2009-08-18T10:57:00.005-03:00

Morte do Agile? Será que o José Papo enlouqueceu, alguns devem se perguntar? Não enlouqueci não! Na realidade, o que pretendo argumentar aqui é minha opinião (reforçada por outros papas do desenvolvimento de software, como o Ivar Jacobson) de que hoje já deveríamos considerar a distinção entre Agile e “Engenharia de Software Tradicional” como algo do passado. Na realidade, o que argumento é que os princípios e práticas pregados pelos agilistas são a Engenharia de Software da atualidade e do futuro próximo.

Ainda em muitos lugares Agile é visto como uma novidade, mas a realidade é que se você deseja realizar projetos de qualidade e com alta produtividade só conseguirá realmente utilizando as práticas adotadas pelos agilistas.

Assim como o Jacobson, já começo a ver as guerras metodológicas como coisas do passado, brigas de egos entre metodologistas... he, he! Em vez de ficarmos falando de uma metodologia ou processo versus outro devemos focar nos melhores princípios e práticas que nos trarão vantagem competitiva no desenvolvimento de produtos de software com qualidade.

Os princípios já estão claros quais são para as novas organizações de desenvolvimento de software: Os princípios do Manifesto Ágil.

Já as práticas podem mudar e devemos usar aquelas mais interessantes para cada projeto. Se o projeto é complexo e tem um modelo de entidades com um negócio muito rico porque não usar a prática de desenvolver um modelo de domínio, como descrito no FDD? Se temos uma equipe que ainda não se conhece bem porque não usar pair programming do XP?

Outras práticas deveriam ser obrigatórias, pois garantem a qualidade do produto. Desenvolver um novo sistema sem testes unitários automatizados é assinar uma sentença de morte para o projeto antes mesmo dele terminar.

Uma outra notícia interessante que mostra ainda mais essa guinada das empresas para o uso do Agile como o padrão da Engenharia de Software de nossos tempos: Na versão 7.5 do Rational Unified Process é possível encontrar uma série de práticas, obrigatórias ou opcionais. O fundamento do RUP se chama “Agile Core”. Este contém as práticas de desenvolvimento iterativo, planejamento de projetos em dois níveis, Time completo, Test-Driven Development e Integração Contínua.

Essa nova versão reforça ainda mais duas mensagens:

- A primeira é que o RUP está ainda mais Ágil e de forma ainda mais clara.
- E a segunda é que se você ainda usa os artefatos do RUP, mas faz tudo em cascata, sem testes unitários automatizados e sem integração contínua tenho que reforçar a má notícia: você não está usando o RUP!!! Portanto, não culpe o processo ou metodologia pelo fracasso do projeto caso não esteja seguindo seus princípios e práticas fundamentais.

Uma observação importante para aqueles que não entenderam a analogia que fiz no título de meu post. A analogia é com a famosa frase dita quando um rei morre: "O Rei está morto! D-us salve o Rei!". Apesar de parecer apenas definir a sucessão do rei para seu descendente, na realidade esta frase possui significado mais profundo.

Esse significado foi magistralmente detalhado no livro sobra história das idéias no período medieval do historiador judeu Ernst Kantorowickz de título "Os Dois Corpos do Rei". A frase na verdade é um reforço da idéia existente no período medieval de que o rei tinha dois corpos, um físico e outro espiritual. O corpo físico podia morrer, mas o corpo espiritual sempre vive. Essa é analogia que faço então com Agile. Agile, como nome e como corrente, pode morrer. Mas Agile como conceitos, princípios e práticas fundamentais da engenharia de software ficará ainda por muito tempo incorporado na engenharia de software.

Tom DeMarco: "Como eu estava errado sobre métricas e controle"

2009-07-17T13:54:00.006-03:00

Na revista IEEE Software de julho/agosto de 2009, Tom DeMarco escreveu um artigo excelente de título Software Engineering: An Idea Whose Time Has Come and Gone? . Tom DeMarco ainda é um metodologista e consultor importante, mas era ainda mais famoso antigamente por ter sido um dos pais da metodologia estruturada.

No artigo ele diz que hoje discorda do que escreveu em um de seus livros muito usados na época de título "Controlling Software Projects: Management,Measurement, and Estimation". Não posso deixar de recomendar a leitura do pequeno texto, mas vão aí algumas frases excelentes (traduzi para o português) :

" 'Você não pode controlar o que não pode medir'. Implícita nessa minha frase está a idéia de que controle seja talvez o mais importante aspecto de um projeto de software. Mas não é. Muitos projetos foram realizados quase sem controle e produziram produtos maravilhosos, como o Google Earth ou o Wikipedia."

"Controle estrito é algo que importa muito para projetos inúteis e importa pouco para projetos úteis. Isso significa que quanto mais você foca em controle, maior a probabilidade de seu projeto estar entregando algo de valor baixo."

"Então, como você gerencia um projeto que não pode controlar? Bem, você gerencia as pessoas e controla o tempo e o dinheiro. Estou sugerindo um approach de gestão muito próximo de métodos ágeis. No mínimo deve ter um aspecto incremental."

"Nos últimos 40 anos nós nos torturamos com a nossa inabilidade de terminar um projeto no prazo e no orçamento. Mas essa nunca deveria ter sido a meta suprema. A meta mais importante é a transformação, criar softwares que mudam o mundo ou transformam a maneira como uma companhia realiza seu negócio. Desenvolvimento de software é e sempre será de alguma maneira experimental. "

O Fim do Taxímetro: Como transformar o obsoleto modelo de negócio baseado na taxa horária

2009-07-14T10:49:00.004-03:00

Recomendo fortemente a leitura do artigo O Fim do Taxímetro do professor e ex-CEO da Ernst & Young Júlio Sergio Cardozo. Ele saiu na revista HSM Management de maio/junho de 2009.

O resumo do artigo, para interessar a todos da nossa área de Tecnologia da Informação e desenvolvimento de software: "Empresas de serviços profissionais, como firmas de consultoria e escritórios de advocacia, têm um imenso desafio pela frente, segundo Julio Sergio Cardozo, da UERJ e também consultor: transformar seu obsoleto modelo de negócio baseado na taxa horária."

Mais alguns insights muito bons:

"Profissionais altamente capacitados não foram treinados para ser máquinas de vender horas. Ainda há tempo para reagir e resgatar o prestígio e a nobreza profissional. Se quiser ser eficiente, venda horas; se quiser ser eficaz, cobre mais, ou melhor, por seu talento. Faça sua escolha."

"Observa-se que os gestores à frente das empresas que adotam a venda de horas como modelo de negócio vivem obcecados por obter a máxima utilização do contingente de profissionais, esquecendo-se do que é fundamental: empresas de serviços profissionais, como um negócio, um empreendimento, não existem para ser eficientes; elas existem para criar e perpetuar riqueza para seus sócios, oportunidades para os colaboradores e conhecimento valioso para os clientes."

"Por todas as razões elencadas até aqui, está mais do que na hora de as empresas de serviços profissionais aposentarem o timesheet e olharem em outra direção. Parece ser pacífico que seus clientes não estão comprando horas quando as contratam. Na verdade, compram resultados, expectativas, sentimentos prazerosos, esperança, sonhos, visão desejada do futuro e soluções para seus problemas que não necessariamente têm relação com o tempo despendido. Se, quando adquire um refrigerador, o consumidor não está preocupado com o tempo que a fábrica levou para produzi-lo, e sim com os benefícios proporcionados, a analogia também se aplica às firmas
de advogados e consultores."

Reforçando mais uma vez: leiam o artigo O Fim do Taxímetro. Mas aproveitem e repassem para seus colegas, gerentes, diretores e clientes. Vamos melhorar nosso mercado, adotando um modelo de negócio mais coerente com a alta capacitação intelectual que a Tecnologia da Informação exige.

Encontro Agile / Mingle Day - Resultados

2009-07-03T09:59:00.005-03:00

O evento “Encontro Agile / Mingle Day”, onde palestrei com o Rodrigo Yoshima e em parceria com a ThoughtWorks, foi um sucesso. Tivemos cerca de 80 pessoas participando em mais esse evento gratuito.

Eu e o Rodrigo Yoshima, devido a alguns fatos recentes ocorridos no Scrum Gathering, discutimos muito sobre “back to basics” na nossa comunidade Agile. Meu objetivo era abrir a mente das pessoas para os princípios de liderança e gestão pós-tayloristas, tendo como foco mostrar evidências dos benefícios de se trabalhar com organizações descentralizadas e do uso de equipes multifuncionais auto-gerenciadas em empresas (não só de TI, mas outras como Toyota, Semco, bancos, etc). Também falei de novos paradigmas de estudo sendo realizados pela ciência da administração.

Seguem os slides. Minha apresentação vai do slide 10 até o 17. Recomendo fortemente a leitura e consulta dos livros que indiquei na bibliografia, no slide 17.

Auto OrganizaçãO E Gestão Por Metas Flexíveis

View more documents from rodrigoy.

Algumas fotos:

Encontro Agile em São Paulo

2009-06-25T15:41:00.004-03:00

Dia 30 de junho de 2009 ocorrerá o Encontro Agile/Mingle User Group Meeting, patrocinado pela Aspercom e a ThoughtWorks. Será um evento gratuito em São Paulo com mini-palestras, discussões e muito bate-papo. Serei um dos palestrantes.

Data: 30 de junho de 2009 às 19:00hs

Facilitadores:
Paulo Caroli (Agile Coach, ThoughtWorks)
Adam Monago (Gerente de Produto - Mingle, ThoughtWorks)
Rodrigo Yoshima (Instrutor Agile, Aspercom)
José Paulo Papo (Especialista Agile)

Agenda:
19:00 Auto-organização e Gestão por Metas Flexíveis (Yoshima, Papo)
19:45 Painel: Quais são seus problemas de gerenciamento de projetos?
20:15 Coffee & Bate-papos
20:50 Mingle User Group Metting (Adam Monago)
(happy hour após o evento!)

Mingle User Group Meeting - São Paulo

O encontro do Mingle User Group (MUG) do Brasil é uma oportunidade para conhecer, discutir e compartilhar experiências com o Mingle. Adam Monago, um especialista no produto juntamente com outros Agilistas experientes, demonstrarão o Mingle provendo dicas e truques em como usar o produto para gerenciamento de projetos e colaboração.

Local:
Mercure Hotel São Paulo Paulista
Rua São Carlos do Pinhal, 87 - Bela Vista - MAPA
(Metrô Brigadeiro)

Inscrições/Informações: contato@aspercom.com.br

Palestrante na Rational Software Development Conference 2009!

2009-05-25T11:40:00.003-03:00

Entre os dias 31 de maio e 4 de junho acontece em Orlando, na Flórida, o IBM Rational Software Conference 2009, evento mundial da IBM Rational.

Eu serei palestrante no evento! O tema de minha palestra será sobre como as novas ferramentas da Rational ( o Rational Team Concert e o Rational Quality Manager) facilitam e agilizam o processo de desenvolvimento de um software embarcado utilizando C e/ou C++.

Escolhi o tema porque é uma área pouco tratada e que possui um alto nível de crescimento no Brasil e no mundo. Cada vez mais softwares são produzidos para aparelhos como satélites, telefones celulares, equipamentos de telecomunicação, equipamentos de carros de última geração e chips em geral.

Para a agenda e mais informações sobre as palestras do IBM Rational Software Conference 2009, acesse o site oficial do evento: www-01.ibm.com/software/rational/rsdc/

Confira as fotos com os papas da engenharia de software do mesmo evento realizado no ano passado:

Slides da Apresentação "Contratos e Scrum: The Good, The Bad and The Ugly" realizada no Brazil Scrum Gathering 2009

2009-05-18T09:43:00.006-03:00

Minha apresentação com o título "Contratos e Scrum: The Good, The Bad and The Ugly" teve uma presença razoável e foi muito elogiada pelos que a assistiram.

Uma novidade, em relação a outras palestras minhas sobre contratos, foi a separação dos contratos em categorias relativas à adaptação para o mundo ágil. O contrato Good é o famoso contrato de escopo varíavel, ideal para o desenvolvimento ágil. O contrato Bad é o contrato de preço fixo, que na realidade é de preço, prazo e escopo fixo (e qualidade deslizante, normalmente para o fundo do poço :-) !), portanto o pior para usar numa situação que demanda processos ágeis.

Os contratos ugly são menos conhecidos: Aquisição Progressiva e contrato por métricas de tamanho, especialmente contratação de uma quantidade de pontos de função no início do projeto, mas sem um escopo com requisitos extremamente detalhados e assinados com sangue. São contratos que diminuem o receio do cliente de contratar no formato clássico escopo varíavel. Alguns agilistas mais extremos podem achar ruim usar pontos de função. Mas a realidade é que a análise de pontos de função pode se tornar exatamente a arma para conquistar mais projetos no formato ágil.

Quem tiver mais interesse sobre o assunto pode deixar seu comentário ou dúvida aqui ou então enviar por email para jose ponto papo arroba gmail ponto com.

A apresentação já está disponível no SlideShare.

Contratos e Scrum: The Good, The Bad and The Ugly

View more presentations from jpapo.

Borland e Ativos de testes da Compuware adquiridos pela MicroFocus

2009-05-07T10:46:00.005-03:00

Segundo notícia do Slashdot, a Borland será adquirida pela empresa inglesa MicroFocus por 75 milhões de dólares. Todos os produtos e linhas relacionadas a testes e qualidade de software da Compuware também serão adquiridas pela MicroFocus por 58 milhões de dólares.

Nesse momento de crise mundial, o que estamos vendo na indústria de software é uma crescente concentração. Empresas capitalizadas e com fluxo de caixa aproveitam os preços baixos de empresas com ações na bolsa que estão com dificuldades financeiras. Esse é um processo normal e saudável do capitalismo.

Como a MicroFocus possui soluções especialmente para mainframe, creio que irão continuar levando a linha de ALM ( Application Lifecycle Management ) para a frente. Vamos ver como eles irão racionalizar as linhas de produtos de testes, já que Borland e Compuware possuem linhas com funcionalidades core similares.

Mas realmente é o fim de uma era. A Borland iniciou seu processo atual de queda com a venda de sua linha de produtos para desenvolvimento. IDEs como C++ Builder, JBuilder e Delphi eram e ainda são muito usadas em várias partes do mundo. Porém era uma linha de negócios onde a Borland não tinha mais como competir, devido ao aparecimento de excelentes IDEs open source ou de baixíssimo custo.

Após vender sua linha de IDEs a Borland focou especialmente no mercado de ALM. Pode-se resumir as principais opções nesse mercado nas seguintes:

- Linha IBM Rational
- Linha Borland ALM
- Linha Microsoft Visual Studio Team System
- Soluções open source ou de baixo custo integradas

A estratégia da Borland foi focar no middle market. Sua solução de ALM não é cara como as da Rational e Microsoft mas não é barata como as open source. Essa aquisição da Borland sinaliza que a estratégia não funcionou tanto como o esperado.

Outro problema foi a concentração apenas no mercado de ALM. Com o desaquecimento da economia é claro que investimentos em soluções ALM deixam de ser as prioridades das empresas. Empresas como IBM e Microsoft sofrem menos impactos pois possuem outras linhas para se sustentar. Porém a Borland vinha gradativamente perdendo vendas e a consequência está aí: sua venda por um preço relativamente baixo para uma empresa inglesa.

Palestrante no Brazil Scrum Gathering 2009!

2009-04-15T15:08:00.004-03:00

Com o intuito de disseminar as melhores práticas do desenvolvimento ágil com Scrum, finalmente será realizado no Brasil um Scrum Gathering. A Scrum Alliance, entidade que congrega Scrum Masters e todos os adeptos desse que é hoje um dos mais famosos processos ágeis, realiza o Brazil Scrum Gathering 2009. O encontro acontece nos dias 12 e 13 de maio de 2009, no Grand Hyatt Hotel. Ele contará com a presença de um dos "pais" do Scrum: Ken Schwaber!

O tema da minha apresentação (José Papo) é “Contratos e Scrum: The Good, the Bad and The Ugly". Tratarei das formas de contratação de projetos usando Scrum e outros processos ágeis e como elas impactam no planejamento do projeto, bem como formas de usar técnicas como análise de pontos de função juntamente com a venda de um projeto nos moldes ágeis. Enfim, o objetivo da minha apresentação é ajudar as pessoas a vender mais projetos de software e ainda conseguir utilizar plenamente o Scrum!!!

A minha apresentação será no dia 12 de maio, às 10h45m. Entre no site do Brazil Scrum Gathering e clique na aba "Program" para conhecer toda a grade de palestras.

Venha participar desse interessante evento!

Minha palestra sobre Contratação de projetos de software no Falando em Agile 2008

2009-03-10T12:15:00.005-03:00

A palestra que ministrei no evento Falando em Agile 2008 sobre Contratação de projetos de Software, manutenção de sistemas e portfólio de projetos com Agilidade foi publicada em vídeo no blog da Caelum. Quem tiver interesse pode assisti-la em vídeo.

Trato sobre diversos tipos de contratos e como reduzir os riscos do desenvolvimento de sistemas, tanto para clientes como para fornecedores, utilizando projetos iterativos e contratos alinhados a um mundo que demanda cada vez mais agilidade e produtividade.

Apresentação no 2° Seminário Brasileiro de Teste de Software

2009-02-18T13:51:00.004-03:00

Com o intuito de disseminar as melhores práticas para teste de software no país a ALATS (Associação Latino-Americana de Teste de Software), entidade sem fins lucrativos originada para estimular a melhoria dos processos de teste das aplicações, realiza o 2° Seminário Brasileiro de Teste de Software (BRATESTE). O encontro acontece entre os dias 12 e 13 de março de 2009, no Renaissance São Paulo Hotel.

O tema da minha apresentação (José Papo) é “Behaviour-Driven Development: A nova Era do Test-Driven Development e Acceptance Test-Driven Development, com exemplos em Concordion e JBehave 2".

A apresentação será realizada no dia 13 de março, às 16h00.

Vale a pena conferir o evento!

Assinaturas gratuitas da revista Engenharia de Software e Conferência!

2009-02-17T14:26:00.003-03:00

Raras são as oportunidades de ter acesso a informações que realmente podem transformar sua carreira. Essa é uma delas.

Dias 22 e 23 de maio, a DevMedia promove em São Paulo o evento Engenharia de Software Conference. Serão mais de 30 palestras que vão desde o projeto até o último teste de um software, passando pelos mais modernos conceitos de gerenciamento.

Com palestrantes renomados e temas pertinentes o evento promete excelentes oportunidades de aprendizado e network. Confira mais detalhes através do link: www.devmedia.com.br/es_conference

Além disso, a DevMedia gentilmente cedeu ao meu blog 10 (dez) assinaturas digitais da revista Engenharia de Software. Irei sorteá-las entre os leitores do blog. Basta colocar um comentário neste post, deixando seu nome e e-mail, e você já estará concorrendo.

Não deixe de participar do sorteio e do evento!

Mudanças no processo de aquisição de software e serviços de TI no governo

2009-02-09T13:20:00.003-02:00

Aos poucos, uma série de mudanças apareceram na processo de aquisição de softwares, desenvolvimento de sistemas e serviços de Tecnologia da Informação do governo federal.

Uma das mudanças se refere à Instrução Normativa 4.

Resumidamente, os seguintes pontos são os que considero de maior impacto:

1 - Empresas terceirizadas não podem mais fazer gestão de TI, sendo assim, cargos de direção, coordenação, gerência ou chefia só poderão ser ocupados por funcionários públicos.

2 - A contratação será por serviços ou demandas, o pagamento será mediante entrega do serviço ou demanda. Não se pode mais fazer uma terceirização global para toda a área de TI do órgão público e menos ainda alocação no estilo "body shop". Desse modo, fica "vedado contratar por postos de trabalho alocados, salvo, excepcionalmente, mediante justificativa devidamente fundamentada."

3 - Os órgãos terão que avaliar, antes de adquirir uma nova solução: se ela existe em outros órgãos públicos; se há similar no portal de software público; e se há equivalente em software livre.

Outra mudança grande é a crescente utilização do modelo de pregão eletrônico para a aquisição de softwares e serviços de desenvolvimento de sistemas. Nesse modelo, a tendência que já notei é da diminuição das necessidades de comprovações técnicas, como ocorre em licitações do tipo técnica e preço. Isso porque a modalidade do pregão tende a ir pelo menor preço e o órgão público acaba definindo poucos critérios obrigatórios para a participação (para permitir a participação de mais empresas e, consequentemente, diminuir ainda mais o preço do serviço).

Além disso, a Lei Geral das Micro e Pequenas Empresas dá preferência para MPEs quando houver empate em licitações do tipo menor preço. E não só empate! Elas possuem prioridade quando suas propostas forem iguais ou até 5% superiores à proposta classificada em primeiro lugar. Isto é, se uma empresa grande der um lance hipotético de R$ 100.000,00 e a pequena ou micro empresa der um lance entre R$ 100.000,00 e R$ 105.000,00 então ela leva se oferecer um real a menos que o primeiro lugar (PS: Já vi esse fenômeno ocorrer)!

É possível notar que o conjunto dessas mudanças tende a diminuir a força e a fatia de mercado de médias e grandes empresas dentro das áreas de Tecnologia da Informação do governo. O oceano ficará ainda mais vermelho dentro do segmento de venda de TI para governo pois:

1 - O número de projetos tende a cair no longo prazo (devido ao reuso que o governo pretende implantar, com a avaliação prévia da existência do software em outros órgãos) e

2 - A competição por esse número menor de projetos aumentará pois elimina as barreiras de entrada pesadas que existiam para as micro e pequenas empresas (barreiras como ter o CMMI ou MPS.BR ou ter um um capital estabelecido muito grande).

Benefícios do código limpo e o custo total de ser proprietário de uma bagunça

2009-01-22T11:14:00.006-02:00

Se você já foi um programador por algum tempo, provavelmente já teve de codificar mais lentamente devido a código ruim e mal feito. O grau de lentidão varia e muitas vezes é significativo. Equipes que se movem rapidamente no início do projeto podem se encontrar mancando a passos de tartaruga alguns meses depois. É aquela situação em que qualquer mudança, por mais trivial que seja, quebra outras partes do código e é feita com medo do impacto que irá gerar.

Conforme o tempo vai passando a bagunça e o lixo aumentam e se tornam tão grandes e tão profundos que ninguém mais consegue limpá-los. Quanto mais a bagunça do código cresce, mais a produtividade do time cai. Os gerentes acham que podem ajudar e fazem a única coisa que está em seu poder: contratam mais gente para manter o sistema. Porém, esse novo pessoal não conhece os meandros do sistema. E o pior, para conhecerem vão levar muitos meses e ainda impactar nas atividades dos desenvolvedores que conhecem (essa é a famosa lei de Brooks: "Incluir mais gente em um projeto atrasado vai atrasá-lo ainda mais"). Vão ainda gerar mais bagunça e mais código macarrônico.

Eventualmente a equipe e/ou os gerentes se revoltam e declaram que não conseguem mais trabalhar com essa base de código odiosa. A alta gerência não quer gastar tanto para refazer todo o sistema, mas também sabe e percebe que a produtividade é horrenda. Eventualmente acabam aceitando e construindo um sistema do zero, mas com as mesmas funcionalidades, para substituir o código antigo. Eu já vi esse filme algumas vezes na minha vida profissional. Você também já viu? Quem já viu sabe, portanto, que manter o código limpo de forma contínua não é apenas mais barato que deixar bagunça. É também uma questão de sobrevivência profissional.

Muitas vezes os programadores são pressionados para fazer o código de qualquer jeito, para atender seus prazos e cronogramas. Muitas vezes precisam também passar horas em claro vomitando linhas e linhas de código ruim. Temos que frisar outro ponto importante, tanto para desenvolvedores como para seus gerentes: Vocês NÃO cumprirão o prazo fazendo bagunça e escrevendo código porcaria. Pelo contrário, a sujeira vai te atrasar instantaneamente e irá forçá-lo a estourar o prazo. A ÚNICA forma de cumprir o prazo e a única forma de se mover rápido é manter o código o mais limpo possível o tempo todo.

Portanto, para ser um excelente programador siga sempre a regra dos escoteiros: Deixe a área do acampamento ainda mais limpo do que quando você a encontrou. Isto é, não limpe só o seu código mas também o código de outros que você precisa modificar. Não precisa ser uma mudança gigantesca. Mude o nome de uma variável para algo que faça mais sentido, quebre um método que esteja muito grande, elimine alguma duplicação de código, refatore um conjunto de ifs encadeados. Se todos limparem um pouquinho de código a cada check-in, a base de código sempre se manterá organizada e limpa.

Vamos supor que agora você acredite que escrever código tosco, ruim, fedido e macarrônico gera impedimentos significativos. Vamos dizer que você aceita a idéia de que a única forma de desenvolver com velocidade alta é ter uma base de código limpo. Você então deve estar se perguntando: "Como eu posso escrever código limpo? E mais, como posso identificar se um código é limpo ou não?". Bom, é aí que entra algo que todos os desenvolvedores deveriam fazer mais em suas carreiras: LER!

Algumas dicas iniciais de livros (há muitos mais, mas é melhor começar com os melhores :-) !) que te farão um melhor programador (confie em mim e leia os livros abaixo todinhos. Mas não leia apenas... ATUE no seu dia a dia usando o que aprendeu):

- Clean Code de Robert Martin
- Code Complete de Steve McConnell
- Emergent Design de Scott Bain

Vamos buscar uma maior qualidade e produtividade para a área de TI e todos sairão ganhando: clientes, fornecedores, desenvolvedores e o Brasil.

Usando o Rational Team Concert ( RTC ) para desenvolver aplicações C e C++

2009-01-20T15:12:00.005-02:00

Escrevi já dois artigos sobre o Rational Team Concert (RTC). O primeiro artigo fala da solução de uma maneira geral. O segundo artigo mostra as novas funcionalidades da versão 1.0.1 e a novidade do uso do Rational Team Concert com o mainframe. Hoje vou comentar um pouco do uso do Rational Team Concert para projetos desenvolvidos em C e C++.

Primeiro, devemos lembrar que o Rational Team Concert possui uma série de ferramentas colaborativas em sua base e um tripé formado por: sistema de planejamento de projeto baseado em um issue tracker, controle de versões integrado com o planejamento e um sistema de integração contínua para builds automatizados também integrado com o controle de versões e o planejamento de projeto.

Utilizar o RTC para desenvolver e controlar colaborativamente um projeto nas linguagens C e C++ é muito fácil. O primeiro passo seria ter no seu ambiente Eclipse o cliente do Rational Team Concert instalado (não esquecer de instalar e configurar o servidor Jazz!), bem como o famoso plugin Eclipse CDT. O Eclipse CDT é um plugin para o Eclipse que facilita bastante o desenvolvimento de aplicações C e C++.

Toda a fundação colaborativa e mais o sistema de controle de versões e o sistema de gestão de incidências funciona da mesma forma para desenvolver as aplicações C e C++. Todo o modelo de planejamento e controle de versões é igual e está integrado diretamente no Eclipse e em seus plugins.

O que muda, mas não gera tanto trabalho, é configurar o sistema de integração contínua para compilar e gerar o executável da aplicação em C e C++. O Rational Team Concert permite a customização da gestão automatizada de builds. Você pode configurar quantas vezes ele irá executar, em que períodos, etc. Mas, o mais importante é que ele permite que você execute qualquer aplicação de linha de comando. Não necessariamente devem ser as ferramentas de build Ant ou Maven. Portanto, você pode facilmente configurar a execução de um makefile!

Usando o Rational Team Concert em seus projetos C e C++ você ganhará produtividade, qualidade, o uso de processos ágeis de desenvolvimento de software ( como o Scrum ou o OpenUP ) e ainda a governança do seu desenvolvimento de software com pouquíssima burocracia e chateação para os desenvolvedores!

Caso tenha interesse em mais detalhes sobre o Rational Team Concert (na solução Java, C, C++ ou .NET) é só deixar seu comentário ou entrar em contato direto comigo.

O que impede uma organização de mudar do desenvolvimento tradicional para a agilidade e o pensamento lean?

2009-01-19T10:14:00.003-02:00

Acabei de finalizar a leitura do livro recém lançado The Art of Lean Software Development: A Practical and Incremental Approach de Curt Hibbs, Steve Jewett e Mike Sullivan.

No capítulo 2 os autores fazem a grande pergunta: se está claro (através de diversas pesquisas e casos reais) que o desenvolvimento tradicional e cascata frequentemente falha e que o desenvolvimento ágil e lean ( enxuto ) aumenta as chances de sucesso, o que impede as pessoas e organizações de fazer a troca?

Há muitas razões, mas os autores acreditam que duas são as principais: Medo e Confusão. Se manter no mesmo padrão de desenvolvimento pode parecer um caminho mais seguro (o antigo ditado "ninguém jamais foi demitido por comprar da IBM" pode ser adaptado para esse caso). Lutar pela implantação de um processo ágil e enxuto pode dar a sensação de ir atrás do novo e expor a carreira a um risco.

As pessoas podem se imaginar convencendo o chefe a adotar práticas ágeis e lean, vendendo a promessa de alta produtividade e maior qualidade. Agora é o pescoço dessa pessoa que está na corda para provar que isso pode acontecer. Há tantas novas práticas para entender e implementar (algumas que requerem treinamento técnico específico como o TDD, por exemplo). Além disso, a gerência ainda pode acabar inconscientemente (ou até conscientemente) sabotando o projeto ao periodicamente "pegar emprestados" recursos para outras tarefas ou amentando o escopo do projeto sem eliminar outras funcionalidades. E pior, a pessoa pode ainda não ter experiência suficiente para reconhecer os impactos que essas e outras ações terão nas promessas feitas.

No final, a pessoa possui medo de ser declarada a culpada de entregar o projeto fora do prazo e com orçamento estourado. E tudo porque ela insistiu em usar essa "nova onda de processos ágeis"!

Esse é o tipo de medo que acaba segurando muitas pessoas. É o mesmo medo que encontra-se em empresas que preferem não inovar para não canibalizar seus produtos existentes. É o medo clássico que dificulta qualquer tipo de mudança organizacional em empresas de qualquer porte. E é o medo que acaba levando muitas empresas a desaparecer por falta de inovação e criatividade.

Some a isso a confusão que uma pessoa tem quando entra no campo de conhecimento do desenvolvimento ágil e enxuto ao se deparar com centenas de livros, artigos, ofertas e soluções.

Concluindo, o medo e a confusão juntas se tornam a receita perfeita para a paralisia! Mostrar os benefícios já comprovados de se adotar metodologias ágeis e conseguir o comprometimento de toda a organização para a adoção é um passo essencial para eliminar o medo. Os livros sobre mudança organizacional de John Kotter podem ajudar nessa tarefa hercúlea. A confusão pode ser mitigada utilizando-se livros, treinamentos e consultoria especializada em processos ágeis e enxutos. Estes instrumentos podem acelerar uma adoção com menos percalços.

Em próximos artigos pretendo comentar sobre as diferenças conceituais dos termos Lean e Agile. Também pretendo tratar de um assunto pouco comentado nos círculos ágeis e que considero fundamental: a agilidade e o pensamento enxuto como instrumentos para alcanlçar resultados relacionados à estratégia competitiva de uma organização que desenvolve software como atividade meio ou atividade fim .

Artigos sobre Agile em publicações do PMI

2009-01-09T14:03:00.004-02:00

Alguns artigos tratando sobre o desenvolvimento ágil e gestão ágil e enxuta (lean) de projetos apareceram em publicações ligadas ao PMI (Project Management Institute).

Leitura interessante, para reforçar o que está perceptível nos países desenvolvidos: Agile virou mainstream e, apesar de percalços e erros de adoção, já é discutida por uma grande fatia do mercado de lá. É interessante notar também que muitos dos gerentes de projeto que estão adotando processos ágeis são PMPs.

No artigo Agile Software Development Projects Enable Adaptability and Success (subtítulo: Agile may be the cure for overdue, high-cost software development projects) o PMI descreve como o número de projetos de desenvolvimento de software entregues no prazo, no custo e com os requisitos necessários aumentou graças à maior adoção de processos ágeis. Eles utilizam o Chaos Report como evidência desse aumento de projetos bem sucedidos.

O outro artigo pode ser encontrado na revista PM Network, que é distribuída para os associados do PMI. Ele pode ser encontrado online na edição de janeiro de 2009. Procure, clicando em Contents, pelo título do artigo: "The Incredible Shrinking Team".

Agora basta a adoção aumentar aqui no Brasil, para não ficarmos para trás em produtividade e qualidade de software. Senão o melhor é ficar só exportando commodities agrícolas mesmo, porque não teremos chance de competir :-) !!!

Livros sobre o papel do Product Owner

2009-01-09T13:46:00.005-02:00

Robert Galen está escrevendo um livro sobre como se tornar um excelente Product Owner. O livro ainda está na fase de draft e está disponível online gratuitamente. Já possui um pouco mais de uma centena de páginas e é uma leitura fortemente recomendada para quem vai assumir esse crucial papel dentro de um projeto ágil.

Outra autora, Ana Forss, também escreveu uma introdução sobre o papel do Product Owner. O título do ensaio é Confessions of a Serial Product Owner .

Só para relembrar: o papel do Product Owner, dentro um projeto Scrum ou ágil, é o de definir as necessidades e requisitos do produto e também determinar o valor para o negócio e as prioridades de cada requisito. É ele quem gerencia o valor do Product Backlog.

Estimando e precificando projetos de software com contratos de preço fixo: O grande dilema

2008-12-18T10:41:00.008-02:00

Tenho uma palestra bem conhecida sobre contratação e estimativas de projetos de software. Ela trata bastante do assunto e mostra como não existe apenas contratos de preço fixo para se comprar projetos.

Porém, no Brasil, a grande maioria dos projetos desenvolvidos por fornecedores terceiros ainda continua sendo contratada na modalidade de preço fixo. Muitos agilistas apenas criticam o contrato, sem mostrar saídas quando não há outra alternativa e o cliente continua exigindo contratos de preço fixo. É claro que o ideal seria assinar um contrato de escopo variável ou deslizante e isso deve sempre ser tentado e negociado. Mas ainda temos muitas empresas que continuarão comprando na modalidade de preço fechado.

O grande autor Steve McConnell (dos livros Code Complete e Rapid Development entre outros) escreveu um artigo em seu blog com o título Estimation of Outsourced Projects. Vou aqui traduzir já resumidamente o artigo e ainda colocando minhas idéias no meio (portanto ele ficou um artigo diferente). Se não gostar você sempre pode ler o artigo original do grande mestre. No final vou incluir uma bibliografia selecionada para aprofundamento do assunto estimativas e precificação.

A questão que frequentemente se encontra no mercado é: "Nossa empresa vende projetos e outsourcing de sistemas para outras empresas. Normalmente os contratos são no modelo preço fixo (preço fechado). Há algo especial no tratamento de estimativas nesse contexto?"

Vamos então aos problemas e dores que encontramos no processo de estimativas de empresas: Se a estimativa faz com que o preço da empresa fique muito alto, pode-se perder o projeto. Se a estimativa faz com que o preço da empresa fique muito baixo, a empresa não só não terá lucro como pode até ter prejuízos maciços. Ambos são resultados indesejados e que são críticos para as empresas que possuem a venda de projetos de software como seu core business! Decorre-se daí o princípio primeiro (deveria ser a Prime Directive de uma empresa fornecedora de software) que é: o processo de estimativas e precificação teria de ser considerado peça e fundamento estratégico de empresas fornecedoras de software.

Tendo como ponto de partida que o processo de estimativas e precificação é estratégico para empresas fornecedoras de software (e vemos que muitas, mesmo sabendo disso, não investem na melhoria desse processo), vamos então a algumas recomendações:

1 - Se seu negócio depende em criar cotações com preços fixos e fechados, foque em habilidades de estimativas como uma competência central e trate-a como uma função crítica de negócio. Isso significa que essas empresas devem investir em treinamento, capacitação, livros e melhoria de seus processos de estimativas e precificação. Vide a lista de livros no final do artigo para começar assim que possível!

2 - Crie estimativas em ranges. Isto é, a estimativa não deve ser expressa em um único valor como, por exemplo, cem mil reais. Ela deve ser expressa em um range como: entre 50.000 reais e 200.000 reais. Melhor ainda se existir uma probabilidade ligada a cada um desses números. Exemplo: 15% de chance de concluir o projeto no orçamento considerando 50.000 reais; e 95% de chance de concluir com 200.000 reais. 120.000 reais nos dá uma chance de 75%. Para detalhes de como levantar essas probabilidades, vide a seção de livros sobre estimativas, compre-os e leia-os!

3 - Em um contexto de contratos de preço fixo, separe a estimativa do preço! Originalmente, em seu livro sobre estimativas, McConnell também chama isso de "separar a estimativa do comprometimento". É claro que a estimativa informa acerca do preço que será cobrado, mas não necessariamente há uma relação direta entre as duas variáveis. Você pode dar o preço no range mais baixo da estimativa (o que te dá uma baixa probabilidade de terminar no orçamento) se você realmente tem interesse de conseguir o negócio mesmo que perca dinheiro (usualmente por motivos estratégicos como entrar no cliente pela primeira vez, fazer um projeto importante dentro de um cliente existente, etc). Ou pode colocar o preço no range de cima caso não queira correr muitos riscos ou consiga mostrar um benefício extra para o cliente para obter um preço maior. É importante frisar essa recomendação porque já ouvi (e o McConnell também!) muitos vendedores insistindo para a área técnica reduzir as "estimativas" para conseguir o projeto, quando na verdade o que precisa ser reduzido é o preço! Isso cria confusão durante o projeto. Separar as estimativas dos preços aumenta a responsabilidade da equipe de vendas (eles precisam entender e arcar com o fato de que precificaram com o range mais baixo e o motivo que os levou a fazer isso). Melhora também o planejamento da equipe de desenvolvimento, porque se há um gap muito grande entre o preço e a estimativa, o projeto já deve ser planejado e gerenciado como sendo de altíssimo risco. Quando estimativa e preço são unificados em uma única palavra chamada "estimativa" (o que não é verdade pois foge à separação entre estimativa e comprometimento) é que começam a acontecer a maior parte dos conflitos e problemas de um projeto contratado.

4 - Tente não dar o preço/comprometimento logo no início do cone de incerteza. É claro que isso é o modelo ideal, mas muitas empresas não conseguem fazer isso com regularidade porque se sentem pressionadas competitivamente caso demorem para dar uma estimativa. Uma explicação para os leigos no assunto: O cone de incerteza define que erros de estimativa no início de um projeto pouco especificado podem ser da ordem de 4 vezes para cima ou para baixo !!! Recomendo ler o artigo The Cone of Uncertainty do Steve McConnell para entender porque ainda estimamos tão mal na indústria de software (na verdade se chega à conclusão que não é um problema de estimativa e sim de comprometimento!!!).

5 - Tente negociar para realizar os projetos em iterações ou pedaços menores. Quando você faz isso, os dados e métricas de preço e prazo das iterações iniciais ajudarão a estimar as próximas com maior chance de acerto. McConnell acredita que a calibração começa a ficar boa com 3 iterações realizadas, não importando o tamanha de cada iteração.

6 - Tente fazer cotações de preços com projetos tendo duas ou mais fases. Eu detalho como isso pode ser feito num projeto usando o RUP na minha palestra indicada acima. A idéia principal é que você consiga atacar as fontes de grande variabilidade e risco (como requisitos instáveis e a arquitetura executável) na primeira fase para conseguir precificar mais facilmente a segunda fase. Esse é a segunda oferta na negociação. A primeira é tentar um contrato de escopo variável (o ideal, mas mais difícil de conseguir).

7 - Colete dados históricos das estimativas em tempo de proposta versus os eventuais resultados para poder construir o cone de incerteza da sua empresa. Fazendo isso, você pode tratar estimativas de projetos com quantidades diferenciadas de informações de acordo com seu posicionamento no cone de incerteza. Isto é, projetos com poucos requisitos devem ser tratados como se estivessem bem no início do cone. Projetos com parte dos requisitos detalhados e já contendo uma arquitetura executável de referência devem ser tratados como estando no meio do cone.

8 - Seja fortemente iterativo assim que iniciar o projeto, não importando se foi precificado com uma ou duas fases. Desenvolver de forma iterativa vai te fornecer a real medida de progresso de um projeto. Construindo software em ciclos curtos você terá idéia dos riscos do projeto relativos a custos e prazos. Você conseguirá negociar com o cliente bem antes no ciclo de vida do projeto e assim não terá que ouvir a famosa frase: "Mas só agora, que faltam apenas 15 dias para colocar o sistema em produção, que você me avisa que o projeto vai atrasar?"

9 - Documente e detalhe o máximo possível todas as premissas que você assumiu ao estimar o projeto e coloque-as no contrato. Por exemplo, se o cliente não definiu uma plataforma para desenvolver o projeto, envolva o seu arquiteto e coloque no contrato exatamente qual plataforma, tecnologia, frameworks e componentes utilizará. Tente definir premissas e as acorde com o cliente. Ele deve aceitar essas premissas, especialmente em projetos onde o cliente quer o preço fixo mas não te fornece muitos detalhes de requisitos (o pior caso).

10 - Gerencie o conjunto de seus projetos e cotações como um portfólio de investimentos, isto é, aceitando que alguns vão dar lucro e outros darão prejuízo. De um ponto de vista realista, quando se estima no início do cone simplesmente não há uma resposta ou modelo mágico para melhorar uma estimativa projeto a projeto. O fato é que os resultados em relação às estimativas variarão em vários graus e frequentemente baseado na sorte. Agora, se você focar no portfólio de projetos como um todo você terá uma variação menor. Outro ponto importante é que os projetos são medidos nas empresas fornecedoras através de métricas financeiras. E em várias delas existe um único número para comparar todos os projetos. Isso é um erro! O número financeiro deve levar em conta as decisões tomadas pelos vendedores, especialmente quando explicitamente diminuem o preço para ganhar o projeto por motivos estratégicos (vide a recomendação 3). Seria um grande erro de gestão de recursos humanos premiar só as equipes ou gerentes de projetos que obtiveram grandes lucros nos projetos. É preciso avaliar também a estimativa original (e não o preço) e relacionar com as outras variáveis. Quando se recompensa alguém baseado em apenas uma variável você fará com que ele busque apenas uma variável esquecendo de outras (mas esse é um assunto longo para outro artigo!).

Finalizando, no final das contas a realidade é que não é possível resolver o problema específico de estimativas bem no início do cone de incerteza usando puramente práticas de estimativas. Você teria que mudar quando você está estimando (mais tarde no cone), o que você está estimando (portfolios versus projetos individuais) ou como você estima (usar contratos de escopo variável ou quebrar o projeto em duas ou mais fases). Portanto, não fique ansioso e desesperado com as estimativas feitas muito no início do cone. O erro delas não é seu... é da própria variabilidade inerente no desenvolvimento de software!

Bibliografia recomendada (ela se baseia só nos livros que eu li):

- McConnell, Steve. Software Estimation: Demystifying the Black Art, Redmond, Wa.: Micro-soft Press, 2006

- Stutzke, Richard D. Estimating Software-Intensive Systems, Upper Saddle River, N.J.: Addi-son Wesley, 2005

- Tockey, Steve. Return on Software, Boston, Mass.: Addison Wesley, 2005

- Boehm, Barry, et al. Software Cost Estimation with Cocomo II, Reading, Mass.: Addison Wesley, 2000

- Cohn, Mike. Agile Estimating and Planning, Upper Saddle River, N.J.: Prentice Hall Professional Technical Reference, 2006

- DeMarco, Tom and Timothy Lister. Waltzing with Bears: Managing Risk on Software Projects, New York: Dorset House, 2003

- Jones, Capers. Estimating Software Costs, New York: McGraw-Hill, 2007

- Putnam, Lawrence and Ware Myers. Five Core Metrics: The Intelligence Behind Successful Software Management, New York: Dorset House, 2003

Melhorando a qualidade e a testabilidade de um sistema com técnicas para quebra de dependências

2008-11-19T19:08:00.015-02:00

Em código de sistemas legados (e mesmo os que não deveriam ser tão legados assim!) encontramos módulos, classes ou métodos muito acoplados entre si e difíceis de serem testados unitariamente. Como os grandes papas do desenvolvimento de software explicam, esse tipo de dificuldade de testar possui forte ligação com um design ou arquitetura ruim.

Portanto: Código com alto nível de testabilidade é código bem projetado e código difícil de testar é mal projetado.

Usando técnicas (como refactoring, Test-Driven Development e Design Emergente) e design patterns apropriados podemos evitar um projeto ruim. Mas como melhorar a testabilidade de classes orientadas a objeto que não foram implementadas dessa forma? Para isso podemos usar algumas técnicas e refatorações (refactorings) apropriados. Isso facilitará os testes unitários de classes críticas de seu sistema e ainda, por tabela, melhorará o design de parte de seu sistema.

Para ajudar no entendimento das técnicas, vamos começar pelo exemplo simples de código Java abaixo:

public class TaxaDAO {
public double fetchRate(){
double rate = 0.0;
// Código para acessar o banco de dados e selecionar a taxa de uma tabela.
return rate;
}
}

public class BusinessRule {
private double commissionRate;
private TaxaDAO myTaxaDAO;

public BusinessRule(){
myTaxaDAO = new TaxaDAO();
this.commissionRate = 10.0;
}
public float getRate(){
double baseRate = myTaxaDAO.fetchRate();
return baseRate + (baseRate * commissionRate);
}
}

Neste exemplo, a classe BusinessRule possui comportamento testável e é importante testar o método getRate(). Porém, este depende diretamente de TaxaDAO. Podemos dizer que TaxaDAO é um objeto efêmero. Ele é efêmero porque possui um estado imprevisível. O valor de retorno do método fetchRate() irá variar de acordo com o conteúdo que está no banco de dados naquele momento específico. E essa imprevisibilidade afeta a testabilidade de qualquer objeto que use TaxaDAO. Além disso, não é boa prática criar testes unitários que dependam de operações de custo alto e tempo longo (conectar e acessar um banco de dados é uma delas).

Uma solução para esse problema seria criar uma versão de TaxaDAO que não entra em contado com a base de dados, retornando um valor conhecido sempre. De acordo com Koskela, dependendo do grau de complexidade este objeto alternativo pode ser conhecido como um stub, um fake ou um mock.

Mas ainda temos um problema. Como podemos fazer o objeto BusinessRule usar a versão substituta de TaxaDAO? Da forma como o design do código de produção está, isso é inviável. Aí podemos usar a primeira técnica de refactoring que nos ajudará nessa tarefa gloriosa: a refatoração Extract Interface. No clássico livro original de MartinFowler, a motivação para o uso de Extract Interface é quando várias classes possuem responsabilidades similares. Mas Michael Feathers nos explica que essa refatoração também é uma excelente técnica para quebrar as dependências entre módulos.

Vamos então para esta que é uma refatoração simples e que aplicaremos na classe TaxaDAO (você poderia fazê-la manualmente ou então usar o recurso de uma IDE que suporte refatorações. A última opção é melhor porque economiza seu tempo e seu cérebro... he, he).

public interface ITaxaDAO {
double fetchRate();
}

public class TaxaDAO implements ITaxaDAO {
public double fetchRate(){
double rate = 0.0;
// Código para acessar o banco de dados e selecionar a taxa de uma tabela.
return rate;
}
}

Extremamente simples, não é? Pois é, muitos refactorings são simples de fazer, outros nem tanto. O importante é que precisamos conhecê-los a fundo para sermos bom desenvolvedores de software! Mas voltando ao nosso exemplo depois da divagação...

Ainda não resolvemos o problema da dependência, pois precisamos modificar a classe BusinessRule. Temos duas possibilidades para resolver a quebra de dependência. Vamos mostrar primeiro a técnica de endo-testing.

Para fazer o endo-testing funcionar devemos primeiro aplicar outro refactoring na classe BusinessRule. É a refatoração Extract and override factory method. TEmos que também modificar a classe para utilizar a interface ITaxaDAO ao invés do objeto concreto TaxaDAO.

public class BusinessRule {
private double commissionRate;
private ITaxaDAO myTaxaDAO;

public BusinessRule(){
myTaxaDAO = makeTaxaDAO();
this.commissionRate = 10.0;
}

protected ITaxaDAO makeTaxaDAO(){
return new TaxaDAO();
}

public float getRate(){
double baseRate = myTaxaDAO.fetchRate();
return baseRate + (baseRate * commissionRate);
}
}

E voilá! Criamos um método chamado makeTaxaDAO() que cria o objeto concreto. O construtor agora faz referência apenas à interface ITaxaDAO. De acordo com Feathers, criação "hard-coded" de objetos diretamente no construtor é ruim quando queremos colocar uma classe sob teste. A refatoração Extract and override factory metgod é extremamente poderosa e simples para nos ajudar.

Mas ainda não terminamos. Como realizar essas refatorações nos ajuda a testar o código? Vamos mostrar agora como seria o código do teste unitário da classe BusinessRule, utilizando a técnica de mocks.

public class BusinessRuleTest extends TestCase {
private BusinessRule testBR;
private MockControl control;
private ITaxaDAO mockDAO;

public void setUp(){
control = EasyMock.controlFor(ITaxaDAO.class);
mockDAO = (ITaxaDAO)control.getMock();
testBR = new BusinessRule(){
protected ITaxaDAO makeTaxaDao(){
return mockDAO();
};
}
public void testGetRate(){
mockDAO.fetchRate();
control.setReturnValue(50.00);
control.activate();

assertEquals("Testando getRate()", 50 * .10,
testBR.getRate())
}
}

Que maluquices fizemos no código do teste unitário? Bom, não vou entrar em detalhes sobre o mock (espere os próximos capítulos!). Mas precisamos explicar o que acontece na criação de um novo objeto BusinessRule, para entender a sacada do endo-testing. O que fizemos na criação de BusinessRule foi criar uma inner class anônima que extende BusinessRule, mas que sobrescreve (overriding) o método makeTaxaDAO() para que ele retorne o mock do DAO ao invés do TaxaDAO concreto! Dessa forma, conseguimos resolver o problema da efemeralidade do objeto que acessa o banco de dados e ainda deixamos o design mais testável e orientado a serviços.

Mas esperem! Ainda não terminou :-). Eu comentei que há duas possibilidades para deixar a classe BusinessRule mais testável. Vamos mostrar a segunda técnica agora, com o uso de Dependency Injection. Algumas pessoas não gostam muito de fazer isso. Uma delas é o Scott Bain, autor do grande livro Emergent Design. Ele é fã do endo-testing. Mas, para quem vai usar um container de Inversão de Controle, nada melhor que usar essa segunda técnica. A injeção de dependências nada mais é que uma forma de definir uma classe de modo que ela receba uma dependência externa e não a acople diretamente no código. Vamos a um exemplo disso antes de voltar ao nosso código.

public interface IFoo
{
void bar();
void baz();
}

public class DatabaseFoo implements IFoo
{
void bar()
{
Database.selectBar().execute();
}

void baz()
{
Database.selectBaz().run();
}
}

A classe DatabaseFoo implementa a interface IFoo no código acima. Agora como uma classe poderia usar o objeto DatabaseFoo? O modo típico seria assim:

public class ImportantClass {
IFoo foo;

public ImportantClass()
{
this.foo = new DatabaseFoo();
}

void doReallyImportantStuff()
{
this.foo.bar();
}
}

Fazendo desta forma acima na classe ImportantClass, nós simplesmente detonamos a idéia de interfaces, já que estamos acoplando nosso código diretamente a DatabaseFoo. Como podemos resolver o problema? Injetando a dependência! Abaixo temos o construtor modificado para receber a interface IFoo como parâmetro.

public ImportantClass(IFoo foo)
{
this.foo = foo;
}

Essa é a famosa constructor-based injection. Poderia ser ainda field-based ou setter-based. Mas para o nosso exemplo a injeção via construtor já basta. Vamos retornar então ao nosso código e refatorá-lo para aceitar a injeção de dependência.

public class BusinessRule {
private double commissionRate;
private ITaxaDAO myTaxaDAO;

public BusinessRule(ITaxaDAO umTaxaDAO){
myTaxaDAO = umTaxaDAO();
this.commissionRate = 10.0;
}

public float getRate(){
double baseRate = myTaxaDAO.fetchRate();
return baseRate + (baseRate * commissionRate);
}
}

Perceba que usando essa técnica não precisamos de um factory method. O que fazemos é injetar um objeto que implemente ITaxaDAO diretamente via construtor. Vamos ver então como ficaria o teste de BusinessRule que utiliza injeção de dependência.

public class BusinessRuleTest extends TestCase {
private BusinessRule testBR;
private MockControl control;
private ITaxaDAO mockDAO;

public void setUp(){
control = EasyMock.controlFor(ITaxaDAO.class);
mockDAO = (ITaxaDAO)control.getMock();
testBR = new BusinessRule(mockDAO);
}
public void testGetRate(){
mockDAO.fetchRate();
control.setReturnValue(50.00);
control.activate();

assertEquals("Testando getRate()", 50 * .10,
testBR.getRate())
}
}

Note que agora nosso teste unitário não precisa mais de uma inner class anônima. O que fazemos é injetar diretamente o nosso Mock (lembre que ele implementa a mesma interface ITaxaDAO) através do construtor do objeto BusinessRule!

Alguém pode perguntar então: Legal, no teste unitário é perfeito, mas... e no código de produção? Como faremos a ligação, o acoplamento entre BusinessRule e TaxaDAO? É aí que entram os famosos frameworks de Inversão de Controle (IoC - Inversion of Control) como Spring, Google Guice, NInject, Unity e etc. Eles é que fazem a amarração e injetam as dependências necessárias. Mas esse artigo está muito longo, e não vou entrar em detalhes sobre esse assunto :-) .

Vamos concluir então: um sistema com boa testabilidade costuma ser um sistema mais bem projetado e arquitetado. Conforme detalhado por Meszaros, quando você utiliza técnicas como o Test-Driven Development você naturalmente acaba projetando para testabilidade (design for testability). Mesmo em sistemas legados, com algumas refatorações, podemos melhorar enormemente a testabilidade do sistema e, consequentemente, aumentar sua qualidade interna e externa.

Referências:

Michael Feathers - Working Effectively with Legacy Code
Gerard Meszaros - xUnit Test Patterns
Martin Fowler - Refactoring: Improving the Design of Existing Code
Scott Bain - Emergent Design
Lasse Koskela - Test-Driven: Practical TDD an Acceptance TDD for Java Developers
Artigo na IBM DeveloperWorks - Unit Testing with Mock Objects
Artigo na Wikipedia - Dependency Injection

Declínio e Queda do Movimento Ágil?

2008-11-18T15:18:00.004-02:00

Muita discussão aconteceu em torno de um segundo assunto nas listas e blogs de desenvolvimento ágil. O tópico se originou a partir do artigo de James Shore The Decline and Fall of Agile. Antes de dar minha opinião propriamente dita é interessante lembrar do livro de Edward Yourdon intitulado The Decline and Fall of the american programmer. Yourdon previu no livro que organizações de software e desenvolvedores americanos perderiam completamente seus negócios e empregos para desenvolvedores de outros países. É claro que isso não aconteceu e Yourdon até escreveu uma retratação de suas previsões no livro Rise and Ressurrection of the american programmer.

Poucos devem ter percebibo a semelhança do título do artigo de James Shore e do livro de Yourdon. Menos pessoas ainda devem fazer a alusão ao clássico livro de História de Edward Gibbon intitulado The History of the decline and fall of the roman empire. A grande diferença é que Gibbon escreveu seu livro posteriormente aos fatos relatados (por isso é História), enquanto Yourdon e Shore escreveramm como previsões (por isso é Futurologia). Esse comentário é só para lembrar que até grandes mestres e profundos conhecedores em determinados campos podem errar.

Mas vamos passar agora aos argumentos de Shore.

De acordo com ele, centenas de empresas estão aplicando mal o desenvolvimento ágil. Muitas estão falhando em atingir seus objetivos de iteração, estão tendo muito débito técnico e não conseguem testar suas aplicações. Segundo Shore, o problema está em que essas organizações e equipes usam apenas o que é mais fácil no Scrum (iterações e scrums) e ignoram as práticas de engenharia (como Test-Driven Development, Refactoring, Pair Programming, Testes de aceitação automatizados, Integração Contínua, etc). Concordo 100% com ele nesse sentido: equipes ágeis precisam adotar práticas de engenharia ágeis para realmente ter uma produtividade e qualidade acima dos padrões de mercado.

Shore acredita que, em parte, o problema desses acontecimentos tem a ver com o Scrum. Como o Scrum não possui práticas de engenharia em seu processo, isso levaria as pessoas a achar que TDD, Refactoring, Design emergente e outras não são importantes. Nesse ponto é que discordo com Shore. Como o próprio Ken Schwaber costuma dizer sobre Scrum: no início de sua adoção por uma empresa o que o Scrum fará é mostrar todos os problemas da sua equipe e da sua empresa. Scrum vai jogar toda a sujeira no ventilador e vai mostrá-la para todos os níveis hierárquicos. E isso é fundamental para entendermos o que queria Scwaber quando idealizou o Scrum. Talvez o problema é que isso seja pouco ou escassamente comentado por Scrum Trainers e por alguns consultores Scrum. É uma parte essencial do que prega o Scrum.

O Scrum força você a fazer entregas curtas de resultados em pequenos espaços de tempo. No início, isso levantará à tona dezenas ou centenas de problemas que a organização tem para alcançar essas metas curtas. E é a partir daí que as reuniões de retrospectiva no final de cada iteração e os próprios daily scrums mostram seu valor. Os problemas vão aparecer diariamente e a equipe, com o apoio da empresa, terá que atuar para resolvê-los. Nesse ponto é que um bom mentor de Agile deve entrar para ir aplicando, mentorizando e convencendo aos poucos sobre o uso de práticas técnicas de engenharia. Essa é a grande sacada do Scrum que talvez seja pouco esclarecida.

Seria ideal que as equipes já aderissem desde o início a um processo ágil recheado com práticas técnicas como o Extreme Programming, o Feature Driven Development ou ao OpenUP. O problema é que a maioria das pessoas aqui no Brasil já têm dificuldade de fazer e entender um simples planejamento iterativo, quanto mais desenvolver testes antes de código e refatorar continuamente seu trabalho.

Eu diria que o Scrum é apenas a porta de entrada para a agilidade. Uma equipe que não evoluir além disso, com certeza irá fracassar como o James Shore brilhantemente mostrou. Mas, ao mesmo tempo, adotar de cara um processo ágil mais completo também pode levar essas equipes a abandonar rapidamente suas tentativas, pois se eles não conseguirem usar acharão que agilidade não é para eles.

Portanto, para terminar falando de História novamente, vou parafrasear duas vezes Churchill para falar de Scrum:

- Scrum é a pior forma de metodologia, exceto por todas as outras que já foram tentadas de tempos em tempos...

- Não, Scrum não é o fim. Não é nem mesmo o começo do fim. Mas, provavelmente, é o fim do começo...

Qualidade de software na prática com Behavior Driven Development e Acceptance Test Driven Development

2008-11-17T15:00:00.005-02:00

Em um artigo anterior sobre qualidade interna e externa de software abordei a importância da testabilidade para a qualidade de um sistema. Reforçando a mensagem: quando você aumenta a testabilidade do software você diretamente melhora a sua arquitetura e o seu design. Desenvolver sem testes unitários automatizados e sem testes de aceitação é simplesmente já construir código legado desde o momento zero!

No artigo eu comentei sobre estratégias para melhorar a qualidade e a manutenibilidade, entrando brevemente no como fazer. Neste artigo vou falar mais do como fazer, tratando sobre técnicas de desenvolvimento de software modernas e ferramentas para apoiá-las: O Behavior driven development (desenvolvimento dirigido por comportamentos) e o Acceptance test driven development (desenvolvimento dirigido por testes de aceitação).

O behavior driven development foi inicalmente descrito por Dan North em seu artigo Introducing BDD. O BDD é similar ao Test Driven Development (TDD), mas é distinto em alguns pontos sutis, porém cruciais. Pelas convenções de TDD os métodos e classes de testes recebem nomes baseados nas classes de produção. BDD reorienta o foco para comportamentos do sistema. O BDD usa um template para se pensar no comportamento e nos testes do código:

Dado (Given) um contexto inicial

Quando (When) um evento ocorre

Então (Then) assegure alguns resultados.

O exemplo do artigo do Dan North é bem ilustrativo. Suponha a seguinte estória do usuário (user story):

Como um cliente, eu desejo sacar dinheiro da ATM, de modo que eu não precise gastar tempo na fila.

Como podemos saber quando essa estória está pronta (conceito de ‘done’)? Há vários cenários a se considerar. Alguns exemplos: conta tem crédito, a conta não tem mais limite de crédito. Usando o template acima o cenário 1 seria esse:

Cenário 1: Conta tem crédito

Dado que a conta possui crédito

E o cartão é válido

E a dispensadora contém dinheiro

Quando o cliente requisitar dinheiro

Então assegure que a conta seja debitada

E assegure que o dinheiro é dispensado

E assegura que o cartão é retornado.

O que isso muda em nossos testes unitários? Muda porque podemos usar uma ferramenta como o JBehave para desenvolver os testes no formato Dado / Quando / Então (Given / When / Then). O teste unitário fica voltado para os comportamentos e não mais para testar simplesmente métodos.

Porém, para equipes experientes e já acostumadas com TDD talvez essa mudança seja impactante. Para equipes novas seja mais complexo que um teste unitário simples. Por isso, a meu ver, o maior ganho do Behavior Driven Development está quando ele é unido com a técnica de Acceptance Test Driven Development (ATDD).

Segundo Koskela, em seu livro “Test Driven: Practical TDD and Acceptance TDD for Java Developers”, o TDD puro ajuda os desenvolvedores de software a produzir código de maior qualidade e manutenibilidade. O problema é que clientes raramente estão interessados em código. Eles querem sistemas que os tornem mais produtivos e gerem retornos sobre os investimentos. O ATDD ajuda a coordenar projetos de software de forma a entregar o que o cliente deseja.

Os testes de aceitação são especificações do comportamento e funcionalidade desejados para um sistema. Eles nos informam como, para uma determinada estória de usuário ou caso de uso, o sistema trata determinadas condições e entradas. Novamente conforme Koskela, um bom teste de aceitação deve ser:

- Propriedade dos clientes

- Escrito em conjunto com clientes, desenvolvedores e analistas de testes

- Sobre o O Que e não sobre o Como.

- Expresso na linguagem do domínio do problema

- Conciso, preciso e sem ambigüidades.

Até aqui fizemos uma descrição de um teste de aceitação que poderia simplesmente estar dentro de um documento Word ou planilha Excel. Então qual é a diferença do teste de aceitação tradicional para o teste de aceitação “clássico”? Primeiro é que no ATDD o teste deve ser automatizado. Esse é um ponto essencial para realizar testes regressivos contínuos. Em segundo lugar, os testes de aceitação são escritos ANTES da funcionalidade. Mas como? Seguindo os passos abaixo:

- Pegar uma estória ou fluxo de caso de uso

- Escrever os testes de aceitação na linguagem do domínio do cliente

- Automatizar os testes de aceitação

- Implementar funcionalidade.

É claro que ferramentas direcionadas para o ATDD ajudariam. Temos diversas open source no mercado como, por exemplo:

- Fitnesse

- S elenium

- Exactor

- TextTest

E por fim, a mais interessante e que vou comentar mais um pouco: Concordion.

O que você acharia se tivesse uma ferramenta que pudesse ler uma especificação de um caso de uso, de uma estória ou de um teste de aceitação escrito em linguagem comum e executasse esses passos em seu sistema automaticamente? Pois é, essa ferramenta existe, é open source e seu nome é Concordion. Ela é um framework que permite transformar uma descrição de requisitos em português em um teste automatizado, algo conhecido como especificação ativa. Portanto, uma especificação que se torna ainda mais útil porque a partir dela podemos executar testes automatizados!!!

Como ela funciona? Basicamente se escreve a especificação em um HTML simples, com comandos escondidos que definem o comportamento dos testes. A instrumentação dessa especificação é feita por uma classe Java que acompanha cada especificação e age como intermediário entre a especificação e o sistema sob teste.

Para alguns exemplos simples e interessantes basta estudar o tutorial do Concordion.

Outro ponto interessante do Concordion é que você pode exercer diretamente código da camada da aplicação ou de negócio ou então usar uma API que navega páginas Web. O site do Concordion recomenda o uso do WebDriver.

Por enquanto é só. Espero que tenha ajudado a esclarecer a importância do BDD e do ATDD para uma melhor qualidade e arquitetura de software. Não fiquem acanhados de tirar dúvidas ou colocar comentários. Basta escrevê-las aqui!

CMMI e Agile: O Retorno

2008-11-13T17:44:00.005-02:00

Já tratei sobre o assunto de CMMI e Agile em outro artigo, em que comentava minhas impressões sobre o tópico. Resumindo eu dizia que: Você pode fazer um processo ágil ficar aderente ao CMMI, porém terá um grande overhead (sobrecarga) de custo e prazo em cada um de seus projetos para conseguir isso. Escrevi isso baseado no excelente estudo do David Anderson sobre o tema, quando ele criou o MSF for CMMI.

Agora o SEI publicou um technical report sobre o assunto intitulado CMMI or Agile: Why not embrace both! E esse assunto deu o que falar nas comunidades e listas de discussão dos agilistas!

Uma das conclusões interessantes do relatório diz: "O Problema percebido entre Agile e CMMI não parte do Agile e CMMI serem inconsistentes inerentemente, mas de uma combinação de falsas percepções e experiências com algumas organizações que impõem processos padrões super pesados e restritivos em todos os projetos como parte do uso do CMMI".

É citado também o grandioso livro Peopleware de Tom DeMarco e Timothy Lister. Os autores afirmam que muitas organizações que passaram pelo CMMI acabaram se tornando avessas a riscos e conservadoras.

Mas, o objetivo final do relatório é tentar minimizar os conflitos entre os dois campos, reconhecer o valor de cada paradigma, eliminar erros e preconceitos mútuos.

O artigo também comenta um ponto que considero crucial. Em todas as discissões sobre o modelo CMMI é inevitável falar sobre a questão da avaliação (erroneamente chamada no mercado de certificação). O artigo reforça que é possível usar práticas alternativas para se atingir um objetivo do modelo. O problema é que vemos que mesmo os auditores oficiais treinados pelo SEI no SCAMPI(o guia de avaliação do CMMI) possuem dificuldade em aceitar ainda esses conceitos. Por ser um modelo, pode existir uma gama de interpretações diferentes no momento de uma validação via auditoria, especialmente devido à necessidade que o SCAMPI impõe em relação à existência de evidências diretas e indiretas da realização de práticas.

Do meu ponto de vista, o problemas não é o modelo CMMI em si, mas o SCAMPI e como é feita a avaliação. Quando se entra na busca do "selinho" é que ocorrem grande parte dos problemas, conforme já descrito no excelente livro "Measuring and Managing Performance in Organizations".

O método de avaliação SCAMPI tende a levar a uma busca frenética por evidências diretas e indiretas, já que os avaliadores oficiais do SEI possuem essa tendência (e sei disso por experiência própria, já que participei em SCAMPIs A e B). Se o SEI mudasse a forma como é feita a avaliação formal e como ela treina seus avaliadores (algo recomendado nesse novo technical report) talvez fosse útil uma organização agile tirar uma avaliação CMMI por motivos de negócio (entrar em licitações, etc). Agora, como está hoje definido o SCAMPI, se torna inevitavelmente necessário adaptar o processo ágil para que ele tenha chances de passar por uma avaliação. Pelo exemplo do próprio MSF for CMMI (discutido em meu artigo anterior) dá pra notar que é um overhead razoável para se adaptar e "passar" em um SCAMPI.

Acho que o primeiro passo concreto que o SEI poderia dar para se aproximar mais dos processos ágeis, seria adaptar o SCAMPI e definir melhor práticas alternativas no modelo CMMI.

Vamos ver o que o futuro reserva em relação a esse assunto!

IBM Rational Team Concert 1.0.1 e versão para System z

2008-11-06T09:09:00.005-02:00

Duas novidades saídas do forno na plataforma Jazz e na linha de produtos IBM Rational Team Concert.

A primeira é o lançamento da versão 1.0.1 do Rational Team Concert. Nós temos a tendência a achar que uma versão 1.0.1 é basicamente patch para correção de defeitos. Porém, o time do RTC desenvolveu nessa versão diversas funcionalidades e recursos novos como:

- Novos relatórios: estatísticas de Story points, Itens de trabalho fechados por iteração, atividade nos itens dia a dia.
- Licença flutuante para o RTC. Uma novidade interessante que pode ajudar a reduzir o investimento inicial necessário!
- Suporte ao banco de dados SQL Server.
- Melhorias no processo Scrum.
- Diagrama de fluxos do controle de versões.
- Suporte para localização de templates de processos (facilita a tradução).
- Outras estatísticas diversas.

A segunda novidade (e essa é para o pessoal da "velha guarda" do mainframe!!!) é o lançamento do Rational Team Concert for System z. Em dezembro, já teremos a primeira versão. Ela permitirá a instalação do servidor do RTC no System z. Mas a melhor notícia é que em 2009 o RTC para System z irá se integrar com a ferramenta Rational Developer for System z.

O Rational Developer for System z é uma ferramenta que permite que programadores COBOL, PL/I e EGL utilizem o Eclipse como plataforma de desenvolvimento de aplicações mainframe, trabalhando no mesmo ambiente líder de mercado dos programadores Java (o Eclipse). Essa ferramenta já se encontra disponível.

Qual o impacto então da integração do RTC com a ferramenta de desenvolvimento COBOL baseada no Eclipse? O impacto é que finalmente programadores mainframe podem usar as mesmas ferramentas e processos que programadores Java, .NET e etc. Isto é, controle de versões baseado em atividades, incidências e tarefas associadas com o código-fonte, integração contínua para COBOL, uso de processos ágeis como Scrum e OpenUP. Realmente uma revolução no processo de trabalho e uma melhoria de qualidade e produtividade para o mundo do mainframe! Programadores COBOL que costumavam reclamar que as ferramentas e soluções de ALM (Application Lifecycle Management) não funcionam muito bem para o mundo mainframe e COBOL (e que gostariam de ter algo assim), logo terão a oportunidade de se beneficiar desse lançamento.

Aguardem pelas notícias de lançamento e artigos mostrando o uso do RTC com o RDz para desenvolvimento COBOL!!!

O Zen da Gestão Ágil: Curso com David Anderson no Brasil

2008-10-16T11:03:00.004-03:00

O evento Zen of Agile Management está se aproximando! Será um evento fundamental e contará com a importante presença de David Anderson, autor do livro "Agile Management for Software Engineering" e um dos principais criadores do MSF 4.0 (Processo de desenvolvimento criado pela Microsoft). O curso acontece nos dias 21 e 22 de outubro de 2008.

Alguns dos tópicos do workshop:

- Como criar ou destruir confiança
- Minha receita para o sucesso
- Métricas, medição, rastreamento e indicadores para a Gestão Ágil
- Identificação de gargalos e Gestão por Restrições (TOC)
- Identificação de perdas
- Gestão de problemas e riscos
- Planejamento simples de iterações
- Planejamento avançado e previsível de iterações, baseado em processos de baixa variação
- Sistemas puxados e "Kanban"
- Seleção do mix de produtos e priorização
- Teoria das Opções Reais e o suporte à decisão
- Combinação de Agile e CMMI
- Como alcançar uma organização ágil de alta maturidade (cultura "Kaizen")

Blog Action Day 2008: A luta contra a pobreza e a Tecnologia da Informacao

2008-10-15T09:22:00.005-03:00

Hoje, dia 15 de outubro, é o Blog Action Day 2008. O tema deste ano é a luta contra a pobreza.

O que a área de Tecnologia da Informação pode fazer para ajudar nesse quesito? Basicamente, temos hoje a ferramenta por exclência para nos apoiar na luita contra a pobreza e a desigualdade social: a Internet. É empiricamente provado por diversos estudos de economistas que o nível educacional de um país está relacionado ao nível de pobreza deste. Um país com uma grande massa de pessoas despreparadas e com baixa escolaridade é mais pobre que países com alto nível educacional.

O acesso universal à Internet e a busca de um laptop por criança, portanto, deveriam ser políticas públicas que devemos buscar em nosso país. É claro que só o computador e o acesso à Internet não vão resolver. As pessoas precisam aprender a ler e escrever corretamente, não só o português como o inglês (grande parte útil do conteúdo disponível na Internet está na língua inglesa). Devem também ser ensinadas a operar corretamente o computador e seus diversos aplicativos.

Portanto, nesse Blog Action Day, vamos nos lembrar de fazer nossa parte e apoiar ONGs (como o Comitê pela Democratização da Informática) e políticas públicas voltadas para a universalização do acesso à maior biblioteca e fonte de informação da face da Terra: a Internet.

Arquitetura de Software: O que é e como documentar

2008-10-10T12:14:00.004-03:00

Resolvi escrever esse aartigo explicando brevemente o que é arquitetura de software depois de uma dúvida na lista de discussões UML Brasil. A dúvida acabava por confundir um pouco arquitetura de software APENAS como sendo o diagrama de classes de design. Antes fosse só isso... os arquitetos de software teriam muito mais tranquilidade... rs.

Vamos começar pela definição teórica clássica do IEEE no seu guia de recomendações IEEE 1471 (e que também se encontra no livro "Software Architecture in Practice, 2nd Edition"): "A arquitetura de um sistema de software é a estrutura ou estruturas do sistema, que contempla elementos de software, as propriedades visíveis externamente desses elementos e o relacionamento entre eles".

É claro que essa definição precisa ser detalhada, pois senão ficamos na mesma :-) .

Quando se fala de estruturas estamos falando de estruturas estáticas e dinâmicas. As estruturas dinâmicas definem como o sistema atua em tempo de execução, portanto apenas um diagrama de classes não resolveria esse ponto.

Quando falamos em propriedades externamente visíveis estamos falando das interações de um elemento ou um sistema com o seu ambiente externo. Pode ser os fluxos de informação de entrada e saída, a forma como o elemento responde aos estímulos externos e o contrato (a interface) desse elemento.

Outra definição importante, que encontramos no excelente livro "Software Systems Architecture: Working with stakeholders using viewpoints and perspectives", é a de que a arquitetura de software deve ser dirigida pelas necessidades dos envolvidos do projeto: clientes, usuários, departamento de TI, suporte, produção, operação, etc. A arquitetura de software não pode ser pensada sem o contexto dos stakeholders. Isso pode parecer óbvio, mas muitos sistemas por aí são feitos sem a devida atenção às necessidades dos envolvidos. Já vi muita gente escolhendo uma determinada arquitetura por ser a onda do momento, sem se perguntar profundamente se aquilo atenderia as necessidades do negócio. Resumindo: Arquiteturas devem ser criadas apenas para atender às necessidades dos stakeholders. Uma boa arquitetura é aquela que atende com sucesso os objetivos e necessidades de seus stakeholders.

Outra definição interessante, vinda do RUP, é a de que a arquitetura de software é um conjunto de decisões cruciais que restringem considerações de design e programação e que possuem um alto impacto para serem revertidas. Por exemplo, se for definido que o sistema será feito em JEE usando um framework Struts 2 então os desenvolvedores não poderão simplesmente desenvolver parte do sistema usando o Spring MVC. Além disso, mudar de Struts 2 para o Spring MVC, por exemplo, traria um alto impacto para a camada web da aplicação.

Além disso, é papel do arquiteto esclarecer as motivações por trás da escolha de determinados elementos arquiteturais em detrimento de outros. Também realizar análises "buy vc. build", isto é, comprar ou utilizar um componente open source ao invés de construí-lo do zero. Ou construir algo do zero considerando que no mercado existe já algo pronto para uso.

O arquiteto também deve enfatizar e focar nos atributos de qualidade do sistema, os chamados requisitos não-funcionais. Deve verificar necessidades vindas dos stakeholders relacionadas a performance, escalabilidade, manutenibilidade, segurança, internacionalização entre outras.

Para se ter uma idéia das várias "áreas" às quais um arquiteto deve endereçar, podemos recorrer novamente ao livro "Software Systems Architecture". O princípio inicial definido pelos autores é que "não é possível capturas as necessidades funcionais e as propriedades de qualidade de um sistema complexo em um único modelo compreensível". A partir daí é que surge a necessidade do que eles chamam de Visões e Perspectivas. O RUP possui o 4+1 View Model. O IEEE define até mais alguns. Algumas dessas Visões: Informacional, Concorrência, Desenvolvimento, Implantação, Operacional e Funcional. Já algumas das perspectivas importantes são: Segurança, Performance e Escalabilidade, Disponibilidade e Resiliência, Evolução, Acessibilidade, Internacionalização, Localização, Regulamentação e Usabilidade.

Agora pode surgir uma dúvida que é comum: devemos documentar essas coisas? Onde as documentamos?

É claro que não existe uma resposta genérica. Como tudo na Engenharia de Software... depende! Um sistema super simples não terá necessidade de documentação alguma. Um sistema super complexo (como o de um satélite ou de um Boeing) terá necessidade de uma documentação mais extensa.

Porém, para os casos em que estamos mais acostumados a trabalhar (sistemas e aplicações empresariais e corporativas) é recomendável ter, no mínimo, um "documento de arquitetura de software". Ele nem precisa ser um documento Word propriamente dito. Pode ser uma página de Wiki, uma folha A4, uma cartolina, etc.

Eu recomendo que esse documento seja sucinto e que tenha somente informações essenciais como:

- Elementos e componentes principais do sistema.
- Camadas do sistema.
- Mecanismos arquiteturais necessários ao sistema.
- Tecnologias escolhidas para resolver cada camada e mecanismo e a motivação por trás dessas escolhas.
- Componentes comprados ou open source que serão usados e como essa decisão foi realizada.
- Descrição dos principais design patterns utilizados e o porquê da escolha.
- Definição de como será feito o acesso a sistemas externos e/ou legados.

Além disso, algumas equipes podem sentir a necessidade de elaborar diagramas UML. Esses diagramas relacionados à arquitetura e ao design estarão no modelo de design (caso se use o RUP como processo de desenvolvimento). A equipe poderá usar diagramas de classe, de atividade, de sequencia, de estados, de componentes e de implantação para facilitar o entendimento visual dos elementos e de seus relacionamentos (conforme a definição de arquitetura de software feita pelo IEEE).

Reforçando e lembrando sempre que as atividades relacionadas à arquitetura são feitas de modo iterativo e incremental. Portanto, cuidado para não cair no modelo cascata e ficar durante longos períodos de tempo só escrevendo o documento de arquitetura. O bom e verdadeiro arquiteto é aquele que põe a mão na massa e prova com código e com testes que sua arquitetura realmente vai atender às necessidades de todos os stakeholders!!! Além disso, o arquiteto deve ser uma pessoa sociável e ir atrás dos stakeholders para validar suas decisões arquiteturais mais importantes.

Bom, essa é apenas uma pontinha introdutória sobre o assunto. Se alguém tiver mais dúvidas pode deixar um comentário nesse artigo!

JustJava 2008 - Sobre o painel de metodologias ágeis

2008-09-18T11:28:00.004-03:00

Participei do JustJava 2008 e fui um dos debatedores no Painel sobre metodologias ágeis, mediado pelo Jorge Diz e com presença também do Rodrigo Yoshima. Depois, fui convocado para participar do painel sobre tecnologias para integração e Java, onde tive oportunidade de falar sobre diversos tópicos como Cloud Computing, SOA (Service Oriented Architecture), Integração entre Java e .NET e Java com Mainframe.

Gostei muito do evento. O Painel sobre metodologias ágeis estava com um bom quórum e tive a oportunidade também de traçar ligações entre as mudanças (para melhor) feitas a partir do JEE 5 e o crescimento no uso de processos ágeis. Por exemplo, um dos aspectos melhorados foi a testabilidade da plataforma JEE, que foi alterado devido a uma forte pressão para modificar o modelo EJB 2 (que era péssimo para se testar unitariamente e que gerava dificuldades para o Test-Driven Development), vindo de profissionais que usavam o TDD como prática e processos ágeis em geral.

Abaixo algumas fotos do evento:

Rational Team Concert - Detalhes da nova solução de ALM da IBM Rational

2008-09-05T08:43:00.004-03:00

O Rational Team Concert é uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa, baseada na plataforma aberta Jazz. Nesse artigo, vou falar sobre seus principais recursos, suas três diferentes edições e preços, a visão futura da plataforma e a questão que ainda confunde novos e antigos clientes: o RTC substitui a suite Rational clássica?

Começando pelas funcionalidades: O RTC conta com um sistema de controle de incidências integrado com controle de versões (possui um sistema de controle de versões próprio e tem conector para o Subversion), wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo. Todas as edições do produto contam com esses recursos. Lembre-se que o Rational Team Concert pode ser usado como um plugin do Eclipse (é uma nova perspectiva) ou através de um browser Web conectado diretamente ao servidor (vide abaixo sobre o futuro do RTC para detalhes específicos relaciuonados a desenvolvedores .NET).

O RTC pode ser usado em três edições distintas (preços de acordo com a página do RTC no site oficial da IBM, na data deste artigo. Para informações mais atualizadas, pode me consultar! ):

- Express-C: permite até 10 usuários. Não possui custo de licença para o servidor e o custo por usuário é de 1200 dólares por desenvolvedor e 600 dólares por contribuidor. Usa como infra-estrutura o Tomcat e o banco de dados Derby.

- Express: permite até 50 usuários. Possui custo de licença de servidor de 6.000 dólares. O valor de licenças para desenvolvedor e contribuidor é o mesmo da edição Express-C. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Possui os mesmos recursos que a versão Express-C. A única grande diferença é a quantidade de usuários máximos permitidos.

- Standard: permite até 250 usuários. Possui custo de licença de servidor de 50.000 dólares. O valor de licenças para desenvolvedor é de 3900 dólares e o de contribuidor é o mesmo da edição Express. Usa como infra-estrutura o Tomcat ou o WebSphere Application Server e o banco de dados DB2 Express, DB2 ou Oracle. Além do maior número de usuários possui os seguintes recursos extras: Configuração de permissões de acesso baseado em papéis, Conectores para ClearCase e ClearQuest, Customização de itens de trabalho do gerenciador de incidências (nas versões Express-C e Express não é possível customizar os work itens), Customização de relatórios e dashboards executivos.

Uma dica e vantagem interessante: em qualquer uma das versões você tem o direito de usar 3 (três) licenças de desenvolvedor gratuitamente! Portanto, se você tem uma equipe de até 3 pessoas pode usar o RTC Express-C sem custo algum! Se sua equipe crescer você paga só pelo quarto usuário em diante.

O que podemos esperar para o futuro próximo do Rational Team Concert?

- Lançamento de um plugin para o Microsoft Visual Studio (hoje desenvolvedores .NET podem usar a ferramenta através do servidor Web mas, com o lançamento do plugin, o desenvolvedor não precisará mais sair da IDE para realizar o seu trabalho).

- Lançamento da edição Enterprise do Rational Team Concert (já virá com as novas versões do Rational ClearCase, ClearQuest e BuildForge. Versão 8.0 da suite Rational).

- Lançamento da ferramenta Requirements Composer, que já está em beta. Facilitará o processo de levantamento de requisitos e criação de protótipos rápidos. Essa ferramenta não substitui o RequisitePro. Elas possuem objetivos distintos: o Requirements Composer auxilia o analista de requisitos no levantamento e o ReqPro auxilia na gestão desses requisitos levantados com os stakeholders.

- Lançamento da ferramenta Quality Manager, que já está em beta. Fornecerá funcionalidade de gestão de testes e qualidade (será a evolução do Rational ClearQuest TestManager) já integrada dentro da plataforma Jazz.

E, para finalizar, vamos ajudar a responder a pergunta: o RTC substitui a suite Rational clássica?

Para empresas pequenas e médias ou equipes pequenas ou médias em grandes corporações o Rational Team Concert atenderá às necessidades imediatas que a suite Rational oferece. E com uma grande vantagem: uma velocidade muito maior (e custo menor!) de instalação, configuração, customização, treinamento, mentorização e administração da ferramenta (a suite Rational clássica demanda mais recursos e tempo, devido à sua grande capacidade de customização). Para times pequenos e médios que desejam usar um processo e ferramenta out-of-the box com as melhores práticas de processos e ferramentas existentes no mercado de desenvolvimento de software, essa é a ferramenta ideal.

Grandes empresas, que desejam uma maior flexibilidade de customizações, configurações e adaptações para adequar ferramentas ao seu processo continuarão necessitando da suite Rational clássica e, em 2009, usarão o novo empacotamento dessa suite, chamado de Rational Team Concert Enterprise. Mas já podem já adquirir a suite Rational Team Concert Standard e plugá-la em suas ferramentas atuais, para facilitar aind mais a vida das equipes de desenvolvimento!

Portanto, pequenos e médios times (de 1 a 250 usuários!) já possuem uma solução completa para suas necessidades de desenvolvimento colaborativo: o Rational Team Concert!

Caso você tenha lido este artigo e está avaliando uma possível aquisição deste produto e seus respectivos treinamentos, configurações e mentorizações entre em contato comigo que ajudarei no que for possível, inclusive para detalharmos face a face as vantagens da nova plataforma Jazz!

Artigos deste blog traduzidos para o espanhol!

2008-08-25T20:13:00.003-03:00

Acabei de descobrir que alguns artigos meus foram traduzido para o espanhol!

O primeiro é o artigo intitulado Scrum Master e sua importância - Antes de construir software, construir pessoas! Quem tiver interesse pode ler a versão espanhola do artigo: Antes de construir software, debemos construir personas!

O segundo é o Qualidade interna e externa de um software e seu código: Como garantir a entrega de um projeto de software com um bom nível de manutenibilidade. Quem tiver interesse pode ler a versão espanhola do artigo: Como hacer y/o comprar software de calidad.

Vídeo do Debate sobre Metodologias Ágeis no TDC 2008

2008-08-25T11:22:00.005-03:00

Participei de um debate sobre metodologias ágeis no The Developer's Conference 2008, realizado no dia 26 de julho de 2008. O Vinícius Teles, que também participou da mesa, gravou tudo e disponibilizou.

Tem assuntos bem interessantes e eu contribuí principalmente falando sobre o RUP e o OpenUP. Também comentei sobre o overhead necessário para se implantar um processo ágil que também atenda ao CMMI, levantando o exemplo do MSF da Microsoft.

Assistam então ao vídeo do debate sobre metodologias ágeis para terem vários pontos de vista acerca do tema.

Wicket in Action: Novo livro publicado sobre esse framework baseado em componentes

2008-08-21T09:50:00.006-03:00

Acaba de ser lançado em formato eletrônico, pela Manning, o livro Wicket in Action. Logo a versão impressa também aparecerá pelas prateleiras.

Existem zilhões de frameworks web para Java. E a cada dia parece que mais aparecem :-) . Apesar dessa profusão de frameworks fornecer uma grande liberdade e opção de escolha, de acordo com as necessidades específicas de cada projeto, ela também traz confusão em relação a qual framework adotar. Tem gente tão desesperada que chega a escrever em seu blog pedindo desesperadamente dicas sobre qual framework adotar :-) !!!

A escolha de usar um determinado framework é uma decisão arquitetural, isto é, tem um impacto de longo prazo no ciclo de vida de um sistema. Mudar essa escolha no meio do projeto ou da vida de um sistema é algo muito complexo e com alto custo.

O Wicket possui uma arquitetura muito interessante conhecida como component-based framework. Mas ao invés de entrar nos detalhes de como ela funciona vou citar apenas quais os benefícios que esse novo modelo fornece:

- Real separação entre o HTML e o código. Desse modo consegue-se obter realmente uma fácil separação entre o papel do web designer e do programador. Podemos dizer que este foi o principal objetivo almejado pelos idealizadores do Wicket.
- Não necessita de JSPs.
- Eliminação de mapeamentos em arquivos de configuração XML. A lógica de navegação é feita em código Java puro e não no "faces-config.xml". Isso torna o código type-safe e elimina o risco de erros difíceis de serem detectados e debugados em arquivos XML.
- Os formulários HTML possuem um "bind" direto com os POJOS. Podemos dizer que o Wicket realmente atinge um modelo de programação focado em POJOs.
- Todo o gerenciamento de estados é feito "automagicamente". É quase como uma biblioteca de interface gráfica para Desktop.
- O web controller é invisível.

Maiores detalhes comparativos, especialmente em relação ao JSF, podem ser encontrados no artigo A Wicket user tries JSF.

Para os que tiverem interesse em ver uma aplicação exemplo vale à pena ver o tutorial da IBM DeveloperWorks Develop a Simple Web Application with Apache Wicket and Apache Geronimo.

Outro framework baseado em páginas e componentes é o Click, para quem quiser comparar.

E, para quem quiser um framework MVC super simples e sem a praga dos XML, vai a dica do Waffle.

E, para quem adotar o Wicket em suas aplicações, é fortemente recomendável a leitura do livro Wicket in Action!

Scrum (ou Agile) com CMMI - É possível?

2008-07-28T14:58:00.006-03:00

Escrevo esse post movido por dois distintos eventos: o primeiro foi o excelente painel sobre metodologias ágeis que ocorreu no TDC 2008 e o segundo foi um posto na lista scrum-brasil sobre o assunto Scrum e CMMI.

A dúvida é: É possível fazer o Scrum ou outro processo ágil ficar aderente ao CMMI e ser avaliado oficialmente por um SCAMPI?

A resposta curta é: Você pode fazer um processo ágil ficar aderente ao CMMI, porém terá um grande overhead (sobrecarga) de custo e prazo em cada um de seus projetos para conseguir isso.

A resposta mais longa e com evidências(he, he!):

Para início de conversa, recomendo fortemente primeiro a leitura do artigo do David Anderson chamado Stretching Agile to fit CMMI Level 3. Anderson foi um dos criadores da nova versão do MSF (processo de desenvolvimento suportado pela Microsoft e mais conhecido por vir como padrão na ferramenta Visual Studio Team System) . Ele explica nesse artigo o que tiveram que fazer para conseguir adequar um processo ágil (o MSF for Agile) para atender o modelo do CMMI.

Fica claro no artigo que existiu um razoável overhead para isso acontecer. Anderson estudou só o overhead para atingir o CMMI nível 3. Se falássemos no nível 4 e no nível 5 o overhead seria ainda maior (teria que incluir controle estatístico de processos, análise causal, gerenciamento quantitativo de projetos, etc).

Segue a conclusão mais interessante de Anderson (negritos meus): "It was therefore necessary to enhance MSF for Agile Software Development with additional activities to cover these aspects of the CMMI. This was non-trivial. The footprint of the guidance material for MSF for CMMI Process Improvement is 150% larger than that of MSF for Agile Software Development. So some large amount of stretching was necessary. For example, MSF for Agile Software Development has 25 work product artifacts whilst the CMMI method has 59. There are 9 metric charts with the agile method whilst the CMMI method has 12. "

Portanto, você pode até atingir o CMMI usando um processo ágil e isso é legal. Porém, tenha em mente que não existe uma solução mágica para isso e avaliadores CMMI (que usam o SCAMPI) ainda determinam a necessidade de documentação explícita (chamados de artefatos diretos e indiretos) para cada uma das práticas específicas das áreas de processo do CMMI.

Tendo isso em mente, você e sua empresa devem estar cientes do grande overhead que será necessário para o processo ágil ficar aderente ao CMMI. Se a empresa realmente necessita do CMMI para governança, como estratégia de marketing ou outro fator qualquer ela antes deve ter consciência que um projeto feito com "Agile CMMI" terá mais custo e será mais lento que um projeto feito com "Agile Agile".

O Adail Retamal da Heptagon respondeu à minha conclusão com um outro dado muito interessante que aqui transcrevo:

"É isso aí, Papo! Nos meus cursos e consultorias sempre saliento esses aspectos também. Minha proposição para um Agile CMMI é:

Nível 2: Scrum, parte da FDD, PSM
Nível 3: + FDD, parte da TOC, algo de Lean
Nível 4: + Six Sigma
Nível 5: + TOC

Claro que outras ajudas serão necessárias para atender certas PAs, mas essa receitinha já abrange uns 80%..."

Mais detalhes sobre esse assunto de Scrum, Agile e CMMI podem ser encontrados no meu artigo Scrum, OpenUP e CMMI.

Evento TDC 2008 - Participação no painel sobre processos de software

2008-07-23T09:49:00.003-03:00

Será realizado na cidade de São Paulo, neste próximo final de semana (dias 25 e 26 de Julho), o evento TDC 2008 - The Developers Conference, que é organizado pela empresa GlobalCode.

Nesse evento, além da excelente trilha sobre Java, teremos uma trilha de palestras bem interessantes sobre metodologias ágeis e engenharia de software, feitas por vários colegas e amigos. Serei um dos participantes do painel final no sábado sobre processos de software.

Abaixo a lista de palestras de amigos no evento:

Estratégias para testes: a metáfora da pirâmide alimentar - Jorge Diz e Kleber Xavier

Scrum - Juan Bernabó

Modelagem Ágil - Manoel Pimentel

eXtreme Programming - Vinícius Manhães Teles

Conheça a iniciativa Jazz da IBM - Pessoas constroem grandes aplicações, não empresas! - Rodolpho Rugolini

Painel Gestão, metodologias e processos de software: com a teoria, a prática é outra - Jorge Diz, Vinicius Teles, Manoel Pimentel, André Piza, Adriano Romero, Enio Stein, José Papo

Veja a Programação do TDC para maiores detalhes de todas as palestras.

Scrum Master e sua importância - "Antes de construir software, construir pessoas!"

2008-06-25T09:03:00.007-03:00

Pretendo aqui ajudar a esclarecer a importância do Scrum Master, qual seu papel em uma organização de desenvolvimento de software que aprende e como devem ser suas características de liderança.

Resolvi escrever esse artigo baseado em duas inspirações: A primeira é a série de livros fenomenais que descrevem em detalhes o Sistema Toyota de Produção (ou Produção Lean), sua filosofia e cultura(os livros são: The Toyota Way, The Toyota Way Fieldbook, Toyota Talent e Toyota Culture). A segunda inspiração teve como base os debates ocorridos nas listas sobre desenvolvimento ágil, tratando sobre se o scrum master é necessário e se o scrum master é uma função única.

Quando falamos do Scrum Master não estamos falando de uma função meramente técnica. Ela é uma função de liderança. Porém, uma liderança diferente daquela encontrada ainda em muitas empresas: o estilo de gestão comando e controle. Estamos falando de uma liderança servidora. Podemos fazer uma analogia com outras organizações, como por exemplo as religiões judaica e cristã protestante. Nessas organizações, uma premissa fundamental é que os fiéis podem ter um contato direto com o Divino, sem necessidade de intermediários. Porém, mesmo assim encontramos as figuras dos rabinos e pastores. Para que eles servem? Eles são o que considero um modelo da liderança servidora. O papel deles não é dizer que só através deles se chega à salvação. Seu principal objetivo é ajudar e servir à sua comunidade, da melhor maneira possível. Ser um guia espiritual e um visionário, que busca compreender e vivenciar a cada dia que passa um pouco mais sobre sua filosofia e transmiti-la àqueles aos quais servem.

O Scrum Master também é um líder nesse sentido. E o capítulo 15 do livro "The Toyota Way", de Jeffrey Liker, me ajudou a compreender a diferença profunda entre os vários tipos de líderes que encontramos e qual é o líder esperado em empresas que buscam o pensamento ágil, enxuto e de uma "Learning Organization". O capítulo explica o Princípio número 9 do Modelo Toyota: "Crie líderes que entendem em profundidade o trabalho, vivam a filosofia e a ensinem para os outros".

Liker descreveu as diferentes formas de liderança através de uma matriz com duas dimensões e que definem quatro possíveis tipos de líderes. A figura abaixo ajuda a entendê-la.

A primeira dimensão define que o líder pode dirigir de cima para baixo através de regras ou então de baixo para cima em um estilo mais participativo para desenvolver as pessoas de modo que elas pensem e tomem as decisões sozinhas.

A segunda dimensão diz que um líder pode ter um entendimento profundo do trabalho ou conhecimento gerencial genérico. Em muitos lugares, de acordo com Liker, existe ainda a noção de que o gerente bem sucedido típico é aquele que tem um MBA e que pode ir para qualquer negócio e instantaneamente trabalhar nele olhando para números e usando princípios de gestão genéricos. (Nenhum gerente da Toyota aceita essa noção. Todos conhecem e inclusive já trabalharam nas organizações de engenharia e no chão de fábrica).

Vamos então entender os quatro tipos possíveis de gerentes:

Gerente burocrata (Top-down e com conhecimento genérico de gestão): é o menos eficaz de todos. Segundo Liker caracteriza a maioria dos gerentes americanos atuais(será que o Brasil é igual?). Como uma pessoa pode ser eficaz tentando gerenciar uma organização de cima para baixo sem ter um conhecimento íntimo e profundo do que está acontecendo e de como esse trabalho é realizado? Eles só possuem uma chance e a usam: criam toneladas de regras e políticas e medem a performance com base nessas regras e políticas. Isso leva a um gerenciamento dirigido por métricas que tira o foco da satisfação dos clientes ou em construir uma organização que aprende.

Facilitador de grupos (Bottom-up e com conhecimento genérico de gestão): Este tipo de gerente é aquele que se baseia na crença de que se um líder possui fortes habilidades de facilitação, ele pode motivas os empregados a trabalhar em conjunto rumo a um objetivo em comum. Facilitadores são catalisadores, porém não conseguem ensinar ou guiar as pessoas em relação ao que devem fazer no dia a dia. Esses líderes podem ser ótimos para motivar equipes e ajudá-las a se desenvolver. Mas eles realmente podem fazer coaching e mentorizar outros naquilo que eles não entendem? Eles nem mesmo possuem a experiência para julgar as contribuições e o trabalho dos seus subordinados.

Mestre de Tarefas (Top-down e com conhecimento profundo do trabalho): Esse tipo de gerente trata os subordinados como marionetes, puxando todas as cordas. Isso se torna um grande fardo, pois uma corda puxada de forma errada pode fazer o processo de trabalho entrar em colapso. Esse líder costuma desconfiar de outros com menos experiência. Como o gerente burocrata, ele dará ordens, mas ordens para fazer tarefas específicas exatamente como ordenado. Essa é a definição de micro-gerenciamento.

Construtor de Organizações que aprendem (Bottom-up e com conhecimento profundo do trabalho): Por terem uma combinação de entendimento profundo do trabalho e a habilidade para desenvolver, mentorizar e liderar pessoas são respeitados por seu conhecimento técnico e são seguidos por suas qualidades de liderança. Esses líderes raramente dão ordens. De fato, esses líderes frequentemente lideram e mentorizam através de questionamentos. Esse líder fará perguntas sobre uma situação e sobre a estratégia da pessoa ou da equipe para resolvê-la, mas não darão nenhuma resposta a essas questões apesar de terem o conhecimento.

Os grandes líderes da história da Toyota possuem as seguintes características:

- Focados numa visão de longo prazo
- Nunca desviavam dos princípios do "Toyota Way" e se modelavam em torno desses princípios para todos verem. Adotavam uma postura de professores e mentores diariamente.
- Cresceram na hierarquia através do trabalho de chão de fábrica e/ou de engenharia e sempre continuaram indo ao local atual onde o trabalho de valor agregado é feito.
- Viam problemas como oportunidades para ensinar e mentorizar as pessoas.

Uma frase comum ouvida na Toyota é: "Antes de contruirmos carros, construímos pessoas". O objetivo dos líderes na Toyota é desenvolver as pessoas para que estas sejam fortes contribuidores para a empresa e que estejam imbuídas dos princípios de auto-gestão e de melhoria contínua realizada por todos os membros de uma equipe.

O grande desafio do líder é ter as três seguintes características: a visão de longo prazo de saber o que fazer, o conhecimento de como fazer e a habilidade de desenvolver pessoas para que possam entender e fazer seu trabalho de forma excelente. O benefício dessa dedicação é mais profunda e duradoura para a competitividade de uma empresa do que usar um líder apenas para resolver problemas financeiros imediatos ou tomar uma decisão para um situação determinada de curto prazo.

É interessante notar que outro conceito usado na Toyota é o de "não fazer compromissos". Isso significa que eles questionam continuamente o "ou". Discussões - como, por exemplo, o que é melhor... um scrum master com habilidades para lidar com pessoas "OU" um scrum master técnico? - são respondidas com: o melhor é ter um gerente de pessoas "E" um gerente técnico. Ou então: o Scrum Master deve fazer só atividades de facilitação e remoção de impedimentos "OU" fazer atividades técnicas? A resposta Toyota seria: deve fazer ambos :-) . Muitas vezes criamos dicotomias que podem ser implodidas com uma análise mais "lean".

A conclusão então é: o Scrum Master é um papel essencial. Precisamos de figuras de liderança servidora nas organizações criadas por seres humanos. O melhor tipo de líder para se tornar um Scrum Master é o construtor de organizações que aprendem (lideram bottom-up e têm conhecimento profundo sobre desenvolvimento de software, isto é, são líderes servidores/professores que respiram e amam o que fazem).

Espero que essas dicas vindas da precursora do pensamento enxuto (Lean Thinking) possam ajudar a entender melhor o papel e a importância do Scrum Master ou de um líder de projetos numa organização de TI.

Vamos então seguir o mesmo caminho: "Antes de construir software, devemos construir pessoas!"

Considerações sobre o RSDC 2008 em Orlando, EUA

2008-06-12T13:15:00.004-03:00

Agora que estou de volta ao Brasil, vou compartilhar importantes informações e insights que tive ao assistir a dezenas de palestras na Rational Software Development Conference 2008 realizada em Orlando - Flórida - Estados Unidos.

Começando pelas palestras dos keynote speakers Danny Sabah, Gerente Geral da IBM Rational; Colleen Arnold, Gerente Geral da IBM Global Services; Steve Mills, executivo do IBM Software Group e Grady Booch, um dos três amigos. O que podemos tirar de ponto mais importante, especialmente para a comunidade de desenvolvimento ágil é: a IBM globalmente está adotando processos ágeis de desenvolvimento. Iniciou e já está em pleno vapor o seu uso nas equipes que desenvolvem os produtos da IBM como o WebSphere, produtos Rational, etc.

As palestras sobre Jazz mostraram claramente que o próprio produto Rational Team Concert foi desenvolvido com base em técnicas ágeis de desenvolvimento (e o Jazz foi construído usando o Jazz!). Colleen Arnold da IBM Services também declarou que já está em andamento o processo de transformação cultural para adoção de agile nas divisões de serviços. Scott Ambler, Erich Gamma, entre outros são líderes nesse processo de transformação dentro da IBM. Eles estão mentorizando equipes IBM ao redor do mundo no uso de desenvolvimento ágil com escala.

Creio que esse é mais um dos exemplos de uma gigante de software e de serviços ligados a Tecnologia da Informação que estão embarcando no uso global dos processos ágeis.

O segundo ponto importante, relacionado ao novo produto Rational Team Concert, é que agora temos uma forma ainda mais simples de obter agilidade com governança. Há muita gente que ainda acredita que existe uma dicotomia entre agilidade e governança, o que é um mito. Já tratei desse assunto em um artigo no meu blog.

Com a ferramenta Rational Team Concert podemos dizer que essa realidade da agilidade com governança se tornou ainda mais simples de atingir. Sua idéia é de ser uma robusta ferramenta de ALM (Application Lifecycle Management) colaborativa. A palavra colaboração aí é a grande novidade dentro desse novo produto. Além disso, o RTC possui um fantástico recurso que, feita a configuração e customização do processo, faz com que a equipe tenha (isso mesmo, seja obrigada!) que realizar atividades (work items) do processo que foram definidas como obrigatórias para poder continuar o seu trabalho. A ferramenta não só lembra as tarefas, como também obriga o time a realizar aquelas fundamentais. Mas é importante reforçar: a ferramenta pode ser configurada para apenas lembrar quais são as tarefas e não obrigar os times a fazê-las. Esse recurso é útil para empresas que precisam seguir padrões de governança como SOX, Cobit, etc e desejam definir atividades de compliance como obrigatórias dentro do processo. Mas todas as atividades podem ser opcionais, se assim for o desejo da equipe e/ou empresa!

O RTC também conta com um sistema de controle de incidências integrado com controle de versões, wiki, sistema de integração contínua e um servidor portal que gera as mais diversas métricas, relatórios e informações executivas sobre os projetos. É o nirvana dos desenvolvedores e gerentes de projeto!

E, se não bastasse, mais uma outra ótima informação para a comunidade ágil. O Rational Team Concert já vêm com dois processos pré-definidos na "caixinha": são eles o Scrum e o OpenUP. Além é claro da flexibilidade que o RTC fornece para a equipe configurar seu próprio processo.

Posso resumir então os principais toques e insights dessa conferência em:

1 - A IBM, como todas as outras gigantes produtoras de software, já embarcaram e entraram de cabeça no mundo do desenvolvimento ágil... só falta você :-) .

2 - O lançamento oficial do Rational Team Concert eleva a um novo patamar a necessária integração entre Agilidade e Governança. A governança agora pode existir sem muitos empecilhos e burocracia, graças à automação proporcionada pela ferramenta.

Com certeza, duas grandes notícias para a indústria de Tecnologia da Informação do Brasil e do mundo!

Futuramente escreverei artigos descrevendo em mais detalhes as mais importantes funcionalidades do Rational Team Concert e como estas auxiliam na adoção de processos ágeis no desenvolvimento de software.

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA - Parte 2

2008-06-06T00:17:00.015-03:00

Continuando a série de fotos tiradas com os líderes e autores importantes no mundo de desenvolvimento de software. Temos também algumas fotos com amigos da IBM Rational Brasil.

Foto com Terry Quatrani (autora dos livros "Visual Modeling with Rational Rose and UML" e "Visual Modeling with Rational Software Architect and UML"):

Foto com Erich Gamma (um dos membros da GoF - Gang of Four - co-autor do livro "DEsign PAtterns" e líder do projeto Jazz e Rational Team Concert da IBM Rational):

Foto com Peter Eeles (co-autor do livro "Building J2EE Applications with the RUP"):

Foto com Kurt Bittner (co-autor dos livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):

Foto com Per Kroll (co-autor do livro "Agility and Discipline Made Easy: Practices from OpenUP and RUP" e "RUP Made Easy"):

Foto com Joe Marasco (autor do livro "The Software Development Edge"):

Foto com Wagner Arnaut (IBM Rational Brasil):

Foto com Paulo Henrique Cruz nos Estúdios da Universal(IBM Rational Brasil):

Foto com Callado (IBM Rational Brasil):

Fotos com líderes e visionários do desenvolvimento de software - RSDC 2008 Orlando EUA

2008-06-03T00:52:00.014-03:00

Caros,

No primeiro dia assisti a palestras de grandes nomes do desenvolvimento de software. Nesse post vou apenas colocar algumas das fotos minhas com os grandes papas da engenharia de software atual. Mais tarde, quando eu tiver mais tempo(pois já está tarde e preciso acordar cedo para o segundo dia de evento... he, he!), vou postar sobre os temas que assisti. Amanhã e quarta vou assistir a palestras de Erich Gamma, Per Kroll, Terry Quatrani, Kurt Bittner, Joe Marasco e Peter Eeles. Aguardem mais fotos!!!

Creio que principalmente quem trabalha, como eu, durante 8 a 10 horas por dia tendo como base a idéia desses mestres ( e ainda estuda, prepara aulas, leciona e discute esses conceitos com os alunos por mais 4 a 6 horas por dia podendo totalizar facilmente umas 16 horas por dia!!!) é que terá a noção da grande honra, emoção e alegria que é poder ouvir de perto, conversar e trocar idéias com esses gigantes do mundo de desenvolvimento de software.

Agora chega de devaneios... vamos às fotos :-) !!!

Foto com Grady Booch (um dos Três Amigos, co-criador da UML e autor dos livros "Object-Oriented Analisys and Design with Applications" e "UML Users Guide"):

Foto com Ivar Jacobson (Outro dos três amigos. Co-autor da UML, autor de livros como "UML Users Guide" e criador do conceito de casos de uso):

Foto com Scott Ambler (Autor de livros como "Agile Modeling", "Object Primer" e "Refactoring Databases"):

Foto com Murray Cantor (Autor do livro "Software Leadership" e líder do plugin RUP para System Engineering):

Foto com Ian Spence (co-autor com Kurt Bittner dos excelentes e fundamentais livros "Use Case Modeling" e "Managing Iterative Software Development Projects"):

Sobre a IBM Rational Software Development Conference 2008

2008-05-28T15:27:00.005-03:00

Dos dias 1 a 5 de junho ocorre em Orlando, Estados Unidos o evento IBM Rational Software Development Conference 2008. Será um evento gigante, contendo centenas de sessões interessantíssimas sobre técnicas e ferramentas para apoiar o desenvolvimento e a engenharia de software.

Participarei do evento e pretendo escrever em meu blog (espero que tenha uma rede wireless lá nas salas da conferência!) sobre todas as novidades. Se possível, vou colocar fotos também.

Vamos ver se consigo tirar fotos com o William Shatner (sim, o capitão Kirk da Enterprise!!!), com o Erich Gamma (um dos caras da GoF) e com o Grady Booch. Vou aproveitar para levar alguns dos meus livros para pegar uns autógrafos. Não voltarei sem ter o meu livro "Design Patterns" assinado pelo próprio Gamma :-) !

Aguardem as notícias e artigos sobre o evento a partir do dia primeiro de junho!!!

Os doze passos para desenvolver software altamente eficaz

2008-05-13T09:42:00.004-03:00

Lendo o livro Dreaming in Code, encontrei uma referência muito interessante para o chamado Joel Test.

Joel Spolsky, um grande desenvolvedor de software. Ex-Microsoft e que possui agora uma companhia que produz uma inovadora ferramenta de gestão de incidências chamada FogBugz.

Ele fez uma lista com 12 passos para medir se um time é bom ou não. O time ganha um ponto para cada passo que possui. 12 é um score perfeito, 11 é tolerável. 10 ou menos e você tem problemas. Segundo ele, que também é um prolífico autor e pesquisador na área de desenvolvimento de software, a verdade é que a maioria das organizações de software possui um score de 2 ou 3!

Aí vão os pontos essenciais:

1. Você usa controle de versões?

2. Você pode criar um build e sua documentação em somente um passo?

3. Você faz builds diários?

4. Você tem uma ferramenta de gestão de defeitos e incidências?

5. Você corrige defeitos antes de escrever código novo?

6. Você tem um cronograma e o mantém continuamente atualizado?

7. Você tem uma especificação?

8. Os programadores tem condições de trabalho tranqüilas?

9. Você usa as melhores ferramentas que o dinheiro pode comprar?

10. Você tem testadores?

11. Novos candidatos escrevem código durante a entrevista?

12. Você faz testes de usabilidade?

Seminário de gestão de projetos de software na FIAP

2008-05-06T09:03:00.005-03:00

No dia 10 de maio de 2008, na FIAP, serei um dos palestrantes no seminário de gestão de projetos de software da Tempo Real Eventos.

Vou falar um pouco sobre o OpenUP e como ele pode ajudar as empresas a adotar um processo de desenvolvimento de software ágil e simples de utilizar.

Resumo da minha palestra:

OpenUP - A Abordagem ágil baseada no processo unificado

Tópicos

OpenUP: Origens
Princípios Fundamentais
Ciclo de Vida
Papéis
Artefatos
Gestão de projetos ágil com OpenUP
Aprendendo mais sobre OpenUP.

Pré Requisitos(para se tirar melhor proveito da apresentação): Conhecimento básico de Engenharia de Software.

Público Alvo: Gerentes de projeto, engenheiros de processos, analistas de qualidade, analistas de sistemas, desenvolvedores.

LookupPage e Naymz: Novos serviços Web 2.0 para visibilidade pessoal na Internet

2008-04-28T09:55:00.006-03:00

Dois novos serviços de colaboração e comunidade Web 2.0 foram lançados. São serviços muito interessantes e com propostas similares em alguns pontos.

O primeiro é o LookupPage. Ele tem como proposta ser uma ferramenta de marketing pessoal que torna o seu nome altamente visível no Google. Como ele faz isso? Ele compra links pagos do Google e, desse modo, seu nome aparece como um link patrocinado caso alguém faça uma busca!

O segundo serviço é o Naymz. Ele também promove seu nome em sites de busca, através de pontos de reputação. Se você chega a um RepScore de 9 você ganha links pagos no Google com seu nome!

O LookupPage é um serviço pago. Entrei nele porque fui achado através de meus sites e convidado para ser um beta user de graça! Entrei em contato com uma representante da empresa e ela forneceu um código para quem desejar um desconto de 80% no serviço. O cupom de desconto é: 9hc6GC .

O Naymz começa gratuitamente. Caso você pague pela conta premium o serviço é extendido e seu nome aparecerá como link pago em outros sites de busca como Yahoo! e MSN.

Só para vocês terem uma idéia, podem fazer uma pesquisa no Google pelo nome Jose Papo para ver como fica.

Abaixo tem um screenshot dessa pesquisa: