TCC: Scrum e XP vs Cascata

Assuntos Gerais Agile
#1

Boa noite.

Estou desenvolvendo meu TCC sobre o tema “Scrum e XP vs Cascata” e estou com um problema: não encontro nenhum livro onde o desenvolvimento em cascata seja descrito com algum detalhe e que o autor não vá logo dizendo que cascata é ruim. O que eu queria onde o desenvolvimento em cascata fosse descrito igual nas tradicionais aula de engenharia de software das faculdades. Já verifiquei vários livros e não achei nada de interessante. Alguém tem alguma sugestão de livo?

Outra coisa que gostaria é, se possível, conversar com pessoas que tem contato com XP e/ou Scrum e saber sobre as dificuldades encontradas, os problemas, os benefícios, se realmente vale a pena a utilização de metodologias ágeis, etc.

Só mais um pedido, alguém conhece algum livro sobre Scrum em português que não seja “Scrum e XP Direto das Trincheiras”? Pelas pesquisas que fiz parece que ninguém ainda se interessou em escrever um livro sobre Scrum no Brasil.

Desde já agradeço.

#2

Durante a faculdade aprendi sobre o CRC e RUP. Apesar de os professores dizerem que era interativo em incremental, aquilo era desenv cascata de forma descarada.

Trabalho hj com SCRUM em minha empresa e tb ensino na prática em meu curso. Lá a metodologia foi passada de forma muito prática, tendo sua descrição apenas umas 3 páginas. Para mim a metodologia se assemelha totatalmente com técnica administrativa moderna (PDCA - Plan Do Control Act). Além disso o sprint curto te faz ficar focado, e o controle gráfico do burndown rate te mostra no ato se vc está atrasado ou não. Juntando o scrum com algumas dicas do Get Real, como prototipação e lançamento rápido para o cliente são se mostraram uma forma produtiva de desenvolvimento pra mim.

Infelizmente sou um cara mais de prática, então não conheço livros pra te indicar, mas espero ter ajudado de alguma forma.

#3

Oi.

Não existe praticamente nenhuma metodologia em cascata. Especialmente hoje em dia.

Usei XP por 5 anos, e o Scrum estou usando há 2 anos. O XP é interessante, mas achei que ele dá menos benefícios que o SCRUM. Acho que o pair programming é super-valorizado.
Ok, há um ganho de produtividade e qualidade em se produzir em par para uma ou outra tarefa, mas para atividades do dia-a-dia, não creio que esse ganho compense o fato de estar gastando dois profissionais no lugar de um só.

Quase não vi pontos negativos em métodos ágeis. Geralmente é bastante fácil modificar software e o ganho de comunicação gera benefícios extremos. O usuário pode definir melhor o que quer a medida que conhece o que o software pode fazer por ele, ao mesmo tempo, a equipe pode esclarecer dúvidas antes que elas virem um monstro implementado. Melhor que isso, o usuário sente-se seguro em não pedir coisas, antes de ter uma visão clara do que quer (e isso é especialmente notável quando a sensação de que se deixar para pedir depois ele nunca terá o requisito implementado acaba).

Existem algumas discussões bastante longas aqui no GUJ sobre esse tema, e o tópico geralmente recai em flame (principalmente quando algum usuário desinformado insiste em chamar o RUP de processo em cascata). Um deles, por exemplo, é esse aqui: http://www.guj.com.br/posts/list/209473.java

#4

[quote]Oi.

Não existe praticamente nenhuma metodologia em cascata. Especialmente hoje em dia.

Outra coisa que gostaria é, se possível, conversar com pessoas que tem contato com XP e/ou Scrum e saber sobre as dificuldades encontradas, os problemas, os benefícios, se realmente vale a pena a utilização de metodologias ágeis, etc.

Usei XP por 5 anos, e o Scrum estou usando há 2 anos. O XP é interessante, mas achei que ele dá menos benefícios que o SCRUM. Acho o pair programming, na minha opinião, são super-valorizados.
Ok, há um ganho de produtividade e qualidade em se produzir em par para uma ou outra tarefa, mas para atividades do dia-a-dia, não creio que esse ganho compense o fato de estar gastando dois profissionais no lugar de um só.

Quase não vi pontos negativos em métodos ágeis. Geralmente é bastante fácil modificar software. Existem algumas discussões bastante longas aqui no GUJ sobre esse tema, e o tópico geralmente recai em flame (principalmente quando algum usuário desinformado insiste em chamar o RUP de processo em cascata). Um deles, por exemplo, é esse aqui: http://www.guj.com.br/posts/list/209473.java [/quote]

O Vini te falou tudo amigo, não confunda metodologia com aplicação do processo.
Eu não lembro de ter estudado a respeito de nenhuma metodologia que pregue o desenvolvimento sistema em cascata como algo sustentável a longo prazo.

O próprio mecanismo de evolução no ciclo de vida do sistema já caracteriza um processo iterativo, ao meu ver isso está independente de metodologia e muito mais relacionado aos valores e práticas que a equipe de desenvolvimento aplica.

Ao meu ver as metodologias ágeis não são interessantes por proporem um modelo iterativo, mas por tornarem isso uma condição essencial para a aplicação do processo fornecendo mecanismos, práticas e principalmente valores que te forçam a pensar a respeito do processo.

Aplicar conceitos e práticas como: small releases, projéteis luminosos, team empowerement, honest plans, most important features, unit test, do not repeat yourself além de uma serie de outros conceitos, fazem com que você constantemente pense a respeito do seu processo e é nesse ponto que uma metodologia ágil te fornece ferramentas para controle e melhoria desse processo.

Bom, resumindo, acho que dificilmente você encontrará livros encorajando o desenvolvimento de software em cascata (inclusive se você encontrar por favor compartilhe conosco).
Acho mais fácil você tentar focar sua tese na aplicação de processo ágeis ou não. Comparando, porque tal metodologia é ágil e porque outra não parece ser (ou definitivamente não é).

Edits: erros de português…nossa :frowning:

#5

@renzonuccitelli ajudou sim, muito obrigado.

@ViniGodoy, @PedroTOliveira, se eu entendi direito, o que vocês querem dizer com “Não existe praticamente nenhuma metodologia em cascata” é que o que nos ensinam na faculdade sobre metodologia cascata é apenas teoria, e que na prática o que se aplicam são processos baseados nessa teoria, estou certo? Sendo assim, como poderiamos então chamar esses métodos?

@PedroTOliveira eu não quero exatamente um livro que encoraje o desenvolvimento em cascata, mas sim um em que explique o desenvolvimento em cascata sem tomar partido de nenhum lado, e seria bom também uma explicação do surgimento da metodologia em cascata. Não quero defender a metodologia em cascata pois mesmo antes de tomar conhecimento sobre metodologias ágeis eu não gostava da cascata. Vou pegar hoje um livro que talvez tenha o que quero, depois posto aqui qual o livro.

No mais, foi muito bom ver opiniões de que não existem metodologias puramente cascata sendo utilizadas na prática.

Mito obrigado a todos, e quem tiver mais experiências a contar ficarei agradecido se compartilharem.

A correção ortográfica do Firefox me ajuda bastante nisso 8)

#6

Primeiro de tudo.

Uma metodologia é um conjunto de práticas. O XP, por exemplo, define o ciclo de desenvolvimento, como as pessoas se organizam, como testes devem ser feitos, como o tempo deve ser medido, etc. O mesmo faz o SCRUM e qualquer metodologia baseada no processo unificado, como o RUP.

“Cascata” não é uma metodologia. É apenas uma única prática, relacionada ao ciclo de desenvolvimento. Não especifica nada sobre como documentos devem ser organizados, sobre como garantir qualidade no processo, ou sobre como mapear requisitos. Uma prática bem antiga, por sinal, que foi abolida praticamente ao mesmo tempo que nasceu.

Nenhum processo, seja hoje ou há mais de 20 anos atrás, preconiza o uso do ciclo de desenvolvimento em cascata. Mesmo processos mais ortodoxos, como o RUP, falam em ciclos iterativos, de no máximo 2 meses de desenvolvimento.

Por isso, siga a sugestão do Pedro. Compare um processo ágil com um iterativo, mas não ágil. Aí sim, você terá processos nos dois casos. Será difícil encontrar um processo sequer que use o desenvolvimento waterfall. A primeira vez que o modelo foi descrito, em 1970 por Winston W. Royce, ele já foi descrito como falho, como você pode ver aqui: http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

Um bom livro sobre processo unificado (que é iterativo, mas não ágil) é o do Craig Larman: Utilizando UML e Padrões.

#7

Cascata não foi feito pra software, você pode até encontrar empresas que fazem cascata em software, mas não utilizam uma metodologia. Da mesma forma que você pode encontrar empresas que fazem processos incrementais e interativos em desenvolvimento de software mas não tem metodologia. E também que usem processos ágeis fora do desenvolvimento de software.

#8

Hoje em dia que todo mundo virou iterativo e incremental, o termo cascata é utilizada para denominar processos não-ágeis, principalmente RUP e seus derivados (alguém conhece outros?).

Mas confesso que não é um ponto de vista amplamente aceito, principalmente consultores dessas metodologias que por motivos pessoais rejeitam terem o termo “cascata” associado ao seu “produto” a todo custo.

#9

Tiago,
fazendo um adendo ao que o vini disse e reforçando:

A iteração no desenvolvimento de software vai além da metodologia.
A iteração é um processo inerente do negócio. Se seu negócio evolui o seu software tem que evoluir por meio de iterações.

O fato de você ter aprendido o desenvolvimento de software na faculdade de forma não iterativa, acho que está mais relacionado ao método de ensino do que o que ocorre no mundo real.

Entenda que até o lançamento final de uma melhoria do produto, iterações em diversos níveis da hierarquia são realizadas, e em alguns casos utilizando até metodologias diferentes da metodologia utilizada pela equipe de desenvolvimento de software.

Leia esse post do Paul Dyson e você vai entender o que eu quis dizer com:
"Acho mais fácil você tentar focar sua tese na aplicação de processo ágeis ou não. Comparando, porque tal metodologia é ágil e porque outra não parece ser (ou definitivamente não é). "

Em poucas palavras… O que você deve procurar comparar é…Ágil ou Não Ágil!

#10

Pessoal, valeu pelas dicas.

O livro que disse que ia pegar que atendia melhor o que eu queria é esse: http://bit.ly/aR0DVv.

To tentando seguir mais ou menos a linha que vocês indicaram, comparar ágil com não ágil.

To precisando de algum caso de sucesso de utilização de metodologias ágeis, alguém tem alguma dica? Interessante se fosse a de vocês mesmos.

Abrigado a todos.

#11

[quote=marcosalex]Cascata não foi feito pra software, você pode até encontrar empresas que fazem cascata em software, mas não utilizam uma metodologia. Da mesma forma que você pode encontrar empresas que fazem processos incrementais e interativos em desenvolvimento de software mas não tem metodologia. E também que usem processos ágeis fora do desenvolvimento de software.

[/quote]

Eh o que eu penso tambem sobre cascata. Eh bastante usado ainda, bastante mesmo, mas ninguem que usa sai proclamando aos quatro ventos que faz.

O motivo é simples, quem usa waterfall na verdade nao usa nada e acaba fazendo tudo por intuição. E a intuição vai nos dizer que devemos primeiro levantar todos os requisitos, depois planejar bem o que deve ser feito, detalhar tudo num projeto bem formado, pra só depois implementar e finalmente testar. Estando tudo ok, entregamos o produto e ficamos todos felizes. Simples assim, nos diz a tal da intuição.

Qualquer um que dedique um pouco do seu tempo para estudar metodologias vai descobrir logo que waterfall nao funciona, seja atraves da literatura, seja através de uma analise cuidadosa dos processos com quais trabalha.

Ou seja, voce nao vai encontrar nenhuma literatura sobre waterfall porque ninguem que estuda o assunto indica waterfall, embora essa ainda seja em muitos lugares a metodologia “default”.

#12

[quote=YvGa]Eh bastante usado ainda, bastante mesmo, mas ninguem que usa sai proclamando aos quatro ventos que faz.

O motivo é simples, quem usa waterfall na verdade nao usa nada (…)[/quote]
É exatamente isso.

Você não vai encontrar um Cascata Development Book, mas é a realidade na maioria das empresas. O motivo é simples, o pensamento cascata parece a forma mais natural de se fazer as coisas ao contratar uma consultoria externa. Escreve-se os requisitos bem detalhadamente, ambos assinam propostas e contratos beeeem detalhados para se “protejer” um do outro. E como o negócio principal do cliente não é TI ele não quer ficar acompanhando e testando durante o processo - “entregue-me o quando estiver pronto pois tenho mais o que fazer!”

É comum que para garantir a “qualidade” o cliente também exija uma enorme pilha de documentos. Com bastante detalhes, é claro.

Em minha opinião é uma relação nociva, em que não há parceria. É como no dilema dos prisioneiros da teoria dos jogos - de tanto um querer ganhar mais que o outro, ambos saem perdendo.
Veja um texto interessante aqui: http://www.objectzilla.com.br/2009/01/27/existe-dicotomia-entre-prazo-e-qualidade/

Minha sugestão para o autor do tópico é: procure incluir em sua pesquisa entrevistas com profissionais do mercado, isso lhe dará uma visão do que é o desenvolvimento em cascata. Essa realidade não está nos livros. :frowning:

#13

[quote=tiago_stos]Pessoal, valeu pelas dicas.

O livro que disse que ia pegar que atendia melhor o que eu queria é esse: http://bit.ly/aR0DVv.

To tentando seguir mais ou menos a linha que vocês indicaram, comparar ágil com não ágil.

To precisando de algum caso de sucesso de utilização de metodologias ágeis, alguém tem alguma dica? Interessante se fosse a de vocês mesmos.

Abrigado a todos.[/quote]

Opa Tiago,

Duas fontes que lembro rapidamente que contém casos de sucesso na aplicação de métodos ágeis:

No livro Scrum and XP from trenches
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

O livro Getting Real dos criadores do Ruby on Rails cita alguns casos também.
http://gettingreal.37signals.com/GR_por.php

[]'s

#14

Tem também os clientes que tentam forçar os fornecedores a um processo cascata, já que é certeza que ele vai errar o preço pra baixo e acreditam que daí podem ganhar com isso no preço, já que muito escopo só vai entrar depois, mas o preço já foi fechado antes.

#15

[quote=mochuara]Hoje em dia que todo mundo virou iterativo e incremental, o termo cascata é utilizada para denominar processos não-ágeis, principalmente RUP e seus derivados (alguém conhece outros?).

Mas confesso que não é um ponto de vista amplamente aceito, principalmente consultores dessas metodologias que por motivos pessoais rejeitam terem o termo “cascata” associado ao seu “produto” a todo custo.
[/quote]
O RUP nunca foi “cascata”, o que aconteceu há algumas décadas em software foi que fizeram uma relação muito próxima e equivocada de engenharia de software com engenharia civil, então se partiu da prática que para construir um grande sistema deveria seguir as práticas que se usavam pra construir um prédio, dai vem a aplicação do processo cascateado para construção de sistemas, e a necessidade de se ter previamente tudo resolvido antes de colocar um tijolo, quero dizer, escrever uma linha de código.

Ai gente que foi formado com 100% de influência da engenharia civil, pegava o RUP, que por mais burocrático que seja, é um processo iterativo e incremental, e fez dele um cascatão gigante, onde o mundo todo praticamente só o souber usar assim.

E não se enganem, tem muita, mas muita empresa mesmo fazendo mini-cascata com Scrum e XP, achando que estão fazendo muita coisa diferente de RUP. Como diz o Yoshima, “agilidade é inspeção e adaptação”, e sem isso não importa o nome que vc use, não será um processo ágil eficiente.

[]s

#16

Não adianta discutir isso com o Mochuara, Luiz. Ele não dá ouvido a qualquer tipo de argumento, nem cita qualquer tipo de autor, exceto ele mesmo…

#17

Henrik, o autor desse livro, deu diversos workshops e ajudou a gente a implementar Kanban aqui na empresa. Muito bom esse livro, recomendado.

//Daniel

#18

[quote=PedroTOliveira][quote=tiago_stos]Pessoal, valeu pelas dicas.

O livro que disse que ia pegar que atendia melhor o que eu queria é esse: http://bit.ly/aR0DVv.

To tentando seguir mais ou menos a linha que vocês indicaram, comparar ágil com não ágil.

To precisando de algum caso de sucesso de utilização de metodologias ágeis, alguém tem alguma dica? Interessante se fosse a de vocês mesmos.

Abrigado a todos.[/quote]

Opa Tiago,

Duas fontes que lembro rapidamente que contém casos de sucesso na aplicação de métodos ágeis:

No livro Scrum and XP from trenches
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

O livro Getting Real dos criadores do Ruby on Rails cita alguns casos também.
http://gettingreal.37signals.com/GR_por.php

[]'s[/quote]

O livro Scrum e XP direto das trincheiras eu já li, e o Getting Real iniciei a leitura a algum tempo atrás e não terminei, preciso voltar a lê-lo. Realmente muito bom os dois livros.

#19

[quote=YvGa]
O motivo é simples, quem usa waterfall na verdade nao usa nada e acaba fazendo tudo por intuição. E a intuição vai nos dizer que devemos primeiro levantar todos os requisitos, depois planejar bem o que deve ser feito, detalhar tudo num projeto bem formado, pra só depois implementar e finalmente testar. Estando tudo ok, entregamos o produto e ficamos todos felizes. Simples assim, nos diz a tal da intuição.[/quote]

Eu realmente discordo de que cascata é intuitivo. A única coisa intuitiva é sobre entregar tudo de uma só vez, mas mesmo assim isso não é uma regra. Quando comecei a desenvolver alguns projetos pessoais, sem ter nenhuma noção sobre metodologias e processos de desenvolvimento, o mais intuitivo era pegar algumas poucas ideias e começar a desenvolver, ajustando a direção conforme o desenvolvimento avançava. Após terminar essa parte do sistema, pegava outras ideias e começava de novo. Acredito que isso seja mais próximo de um processo ágil do que de cascata.

Quando comecei a ver sobre a metodologia cascata logo pensei “isso não pode dar certo, não é nada prático”. Ao conhecer as metodologias ágeis achei o processo algo muito mais natural de se seguir do que cascata (e por isso tenho estudado sobre metodologias ágeis). Conversando com várias pessoas e lendo vários artigos na internet vejo que a maioria das pessoas pensam assim, as metodologias ágeis são muito mais intuitivas de serem seguidas do que cascata.

#20

Se cascata virou termo para referenciar o anti-pattern que é especificar todo o sistema antes de implementar como isso é diferente de RUP e seus documentos de requisitos?