Com a popularização das práticas de desenvolvimento ágil de software, a forma de se pensar artefatos de software e de combinar esses artefatos na produção de software tem mudado também.
Atualmente, no Brasil e em todo o mundo, a tríade Epic, Feature e User Story são os artefatos mais utilizados para estruturação de backlog de produto (product backlog) e para uso em backlog de sprints (sprint backlog).
Tendo a dizer que talvez pelo menos 50% das organizações que estando estão caminhando para um processo produtivo orientado ao mindset ágil estão utilizando esses artefatos para tratar o escopo de seus produtos de software.
Para compararmos, antes de começarmos a falar mais sobre cada um dos três artefatos, vamos fazer uma rápida comparação destes artefatos com outros equivalentes utilizados em empresas com processos mais tradicionais.
Um Epic é o equivalente ao conceito de Módulo.
Geralmente temos um sistema e esse sistema é dividido em módulos, que agrupam funcionalidades (geralmente disponíveis através de interface gráfica).
Uma Feature faz parte de um Módulo, e possui seus Requisitos Funcionais e suas Regras de Negócio.
Uma User Story é uma função da Feature, e está associada a ela. Equivale aos Requisitos Funcionais de uma interface gráfica, por exemplo.
Requisitos Não Funcionais geralmente atendem/suportam mais de um Requisito Funcional ou funcionalidade do sistema.
Na visão dos três artefatos que estamos tratando neste post, os Requisitos Não Funcionais equivalem a Features (afinal o aspecto não funcional do produto também é parte do produto) e seu escopo é representado em User Stories (geralmente chamamos de “histórias técnicas) quebradas e de menor tamanho.
Obs.: mas não é boa prática termos “histórias técnicas”, para isso devemos usar artefatos como Spike, Technical Debt, Creep etc.
Abaixo segue um exemplo desta estrutura, e a correlação entre os artefatos “novos e antigos”.
Vamos falar mais sobre isso neste post, continue conosco! 🙂
Relação com modelos tradicionais e ágeis
Quando se fala sobre os artefatos Epic, Feature e User Story Story, geralmente relaciona-se com os modelos de desenvolvimento ágeis.
/* “se o processo for ágil tem que usar História de Usuário, senão não é ágil”. Na realidade, nem existe desenvolvimento ágil. Agilidade é mindset! E este mindset vai muito além da produção de software, se aplica até a clínica veterinária, por exemplo */
Na realidade, do ponto de vista prático, não há muita diferença se compararmos os artefatos que estamos tratando neste post com os artefatos “mais tradicionais” (como comparamos anteriormente, na imagem).
Importante ficar claro que podemos utilizar Epic, Feature e User Story em projetos Waterfall, por exemplo.
A pergunta que sempre deve ser feita é: faz sentido?
E também podemos usar o conceito de Módulos, Funcionalidades Gráficas e Requisitos Funcionais e Regras de Negócio em projetos “ágeis”.
XP e SAFe solidificaram estes artefatos
Um dos frameworks ágeis mais antigos e interessantes (na minha opinião) é a XP, ou Extreme Programming.
A XP trouxe consigo o conceito de User Story e em sua filosofia, o mindset de que as histórias devem ser INVEST:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Obs.: em outro post falaremos muito sobre cada uma das letras acima.
Além das histórias deverem ser INVEST, com a chegada do mindset Lean Thinking na produção de software, começou-se a perceber que, conforme as “entrelinhas do manifesto ágil”, não havia sentido em gerar desperdício pensando, escrevendo e discutindo histórias do futuro.
Mesclando Lean Thinking e mindset ágil, temos a conclusão de que pensar em detalhes no futuro do escopo de um produto é desperdício garantido.
Mas grande empresas, diferente de startups, precisam ter alguma visão de médio/longo prazo em relação aos seus produtos.
/* executivos não pensam (e nem vão pensar tão cedo) em entregas curtas, testes de hipóteses, feedback, e “no final a gente vê como fica”. E não acho que isso seja ruim, é importante equilibrar as coisas */
Então conceitos como Epic e Features começaram a ser utilizados nos backlogs de produtos das empresas que estavam utilizando Scrum, XP, frameworks proprietários orientados à agilidade, dentre outros.
Mesmo sem os detalhes todos antes de começar a desenvolver o software (como no mundo Waterfall), aquilo que é de curto prazo se detalha, o que não é fica macro, mas não “invisível”.
Estas visão que os executivos tanto precisam é viabilizada através de Epics e Features agrupados com contextos de produto (product backlog que permite termos um product roadmap).
O ágil então começou a ser pensado para grandes empresas, e surgiu o conceito de “ágil em escala“.
Hoje um dos frameworks mais difundidos para lidar com ágil em escala é o SAFe (Scaled Agile Framework).
No SAFe Epic, Feature e User Story (tem outros artefatos, como Themes, Tasks etc. mas não se aplicam neste post) são os principais artefatos de especificação utilizados.
Relação entre Epic, Feature e User Story
Na imagem acima temos cinco artefatos/conceitos:
- Theme (tema)
- Epic (épico)
- Feature (funcionalidade/característica)
- User Story (história de usuário)
- Task (tarefa)
Há uma relação de realização entre os artefatos (como podemos ver no diagrama de classes que usei para representar na imagem acima).
O relacionamento entre os artefatos é:
- 1 Theme é realizado por 1 ou muitos Epics.
- 1 Epic é realizado por 1 ou muitas Features.
- 1 Feature é realizado por 1 ou muitas User Stories.
- 1 User Story é realizada por 1 ou muitas Tasks.
No tópico seguinte vamos entrar no detalhe sobre estas relações e nos detalhes sobre cada artefato (Epic, Feature e User Story).
Neste post não vamos entrar no detalhe sobre o que é Theme (Tema) e Task (Tarefa), mas segue uma definição para contextualizar melhor (caso você não conheça previamente do que se trata):
- Theme (Tema): são assuntos nos quais os Epics (épicos) se agrupam, e geralmente são definidos conforme o contexto de negócio em que o épico está. Por exemplo: numa empresa há uma iniciativa de “Diminuir a inadimplência para vendas a prazo”. Isso pode ser o tema, e todos os épicos agrupados neste tema são orientados para realizar a visão do tema.
- Task (Tarefas): são tarefas que devem ser realizadas para realizar uma histórias de usuário (User Story). Uma histórias de usuário agrupa todas as tasks referentes a ela. Por exemplo: no Sprint X de uma equipe há uma histórias chamada “Filtrar lista de pagamentos atrasados por age da dívida”, e para realizar esta histórias várias tarefas tem que ser realizadas (estruturar query para buscar dívidas por age, fazer tunning na base de títulos para atender a algum requisito não funcional de performance, criar índices em algumas tabelas do banco de dados, implementar testes unitários dos métodos de busca etc.). Estas tarefas, necessárias para realizar a histórias, são as tasks.
Epic, Feature e User Story
Abaixo, vamos abordar sobre algumas dimensões comuns, os três artefatos.
Epic (Épico)
Objetivo
O objetivo de um Épico é realizar um tema de negócio. Podem haver 1 ou mais épicos agrupados sob um tema.
Quando todos os épicos do tema estiverem concluídos, o tema está finalizado.
Um épico agrupa 1 ou muitas features (funcionalidades/características) que estão no contexto do épico.
Exemplo: para o tema “Diminuir a inadimplência para vendas a prazo” temos um épico chamado “Implementação de políticas de trava de parcelamento para clientes com nota abaixo de 8”.
Duração
A duração de um épico deve ser maior que 1 mês, mas não maior que 3 meses.
Maior que 1 mês, pois a boa prática de previsibilidade preza que uma feature não tenha mais que 1 mês, e um épico deve ter no mínimo 1 feature.
Menor que 3 meses pois a boa prática preza que, em contextos ágeis, trabalhemos com horizontes de 3 meses, revisitando a estratégia do produto a cada trimestre (quartil).
Medida de Tamanho
Um épico deve ser estimado utilizando técnicas como Tamanho de Camisa, ou Contagem de Pontos de Função Indicativa.
Nível de Gestão
Épicos são definidos no nível estratégico de uma empresa (com ressalvas para contextos de startups, onde são poucas as pessoas e a cultura da empresa já nasce [ou pode nascer] ágil).
A realização de um épico gera como efeito direto a realização de uma ação estratégica da empresa, através da entrega de um produto novo ou incrementos num produto existente.
Épicos são gerenciados em nível de portfólio de produto, geralmente por um Product Manager (Gerente de Produtos) ou profissional equivalente.
Medida de Progresso
O progresso da produção de um épico deve ser deve ser o progresso da conclusão das features agrupadas nele, que o realizam.
O progresso em termos de efetividade de resultados do produto para o negócio deve ser medido através de ferramentas como KPIs ou OKRs.
Responsável
O profissional responsável por gerenciar o progresso da produção dos épicos e a eficiência/eficácia do ponto de vista de resultado de negócio, deve ser alguém como um Product Manager (Gerente de Produto).
Em algumas empresas esse papel pode ser o PO (Product Owner) ou BO (Business Owner).
Feature (Funcionalidade/Característica)
Objetivo
O objetivo de uma Feature é realizar um Épico, podem haver 1 ou mais features agrupados sob um Épico.
Quando todas as Features do Épico estiverem concluídas, o épico está finalizado.
Uma Feature agrupa 1 ou muitas User Stories (histórias equivalem a requisitos funcionais) que estão no contexto da Feature.
Exemplo: para o épico “Criação do dashboard de vendas” temos uma feature chamada “Implementar dashboard de vendas mensais de varejo”.
Duração
A conclusão de uma feature deve ser menor que 1 mês e maior que 1 semana.
Menor que 1 mês, pois a boa prática de previsibilidade preza que uma feature não tenha mais que 1 mês (do contrário tem status de épico), além do fato de que maior que isso, fatalmente gerará uma funcionalidade altamente acoplada.
Menor que 1 semana pois a boa prática preza que, em contextos ágeis, menor que 1 semana é pequeno demais para a entrega ter status de feature (passa a ser uma história), podendo gerar funcionalidades sem a completude necessária para ser uma entrega de valor.
Medida de Tamanho
Uma feature deve ser estimada utilizando técnicas como Tamanho de Camisa, ou Contagem de Pontos de Função Estimativa.
Nível de Gestão
Features são definidas no nível estratégico/tático de uma empresa (salvo no contexto de startups, onde são poucas as pessoas e a cultura da empresa já [pode nascer] nasce ágil).
A realização de uma feature gera como efeito direto a realização de uma ação tática da empresa, através de um incremento de um produto.
Nível de Controle
Features são gerenciadas em nível de programa de produto, geralmente por um Product Manager (Gerente de Produtos) ou mesmo pelo PO (Product Owner).
Medida de Progresso
O progresso da produção de uma feature deve ser deve ser o progresso da conclusão das user stories (histórias) agrupadas nela, que a realizam.
O progresso em termos de efetividade de resultados do produto para o negócio deve ser medido através de ferramentas como KPIs ou OKRs.
Responsável
O profissional responsável por gerenciar o progresso da produção dos épicos e a eficiência/eficácia do ponto de vista de resultado de negócio, deve ser alguém como um Product Manager (Gerente de Produto).
Em algumas empresas esse papel pode ser o PO (Product Owner) ou BO (Business Owner).
User Story (História de Usuário)
Objetivo
O objetivo de uma User Story é realizar uma Feature e podem haver 1 ou mais histórias agrupadas sob uma Feature.
Quando todas as histórias da Feature estiverem concluídas, a feature estará finalizada.
Uma história de usuário agrupa 1 ou muitas Tasks (tarefas são micro atividades que precisam ser realizadas para que a história se realize) que estão agrupadas na história.
Exemplo: para o Feature “Implementar dashboard de vendas mensais de varejo” temos uma história chamada “Implementar indicador de vendas por região”.
Duração
A conclusão de uma história deve ser menor que 1 semana e maior que 1 dia.
Menor que 1 semana, pois a boa prática de estimativas e controle preza que uma história não tenha mais que 1 semana (do contrário tem status de feature), além do fato de que maior que isso, fatalmente gerará uma história altamente acoplada.
Maior que 1 dia pois a boa prática preza que, em contextos ágeis, menor que 1 dia é pequeno demais para a entrega ter status de história (passa a ser uma task), podendo gerar requisitos sem a maturidade que uma história INVEST demanda.
Medida de Tamanho
Uma história deve ser estimada utilizando técnicas como Story Points, Business Complex Points, ou Contagem de Pontos de Função Detalhada.
Nível de Gestão
User Stories são definidas no nível operacional de uma empresa.
A realização de uma história gera como efeito direto a realização de uma ação tática da empresa, através de realização de requisitos necessários para materializar uma feature.
Nível de Controle
User Stories são gerenciadas em nível do time do produto (time Scrum, por exemplo), geralmente por um PO (Product Owner) ou até mesmo pelo time de desenvolvimento.
Medida de Progresso
O progresso da produção de uma história deve ser deve ser o progresso da conclusão das tasks (tarefas) agrupadas nela, que a realizam.
O progresso em termos de efetividade de resultados do produto para o negócio deve ser medido através de ferramentas como KPIs ou OKRs.
As histórias sensibilizam pouco os resultados do produto, geralmente o lançamento da feature na qual as histórias pertencem é que sensibiliza os indicadores do negócio.
Responsável
O profissional responsável por gerenciar o progresso da produção das histórias deve ser alguém como um Product Owner (Dono do Produto) ou papel equivalente.
Product Backlog x Sprint Backlog
Projetos ou esteira de produtos (Squad por exemplo) que rodam sob o framework Scrum utilizam os conceitos de Backlog de Produto (product backlog) e Backlog do Sprint (sprint backlog).
O objetivo é organizar o trabalho a ser feito, de maneira sistematizada, em um backlog bem priorizado e estimado, dentro da realidade.
Para contextualizar apenas (não vou entrar no detalhe das características dos tipos de backlog citados acima), o backlog de produto é composto por épicos e features, enquanto o backlog do sprint é composto de histórias .
/* mas se você ficar com dúvida sobre o assunto pode usar os comentários que posso ajudar */
Conclusão
Falamos um pouco sobre Epic, Feature e User Story.
São três dos principais níveis de granularidade de artefatos de especificação de produtos que usamos atualmente, principalmente em projetos realizados em contextos ágeis.
Obviamente que o assunto não se esgota aqui, este post é apenas uma referência geral, há muito o que falar.
Fique à vontade para usar os comentários, no que eu puder ajudar ou simplesmente trocar ideias, fico à disposição!
E devemos lembrar sempre: agilidade não tem a ver com as tecnologias, métodos ou técnicas aplicadas para desenvolver o software.
Agilidade é mindset, mentalidade, forma de pensar.
E melhor que usar Epic, Feature e User Story, é pensar verdadeiramente ágil!
Abraço!