Revisão Ágil + UX

Os métodos ágeis nasceram como resposta aos limites do modelo tradicional em software. Em vez de planejar tudo e entregar no fim, o time entrega em ciclos curtos e aprende com o cliente a cada volta.

Cascata × ágil

Em uma linha: ágil = iterativo e incremental. O deck 4 desenha isso como um laço: os devs entregam valor (resolver problemas usando software) aos clientes, e os clientes devolvem aprendizado aos devs. Agilidade é aprendizado e geração de valor contínuos.

Por que software pede outro jeito

• Software não é carro, ponte ou casa: é abstrato e adaptável. O cascata veio das engenharias tradicionais e não funcionou bem com software.
• O contexto acelera: transformação digital, usuários mudando de comportamento, competição pela experiência e produtos que evoluem em ciclos curtos.
• Por isso, ganha quem aprende mais rápido, e não quem entrega mais rápido.

Manifesto Ágil (2001)

Métodos ágeis são um conjunto de práticas iterativas e incrementais, com foco em entrega contínua de valor, adaptação rápida a mudanças e colaboração intensa com os stakeholders. A base conceitual são os 4 valores do manifesto:

Quando ágil não compensa

Fonte citada no deck 4: Embracing Agile, Rigby, Sutherland e Takeuchi, Harvard Business Review, 2016.

• Mercado estável e previsível.
• Requisitos claros desde o início e que não vão mudar.
• Cliente sem tempo para colaborar com frequência.
• Solução já conhecida, porque um sistema parecido já foi feito.
• Trabalho que pode ser resolvido em sequência, por áreas isoladas (silos).
• Cliente não consegue testar partes antes do produto completo.
• Mudar no fim do projeto é caro ou impossível.
• Mudanças provisórias podem ter impacto catastrófico.

UX é o conjunto de percepções e respostas de quem usa um produto ou sistema: a experiência inteira, com percepção, emoção, eficiência e valor percebido. Não é só a tela.

UX × UI

A frase que o professor repete: UX é decisão de negócio, e não "tela bonita".

As 4 dimensões (deck 3)

• Usabilidade: dá para usar com eficiência e sem esforço desnecessário.
• Acessibilidade: dá para qualquer pessoa usar, inclusive quem tem alguma deficiência.
• Desejabilidade: a pessoa quer usar (atração, emoção, marca).
• Utilidade: resolve uma necessidade real.

UX mexe no resultado financeiro

Experiência ruim vira prejuízo: converte menos, perde mais cliente e encarece a aquisição.

Produto digital nunca fica "pronto"

Atualizações frequentes, feedback imediato, dados em tempo real e concorrência global fazem do produto digital algo sempre em evolução, nunca finalizado. Produtos, usuários e mercado mudam rápido, e por isso é preciso aprender continuamente.

Integrar UX ao ágil é pesquisar, prototipar, testar e ajustar dentro de cada sprint, com o usuário no centro das decisões. Não existe produto ágil sem uma experiência do usuário bem definida.

Design Centrado no Usuário (DCU / UCD)

Princípios (deck 2): empatia, pesquisa, testes constantes e iteração. A pergunta-guia: estamos resolvendo o problema certo?

Etapas (deck 3), nesta ordem:

O foco é resolver problemas reais.

Ferramentas e artefatos

O deck 1 resume: UX começa antes do design.

Linear × integrado (deck 3)

Tradicional:

Ágil integrado: as setas vão e voltam, e tudo acontece dentro de cada sprint.

Princípios de UX no ciclo ágil: pesquisa contínua com usuários, prototipação rápida, testes frequentes e feedback iterativo.

UX no Scrum, na prática (deck 2)

• Pesquisa antes da sprint.
• Prototipação rápida.
• Testes durante o desenvolvimento.
• Ajustes no backlog com o que se aprendeu.

O risco de separar UX e ágil: UX pesquisa isolado, o dev implementa sem validação, falta alinhamento estratégico e a experiência sai fragmentada.

Adaptação contínua

Adaptar-se é competência estratégica: testar hipóteses, medir comportamento, aprender com o erro e ajustar rápido. O ciclo é o mesmo do Lean Startup:

Mentalidade que a disciplina quer formar: pensar no usuário antes da solução, trabalhar em ciclos curtos, validar antes de escalar, usar dados para decidir e integrar UX ao processo ágil.

complementoO deck 1 cita Dual Track Agile e Discovery × Delivery só como tópicos. A ideia: uma trilha de discovery (descobrir o que vale construir, com pesquisa, protótipos e testes) roda em paralelo à de delivery (construir e entregar o que já foi validado).

Ágil e UX só viram resultado com times multidisciplinares, comunicação aberta e decisões tomadas com evidência, não com opinião.

Times multidisciplinares

Composição típica no deck 3: Product Owner, Scrum Master, Desenvolvedores, Designer UX/UI, Analista de Dados e Stakeholders. UX trabalha dentro do time, nunca separado. O deck 2 reforça a ideia com Luis André Barroso, brasileiro e ex-VP de Engenharia do Google: software é um esporte em equipe.

Comunicação e colaboração

• Daily objetiva.
• Backlog transparente.
• Cultura de feedback.
• Retrospectivas estruturadas.

Um ambiente psicologicamente seguro, onde dá para errar e discordar sem medo, melhora o desempenho do time.

Dois tipos de dado

Indicadores comuns: NPS, taxa de conversão, taxa de retenção e tempo de tarefa.

complementoNPS (Net Promoter Score): o usuário dá nota de 0 a 10 para "recomendaria?". NPS = % de promotores (9–10) menos % de detratores (0–6). Tempo de tarefa: quanto a pessoa leva para concluir uma ação, uma medida de usabilidade.

Organizações de alta performance

Iteram rápido, escutam o usuário o tempo todo, medem resultados reais e ajustam a estratégia com base em evidências. O resultado é inovação sustentável e vantagem competitiva, que é a integração final agilidade + UX + dados.

O XP se organiza em três camadas: XP = valores + princípios + práticas. Os valores vêm primeiro, porque cultura é fundamental em software.

Práticas, em 3 grupos

As três em negrito são as que o deck destaca e detalha.

Contratos com escopo aberto

O contrato fixa a equipe e o custo por período, não o escopo: a contratada fornece x programadores para desenvolver o sistema y, por z reais ao mês, com renovação mensal até uma das partes cancelar. Exige maturidade e acompanhamento do cliente.

Vantagens: privilegia a qualidade; o cliente não é enganado com "entregar por entregar"; dá para trocar de fornecedor.

Programação pareada (pair programming)

Dois devs no mesmo código, no mesmo computador. Um estudo com engenheiros da Microsoft (2008) apontou:

Ambiente de trabalho

O time trabalha junto, no mesmo espaço, com story cards e cartazes na parede que deixam o trabalho em andamento visível (feito, esta semana, esta release, a estimar, futuro).

Mob Programming

É a evolução do pair programming: o time inteiro na mesma tarefa, ao mesmo tempo, no mesmo ambiente (ou virtualmente), com um único computador ou ambiente compartilhado. Parte dos princípios do XP e mira colaboração, aprendizado e qualidade.

Os papéis giram com frequência para manter todos engajados. Uma sessão típica:

1. Definir o problema ou a tarefa.
2. Um membro assume como driver.
3. O resto do time navega.
4. As decisões são discutidas em grupo.
5. Os papéis rodam.
6. Tudo em pequenos ciclos de feedback contínuo.

O Scrum organiza o trabalho em sprints, ciclos de duração fixa (time-box). A cada sprint, o sistema cresce com novas funcionalidades funcionando.

O resumo do próprio deck: sprint é evento; PO e devs são papéis; backlog do produto é artefato.

Histórias e o Product Owner

Num sprint, o time implementa algumas histórias de usuário, e cada história é uma funcionalidade (o exemplo do deck é um fórum de perguntas e respostas). Quem escreve as histórias é o PO: papel obrigatório, especialista no domínio e próximo do problema.

As 5 funções do PO: escrever as histórias; explicá-las aos devs durante o sprint; definir os testes de aceitação; priorizar; manter o backlog do produto.

Stakeholders são os clientes e qualquer parte interessada ou afetada pelo sistema, como o jurídico, que se interessa pelo módulo de contratos.

Tipos de PO (exemplo: sistema acadêmico da Pró-reitoria de Graduação): desenvolvimento interno ou terceirizado → o PO é um funcionário da prograd; compra de produto pronto → o PO é um "proxy" do cliente (vendas, marketing).

Backlog do produto × backlog do sprint

Planejamento do sprint, em 2 partes

1. Quais histórias entram: o PO propõe as que quer ver prontas, e os devs dizem se têm velocidade para implementá-las.
2. Como fazer: as histórias viram tarefas, e as tarefas são alocadas aos devs.

Exemplo do deck: a história "Postar perguntas" vira tarefas como interface web (layout, CSS), banco de dados e tabelas, camada de acesso a dados e camada de controle (cadastrar, remover, atualizar).

Time e Scrum Master

• Time pequeno, entre um time de basquete e um de futebol: 5 a 11 membros, sendo 1 PO e 1 Scrum Master.
• Multidisciplinar (devs, designers, cientistas de dados); costuma ser chamado de squad.
• Scrum Master: especialista em Scrum que ajuda o time a seguir o método e os eventos; remove impedimentos não técnicos (ex.: máquinas ruins); não é chefe; pode atender mais de um time.

Eventos ao longo do sprint

Time-box e critério de pronto

Time-box: toda atividade tem duração bem definida. Critérios de conclusão (done criteria): uma história só está pronta se passou nos dois tipos de qualidade.

A tirinha "Feature complete" do deck brinca com o "pronto!" que esquece testes, code review, documentação e dívida técnica.

Quadro, burndown e estimativa

• Scrum board: colunas Backlog → To Do → Doing → Testing → Done. O deck mostra exemplos no GitHub Projects (Mozilla) e no GitLab.
• Burndown chart: eixo X = dias do sprint; eixo Y = soma das horas das tarefas que faltam. A linha desce até zero no último dia.
• Story points: número inteiro para comparar o tamanho das histórias. Escala do deck:

• Velocidade: quantos story points o time implementa em um sprint. A definição de story points é empírica, calibrada pela experiência do time.

Kanban quer dizer "cartão visual". É um fluxo contínuo de trabalho num quadro, sem sprints, controlado por limites de trabalho em andamento (WIP).

Kanban × Scrum

A sugestão do deck: talvez começar com Scrum e depois migrar para Kanban.

Sistema pull

Ninguém empurra tarefa para ninguém: cada membro puxa o trabalho.

1. Escolhe uma tarefa para trabalhar.
2. Conclui a tarefa e move o cartão para a frente no quadro.
3. Volta ao passo 1.

O quadro

As colunas grandes são os passos (no exemplo: Backlog, Especificação, Implementação, Revisão de código). Cada passo tem duas subcolunas, em andamento e concluídas, e os cartões andam da esquerda para a direita com o tempo.

Limites WIP (Work in Progress)

WIP é o número máximo de tarefas em um passo, contando as em andamento e as concluídas daquele passo. Serve para:

• Criar um fluxo de trabalho sustentável, sem sobrecarregar o time. O WIP é um "acordo" entre o time e a organização e representa a capacidade do time.
• Evitar que o trabalho se acumule em um passo só.

Duas regras especiais: na Especificação, WIP = histórias em especificação + grupos de tarefas especificadas (cada linha do quadro é um grupo, porque tarefas na mesma linha vêm da mesma história). Na Revisão de código, só conta a subcoluna "em revisão"; as revisadas não contam.

Exemplo do deck (p. 83), com limites 2, 5 e 3:

• Violação (p. 86): 6 tarefas em Implementação com WIP 5 → o quadro não é válido.
• No limite (p. 87): Implementação com 5 de 5 → talvez seja hora de revisar tarefas e liberar o fluxo.

O Lean nasceu no Sistema Toyota de Produção com um objetivo: eliminar desperdícios e maximizar o valor para o cliente. Hoje aparece em software, gestão de produtos e processos organizacionais.

Princípios gerais

Eliminar desperdícios · aprendizado contínuo · entrega rápida · empoderamento da equipe · otimização do fluxo.

O que conta como valor

No Lean, quem define valor é o cliente. Uma atividade só gera valor se resolve um problema real, se o cliente estaria disposto a pagar por ela e se contribui diretamente para o resultado final. O que não agrega valor é desperdício.

complementoDesperdício em software, na prática: funcionalidade que ninguém usa (superprodução), esperar aprovação ou ambiente (espera), trabalho pronto e não entregue (estoque), bug (defeito).

Fluxo de valor e melhoria contínua

• Fluxo de valor (value stream): todas as etapas para entregar valor ao cliente (ideia → desenvolvimento → testes → entrega). O Lean quer otimizar esse fluxo.
• Value Stream Mapping (VSM): ferramenta para mapear o processo, achar gargalos, reduzir desperdícios e melhorar o fluxo.
• Kaizen: melhoria contínua, feita de pequenas melhorias constantes, com a equipe inteira envolvida e ajustes contínuos no processo. É base do Lean.

Lean Startup e MVP

Lean Startup é o Lean aplicado ao desenvolvimento de negócios, criado por Eric Ries (livro A Startup Enxuta). O objetivo é validar ideias rápido com o mercado, girando o ciclo:

MVP (Produto Mínimo Viável): a versão mais simples do produto que já gera aprendizado. Reduz riscos, valida hipóteses e traz feedback rápido do mercado; é muito usado em startups e inovação.

Lean como cultura, e ao lado do ágil

Lean não é só técnica, é cultura: exige transparência, colaboração, aprendizado contínuo e foco no cliente. Traz menos desperdício, mais produtividade, mais qualidade, entregas mais rápidas e mais valor ao cliente.

Ele complementa Scrum, Kanban e XP: o ágil foca em gestão e desenvolvimento; o Lean, em eficiência e fluxo de valor.

O SAFe escala as práticas ágeis para grandes organizações: integra muitas equipes, melhora o alinhamento estratégico, acelera a entrega de valor e garante governança e coordenação.

Origem e princípios

Criado por Dean Leffingwell, inspirado em Lean Thinking, desenvolvimento ágil, DevOps e sistemas complexos. É hoje um dos frameworks mais usados para escalar o ágil.

Princípios (Lean + ágil): pensamento sistêmico · entrega incremental de valor · limitar o trabalho em progresso · decisão descentralizada · cultura de melhoria contínua.

Os 4 níveis

ART, PI e PI Planning

Lean Portfolio Management: alinhar estratégia e execução, investir no que tem mais valor, gerir o fluxo de investimentos e promover inovação.

Benefícios: alinhamento organizacional, previsibilidade das entregas, coordenação entre equipes, escalabilidade e visibilidade estratégica. É amplamente usado em grandes empresas e projetos complexos.