Roteiro: Práticas Dinâmicas no RUP

Tópicos

Introdução

O Rational Unified Process (RUP) é um framework de processo que foi aperfeiçoado pela Rational Software com o passar dos anos e que tem sido amplamente usado para todos os tipos de projeto de software, do pequeno ao grande. Recentemente, um número cada vez maior de processos "dinâmicos", como eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) 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 mais informações sobre a Agile Alliance.)

O objetivo deste roteiro é ajudar essas equipes de projeto a avaliar algumas das práticas "dinâmicas" encontradas em um desses métodos para verificar como o processo de desenvolvimento de software mais completo, definido pelo RUP, lida com elas.

Visão Geral de Roteiros

A comunidade Agile sintetizou várias "melhores práticas" que se aplicam especialmente a equipes de projetos pequenos no mesmo local. Embora o RUP seja destinado a equipes de projeto de qualquer tamanho, ele pode ser aplicado com êxito a projetos pequenos. Em geral, o RUP e os processos da comunidade Agile têm uma visão semelhante sobre as melhores práticas necessárias para desenvolver software de qualidade — por exemplo, aplicação de desenvolvimento iterativo e foco nos usuários finais.

Este roteiro explica como aplicar algumas das "melhores práticas", identificadas na comunidade Agile, a projetos baseados no RUP. Nesse caso, o foco estará especificamente nas práticas apresentadas pela metodologia eXtreme Programming (XP). (Para obter mais informações sobre XP, consulte o site da Web: http://www.extremeprogramming.org.)

Práticas de XP

Em XP existem quatro "atividades" básicas (codificação, teste, monitoramento e design) que estão intrinsecamente relacionadas com as 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. Segundo o livro Extreme Programming Explained, estas são as práticas de XP:

• Jogo de planejamento: determine com rapidez o escopo do próximo release combinando prioridades comerciais e estimativas técnicas. Quando a realidade superar o plano, atualize-o.
• Pequenos releases: coloque um sistema simples em produção rapidamente, depois libere novas versões em um ciclo mais curto.
• Metáfora: oriente todo o desenvolvimento com uma simples história compartilhada sobre como o sistema funciona.
• Design simples: o design do sistema deve ser sempre o mais simples possível. Qualquer complexidade extra deve ser removida assim que for descoberta.
• Teste: os testes unitários são escritos ininterruptamente pelos programadores e devem ser executados sem problemas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as características foram alcançadas.
• Refatoração: os programadores reestruturam o sistema sem alterar seu comportamento a fim de remover duplicação, melhorar a comunicação, simplificar ou adicionar flexibilidade.
• Programação em pares: todo código de produção é escrito por 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: integre e crie o sistema muitas vezes por dia, sempre que uma tarefa for concluída.
• Semana de 40 horas: a regra é não trabalhar mais do que 40 horas por semana. Nunca faça hora extra duas semanas seguidas.
• Cliente no local: Inclua na equipe um usuário real que esteja disponível o tempo inteiro para responder dúvidas.
• Padrões de codificação: programadores escrevem todo o código de acordo com regras que enfatizem a comunicação através do código-fonte.

As atividades realizadas como resultado da prática "Jogo de planejamento", por exemplo, serão mapeadas principalmente para a disciplina Gerenciamento de Projeto, do RUP. No entanto, alguns tópicos do RUP, como modelagem de negócios e implantação do software liberado, estão fora do escopo de 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 de XP Compatíveis com o RUP

Nas disciplinas em que a 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:

• Jogo de planejamento: As orientações de XP sobre planejamento podem ser usadas para atingir muitos dos objetivos mostrados na disciplina do RUP denominada Gerenciamento de Projeto, 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.
• Refatoração e teste anterior ao design: Estas técnicas são boas para serem aplicadas na disciplina 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 através de builds no nível de sistema e de subsistema (dentro de uma iteração). Os componentes testados em unidades são integrados e testados no contexto do sistema emergente.
• Cliente no local: Seria vantajoso para muitas das atividades do RUP ter um cliente no local fazendo parte da equipe, o que poderia reduzir o número de entregas intermediárias necessárias, especialmente em relação a documentos. Como meio preferido de comunicação desenvolvedor-cliente, a XP destaca a conversação, que depende da continuidade e da familiaridade para acontecer. No entanto, quando um sistema — ainda que pequeno — precisa ser transferido, é necessário muito mais do que conversação. 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, guia de programação, que pode ser considerado quase sempre obrigatório. (Os perfis de risco são os principais fatores de adaptação.)
• Semana de 40 horas: Assim como no XP, o RUP sugere que as horas extras não devem ser uma constante. 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 fazer horas extras sem receberem por elas, apenas pela satisfação de ver o trabalho concluído, e os gerentes não 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 em pares: A XP afirma que a programação em pares é vantajosa para a qualidade do código e que, como essa capacidade é adquirida, ela se torna ainda 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 programação em pares, bem como refatoração e teste anterior ao design, são fornecidas com o RUP, na forma de artigos. 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. Todavia, em algumas circunstâncias, o trabalho em pares (e algumas das outras práticas de equipe defendidas pela XP) é claramente vantajoso, já que cada membro da 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 formadas tanto por pessoal experiente como por novatos.

Práticas de XP Incompatíveis

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 grandes e mais complexos, a arquitetura como metáfora é simplesmente insuficiente. O RUP fornece um framework de descrição muito mais rico para arquitetura que não se constitui apenas em "caixas grandes e conexões", como descrito no livro Extreme Programming Explained. Mesmo na comunidade XP, a metáfora vem sendo desaconselhada. Ela não é mais uma das práticas do XP (até que consigam descobrir como descrevê-la bem; talvez uma metáfora pudesse ajudá-los).
• Propriedade Coletiva: É útil se os membros de uma equipe responsável por um subsistema ou um sistema pequeno estiverem familiarizados com todo o código. 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.
• Refatoração: Em um sistema grande, a refatoração freqüente não é um substituto para a falta de arquitetura. O Extreme Programming Explained afirma: "A estratégia de design da XP parece um algoritmo subindo e descendo a 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 esse tipo de algoritmo é que, quando ele atinge o ponto ideal, pode ser que uma pequena mudança não consiga melhorar a situação, somente uma grande mudança". No RUP, a arquitetura fornece a visão e o acesso à "grande montanha", tornando flexível um sistema grande e complexo.
• Pequenos Releases: A freqüência com que um cliente aceita e implanta novos releases dependerá de muitos fatores, geralmente incluindo o tamanho do sistema, que costuma estar 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 implantação.

Práticas de XP que Requerem Cautela

Por fim, mesmo uma prática de XP, que aparentemente possa ser utilizada no RUP (Design Simples), precisa de alguma elaboração e cautela quando aplicada de forma geral.

• Design Simples
  A XP é baseada em funcionalidade: histórias de usuários são selecionadas, divididas em tarefas e só então implementadas. Segundo o Extreme Programming Explained, o design correto para o software é aquele que executa todos os testes, não tem lógica duplicada, declara todas as intenções importantes para os programadores e tem 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 "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.

  Por isso, 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 de Artefatos para um Projeto Pequeno

Quando adaptamos o RUP para um projeto pequeno e reduzimos os requisitos de artefato de acordo, como isso se compara ao equivalente de artefatos em um projeto de XP? Observando o roteiro de projeto pequeno no RUP, vemos que um exemplo de configuração do RUP foi definido para produzir menos artefatos (como mostrado na Tabela 1).

Tabela 1: mapeamento de artefatos XP-para-RUP para um projeto pequeno

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 o Exemplo de Caso de Desenvolvimento para Projetos Pequenos também inclui alguns artefatos que não são abordados pela XP mas que são necessários em muitos projetos. Entre eles podemos citar Modelo de Dados e artefatos relacionados à implementação, como Material de Suporte para o Usuário
.

Atividades

O RUP define uma atividade como o trabalho realizado por um papel, quer seja usando e transformando artefatos de entrada ou produzindo artefatos de saída novos e alterados. O RUP continua a enumerar essas atividades e a categorizá-las de acordo com as disciplinas dele. São elas: modelagem de negócios, requisitos, análise e design, implantação e gerenciamento de projeto (entre outras).

As atividades estão relacionadas a tempo através dos artefatos que elas produzem e consomem: uma atividade pode ser iniciada de forma lógica quando suas entradas estão 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 orientações claras sobre como um artefato deve ser produzido ou alterado e podem ser usadas para ajudar o gerente de projeto no planejamento.

Combinadas através do RUP, já que são descritas em termos de ciclo de vida, artefatos e atividades, são "melhores práticas", ou seja, princípios de engenharia de software que comprovadamente produzem softwares de qualidade criados para orçamento e 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. Observe que a XP também usa a noção de "práticas", mas, como veremos, não corresponde exatamente ao conceito de melhores 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.

Por isso, há equivalência entre as atividades de XP e do RUP, mas as "atividades" de XP não são formalmente identificadas ou descritas como tal. Por exemplo, no capítulo 4, "Histórias de Usuários", do livro Extreme Programming Installed, você encontrará o título "Definir requisitos com histórias, escritas em cartões" e verá que todo o capítulo é um misto de descrição de processo e orientações sobre o que são histórias de usuários e como (e por quem) elas devem ser produzidas. Nas várias seções dos livros sobre XP (com títulos que são um misto de ênfase em artefatos e ênfase em atividades), 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 orientações 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 no XP e acreditamos que deva ser aplicado a todos os usuários de RUP.

Papéis

No RUP, as atividades são realizadas por papéis (ou, mais precisamente, por indivíduos ou grupos que assumem papéis). Os papéis também têm responsabilidade por certos artefatos; o papel responsável normalmente criará o artefato e assegurará que quaisquer mudanças nele efetuadas por outros papéis (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. Um papel não deve ser mapeado apenas para uma única posição ou "slot" em uma organização.

O Extreme Programming Explained identifica sete papéis aplicáveis a XP (Programador, Cliente, Testador, Rastreador, Técnico, Consultor e Diretor) e descreve suas responsabilidades e as competências exigidas das pessoas que irão assumi-los. Também são feitas referências a esses papéis em alguns dos outros livros sobre 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 na XP, na realidade, assume vários papéis do RUP (Implementador, Revisor de Código e Integrador) que exigem competências ligeiramente diferentes.

Papéis do RUP e do XP em um Projeto Pequeno

Quando papéis do RUP são mapeados para um projeto pequeno (como no Template de Plano de Desenvolvimento de Software para Projetos Pequenos), o número de papéis de XP aos quais eles correspondem é reduzido consideravelmente em relação ao número de posições (ou cargos), passando para 5. A Tabela 3 (retirada do RUP) mostra esse mapeamento com o papel de XP correspondente.

• eXtreme Programming (XP) (Consulte http://www.extremeprogramming.org/more.html para obter mais informações):
  • Extreme Programming Explained: Embrace Change. 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.
    
  • Refactoring Improving the Design of Existing Code. 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.
    
  • Extreme Programming Installed. Autores: Ron Jeffries, Chet Hendrickson e Ann Anderson. Esse livro aborda práticas específicas de XP em mais detalhes do que o Extreme Programming Explained. Ele ensina a programar estilo de XP.
    
  • Planning Extreme Programming. Autores: 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.
    
  • Extreme Programming Examined. Autores: Giancarlo Succi e Michele Marchesi. Artigos apresentados em XP2000. Um conjunto completo de artigos aborda a maioria dos tópicos.
    
  • Extreme Programming in Practice. Autores: Robert C. Martin e James W. Newkirk. É um projeto real, que usou a XP, descrito em detalhes.
    
  • Extreme Programming Explored. Autor: William C. Wake. Baseado no conhecido site da XPlorations. Alguns assuntos específicos são explorados em detalhes.
    
  • Extreme Programming Applied: Playing to Win. Autores: Ken Auer e Roy Miller. Experiências de pioneiros na aplicação de XP. Será publicado em setembro.
• Consulte http://www.agilealliance.org/signatories.html
  para obter informações sobre outros membros da Agile Alliance.
  

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process