O ano de 2008 terminou. Um feliz 2009 a todos!

Que o novo ano nos traga um cenário mais positivo de TI onde os gestores tenham mais consciência do nosso dever ético de produzir software com excelente qualidade externa e interna para os nossos usuários e que os profissionais de TI tenham condições dignas de trabalho, responsabilidade e tempo de praticar boas práticas de engenharia de software.

Compilo abaixo uma referência facilitada de artigos publicados no nosso blog em 2008 para os praticantes de engenharia de software, Java, BPM e SOA.

Artigos de 2008

• Métodos Ágeis:O seu time é agil ou apenas “conserta e remenda” código?
• BPM: BPM Não é Engenharia de Software. BPM é sobre Pessoas e Processos de Negócio!
• BPM: Padrões, Tecnologias e Ferramentas Java para Suporte BPMS - Evento Java Developer Day ASSESPRO-MG
• BPM: Recursos para suporte a projetos BPM
• Métodos Ágeis: Práticas de Processo. Um Processo é uma coleção de práticas ágeis!
• Pessoas: Da Eficácia à Grandeza da TI
• Java EE: Mais Suporte a JPA dos Fornecedores de Mercado Java - IBM Rational Application Developer 7.5 e WebSphere Application Server 7.0
• Padrões: Sobre os Ombros de Gigantes - Padrões de Desenho, Análise, Testes, Arquitetura e muito mais
• Arquitetura: DeArchitectura - Uma Visão Sócio-Técnica sobre Arquitetura de Software
• Pessoas: O profissional “Um ano júnior, dois anos pleno e trinta e dois anos sênior”!?
• Gerência de Projetos: A Relação Tensa entre Gerentes e Arquitetos de Software
• Pessoas: Os 13 Comportamentos de Liderança de um Arquiteto de Software em Projetos
• Arquitetura: Cercado pelo mega-oceano Pantalassa, nasce o Pangea!
• BPM: BAM *Business Activity Monitoring* Para Leigos
• Arquitetura: 5 Razões para Modelar Arquiteturas de Sistemas com o Método “4+1″
• Requisitos: Eu tenho os requisitos e a solução, mas qual o problema mesmo?
• Gerência de Projetos: Fazer Software é Como Construir uma Ponte ou Dirigir um Filme?
• Java: (Java e .NET) Birds of a Feather Flock Together
• Métodos Ágeis: Scrum It Now - na Prática
• Java EE: Apresentações do JBOSS RoadShow 2008 Disponíveis
• Java EE: A Melhor Certificação de Arquitetura Java do Mercado é da… Microsoft
• BPM: Aprenda BPM Jogando
• Arquitetura: Uma refeição de arquitetura de software: Livros para Criar, Avaliar e Documentar Arquiteturas de Software
• Fábricas de Software: Fábricas de Software - Padrões e Práticas
• Métodos Ágeis: Mais Jazz - Ferramentas Colaborativas para Requisitos, Gerência, Estimativas e Qualidade de Software
• OO: Modelagem de Domínio - Ferramenta Essencial para a Modelagem de Sistemas Computacionais
• SOA: Troque a “Zorra Total” por um bom Filme (SOA)
• Engenharia de Software: Apresentações da Conferência Anual de Desenvolvimento de Software da IBM Rational Disponíveis para Download
• Métodos Ágeis: It’s Jazz Time!
• Engenharia de Software: 20 práticas para aumentar a maturidade de desenvolvimento de software do seu time
• Java EE: O avanço do JBOSS AS no mercado de Servidores de Aplicação
• Testes: Ferramentas e Recursos para Engenheiros e Analistas de Testes
• Pessoas: Carreiras de Desenvolvimento em Java e .NET
• SOA: Uma (Excelente) Biblioteca de Engenharia de Software e SOA à Sua Disposição
• BPM: Suítes BPMS - Magic Quadrant Gartner 2007
• SOA: Evolução das Plataformas SOA Open-Source - Como criar uma aplicação SOA em Dez Minutos!

A palavra “ágil” ganhou muita popularidade em TI nos últimos anos, mas infelizmente ela tem sido deturpada para mascarar más práticas e o infame “anti-processo” conserta e remenda. Agilidade, contrariamente ao senso comum, requer muita disciplina de pessoas e times.

Por exemplo, consideremos um desenvolvedor. Um desenvolvedor ágil precisa realizar uma série de rituais diários para se manter ágil, como por exemplo:

• Refatorar o seu código continuamente. Sistemas que não são refatorados crescem de forma desordenada e permitem que o caos se instale.
• Criar e manter testes de unidade no seu código, preferencialmente com ferramentas da família xUNIT (jUNIT, nUNIT).
• Gerar builds diários do seu código para aumentar o ciclo de feedbacks dos times de testes e usuários finais.
• Colaborar continuamente com os seus pares (stand-up meetings, sessões de pair programming).

Agilidade, portanto, implica em disciplina e trabalho duro. Felizmente, estamos observando o advento de ferramentas e ambientes de desenvolvimento que trazem cada ves mais os conceitos das escolas ágeis para o dia a dia de gerentes, analistas, desenvolvedores e testadores. Citei recentemente o Jazz e o IBM Rational Team Concert da IBM. Ele pode ser estudado e baixado a partir do lúdico e interativo site A Viagem do Sr. Ping, que infelizmente perdeu contato com o seu time.

Aprendendo a ser ágil!

Mas como podemos aprender a ser ágil? A tarefa realmente não é simples. Mas podemos praticar as idéias e conceitos em projetos e ganhar experiência.

Para quem quiser aprender e aperfeiçoar conceitos, recomendo o “Kit de Agilidade” compilado no portal DeveloperWorks da IBM. São diversos papers, vídeos e outras informações sobre práticas ágeis. Recomendo, em particular, o rápido webcast do mestre Scott Ambler sobre o uso de práticas ágeis. Outras informações estão disponíveis também no site http://ibm.com/rational/agile.

Para os “designers” e arquitetos de software, recomendo também uma série de artigos que escrevemos no site “DeArchitectura” sobre como práticas ágeis para a arquitetura de software. Resumo os links abaixo:

• Arquiteturas Ágeis com o AUP.
• As Atividades de Arquitetura com o OpenUP.
• OpenUP - Agilidade, Controle de Riscos e Disciplina Arquitetural
• Extraindo o sumo da arquitetura com o EssUP.

Pensamento do dia: “Quem faz errado faz duas vezes” - Pensamento popular.

Recebi um artigo instigante, escrito pelo vice presidente da Fujitsu (Keith Swenson), sobre BPM e a sua relação com engenharia de software - BPM is not Software Engineering. A hipótese do autor, que concordo, é que BPM é uma ciência diferente de engenharia de software e requer uma abordagem diferente para a sua implementação.

Em suas palavras:

“Business Process Management” is, as the name implies, about management of business processes. A business process is not managed by a software engineer. A “business process” is not a program. It may be supported by a program, but the business process is the thing that the organization wants done.

O autor discute erros cometidos por engenheiros de software em implementações BPM tais como o uso excessivo de abstrações e modelos, que não são compreendidos por pessoas das áreas de negócio, e uma crença excessiva na automação ou uso de programas para resolver os problemas de negócio. O artigo me lembra das leis da automação escritas por Bill Gates há algum tempo:

A primeira lei da automação diz que a automação de um processo eficiente irá aumentar a sua eficiência, Bill Gates

A segunda lei da automação diz que a automação de um processo ineficiente irá apenas aumentar a sua ineficiência, Bill Gates

Um outro fato nesta direção que também me chama a atenção também é dos especialistas e renomados consultores BPM Jeston & Nellis, que acabaram de lançar a segunda versão de um dos melhores livros sobre implementação BPM - Business Process Management: Practical Guidelines to Successful Implementations (Paperback). Eles citam neste livro que cerca de 30% de uma implementação BPM é gasta com People Change Management“.

People Change Management é sobre pessoas, é sobre a compreensão genuína dos seus métodos de trabalho, é sobre a detecção dos problemas que tornam os seus processos ineficientes, é sobre o estabelecimento de confiança entre times, é sobre mudança cultural e a proposição de novas formas de trabalho e finalmente, sobre o acompanhamento e suporte em novas formas de trabalho, mais eficazes e mais eficientes.

Citando uma frase de Keith Swenson novamente:

BPMN does not exist for the convenience of Software Engineers, because BPM is not Software Engineering.

.