Escopo Iterativo e Incremental para o Gerenciamento Ágil de Requisitos

Introdução

Um dos primeiros desafios quando se implanta metodologias ágeis, é nivelar qual o entendimento necessário para iniciar um projeto de desenvolvimento de software e como prover uma gestão de requisitos alinhada com a necessidade de entregas e com a aderência necessária dentro de uma organização, portanto, nesse texto pretendo provocar uma reflexão através de alguns conceitos básicos, sobre como que através da filosofia incremental e iterativa das metodologias ágeis, podemos ter um escopo de um produto suficientemente informativo para iniciar e conduzir um projeto de desenvolvimento do mesmo.

 

Visualizando o problema inicial em alto nível

Uma prática bem interessante e bastante salutar nesse processo de concepção de produtos é o entendimento em “linhas gerais” de qual é o problema de fato, para qual se deseja criar uma solução, então para ilustrar esse cenário, vou fazer uma breve comparação com o nosso cotidiano.

Portanto, vamos trabalhar com exemplo fora da área de TI, então imagine que você é um construtor de móveis e alguém lhe apresenta o problema exposto na Figura 01 como necessidade para criação de um novo produto.

clip_image002
Figura 01 – Visão com a necessidade abrangente para um produto.

 

Visualizando a solução inicial em alto nível

Agora que você já conhece de maneira abrangente qual a necessidade que o produto irá resolver, conforme mostra a figura 02, podemos iniciar a visualização em alto-nível da possível solução para essa necessidade.

Observe que esse desenho representa uma visão ampla, que dá dimensão do que será construído, porém essa visão está livre dos pequenos detalhes, ou seja, nesse momento pode ser um desperdício de recursos tentar conhecer os pequenos detalhes de cada área do escopo, portanto veja que no nosso exemplo, basta sabermos que a nossa solução terá um encosto, um assento e pernas.

clip_image004

Figura 02 – Visão inicial com a solução em alto nível

 

Validação da visão em alto nível junto ao cliente

Outro grande princípio ágil é o feedback constante para garantir uma contínua inspeção e adaptação, porém uma das formas de obter esse feedback é através da participação ativa do cliente (ou alguém que o represente) durante todo o projeto.

Dessa forma, conforme mostra a figura 03, será possível validar se a idéia de solução que fora imaginado está de acordo com a necessidade apresentada pelo cliente.

clip_image006
Figura 03 – Validação da visão inicial de solução para a necessidade do cliente

 

Incrementando de forma iterativa o conhecimento sobre o escopo

Após validar que a solução estava de acordo com a necessidade, agora podemos mergulhar um pouco mais no detalhamento do escopo, assim o cliente pode expor mais detalhes sobre o mesmo, dessa forma, um dos primeiros detalhes importantes, era haver mobilidade ao usar esse produto, então dentro do tema perna da cadeira, foi solicitado algo que permitisse mover-se ao usar esse produto.

Portanto, o foi descoberto que o cliente iria precisar do item rodinhas mostrado na figura 04 logo na primeira versão do produto.

clip_image008

Figura 04 – Item adicionado para entender um pouco mais o escopo da primeira versão.

Assim, o resultado dessa primeira versão, foi pernas de cadeira com rodinhas para locomoção, semelhante ao mostrado na figura 05 abaixo.

clip_image010

Figura 05 – Primeira Versão do Produto

Em seguida, na segunda versão do produto, foi descoberto que no encosto e no assento, o cliente desejaria bastante conforto ao usar esses temas, então fora adicionado o detalhe almofada para atender essa necessidade, conforme exibido na figura 06.

clip_image012
Figura 06– Item adicionado para entender um pouco mais o escopo da segunda versão do produto.

Portanto, o resultado dessa segunda versão do produto, foi uma cadeira, com rodinhas nas pernas e com acolchoamento no encosto e no assento, semelhante ao exibido na figura 07.

clip_image014

Figura 07 – Segunda Versão do Produto contendo acolchoamento.

Dando continuidade na evolução iterativa do produto, conforme mostra a figura 08, foi descoberto que o cliente irá usar o produto em um ambiente de trabalho, portanto, será necessário ter dentro do tema assento, um apoio para os braços para assegurar certa ergonomia durante o seu uso no trabalho.

clip_image016
Figura 08 - Item representando a necessidade de ergonomia ao usar o produto.

Sendo que com esse último detalhamento do desejo, o produto final foi uma cadeira, com rodinhas nas pernas e com acolchoamento e com apoio para os braços na base do assento de acordo com o mostrado na figura 09.

clip_image018
Figura 09 – Versão Final do Produto

 

Resumindo

Observe que o produto foi ao encontro das necessidades que o cliente fora descobrindo a cada iteração e mediante cada feedback do produto e, dentro do verdadeiro espírito Lean, não criamos nada além do que o cliente realmente precisava naquele produto e no tempo certo de sua necessidade.

Isso fez com que o cliente recebesse valor agregado do produto a cada ciclo, aumentando então a sua percepção de qualidade com relação ao produto.

Conforme mostra a figura 10, veja que esse comportamento, é possível devido ao fluxo básico que os processos ágeis promovem, para gerar um entendimento que nasce numa visão em alto nível e o suficientemente ampla acerca do escopo e vai sendo detalhada de forma incremental através das iterações ao longo de um projeto.

clip_image020
Figura 10 – Fluxo básico proposto pela agilidade

É importante observar que esse modelo, segue uma forma de pensamento que realmente existe no mundo real e desperta a possibilidade de um maior alinhamento com o contexto de negócio que aquele escopo está inserido.

Algumas implementações de metodologias ágeis como XP (Extreme Programming) e FDD (Feature Driven Development), endereçam diferentes nomes para essa visão, por exemplo, num universo mais voltado para o XP, é comum existir a visão de Temas e Épicos, que são usados para representar os desejos de clientes em alto nível e tanto essa visão de Tema quanto a visão de Épico, serão detalhados de forma agrupada ou desmembrada em Estórias menores a serem trabalhadas numa iteração. Já a FDD, trata esse alto nível de entendimento usando a visão de Áreas e Atividades para compor uma FBS (Feature Breakdown Structure) contendo o conjunto de funcionalidades agrupadas por Atividades de Negócios e que por sua vez, estão agrupadas por suas respectivas Áreas dentro do negócio.

Já projetos que estejam usando Scrum como metodologia para gerenciamento do ciclo de desenvolvimento de um produto, podem aplicar qualquer uma das dessas visões, pois como já é de conhecimento de todos, o Scrum não endereça um tratamento específico de questões relacionadas à engenharia de requisitos, tornando então totalmente factível o uso de Scrum aliado com XP ou FDD para o desenvolvimento de software.

 

Conclusões

Como você pode observar, esse texto forneceu uma visão bem fundamental de como as metodologias ágeis como Scrum, XP e FDD, tratam a evolução de um escopo dentro de um projeto ágil de desenvolvimento de software.

Observe também que essa visão é oriunda da herança que os processos ágeis têm dos conceitos Lean, onde através desse pensamento, o desenvolvimento de um produto, satisfaz exatamente a necessidade de hoje do seu cliente, evitando que tenhamos a famosa síndrome de Nostradamus, onde na tentativa de “surpreender” o cliente, criamos soluções com detalhes que ainda não foram solicitados, só por achar que no futuro, por ventura o mesmo poderia necessitar de um determinado recurso.

Por isso, é muito importante que esse artigo, o estimule a pensar em novas formas de criar produtos que mais cedo possível, agreguem valor dentro de seu negócio ou do seu cliente, minimizando então, o desperdício em seus projetos de desenvolvimento. Muito obrigado e até a próxima!

 

 

Sobre o autor:

Manoel Pimentel, CSP

Manoel Pimentel, CSP

É Engenheiro de Software, com 15 anos na área de TI, atualmente trabalha como Coach em Agile, Lean e TOC para empresas do segmento de serviço, financeiro e bancário. É Diretor Editorial da Revista Visão Ágil e Editor Chefe da InfoQ Brasil, Já escreveu sobre agile para importantes portais e revistas do Brasil e exterior e Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Contatos: manoel@visaoagil.com

About these ads

28 thoughts on “Escopo Iterativo e Incremental para o Gerenciamento Ágil de Requisitos

  1. Muito legal esse exemplo, já mostrei aos meus diretores aqui da empresa e funcionou muito bem para entenderem como funciona o processo incremental.

    Ótimo trabalho.

  2. Ontem mesmo estava lendo sobre RUP e agora fiz uma comparação de como não precisamos ir à Lua para entender o que o cliente quer.

    Parabéns.

  3. Manoel, excelente sua percepção, fantástica para uso imediato em equipes que precisam entender como trabalhar com estratégias emergentes direcionada a escopos incrementais e iterativos.

    Vamos em frente!

  4. Olá Manoel,

    Entrei recentemente, na verdade ontem, na lista da revista. Não conhecia o seu trabalho, tomei conhecimento pela iniciativa que está sendo realizada no C.E.S.A.R EDU em Recife (o rss), onde você marcará presença na próxima semana. Eu trabalho no C.E.S.A.R como Engenheira de Qualidade de Software.
    Bem, achei muito didático o seu texto, o exemplo apresentado facilita o entendimento, mas um ponto crítico relacionado a requisitos / features se faz presente em um nível anterior ao gerenciamento dos requisitos; o desenvolvimento. Notei que durante todo o texto você usou a frase: “Foi descoberto que o cliente…” exatamente esse processo de descoberta é muito complexo dependendo do projeto por n motivos: desconhecimento do negócio por parte da equipe, dificuldade do cliente em apresentar suas necessidades, complexidade do negócio, imaturidade de ambos os lados, … Você planeja escrever algo sobre isso? Técnicas para identificação das necessidades do cliente?
    Parabéns pelo excelente trabalho!
    Abraços
    Andrea Pinto

    • Olá Andrea,

      Obrigado pelo seu comentário.

      Em minha participação lá no RSS (C.E.S.A.R), falarei um pouco sobre essas questões também, então vamos poder conversar bastante sobre esse assunto, ok?

      Mas de imediato, posso lhe falar que acredito que esse processo de descoberta é algo de fato muito crítico desde a época em que usávamos JAD para esse tipo de imersão junto ao cliente.

      Infelizmente, não posso dizer que com agile esse problema acaba, o que acontece, é que essa complexidade da descoberta dos desejos é significativa minimizada, pois através das práticas ágeis, somos estimulados a ter uma mudança de atitude entre o cliente e a equipe.

      Essa mudança de atitude ocorre em várias esferas, principalmente no conteúdo e na forma como o escopo é tratado.

      Já existem alguns textos, palestras e vídeos (ver http://visaoagil.wordpress.com/2008/08/14/modelagem-agil-na-tdc-2008/) publicados aqui mesmo em nosso Blog, que tratam de algumas técnicas relacionadas à modelagem ágil e como ela pode ajudar nesse processo de aprendizagem acerca dos escopos, mas pretendo assim que possível escrever outros artigos abordando essas técnicas.

      Como o Felipe mencionou em sua resposta, podemos usar a TOC (Teoria das Restrições), não só para dirimir conflitos, mas também podemos usar para auxiliar no processo de raciocínio baseado em causa e efeito nesse desafio da descoberta dos desejos dos clientes.

      Obrigado a todos.

  5. @Manoel
    Parabéns pelo artigo. Muito bom.

    @Andrea,

    Essa descoberta citada no texto acontece durante um processo de exploração da situação junto ao cliente. Uma vez que o cliente está presente durante o planejamento, podemos aprovietar dessa presença para, através de diálogo, encontrar os requisitos “ocultos”.

    Essa abordagem é prevista em vários conceitos, inclusive em DDD. A primeira versão é algo superficial e serve apenas para colocar a equipe num caminho (nem sempre certo). A evolução (do processo evolutivo) é exatamente a descoberta de quando corrigir o caminho.

    Em alguns casos, pode-se também usar TOC para ajudar na resolução dos conflitos.

    Grande Abraço,

    Felipe

  6. Obrigada Felipe e Manoel pelas respostas :) Manoel, infelizmente não participarei da sua apresentação no RSS, mas com certeza entrarei em contato com quem participar :) Obrigada pela sugestão de leitura, fico no aguardo então de mais artigos sobre esse assunto com a mesma abrodagem didática que você utilizou nesse artigo.

  7. Artigo muito interessante, Manoel!! No entanto, como lidar com situações como essas:

    “Beleza, vamos fazer só isso porque é o que o cliente está precisando agora, mas se ele pedir aquela outra funcionalidade depois, teremos um grande trabalho. Se fizermos agora, o trabalho será bem menor…”

    Às vezes, nós pensamos em fazer logo uma determinada funcionalidade com medo de que, se o cliente pedir depois, o trabalho será muito mais complexo.

    • Olá Paulo, Muito Obrigado pelo comentário.

      Lembre-se que para gerar valor o mais cedo para cliente, é interessante que sigamos a priorizaçao estabelecida por ele no Backlog de funcionalidades a serem implementadas. Claro que podemos ajudar o cliente a descobrir essas funcionalidades e, também como será o critério de priorização a ser usado.

      Em agile é possível que a ordem de priorização do cliente seja negociada em função de dependências técnicas, mas nesse caso, há um alinhamento junto ao cliente de que na iteração vigente, será entregue valor de negócio menor, em função da necessidade real de implementar questões técnicas que serão importantes durante todo o projeto.

      Outra dimensão importante a analisar é sobre a ótica da simplicidade da solução, pois é interessante que tentemos manter nossa solução mais simples possível sobre pelo ponto de vista técnico, para que não gastemos muito recurso na implementação de uma solução complexa demais, sem entregar funcionalidades de agreguem valor ao cliente.

      Abraços,

      Manoel Pimentel

  8. @Paulo

    Vale lembrar que nesse caso, se o cliente não pedir, ele terá pago por algo que não precisa, portanto é importante apresentar isso pra ele e ele decide o que deve ser feito. É um trade-off que tem que ser devidamente explicado para o cliente.

  9. Pingback: Living Blog » Blog Archive » Requisitos e SCRUM

  10. Pingback: Visão Ágil marcará presença na RSS’2009 « Blog Visão Ágil

  11. Pingback: ADSystems » Projetos ágeis - Levantamento Inicial

  12. Olá Manoel, tudo bem?

    Primeiramente parabéns pelo ótimo artigo sobre Metodologia Ágil. Gostaria de saber se você tem algum artigo ou recomendação de livro sobre gerência de projetos ágeis?
    Pois estou fazendo uma monografia sobre esse assunto, e preciso de material.

    Fico no aguardo da resposta.

    Atenciosamente,

    Almiro Alves

  13. Excelente artigo! Estou fascinado com o estudo de processos ágeis!
    Manoel, sou aluno do mestrado em ciências da computação na Universidade Federal do Ceará e mandei um e-mail para você.Aguardo ansioso o contato!

  14. Excelente artigo, trabalho em uma instituição financeira e temos um problema que é a validação dos requisitos, talvez seja o template utilizado que não é muito didatico, já que realizamos o registro dos registros e documentos em formato de Ata de reunião.

    Gostaria de saber se vc utiliza algum modelo para validação e também para alteração dos requisitos, andei pesquisando na internet porém ainda não localizei um que seja de fácil aplicação.

  15. Pingback: Escopo, o inimigo do sucesso | Jeveaux's Weblog

  16. Pingback: Agile FAQ #3: O que você prefere? Uma mentira ou software funcionando no início de um projeto? « Blog Visão Ágil

  17. Pingback: Práticas ágeis são o caminho para a qualidade de software?

  18. Pingback: TecNews: Noticias Tecnofagia

  19. Pingback: Escopo, o inimigo do sucesso :: Tutoriais CTDO - Sua Base de Tutoriais Online

  20. Pingback: Projetos ágeis – Levantamento Inicial | Blog Lambda3

  21. Pingback: Corta Conta – uma aplicação completa em Android | Parte 3 – Análise de Requisitos | Espectro de Petrogrado | Thiago Baptista

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s