Engenharia de Software: 40 Anos de sofrimento e aprendizado

quinta-feira, 7 de agosto de 2008

Um pouco de história:
Modelo Cascata ou Waterfall:
Nas empresas que passei, pelo menos a maioria, posso dizer que trabalharam (ou trabalham) com o método cascata para o desenvolvimento de software, que tem seus prós e contras, o problema é que este modelo foi concebido nos anos 70 por W. W. Royce, e consiste na evolução de cada fase do projeto de forma sequencial (Figura 1), vemos na imagem que o primeiro quadrado inicia-se pelo "Requerimento", ou seja, é aquela fase do projeto que demora até meses para ser feita, onde o analista tem que coletar todas as informações pertinentes do projeto e definir os seus requisitos.

Pois bem, uma vez definido os requisitos e fechado o contrato ou a SLA, é montado o cronograma e iniciando a segunda fase deste modelo, a fase do "Projeto", e aí é que geralmente os problemas começam, pois muitas vezes, o cliente ao especificar um projeto não tem nem certeza do que quer, apenas uma idéia, ficando para o analista decifrar tudo o que cliente quer, e quando os requisitos chegam para os desenvolvedores, muitas vezes estes não tem nem contato com o usuário, e tem que se virar com o entendimento baseado nos documentos de especificação, o máximo é uma conversa rápida com o analista, e quando possível.
Outro problema é que estes projetos, são estimados em torno de 3 - 6 meses, e conforme o tempo vai passando, acontece coisas com o cliente e ele começa a esquecer o que foi acordado, sobrando para o pobre desenvolvedor que acaba tendo que refatorar o código para atender a necessidade do usuário, e no modelo cascata não podemos voltar uma fase, conclusão, projetos mal sucedidos, ou atrasados, ou o produto acaba não atendendo o cliente.

Modelo Espiral:


Para tentar acabar com estes problemas conhecidos do Modelo Cascata, em 1988 Barry Boehm escreveu um artigo “A Spiral Model of Software Develpement and Enhancement” , que propõe um desenvolvimento iterativo e incremental que podem chegar de 6 meses a 2 anos,


Vantagens deste modelo:
• O Modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.
• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.


Desvantagens:
• Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.
• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.
• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.
• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.
• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

RUP:

Nestes 3 últimos anos especificamente, tenho trabalhado com um híbrido de RUP, e nas minhas experiências não tenho tido o sucesso desejado, vendo a causa pude chegar a conclusão que para uma metodologia desta dar certo não dependendo só dos templates do método e das fases estabelecidas mas da cultura da empresa e das pessoas envolvidas, pelo menos nos locais onde trabalhei com esta metodologia as pessoas trabalham com RUP em uma forma cascata, e RUP pode será ágil, que é o que mostra o artigo RUP Ágil de José Papo em seu blog. Mas mesmo assim, as pessoas tendem a trabalhar com um RUP mais “pesado”, com um excesso de documentação a ser preenchida, onde para cada passo que é dado, é preciso de assinaturas dos envolvidos.
Ou seja, essa situação faz com que as pessoas envolvidas no processo (leia-se cliente, fornecedor, terceiro) acabam entrando em conflito, pois imagine a seguinte situação, eu tenho um determinado cliente que pede uma determinada funcionalidade no sistema DELE, após eu(analista) colher o requisito, eu tenho o trabalho de documentar isso em um documento definindo as fronteiras do sistema, identificando principais envolvidos/interessados e priorizando suas necessidades, e os requisitos funcionais e não funcionais, pois bem, depois de todo este trabalho, antes de fazer qualquer coisa eu tenho que pegar um documento assinado ou email, provando que foi uma solicitação real e será implementada de acordo com a especificação.
É normal que o cliente terá receio de assinar qualquer documento, pois na cabeça dele, ele pensa que se acontecer alguma coisa errada no processo, a culpa irá recair sobre ele por causa deste documento assinado. Isso vai gerando um desconforto muito grande entre os envolvidos, e o atraso é evidente pois para cada passo é preciso da aprovação do cliente, cada fase do projeto é auditada. Então me diga, Cadê a agilidade?
Lembro que estas foram as minhas experiências com RUP.
Será que não tem algo errado nisto ? Por quê muitas empresas utilizam processos de desenvolvimento de 40 anos atrás, sendo que todo ano é publicado o relatório do Caos pela Standish Group International, onde até o ano passado, 1 entre 3 projetos estouram o orçamento,

Foram por causa dessas perguntas que comecei a me interessar por meios alternativos de gerenciamento de projeto, foi quando conheci as metodologias ágeis. E descobri algo que o que realmente faltava nestes processos / modelos / metodologias, e é algo que é o ponto chave em metodologias como SCRUM, é que esta metodologia é centrada em PESSOAS, GENTE, SER HUMANO, agora que as outras não priorizam. Desenvolvimento LEAN. Veja alguns dos principios:

“Indivíduos e interações são mais importantes que processos e ferramentas.”

“Software funcional é mais importantes que excesso de documentação.”

Para uma idéia melhor sobre o que que é manifesto ágil, veja meu outro post Agile Manifesto – Metodologias Ágeis.

E essa descoberta mudou radicalmente o meu processo de pensar, é a solução para todos o problemas? NÃO.

Mas com certeza é um passo muito importante para quebrar o paradigma de desenvolvimento de software tradicional.

Aos poucos vou falar sobre estes processos ágeis, recomendo que você leia as seguintes matéria.


Blog:

Agile Manifesto – Metodologias Ágeis
TDD – Test Driven Development
SCRUM – Uma abordagem prática

Livros:
Agile Software Development with SCRUM
Extreme-Programming-Explained
User Stories Applied
Lean-Software-Development

2 comentários:

rbellia disse...

Muito bom esse seu overview !
Acabei de voltar do MC de Scrum que teve hoje na Globalcode com o Juan da Teamware e estava muito bom tbém.

Consultora Educacional disse...

Gosto muito dos artigos de ótima qualidade do seu Blog. Quando for possível dá uma passadinha para ver nosso Curso de Informática Online. Melissa.