Visão Ágil e Visão estruturada-Parte 3-Métodos Ágeis

Métodos Ágeis:

O surgimento dos métodos ágeis se deu, para surpresa de muitos, bem antes da Internet e dos processos colaborativos. A pedra fundamental dos métodos ágeis foi o desenvolvimento de projeto com estilo iterativo e incremental, aplicado à engenharia desde a metade dos anos 30. IIDD, como era chamado "Interative and Incremental Design and Development", já era muito usada em projetos de engenharia de hardware(não software). O grande precursosr dos métodos iterativos e incrementais foi Dr Edward Deming, um estatístico, professor que promoveu o conceito de PDCA(originalmente PDSA), com o -S- de Study ao invés de -C- de Check. A Nasa,a Força Aérea Americana e a indústria japonesa usaram intensivamente o método de Deming em projetos "time box", iterativos e com ciclo de desenvolvimento incremental de produtos. Na metade dos anos 50, diversos projetos de software usaram o método de IIDD, empregando muitos dos conceitos hoje aplicados nas metodologias ágeis. Entretanto num mundo dominado pelo Cobol, com demandas por projetos complexos, grandes arquivos, abordagem top-down estruturada, isso acabou não sendo percebido como um possível padrão emergente. Em 1976, Tom Guilby apontou no seu livro "Software Metrics", que um método superior para desenvolvimento de software existia e lançou a idéia de algo mais leve, mais ágil, mais adaptativo, com ciclos e iterações que mostravam mais rapidamente os produtos ao cliente. Essas idéias foram gradativamente amadurecidas e em 1985, Barry Boehm lançou o seu método Espiral, no seu "The Spiral Model of Software Deevelopment and Enhancement". Durante os anos 90, aumentou a aceitação dessa nova abordagem e o IIDD ganhou variantes como RAD(Rapid Application Development) e RUP(Rational Unified Process). Embora soando estranho, algumas técnicas inovadoras de métodos ágeis surgiram em grandes empresas: XP(eXtreme Programming) surgiu na Chrysler Corp em 1996, num projeto pilotado pelos ainda não gurus Ron Jeffries e Kent Beck. Já no final da década, ficou claro que um método que privilegiava a forte interação entre equipes, usava a comunicação "tête-à-tête",aplicava uma rigorosa interação com o cliente, empregando times pequenos e rápidos,e com as entregas frequentes de software, se tornaria uma forte abordagem para se fazer software de forma superior àquela vigente. Vários métodos foram derivados dessas idéia originais como Scrum, Crystal, FDD, etc. Com a proliferação de métodos se deu um fenômeno parecido com o que aconteceu quando do surgimento da UML. Havia a necessidade de se definir algo em comum e os grandes gurus de cada linha se uniram para escrever o famoso "Manifesto Ágil", nascido nas montanhas geladas do estado de Utah. Os líderes foram: Kent Beck,Ron Jeffries,Alistair Cockburn, Jim Highsmith,Bob Martin,Mike Beedle,Ken Schwaber e Jeff Sutherland. Um subconjunto desses autores se juntou à Mary Poppendick para formar a Agile Alliance, organização não lucrativa voltada para encorajar o uso de métodos ágeis. Enquanto o primeiro manifesto foi focado para programação, 2 gurus originais(Cockburn e Highsmith) se juntaram com outros luminares como David Anderson, Mike Cohn, Todd Little, etc para definir os seis princípios de gerenciamento, conhecido pelo estranho nome de "Project Management Declaration of Interdependence(DoI)". Os 15 autores do DoI formaram o Agile Project Leadership Network(APLN), de novo, um organismo sem fins lucrativos que encorajava a prática de métodos ágeis, agora em domínios de liderança e gerenciamento. Esses manifestos, somados ao crescimento de desenvolvimento de software para a internet alavancou o método, sendo que o mais conhecido (Scrum) continua a crescer além do software, alcançando domínios que objetivam os mesmos ganhos definidos por Deming e equipe, com o seu IIDD. Assim surgiu um método caracterizado por premissas frontalmente opostas àquelas existentes :
1)Equipe pequena,coesa e trabalhando com forte interação;
2)Forte participação do cliente;
3)Entregas pequenas e em maior frequência;
4)Comunicação "tête-à-tête", com experiência fortemente focada em projetos menores, sem os rigores do custo fixo, com aceitação de riscos, que segundo o método, serão mitigados pelas suas próprias características de fluidez,rapidez e de entregas menores.
Da mesma maneira, o modelo ágil proposto deverá ser observado, segundo seus valores e princípios de uma forma aberta, atentando para o fato de que o Manifesto ágil define preferências e não alternativas excludentes e encoraja o foco sobre certas áreas mas não elimina outras.

Visão Ágil e Visão estruturada-Parte-2-CMMI

CMMI:

Um dos pontos mais importantes para se entender as diferenças e ajustar os encaixes, quando falamos de CMMI(MPS.BR) e métodos ágeis, é compreender a origem de cada abordagem.
O CMMI surgiu para se desenvolver projetos grandes, de gerência altamente complexa, torneados com escopo imutável e custo definido, além de altíssima aversão a riscos. Os primeiros projetos CMM surgiram para a fabricação de softwares que visavam controlar naves espaciais, satélites inovadores e armamentos de tecnologia inédita. O modelo foi publicado em 1989, por Watts Humphrey, no seu livro "Managing the Software Process". O Departamento de Defesa(DoD), responsável por esses projetos estratégicos não tinha outra saída, naquele momento, senão sugerir métodos altamente estruturados, com forte gerência de requisitos e um estrito controle das partes envolvidas.Um ambiente onde o escopo era(ou tinha que ser) definido rigorosamente, pois o software era tido como um componente de algo maior, cuja infalibilidade era a premissa primeira, até porque naves espaciais, satélites,equipamentos médicos,etc, implicavam aspectos de segurança de vida. Os usuários não eram stakeholders colaborativos, como agora percebemos, entrando no circuito do processo somente para os testes e com pouca intervenção durante o trajeto. Esse conceito era chamado de "low trust". O sistema era desenvolvido por processos cuidadosamente definidos centrados no menor risco, na fortíssima padronização e em relacionamentos amplamente costurados por contratos entre clientes e desenvolvedores. Isso acabou moldando a personalidade do modelo CMMI para ambientes que os americanos chamavam de " high ceremony" e "low trust" , ou seja com alto nível de controle de risco e aplicação de gerência e com baixa interveniência dos usuários. As entregas, por sua vez, também obedeciam a uma receita da época: os "deliveries" eram monolíticos e infrequentes. Porquê? Por que a parada de um caça de guerra para troca de possível componente(software incluído), ou a suspensão da funcionalidade de um aparelho médico podia custar muitas horas de logística. Na época, claro,não se baixava um software pela internet. Além disso, entregar o componente funcionando na sua plenitude, no primeiro "delivery" era premissa de primeira ordem. Tudo isso, num projeto gigantesco, com envolvimento de múltiplas empresas com inúmeras equipes e entrelaçados por contratos governamentais exigentes em termos de baixo risco. Com o tempo, o CMM ganhou variantes para outros projetos(não somente de software) e não demorou o pleito para que todas essas fossem empacotadas num único modelo, quando nasceu o CMMI, em 1998. O CMMI foi evoluindo e hoje forma o framework com um conjunto melhorado de padrões, práticas e idéias.Mas a sua gênese trouxe marcas que definiram o método e que se observa no seu genoma:
1)Aplicado para projetos grandes e de alta complexidade;
2)Aplicado em projetos com múltiplas equipes, oriundas de empresas diferentes e até competidoras entre si, onde a competitividade influia e o alto protocolo definido substituia a confiança(trust) e a coesão das equipes, definindo um ambiente com traços de "low trust". Ou seja, a confiança entre os times não se dava por coesão, integração e interação constante das equipes(valor do relacionamento do capital humano), mas pelo nivel de cerimônia, rigor e protocolo que o processo impunha;
3)Projetos onde os "deliveries" eram monolíticos e infrequentes, pois a logística de parada dos seus receptores de software (aviões,satélites e devices médicos) implicava sérios riscos. A idéia era entregar o " todo" com "quase tudo" funcionando na primeira vez( a velha e volumosa cascata);
4)Os projetos tinham que ter baixos riscos(aversão intensa a riscos) devido às suas características técnicas especiais e ao alto investimento de recursos públicos, dada as características dos projetos.
Assim nasceu um modelo CMMI, fortemente estruturado, revestido pelo rigor das regras e com baixa interação do capital humano(entre equipes),porém aplicado para projetos gigantes e de alta complexidade operacional e gerencial.Isso, entretanto, não significa que o Modelo, tal como definido hoje, não pode ou não deve ser aplicado em projetos que possuem estilo e ciclos de vidas diferentes. Um modelo, qualquer que seja, deve ser visto como um guia e não como uma regra ortodoxa calcada sobre preceitos imutáveis, conforme veremos na parte 4.

Visão Ágil e Visão estruturada-Parte-1-Introdução

Quando um dinossauro como eu, cheio de movimentos letárgicos e pré-reumáticos, é convidado a falar sobre MPS.BR num evento chamado -Maré de Agilidade- , há que se preparar. Como sou um "sem-prancha", e da praia só gosto da paisagem, detesto a areia e me incomodo com o sol, senti a necessidade de buscar um pouco da história para preencher o vazio que tal combinação insólita proporcionaria(um dinossauro sem prancha, numa praia cheia de jovens surfistas, brilhantes e ágeis). Fui estudar um pouco acerca dos dois pólos aparentemente antagônicos e distantes dentro do campo da Engenharia de Software: O métodos ágeis e os métodos , que chamei de estruturados, envolvendo CMMI e MPS.BR. Esse artigo, claro, não objetiva nem evangelizar os seus pouquíssimos leitores de forma a cooptá-los a uma genuflexão definitiva diante do altar de uma das alternativas, nem acender uma tocha provocativa, buscando detonar uma linha e colorir de méritos a remanescente. Muito pelo contrário, a missão é de paz.
Se pudesse definir um objetivo sintético para essas reflexões, diria que, como já falei por cerca de 4 horas e pouco no podcast do Vinicius Manhães Teles, estamos falando de métodos convergentes e não de extremos que nunca se tocarão.
Esse trabalho foi centrado no melhor "paper" que detalhou os dois métodos. Publicado pelo SEI, em Novembro de 2008, sob o título de CMMI or Agile: Why not embrace both, esse artigo, escrito por pessoas ligadas profundamente à engenharia de software, mostra com equilíbrio e vislumbre as trilhas de convergências entre as duas propostas. Dentre seus autores (Hillel Glazer, da Entinex,Inc; Jeff Dalton, da Broadsword Solutions Corp;Mike Konrad do SEI; e Sandy Shrum do SEI), também se encontra David Anderson, da David Anderson Associates, um dos signatários do Manifesto Ágil, em uma das suas vertentes. Ele foi escrito em várias partes, para que um leitor incauto possa desistir dele, sem grandes perdas de oxigênio e comprometimentos de suas sinapses. A estrutura, segue uma estrutura próxima do artigo original:
1)Essa introdução
2)Visão do CMMI e métodos estruturados(MPS.BR)
3)Visão dos métodos ágeis
4)Entendendo o conceito de modelo
5)Analisando o Manifesto Ágil
6)Desafios
7)Conclusão
8)Adendos-extensões sobre o assunto