The Waterfall Was Always Wrong

This message was edited 1 time. Last update was at 06/03/2008 01:36:04

Mensagem interessante do Boris Gloger na lista "oficial" de Scrum:

On Thu, Mar 6, 2008 at 4:29 PM, Boris Gloger <boris.gloger@gmail.com> wrote:
>
> Hi,
>
> Bob Schatz and myself gave a training last week in Mechelen. Bob showed
>
> http://gallery.mac.com/borisgloger/100211
>
> us the paper of Winston W. Royce:
>
> MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS
>
> http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
>
> It is absolut clear, after reading this paper -- it is all a big mistake.
>
> Cheers
>
> Boris
>
>
> ----------------------------------------
> Boris Gloger
>
> Scrum - Produkte zuverlässig und schnell entwickeln
> http://www.hanser.de/buch.asp?isbn=978-3-446-41495-2&area=Computer
> ----------------------------------------
>

Algumas empresas ainda insistem em usar este modelo e suas variações, seria interessante um tópico fixo com links e depoimentos do pessoal conhecido, assim todos poderiam consultar e tentar mudar a mentalidade de alguns gestores.

O tópico poderia incluir algumas alternativas para o modelo também.

This message was edited 1 time. Last update was at 06/03/2008 09:36:19

aleck wrote:
O tópico poderia incluir algumas alternativas para o modelo também.

Er... modelo iterativo incremental, aquele que toda empresa que faz RUP finge que adota enquanto faz waterfall e que todo professor finge que ensina na faculdade enquanto o aluno finge que aprende?

pcalcado wrote:Er... modelo iterativo incremental, aquele que toda empresa que faz RUP fine que adota (...)

Fingem mesmo, aqui o processo permite iterações mas elas acabam funcionando como mini-waterfalls.

tnaires wrote:Fingem mesmo, aqui o processo permite iterações mas elas acabam funcionando como mini-waterfalls.

Tipo, pequenas iterações de 6 meses ?

nbluis wrote:Tipo, pequenas iterações de 6 meses ?

Não chegam a tanto, mas duram entre dois e quatro meses.

Agree.

Até em projetos pequenos dá pra ver que é um erro.
Eu nunca usei iterativo incremental, mas gostaria de usar uma vez. Mesmo em projetos pequenos.
Quando li o livro do Sommerville senti que iterativo era ruim, mas depois de ver na prática como ambos funcionam e a data do livro... fiquei impressionado.
Recomendam algum artigo válido?

Tenho uma dúvida: vamos supor que temos um projeto dividido em n iterações. O resultado da primeira iteração foi disponibilizado para o cliente, em ambiente de produção. Então iniciou-se a segunda iteração, e de repente o cliente liga dizendo que encontrou um erro.

Pergunta: e agora? Corrige-se o erro na iteração em andamento? Caso negativo, em qual momento deve-se aplicar as correções?

P.S. - claro que se a iteração for pequena ( uma ou duas semanas ), e envolver poucos requisitos, isso fica mais improvável de acontecer - e mais fácil de lidar.

Dentro da iteração é um pequeno espaço planejado onde o escopo é fixo (escopo somente da iteração corrente). Erros e divergencias encontradas são agendadas. Podem ser resolvidas na terceira, na sexta, na décima. Depende da criticidade do erro.

tnaires wrote:Fingem mesmo, aqui o processo permite iterações mas elas acabam funcionando como mini-waterfalls.

O próprio RUP "ensina" que dentro da iteração é um mini-waterfall, mas não é o mais indicado e não é assim que acontece na prática. Temos iteratividade dentro da iteração. Vou escrever sobre isso no meu próximo artigo.

tnaires wrote:Tenho uma dúvida: vamos supor que temos um projeto dividido em n iterações. O resultado da primeira iteração foi disponibilizado para o cliente, em ambiente de produção. Então iniciou-se a segunda iteração, e de repente o cliente liga dizendo que encontrou um erro.

Pergunta: e agora? Corrige-se o erro na iteração em andamento? Caso negativo, em qual momento deve-se aplicar as correções?

P.S. - claro que se a iteração for pequena ( uma ou duas semanas ), e envolver poucos requisitos, isso fica mais improvável de acontecer - e mais fácil de lidar.

O defeito vira um novo cartão e é tratado como qualquer outro: a equipe estima, o cliente prioriza e ele entra em alguma iteração.

Olá

Que fique claro que este diagnóstico de que desenvolvimento em cascata sempre foi errado é uma análise a posteriori.

Todas as teorias e metodologias evoluem a partir de algumas idéias básicas viáveis de acordo com os recursos disponíveis no tempo em que foram criadas. Antigamente era muito natural se pensar em desenvolvimento em cascata porque os sistemas eram muito mais simples e as dificuldades de desenvolvimento muito maiores. Hoje a gente consegue compilar e testar um sistema várias vezes por dia. Antigamente, às vezes, a gente demorava uma semana para tirar o erros de compilação de um trecho de sistema de 500 ou pouco mais instruções. Cada compilação custava uma fortuna porque hora de mainframe custava muito. Qualquer programinha vagabundo atingia o custo de 10 mil dólares rapidinho. E geralmente o programador era um cara baratinho que só sabia escrever código. Neste ambiente não havia sentido muitas iterações e o que se tentava era aprofundar a análise feita pelo tal do analista de sistemas.

[]s
Luca (que passou por tudo isto e outras coisas mais jurássicas)

This message was edited 1 time. Last update was at 06/03/2008 22:30:03

rodrigoy wrote:

tnaires wrote:Fingem mesmo, aqui o processo permite iterações mas elas acabam funcionando como mini-waterfalls.

O próprio RUP "ensina" que dentro da iteração é um mini-waterfall, mas não é o mais indicado e não é assim que acontece na prática. Temos iteratividade dentro da iteração. Vou escrever sobre isso no meu próximo artigo.

Iteratividade dentro da iteracao no RUP? Pode ate ser que eles tenham definido assim Rodrigo, mas ninguem nunca viu isso acontecer em lugar algum....

This message was edited 1 time. Last update was at 07/03/2008 00:11:05

Paulo Silveira wrote:
Iteratividade dentro da iteracao no RUP? Pode ate ser que eles tenham definido assim Rodrigo, mas ninguem nunca viu isso acontecer em lugar algum....

Lá na lista UML-BR a gente falou sobre isso a uns 2 anos atrás. Se olhar o modelo do RUP a unidade atômica de construção é um caso de uso, se não me engano no EssUP é um cenário (pode ler como user storie). Se uma iteração está definido que serão entregues 10 cenários, cada cenário se torna uma mini-iteração sem entrega para o usuário.

Beleza, aqui no Brasil conheço 5 caras que conhecem o RUP de fato, então, isso é igual a enterro de anão, cabeça de bacalhau, gerente de projeto PMP ágil, cliente feliz em FSW, essas coisas.

[editado - adicionado]

Bem, fora do RUP, no XP também é iterativo dentro da iteração. O Scrum tem um conceito importante que é o pedaço de funcionalidade potenciamente implantável, IMHO isso não é simplemente um UC, uma Story ou um cenário. Talvez um botão "Imprimir" é potencialmente implantável, assim como um bug, ou uma coluna a mais na grid. A maneira como construímos cada pedaço desse é uma iteração dentro do desenvolvimento. Conforme a tecnologia avança, desenvolver esses incrementos é mais rápido e talvez o feedback para os usuários pode ser mais rápido. Talvez no futuro o desenvolvimento seja tão rápido que não precisaremos mais trabalhar iterativamente. O desenvolvimento será real-time.

[/editado]

Luca wrote:
Que fique claro que este diagnóstico de que desenvolvimento em cascata sempre foi errado é uma análise a posteriori.

Depende do que você chama de posteriori. O que muita gente, do profissional junior até o professor da facudlade conceituada, não entende é que o paper original citava o waterfall como anti-pattern e a notícia acima fala do termo waterfall em si, não da prática de waterfall. Como é uma maneira facilmente entendível e aplicável as pessoas acharam que waterfall era algo bom.

Notícias, artigos e o maior fórum brasileiro sobre Java