Levantamento de requisitos
Exploraremos a fase crucial da Análise de Requisitos, fundamental para o êxito de um projeto. Investigaremos os riscos associados ao desenvolvimento de software, desde aspectos relacionados ao valor até questões técnicas, com base nas perspectivas de Marty Cagan.
Salientaremos a relevância do "Upstream" no fluxo de desenvolvimento, concentrando-nos na concepção e validação de ideias antes da implementação. Abordaremos componentes essenciais da Análise de Requisitos, como a definição da Persona, compreensão do problema, objetivos da solução e jornada do usuário.
Analisaremos requisitos funcionais e não funcionais, assegurando a coerência com o propósito de conceber soluções eficazes.
Riscos do desenvolvimento de software
Para compreender a importância da Análise de Requisitos, é fundamental examinar os riscos associados ao desenvolvimento de software, conforme enfatizado por Marty Cagan. Esses riscos englobam:
Risco de valor
Este é o risco mais crítico e deve ser priorizado na análise. Ele se relaciona com a possibilidade de o cliente não reconhecer a necessidade do produto. É crucial avaliar se o que está sendo desenvolvido oferece valor suficiente para o usuário a ponto de justificar o investimento ou a adoção do produto.Geralmente, este risco é avaliado pelo Gerente de Produto ou pelo Proprietário do Produto.
Risco de negócio
Este risco envolve a possibilidade de o produto entrar em conflito com os interesses da empresa, resultando em impactos negativos. Para determinar a viabilidade da solução para a empresa que a está desenvolvendo, é preciso fazer as seguintes perguntas:- O produto contribui para os objetivos estratégicos da empresa?
- É financeiramente viável, ou seja, a receita esperada supera significativamente os custos envolvidos?
- O produto apresenta algum risco legal para o negócio?
- Risco de usabilidade
Este risco diz respeito à possibilidade de a solução não ser adotada devido a problemas na experiência do usuário. É essencial analisar este risco para garantir que a solução seja intuitiva e fácil de usar. Geralmente, pode ser validado por meio de testes de usabilidade.
- Risco técnico
Este risco está relacionado à possibilidade de a equipe de desenvolvimento não ter os recursos necessários (técnicos, financeiros, humanos, etc.) para implementar a solução. Este é o risco mais significativo a ser abordado neste curso. Uma maneira de mitigá-lo é seguir os processos de análise de requisitos e refinamento técnico.
A figura abaixo representa Os quatro grandes riscos segundo Marty Cagan. Fonte: Elaborado pela FIAP (2023)
O fluxo de desenvolvimento: Upstream e Downstream
Introduzimos um fluxo de desenvolvimento dividido em Upstream e Downstream. O Upstream engloba fases que mapeiam, exploram, validam e transformam ideias em tarefas de desenvolvimento.
Começamos com o backlog, onde consideramos todas as ideias, priorizamos as mais promissoras e, em seguida, entramos no Levantamento de Requisitos.
O Downstream engloba as fases do início do desenvolvimento, até o Deploy para o usuário final. São as fases de “produção” do sistema.
A figura abaixo representa o Upstream e Downstream. Fonte: Elaborado pela FIAP (2024)
Para evitar problemas no Downstream, ou seja, no desenvolvimento, é fundamental que a pessoa desenvolvedora ou líder técnico se envolva em algumas fases do Upstream. Se negligenciarmos isso, podem ocorrer situações como:
- Não compreensão dos requisitos;
- Imprevisibilidades no desenvolvimento;
- Surgimento de bugs e débitos técnicos.
Solução e Levantamento de Requisitos na Prática
A solução para esses problemas reside no Levantamento de Requisitos, materializado na Documentação da Demanda ou do Produto. Vamos destacar alguns pontos essenciais nessa etapa:
Persona: será necessário entender quem será a pessoa usuária que utilizará a solução. Conhecer a persona é a base para entender o problema e propor a solução adequada.
Problema e jornada atual: compreender a jornada atual da persona é crucial para identificar os problemas que ela enfrenta diariamente (e não os cometer novamente).
Objetivo: qual é o objetivo da solução? Entender as expectativas do(a) cliente ou da área de negócio é vital para o sucesso do desenvolvimento. Com o objetivo claro, fica mais fácil definir “como” iremos fazer a solução.
Jornada da solução: a Jornada da solução são as etapas que a persona percorrerá para resolver o problema do usuário. Ela é essencial para embasar o desenvolvimento e garantir que a solução técnica atenda todas as etapas dessa jornada.
Requisitos funcionais e não funcionais: descrever as funções do sistema e as restrições necessárias para garantir seu funcionamento adequado.
Exemplo prático: sistema de gestão de tarefas colaborativas
- Sistema de CRM Integrado com o Sistema da Empresa.
- Persona: Diretor(a), gerente e analistas de vendas; qualquer cliente que queira uma nova proposta.
Problema e Jornada atual
Atualmente, a equipe comercial utiliza uma planilha Excel para o controle do workflow da área comercial. Isso gera alguns problemas e dificuldades, como a perda de informações do(a) cliente, dificuldade em fazer o follow-up da proposta e falta de um controle gerencial do que está no pipeline.
Jornada atual
Recebe um novo pedido de cotação por e-mail. Esse e-mail nem sempre contém todas as informações necessárias e, ocasionalmente, o analista comercial precisa interagir com o cliente para obter os detalhes essenciais para um novo requisito.
Registra uma entrada na planilha Excel com os detalhes do serviço: "data de recebimento", "nome do cliente", “empresa cliente”, "serviço a ser fornecido", “objetivo da empresa solicitante”.
Coleta também e preenche informações adicionais para a precificação em outra aba da planilha Excel:
- Porte da empresa
- Segmento da empresa
Elabora um PowerPoint com as informações da proposta.
Envia o PowerPoint elaborado por e-mail.
- No decorrer desse processo, o cliente solicita um acompanhamento várias vezes, visto que o prazo de resposta é de 3 dias úteis.
Objetivo com a Solução
Concentrar todos os dados de cotação de clientes em uma única plataforma, assegurando que cada cotação contenha os dados cruciais para fornecer um orçamento preciso, visando aprimorar a eficácia da equipe de vendas e diminuir o tempo de resposta ao cliente. Objetivos específicos podem abranger: incrementar as vendas em 10% por meio de uma segmentação de clientes mais refinada e diminuir pela metade o tempo de resposta ao cliente.
Jornada da solução
A figura abaixo representa A jornada da solução. Fonte: Elaborado pela FIAP (2024)
Requisitos da solução:
- Funcionais: registro de Empresas, registro de novas cotações, envio automatizado de e-mails de acompanhamento, geração automática de proposta, envio automatizado de proposta, rastreamento de e-mail para acompanhamento da resposta à proposta.
- Não funcionais: segurança de dados de alto nível, disponibilidade de 99%, capacidade de escala para suportar até 100 usuários internos e acomodar pelo menos 1000 propostas simultaneamente, desempenho ágil mesmo com grandes volumes de dados.
Nesse formato, o profissional em desenvolvimento terá recursos para estabelecer uma base mais sólida para compreender a demanda e se preparar tecnicamente para analisar a viabilidade, os impactos técnicos e oferecer uma previsão mais precisa.
Refinamento técnico
Veremos o procedimento de aprimoramento técnico de um Sistema de CRM Integrado. Examinaremos minuciosamente cada fase da jornada do usuário no sistema de CRM, desde o recebimento de uma solicitação de orçamento por e-mail até a criação automatizada de propostas. Esse caso prático demonstra vividamente a necessidade de compreender e mapear cada aspecto do processo, assegurando o desenvolvimento de uma solução técnica eficaz e alinhada às demandas do negócio.
Refinamento da jornada do usuário
Este estágio visa fornecer o suporte técnico necessário para a referência que está envolvida neste aprimoramento.
A figura abaixo representa A jornada da solução. Fonte: Elaborado pela FIAP (2024)
Nesta fase, buscamos identificar os requisitos técnicos essenciais para que a solução aborde nosso desafio e englobe todas as fases de nossa jornada. É durante este momento que a liderança técnica ou a figura técnica de referência da equipe obtém o embasamento necessário para iniciar a concepção das abordagens técnicas viáveis para alcançar os objetivos do sistema.
Spikes e POCs
Os Spikes e POCs são abordagens que empregamos para validar soluções técnicas antes do desenvolvimento efetivo. Estas duas formas de validar as soluções são cruciais para mitigar os riscos tecnológicos da solução e garantir que nossa estratégia de desenvolvimento seja eficaz na consecução dos objetivos estabelecidos.
Para definições mais precisas, os Spikes são tarefas de desenvolvimento focadas em explorar novas soluções e adquirir conhecimento. São realizados durante a sprint e frequentemente envolvem fluxos mais complexos, requerendo validações mais elaboradas, o que justifica sua inclusão na sprint.
Uma sprint é um período de tempo fixo, geralmente de duas a quatro semanas, durante o qual uma equipe de desenvolvimento trabalha para entregar um conjunto específico de funcionalidades ou itens de trabalho.
As POCs (Provas de Conceito), por sua vez, são um exercício de validação de uma ideia antes de implementá-la em ambiente de "produção". No contexto tecnológico, esse conceito se aplica à verificação da viabilidade das soluções técnicas para determinar se estas satisfazem nossos objetivos.
Por meio desses métodos, conseguimos obter maior confiança para abordar o problema e adquirimos uma compreensão mais clara das complexidades envolvidas no desenvolvimento, permitindo-nos fornecer estimativas mais precisas.
Desenho da Arquitetura
A elaboração da Arquitetura de um software é uma etapa crucial para compreender como as diversas entidades e informações irão interagir. Para o nosso sistema de CRM, a estrutura da solução pode ser delineada da seguinte forma:
Front-end: Interface do usuário desenvolvida utilizando frameworks modernos como React ou Vue.js, proporcionando uma experiência fluida e responsiva. Esta camada se conecta ao back-end por meio de APIs RESTful ou GraphQL para troca de dados.
Back-end: Construído com linguagens robustas, como Node.js, Python ou .NET Core, o back-end é responsável pela lógica de negócios, processamento e armazenamento de dados. Ele interage não apenas com o front-end, mas também com o banco de dados e outros serviços, como autenticação e autorização.
Banco de Dados: Utilizamos sistemas de gerenciamento de banco de dados relacional (RDBMS) como PostgreSQL ou MySQL para armazenar informações do cliente, transações e interações. Para dados não estruturados ou com alta performance, soluções NoSQL como MongoDB podem ser consideradas.
Serviços de Autenticação: Integração com serviços de autenticação segura, como Auth0 ou OAuth2, para garantir o acesso seguro aos dados dos clientes.
API Gateway: Ponto de entrada unificado para todas as requisições ao sistema, simplificando a gestão de APIs, autenticação, autorização e monitoramento de tráfego.
Serviços de Cloud e Microserviços: Arquitetura baseada em microserviços hospedados em plataformas de cloud como AWS, Google Cloud ou Azure, garantindo escalabilidade e flexibilidade.
Sistema de Filas e Mensageria: Utilização de sistemas de filas como RabbitMQ ou Kafka para processamento assíncrono de tarefas e integração entre diferentes partes do sistema.
A mensageria, ou “messaging”, é justamente o sistema que gerencia todas as formas de comunicação entre empresas e clientes.
Ferramentas de Monitoramento e Log: Implementação de soluções como ELK Stack ou Prometheus e Grafana para monitorar a saúde da aplicação, desempenho e diagnosticar problemas proativamente.
Segurança: Implementação de medidas de segurança em todas as camadas, incluindo criptografia de dados, firewalls e práticas de desenvolvimento seguro para proteger contra vulnerabilidades.
Preenchimento do Requisito Técnico da Solução
Com as Provas de Conceito (POCs) concluídas e a Arquitetura da solução já delineada, a elaboração do requisito técnico da solução é realizada com base nas deliberações feitas durante o processo de refinamento. Neste contexto, o preenchimento deve abordar os seguintes aspectos:
Descrição Detalhada da Solução: fornecer uma visão abrangente da solução proposta, incluindo detalhes técnicos, componentes da arquitetura e como cada parte contribui para satisfazer os requisitos do projeto.
Tecnologias e Ferramentas Utilizadas: especificar as tecnologias, linguagens de programação, frameworks e ferramentas que serão empregadas na implementação da solução, justificando a escolha de cada uma em relação aos requisitos e desafios técnicos identificados.
Integrações e Dependências: identificar quaisquer sistemas externos ou internos com os quais a solução precisará integrar-se, incluindo APIs, serviços de terceiros, bases de dados, etc., e descrever como essas integrações serão gerenciadas.
Estratégias de Implementação e Desenvolvimento: definir a metodologia de desenvolvimento, processos e práticas que serão adotadas pela equipe técnica, incluindo abordagens ágeis, integração contínua/desdobramento contínuo (CI/CD), revisão de código, entre outros.
Segurança e Conformidade: descrever as medidas de segurança que serão implementadas para proteger a solução e os dados manipulados, bem como como a solução atende a regulamentos específicos ou padrões de conformidade relevantes.
Escalabilidade e Manutenibilidade: apresentar como a solução foi projetada para suportar crescimento e mudanças ao longo do tempo, incluindo estratégias para escalabilidade, balanceamento de carga e manutenção.
Testes: detalhar o plano de testes para a solução, incluindo tipos de testes (unitários, integração, desempenho, segurança, etc.), ferramentas a serem utilizadas e como o processo de testes será integrado ao ciclo de vida de desenvolvimento.
Documentação: especificar o tipo de documentação que será fornecida, abrangendo documentação técnica, manuais de usuário e diretrizes de operação e manutenção.
Plano de Implantação: descrever o processo de implantação da solução, incluindo ambientes de desenvolvimento, teste e produção, além de estratégias para rollout e rollback.
Critérios de Aceitação e Validação: definir os critérios específicos que a solução deve atender para ser considerada completa e os métodos que serão utilizados para validar a solução contra esses critérios.
Estimativas
As previsões de esforço no desenvolvimento de software são frequentemente debatidas e, em geral, desafiadoras de se realizar. Muitas vezes, não levamos em conta aspectos cruciais que surgem como surpresas durante o processo de desenvolvimento. Em outras ocasiões, simplesmente não conseguimos avaliar com precisão a complexidade de uma determinada tarefa.
Neste cenário, são apresentadas duas abordagens para estimar o esforço. Uma delas é o Planning Poker, utilizando a sequência de Fibonacci, atribuindo notas como 1, 2, 3, 5, 8..., considerando tanto o tamanho da tarefa quanto sua complexidade técnica. Esse método é valioso para estimular a discussão sobre os impactos do desenvolvimento na equipe, porém é difícil obter estimativas precisas sem um histórico consolidado.
A outra abordagem é o método de Monte Carlo, que pode complementar as pontuações do Planning Poker. Ele fornece percentuais da probabilidade de a equipe conseguir completar uma certa quantidade de pontos dentro do prazo estabelecido. Funciona da seguinte maneira:
A figura abaixo representa Using Monte Carlo Forecasts in your Scrum Events. Fonte: Benjamin Huser-Berta - Medium (2023)
O gráfico apresentado na figura acima, denominado Monte Carlo na Metodologia Ágil, ilustra a quantidade de itens que uma equipe consegue completar com um nível específico de confiança. Por exemplo, no caso mencionado, extraído do artigo "Using Monte Carlo Forecasts in your Scrum Events", do autor Benjamin Huser-Berta, a equipe analisada entrega 27 itens ou mais em 79,7% das sprints, indicando uma probabilidade substancial de alcançar essa quantidade.
Definition of Done
Veremos as distinções e relevâncias dos conceitos de Definition of Ready (DoR) e Definition of Done (DoD) no âmbito do desenvolvimento de software.
A diferença do Definition of Ready e do Definition of Done
Embora ambos sejam essenciais para o gerenciamento de projetos ágeis, o DoR e o DoD têm finalidades distintas. O DoR consiste em um conjunto de requisitos que devem ser atendidos antes que uma tarefa seja iniciada, garantindo sua adequada preparação para o desenvolvimento. Por outro lado, o DoD é uma lista de critérios que uma tarefa deve satisfazer para ser considerada finalizada, garantindo que todos os aspectos de qualidade e funcionalidade tenham sido abordados.
Definition of Ready
O DoR serve como uma barreira de entrada para a qualidade no início das atividades, assegurando que todas as informações essenciais estejam disponíveis e que os requisitos sejam compreendidos e claros. Ele engloba critérios como a precisão da descrição da tarefa, a definição de critérios de aceitação e a identificação de dependências. Essa clareza no início do processo ajuda a prevenir equívocos e retrabalhos, otimizando o fluxo de trabalho da equipe.
Definition of Done
O DoD, em contrapartida, são os critérios indispensáveis para o encerramento das atividades. Ele engloba aspectos como a excelência do código, a execução de testes unitários e de aceitação, revisões de código, atualizações de documentação e a aprovação do Product Owner. O DoD garante que a tarefa não apenas satisfaça os requisitos funcionais, mas também preserve a integridade e a qualidade do produto globalmente.
A importância desses documentos
Esses registros são cruciais para o êxito e a eficácia do desenvolvimento ágil. Eles oferecem clareza e orientação à equipe, estabelecendo expectativas definidas e evitando desperdício de esforços.
Além disso, auxiliam na manutenção da consistência e qualidade ao longo do ciclo de vida do desenvolvimento, facilitando a comunicação e colaboração entre os membros da equipe e stakeholders. Em suma, DoR e DoD são ferramentas indispensáveis para garantir que todas as tarefas sejam abordadas de maneira estruturada e padronizada, contribuindo significativamente para a entrega eficiente e de alta qualidade de produtos de software.
No nosso cenário, o DoR seria:
- Documentação de requisitos elaborada, contendo todas as informações do fluxo de solução;
- Refinamento Técnico concluído;
- Arquitetura da solução delineada;
- Tarefas divididas em itens de desenvolvimento;
- Estimativa das demandas realizada;
- Priorização feita pelo PM ou PO.
O DoD seria:
- Revisão de código;
- Aprovado pela equipe de QA;
- Validado pelo usuário final.