❧ Desenvolvimento Ágil: Scrum e XP ❧

Introdução: O Contexto da Agilidade4.1

Nos dias de hoje, as empresas operam num ambiente global caracterizado por mudanças extremamente rápidas e imprevisíveis. Para que essas organizações se mantenham competitivas e sobrevivam, elas precisam de responder prontamente a novas oportunidades de negócio, conquistar novos mercados antes da concorrência, adaptar-se a alterações súbitas nas condições económicas e enfrentar o surgimento constante de produtos e serviços rivais.

Como o software tornou-se parte integrante e indissociável de quase todas as operações de negócios, a pressão por velocidade recai diretamente sobre as equipas de desenvolvimento. Novos sistemas precisam de ser criados rapidamente para aproveitar essas oportunidades e responder às ameaças competitivas. Consequentemente, a entrega rápida e a flexibilidade deixaram de ser diferenciais para se tornarem requisitos críticos de sobrevivência.

Nesse cenário dinâmico, o modelo tradicional de desenvolvimento, também conhecido como modelo em cascata ou waterfall (onde se especifica tudo detalhadamente antes de escrever uma linha de código), muitas vezes falha. Ele falha porque assume uma estabilidade de requisitos que simplesmente não existe mais. É aqui que entram os métodos ágeis. O objetivo principal da engenharia de software ágil é justamente permitir o desenvolvimento incremental e a entrega rápida de software funcional.

Esses processos compartilham algumas características fundamentais que deve conhecer e diferenciar. Primeiramente, as etapas de especificação, projeto e implementação são intercaladas. Ou seja, em vez de fases distintas e sequenciais, elas acontecem simultaneamente ou em ciclos muito curtos de feedback. Além disso, o sistema é desenvolvido numa série de incrementos ou versões; a cada ciclo, uma parte usável do software é entregue. As ferramentas de apoio ao desenvolvimento, como ambientes de desenvolvimento integrados (IDEs) modernos e ferramentas de visualização de código, são utilizadas extensivamente para dar suporte a esse ritmo acelerado, automatizando tarefas repetitivas. Por fim, há um envolvimento constante e ativo dos usuários finais e demais interessados no sistema (stakeholders), que validam cada versão entregue, garantindo que o produto final realmente atenda às suas necessidades, mesmo que elas mudem durante o processo.

Métodos Ágeis e o Manifesto4.2

Nas décadas de 1980 e 1990, predominava a visão de que o desenvolvimento de software de qualidade dependia de um planejamento cuidadoso, processos rigorosos e documentação extensiva. Essa abordagem, derivada da engenharia de sistemas críticos e aeroespaciais, justificava seu alto custo de coordenação pela complexidade desses projetos. No entanto, quando aplicada a sistemas corporativos menores e dinâmicos, essa metodologia dirigida a planos gerava um overhead excessivo, tornando o desenvolvimento mais lento do que a evolução dos requisitos do mercado. A insatisfação com essa rigidez e o desperdício de tempo em documentação levaram ao surgimento dos métodos ágeis na década de 1990, que mudaram o foco para a entrega rápida de software útil.

Essa nova filosofia foi consolidada no Manifesto Ágil, que inverteu os valores tradicionais ao priorizar indivíduos e interações, software em funcionamento, colaboração com o cliente e resposta a mudanças, em detrimento de processos, ferramentas, documentação abrangente e negociação de contratos. Métodos como Extreme Programming (XP), Scrum e DSDM, embora proponham processos diferentes, compartilham um conjunto de princípios fundamentais baseados nesse manifesto, conforme detalhado na tabela abaixo:

Embora esses métodos sejam altamente eficazes para o desenvolvimento de produtos comerciais e sistemas personalizados internos, sua aplicação enfrenta barreiras práticas significativas. O sucesso depende, por exemplo, de um cliente disposto e capaz de dedicar tempo integral à equipe, o que nem sempre é possível devido a pressões externas. Além disso, a cultura organizacional de grandes empresas, habituadas a processos formais, muitas vezes resiste à informalidade e à autonomia exigidas pelo modelo ágil, e nem todos os desenvolvedores possuem o perfil de personalidade necessário para a intensa colaboração interpessoal que o método exige.

Outro desafio crítico é o aspecto contratual e a manutenção de longo prazo. Como a especificação incremental é inerente ao ágil, torna-se difícil firmar contratos tradicionais de escopo fechado, levando a disputas sobre prazos e custos caso surjam problemas. No que tange à manutenção, a ênfase em código limpo em vez de documentação formal pode ser arriscada: se a equipe original se desfizer, o conhecimento implícito sobre o sistema é perdido, dificultando a evolução do software por novos membros que não têm um documento de requisitos coerente para consultar. Devido a esses fatores, especialistas sugerem que, para muitos projetos, uma abordagem híbrida que incorpore técnicas de planejamento tradicional aos métodos ágeis pode ser o caminho mais seguro.

Comparativo: Ágil vs. Dirigido a Planos4.3

As abordagens ágeis e as dirigidas a planos diferem fundamentalmente na forma como estruturam as atividades. Enquanto o ágil considera o projeto e a implementação como atividades centrais, incorporando elicitação de requisitos e testes nesse fluxo contínuo, a abordagem dirigida a planos identifica estágios distintos, onde a saída documental de uma fase serve de base para o planejamento da próxima. Essa distinção, onde o modelo dirigido a planos comunica-se via documentos formais e o ágil itera requisitos e projeto conjuntamente, é ilustrada na figura abaixo:

É importante notar que essas fronteiras não são rígidas. Um processo dirigido a planos pode apoiar entregas incrementais, assim como equipes ágeis podem produzir documentação formal quando necessário. Na verdade, a maioria dos projetos de software inclui práticas das abordagens dirigidas a planos e ágil. Para optar por um equilíbrio entre as abordagens, você precisa responder a uma série de questões técnicas, humanas e organizacionais, resumidas na tabela a seguir:

Na realidade, a questão sobre rotular o projeto como dirigido a planos ou ágil é secundária. A principal preocupação do comprador é adquirir um sistema executável que atenda às suas necessidades. Na prática, muitas empresas bem-sucedidas adotam uma postura híbrida, integrando práticas ágeis dentro de seus processos dirigidos a planos.

Extreme Programming (XP)4.4

Extreme Programming (XP) é talvez o método ágil mais conhecido e amplamente utilizado, cujo nome foi cunhado por Kent Beck (2000) com a premissa de elevar práticas de desenvolvimento reconhecidamente boas a níveis "extremos" de disciplina. Em vez de integrar o código apenas no final do mês, no XP a integração e os testes ocorrem várias vezes ao dia. O ciclo de vida é rápido e focado em feedback constante, onde programadores trabalham em pares, escrevem testes antes mesmo do código e realizam releases frequentes, conforme ilustrado no fluxo abaixo:

Para sustentar esse ritmo, o XP fundamenta-se em um conjunto de práticas que devem ser seguidas disciplinarmente. Diferente de processos que dependem de burocracia, o XP depende da sinergia entre as seguintes técnicas:

O processo de planejamento, conhecido como "Jogo de Planejamento", transforma necessidades abstratas em código executável. O cliente escreve "estórias" (cenários de uso) em cartões. Abaixo, temos um exemplo prático (Quadro 3.1) de como um requisito complexo de saúde é descrito em linguagem natural pelo cliente:

Uma vez definida a estória, a equipe de desenvolvimento a analisa e a decompõe em tarefas técnicas menores e estimáveis (Quadro 3.2). Se houver incerteza técnica, a equipe pode realizar um "Spike" (um tempo dedicado apenas à investigação sem entrega de código).

Essa abordagem desafia a engenharia tradicional ao descartar o princípio de "projetar para a mudança" (tentar antecipar requisitos futuros na arquitetura). O XP assume que o futuro é incerto e que antecipação gera desperdício. Em vez disso, a metodologia aceita que mudanças ocorrerão e confia na refatoração constante para reorganizar o software quando necessário. Embora essa falta de design prévio possa degradar a estrutura do código se não for vigiada, a refatoração contínua, apoiada por ferramentas modernas que automatizam essas mudanças, mantém o sistema limpo. Na prática, muitas empresas adaptam o XP, utilizando suas práticas técnicas (como testes automatizados e integração contínua), mas flexibilizando aspectos organizacionais como a programação em pares ou a presença física do cliente.

Testes em XP4.4.1

A abordagem de testes no desenvolvimento incremental difere significativamente do desenvolvimento dirigido a planos. No contexto incremental, a ausência de uma especificação formal do sistema impede que uma equipe externa desenvolva testes de sistema tradicionais. Consequentemente, alguns métodos ágeis possuem processos de teste informais. Para mitigar problemas de validação, o Extreme Programming (XP) enfatiza a importância crítica dos testes de programa, adotando uma postura que visa reduzir a probabilidade de erros desconhecidos na versão atual do sistema.

As principais características que definem a estratégia de testes no XP são o desenvolvimento test-first, a criação incremental de testes a partir de cenários, o envolvimento ativo dos usuários na validação e o uso extensivo de frameworks de automação. O desenvolvimento test-first representa uma das inovações mais marcantes desta metodologia. Ao invés de escrever o código e posteriormente os testes, o desenvolvedor escreve os testes antes da implementação. Esta prática permite a execução imediata dos testes durante a codificação, facilitando a identificação precoce de problemas.

Ao escrever os testes antecipadamente, define-se implicitamente uma interface e uma especificação de comportamento para a funcionalidade. Essa abordagem reduz ambiguidades de requisitos e mal-entendidos de interface, sendo aplicável sempre que houver uma relação clara entre um requisito e sua implementação. No XP, essa ligação é visível pois os cartões de histórias (requisitos) são divididos em tarefas, que servem como unidade principal de implementação. Além disso, essa prática evita o problema de test-lag, que ocorre quando a implementação avança muito à frente dos testes, levando a uma tendência de ignorar a validação para cumprir cronogramas.

Os requisitos do usuário em XP são expressos como cenários ou histórias, priorizados pelo cliente. A equipe de desenvolvimento avalia cada cenário e o divide em tarefas, onde cada tarefa gera um ou mais testes de unidade. No processo de testes, o papel do cliente é fundamental para ajudar a desenvolver testes de aceitação para as histórias do próximo release. O teste de aceitação verifica se o sistema atende às reais necessidades do cliente utilizando seus próprios dados. Abaixo, apresenta-se um exemplo prático da estrutura de um caso de teste para prescrição médica:

Uma grande dificuldade encontrada no XP é obter o apoio contínuo do cliente para o desenvolvimento desses testes de aceitação, visto que eles frequentemente possuem tempo limitado e podem considerar a simples entrega dos requisitos como contribuição suficiente.

A automação é essencial para sustentar o desenvolvimento test-first. Os testes são escritos como componentes executáveis e autônomos que simulam a entrada e verificam a saída. Frameworks como o JUnit facilitam a escrita e execução desses conjuntos de testes. Como a validação é automatizada, sempre que uma nova funcionalidade é adicionada, os testes podem ser executados rapidamente para detectar regressões ou novos defeitos.

Apesar de o desenvolvimento test-first e a automação gerarem um grande volume de testes, isso não garante necessariamente a completude da validação do programa. Existem três razões principais para essa limitação, conforme detalhado na tabela a seguir:

Programação em Pares4.4.2

Uma das práticas mais inovadoras introduzidas no Extreme Programming (XP) é a programação em pares. Neste modelo, os desenvolvedores sentam-se juntos na mesma estação de trabalho para desenvolver o software. É fundamental destacar que essas duplas não são estáticas, pelo contrário, os pares são formados de maneira dinâmica, garantindo que todos os membros da equipe trabalhem uns com os outros ao longo do processo de desenvolvimento.

A adoção dessa metodologia oferece benefícios estruturais significativos para a equipe e para a qualidade do código, conforme detalhado na tabela a seguir:

Existe um debate comum sobre a eficiência dessa prática, baseado na intuição de que dois desenvolvedores trabalhando juntos produziriam apenas metade do código que produziriam separadamente. Estudos acadêmicos apresentam conclusões variadas sobre o tema. Pesquisas utilizando estudantes voluntários (Williams et al.) sugeriram que a produtividade é comparável à do trabalho individual, pois a discussão prévia reduz falsos começos e o retrabalho. Por outro lado, estudos com programadores experientes (Arisholm et al.) indicaram uma perda de produtividade significativa, onde os ganhos de qualidade não compensaram totalmente o custo adicional.

Gerenciamento Ágil com Scrum4.5

A principal responsabilidade dos gerentes de projeto de software reside em garantir a entrega do produto dentro do prazo e do orçamento previstos, supervisionando o trabalho dos engenheiros e monitorando o progresso do desenvolvimento. Tradicionalmente, a abordagem padrão é dirigida a planos, exigindo que o gerente possua uma visão estável de todo o escopo e dos processos de desenvolvimento. No entanto, essa rigidez não se adapta bem aos métodos ágeis, nos quais os requisitos são incrementais e as mudanças são a norma. O desenvolvimento ágil requer uma gestão adaptada para ciclos curtos e para a maximização dos recursos disponíveis.

Nesse contexto, a abordagem Scrum destaca-se como um método ágil focado no gerenciamento do desenvolvimento iterativo, ao invés de prescrever práticas técnicas específicas. O Scrum não dita o uso de práticas como programação em pares ou desenvolvimento test-first, o que permite sua combinação com frameworks técnicos como o XP (Extreme Programming). O fluxo de gerenciamento desse processo é visualizado na figura abaixo:

O ciclo de vida no Scrum divide-se fundamentalmente em três fases. A primeira consiste no planejamento geral, onde se definem os objetivos e a arquitetura do software. A segunda fase é composta por ciclos de sprint, onde ocorre o desenvolvimento incremental do sistema. Por fim, a fase de encerramento completa a documentação e avalia as lições aprendidas. A grande inovação do Scrum reside justamente na sua fase central, os sprints, que são unidades de planejamento onde o trabalho é avaliado, selecionado e implementado.

As características essenciais que regem o funcionamento de um Sprint estão detalhadas na tabela a seguir:

A eficácia do Scrum é amplamente documentada, com relatos de sucesso em diversos setores, como telecomunicações. As vantagens observadas na aplicação desse método, segundo Rising e Janoff (2000), incluem:

Embora o Scrum tenha sido originalmente concebido para equipes colocalizadas, permitindo reuniões presenciais diárias, a realidade atual do desenvolvimento de software frequentemente envolve equipes distribuídas globalmente. Consequentemente, diversas experiências e adaptações estão em curso para viabilizar o uso do Scrum em ambientes de desenvolvimento distribuído, mantendo a agilidade e a coesão da equipe mesmo à distância.

Escalamento de métodos ágeis4.6

Os métodos ágeis foram originalmente concebidos para equipes de programação de pequeno porte, situadas em um mesmo ambiente físico para facilitar a comunicação informal. No entanto, a necessidade premente de acelerar a entrega de software alinhada às demandas do cliente também se aplica a sistemas de grande escala. Autores como Denning (2008) argumentam que adaptar a agilidade para grandes sistemas é a única via para evitar falhas clássicas da engenharia de software, como estouros de orçamento e produtos desconectados das necessidades reais.

Para compreender o desafio, é necessário distinguir as características inerentes ao desenvolvimento de sistemas de grande porte, que diferem substancialmente dos projetos pequenos. A tabela a seguir detalha essas diferenças cruciais:

Ao abordar a expansão do agilismo, identificam-se duas perspectivas distintas. A primeira é o Scaling Up, referente ao uso de métodos ágeis para desenvolver sistemas grandes e complexos. A segunda é o Scaling Out, que diz respeito à introdução desses métodos em grandes organizações com culturas estabelecidas.

Para o sucesso do Scaling Up, Leffingwell (2007) defende a manutenção dos fundamentos ágeis, como planejamento flexível e integração contínua, mas com adaptações críticas para suportar a escala:

Por outro lado, o Scaling Out enfrenta barreiras organizacionais. Enquanto pequenas empresas adotam o ágil rapidamente por falta de burocracia, grandes corporações enfrentam dificuldades significativas na transição cultural e processual.

Os principais obstáculos enfrentados por grandes empresas ao tentar "escalar para fora" o ágil incluem:

Em suma, apresentar e sustentar métodos ágeis em uma grande organização não é apenas uma mudança técnica, mas um profundo processo de mudança cultural. Isso exige tempo, recursos significativos e "evangelizadores" internos dedicados a promover a transição, algo que poucas grandes empresas conseguiram realizar plenamente até o momento.

Questões4.7

1. Explique por que, para as empresas que operam em mercados globais dinâmicos, a entrega rápida e a implantação contínua de novos sistemas frequentemente são consideradas mais críticas para a sobrevivência do que a funcionalidade detalhada desses sistemas.

2. Explique como os princípios básicos do Manifesto Ágil (como entrega incremental e aceitação de mudanças) levam ao desenvolvimento e implantação de software acelerados, contrastando com a rigidez dos modelos dirigidos a planos.

3. Com base na tabela de fatores técnicos, humanos e organizacionais apresentada no texto, cite três cenários ou características de projeto onde você não recomendaria o uso de um método ágil, preferindo uma abordagem dirigida a planos.

4. O Extreme Programming (XP) expressa os requisitos dos usuários como "estórias" em cartões, em vez de documentos de especificação detalhados. Discuta as vantagens dessa abordagem para o planejamento incremental e as desvantagens potenciais para a manutenção de longo prazo e contratos de escopo fechado.

5. Explique por que o desenvolvimento test-first (testes antes do código) ajuda o programador a desenvolver um melhor entendimento dos requisitos do sistema e a evitar ambiguidades. Quais são as limitações dessa abordagem em relação à completude da validação e interfaces complexas?

6. Embora intuitivamente pareça que dois programadores trabalham o dobro se estiverem separados, sugira razões baseadas no texto (como revisão informal e refatoração) pelas quais a programação em pares pode ser considerada eficiente e benéfica para a qualidade do código e gestão de risco da equipe.

7. Compare a abordagem Scrum para o gerenciamento de projetos com abordagens convencionais dirigidas a planos. Foque sua comparação na forma como cada uma lida com a incerteza dos requisitos, o planejamento das atividades (Sprints vs. Fases Longas) e o papel do gerente (Scrum Master vs. Gerente de Projeto tradicional).

8. Você é um gerente de software em uma empresa responsável pelo desenvolvimento de um sistema crítico de controle para aeronaves, sujeito a rigorosas regulamentações de segurança e auditoria. Analise a viabilidade de utilizar uma abordagem puramente ágil (como XP) versus uma abordagem dirigida a planos para este projeto, considerando os fatores de "Regulamentação" e "Tipo de Sistema" discutidos no texto.

9. O texto menciona que um dos desafios dos métodos ágeis é a necessidade de um cliente disponível em tempo integral ("Cliente no Local"). Discuta as dificuldades práticas de implementar esse princípio em grandes organizações e como a falta de consenso entre diferentes stakeholders pode afetar o progresso da equipe ágil.

10. Para reduzir custos, sua empresa decidiu que a equipe de desenvolvimento passará a trabalhar de forma totalmente remota e distribuída. No entanto, a gerência não considerou que a equipe utiliza Scrum e programação em pares. Discuta os desafios de comunicação e coordenação que essa mudança impõe às práticas ágeis (que foram desenhadas para ambientes colocalizados) e mencione adaptações necessárias para o "Scaling Out" ou trabalho distribuído.

Próximos passos4.8