Você sabe realmente o que significa Iterativo Incremental?
De certa forma me sinto até meio marginalizado ao falar desse assunto, uma por que já se passaram muitos e muitos anos que todo o método de desenvolvimento de software fala em desenvolver um software de maneira iterativa e incremental. Outra por que os agilistas já fizeram um alarde muito grande em cima do assunto, mas mesmo assim começo achar que ainda existem dúvidas para as pessoas.
Desenvolver um software novo é muito mais fácil do que desenvolver uma solução que substitua um sistema existente e essa complexidade aumenta ainda mais quando estamos falando de arquitetura corporativa. Que seriam sistemas de sistemas e como cada sistema conversa um com o outro, sim você pode usar SOA.
Desenvolvimento Tradicional?
Os agilistas costumam chamar de desenvolvimento tradicional todo método que usa cascata! E com certeza você já ouviu falar que RUP foi muito utilizado em cascata apesar do método não ser cascata! Hoje começo a ver o projetos pelo mercado que são cascata e se dizem ágeis! Não estou falando da ultima caça as bruxas do Scrum; Mas vejo que para variar esse não é um bom nome.
Lembrem-se que hoje agile tem quase 10 anos e o tradicional é agile agora, então a coisa já muda de figura? Cuidado com generalizações pessoal! Ok mas meu ponto aqui é você sabe realmente o que significa desenvolver de forma iterativa e incremental?
Desenvolvimento Iterativo Incremental
Significa não criar um gargalo em cima das disciplinas: Arquitetura, Analise, Design, Implementação, testes, etc... e na verdade paralelizar o trabalho por feature ou requisitos ou até mesmo por estórias. Em fim vamos ter um pipeline onde o trabalho em várias disciplinas vai acontecer em paralelo. Você pode usar um kanban da vida para gerenciar esse fluxo.
Este pipeline teve ter um também um processo de melhoria continua baseado em PDCA como o Scrum por exemplo. Você pode ganhar tempo usando algo como o ScrumBan por exemplo.
Ver o fluxo na parede?
Existe uma grande vantagem de ver o fluxo de desenvolvimento(dashboard), objetivos(BSC, etc...) em uma parede a questão ai são duas: Contextualização e foco. Por que por mais que você tenha esse tipo de coisas em um CMS ou um documento do word ou excel é muito comum você não abrir esse documentos toda hora, mas a parede está lá e você fica todo o dia olhando para ela, essa é uma parte essencial quando falamos em domínio de ambiente.
Isso pode parecer difícil?
Pode! Mas é ai que você deve tomar cuidado! Não pense em muitas funcionalidades de cara! ok ok ok mais ai alguém pode dizer mas se eu não tiver várias funcionalidades eu não consigo entregar valor! OK faça várias mas com o mínimo possível em cada uma.
Uma ferramenta excelente para resolver esse tipo de problema é um bom roadmap de produto, que é totalmente diferente de um backlog. São coisas diferentes, imagine que o backlog tem o escopo mas isso é diferente de se ter um planejamento de release com 3 ou 4 versos programadas para o futuro. Esse plano de release nada mais é que uma prática esquecida da gerencia de configurações que pode ser usada de forma muito útil e efetiva.
A primeira versão
Deve ser muito mais do que uma prova de conceito, porem você deve tentar fazer o mínimo, lembrando que entregas maiores significam mais possibilidades de bugs, mais possibilidades de mudanças no negócio, mais riscos e menos retorno. Quanto menos é melhor nesse caso. Isso não significa que você vai colocar coisas sem valor, isso também não pode acontecer.
Depois nas versões seguintes você vai incrementando o software e colocando novos requisitos, novas implementações e assim por diante. Nada impede você de incrementar a mesma funcionalidade ou requisito fazendo assim uma versão mais básica e depois incrementando essa versão.
O Exemplo do Gmail
A primeira versão do GMail era um email web bem simples, porem eficiente. Depois em outra versão entrou a integração com o google talk, depois em outra versão entrou os temas, depois entrou as propagandas e assim por diante. Assim que devemos fazer, começamos com pouco e depois vamos incrementando as funcionalidades.
Não tente colocar muitas funcionalidades de cara, por que enquanto o sistema não está em produção ele não existe e sendo assim você ainda não obteve lucro/retorno. Colocar o sistema em produção não garante retorno em si só. Por que não? Por que isso depende da qualidade do software, várias entregas problemáticas podem matar a confiança dos usuários no software.
As Atualizações do Windows
Acho que esse é um bom exemplo, tem tanta gente que já passou tantos problemas com isso que muitas pessoas simplesmente não atualizam mais o sistema operacional com medo de gerar novos problemas e isso é péssimo para um produto de software. Ai entra a importância da qualidade em termos de QA e qualidade do produto/qualidade do processo.
