Tópicos

Introdução

O RUP (Rational Unified Process) é uma estrutura de processo que o Rational Software aperfeiçoa com o passar dos anos e tem sido amplamente utilizado para todos os tipos de projetos de software, do pequeno ao grande. Recentemente um número crescente de processos "agile" - como XP (eXtreme Programming), SCRUM, FDD (Feature-Driven Development) e a Metodologia Crystal Clear têm obtido reconhecimento como métodos eficazes para a criação de sistemas menores. (Consulte www.agilealliance.org para obter informações adicionais sobre a Agile Alliance.)

As seguintes seções têm por objetivo auxiliar essas equipes de projeto, avaliando algumas das práticas "agile" localizadas em um desses métodos para verificar como elas são tratadas por um processo de desenvolvimento de software mais completo definido pelo RUP (para obter informações adicionais sobre o RUP, consulte Introdução ao RUP).

Visão Geral

A comunidade agile sintetizou um número de "boas práticas" que são especialmente aplicáveis às equipes de projeto pequenos no mesmo local. Embora o RUP seja destinado às equipes de projeto de qualquer tamanho, ele pode ser aplicado com êxito aos projetos pequenos. Em geral, o RUP e os processos da comunidade Agile têm uma visualização semelhante às boas práticas principais requeridas para desenvolver software de qualidade, por exemplo, aplicando o desenvolvimento iterativo e enfatizando os usuários.

As seguintes seções explicam como aplicar algumas das "boas práticas" identificadas na comunidade Agile para projetos com base em RUP que gostariam de se beneficiar de algumas dessas práticas. Nesse caso, o foco estará especificamente nas práticas apresentadas pela metodologia eXtreme Programming (XP). (Para obter informações adicionais sobre o XP, consulte o Web site: http://www.extremeprogramming.org.)

Práticas XP

O XP inclui quatro "atividades" básicas (codificação, teste, escuta e design), que na verdade são alinhadas mais intensamente às disciplinas do RUP. Essas atividades de XP são executadas usando um conjunto de práticas que requerem a execução de atividades adicionais, que estão mapeadas em outras disciplinas do RUP. As práticas do XPs, de acordo com o Extreme Programming Explained são:

• O jogo do planejamento: Determine rapidamente o escopo da próxima liberação, combinando as prioridades de negócios e as estimativas técnicas. Quando a realidade superar o plano, atualize-o.
• Pequenas Liberações: Coloca um sistema simples em produção rapidamente, em seguida, libera novas versões em um ciclo muito curto.
• Metáfora: Guia todo o desenvolvimento com uma história simples compartilhada de como todo o sistema funciona.
• Design Simples: O sistema deve ser projetado o mais simplesmente possível a qualquer momento. Qualquer complexidade extra deve ser removida assim que for descoberta.
• Teste: Os programadores escrevem testes de unidade continuamente, que devem ser executados sem problemas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as características foram alcançadas.
• Recriação: Os programadores reestruturam o sistema sem alterar seu comportamento para remover a duplicação, aprimorar a comunicação, simplificar ou incluir flexibilidade.
• Programação aos Pares: Todo o código de produção é gravado com dois programadores em uma máquina.
• Propriedade Coletiva: Qualquer pessoa pode alterar qualquer código em qualquer lugar do sistema a qualquer momento.
• Integração Contínua: Integra e constrói o sistema muitàs vezes por dia, sempre que uma tarefa é concluída.
• 40 horas por semana: A regra é não trabalhar mais de 40 horas por semana. Nunca faça hora extra duas semanas seguidas.
• Cliente On-site: Inclui um usuário real, ativo na equipe, disponível em tempo integral para responder perguntas.
• Padrões de Codificação: Os programadores escrevem todo o código de acordo com as regras, enfatizando a comunicação por meio do código.

As atividades realizadas como resultado da prática de "jogo de planejamento", por exemplo, mapearão principalmente para a disciplina de gerenciamento de projeto do RUP. Mas alguns tópicos RUP, como a implementação do software liberado, estão fora do escopo do XP. A obtenção de requisitos está ainda mais fora do escopo de XP, já que é o cliente quem define e fornece os requisitos. Além disso, devido aos projetos de desenvolvimento mais simples com os quais lida, a XP pode tratar de forma mais superficial as questões que o RUP aborda em detalhes na disciplina de Gerenciamento de Configuração e Mudança e na disciplina de Ambiente.

Práticas XP Compatíveis com RUP

Nas disciplinas em que o XP e o RUP se sobrepõem, as seguintes práticas descritas no XP podem ser e, em alguns casos já são, empregadas no RUP:

• O Jogo de Planejamento: A orientação de XP sobre planejamento poderia ser utilizada para alcançar muitos dos objetivos mostrados na disciplina do Gerenciamento de Projeto do RUP para um projeto muito pequeno. Isso é especialmente útil para projetos sem muita formalidade e que não precisam produzir artefatos de gerenciamento de projeto intermediários de modo formal.
• Design Teste Primeiro e Recriação: Essas são boas técnicas que podem ser aplicadas na disciplina de implementação do RUP. A prática de XP para testes, que requer teste anterior ao design, é uma forma excelente de esclarecer requisitos em um nível mais detalhado. Como veremos na próxima seção, a refatoração pode não ser compatível com sistemas maiores.
• Integração Contínua: O RUP suporta essa prática por meio de construções nos níveis de subsistema e de sistema (dentro de uma iteração). Os componentes testados em unidades são integrados e testados no contexto do sistema emergente.
• Cliente On-site: Muitas das atividades do RUP se beneficiariam muito por terem um cliente on-site como um membro da equipe, que pode reduzir o número de produtos liberados intermediários necessários, especialmente os documentos. Como meio preferido de comunicação cliente-desenvolvedor, a XP destaca a conversação, que tem como base a continuidade e a familiaridade para ser bem-sucedida; no entanto, quando um sistema, mesmo pequeno, tiver que ser transferido, mais de uma conversação será necessária. A XP permite fazer isso como uma reflexão posterior (por exemplo, projetar documentos no final de um projeto). Como não impede a produção de documentos ou outros artefatos, a XP defende que devem ser produzidos apenas aqueles que são realmente necessários. O RUP concorda, mas continua a descrever o que é necessário quando a continuidade e a familiaridade não são ideais.
• Padrões de Codificação: O RUP tem um artefato-diretrizes de programação-que quase sempre seria considerado obrigatório. (Os perfis de risco são os principais fatores de adaptação.)
• Quarenta Horas por Semana: Como na XP, o RUP sugere que trabalhar horas extras não deve ser uma condição crônica. A XP não sugere um limite rígido de 40 horas, admitindo diferentes margens de tolerância para o período de trabalho. Os engenheiros de software costumam trabalhar muitas horas sem gratificação extra, trabalham apenas pela satisfação de verem algo concluído, e os gerentes não necessariamente precisam colocar arbitrariamente um ponto final nisso. O que eles nunca devem fazer é impor essa prática ou se utilizar dela. Eles devem reunir métricas sobre as horas realmente trabalhadas, ainda que não compensadas. Se o registro de horas trabalhadas de um funcionário for alto durante um período prolongado, isso certamente deve ser investigado. Entretanto, essa questão deve ser resolvida entre o gerente e o indivíduo, dentro do contexto das circunstâncias em que ocorrem, admitindo preocupações que o restante da equipe poderia ter. Quarenta horas é apenas uma diretiva, mas convincente.
• Programação aos Pares: O XP afirma que a programação aos pares é benéfica para a qualidade do código e que uma vez que essa habilidade é adquirida, ela torna-se mais agradável. O RUP não descreve o mecanismo de produção de código em um nível tão refinado, embora seja possível usar a programação em pares em um processo baseado no RUP. Algumas informações sobre a programação aos pares, assim como teste anterior ao design e refatoração, são fornecidas com o RUP, na forma de white papers. Obviamente, não é obrigatório usar essas práticas no RUP. No entanto, em um ambiente de equipe, com uma cultura de comunicação aberta, podemos arriscar um palpite de que seria muito difícil discernir os benefícios da programação em pares (em termos de efeito sobre o custo total do ciclo de vida). É normal que as pessoas se reúnam para discutir e resolver problemas em uma equipe bem integrada, sem que sejam obrigadas a fazer isso.

A idéia de que um bom processo deve ser imposto no nível "micro" não costuma ser bem recebida e pode não ser adequada a algumas culturas empresariais. Por isso, qualquer imposição rígida não é defendida pelo RUP. Entretanto, em algumas circunstâncias, o trabalho em pares, e algumas das outras práticas de equipe defendidas pela XP, é obviamente vantajoso, como cada membro de equipe pode ajudar o outro; por exemplo:

• no início da formação da equipe, quando as pessoas ainda estão se conhecendo
• em equipes que não tenham experiência em uma determinada tecnologia nova
• em equipes mistas formadas tanto por pessoal experiente como por novatos

Práticas XP que Não São Bem Escaladas

As práticas do RUP, a seguir, não são compatíveis com sistemas grandes (nem a XP afirma que o são). Por isso, seu uso estaria sujeito a esta condição no RUP.

• Metáfora: Para sistemas complexos maiores, a arquitetura como metáfora é simplesmente insuficiente. O RUP fornece uma estrutura de descrição muito mais rica para a arquitetura que não é apenas tão Explicada pela Programação Extrema quanto é descrita-"grandes caixas e conexões". Mesmo na comunidade XP, a metáfora foi reprovada mais recentemente. Não é mais uma das práticas na XP (até que consigam descobrir como descrevê-la bem, talvez uma metáfora pudesse ajudá-los).
• Propriedade Coletiva: Isso será útil, se os membros de uma equipe responsável por um sistema pequeno ou um subsistema estiverem familiarizados com todos os seus códigos. Porém, se você deseja que todos os membros da equipe estejam em condições de efetuar mudanças em qualquer lugar, isso vai depender da complexidade do código. Geralmente, é mais rápido (e seguro) que a correção seja efetuada pelo indivíduo (ou par) que esteja trabalhando no momento no respectivo segmento do código. A familiaridade com qualquer código (até mesmo o mais bem escrito), especialmente se ele é complexo pelo aspecto algorítmico, diminui rapidamente através do tempo.
• Recriação: Em um sistema grande, a recriação freqüente não é uma substituta para a falta de arquitetura. A Programação Extrema Explicada diz: "a estratégia de design do XP é semelhante a um algoritmo hill-climbing (escalada de montanha). Você pega um design simples, torna-o um pouco mais complexo, depois um pouco mais simples e de novo mais complexo. O problema com os algoritmos hill-climbing é alcançar o ponto ideal, em que nenhuma pequena alteração poderia aprimorar a situação, mas uma alteração grande poderia." No RUP, a arquitetura fornece a visualização e o acesso à "grande montanha" tornando flexível um sistema grande e complexo.
• Liberações Pequenas: A freqüência com que um cliente pode aceitar e implementar novas liberações dependerá de muitos fatores, normalmente incluindo o tamanho do sistema, que normalmente está relacionado ao impacto nos negócios. Um ciclo de dois meses pode ser muito curto para alguns tipos de sistema, sendo proibido pela logística de implementação.

Prática XP que Requer Cuidado

Finalmente, uma prática de XP que aparentemente possa ser utilizada no RUP-Design Simples-precisa de alguma elaboração e cuidado quando aplicada geralmente.

• Design Simples
  XP é muito direcionada à funcionalidade: histórias de usuários são selecionadas, decompostas em tarefas e, em seguida, implementadas. De acordo com Extreme Programming Explained, o design correto para o software a qualquer momento é o que executa todos os testes, não tem lógica duplicada, declara todas as intenções importantes para os programadores e possui o menor número possível de classes e de métodos. A XP não acredita que seja certo acrescentar itens desnecessários apenas para agregar valor de negócio para o cliente.

  Há um problema aqui, semelhante ao problema das otimizações locais, que é lidar com o que o RUP chama de requisitos RUP "não-funcionais". Esses requisitos também agregam valor de negócio para o cliente, mas são mais difíceis de expressar como histórias. Algumas das restrições (assim denominadas pela XP) se enquadram nessa categoria. O RUP também não defende que se faça design a mais do que seja necessário em qualquer tipo de modo especulativo, mas defende o design com um modelo arquitetural mental - modelo este que é uma das chaves para se encontrar os requisitos não-funcionais.

  Assim, o RUP concorda com a XP que o "design simples" deve incluir a execução de todos os testes, mas com a condição de que ele inclua testes que demonstrem que o software atenderá aos requisitos não-funcionais. Mais uma vez, essa só é uma questão válida à medida que o tamanho do sistema e a complexidade aumentem ou quando a arquitetura é inédita ou os requisitos não-funcionais são dispendiosos. Por exemplo, a necessidade de dados desordenados (para operar em um ambiente distribuído de forma heterogênea) parece tornar o código excessivamente complexo, mas ele ainda será necessário durante todo o programa.

Mapeamento dos Artefatos para um Pequeno Projeto

Quando adaptamos o RUP para um projeto pequeno e reduzimos os requisitos do Produto de Trabalho de acordo, como isso se compara ao equivalente dos artefatos em um projeto XP? A Tabela 1 mostra um conjunto típico de artefatos RUP em um pequeno projeto RUP.

Tabela 1: Mapeamento XP-a-RUP de Artefatos para um Pequeno Projeto

Embora a granularidade dos artefatos varie nos dois lados, em geral os artefatos no RUP para projetos pequenos (do tipo com o qual a XP lidaria tranqüilamente) são mapeados sem problemas para os de um projeto de XP.

Observe que a tabela também inclui alguns artefatos que não são cobertos pelo XP, mas são necessários em muitos projetos. Isso inclui o Modelo de Dados e os artefatos relacionados à implementação, como o Material de Suporte ao Usuário.

Atividades

O RUP define uma Tarefa como trabalho executado por uma Função-seja utilizando e transformando os artefatos de entrada ou produzindo artefatos de saída novos e alterados. O RUP continua enumerando essas atividades e as categoriza de acordo com as disciplinas RUP. Essas disciplinas incluem: requisitos, análise e design, implementação e gerenciamento de projeto (entre outras).

As atividades estão relacionadas ao tempo por meio dos artefatos que produzem e consomem: uma atividade pode logicamente ser iniciada quando suas entradas estiverem disponíveis (e em um estado de maturação apropriado). Isso significa que os pares de atividades produtor-cliente podem se sobrepor no tempo, se o estado do artefato permitir. Eles não precisam obedecer a uma seqüência rígida. As atividades se destinam a fornecer diretrizes claras sobre como um artefato deve ser produzido ou alterado e podem ser usadas para ajudar o gerente de projeto no planejamento.

Combinadas por meio do RUP, já que são descritas em termos de ciclo de vida, artefatos e atividades são "boas práticas": princípios de engenharia de software que comprovadamente produzem softwares de qualidade criados para orçamento de programação previsíveis. Através de suas atividades (e artefatos associados), o RUP suporta e realiza essas melhores práticas. Elas são temas executados através do RUP - que sustentam os principais princípios que fundamentam o RUP. Observe que a XP utiliza a noção de "práticas" também, mas, como veremos, não corresponde exatamente ao conceito de boas práticas do RUP.

A XP apresenta uma visão de desenvolvimento de software que é atraentemente simples, composta por quatro atividades básicas (codificação, teste, monitoramento e design) que devem ser ativadas e estruturadas de acordo com algumas práticas de suporte (conforme abordado no capítulo 9 do livro Extreme Programming Explained). Na verdade, como observado anteriormente, as atividades de XP estão mais relacionadas em escopo às disciplinas do RUP do que às atividades do RUP. Muito do que acontece em um projeto de XP (além de suas quatro atividades básicas) é resultado da elaboração e da aplicação de suas práticas.

Portanto, há equivalência entre as atividades de XP e RUP, mas as "atividades" de XP não estão formalmente identificadas ou descritas como tal. Por exemplo, analisando o Capítulo 4, "Histórias de Usuários", no Programação Extrema Instalada, você encontrará o título, "Definir Requisitos com Histórias, Escritas em Cartões" e em todo o capítulo há uma mistura da descrição do processo e da orientação sobre o que são histórias de usuários e como (e por quem) elas devem ser produzidas. E continua assim; nas várias seções dos manuais de XP (com títulos que são uma mistura de ênfase em artefato e ênfase em atividade), os "itens produzidos" e os "itens feitos" são descritos em graus variáveis de prescrição e de detalhes.

O grau de prescrição aparentemente alto do RUP é resultado da abrangência e maior formalidade no tratamento de atividades e de suas entradas e saídas. Não falta prescrição à XP, porém, na sua tentativa de permanecer leve, a formalidade e os detalhes são simplesmente omitidos. A falta de especificidade não é vantagem nem desvantagem, mas a falta de informações detalhadas no XP não deve ser confundida com simplicidade. A falta de detalhes pode ser ótima para desenvolvedores mais experientes, mas, em muitos casos, a fartura de detalhes é uma grande ajuda para membros da equipe que sejam novos ou que ainda estejam tentando acompanhar o ritmo da abordagem da equipe quanto a desenvolvimento de software.

Com Atividades, assim como com Artefatos, é importante manter o foco no que estamos tentando alcançar. Executar uma atividade às cegas nunca é uma boa prática. As atividades e as diretrizes associadas estão à disposição para quando você precisar delas para atingir seus objetivos, mas não devem ser usadas como desculpa para não ter de descobrir qual é o seu objetivo. Esse pensamento é bem articulado em XP e acreditamos que deva ser aplicado a todos os usuários de RUP.

Funções

No RUP, as atividades devem ser executadas por funções (ou, mais precisamente, por indivíduos ou grupos exercendo funções). As funções também têm responsabilidade por artefatos específicos; a função responsável normalmente criará o artefato e garantirá que as mudanças feitas por outras funções (se permitidas) não danifiquem o artefato. Um indivíduo ou um grupo de pessoas pode assumir apenas de um a vários papéis. Uma função não tem que ser mapeada para uma única posição ou "slot" em uma organização.

A Programação Extrema Explicada identifica sete funções aplicáveis ao Programador XP, Cliente, Testador, Rastreador, Técnico, Consultor e Diretor e descreve suas responsabilidades e as competências requeridas das pessoas que as executarão. As referências também são feitas a essas funções em alguns dos outros manuais de XP . A diferença no número de papéis no XP e no RUP é fácil de explicar.

• A XP não aborda todas as disciplinas do RUP.
• Os papéis de XP equivalem mais a posições dentro de uma organização (possivelmente com várias responsabilidades) do que a papéis do RUP. Por exemplo, o Programador do XP, na verdade, executa várias funções do RUP: Implementador, Revisor de Código e Integrador, que requerem competências ligeiramente diferentes.

Funções XP e RUP em um Pequeno Projeto

Quando as funções RUP são mapeadas para um projeto pequeno, o número de funções parecidas com XP as quais elas correspondem é reduzido consideravelmente em que o número de posições ou títulos de tarefas é 5. A Tabela 3 (retirada do RUP) mostra este mapeamento com a Função XP correspondente.

Tabela 3: Mapeando Funções XP para Funções RUP em um Projeto Pequeno

Utilizando Práticas XP com o RUP

O RUP é um framework de processo a partir do qual determinados processos podem ser configurados e, em seguida, instanciados. O RUP deve ser configurado, esta é uma etapa obrigatória, definida no próprio RUP. Especificamente falando, devemos comparar uma versão adaptada do RUP com XP, ou seja, com o RUP adaptado às características do projeto que a XP explicitamente estabelece (e as que podem ser inferidas). Um processo de RUP adaptado dessa forma poderia acomodar muitas das práticas de XP (como programação em pares, refatoração e teste anterior ao design), mas ainda não seria idêntico à XP, por causa da ênfase do RUP em arquitetura, abstração (em modelagem) e risco e de sua estrutura diferente no tempo (fases e iterações).

A XP é dirigida intencionalmente para a implementação de um processo leve para projetos pequenos. Ao fazer isso, ela também inclui descrições (pelo menos nos livros) que não são totalmente elaboradas. Em uma implementação de XP, sempre haverá itens que precisam ser descobertos, inventados ou definidos rapidamente. O RUP acomodará projetos que estejam adequados ou além do escopo da XP em escala e tipo. Como mostra este roteiro, na verdade, o RUP é perfeitamente compatível com a maioria das práticas descritas na literatura sobre XP.

Lembre-se de que a essência da XP é o foco na organização, nas pessoas e na cultura. Isso é importante em todos os projetos e, certamente, é aplicável aos projetos que usam o RUP. O uso conjunto dessas práticas seria muito vantajoso para projetos pequenos.

Referências ao Processo Agile

• eXtreme Programming (XP) (Consulte http://www.extremeprogramming.org/more.html para obter informações adicionais.) :
  • Programação Extrema Explicada: Adotar Alteração. Kent Beck explica os conceitos e a filosofia por trás da XP. Esse livro ensina o quê e por que, mas não como.
    
  • Recriação Aprimorando o Design do Código Existente. Martin Fowler escreve o primeiro volume autorizado sobre refatoração. Apresentado como padrões. Há muitos exemplos em Java. Esse livro ensina a refatorar e por que.
    
  • Programação Extrema Instalada. Autores: Ron Jeffries, Chet Hendrickson e Ann Anderson. Esse livro aborda práticas específicas de XP em mais detalhes do que a Programação Extrema Explicada. Ele ensina a programar estilo de XP.
    
  • Planejando a Programação Extrema. De Kent Beck e Martin Fowler. Esse livro apresenta os pensamentos mais recentes sobre planejamento de software em um ambiente de entrega rápida. Ele ensina a executar um projeto de XP.
    
  • Programação Extrema Examinada. De Giancarlo Succi e Michele Marchesi. Artigos apresentados em XP2000. Um conjunto completo de artigos aborda a maioria dos tópicos.
    
  • Programação Extrema em Prática. Por Robert C. Martin, James W. Newkirk. Um projeto real que utilizou XP é descrito em detalhes.
    
  • Programação Extrema Explorada. De William C. Wake. Com base no Web site popular XPlorations. Alguns assuntos específicos são explorados em detalhes.
    
  • Programação Extrema Aplicada: Jogando para Ganhar De Ken Auer e Roy Miller. Experiências de pioneiros na aplicação de XP. Será publicado em setembro.

Para obter informações sobre outros membros do Agile Alliance, consulte http://www.agilealliance.org.