Qual é a diferença entre o desenvolvimento iterativo e incremental?
Nas minhas aulas de formação, reparo frequentemente que os alunos confundem o desenvolvimento iterativo e incremental (IID). O objetivo deste artigo é proporcionar uma compreensão da relação entre o desenvolvimento incremental e o iterativo.
Começarei com uma comparação entre uma abordagem em cascata e uma abordagem ágil, utilizando o exemplo da entrega de uma aplicação de pagamentos. Está também incluído um minisseminário online correspondente sobre estas abordagens. Na segunda parte deste artigo, posicionarei as abordagens em cascata e ágil numa matriz que mostra a interseção entre o desenvolvimento incremental e o iterativo, explicando os quatro quadrantes da matriz.
Ágil vs. Cascata: o desenvolvimento de uma aplicação de pagamentos
A abordagem em cascata
Se esta aplicação for desenvolvida de acordo com um modelo tradicional em cascata, podem observar-se os seguintes passos na figura 1.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Figura 1: Este diagrama mostra um ciclo de vida típico em cascata, utilizando o exemplo da entrega de uma aplicação.
Iniciação do projeto
Tudo começa com um patrocinador do projeto do departamento de marketing, que conseguiu disponibilizar os fundos necessários para esta aplicação. Partia do princípio de que a aplicação iria melhorar a retenção de clientes e a entrada de novos clientes. Visualizou três grupos de funções de alto nível.
Depois de o projeto ser aprovado, é atribuído um gestor de projeto e é criada uma equipa de projeto. Após muitas discussões e sessões de trabalho de recolha de requisitos, chegou-se a um acordo para entregar uma aplicação de pagamentos com 250 funcionalidades. Todas estas funcionalidades são registadas num documento de requisitos de software extenso e muito detalhado, assinado pelo patrocinador do projeto e pelo representante do cliente (bem como por outras partes interessadas importantes).
Fase de conceção do projeto
No passo seguinte, a equipa de projeto traduz os requisitos numa conceção para a aplicação. O arquiteto verifica a conceção face aos princípios de conceção. Verifica também se todos os atributos de dados necessários estão disponíveis no sistema de retaguarda.
Já passaram dois meses e o cliente ainda não viu nada a funcionar, apenas alguns relatórios de progresso. E é provável que estes relatórios de progresso envolvam algum tipo de relatório «melancia», deixando o cliente sem perceber se o projeto está ou não no caminho certo.
Fase de desenvolvimento do projeto
São necessários seis meses para desenvolver a aplicação e, quando isso está concluído, é pedido ao representante do cliente que disponibilize algumas pessoas que possam ajudar a realizar um teste de aceitação do utilizador. Durante o teste, torna-se claro que várias funcionalidades não estão a funcionar.
A equipa de projeto não compreende porquê. É exatamente o que estava descrito no documento de requisitos. Isto conduz a muitas discussões, retrabalho e atrasos, e os clientes não estão satisfeitos com os resultados. Além disso, se analisarmos o resultado final, poderemos notar que muitos dos requisitos desenvolvidos não são utilizados pelo cliente ou são raramente utilizados.
A situação poderia ser ainda pior. Suponhamos que o desenvolvimento da aplicação demorou 1,5 anos e que outro banco entrega uma aplicação de pagamentos quando ainda está a meio do trabalho. O que faria nesse momento? Continuaria a ter um caso de negócio viável para prosseguir e concluir a sua própria aplicação?
Analisando a figura 1, torna-se claro que, com uma abordagem em cascata, o âmbito e os critérios de qualidade subjacentes são fixados através de uma única entrega. Todos os passos são executados uma vez para todo o projeto e o controlo da gestão está centrado no custo e no tempo. A entrega de valor ao cliente só ocorre após a implementação da aplicação completa.
A abordagem ágil
Se desenvolvermos a aplicação utilizando uma abordagem ágil de gestão de projetos, observamos o seguinte padrão:
- A equipa de desenvolvimento afirma que consegue entregar as duas primeiras funcionalidades priorizadas pelo responsável pelo produto na primeira iteração.
- A equipa de projeto entrega um incremento do produto a cada três semanas (ciclo de trabalho, iteração ou período delimitado).
- Após as primeiras entregas ou incrementos, vemos um cliente que confia que o projeto será entregue. Já tem uma aplicação funcional e compreende que nem todas as funcionalidades estão disponíveis, mas as que estão funcionam.
Ao analisarem a versão mais recente e as funcionalidades disponibilizadas, mencionam uma funcionalidade completamente nova. Uma funcionalidade que ninguém tinha em mente no início do projeto, mas que poderia tornar a vida do cliente mais produtiva.
Após cada incremento, o retorno do cliente resulta em novas capacidades funcionais (que não constavam da lista original) ou em ajustes de funcionalidades potenciais. O produto torna-se cada vez mais maduro. A cada incremento, o cliente recebe uma nova versão e fica mais satisfeito.
Figura 2: O diagrama mostra o ciclo de desenvolvimento ágil, utilizando o mesmo exemplo da entrega de uma aplicação.
Se analisarmos a figura 2, vemos um fluxo constante de entregas ao longo de uma duração fixa e utilizando equipas ágeis permanentes (estes são custos fixos). O âmbito e os critérios de qualidade subjacentes são flexíveis (dinâmicos), com pequenas entregas frequentes (estes são os incrementos).
Todos os passos destinados à entrega de uma funcionalidade ou história de utilizador são executados repetidamente (tornando o processo iterativo) até que a qualidade necessária seja alcançada. O controlo da gestão centra-se na entrega de valor ao cliente. A entrega de valor ao cliente ocorre após cada implementação de um incremento.
Cascata vs. Ágil: Resultados da entrega
Se analisarmos mais atentamente os dois produtos, tanto o modelo em cascata como a abordagem ágil de desenvolvimento de software, vemos um produto com 250 funcionalidades e um cliente pouco satisfeito, e um produto com apenas 150 funcionalidades e um cliente muito satisfeito (ver figura 3).
Figura 3: Este diagrama compara as diferenças no tempo, no número de funcionalidades e na satisfação do cliente entre as abordagens em cascata e ágil.
E, se analisarmos ainda mais detalhadamente o produto entregue pela abordagem ágil, vemos apenas um subconjunto de 100 funcionalidades da lista original e 50 funcionalidades novas ou ajustadas. Isto está de acordo com alguns princípios importantes do Manifesto Ágil, incluindo:
- Simplicidade, a arte de maximizar a quantidade de trabalho que não é realizado: apenas 150 funcionalidades em vez de 250
- Acolher a mudança dos requisitos, mesmo numa fase avançada do desenvolvimento: adaptação ao feedback do cliente após cada iteração e incremento
Os processos de desenvolvimento ágil aproveitam a mudança para obter uma vantagem competitiva para o cliente (foram entregues 50 funcionalidades novas ou ajustadas). E, como resultado, o cliente fica muito satisfeito. A maior prioridade da equipa é satisfazer o cliente através da entrega antecipada e contínua de sistemas de software valiosos.
Miniwebinário: Entrega em cascata vs. ágil
Eis um breve webinário com mais informações sobre as diferenças entre a entrega em cascata e a entrega ágil.
Diferenças entre o desenvolvimento iterativo e incremental
Agora que expliquei as diferenças entre uma abordagem em cascata e uma abordagem ágil, utilizando o exemplo da criação de uma aplicação de pagamentos, vou posicionar a cascata e o ágil numa matriz que compara o desenvolvimento iterativo e incremental.
Como último passo, vou desenvolver o conceito de produto mínimo viável (MVP) e de produto mínimo comercializável (MMP), e mostrar onde estes se enquadram nas diferentes abordagens e num mapa de histórias. Incluí também um miniwebinário correspondente.
Matriz do desenvolvimento iterativo e incremental
Como referi, reparei que os estudantes confundem frequentemente os conceitos de iterativo e incremental. Na figura 4, pode encontrar quatro quadrantes, resultantes de uma linha horizontal que representa o desenvolvimento incremental ou não incremental e de uma linha vertical que representa o desenvolvimento iterativo ou não iterativo. Veja este vídeo do YouTube para consultar uma versão muito simples desta figura.
Figura 4: Esta matriz mostra diferentes abordagens de desenvolvimento e se os membros das equipas que seguem essas abordagens precisam de iterar e/ou trabalhar em incrementos.
Quadrante inferior esquerdo
No canto inferior esquerdo, vemos a abordagem em que não existem iterações nem incrementos. Esta é a abordagem em cascata. Todas as atividades (conceção, análise, construção, testes e implementação) são realizadas uma única vez para todo o projeto.
Neste caso, vemos uma única entrega do produto final com base num âmbito fixo. O valor para o cliente só pode ser alcançado após a entrega do produto final. Um dos principais objetivos desta abordagem é gerir os custos.
Quadrante inferior direito
No quadrante inferior direito, vemos uma abordagem incremental sem iterações. Trata-se de uma entrega faseada ou incremental de partes mais pequenas do produto. Todas as atividades de uma determinada fase (conceção, análise, desenvolvimento, testes e implementação) são realizadas uma única vez.
Dentro de uma determinada fase, o âmbito é fixo, mas o produto total baseia-se num âmbito mais dinâmico ou flexível. O valor para o cliente pode ser alcançado após cada entrega do produto. Um dos principais objetivos desta abordagem é a rapidez de entrega.
Quadrante superior esquerdo
No quadrante superior esquerdo, vemos uma abordagem espiral ou iterativa sem incrementos. Trata-se de uma única entrega em que o produto final é criado através de várias iterações. Um bom exemplo desta abordagem é o pensamento de design. No gráfico, vê-se uma sequência das atividades de definição, análise, geração de ideias, concretização e reflexão.
Esta sequência será realizada repetidamente ou de forma iterativa, aproximando-se, em cada iteração, do produto final, correto ou necessário. Em muitos casos, este produto final é um protótipo ou modelo. Nesta abordagem espiral, temos um âmbito dinâmico ou flexível. O valor para o cliente só pode ser alcançado após a entrega do produto final. Um dos principais objetivos desta abordagem é a correção da solução.
Quadrante superior direito
No quadrante superior direito, vemos a abordagem ágil, que utiliza incrementos e um método iterativo. O Scrum é um bom exemplo desta abordagem.
No final de cada incremento, frequentemente chamado sprint ou período fixo, é entregue um incremento do produto. Este incremento é o resultado de muitas iterações para desenvolver partes pequenas, mas corretas, frequentemente chamadas histórias de utilizador ou itens da lista de pendências do produto. O projeto iterativo final será entregue peça a peça.
Nesta abordagem ágil, temos um âmbito dinâmico ou flexível. O valor para o cliente pode ser alcançado após cada entrega do produto. Um dos principais objetivos desta abordagem é o valor para o cliente através de entregas frequentes e do retorno dos utilizadores.
MVP ou MMP?
Na figura 4, também pode encontrar os acrónimos MVP e MMP. MVP significa produto mínimo viável e é uma versão de um novo produto ou serviço que permite a uma equipa recolher o máximo de aprendizagens sobre os clientes e obter validação com o mínimo esforço. O MVP do serviço Dropbox era um simples vídeo. Isto significa que o P em MVP poderia ser um produto completamente diferente daquele que acaba por ser o produto final.
Um exemplo que ilustra o MVP e o MMP
Costumo utilizar o seguinte exemplo de um novo produto financeiro. Um diretor comercial entusiasta tem uma excelente ideia relativamente a um novo produto financeiro. Pensa que conseguem vender pelo menos 100 000 destes produtos.
Juntamente com alguns especialistas financeiros, concebem o produto em alguns meses. É atribuída uma equipa de desenvolvimento e esta demora 4 meses a desenvolver o produto. Em paralelo, são desenvolvidos folhetos comerciais e o produto é lançado com um grande evento.
Infelizmente, apenas algumas pessoas compram o produto. Se seguirmos a abordagem MVP, poderemos partir do pressuposto de que 10% dos utilizadores da página Web estão interessados neste produto. Desenvolveríamos então um MVP para testar esta hipótese.
Neste caso, o MVP poderia ser um simples botão na página inicial. Se clicar, é apresentado um ecrã com uma mensagem relativa a este novo produto e a opção de adicionar o seu endereço de e-mail caso esteja interessado. Suponha que menos de 1% dos visitantes carregou no botão — o produto não seria desenvolvido e a empresa teria poupado muitos recursos escassos.
Se analisarmos mais atentamente a figura 4, vemos a utilização potencial de MVP em todos os quadrantes. Ao utilizar uma abordagem em cascata, poderia criar um MVP na primeira fase de conceção do software para verificar se existe uma justificação comercial para o projeto.
O mesmo pode ser feito na primeira fase do primeiro incremento quando se segue uma entrega faseada. Em alguns casos, o resultado da sua abordagem de pensamento de design poderia ser um MVP. O MVP também poderia ser benéfico no início de uma abordagem ágil.
Muitas pessoas consideram que o primeiro produto entregue no final da sua entrega faseada é o MVP. Poderá ser esse o caso, mas, na maioria das situações, não se trata de um MVP, mas sim de um MMP. MMP, ou produto mínimo comercializável, é o produto mais pequeno capaz de proporcionar valor ao seu cliente.
Como é a entrega ágil?
Agora que está claro que os modelos incrementais e os modelos iterativos não são iguais e que compreendemos a utilização de MVP e MMP, podemos explorar com mais detalhe o aspeto da entrega incremental e iterativa.
Provavelmente já viu o famoso exemplo de Jeff Patton sobre a Mona Lisa, em que a pintura é criada peça a peça (entrega faseada). Outra forma de abordar esta situação é começar pelo primeiro incremento, no qual é criado apenas um esboço rudimentar, e, a cada nova iteração, adicionar mais detalhes ao esboço, até obter, em última análise, a pintura final (entrega incremental e iterativa ou entrega ágil).
Na primeira situação, já deve ter uma ideia detalhada do produto final; na segunda situação, basta ter um esboço de alto nível, uma vez que é muito mais fácil efetuar alterações. Se analisarmos a figura 5, vemos um mapa de história para um novo produto chamado ABC.
Figura 5: Um exemplo de mapa de histórias para um produto específico.
O proprietário do produto idealizou sete funcionalidades para este produto. As primeiras quatro funcionalidades são indispensáveis. As funcionalidades 5 e 6 são desejáveis e a última funcionalidade é opcional. Muitos chamariam a isto priorização MoSCoW (indispensáveis, desejáveis, opcionais e a não implementar).
Cada funcionalidade, por si só, pode ser dividida em partes mais pequenas. Na figura, vê funcionalidades ou histórias de utilizador classificadas como indispensáveis, desejáveis e opcionais. Uma funcionalidade pode ser indispensável, mas isso não significa que todas as histórias de utilizador subjacentes também o sejam. Ou uma funcionalidade pode ser desejável, mas, se implementar essa funcionalidade, algumas histórias de utilizador são indispensáveis e outras são desejáveis ou opcionais.
Para implementar este produto ABC, vê cinco incrementos ou versões. A primeira é o produto mínimo comercializável. Este MMP consiste nas duas primeiras histórias de utilizador indispensáveis da funcionalidade 1 e nas primeiras histórias de utilizador indispensáveis das funcionalidades 2 e 3.
A versão 2 contém as duas histórias de utilizador indispensáveis seguintes das funcionalidades 1, 2 e 3 (desenvolvimento iterativo). O desenvolvimento do produto prossegue com a implementação das versões seguintes. A cada versão, o valor para o cliente aumenta.
Após a versão 5, o proprietário do produto deixa de implementar histórias de utilizador. O feedback do cliente mostrou-lhe que o produto ABC era ‘adequado à finalidade’ e, tendo em conta o princípio da simplicidade do Manifesto Ágil, deixa de desenvolver o produto.
Mini seminário online: desenvolvimento iterativo e incremental
Eis um seminário online aprofundado sobre desenvolvimento iterativo e incremental de software.
Considerações finais
A sua equipa de desenvolvimento de software tem bem claro o que são o desenvolvimento iterativo e incremental? Como os está a aplicar às suas metodologias ágeis ou em cascata?
Partilhe connosco nos comentários ou aderir ao nosso programa de subscrição DPM e discuta com outros membros no nosso fórum exclusivo!
