CMM versus Agile no Desenvolvimento de Software

Prévia do material em texto

Universidade Estácio de Sá – Campus Nova América
Curso: Engenharia de Software
Aluno: Leonardo Carvalho Fournier
Matrícula: 201502857421
Estudo de Caso: CMM versus Agile Metodologias de Guerra em Desenvolvimento de Software
O texto inicia falando sobre como Jennifer Denton, Diretora de Informação do Hardcore Financial Bank(HFB), impulsionada por um competidor numa conferência sobre a sua experiência com a implementação de CMM(Modelo de Maturidade e Capacitação) na sua empresa. Logo de cara, embora ela tivesse a melhor das intenções, presenciou uma oposição muito forte de alguns dos melhores membros da sua equipe. Um dos seus funcionários então lhe enviou um relatório sobre CMM versus Agile. E Fenton então percebeu que havia defensores das duas ideias na sua equipe, e sua certeza na decisão anterior, se tornou uma dúvida.
A HFB estava em crescimento muito grande, mas os sistemas ainda falhavam constantemente, estouravam o orçamento e os desenvolvedores seniores começaram a pedir um amadurecimento no desenvolvimento de software da empresa. Dois dos desenvolvedores chegaram a dizer que sairiam da empresa, caso ela adotasse o CMM. Alegavam que CMM é um modo antiquado e que a melhor prática naquele momento era o Agile. O movimento ágil foi criado em 2001.
O texto decorre sobre como guerras existiram nas ultimas décadas no desenvolvimento de software, como desenvolvimento estruturado contra o tradicional em 70, orientado a objetos versus estruturado em 80 e, nos anos 90, do design orientado a objetos contra desenvolvimento tradicional. No início do século 21 Metodologia ágil versus CMM. Neste âmbito a discussão tinha uma cara de desenvolvedor contra gestor. Nas décadas anteriores os processos foram ficando mais como uma linha de produção e programadores perderam o papel central no processo, mas com a introdução de OO o poder dos programadores aumentou muito.
Para muitos, a metodologia ágil é a melhor forma de resolver problemas complexos, se comparada a forma rígida do modelo em cascata. Mas para muitos programadores a produção de tudo que não é código não é essencial, ideia que é oposta a visão dos gestores que querem artefatos tangíveis.
Embora o CMM traga uma organização, muitos criticam que para obter uma certificação dessas a empresa precisa de um bom processo administrativo e não desenvolvimento de software. Que basta seguir cegamente processos sejam eles quais forem. Nos níveis 3 e 4 o ponto mais evidente é um estilo de gestão muito forte. Em muitas empresas a preocupação é maior com a gestão do projeto que com o projeto em si.
No final da década de 80 e início de 90 as linguagens OO surgiram com muita força no meio corporativo, mas embora a adoção delas tenha sido muito boa, os projetos como um todo tiveram resultados piores que no paradigma tradicional, fazendo com que os próprios programadores entendessem que era necessário criar mecanismos de otimização do processo de desenvolvimento.
Neste ambiente o Agile cresceu, para atuar em temas como:
Sistemas são melhores desenvolvidos em incrementos pequenos;
Usuários e desenvolvedores precisam trabalhar de mãos dadas;
Cada incremento de sistema deve ser desenhado para lidar com os requisitos mínimos;
Quando as mudanças nos requerimentos ocorrem, elas devem ser concebidas;
Deve existir pouca ou nenhuma documentação acima do código atual;
Os gurus da programação OO colocam Agile como uma aversão à papelada imposta pela CMM. Diferentemente do CMM o Agile se desenvolveu espontaneamente.
Ken Beck, criador da metodologia XP, no seu livro Extreme Programming Explained, propôs 12 ideias que constituíram a abordagem Agile: Planejamento do Jogo, Pequenos Comunicados, Metáfora(arquitetura), Desenho Simples, Teste, Fatoração, Programação em Par, Propriedade Coletiva, integração contínua, 40 horas semanais, Cliente no local e Padrões de Codificação.
A abordagem da Agile deriva de certas crenças sobre dinâmicas de grupo e psicologia humana. As pessoas trabalham melhor em grupos, então podemos programar em equipes; revisar o código é bom, então sempre temos programação par; design orientado para o resultado é bom, então podemos incorporar "desenvolvimento com teste primeiro"; as pessoas funcionam melhor quando descansam o suficiente, então podemos instituir a regra de trabalho de 40 horas.
No desenvolvimento da CMM, os gestores assumem a maioria das responsabilidades. Na Agile, a equipe assume a responsabilidade.
Defensores de CMM julgam que com Agile corre-se o risco de desenvolver sistemas sem conhecer todos os requisitos necessários.
Em um projeto da Agile, o produto final é sempre o foco claro — não os requisitos, não o design, mas o código de trabalho real.