3. Estratégias de Engenharia de Software
3.1 Estratégia Priorizada 📕
- Abordagem: Ágil
- Ciclo de Vida: Interativo Incremental
- Processo: RAD
3.2 Quadro Comparativo 📋
O quadro a seguir apresenta características relacionadas ao RAD (Rapid Application Development) e ao Scrum/XP, com ajustes para tornar a comparação mais precisa e útil na escolha do processo mais adequado ao caso da VB.
| RAD | Scrum/XP | |
|---|---|---|
| Foco | Desenvolvimento rápido com prototipação e ciclos curtos para validação precoce de requisitos. | Entrega contínua de valor ao cliente, com ênfase na qualidade do código e adaptação às mudanças. |
| Foco Principal | Prototipagem rápida para validar ideias, requisitos e interfaces com usuários. | Entregas incrementais e iterativas que mantêm qualidade técnica (TDD, refatoração, integração contínua). |
| Estrutura | Fases típicas: planejamento de requisitos, design centrado no usuário, construção de protótipos e transição. Menos ênfase em cerimônias formais. | Estrutura baseada em papéis (PO, SM, Time), iterações (sprints), backlog, revisões e práticas XP (TDD, pair programming, CI). Cerimônias definidas. |
| Equipe | Geralmente concentrada em especialistas e desenvolvedores focados em protótipos; stakeholders participam intensamente nas fases de validação. | Equipe autogerida e multifuncional; colaboração contínua entre desenvolvedores, PO e demais stakeholders. |
| Arquitetura | Planejamento arquitetural inicial reduzido; foco em protótipos para validação rápida. Arquitetura pode precisar ser refeita/ajustada para o produto final. | Arquitetura evolutiva e intencional: começa simples e é continuamente refinada para suportar qualidade, escalabilidade e manutenção. |
| Flexibilidade | Alta flexibilidade nos requisitos e no design inicial; porém, sem práticas de engenharia fortes, a qualidade pode ser comprometida em projetos maiores. | Alta flexibilidade aliada a disciplina técnica (TDD, CI, refatoração), o que ajuda a manter qualidade mesmo com mudanças frequentes. |
| Participação do Cliente | Muito ativa durante prototipagem e validação de UIs/fluxos; feedback rápido sobre aparência e usabilidade. | Participação contínua através de revisões de sprint, refinamento de backlog e feedback frequente sobre funcionalidades entregues. |
| Riscos | Vulnerável a retrabalho se mudanças ocorrerem após a fase de protótipo ou se protótipos forem usados como solução final sem adequada engenharia. | Risco reduzido graças a entregas curtas, feedback contínuo e automação de testes; porém requer disciplina do time para manter práticas. |
| Complexidade | Processo geralmente mais simples e informal; entretanto, sistemas grandes podem tornar a abordagem complexa se a arquitetura não for considerada. | Práticas e disciplina podem parecer "mais complexas" de início, mas reduzem complexidade técnica a médio/longo prazo (melhor manutenção, menos dívidas técnicas). |
| Métricas | Foco em velocidade de entrega de protótipos, tempo até validação com usuários e taxa de iterações de design. | Métricas típicas: velocity, lead time, qualidade do código (dívida técnica), cobertura de testes e taxa de defeitos. |
| Escalabilidade | Geralmente mais indicada para projetos pequenos ou médios; escalar exige disciplina e adaptações arquiteturais. | Pode escalar para times grandes com frameworks e práticas adicionais (LeSS, Nexus, SAFe), mantendo práticas XP para qualidade. |
| Documentação de usuário | Protótipos servem como artefatos primários para guiar o usuário; documentação formal reduzida. | Documentação funcional mínima e atualizada; ênfase em entrega testada e na comunicação direta com stakeholders. |
| Velocidade de Implementação | Muito rápida nas fases iniciais (prototipagem); velocidade para produto final depende de esforço de engenharia adicional. | Ritmo moderado e previsível em sprints; menos rápido que um protótipo, mas entrega valor consistente e sustentável ao longo do tempo. |
| Documentação | Leve, focada em comunicação direta e nos protótipos. | Leve e funcional — apenas o necessário para compreensão, manutenção e onboarding. |
3.3 Justificativa 🛎️
Considerando o quadro comparativo apresentado, bem como nossas abordagens e ciclo de vida, as vantagens do RAD se mostram mais expressivas em relação ao ScrumXP, especialmente ao avaliarmos fatores como tamanho da equipe, escalabilidade e o perfil do cliente. Neste projeto, o cliente possui conhecimento limitado sobre tecnologias e necessitará de feedbacks constantes e iterações frequentes.
Dessa forma, a adoção do RAD como processo, com seu enfoque em protótipos, representa a opção mais adequada para atender às necessidades do projeto.
Hisórico de Versão 🔄
| Data | Versão | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|