Palestra aos alunos da disciplina de Engenharia de Software do curso de Análise e Desenvolvimento de Sistemas da Faculdade de Tecnologia (FATEC) de Sorocaba/SP em março de 2023.
Sou ex-aluna do curso, que antigamente se chamava “Processamento de Dados”, e fiquei muito feliz ao receber o convite para falar do tema que tem sido meu dia a dia profissional desde 2021 (junto com SEO, é claro) no mesmo lugar que estudei há anos. A seguir, o conteúdo apresentado aos alunos.
Desenvolvimento Cascata vs. Manifesto Ágil
Antigamente, na época em que estudei na FATEC, era ensinado e adotado o modelo cascata de desenvolvimento, em que cada etapa do desenvolvimento do software era feita após a conclusão da etapa anterior, passando por Requisitos, Projetos, Codificação, Testes, Implantação e Sustentação (Manutenção)… etapas que podem levar meses (e até anos).
O maior problema sobre isso é que, quando a entrega acontece…. o problema, a necessidade, o escopo, a prioridade… mudaram! Tempo e dinheiro foram gastos em uma solução que não serve mais em sua totalidade. Quer exemplo maior do que o coronavírus sobre mudança de prioridade nas empresas?
Em 2001, foi publicado o manifesto ágil:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Escopo flexível
Sabendo que o escopo vai mudar… ideal é que não sejam flexíveis:
- Prazo;
- Custo;
- Qualidade.
Se o tempo passou e nada do escopo ou das prioridades mudou… algo está errado…
…ou o produto digital é inútil
…ou está sendo visto pelas pessoas erradas.
Mudanças de requisitos precisam ser bem vindas no ágil!
Metodologia Ágil
Entregas fatiadas e incrementais
É muito fácil pensar com a cabeça em “modo cascata”. Pensar em entregar uma nova funcionalidade completa e perfeita – porém, levando mais tempo para colocar no ar, e o pior: com risco de descobrir depois que os usuários não estão utilizando, não está trazendo resultado para a empresa, não está entregando valor.
Por isso, pensar em fatiar entregas é um exercício, precisa se tornar um hábito.
Ao fatiar entregas de software:
- Usuário já começa usar a funcionalidade (mínimo que seja);
- Você já começa a medir;
- E é capaz de corrigir algo ou quem sabe até mesmo descartar algum incremento, revisar as prioridades.
Medir!
Como você sabe se a 1ª entrega comprova seu uso e vale a pena incrementar? MEDINDO!
- Quais métricas monitorar? Identifique como conferir resultados da nova funcionalidade.
- Está coletando os dados? Certifique de há registro dos dados necessários para as métricas que você definir.
Scrum
Sprint
Período/Ciclo de desenvolvimento para “entregas rápidas”. Ex: 2 semanas.
Product Owner (PO)
- Dono do produto (#SQN);
- Líder do time? NÃO! Não tem líder, todo mundo é responsável pela entrega (embora o fato do PO cobrar entregas, pode gerar esse sentimento no time);
- Precisa saber programar? Não, mas ter noção de tecnologia ajuda muito.
Scrum Master (SM)
- Reforça práticas do ágil;
- Acompanha entregas vs. esperado da Sprint;
- Destrava impedimentos;
- Facilitador, “líder-servidor”;
- NÃO pode ser desconetado do negócio! Senão, pode comprometer as entregas que o PO precisa, se o SM não compreender as necessidades do negócio.
Cerimônia Refinamento
Se você é desenvolvedor, por favor ajude o PO durante o refinamento em…:
- Discutir o problema em busca da melhor solução;
- Avaliar se a atividade é viável;
- Identificar possíveis impedimentos;
- Se é possível fatiar a entrega (seja para entregar primeiro uso ao cliente ou até mesmo para entender se é possível desenvolvedores atuarem de maneira simultânea);
- E como fatiar as user stories!
User Story & Cerimônia Planning
- EU, Paula 34 anos, fã de compras online
- QUERO comprar no site produto do meu tamanho correto
- PARA não ter trabalho de trocar ou devolver, mas receber produto e já utilizar de imediato
Obviamente, apenas a estória acima não é suficiente para o desenvolvedor saber qual é o problema e analisar qual melhor solução, mas apenas qual expectativa do cliente se deseja atender.
É fundamental complementar a tarefa com o descritivo do problema, insumos/dados que embasam a situação (especialmente se a tarefa for correção de bug), documentação técnica (quando houver, ex: credenciais, endpoints, etc), possível solução (quando já houver) e critérios de aceite para que o time de QA (Quality Assurance – testes) identifique tudo que precisa validar para aprovar ou reprovar a atividade.
Com a user story criada e refinada, a tarefa é discutida na Planinng em que cada desenvolvedor vota com alguma pontuação levando em consideração a complexidade. Se as pontuações forem muito diferentes… os desenvolvedores deverão argumentar a razão da pontuação considerada e entrarem em um consenso. Há times que utilizam outras formas para pontuar, como modelo T-Shirt.
Cerimônia Review
Ao final da Sprint, os desenvolvedores apresentam as entregas ao Product Owner.
- A entrega foi de acordo com o que foi pedido?
- User story mal escrita = entrega equivocada!
- Atendeu a todos os critérios de aceite?
- Foi concluída por completo ou terá que seguir em nova Sprint?
- Erramos na pontuação estimada na Planning?
Cerimônia Retrospectiva
Análise do que funcionou bem na Sprint e o que poderia ser melhor, para ser feito na próxima Sprint.
A pessoa que atua como Scrum Master pode ser facilitadora da cerimônia.
- O que foi bom?
- O que foi ruim?
- O que devemos começar a fazer?
- O que devemos parar de fazer?
Priorização de Backlog
- Foco no problema, não na solução;
- Qual entrega de valor ao negócio (retorno financeiro, redução de problemas) vs. esforço?
- Metas & OKR: estamos na mesma direção da estratégia da empresa?
- GUT: Gravidade, Urgência e Tendência;
- Há alguma alternativa paliativa até que seja desenvolvida a demanda?
- Há algum evento próximo? Ex: Black Friday;
- Há prazo legal para adequação? Ex: LGPD.
Frases para gravar!
- Ame o PROBLEMA, não a solução;
- Aprenda a SABER dizer NÃO;
- EFICÁCIA: fazer a coisa certa (o quê);
- EFICIÊNCIA: fazer certo a coisa (como);
- Menos achismos, MAIS DADOS;
- ESTRATÉGIA não é apenas sobre o que fazer, mas também sobre o que NÃO FAZER;
- COMUNICAÇÃO é fundamental.
Na prática…
- Nem tudo será “by the book”;
- Nem sempre conseguimos aplicar tudo o que gostaríamos, e isso faz parte;
- “Top down” também faz parte;
- Parece fácil, mas não é.
Para saber mais
Artigo “Equipes ágeis, Scrum e os papéis Product Owner e Product Manager“.
Podcast
Livros
- Livros sobre agilidade do autor Paulo Caroli
- Livros sobre agilidade e Scrum da Casa do Código
- Livro Gestão Moderna de Produtos Digitais do autor Diego Eis
Eventos
Certificação para Product Owner: confira diferenças entre CSPO® e PSPO™ e como renovar a certificação CSPO®.
E qual a relação disso tudo com SEO, foco deste blog?
Conforme relatei no artigo “Google Meetup SP – SEO além do Marketing: SEO na estratégia do produto“, meu foco tem sido menos em SEO desde 2021 (embora ainda acompanhando SEO de perto), e maior em metodologias ágeis e Produtos Digitais, pois atualmente atuo com Product Owner em uma squad Scrum.
O objetivo é continuar o Blog sobre SEO, tema que gosto muito, mas naturalmente terá mais conteúdo sobre Produtos Digitais e Metodologias Ágeis passando por aqui, até porque é um movimento de carreira que pode acontecer com outros profissionais de SEO.
Fontes das imagens:
- Capa do artigo e outras imagens de mesma identidade visual: https://www.canva.com
- Imagem Manifesto Ágil: https://agilemanifesto.org/
- Imagem MVP: https://medium.com/neemz-product/the-product-manager-and-the-mvp-a0c618b0d8fa
- Imagem Scrum: https://greenique.de/blog/scrum-vs-kanban