Os doze passos para desenvolver software altamente eficaz

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

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

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:

Disciplina de Construção de Componentes de Software no SENAC-SP

Lecionarei a disciplina de Construção de Componentes de Software I e II (20 aulas ao todo) na pós-graduação do SENAC-SP. Estou utilizando uma bibliografia novíssima e trabalhando no coração de como desenvolver sistemas realmente orientados a objetos. Além disso achei importante fornecer técnicas para manter código legado (veja a definição de código legado em meu artigo sobre qualidade interna do software), já que na maior parte do tempo estamos mantendo código existente e não construindo novos sistemas.

A seguir, os tópicos que serão vistos e também a bibliografia. Creio que o pessoal vai gostar bastante, já que percebo poucos ministrando disciplinas que abordam esses temas em profundidade. A idéia é elevar o patamar dos desenvolvedores e ajudá-los a compreender de uma forma didática os conceitos fundamentais e avançados da orientação a objetos. Também falar sobre princípios e práticas para se tornar um desenvolvedor mais eficiente e eficaz, um ás do código de qualidade :-) !

- Fundamentos do design emergente e a natureza do desenvolvimento de software
(Os exemplos de códigos da disciplina estão em Java e C# e eventualmente em C++, C e Visual Basic)

- Qualidades de um bom código OO através de exemplos
• Encapsulamento
• Coesão
• Acoplamento
• Redundância
• Testabilidade
• Legibilidade

- Patologias

- Princípios OO através de exemplos
• Separando uso da criação
• Single-Responsibility Principle
• Liskov-Substitution Principle
• Interface Segregation Principle
• Open-Closed Principle
• Dependency Inversion Principle
• Encapsulamento dos conceitos variáveis
• Dicas da GoF

- Práticas
• Estilo de codificação consistente
• Programação por intenção
• Encapsulamento de construtor
• Análise de Variabilidade

- Tranformando código procedural em código OO através de patterns (Parte 1)

- Tranformando código procedural em código OO através de patterns (Parte 2)

- Dicas para criar rotinas de alta qualidade

- Programação defensiva

- Processo de programação baseada em pseudocódigo

- Técnicas para uso de variáveis

- O poder dos nomes de variáveis

- Uso dos tipos de dados fundamentais

- Organizando código

- Idéias gerais para controle em código

- Usando condições

- Controlando Loops

- Métodos Table-Driven

- Layout e Estilo

- Código auto-documentado

- Técnicas para code tuning

- Medindo a qualidade interna do código

- Estratégias de Integração

- Técnicas de build e release

- Reuso Estratégico de Software e Asset-Based Development

- Testes unitários automatizados e Test-Driven Development

- Refactoring (Parte 1)

- Refactoring (Parte 2)

- Refactoring para Patterns

- Trabalhando com código legado (Parte 1)

- Trabalhando com código legado (Parte 2)

- Domain Driven Design

- Inversão de Controle e Injeção de Dependências – Exemplificado com Google Guice e Unity .NET DI

- MVC e MVC 2 para Web – Exemplificado com Struts 2

- Mapeamento objeto-relacional – Exemplificado com Hibernate e LINQ

- Persistência com o Pattern Transaction Script – Exemplificado com iBatis

- Bancos de dados orientados a objetos – Exemplificado com o db4o

- Trabalhando de forma iterativa com o banco de dados – Refatorando o banco de dados


Bibliografia Básica

1. Steve McConnell, Code Complete, 2nd Edition, Microsoft Press, 2004.
2. Martin Fowler, Refactoring, Addison-Wesley, 1999. (Complemento: http://www.refactoring.com)
3. Scott Bain, Emergent Design, Addison-Wesley, 2008.

Bibliografia Adicional

1. Robert Martin, Agile Principles, Patterns and Practices in C#, Prentice Hall, 2006.
2. David Astels,Test-Driven Development: A Practical Guide, Prentice Hall, 2003.
3. Lasse Koskela, Test Driven, Manning, 2008.
4. Alan Shalloway, Design Patterns Explained, 2nd Edition, 2004.
5. Floyd Marinescu, Domain Driven Design Quickly, 2006.
6. Gary Pollice, Head First OOAD, O’Reilly, 2006.
7. Eric Freeman, Head Fist Design Patterns, O’Reilly, 2004.
8. Craig Walls, Spring in Action, 2nd Edition, Manning, 2007.
9. Robbie Vanbrabant, Google Guice, Apress, 2008.
10. Gavin King, Java Persistence with Hibernate, Manning, 2007.
11. Clinton Begin, iBatis in Action, Manning, 2007.
12. Erik Hatcher, Ant in Action, 2nd Edition, Manning, 2007.
13. Paul Duvall, Continuous Integration, Addison-Wesley, 2007.
14. Chris Richardson, POJOs in Action, Manning, 2005.
15. Kent Beck, Implementation Patterns, Addison-Wesley, 2007.
16. Michael Feathers, Working Effectively with Legacy Code, Prentice-Hall, 2004.
17. Ian Roughley, Practical Apache Struts 2 Projects, Apress, 2007.
18. Jimmy Nilsson, Applying DDD and Patterns with Examples in C#, Addison-Wesley, 2006.
19. Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.
20. Scott Ambler, Refactoring Databases, Addison-Wesley, 2006.
21. Joshua Kerievski, Refactoring to Patterns, Addison-Wesley, 2004.
22. Joe DeCarlo et al., Strategic Reuse with Asset-Based Development, IBM Redbooks, 2008.

Metodologias Ágeis - Seminário na PUC-SP

Vou iniciar uma nova disciplina, no formato de seminário, na pós-graduação em Engenharia de Software da PUC-SP. Ela terá como objetivo detalhar os principais processos de desenvolvimento de software ágeis, bem como ensinar como planejar projetos ágeis e iterativos. Depois colocarei algumas das apresentações no meu site pessoal Erudio.

Os tópicos abordados em cada uma das dez aulas são:

Aula 1 - Waterfall and Iterative Game (dinâmica)
Aula 1 - Introdução, o manifesto ágil, processos iterativos versus cascata, motivação para adoção
Aula 2 - Scrum e XP
Aula 3 - OpenUP e RUP
Aula 4 - RUP Game (dinâmica)
Aula 5 - Planejamento de projetos ágeis e iterativos – parte 1
Aula 6 - Planejamento de projetos ágeis e iterativos – parte 2
Aula 7 - Estratégias de automação para projetos iterativos e ágeis (ferramentas e abordagens)
Aula 8 - Test-Driven Development e Programação por Intenção – parte 1 (Laboratório)
Aula 9 - Test-Driven Development e Programação por Intenção – parte 2 (Laboratório)
Aula 10 - XP Game (dinâmica)

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

Na vasta maioria de projetos de software requisitados para fornecedores internos (o próprio departamente de TI) ou externos (consultorias e fábricas de software), podemos notar que os principais itens de performance medidos são o prazo de entrega e o custo. Conforme nos mostra Robert Austin magistralmente, no seu livro “Measuring and Managing Performance in Organizations”, medir um sistema complexo através de poucas métricas o torna disfuncional e gera efeitos contrários aos pretendidos.

Quando se mede a performance de um projeto de software apenas por seu custo e prazo nota-se um comportamento disfuncional clássico: como o gerente de projeto e os membros da equipe só serão medidos pela velocidade de entrega, então tudo é feito às pressas e usualmente sem a atenção devida a um bom design, a testes unitários e funcionais e a refatorações constantes. Sem esses cuidados, o sistema costuma entrar com um número de defeitos acima do desejado e ainda se torna um código legado desde sua entrada em produção. Essa medição de performance também faz com que os níveis gerenciais demandem mais de 40 horas semanais dos profissionais (muitas vezes sem o devido pagamento de horas extras), o que ainda gera uma degradação de moral da equipe e um turn-over mais alto na empresa.

Como então podemos obter um bom código, que não vire legado assim que é entregue para a equipe que irá mantê-lo? Primeiro vamos definir o que é um código legado, o que é um código bom e o que significa o requisito não-funcional de manutenibilidade.

Quando se fala a palavra código legado, na cabeça dos desenvolvedores surge uma visão de código impossível de entender, estruturalmente complexo, cheio de condições encadeadas, código macarrônico e métodos com centenas e até milhares de linhas de código! Segundo Michael Feathers (em seu livro “Working Effectively with Legacy Code”) código legado é aquele difícil de entender e, consequentemente, difícil de alterar para implementar novas funcionalidades ou corrigir defeitos. Mas, segundo ele, a definição mais importante é: código legado é código sem testes unitários automatizados. Essa definição radical e inusitada nos mostra a importância de uma suíte de testes unitários para manter a sanidade do código e nossa coragem de fazer modificações quando necessárias. Sem testes os desenvolvedores adotam a postura de não mexer em código que “não é deles”, por medo de gerar defeitos. Também não fazem modificações estruturais para manter o código coeso e com baixo acoplamento, especialmente quando incluem novas funcionalidade. Portanto, sem testes unitários é difícil dar manutenção evolutiva e corretiva no código e mantê-lo bom, evitando que se torne legado e complexo.

Nossa próxima definição é sobre código bom. Essa é uma definição mais complexa. Gosto muito do termo inventado por Kent Beck: “code smell”. O “mau cheiro” em código é um sintoma de que algo está errado. É uma indicação de que o código precisa ser refatorado ou o design deve ser reexaminado. Alguns “maus cheiros” clássicos são (acesse a taxonomia de maus cheiros, caso queira mais detalhes):

• Métodos longos - esse tamanho pode variar, mas algumas pessoas consideram que um método com mais de 50 linhas de código já é um método longo (alguns mais puristas chegam a dizer que um método deve ter no máximo 10 linhas!). Veremos adiante no artigo que a complexidade ciclomática pode nos ajudar a obter um indicador mais preciso.

• Classes grandes e complexas - normalmente as que não seguiram o princípio de alta coesão
• Classes com intimidade com muitas outras classes - as que não seguiram o princípio de baixo acoplamento
• Classes preguiçosas – que não fazem muita coisa ou são executadas com pouca freqüência
• Código duplicado – essa é uma das maiores pragas que devem ser combatidas... rs.

E o requisito não-funcional da manutenibilidade? Bom, esse é, como qualquer requisito não-funcional, fundamental para uma definição da arquitetura de um software. É a facilidade de manutenção para inclusão de novas funcionalidades, correção de defeitos e alterações de regras de negócio. Esse requisito é fundamental para qualquer sistema que venha a ter uma vida útil longa em produção e que sofrerá contínuas modificações. Clientes e outros stakeholders não costumam falar claramente “esse sistema deve durar 10 anos em nossa empresa, é crítico e terá um número grande de requisitos novos mensalmente”. Por isso a manutenibilidade deve ser questionada claramente para os stakeholders. Alguns dizem que não se deve preocupar com manutenibilidade se o código durar pouco tempo. Tome cuidado, porque a tendência de todo código criado é a de continuar sendo usado por tempos razoáveis. Portanto, desconfie se disserem que o sistema ficará pouco tempo em produção. Nem sempre o cliente sabe tudo (vide o livro “O Dilema da Inovação” de Clayton Christensen para detalhes desse fenômeno no mundo dos negócios) !

Agora o problema: tendo em vista que sabemos a importância de se obter um código bom, não legado e com alta manutenibilidade, como medir isso em um fornecedor (interno e/ou externo) e como garantir que essa qualidade existe? Aí vão algumas dicas.

A primeira parte é a mais fácil: medições de código. Hoje temos várias ferramentas (neste artigo estou focando em ferramentas para Java, mas saibam que também existem similares para .NET e outras plataformas) que ajudam em 80% do esforço de detectar problemas. Vamos a algumas delas para exemplificar:

• Usar JUnit para fazer os testes unitários automatizados e, desse modo, não deixar o código virar legado conforme definição do Feathers. Como um cliente pode medir se os testes unitários estão sendo feitos e se são relevantes? Uma forma muito boa é medir a cobertura de código (de linhas e de desvios) realizada pelos testes unitários. Para isso é possível usar uma ferramenta open source como o Cobertura ou uma ferramenta como a embutida no Rational Application Developer.
• Usar uma ferramenta como o JavaNCSS para contar a quantidade de linhas de código e a complexidade ciclomática por método. Com essas métricas pode-se analisar se o código de cada método está complexo demais e se deve ser quebrado para manter a coesão. É possível usar uma ferramenta como o crap4J para tirar métricas combinadas entre cobertura de código e complexidade ciclomática.
• Usar uma ferramenta de análise estática de código como o PMD ou a embutida no Rational Application Developer para avaliar regras básicas de código. Essa é uma ferramenta essencial e que deve ser utilizada antes de qualquer inspeção formal feita por desenvolvedores. Ela irá pegar erros básicos que forem configurados. Ela detecta falhas como:
• Métodos longos
• Nomes de variáveis e métodos curtos
• Nomes de variáveis que não começam com letra minúscula
• Identação de chaves
• Quantidade excessiva de parâmetros
• Acoplamento entre objetos
• Aninhamentos grandes de ifs e elses
• Densidade de switch
• Código não utilizado (variáveis, parâmetros, métodos, etc)
• Usar a ferramenta CPD (Copy/Paste Detector) para identificar código duplicado e passível de refatoração.
• Usar uma ferramenta de análise de dependências de código orientado a objeto como o JDepend ou o Rational Software Architect (com sua capacidade de descoberta arquitetural e detecção de antipatterns arquiteturais).

Todas as ferramentas acima podem ser executadas através de um simples comando do Ant, após feita a configuração correta. Isso pode ser ainda colocado para executar dentro de um servidor de integração contínua, que pode enviar relatórios diários por email do status das métricas de código.

Além de medir o código usando ferramentas, sempre faça auditorias em cada uma das versões entregues (lembre que ferramentas garantem 80% dos casos, normalmente os mais típicos). As ferramentas não excluem o uso de bons desenvolvedores inspecionando formalmente código. Segundo McConnell, no livro “Code Complete”, de 45 a 70% dos defeitos de um código são removidos quando este passa por uma inspeção formal de desenvolvedores experientes.

Agora vamos à parte que dará mais trabalho (em termos de negociação e possíveis conflitos): como garantir essa qualidade de seu fornecedor? A resposta: estabeleça um SLA (Acordo de nível de serviço) para cada parâmetro importante discutido na primeira parte (métricas). Pode-se definir, por exemplo:

• Uma complexidade ciclomática de até 15 como aceitável, de 16 a 30 como aceitável se o fornecedor justificar de forma admissível ou inaceitável quando maior que 30.
• Uma cobertura de linhas de código de 80% como aceitável. Abaixo disso é inaceitável e acima disso é bônus.
• Regras definidas pelo cliente nas ferramentas de análise estática de código devem ser todas seguidas. Não deve aparecer nenhum erro.

Com base nisso pode-se elaborar penalidades no caso do fornecedor não estar dentro do SLA e bônus por ultrapassar os limites aceitáveis do SLA.

È possível também elaborar SLAs para que o fornecedor realize testes funcionais automatizados e testes de performance automatizados. Testes automatizados são mais garantidos porque podem ser executados para confirmar se foram feitos (diferentemente de casos de testes manuais) e ainda se tornarão um ativo de sua empresa, pois serão usados como testes regressivos. Um mínimo de testes funcionais automatizados (nem que sejam apenas os chamados "smoke tests") deve ser requerido.

Com essas técnicas você pode sair da situação da figura abaixo:

Para entrar numa situação bem melhor como essa:

E uma dica: se o seu fornecedor questionar e dizer que terá que aumentar o custo por causa disso, pergunte a ele: como você fazia então para garantir a qualidade e manutenibilidade de seu código sem essas métricas? Ou não fazia? Provavelmente o fornecedor que faz essa colocação não terá uma boa resposta verdadeira.

Outra dica: se o seu fornecedor se diz “agile”, não aceite apenas que haja entregas durante iterações curtas. Isso é apenas um lado (também importante). Exija a qualidade acima para realmente provar a agilidade do fornecedor. Processos ágeis primam muito pela qualidade interna e externa do código. Esse aviso é importante pois já pode-se notar no mercado o que costumam chamar de empresas “pseudo-agile”. São aquelas que dizem que praticam Scrum e XP, mas na verdade praticam mesmo a codificação caótica e indisciplinada, tudo que processos ágeis não são.

Por que estou dando essas informações valiosas? Porque acredito que, se os clientes foram mais exigentes com seus fornecedores de software, então todo o país terá a ganhar. Formaremos profissionais de maior qualidade, que geram um produto (código) de maior qualidade e aí poderemos competir no mercado externo com outros profissionais não apenas nos termos de custo e sim da qualidade do trabalho. Mudaremos de uma estratégia de oceano vermelho de custo para uma estratégia de oceano azul da diferenciação.

Portanto relembrando para o cliente: elabore contratos que demandem entregas curtas (desenvolvimento iterativo) com qualidade interna e externa medida por ferramentas, pessoas e SLAs. Vamos melhorar juntos o nível de qualidade dos nossos produtos!

Dando uma dica para fornecedores: Sejam pró-ativos e ofereçam esse tipo de contrato para seus clientes. Mudem suas estratégias de desenvolvimento e ofereçam qualidade com agilidade. Gerem benefícios de valor agregado, antes que seus concorrentes o façam!

Aguardo comentários de vocês sobre esse artigo. É sempre bom dialogar com os leitores do meu blog!

Em um próximo artigo vou tratar da situação onde você tem um sistema legado, com código "mal-cheiroso", e quer melhorar sua qualidade interna para continuar incluindo novas funcionalidades. Vamos mostrar técnicas para melhorar a manutenibilidade de sistemas já existentes (um problema que muita gente tem hoje na nossa área!).

ProjectKoach 2008: Gestão de Projetos OpenUP com ferramenta integrada ao Eclipse

Lancei um post há algum tempo falando sobre uma interessante ferramenta para apoiar a gestão de projetos com o OpenUP. A ferramenta se chama ProjectKoach.

Pois uma excelente notícia: a versão 2008 do ProjectKoach agora vêm em dois modelos: standalone e integrada ao Eclipse!

Com a integração há mais facilidades para trabalho colaborativo em equipe. Outra funcionalidade excelente da ferramenta é a integração com o Eclipse Process Framework (EPF). O ProjectKoach consegue importar bibliotecas de métodos instaladas em seu ambiente e gerar sua WBs a partir de sua configuração customizada!

E o melhor de tudo: a ferramenta é gratuita. Faça um test drive indo ao site do ProjectKoach.

Revisoes e Inspecoes de Software e/ou Pair Programming no CMMI

Uma interessante questão surgiu no grupo CMMI Brasil:

O que caracteriza uma revisão por pares ? Se um time desenvolve seus componentes em conjunto (pair programming), podemos dizer que o componente já está revisado na sua origem ?

Minha resposta:

De acordo com uma das referências clássicas sobre revisões em pares (Livro "Peer Reviews in software" de Karl Wiegers), podemos considerar sim o pair programming como um prática de peer review, porém informal (pois não envolve preparação e registro de informações e métricas).

Ela poderia ser considerada uma prática alternativa que ajuda a atingir os "Specific Goals" da PA de Verificação. Porém, acredito que seria necessário uma boa demonstração (inclusive mostrando referências) de que o pair programming pode substituir revisões formais ou inspeções.

Outra estratégia que você pode usar é a de trabalhar com o pair programming E fazer revisões e/ou inspeções em artefatos considerados mais críticos.

Eu, particularmente, considero que revisões e inspeções possuem um retorno sobre investimento gigantesco e já mais que comprovado na indústria (quem quiser pode ver esses dados em meus materiais de ensino da disciplina de revisões e inspeções que ministro na pós de Engenharia de Software da USJT).

Inclusive, revisões e inspeções dão mais retorno que testes! Realizar revisões em artefatos de requisitos e em código de componentes mais complexos (com apoio de ferramentas de análise estática de código) é crucial para melhorar a qualidade e aumentar a produtividade (devido à redução do retrabalho) da equipe.

De acordo com os autores clássicos em revisões e inspeções, quem deve fazer a inspeção de artefatos são membros da equipe que possuem a mesma função do autor do artefato analisado e também, se possível, pessoas que utilizarão o artefato. Até porque, em alguns casos, seria complicado pedir para um analista de requisitos ou um gerente de projetos para revisar código-fonte. A formação deles não é técnica (muitas vezes) e levaria à detecção de um número bem reduzido de defeitos.

Pode não parecer, mas revisões e inspeções são mais dinâmicas do que muita gente imagina. Além disso geram possibilidades imensas de melhoria contínua das equipes.

Minha dissertação publicada: Uma linguagem de padrões para automação de projetos de desenvolvimento ágil de software com ênfase na plataforma J2EE

Caros,


Acabei de disponibilizar minha dissertação de mestrado, defendida em dezembro de 2007, sob orientação do professor doutor Mauro de Mesquita Spínola. O título é "Uma linguagem de padrões para automação de projetos de desenvolvimento ágil de software com ênfase na plataforma J2EE".

Resumo:

Um dos resultados do Extreme Chaos Report, também analisado por Boehm no
seu modelo de estimativas COCOMOII, mostra que ferramentas de engenharia
de software geram um impacto significativo na probabilidade de sucesso de um
projeto de software e servem como apoio ao aumento de qualidade e produtividade da equipe, quando utilizadas para suportar o processo de desenvolvimento. Ferramentas de engenharia de software são aquelas que suportam o processo e automatizam tarefas feitas pela equipe que desenvolve software. Pode-se considerar também que as empresas que têm se destacado no negócio de software são as que possuem um processo de criação e inovação de produtos ágil e eficaz. Novas técnicas e processos pautados no desenvolvimento ágil surgiram com o objetivo de solucionar os problemas da complexidade do desenvolvimento de novos softwares e para fornecer agilidade no lançamento de novos softwares e produtos. Mesmo assim, percebe-se que poucas empresas desenvolvedoras possuem um ambiente automatizado organizado e que apóie a agilidade. Este trabalho exploratório busca entender como podemos automatizar um ambiente de projeto ágil de desenvolvimento de software. Seu objetivo é propor um conjunto de soluções específicas para a automação de ambientes colaborativos, com ênfase no desenvolvimento ágil de software e foco na plataforma J2EE. A pesquisa bibliográfica é complementada por um Web survey e por um estudo de caso incorporado de casos múltiplos, com o objetivo de avaliar o estado atual da automação em empresas brasileiras e analisar quais atributos de um ambiente de desenvolvimento podem ser considerados importantes. O trabalho utiliza o formato dos padrões (patterns) e da linguagem de padrões (pattern language), já estabelecidos como úteis para documentar soluções dentro da comunidade de desenvolvimento de software,
para fornecer o conjunto organizado de práticas de automação para engenharia de software. A linguagem de padrões resultante traz também recomendações de ferramentas específicas para apoiar a automação de projetos de desenvolvimento de software com base na plataforma J2EE.

PALAVRAS-CHAVE: Padrões, desenvolvimento ágil de software, ambientes
colaborativos de desenvolvimento de software, ferramentas de apoio ao
desenvolvimento de software, automação de fábricas e projetos de software, Java 2 Platform Enterprise Edition, J2EE.

Faça o download para leitura da dissertação de mestrado de José Papo.

CMMI Brasil - Novo Grupo de Discussão!

Devido à decisão de fechar o grupo CMM-Brasil, feita pelo fundador, criei um novo grupo de nome CMMI-Brasil para continuar as discussões e os debates que ocorriam na antiga lista.

Ele possui o mesmo escopo do anterior, que é ser um grupo criado para troca de experiências entre profissionais que trabalham com modelos de maturidade e processos de desenvolvimento de software. O tema de interesse do grupo é ligado a modelos, padrões e processos que possuam aceitação internacional, como CMMI, MPS.BR, ITIL, SPICE, RUP, Metodologias Ágeis, SWEBOK, PRINCE2 e Guia PMBOK do PMI, séries ISO, etc. A participação é aberta a todos interessados ou envolvidos profissionalmente com exportação e modelos de melhoria de processos de software, bem como gerenciamento de projetos.

Aproveite e junte-se a nós para gerar e compartilhar conhecimentos sobre essa área tão vasta. Acesse a página do CMMI-Brasil e faça seu cadastro!

Google Web Toolkit Applications - Livro sobre aplicações Ajax e RIA usando GWT

Google Web Toolkit (GWT) é um framework Java que facilita a construção de aplicações AJAX no modelo RIA (Rich Internet Applications). Codificar em JavaScript para múltiplos browsers, com o intuito de conseguir efeitos AJAX, é extremamente complexo e pouco produtivo. O GWT elimina muitos desses problemas de uma maneira extremamente poderosa: ele permite que o programador Java escreva código utilizando uma API similar ao Swing (API de criação de interfaces gráficas desktop) e depois use um compilador especial para converter essas classes Java em HTML e JavaScript adaptado aos principais browsers de mercado.

Diferentemente de outras opções RIA como o Silverlight da Microsoft e o Flex da Adobe, o produto gerado pelo GWT não precisa de plugins ou componentes especiais para executar nos browsers.

O livro em questão, Google Web Toolkit Applications de Ryan Dewsbury, assume conhecimento de Java. Conhecimento básico das APIs Swing, AWT ou SWT (para criação de interfaces gráficas desktop) com certeza agiliza a absorção do conteúdo do livro e da API do GWT.

O livro aborda os seguintes assuntos:

Parte I: Entendendo GWT

1. Primeiros passos com o Google Web Toolkit.
2. Visão Geral da Biblioteca de Interface do Usuário
3. Técnicas de Integração com Servidor
4. Engenharia de Software para Ajax.
5. Usando o kit efetivamente.

Parte II: Aplicações RIA exemplificadas - Essa parte apresenta aplicações reais desenvolvidas pelo autor e que demonstram diversas abordagens diferentes para a programação GWT.

6. Gadget Desktop Application.
7. Multi-search application.
8. Blog Editor Application.
9. Instant Messenger Application.
10.Database Editor Application - A que eu achei mais interessante. Cria um gerenciador de banco de dados pela Web. A aplicação inclui idéias de como ler e gerenciar estruturas de dados complexas acessando o servidor usando Data Access Objects, geração de código XML e JSON e integração com PHP, Ruby on Rails e Java com Hibernate.

Recomendo fortemente o livro para quem tiver necessidade de usar essa tecnologia na prática. Também acho interessante para todos aqueles que desejam explorar o mundo das Rich Internet Applications!

Planejamento ágil - reuniões para definição de releases e iterações

Na lista de discussões scrum-brasil surgiram algumas dúvidas relativas a aspectos do processo de planejamento de releases (versões) e sprints (ou iterações).

Dúvidas:

1 - Na reunião de planejamento de um release, se o time não se sentir confortável com suas estimativas em pontos, o time pode já quebrar as estórias em tarefas - e estimar essas tarefas em horas ?

2 - Na reunião de planejamento de sprints ou iterações, é necessário que todas as tarefas sejam atribuídas a algum membro já na ? Ou podemos apenas atribuir um conjunto inicial pequeno de tarefas e depois a medida que as tarefas forem sendo encerradas, o membro escolhe qualquer tarefa que ainda não tenha "dono"?

Minhas respostas (lembrando que essas dicas valem para os principais processos ágeis como Scrum, Extreme Programming, Crystal Clear e OpenUP):

1 - A estimativa em pontos é feita no Release Planning. Se no Release Planning eles não se sentem confortáveis para estimar uma estória ou item isso pode significar que: 1 - a estória é muito grande; 2 - Há muitas dúvidas e pontos nebulosos.

2 - As tarefas (tasks) não precisam ser TODAS distribuídas nessa reunião. Elas precisam ser estimadas, mas não alocadas a desenvolvedores específicos. Usualmente os desenvolvedores selecionam uma ou, no máximo, duas tarefas para iniciar a iteração. Essa alocação de tarefas continua ocorrendo, usualmente nos daily stand-up meetings (reuniões diárias em pé). Lembrando que são os desenvolvedores que se alocam nas tarefas. Eles não são alocados por alguém de nível gerencial.

As tarefas não devem ser distribuídas pela equipe durante a reunião de planejamento do sprint por um simples motivo: fazendo isso você está achando que identificou todas as tarefas da iteração e isso não será nunca realidade. Novas tarefas aparecem. Tarefas existentes precisam se dividir em duas ou mais, etc. O modelo comando e controle não ocorrerá porque os próprios desenvolvedores escolherão quais tarefas farão durante os daily stand-up meetings e APENAS após terem completado uma tarefa anterior.

Para corroborar ainda mais minha afirmação cito o excelente e crucial livro "Agile Estimating and Planning" (recomendo a todos que estejam usando Scrum, XP, OpenUP ou outro processo ágil que contenha Release Planning e Iteration Plannings que leiam o livro. Diria até que é leitura obrigatória!!!) do Mike Cohn:

Subtítulo "Tasks are not allocated during iteration planning" na página 147 capítulo 14: "Enquanto se planeja a iteração, tarefas não são alocadas a indivíduos específicos. No início da iteração, pode parecer óbvio quem irá trabalhar em uma tarefa específica. Porém, baseado no progresso de todo o time no conjunto das tarefas, o que é óbvio no início pode não ser o que acontece durante a iteração. Indivíduos não escolhem as tarefas em que vão trabalhar até que a iteração inicie e geralmente só escolhem uma ou duas tarefas relacionadas por vez. Novas tarefas não são iniciadas até que as previamente selecionadas sejam completadas. Não há nada a ganhar e muito a perder ao alocar indivíduos a tarefas específicas durante o planejamento da iteração."

Resenha do livro Head First Software Development da O'Reilly

O livro Head First Software Development, da O'Reilly, segue o mesmo padrão de conteúdo da série Head First: uso de imagens, análise de exemplos reais e simulados para ajudar no entendimento dos tópicos considerados, utilização de exercícios como: palavras cruzadas, preenchimento de lacunas, sessões de perguntas e respostas. Tudo com o intuito de reforçar conceitos estudados em um capítulo.

O livro possui uma meta ousada: Ensinar melhores práticas, técnicas e princípios para um ótimo processo de desenvolvimento de software e mostrar como é o ciclo de vida do desenvolvimento de software.

Os autores optaram claramente por demonstrar neste livro uma abordagem ágil para o desenvolvimento de software. O grande diferencial do livro é seu aspecto lúdico e divertido, o que facilita a leitura.

A seguir o conteúdo de cada capítulo:

1. Great Software Development
2. Gathering Requirements
3. Project Planning
4. User Stories and Tasks
5. Good-enough Design
6. Version Control
7. Testing and Continuous Integration
8. Test-Driven Development
9. Ending an Iteration
10. The Next Iteration
11. Bugs
12. The Real World
Appendix A. Leftovers
Section A.1. #1. UML class diagrams
Section A.2. #2. Sequence diagrams
Section A.3. #3. User stories and use cases
Section A.4. #4. System tests vs. unit tests
Section A.5. #5. Refactoring
Appendix B. techniques and principles
Section B.1. Development Techniques
Section B.2. Development Principles

É interessante notar que também existe um bom tratamento sobre as ferramentas básicas para a montagem de um bom ambiente colaborativo de desenvolvimento nos capítulos 6 e 7. No capítulo 5 encontramos uma breve exploração de conceitos relacionados a design (projeto) e refactoring de software.

Eu, particularmente, já conhecia todas as técnicas mostradas por eles e que são tratadas em diversos outros livros sobre processos ágeis. Recomendo fortemente para pessoas que querem conhecer mais sobre desenvolvimento ágil (e ainda possuem muitas dúvidas) e também para profissionais experientes que desejam ler um livro com uma abordagem mais interessante e diferenciada.

O livro também é muito recomendável para uso em disciplinas de Engenharia de Software, Processos de Desenvolvimento de Software e em treinamentos de métodos ágeis. Seus fortes aspectos didáticos auxiliam no entendimento de todos os tópicos abordados, seus relacionamentos e sua importância para o desenvolvimento de softwares.

Otimização para sites de busca (SEO) - Erros arquiteturais

Conforme prometido no artigo , vou comentar sobre erros arquiteturais comuns que podem afetar uma estratégia de Search Engine Optimization (Otimização para sites de busca) eficaz.

Os mais importantes erros cometidos (especialmente e com frequência por web designers):

- Criar sites inteiros em Flash ou outra tecnologia RIA (Rich Internet Application).

- Criar a página Home em Flash.

- Criar páginas com o texto sendo uma figura (sim, isso existe!) ao invés de HTML, pdf ou um doc.

- Criar um menu de navegação de páginas do site em Flash ou apenas com JavaScript ou apenas usando figuras como botões.

Os pontos acima são os mais básicos, pois o seu site ou muitas páginas dele podem simplesmente não constar do google devido aos pontos acima relatados. O Google e outras ferramentas de busca indexam HTML. Elas não indexam (ainda não... pelo menos!) aplicações RIA como Flash, Flex, Silverlight, Google Web Toolkit, etc ou menus dinâmicos escritos apenas em JavaScript ou com figuras e botões ao invés de links. Nós, seres humanos, adoramos esse contexto visual e essas aplicações mais amigáveis. Porém e, infelizmente, os robôs de busca ainda não conseguem compreender esses formatos. Os spiders de busca amam mesmo é texto HTML!

Caro web designer ou desenvolvedor web: isso não significa que você não deve nunca mais usar Flash ou RIA na sua vida ou fazer algum efeito legal em JavaScript. Você deve apenas controlar com parcimônia seu uso. Crie a home page do site, seus menus e seu conteúdo escrito usando HTML e trate um Flash como uma aplicação interna ao site. Lembre-se: conteúdo escrito deve sempre e preferencialmente estar em formato HTML, para que possa ser lido perfeitamente pelos robôs de busca.

Outro erro arquitetural grave é o formato das URLs dinâmicas de um site. Esse é um erro causado especialmente pelos arquitetos e programadores web. URLs dinâmicas, dependendo de como são formadas, podem causar problemas para a leitura dos robôs de busca. Mesmo quando não trazem problemas elas reduzem as chances de um bom posicionamento na busca orgânica. Isso ocorre porque as máquinas de busca procuram as palavras-chave especialmente no título da página, na URL e no corpo do texto. Nesse artigo não vou falar sobre estratégias de como encontrar boas palavras-chave e como usá-las dentro de uma página de site (quem sabe outro dia!). O importante é que se saiba que a URL de uma página ajuda a dar mais relevância às palavras-chave. Uma boa URL também ajuda na leitura dos seres humanos que a estão acessando. Portanto há ótimos motivos para que a URL seja amigável!

Portanto, uma URL ruim pode fazer com que a página tenha um rank menor ou, pior ainda, nem seja listada no mecanismo de busca.

Exemplos de URLs ruins:

http://yourdomain.com/index.html&DID=18&CATID=13

http://yourdomain.com/buyAHome.do;jsessionid=07D3CCD

http://www.yourdomain.edu/racing/scores.php?prg=1

As três URLs acima são ruins pois não especificam do que exatamente se trata a página e ainda podem gerar problemas de acesso aos robôs.

Note agora como são URLs bem formuladas:

http://josepaulopapo.blogspot.com/2008/01/introducao-openup.html

http://josepaulopapo.blogspot.com/2008/01/bibliografia-marketing-otimizacao-sites.html

http://www.amazon.com/Enterprise-Scrum-Ken-Schwaber/dp/0735623376

Nas duas primeiras URLs (do meu site. É claro que eu uso técnicas de SEO!!!) é possível verificar que o primeiro artigo trata de uma introdução ao OpenUP e o segundo é uma bibliografia sobre otimização de sites. Ambos são de janeiro de 2008 (2008/01). No terceiro link vemos como a Amazon também usa de forma correta as URLs: a URL contém as palavras-chave do livro (que se chama "The Enterprise and Scrum"), bem como o ISBN (caso o usuário faça uma busca pelo ISBN no google também achará logo nos primeiros resultados a página da Amazon).

Não vou citar nomes (e nem URLs!), mas procure os principais sites brasileiros de vendas de livros e outros produtos aqui do Brasil e vocês notarão que eles ainda não possuem URLs boas (provavelmente devido a um problema arquitetural no desenvolvimento e falta de conhecimento de técnicas de otimização para sites de busca).

Falamos então de alguns erros básicos e principais (há mais! mas não os tratamos nesse artigo) na construção de sites e que podem torná-lo praticamente invisível nos sites de busca como Yahoo, Google, etc. Mais uma vez recomendo que clientes peçam claramente que seus sites sejam Search Engine Friendlies - isto é amigáveis a sites de busca - se acharem necessário e que os analistas de requisitos perguntem isso claramente a seus clientes (trate como um requisito não funcional do site).

Se sua empresa (ou a empresa contratada para construir seu site) não conhece as técnicas de SEO, contrate um especialista para ajudá-lo. Nada pior do que não conseguir um marketing de busca orgânico bom (e ainda por cima gratuito!!!) devido a erros arquiteturais de construção do site e por não saber como as máquinas de busca indexam as páginas!

Uma Introdução ao OpenUP na revista Visão Ágil

Escrevi um artigo na terceira edição da revista Visão Ágil com uma introdução ao OpenUP. Basta acessar a terceira edição da revista e buscar pela matéria na página 25.

O texto inicia assim:

"OpenUP é um processo enxuto, baseado no 'Unified Process', que possui um ciclo de vida iterativo e incremental. O OpenUP também foi elaborado como uma filosofia ágil, pragmática e que foca na natureza colaborativa do desenvolvimento de software. É um processo de baixa cerimônia e que não indica nenhum tipo de ferramenta específica. Uma das características visíveis do OpenUP é que a disciplina de gestão de projetos é uma adaptação do Scrum (processo ágil empírico com foco nos aspectos de gestão de projetos, sem entrar em detalhes da engenharia de software).

O OpenUP possui princípios (isto é, se você não seguir um dos princípios você não está na realidade adotando o processo como se deve) semelhantes à versão 7 do RUP. Eles são:

● Balancear prioridades competidoras para maximizar o valor aos envolvidos do projeto.
● Colaborar para alinhar interesses e compartilhar entendimento.
● Focar cedo na arquitetura para minimizar riscos e organizar o desenvolvimento.
● Evoluir para continuamente obter feedback e melhorar.

O OpenUP pode ser mais facilmente entendido através dos seus ciclos de visibilidade. Vamos falar sobre cada um deles separadamente, na seqüência do ciclos mais curto até o ciclos mais longo, para dar uma visão clara de como é a vida em um projeto OpenUP...".