Já há quem fale sobre a obsolescência das iterações como as conhecemos. Um dos maiores “culpados” por esse novo movimento é uma prática antiga da produção just-in-time: o Kanban. Mas este texto não é para falar de coisas tão novas assim. Isso aqui é sobre como boa parte da indústria ainda nem digeriu a idéia que veio antes: as iterações.
Mas espera aí. Todo mundo usa iterações, não?
Bom, na verdade não. Como podemos observar a partir de alguns relatos bem recentes, desenvolvimento de software em cascata ainda é realidade em muitos lugares. Pode parecer uma realidade bem distante para você, mas é algo bem próximo para essas pessoas. Tão próximo e tão incômodo que elas tomaram o tempo de sentar-se e escrever sobre o assunto. O pessoal do 1up4Developers até dedicou um site inteiro a isso. Eles deviam estar verdadeiramente sofrendo quando começaram isso.
A triste realidade é que não é tão incomum assim encontrar organizações onde uma “iteração” normalmente dura seis meses e onde é terminante proibido tocar em uma única linha de código enquanto a equipe não atravessar oficialmente a “fase de requisitos” (e talvez mais algumas outras fases depois dela). O pior é saber que o modelo da cascata nasceu somente como contra-exemplo (pdf), algo que deveria ser evitado tanto quanto possível. Não sei que seqüência de eventos esdrúxula consegue levar um modelo de contra-exemplo fabricado a prática padrão de toda uma indústria, mas foi o que aconteceu.
Felizmente, já existe uma solução para isto e ela, sem muita surpresa, atende pelo nome de iteração. Não iterações de seis meses para camuflar um processo em cascata, mas iterações de verdade que permitam feedback rápido e adaptação a mudanças. Antes que possamos começar a tornar as iterações obsoletas, precisamos apresentá-las a quem ainda não as conhece. Mais importante ainda: a quem acha que as conhece mas nunca viu nada além de desvirtuações do conceito.
Podemos até mesmo começar com cascatas iteradas. Já que eles parecem gostar da cascata, dividiremos os projetos em cascatas menores com entregas de software real ao final de cada ciclo. Todo mundo continua trabalhando do mesmo modo de sempre, mas agora os prazos para cada fase e o escopo da iteração como um todo serão reduzidos. A diferença é que os clientes terão software para observar mais cedo, algo real e bastante vivo que possam usar como base para novas idéias ao invés de serem obrigados a fazer especulações baseadas em documentos mortos. Certamente não é o ponto a que queremos chegar, mas quem disse que ia ser fácil?
Uma questão essencial para esta estratégia é o tamanho das iterações. Cascatas iteradas muito longas seriam somente casos especiais do processo de desenvolvimento anterior. Seis meses certamente é muito tempo e três meses ainda parece muito. A partir de um mês de duração começamos a conversar. Ainda é bastante longo, mas, novamente, é só um ponto de partida.
Depois disso o próximo passo provavelmente deve ser mostrar como representações intermediárias podem ser ineficientes. Novamente o encolhimento das iterações deve nos ajudar. Prazos de um mês já devem estar suficientemente difíceis de cumprir quando se tem representações intermediárias para criar e as equipes provavelmente já começaram a eliminar as práticas mais ineficientes neste ponto. Encolher as iterações para quinze dias deve dar conta de eliminar a maioria das ineficiências restantes. Você simplesmente não consegue produzir porções significativas de software funcionando se tiver que escrever treze documentos e aprovar cinco solicitações de mudança pra cada linha de código que precisar alterar.
Quando chegarmos a este ponto, será que deveríamos parar aí? A beleza deste processo de encolhimento das iterações é poder continuar diminuindo-as. Iterativamente, se você me permite. O limite será alcançado quando em uma iteração couber somente um requisito. Neste ponto, a única maneira de continuar encolhendo as iterações é encolher os próprios requisitos, tornando-os cada vez mais simples e atômicos.
Mas será que sua organização vai ter coragem para chegar lá?
Muito bom o post, Thiago !
Valeu por ter mencionado o 1up4Dev ! Somente adicionando mais informações … além do sofrimento da equipe, o 1up4dev nasceu também com o objetivo de mostrar que o modelo cascata está ai e muito vivo ! Ultimamente, muitos blogs falam somente sobre modelos agéis e etc. e quase ninguém pelo menos, fala como devemos migrar do cascata para o agil! Ou pior ainda, tem muita gente que vive no waterfall, sem ter a minima noção do mau deste modelo.
Atitudes como esta sua, elucidar o povo da nossa área, que o 1up4dev busca também.
[]s
Excelente post Thiago.
Hoje estou em um projeto absolutamente em cascata, e já bati muito nesta tecla com a equipe para diminuirmos -termos- iterações, pois nem isso temos, ou seja, o cliente somente receberá o software depois de um ano aproximadamente.
Devido a problemas com licitação e prazos ficou resolvido que haveria uma iteração intermediária, algo próximo de 6 meses, mas isso somente porque fomos (empresa) obrigados. Ainda assim, como você mesmo disse, uma iteração de 6 meses é muito, mas muito tempo.
Desenvolvimento de software não é uma tarefa simples, ainda mais com uma equipe e principalmente uma gerência que acredita piamente em um modelo em cascata.
Abraços e parabéns pelo post!
Também vejo muito gente utilizando Cascata, porém pouca gente defendendo cascata. Vejo muita gente defendendo o RUP A galera tá usando cascata pensando que é RUP!!
Sobre a estratégia de introduzir agilidade em um ambiente, também gosta da estratégia de utilizar conceitos já conhecidos, tipo essa cascata iterativa que você falou. Mas no meu caso eu preferi começar pelo Open UP, dada a popularidade do RUP. Ainda é cedo pra avaliar o sucesso da estratégia, mas o pessoal está bem mais aberto a mudança.
Muito bom o post. É uma discussão boa, mas precisamos analisar diversas realidades. Eu defendo muito a utilização de iterações, gosto da idéia de 15 dias, defendo um desenvolvimento mais ágil. Mas quando me deparo com alguém mais conservador e este me faz algumas colocações, fico na dúvida se é uma boa opção mesmo.
Se você me permite, arrisco dizer que o problema não é conosco. É com o cliente. Cada vez mais vejo que o cliente de software tem muito o que aprender ainda para que a vida de ambos (fornecedor e consumidor) seja melhor. Eles é que são os conservadores, não nós. Para a maioria dos desenvolvedores trabalhar com desenvolvimento ágil, escopo aberto, prazos e esforço negociável e flutuante é o paraíso. Mas tente empurrar isso em empresas grandes e mais antigas, principalmente as que não são da área de T.I. É bater com a cabeça no muro.
Por isso ficamos no modelo cascata. O cliente quer garantia de entrega, quer o escopo todo implementando, quer prazos fechados.
Como iniciar a desenvolver algo antes da análise estar concluída se o cliente pode mudar de idéia e podemos ter jogado dinheiro (tempo) fora? Como mostrar algo antes do tempo para o cliente para que ele acabe mudando de idéia e solicite uma mudança sem entender que mudar algo nessa altura significa maior custo e maior prazo? Quem vai arcar com o prejuízo?
É vendo essa realidade, e principalmente aplicando modelos como o CMMi, que vemos na prática como é difícil desenvolver em iterações corretamente. Acabamos preferindo a segurança da burocracia, mesmo sabendo que em termos de produtividade e qualidade não é a melhor opção. Mas isso é algo que precisamos discutir e mudar.
Abraços.
Marcelo, interessante você comentar sobre isso. O curioso é que o pontapé inicial para meu texto foi uma observação de um cliente durante uma reunião de, no melhor estilo cascata, elicitação de requisitos.
Você leu certo mesmo: estou falando de um comentário de um cliente, não de meus colegas choramingando contra o processo em cascata da empresa.
A equipe estava apresentando os casos de uso revisados após alterações solicitadas pelo cliente, como exigido pela polícia do processo interna, e a observação dele foi que sempre que lhe mostravam documentos daquele tipo ali ele só podia imaginar que as coisas iam funcionar como esperado e que confiava na equipe de desenvolvimento para fazer a coisa certa, mas que só tinha certeza realmente que tudo funcionaria durante a homologação final. O detalhe é que, devido às várias representações intermediárias exigidas e ao escopo nada enxuto das iterações nesta empresa em particular, a tal “homologação” só seria dali a dois meses. Ou seja, o cliente iria demorar pelo menos dois meses para saber se a equipe estava no rumo certo.
Claro que isto é só evidência pontual, uma história dentre milhares que podem ser contadas. Estatisticamente irrelevante, certo? Pode ser que este seja o único cliente do mundo que prefere ver software funcionando do que documentos. Mas eu desconfio que não.
Interessante. Também já me deparei com clientes mais abertos, esses são ótimos de trabalhar. O que tentei deixar claro foi que o cliente precisa ter essa mente para a coisa funcionar. Se ele tem, você teve sorte
.
Fiz um treinamento de XP com o Vinícius Teles e ele relatou decidiu só trabalhar com escopo aberto, prazo flexível, técnicas ágeis e Ruby On Rails. Se o cliente não quisesse alguma dessas coisas, “poderia procurar outro fornecedor”, em outras palavras. Não acho que ele seja tão rigoroso assim, mas deu para ver a posição da empresa dele. Isso é bom. Mas é preciso um mercado maduro para aceitar tais coisas. Empresas mais tradicionais vão querer impor, e não aceitar. Ficamos limitados.
No caso a empresa dele é no Rio, eu vivo em Fortaleza. Já são realidades diferentes. Em SP nem se fala. Mas em geral, na medida que o mercado amadurece é que essas questões surgem com mais força. É preciso um patrocinador. Mas nada que impede que a comunidade catalize o amadurecimento. Creio que esse seja a idéia.
* Engraçado que acabamos discutindo modelos tradicionais x ágeis, e não iterações x cascata. É a aplicação da discussão na nossa realidade. Mas é estranho no mínimo, pois iterações já deveriam ser padrão (em ambos os casos) há décadas. A gente vai levando…
Abraços.