Mensagem interessante do Boris Gloger na lista “oficial” de Scrum:
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.
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?
Fingem mesmo, aqui o processo permite iterações mas elas acabam funcionando como mini-waterfalls.
Tipo, pequenas iterações de 6 meses ? :lol:
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.
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.
[quote=tnaires]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.[/quote]
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)
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.[/quote]
Iteratividade dentro da iteracao no RUP? Pode ate ser que eles tenham definido assim Rodrigo, mas ninguem nunca viu isso acontecer em lugar algum… 
[quote=Paulo Silveira]
Iteratividade dentro da iteracao no RUP? Pode ate ser que eles tenham definido assim Rodrigo, mas ninguem nunca viu isso acontecer em lugar algum… :([/quote]
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]
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.
Vocês, engenheiros de software, usam Modelagem de Software, quando usam metodologias de desenvolvimento ágil (tipo a iterativa incremental)?
Olá
Exato. Até porque as tarefas e responsabilidades eram completamente separados. Analista só analisava, programador só codificava e o usuário/cliente sempre era um chato.
[]s
Luca
Ser iterativo é um valor ágil, assim, todas as metodologias ágeis são iterativas. Nem todos os processos de desenvolvimento iterativos são necessariamente ágeis.
Nós modelamos sim, mas na maioria das vezes:
- Modelamos focando o código e não o modelo
- Modelo é só para ajudar a ter uma idéia
- Não consideramos modelos artefato (não mantemos na nossa configuração), jogamos a maioria dos modelos fora
- Não gastamos $$$ em ferramentas caras
- O uso do modelo é homeopático
- Não precisa ser em UML
- Huguinho faz caso de uso, Zezinho faz o UML, Luisinho codifica dá nojo para a maioria dos agilistas (eu principalmente)
- O código também é modelo
- Dá pra fazer um modelo mentalmente
- Modelagem = Alguns Minutos, Implementação e Teste = Algumas Horas