Arquitetura Pragmática para o Gerenciamento de Ciclo de Vida do Aplicativo

Conceitos ágeis aplicados à arquitetura utilizando o Collaborative Lifecycle Management

Este artigo explica como as equipes ágeis utilizam o gerenciamento de design para produzir e manter sistemas intensivos de software. Ele descreve uma abordagem pragmática para a colaboração eficiente em designs em um ambiente de gerenciamento de ciclo de vida do aplicativo (ALM). Com base em exemplos realistas, o artigo aborda a arquitetura concreta e as atividades de design utilizando a solução Rational para o Collaborative Lifecycle Management (CLM).

Jean-Louis Maréchaux, Software Engineer, IBM

author photoJean-Louis Maréchaux é Software Engineer para o software Rational no IBM Canada Lab. Antes de fazer parte do grupo do Rational, Jean-Louis trabalhou como IT Architect para o grupo IBM Global Business Services e em outras organizações de TI, onde se envolveu com a arquitetura, design e desenvolvimento de aplicativos. Suas principais áreas de interesse são: arquitetura de software, ALM, tecnologias Java e práticas de desenvolvimento de softwares ágeis. Publicou vários artigos e deu palestras em várias conferências e workshops. Siga Jean-Louis em seu blog: Pragmatic Architecture.


nível de autor Contribuidor do
        developerWorks

16/Nov/2012

Introdução

O gerenciamento de ciclo de vida do aplicativo (ALM) decompõe silos organizacionais e promove a colaboração e visões voltadas para a função do ciclo de vida do aplicativo. Agora que os métodos de desenvolvimento ágeis são conhecidos, a arquitetura do software está se desenvolvendo para se tornar uma prática colaborativa quando se trata do envolvimento de toda a equipe. O design ágil é importante para alinhar as atividades de desenvolvimento às necessidades de negócios e para produzir sistemas intensivos de software de alta qualidade.

Este artigo explica como a arquitetura pragmática se ajusta a um ciclo de vida de desenvolvimento de softwares ágeis. Ele aborda as diferentes tarefas de design a serem consideradas durante um sprint e descreve como a solução Rational para o Collaborative Lifecycle Management suporta o ALM ágil.


ALM ágil

Não há nenhuma autoridade reconhecida para definir o que é o gerenciamento de ciclo de vida do aplicativo. O ALM é um termo amplo que geralmente se refere tanto aos processos quanto às ferramentas. Ele pode ser visto como o controle de um aplicativo de software desde a ideia inicial até o momento em que o aplicativo se torna obsoleto. A Forrester Research define ALM como a coordenação de atividades de ciclo de vida de desenvolvimento, incluindo requisitos, modelagem, desenvolvimento, construção e teste, por meio destas funções:

Rastreabilidade
Gerenciamento de relacionamentos entre o desenvolvimento de artefatos que são utilizados ou produzidos por atividades (integração)
 
Automação de processo
Execução de processos que abrangem essas atividades
 
Relatório
Relatório sobre o progresso do esforço de desenvolvimento como um todo
 

O ALM é uma disciplina. A rastreabilidade, a automação de processo e o relatório podem ser obtidos manualmente. Ainda assim, o ALM é bem mais eficaz e eficiente quando a coordenação e a integração são suportadas por uma ferramenta. Com os Cinco Imperativos para o Gerenciamento de Ciclo de Vida do Aplicativo, a IBM sugere que uma plataforma ALM deve suportar:

  • Colaboração no contexto
  • Planejamento em tempo real
  • Rastreabilidade do ciclo de vida
  • Inteligência de desenvolvimento
  • Melhoria contínua

ALM ágil, um oxímoro?

O Manifesto Ágil recomenda que os engenheiros de software "prezem os indivíduos e as interações sobre os processos e as ferramentas". Por esse motivo, muitos dos primeiros adotantes de metodologias ágeis estigmatizaram processos e ferramentas como impedimentos para o desenvolvimento bem-sucedido de softwares.

O ALM oferece a plataforma colaborativa para equipes ágeis multidisciplinares bem-sucedidas.

Ainda assim, os ganhos de produtividade sem as ferramentas se mostraram difíceis em alguns ambientes. As principais práticas ágeis devem ser adaptadas quando os desenvolvedores precisam interagir com equipes grandes ou distribuídas. As organizações sujeitas a requisitos regulamentares querem mecanismos confiáveis para suportar a rastreabilidade. As equipes que estão enfrentando outros fatores de ajuste de escala (consulte o Modelo de Ajuste de Escala Ágil em Recursos) tentam equilibrar a disciplina e agilidade a fim de serem mais eficientes.

O ALM ágil propõe reconciliar a flexibilidade, o conjunto de ferramentas leve e o trabalho em equipe. O objetivo é fornecer a quantidade certa de disciplina à sua equipe ágil e a plataforma integrada para coordenar os requisitos, o design, o desenvolvimento, a projeção e as atividades de teste. Portanto, não há nenhuma contradição com os princípios ágeis. O ALM oferece a plataforma colaborativa para equipes ágeis multidisciplinares bem-sucedidas.

Arquitetura pragmática

A função de arquiteto desapareceu de algumas abordagens ágeis, como scrum ou XP. Em outras metodologias ágeis, a função ainda está presente (Crystal, OpenUP) ou foi simplesmente renomeada (coordenador técnico em DSDM). No entanto, as atividades arquitetônicas sempre fazem parte dos métodos de desenvolvimento de softwares ágeis. Ao longo de um projeto, a equipe ágil precisa tomar decisões sobre prioridades, estimativas de esforço, soluções técnicas ou impacto de uma mudança. Na verdade, a grande mudança no desenvolvimento de softwares ágeis é que o design ocorre o tempo todo. Segundo Kent Beck em Extreme Programming Explained, "A questão não é desenvolver ou não, a questão é quando desenvolver. O design incremental sugere que o tempo mais efetivo para desenvolver seja à luz da experiência".

A arquitetura e o design não são responsabilidades de uma única pessoa. Eles são um esforço em equipe para suportar as atividades de desenvolvimento. As equipes ágeis devem valorizar o pragmatismo e a experiência prática, ao contrário do dogmático e da teoria.

  • Promover o trabalho colaborativo, que envolve todos os membros da equipe
  • Reduzir os riscos e as incertezas
  • Aderir ao minimalismo e aos princípios da simplicidade
  • Gerar os principais elementos para descrever a arquitetura durante sua iteração inicial
  • Modificar os designs durante todo o ciclo de vida de desenvolvimento para se adaptar às necessidades emergentes
  • Abordar tanto os requisitos funcionais quanto os não funcionais
  • Testar os conceitos teóricos e aproveitar a experiência empírica passada
  • Investir em requisitos conhecidos, em vez de necessidades futuras hipotéticas
  • Concentrar-se em tarefas que suportam a equipe de desenvolvimento

No ALM ágil, a arquitetura pragmática é essencial para suportar o desenvolvimento iterativo, reduzir o prazo de lançamento no mercado e melhorar a qualidade dos sistemas intensivos de softwares.


O gerenciamento de design em um ambiente ALM ágil

Em um típico ciclo de vida ágil (Figura 1), a equipe prioriza a lista não processada de produtos para identificar as histórias mais valiosas do usuário. Em seguida, elas são decompostas em tarefas e a equipe se concentra em sua conclusão para produzir softwares funcionais. Ao final do sprint, a equipe coleta feedback a ser considerado antes do início do próximo sprint.

Figura 1. Um exemplo de ciclo de vida de desenvolvimento ágil
Um exemplo de ciclo de vida de desenvolvimento ágil

Para desenvolver e fornecer um sistema de alta qualidade, as equipes ágeis executam tarefas de design durante todo o tempo. As informações sobre o design ajudam a priorizar a lista não processada de produtos e a avaliar o esforço de desenvolvimento para um sprint. Quanto aos profissionais ágeis, o design, desenvolvimento e teste são atividades interligadas para criar sistemas intensivos de software de forma iterativa.

Solução IBM Rational para o Collaborative Lifecycle Management

A solução Rational para o Collaborative Lifecycle Management (Figura 2) é uma plataforma ALM que integra o gerenciamento de requisitos, de mudanças e de configuração, de qualidade e de design. O ambiente suporta a colaboração no contexto, o planejamento em tempo real, a rastreabilidade do ciclo de vida, a inteligência do desenvolvimento e a melhoria contínua.

Figura 2. Colaboração da equipe e integração do ciclo de vida
Colaboração da equipe e integração do ciclo de vida

Os recursos de gerenciamento de design (consulte Recursos) possibilitam que as equipes colaborem nos designs, vinculem os recursos de design a outros artefatos de ciclo de vida (requisitos, testes ou itens de trabalho) e entendam o impacto de uma mudança. Com o Collaborative Lifecycle Management (CLM), os proprietários de produtos, scrum masters, membros da equipe e outras partes interessadas podem aproveitar as informações de design a qualquer momento. Os recursos de gerenciamento de design ajudam as equipes a colaborarem com os designs de forma eficiente, sejam eles colocalizados ou distribuídos.

Priorização da lista não processada

A lista não processada de produtos menciona todas as funcionalidades desejadas que ainda não foram incluídas no sistema (Figura 3).

Figura 3. Histórias do usuário priorizadas na lista não processada de produtos
Histórias do usuário priorizadas na lista não processada de produtos

Histórias e epopeias do usuário são populares entre as equipes ágeis para capturar os diferentes recursos do produto e falar sobre eles. Uma lista não processada de produtos se desenvolve ao longo do tempo. Algumas histórias são refinadas e novas histórias são descobertas e incluídas. A lista não processada de produtos é priorizada, com as histórias mais valiosas em primeiro. A parte inferior da lista não processada contém histórias ou epopeias menos valiosas, que ainda não são bem entendidas, como ilustra a Figura 1.

O valor de negócios é um importante fator a ser priorizado na lista não processada de produtos. No entanto, outros aspectos também devem ser considerados, como riscos e dependências.

Equipes ágeis experientes desejam abordar os riscos logo no início do processo para remover incertezas assim que possível. Quando uma história pode sugerir alguns desafios técnicos, é uma abordagem segura aumentar sua prioridade. Além disso, os profissionais pragmáticos sabem que podem existir algumas dependências entre histórias. Às vezes, uma história de alta prioridade pode ser implementada apenas depois que o trabalho de uma história relacionada for concluído.

Para identificar os riscos e as dependências técnicos, as equipes ágeis podem aproveitar as informações de design. Um rápido acesso à visão geral do design (Figura 4) pode ajudar a equipe a identificar as dependências. Uma breve discussão da arquitetura do sistema pode levar à descoberta de novos riscos técnicos.

Figura 4. Recursos de design
Recursos de design

Como o Collaborative Lifecycle Management é uma plataforma de ambiente integrado, o acesso à lista não processada de produtos é simples para todas as partes interessadas. As informações de design oferecem insights sobre os membros da equipe para que a lista não processada seja priorizada com base em informações concretas.

Planejamento do sprint

Cada sprint começa com um exercício de planejamento, no qual a equipe define seu objetivo e sua lista não processada. Com base na experiência e na métrica, a equipe seleciona a partir de uma lista não processada de produtos e de histórias mais valiosas que podem estar contidas em um sprint (Figura 5, etapa 1). Em seguida, as diferentes tarefas são obtidas e estimadas para implementar as histórias (Figura 5, etapa 2).

Figura 5. Planejamento do sprint no ciclo de vida ágil
Planejamento do sprint no ciclo de vida ágil

Durante as atividades de planejamento, as equipes ágeis consultam as informações de design para fazerem escolhas inteligentes. Para decompor uma história em tarefas e estimar o esforço de desenvolvimento, os membros da equipe devem entender a estrutura do aplicativo. O trabalho que é necessário para implementar uma história varia, dependendo dos desafios técnicos e ativos disponíveis para reuso.

Com o Collaborative Lifecycle Management (CLM), os membros da equipe rapidamente acessam a viabilidade técnica de um requisito. Eles captam os resultados de suas discussões para controlar as decisões tomadas (Figura 6).

Figura 6. Exemplo de documento de design compartilhado
Exemplo de documento de design compartilhado

As equipes também podem procurar ativos reutilizáveis por meio da procura de texto simples (Figura 7).

Figura 7. Procura de texto completo e resultados da procura
Procura de texto completo e resultados da procura

O fácil acesso às informações de design facilita o exercício de planejamento para as histórias mais complexas. As informações de design ajudam as equipes a avaliarem o esforço de desenvolvimento para o sprint. Durante uma sessão de planejamento, pensamentos iniciais podem ser captados e persistidos em um documento de design da web para reuso posterior.

Desenvolvimento iterativo

Durante os sprints, as equipes ágeis se concentram no desenvolvimento para fornecer o software funcional. No entanto, o código não surge do nada. Primeiro, ele deve implementar uma história específica, pois o alinhamento às necessidades de negócios é fundamental para oferecer bons softwares. O desenvolvimento não é um simples processo de tradução de uma linguagem (humana) para outra (de programação). Para desenvolver um recurso, programadores experientes consideram as melhoras práticas da linguagem, os padrões de design, a complexidade do código ou a facilidade de desenvolver e manter o software.

Os desenvolvedores colaboram. Como uma equipe, eles conversam, dão ideias e, juntos, localizam soluções para os desafios descobertos durante um sprint. As lousas têm sido úteis para ideias e resolução de problemas. O CLM oferece um suporte mais robusto para o rascunho. Durante uma sessão em grupo, os membros da equipe podem criar rascunhos sobre o servidor de gerenciamento de design (Figura 8). Os rascunhos são imediatamente acessíveis às partes interessadas colocalizadas e distribuídas para facilitar a colaboração.

Figura 8. Rascunhos de design
Rascunhos de design

Também pode ser necessário que as equipes concluam tarefas de design para abordar algumas histórias do usuário complexas, colaborem com os parceiros de negócios ou suportem os requisitos regulamentares. Os profissionais ágeis preferem o design "em um flash" para concluir as tarefas de design como parte das atividades de desenvolvimento (sem nenhum grande design inicial). Com o Collaborative Lifecycle Management, as equipes ágeis trabalham com diagramas de design no repositório compartilhado. As partes interessadas acrescentam comentários ou marcações sobre os diagramas para a fácil colaboração, mesmo com recursos distribuídos (Figura 9).

Figura 9. Comentários e marcações nos diagramas
Comentários e marcações nos diagramas

A rastreabilidade do ciclo de vida da plataforma CLM oferece insight para a tomada de decisão mais rápida durante um sprint. Os requisitos, recursos de design, tarefas e testes estão ligados para que os profissionais tenham fácil acesso aos artefatos relacionados. Como o desenvolvimento iterativo e incremental leva a um retrabalho constante, as equipes ágeis utilizam o recurso de análise de impacto para entender como uma mudança afeta toda a situação (Figura 10).

Figura 10. Artefatos do ciclo de vida ligados ao recurso de design New Contribution
Artefatos do ciclo de vida ligados ao recurso de design New Contribution

Um sprint é uma abordagem iterativa e incremental que depende de uma sucessão de testes, codificações e tarefas de refatoração. Uma história do usuário está completa quando as condições de sucesso são alcançadas. As equipes aproveitam as informações de design existentes para entenderem o contexto técnico, encontrarem ativos reutilizáveis, desenvolverem casos de teste adequados ou reduzirem a dívida técnica.


Resumo

O ALM ágil promove a interação entre os requisitos, design, desenvolvimento, projeção e atividades de teste. Utilizando ferramentas leves, as equipes multidisciplinares colaboram e coordenam suas atividades para produzir sistemas intensivos de softwares. Com a adoção dos princípios da arquitetura pragmática, os membros da equipe se concentram no conjunto mínimo de atividades de design necessárias para suportar o desenvolvimento do sistema. Os profissionais ágeis utilizam as informações de design para facilitar a priorização da lista não processada, o planejamento do sprint e o desenvolvimento iterativo.

A solução Rational para o Collaborative Lifecycle Management (CLM) é uma plataforma ALM ágil que oferece colaboração no contexto, planejamento em tempo real, rastreabilidade do ciclo de vida, inteligência de desenvolvimento e melhoria contínua. Com fácil acesso a informações confiáveis e atualizadas, o CLM ajuda as equipes multidisciplinares a serem mais eficientes em seus ambientes ALM ágeis.


Agradecimento

Agradeço imensamente a Fariz Saracevic, Lifecycle Scenario Architect no software IBM Rational, por revisar este artigo e fornecer feedback em cima da hora.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=845428
ArticleTitle=Arquitetura Pragmática para o Gerenciamento de Ciclo de Vida do Aplicativo
publish-date=11162012