| Feb 08 |
Entrega Cascata VS Entrega IncrementalAlow Brasil !!! Voltando a postar minhas idéias por aqui Acho que nos últimos meses, tivemos algumas situações bem interessantes que baseiam uma boa análise sobre este assunto. Vamos lá então. Primeiro, é preciso conceituar os dois modelos: Entrega Cascata e Entrega Incremental. Entrega Cascata: Parte do principio que o projeto é dividido em fases estensas com cada uma focada numa área de conhecimento da engenharia de software. Em geral, os modelos mais comum parecem com isso:  Modelo waterfall padrão Neste modelo, as fases do projeto são divididas e as entregas são feitas ao final de cada fase, separando-se os entregáveis geralmente em:
Pode-se também adotar uma estratégia de quebrar a fase de desenvolvimento em vários releases ou entregas parciais, que podem ou não ser focadas em módulos funcionais do sistema. Este modelo apresenta alguns princípios básicos que o norteiam do início ao fim:
Existem outras características que até são importantes, mas não vou abordar agora, ok? Acho que essas já definem bem o modelo. Entrega Incremental Parte do princípio que o projeto é desenvolvido contando-se com o aprendizado funcional e técnico do cliente e das pessoas envolvidas. Possui tempo x custo fechados, mas aceita e encoraja melhorias e alterações no escopo para entregar um produto melhor ao final do projeto. Em geral, um modelo incremental é bem parecido com isso:  Modelo padrão incremental O projeto todo é dividido em releases e a cada entrega os envolvidos têm a chance de avaliar e dar feedback para que haja melhoria no proximo release. As disciplinas de engenharia de software são absorvidas dentro da construção de cada release, não estando em fases separadas. Uma caracteristica muito importante neste modelo é que um time é obrigatoriamente composto por profissionais multidisciplinares, pois o trabalho é multidisciplinar. Os princípios básicos que o norteiam este modelo são:
Também existem outras características importantes neste modelo, mas que não precisam ser ditas agora. Bom, uma vez que conceituamos os dois mundos, vamos analisar no que isso impacta quando falamos num projeto de software: Geralmente, tanto o cliente quanto a equipe de desenvolvimento estão acostumados a receber/entregar código-fonte e/ou programas funcionando somente no final do projeto. Isso traz uma falsa percepção de andamento, fornecida pelo famoso “%” de conclusão das tarefas. A verdade é que enquanto não existe software funcionando, não dá pra dizer que algo no projeto andou de fato. Isso é um dos motivos para afimarmos que uma estratégia de “GANT” não serve para projetos de software. Pois bem, as pessoas estão acostumadas a terem um projeto rodando muito bem do começo até a hora do “QA” ou ciclo de testes ao final da etapa de desenvolvimento. Com isso, o stress do projeto fica sempre para o final e a capacidade de se tomar decições corretivas ou de estabilização fica totalmente comprometida. Afinal, ficamos com pouco tempo hábil para corrigir os problemas de um projeto inteiro na hora do teste, certo? Por outro lado, quando trabalhamos com desenvolvimento incremental, o stress que aconteceria no final do projeto vem para o começo. Isso é bom sob a ótica de gestão do projeto, pois temos uma tendência de melhorar a cada iteração. MAS, nem tudo são flores. O grande problema, é que em geral o cliente não está preparado para ter stress logo no início de um projeto. Ele acaba achando que se as coisas estão ruins no começo, a tendência será sempre de piora e não de melhora. Isso faz com que o nível de stress e desconfiança fique insuportável e em muitos casos com que a estratégia de entrega incremental fique inviável tanto para o cliente quanto para o time, pois as pessoas do time também não conseguem desenvolver um trabalho com o stress, pressão e desconfiança do cliente a todo instante. Certa vez, ouvimos de um cliente: “Nossa, mas vocês estão sendo transparentes demais com os problemas do projeto. Isso está errado, nós não queremos saber dos problemas de vocês. Contratamos um projeto e ele deve ser entregue, independente dos problemas…” O fator de falha aqui está na cultura da contratação e na relação cliente x fornecedor. Se o cliente sabe do problema, automaticamente se torna responsável pela solução e ninguém quer ter problemas para resolver, mesmo que um dia eles venham puxa-lo pro buraco. Em resumo, em alguns casos vemos que a “ilusão” de um projeto andando bem e que a falsa percepção de evolução é mais importante para o cliente do que ver software funcionando ou saber dos problemas para trata-los. Afinal, enquanto os problemas estão debaixo do tapete, fica muito mais fácil de não se comprometer e ao final jogar a culpa do fracasso no time de projeto. Num caso como esse, deve-se repensar se realmente uma estratégia de entrega incremental agrega ao projeto. Em alguns casos, vamos ver que a única saída será o “bom e velho” Waterfall… E você, o que pensa a respeito? Qual o melhor modelo de entregas na sua opinião? Grande abraço !!! André Nascimento 11 Responses to “Entrega Cascata VS Entrega Incremental”Leave a Reply |
Uma das coisas que estavam na fila é abordar um pouco as diferenças entre um projeto com entregas de escopo ”programado” e um projeto com entregas incrementais de software.-
Search
Muito interessante. De qq forma, tem que pensar se vale fazer o projeto assim, sabendo que haverá problema e stress no final. Já vi empresas (fornecedores) recusando projetos por que o cliente queria trabalhar de forma cascata. É uma questão de escolha, e cultura. Parabéns pelo artigo.
Obrigado pela visita e pelo comentário Rafael.
Sim, a questão é sempre cultural, por isso o foco quando se fala em agilidade tem que ser sempre cultural. O maior problema é que ninguém quer perder $$$ e no final acabamos tendo que atender esse tipo de projeto. Enquanto a mentalidade de quem contrata não mudar, vai ser cada vez mais difícil.
Grande abraço
André Nascimento
Olá André!
Primeiramente parabéns pelo artigo! Você abordou de forma muito clara e objetiva a diferença fundamental entre cascata e iterativo: a entrega adiantada e contínua de software de valor.
Só para complementar, tenho vivenciado vários modelos de desenvolvimento iterativo fracassando por causa da cultura do cliente. Empresas mais “corp” não costumam gostar de entregas freqüentes pois isso dá muito “stress” logo no começo do projeto como você citou. Demanda deles uma maior participação no projeto, definições difíceis que tem que ser feitas e claro, lidar com riscos e problemas.
Isso sem falar no maravilhoso modelo de contratação com o escopo, prazo e custo fixos. As vezes isso me parece mais uma busca de um fornecedor para votar a culpa do que vontade de resolver os
Olá André!
Primeiramente parabéns pelo artigo! Você abordou de forma muito clara e objetiva a diferença fundamental entre cascata e iterativo: a entrega adiantada e contínua de software de valor.
Só para complementar, tenho vivenciado vários modelos de desenvolvimento iterativo fracassando por causa da cultura do cliente. Empresas mais “corp” não costumam gostar de entregas freqüentes pois isso dá muito “stress” logo no começo do projeto como você citou. Demanda deles uma maior participação no projeto, definições difíceis que tem que ser feitas e claro, lidar com riscos e problemas.
Isso sem falar no maravilhoso modelo de contratação com o escopo, prazo e custo fixos. As vezes isso me parece mais uma busca de um fornecedor para votar a culpa do que vontade de resolver os problemas.
Abs.
Infelizmente é verdade a posição de alguns clientes quanto a não querer se envolver nos problemas. Aliás, em alguns casos nem todos estão efetivamente comprometidos com o sucesso do projeto e ocorre politicagem ruim…
Já ouvi coisas como: vcs entregam aos pouquinhos e me obrigam a testar várias vezes. Não entendo isso. Estamos acostumados a receber e testar tudo no final e é assim que funciona!
Precisamos evoluir a cultura de quem compra software, urgentemente.
Abraços e parabéns pelo post!
Marcelo Zeferino
Boa tarde, não sei realmente qual é a natureza do “problema” aparecer antes no modelo incremental. Na verdade eu só enxergo um problema nos dois modelos. Em cascata vc só vai saber se está certo o projeto que vc construiu, se as funcionalidades operam de acordo com o solicitado pelo cliente e sem erro. O problema nesse caso são as funcionalidades não ficarem de acordo. E ai vem correria pra correção e crises com o cliente, que esperou sei lá 6 meses e ainda não recebeu o que pediu. A proposta do modelo incremental, é ir desenvolvendo o básico, COM QUALIDADE, de acordo com a necessidade do cliente e ir incrementando a aplicação, até que o produto final seja terminado. Isso na verdade minimiza os problemas pois em todo o desenvolvimento vc passa a ter contato com o cliente, em pequenos “sprints”, e se vc desenvolver problemas, ai o problema é seu mesmo. pois deixando claro o modelo de desenvolvimento do projeto com o cliente e isso estando acordado, não há problema. Além do que o cliente já pode ir desfrutando da aplicação desde o básico até o final, sempre tendo a certeza que o projeto está em andamento. Além disso você vai tendo o feedback do cliente se o desenvolvimento das funções está no caminho certo ou não. minimizando drasticamente que você desenvolva problemas para o cliente (funcionalidades não compatíveis com o especificado).
sugiro a leitura do manifesto ágil, para entender sobre desenvolvimento agil. http://agilemanifesto.org/iso/ptbr/
Oi Rodrigo,
A questão do problema aparecer antes no modelo incremental é boa, óbvio, como eu disse no artigo. O que eu quis abordar é que em geral o cliente não suporta quando esses problemas aparecem, porque ele não quer saber de problemas para o lado dele.
Ora, problemas existem, não há como negar. Querer que um time de software entregue tudo sem nenhum problema é no mínimo um sonho. A diferença é que esses problemas que acontecem no modelo iterativo criam uma situação insustentável entre cliente e time, geralmente porque o cliente não quer se comprometer em resolvê-los.
É claro que a obrigação do time é entregar software com qualidade e diminuir ao máximo a ocorrência de problemas. MAS, no mundo real, projeto sem problemas isso não existe. A diferença está na forma como cliente e equipe trabalham juntos para sairem dos problemas.
Esse tipo de postura que é difícil de achar, principalmente no cliente.
PS: Não entendi sobre a indicação de leitura do manifesto. Foi algum “sarcasmo” ou eu falei algo que feriu o manifesto?
Abs,
André Nascimento
André, muito bom o post e acho legal a forma transparente como você coloca os problemas da sua equipe em ambiente de outsourcing ágil.
Vou ser beeem sincero com você: cada vez menos acredito que um contrato por projeto escape de todos esses problemas que você falou. Atualmente tenho visto um movimento grande de empresas contratando body shop e buscando mesmo assim modelos ágeis. Agilidade não é uma otimização local no desenvolvimento. Se você não deixar regras claras sob quem está demandando e sob quem irá fazer rollout (aka pessoal de infra) a value stream sempre sofrerá esses vieses.
Abraços e vamos discutir hoje no HHA…
Opa, obrigado pela visita e pelo comentário
Concordo com você. Na verdade, nós chegamos juntos aqui a conclusão de que existem fatores que são pré-requisitos fundamentais pra se trabalhar com Agile em outsourcing e que simplesmente não dá pra abrir mão.
Estamos trabalhando pra implementar isso, porque sinceramente hoje, na maioria dos cenários querer usar Scrum ou Agile com outsourcing não funciona…eheheh
Abs e até daqui a pouco.
André Nascimento
Opa André, não foi sarcasmo não. Eu escrevo seco mesmo.
Com certeza eu entendi o que você propôs no post. Mas acredito que faltou um pouco mais de clareza ao expressar as diferenças entre as metodologias.
Você mencionou o outsourcing com a questão do desenvolvimento ágil nos comentários também.
Eu trabalhei em algumas grandes empresas em São Paulo, nas duas pontas, sendo a empresa de outsourcing, e sendo o cliente que contrata o outsourcing. E a minha opinião sobre isso é: outsourcing é a forma mais enganadora de vender projetos com a desculpa de que o que não faz parte do core business da empresa deve ser terceirizado.
Vivenciei desde pequenos projetos que não atenderam as expectativas dos clientes, até projetos gigantescos como o sistema de gestão de uma grande empresa na área de saúde suplementar, que após 4,5 anos de projeto teve que ser colocado no ralo, após milhões de reais investidos.
Eu acredito no INsourcing, pois um software nada mais é do que uma ferramenta que auxilia o teu processo de negócio.
Se você não está inserido no contexto do negócio, dificilmente você capta todas as nuances do processo, todos os problemas do processo, para desenvolver um projeto que realmente atenda as necessidades do cliente.
No outsourcing não existe modelo agil, nem incremental, pelas questões financeiras envolvidas. Portanto fecha-se um pacote com o escopo e vai ser aquilo, não tem mudanças e os projetos não fluem. Fora todas as reuniões de discussões para incluir change requests no projeto que desgastam a relação com o fornecedor, porque o cliente não aceita sem a mudança e o fornecedor diz que não tá no escopo e que vai demandar mais investimento.
Acredito que é possível trabalhar com empresas terceiras, desde que os responsáveis e a equipe de desenvolvimento do projeto estejam inseridos ali, no core do cliente, pra conhecer exatamente o que devem fazer. E isso se faz muito mais facilmente com o desenvolvimento ágil.
abraços e desculpe a má impressão do meu “direct mode” de escrever.