Marco Mendes´s Blog

Se a sua empresa lembra o programa Zorra Total, talvez seja interessante trocar de canal. A troca de canal significa pensar sua empresa como uma coleção de processos e implementar práticas ágeis de BPM e BPM Enabled by SOA. Experiências a respeito são sempre uma boa fonte de inspiração e por isso compartilho neste brevíssimo blog uma coletânea de dezenas de filmes SOA compilados pela IBM.
Filmes e WebCasts SOA

Acredito que independente da sua escolha de fornecedor, estes vídeos fornecem exemplos, relatos, experiências e casos de sucesso da adoção de BPM e SOA em empresas de toda sorte.

Recomendo também, para complementar estes webcasts, o espaço SOA da IBM (SOA Space). O SOA Space é um mash-up (portal Web 2.0) com dezenas de portlets com conteúdos variados e informativos sobre SOA.

Estive semana retrasada no evento RSDC (Rational Software Development Conference) em São Paulo, que tratou de tópicos de alta relevância no desenvolvimento de software e focou no anúncio oficial da plataforma Jazz, uma nova geração de ferramentas de desenvolvimento baseadas no conceito CDE (Collaborative Development Environments). É muito bom saber que no Brasil temos eventos deste nível na área de TI. Para aqueles que não puderam acompanhar o evento, a boa notícia é que as apresentações estão disponíveis para download.
Apresentações do Evento On-line

Para os mais atarefados, recomendo em particular três apresentações:

• Abertura Executiva - Marco Bravo - Diretor de Software Group IBM Brasil
• Keynote Speaker: Investimentos em Software: Agregando valor aos negócios em tempos instáveis - David Lubanko, Consultor Rational
• Jazz: Desenvolvimento na Era da Colaboração - Roberto Argento - Gerente Rational - Brasil

Para os céticos, recomendo os estudos de casos que mostram a implementação de práticas de processo e ferramentas em empresas do calibre do Banco do Brasil e Vivo/Telefonica, entre outras.

Finalmente, é importante mencionar também a disponibilidade de vídeos e podcasts do evento RSDC dos EUA, que congregou mais de 3000 participantes. O link para assistir a estas apresentações estão aqui: IBM RSDC 2008. (caso você não tenha uma conta no site da IBM, basta criar uma conta para ter acesso à IBM TV, onde estão os vídeos).

Imagine mesclar os conceitos Web 2.0 (Wikis, Blogs, Chats/IM, Emails, Fóruns de discussão, WhiteBoards) e os conceitos de metodologias ágeis (XP/SCRUM) dentro de um ambiente de desenvolvimento poderoso como o Eclipse. Esta interessante idéia foi apresentada na ACM em 2003 como um projeto de pesquisa e criou um novo conceito, chamado de ambientes colaborativos de desenvolvimento (CDEs). Um CDE estende uma IDE incorporando conceitos de métodos ágeis como SCRUM e XP e os conceitos de colaboração contexto em tempo real.

O melhor é que isso agora em 2008 é realidade, com uma plataforma aberta de colaboração chamada Jazz (http://jazz.net). O Jazz é um ambiente aberto (assim como o Eclipse) e está sendo usado pela IBM para gerar toda a sua nova linha de produtos. O primeiro produto desta linha se chama IBM Rational Team Concert e possui uma versão gratuita para times de até 3 pessoas.

Realmente a promessa de produtividade no primeiro dia é realizada com o Jazz. Em menos dez minutos já havia instalado o Jazz e disparado o servidor (que opera sobre Middleware Tomcat/Derby na sua instalação default). Rapidamente consegui criar um projeto baseado em um processo SCRUM através de templates pré-definidos, alocar pessoas a estes times, criar tarefas, subir código para o repositório SCM Jazz, gerar um build da minha aplicação de teste através do engine de automação de builds do Jazz e operar o portal Web para examinar métricas diversas tais como Burndown, backlog de atividades, retrospectivas e defeitos em aberto, dentre inúmeras outras

Anexo a este blog uma apresentação realizada esta semana na Squadra sobre a plataforma Jazz e as suas excitantes possibilidades no desenvolvimento ágil e colaborativo entre times.

- A plataforma Jazz

Entregar sistemas de software não é uma arte. É uma complexa ciência que requer, dentre vários outros fatores, muito estudo. Para apoiar neste aspecto, compilo artigos que me muito me ajudaram nos últimos anos, escritos por “mestres” na arte de desenvolver sistema e que são uma eterna fonte de inspiração.

1. Processos ágeis - The Seven Habits of Effective Iterative Development
2. Projetos Iterativos - Planning an Iterative Project e Iterative Development
3. Bom planejamento de Projetos - Project planning best practices
4. Gerência de Riscos - Gambling with Success: Software Risk Management
5. Estimativa de Tamanho de Software - Estimating Software Development Effort based on Use Cases - Experiences from Industry
6. Modelagem de Negócios - Effective Business Modeling with UML: Describing Business Use Cases and Realizations
7. Gerência de Requisitos - So You Want to be a Requirements Analyst? e The Five Levels of Requirements Management Maturity
8. Modelagem de Casos de uso - Why Use Cases Are Not Functions, Features, Requirements, Use Cases, Oh My e The Top Ten Ways Project Teams Misuse Use Cases – and How to Correct Them.
9. Escrita Estruturada de Regras de Negócio - Business Rule Overview e Business Rules.
10. Especificação de Glossário de Termos - Glossary Overview.
11. Mapas de Navegação e Prototipação - User experience storyboards: Building better UIs with RUP, UML, and use cases.
12. Análise Robusta e Modelagem de Domínio - Robustness Diagram Overview e Driving Design: The Problem Domain.
13. Modelagem Arquitetural - Reference Architecture: The Best of Best Practices e Capturing Architectural Requirements.
14. Modelagem de Estruturas de Análise e Desenho - Driving Design: The Problem Domain
15. Modelagem Comportamental - Sequence Diagrams: One Step at a Time
16. Mapeamento Objeto Relacional - The Object-Relational Impedance Mismatch.
17. Gerência de Mudanças - Software Change Management.
18. Gerência da Qualidade - Software Quality at Top Speed e Determining Your Project’s Quality Priorities
19. Desenvolvimento Centrado em Testes Generating Test Cases From Use Cases, Test-Driven Development.
20. Refactoring e Testes de Unidade - Refactoring, a first example.

É fato notório para a comunidade de TI Brasileira o uso das soluções JBOSS para o desenvolvimento de aplicações corporativas basadas em Java. A ausência de um reconhecimento formal, entretanto, gerava questionamento por diversos decisores sobre a maturidade desta solução. Uma notícia recente, entretanto, lança o devido reconhecimento técnico e mercadológico desta solução.

O JBOSS AS figura no Gartner Magic Quadrant como um membro do quadrante líder, conforme mostrado na figura abaixo.

.

Vejo esta análise de forma similar as análises realizadas pelo grupos de investimento internacionais, como o Standard and Poors, a respeito da maturidade da economia Brasileira. A análise, por si só, nada muda na solução JBOSS AS, mas traz possibilidade de adoção da solução em contextos onde esta hipótese nao caberia por falta de respaldo de institutos de renome como o Gartner.

Apesar disso, o grupo JBOSS ainda carece de um modelo de serviço e suporte mais presente no Brasil para que possa enfrentar definitivamente os seus grandes concorrentes (BEA, IBM, Oracle e Microsoft) no disputado mercado de servidores de aplicação. Mais informações sobre esta análise podem ser encontradas no relatório do Gartner, disponível aqui.

Uma execução saudável de um projeto requer profissionais e recursos de primeira linha para a disciplina de teste. Compilo abaixo algumas informações muito interessantes para analistas e engenheiros de testes nos tópicos de gerência de testes , testes funcionais, testes de desempenho, testes de WebServices/SOA e testes de caixa branca (para desenvolvedores) e sistemas embutidos. Estes excelentes materiais fazem parte do portal do DeveloperWorks da IBM e trazem experiência provada para auxiliar times de testes a serem mais efetivos.

• Kit de Gerência de Testes
• Kit de Testes Funcionais (Manuais e Automatizados)
• Kit de Testes de Desempenho
• Kit de Testes de Arquitetura SOA e WebServices
• Kit de Testes de Caixa Branca e Sistemas Embutidos

Interessante notar que a plataforma IBM para testes é baseada em uma plataforma *aberta* para testes, que implementa muitas das funcionalidades mostradas nos kits acima, especialmente para as áreas de testes funcionais e desempenho. Esta plataforma se chama Eclipse Test and Peformance Tools Platform. Um passeio rápido por esta plataforma pode ser feito aqui.

O que deve saber um desenvolvedor Java, .NET ou de outra tecnologia para ter sucesso e crescimento no mercado? O senso comum é que nós, enquanto desenvolvedores, devamos saber apenas programar, conhecer algoritmos, estruturas de dados e APIs.

Infelizmente, o mundo real exige muitas outras coisas não ensinadas na graduação. Coloco abaixo alguns pontos que observo como exigências explícitas e implícitas no nosso dia e dia a partir dos desafios de projetos das nossas empresas e de empresas por todo o Brasil.

• Conhecimentos sólidos de escrita de código. Martin Fowler, autor de renome na nossa área, tem uma frase interessante: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”. Para termos conhecimento sólidos de desenvolvimento, devemos dominar, obviamente, estruturas de dados e algoritmos e APIs de programação. Além disso, devemos conhecer também “idioms”, testes de unidade e técnicas de refatoração. Um excelente livro, que recomendo fortemente para quem aumentar o seu conhecimento em escrita de código, é o livro Code Complete do autor Steve McConnell. Outro excelente livro nesta área é: Refactoring: Improving the Design of Existing Code, de Martin Fowler.
• Conhecimento de Padrões. Quase nenhum problema que vivemos no dia a dia é realmente inédito. A chance deste problema ter sido enfretado e resolvido por outra pessoa no mundo é alta. Existe uma chance boa também de uma boa solução para os seus problemas terem sido documentados em padrões. Temos diversos tipos de padrões, tais como padrões de arquitetura, padrões de desenho, padrões de análise, padrões de implementação (idioms) e padrões de testes. Somente os padrões de desenho essenciais do clássico livro do Gamma (Design Patterns: Element of Reusable Object Oriented Software) somam 23. Temos mais de uma centena de padrões de arquitetura apenas nos livros (obrigatórios): Patterns Oriented Software Architecture vol. 4 (Bushman et al.), Enterprise Integration Patterns (Gregor Hohpe) e Enterprise Applications Architectures (Martin Fowler).
• Conhecimentos de Processo de Software. Você domina algum processo de software? Dominar um processo é conhecer suas nuances, bases filosóficas e aplicá-lo na prática. Ouço com frequência pessoas que dizem usar “processos ágeis” mas desconhecem TDD (Test Driven Development) ou Agile Modeling. Também ouço pessoas que dizer usar o RUP mas ainda confundem elaboração com análise. Em verdade vejo que muitos desenvolvedores, por desconhecimento, usam o famoso processo “conserta e remenda” no seu dia a dia. Como desenvolvedores, devemos aumentar o nosso conhecimento de engenharia de software e de processos de software. Livros chave nesta área incluem: The Rational Unified Process: An Introduction, Philipe Kruchten e XP Explained, Kent Beck.
• Conhecimentos Laterais. Conhecer profundamente de implementação e de uma linguagem é bom. Entretanto, um bom desenvolvedor deve conhecer e aplicar técnicas laterais de outras disciplinas. Exemplos incluem: requisitos funcionais e não-funcionais, modelagem de casos de uso, modelagem de dados, UML, arquitetura de software, gerência de configuração, testes funcionais, testes não-funcionais, técnicas e métricas de qualidade de software, práticas de gerência de projeto, ferramentas de desenvolvimento, técnicas de integração de sistemas, modelagem de processos de negócio, produtos para verticais tais como ERP, CRM ou HRMS; liderança técnica e práticas de gerência.
• Pró-atividade. É importante possuir e aplicar um atitude crítica sobre as decisões do projeto. Questionar e debater as escolhas gerenciais e criar acordos ganha ganha com todo o time é a essência do desenvolvimento em time praticado e enfatizado por qualquer metodologia ágil. O papel do desenvolvedor não é apenas escrever código, mas ser uma peça central no sucesso do projeto. Com tal responsabilidade, ele não pode simplesmente reclamar de uma decisão inadequada de sua gerência e fazer as tarefas por que foi comandado para isso. Um desenvolvedor não pode se vitimizar e criar uma espiral descendente de desânimo e apatia com o o seu time. Ao invés, ele deve (junto do time) fazer o trabalho necessário e possível para o sucesso do projeto. Criar sinergia com seus pares, ambientes saudáveis e estratégias ganha ganha é fundamental para qualquer trabalho de time, especialmente o pesado trabalho de desenvolvimento de software. Como aprendi há algum tempo, o problema não são os eventos (positivos ou negativos) que ocorrem no seu projeto. A verdadeira pró-atividade vem de como reagimos e respondemos a estes eventos..
• Comunicação. A clássica idéia do desenvolvedor que vai para o escritório, senta em sua cadeira, coloca o seu fone de ouvido e fica o dia inteiro escrevendo código como um autista é filme de ficção científica. Desenvolvedores devem se comunicar o tempo todo. Eles devem conversar diariamente com os analistas, com os gerentes e com os testadores. Eles devem conversar diariamente com os seus pares e somente após isso então conversar com a máquina. A maior parte dos problemas de projetos nascem de questões de comunicação e requisitos. Compreender profundamente o ambiente e os requisitos de projeto é papel chave para todo desenvolvedor.
• Formação Acadêmica. Infelizmente os tempos mudaram. Uma graduação em computação significava muita coisa há 25 anos atrás. Hoje isso é apenas o começo. Um bom desenvolvedor deve investir continuamente na sua formação. Cursos de especialização, pós-graduação lato sensu em engenharia de software, arquitetura de software, redes e outros tópicos bem como mestrados profissionais, mestrados strict sensu e doutorados devem ser perseguidos todo o tempo. Além disso, certificações específicas de Java (SCJP, SCWCD, SCEA) e .NET (MCAD, MCSD, MCTS) devem ser alcançadas. Finalmente, assinar e ler revistas específicas, podcasts, newsletters e webzines bem como participar de eventos específicas e ser membro de comunidades como por exemplo o MGJUG e os .NET Raptors, entre várias outras, é fundamental para manter a empregabilidade.
• Humildade. A nossa carreira dura em média 35 anos. A ansiedade, entretanto, nos prega peças. Devemos tomar cuidado, portanto, antes de dizermos que somos sêniores em algum assunto ou buscar atalhos profissionais. Para nos tornarmos sênior em alguma coisa, precisamos de anos e talvez décadas de trabalho em um tópico específico. Precisamos de um vasto portfólio de projetos vividos e dezenas de milhares de horas de trabalho em nosso currículo. O nosso aprendizado é lento e somente vem com o tempo, muitos erros e com a experiência acumulada. Devemos saber ter paciência e humildade para criamos uma carreira sólida enquanto desenvolvedores.
• Foco e persistência. Ser desenvolvedor é uma carreira de longo prazo. Trocá-la por uma carreira de gerente ou analista simplesmente por uma questão monetária ou status é um erro, a não ser que a sua voz esteja em outra carreira. Felizmente, desenvolvedores agora tem a chance de serem bem remunerados por seu trabalho. Cada vez mais as empresas valorizam o desenvolvedor pelo valor agregado que ele produz ao projeto. Isso é fato e observo vários desenvolvedores que ganham mais que gerentes ou analistas. Não existe nada de errado com isso, nem existiria com o contrário. O retorno financeiro deve ser proporcional ao valor agregado trazido por cada membro do time.
• Ética. Este talvez seja o atributo mais importante. Um desenvolvedor deve ser implacável com qualquer desvio de conduta praticado por qualquer membro de um projeto. Um desvio de conduta não é apenas desviar dinheiro. Ao invés, um desvio de conduta é entregar um produto com qualidade inadequada, mascarar um produto para ganhar tempo, trabalhar com má vontade, manipular pessoas ou simplesmente dizer “mentiras brancas” sobre a situação do projeto para um colega do time ou cliente.

Em resumo, apesar de todas as dificuldades e pressões do dia a dia, a carreira de desenvolvedor é empolgante e pode ser bastante valorosa para os que nela acreditam e investem. Recomendo os livros citados aqui (a maior parte deles traduzidos para o português) como ponto de partida de desenvolvimento técnico e as inúmeras redes sociais na Web sobre Java e .NET para aprendermos continuamente com as pessoas ao nosso redor.

A Internet nos trouxe as bibliotecas digitais. Bibliotecas digitais são excelentes mecanismos para conhecer novos assuntos, nos aprofundarmos em assuntos já conhecidos ou mesmo aumentar a nossa produtividade enquanto engenheiros de software.

Melhor ainda se a biblioteca digital puder ser usada sem a violação de direitos autorais, fato que infelizmente não ocorre com outras “bibliotecas” de endereço e reputação duvidosa.

Em particular, recorro sempre à um biblioteca de excelente qualidade chamada RedBooks. O RedBooks (http://www.redbooks.ibm.com) é uma biblioteca pública de livros diversos de TI. O download dos livros em formato digital é gratuito e os livros podem eventualmente ser comprados em formato impresso.

O segredo do Redbooks é que esta é uma rede social, i.e., qualquer pessoa com conhecimento técnico suficiente pode se inscrever e participar de um projeto que irá escrever um novo livro. Vários Brasileiros participam ativamente deste processo, inclusive.

Existem vários domínios (assuntos) dentro desta bibliotecas. Destaco três em particular:

• RedBooks para Desenvolvimento de Aplicações.
• Software Rational (Ferramentas para Governança do Desenvolvimento e Entrega de Aplicações)
• Software WebSphere (Ferramentas para Operações de Aplicações e SOA)

A qualidade dos RedBooks, de forma geral, é muito boa. É possível, inclusive, votar na qualidade e criticar os livros, que eventualmente são melhorados ao longo do tempo. Dados de pesquisa da IBM junto a seus clientes mostraram dados interessantes do aumento de produtividade no uso dos RedBooks. Coloco aqui um fragmento desta pesquisa.

Para não perder o hábito de falar sobre SOA, coloco aqui as dezenas de ocorrências que encontrei sobre SOA no RedBooks Online.
- Redbooks de SOA

O que é uma arquitetura de referência?

É uma coleção de de boas práticas arquitetônicas para capturar soluções provadas em um problema de um determinado domínio. Em termos simples, ele oferece uma base de onde criamos boas arquiteturas de software em projetos de TI. Um exemplo interessante de uma arquitetura de referência específica para o domínio Java é o Java EE (Java Enterprise Edition), que define um modelo provado para a montagem de aplicações corporativas em tecnologias Java.

Quando falamos de SOA, estamos falando de gerar agilidade para os negócios. O propósito básico de SOA é prover à TI um mecanismo provado de alinhamento com áreas de negócios. Quando somamos SOA e arquiteturas de referência estamos falando, portanto, de um conjunto de mecanismos provados para projetos SOA. Interessante notar que SOA não é uma arquitetura de TI, mas uma arquitetura de negócio. Portanto, uma arquitetura de referência para SOA envolve aspectos técnicos e também aspectos de negócios. Exemplos incluem:

• Camada de Governança
• Camada de Serviços de Apresentação (ex: Portais e Mash-ups)
• Camada de Serviços de Processos de Negócio
• Camada de Serviços de Dados

Desenhar e montar uma arquitetura de referência, entretanto, não é uma tarefa fácil. São necessários anos de práticas e vários projetos para capturar as boas práticas e afastar as más práticas. Felizmente, podemos contar com duas empresas sólidas, com dezenas de anos de experiência no desenvolvimento, entrega e suporte de aplicações corporativas. Destaco aqui a BEA e a IBM. Exemplos de seus produtos incluem os OLTPs de excelente reputação como o BEA’s TUXEDO (desde 1983) e o IBM CICS (desde 1969). Interessante notar, as duas soluções mais maduras de SOA do mercado são da BEA e IBM. Delas vêm também boas arquiteturas de referência, que podem ser usadas até por empresas e pessoas que não usem produtos destas empresas. Destaco, em particular, dois excelentes white papers da BEA e da IBM, respectivamente.

• BEA’s SOA Reference Architecture SOA - Excelente artigo com a montagem de uma arquitetura de referência para SOA.
• Design an SOA solution using a reference architecture - Também um excelente artigo com uma arquitetura de referência em nove camadas.

Embora com visões diferentes, os dois artigos podem e devem ser usados por qualquer técnico interessado em SOA e BPM. Como disse Isaac Newton certa vez sobre o seu trabalho da figura do começo deste artigo: “Eu pude ver mais longe porque estava apoiado nos ombros de gigantes”.