BT

Modelagem Ágil: aperfeiçoando a comunicação e a compreensão - Parte 1

Postado por Lee Ackerman , traduzido por Mário Henrique Trentim em 07 Dez 2011 |

Estatísticas alarmantes mostram que os projetos de TI chegam a custar 400% mais que o previsto, realizando apenas 25% dos benefícios prometidos. Embora pesquisas do Standish Group mostrem alguma melhora neste quadro, estamos ainda muito longe do sucesso em projetos de TI.

Podemos classificar o fracasso dos projetos em duas categorias :

  • Técnico:
    • A solução não atende aos requisitos do projeto (escalabilidade, performance, confiabilidade, custo etc.);
    • Devido aos desafios técnicos, prazos são ultrapassados, até que os patrocinadores perdem a confiança e encerram o projeto.
  • Funcional:
    • A equipe não compreende os requisitos fornecidos;
    • Os requisitos fornecidos não são os requisitos corretos.

Parte dos problemas se deve a um pensamento simplista de causa e efeito entre os domínios do problema e da solução. Acredita-se que, compreendido o problema, basta encontrar uma solução.

A Modelagem Ágil é coerente com o Manifesto Ágil e seus princípios. Portanto, é uma prática que pode fazer parte do seu repertório de ferramentas ágeis.

Entretanto, os atuais projetos de TI são maiores em escopo, custo e prazo, além de serem mais complexos, envolvendo muitos sistemas e departamentos de uma ou mais empresas. A compreensão do problema e da solução caminham juntos, ou seja , à medida que são propostas soluções, compreend e-se melhor o problema.

Esse processo iterativo de análise nos domínios do problema e da solução é ainda mais complexo do que a visão simplificada anterior, por envolver divers a s partes interessadas com pontos de vista e capacidades de compreensão diferentes.

A figura acima resume as causas de fracasso do ponto de vista funcional mencionadas no início. E o fracasso funcional é uma das grandes causas dos fracassos técnicos. Portanto, as seguintes dimensões são cruciais para o sucesso nos projetos:

  • Compreensão
    • Compreendemos o domínio do problema?
    • Compreendemos o domínio da solução?
    • Compreendemos a transição entre esses dois domínios?
  • Comunicação
    • As partes interessadas são capazes de comunicar os requisitos para aqueles que irão desenvolver a solução?
    • Os membros da equipe que desenvolverá a solução são capazes de comunicar os detalhes da solução entre eles?
    • A equipe de desenvolvimento é capaz de comunicar os desafios e alternativas para as partes interessadas? 

Os ideais básicos d o Agile (manifesto , princípios e bom senso) surgiram da necessidade de reforçar as dimensões de compreensão e comunicação.

A figura anterior ilustra o Manifesto Ágil, em que (nunca é demais lembrar), indivíduos e interações são mais importantes que processos e ferramentas; responder a mudanças é mais importante que documentação; colaboração com o cliente é mais importante que negociação de contratos; e que software funcionando é mais importante que seguir um plano.

Embora a m odelagem seja uma técnica importante em desenvolvimento de softwarem inclusive em metodologias ágeis, frequentemente é subestimada ou mal entendida. Na luta contra o desenvolvimento centrado em processos burocráticos e contra o desenvolvimento baseado em ferramentas, a modelagem acabou sendo atacada também. Precisamos corrigir essa má impressão.

Um bom começo é defini ção de modelagem. Basicamente, a modelagem é a simplificação da realidade. Não significa utilizar determinada notação, ferramenta ou processo. A modelagem permite compreender e focar nos aspectos importantes, sem detalhes desnecessários.

Considerando essa definição de modelagem, podemos avançar e descrever a ideia de modelagem ágil. Em modelagem ágil, adotamos uma abordagem ágil usando modelos que nos auxiliam a compreender e comunicar.

Destacamos abaixo alguns aspectos de Modelagem Ágil:

  • O processo de modelagem e os modelos suportam comunicação e compreensão.
  • A Modelagem Ágil busca criar modelos simples usando ferramentas simples. Adote a simplicidade.
  • O foco é entregar software, não modelos. Modelos devem ser usados quando e onde adicionam valor. Se eles não agregam valor nem nos auxiliam no sentido de entregar software funcionando, então não devem ser utilizados.

  • Modelos devem ser mantidos pelo tempo necessário. Se um modelo serviu ao seu propósito e deixa de ser necessário, jogue fora. Isso permite manter a agilidade sem burocracia. Por outro lado, se seu modelo pode ainda ser útil, guarde ou recicle.
  • A Modelagem Ágil utiliza múltiplos modelos para diferentes perspectivas, níveis de abstração e públicos. Cada modelo é criado a partir de um objetivo e para satisfazer determinado público.
  • A M odelagem Ágil combina de modelos formais e informais conforme a situação, público-alvo e objetivos. Por exemplo, um modelo poderia ser composto de formas simples desenhadas a lápis ajudando o essencial de um sistema, ou utilizando diagramas detalhados de classes do UML.

Conclusões

Para valorizar pessoas e suas interações é preciso fortalecer a comunicação. Em vez de investir em novas ferramentas ou adotar processos prescritos, sugerimos uma abordagem diferente, a Modelagem ágil. A utilização de métodos de modelagem facilita a compreensão do problema e da solução, além de melhorar a comunicação entre os stakeholders e resposta a mudanças.

Na segunda parte deste artigo, veremos com mais profundidade os princípios, valores e práticas de Modelagem ágil.


Referências

  1. AgileModeling.com : Excelente fonte de consulta sobre modelagem, criada por Scott Ambler.
  2. Disciplined Agile Delivery - Website comunitário sobre práticas ágeis.

 

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.