Forem: Lucas Lima

Gerenciamento de projetos ágeis: Monitorando o progresso e entregando os incrementos

Lucas Lima — Fri, 16 Aug 2024 00:56:19 +0000

No contexto do desenvolvimento ágil, o gerenciamento de projetos desempenha um papel crucial na entrega contínua de valor ao cliente. Neste texto, exploraremos estratégias e técnicas para monitorar o progresso e garantir que os incrementos sejam entregues com sucesso.

Como monitorar o progresso do projeto?

O gráfico de Burn Down é uma ferramenta essencial para monitorar o progresso de um projeto ágil, como o Scrum. Ele visualiza a quantidade de trabalho restante ao longo do tempo. Existem dois tipos principais: o Burn Down do Backlog do Produto, que mostra a soma dos esforços restantes ao longo das sprints, e o Burn Down da Sprint, que representa o trabalho restante dentro de uma sprint específica, geralmente em horas ou dias. Esses gráficos ajudam a equipe a avaliar seu planejamento, execução das histórias, e fazer ajustes conforme necessário para atingir os objetivos da sprint.

Gráfico de burndown do produto (Release)
O gráfico de burndown do produto (Release Burndown Chart) registra a soma dos esforços restantes do backlog ao longo do tempo, atualizando ao final de cada sprint para refletir o progresso. No eixo horizontal estão as sprints e no vertical, o trabalho restante. Medido em pontos de história ou dias, ele mostra a quantidade de trabalho restante e ajuda a prever o término do projeto. Para projetos com muitas mudanças, um gráfico alternativo pode ser usado, mostrando trabalho adicionado ou removido em cada sprint, ajudando a visualizar tendências e prever o fim do projeto.

Gráfico de burnup
Representam o progresso na entrega do trabalho, mas com diferenças na apresentação dos dados: o burndown mostra o quanto falta para atingir a meta, enquanto o burnup mostra o que já foi feito até o momento. No eixo horizontal, mede-se o tempo, e no eixo vertical, o montante de trabalho em pontos de história, horas, etc. O gráfico de burnup possui duas linhas: a curva, que representa o trabalho entregue, e a reta, que representa o trabalho solicitado. A distância entre essas linhas indica o trabalho restante. Esse gráfico permite análises de escopo versus entregas, alertando sobre possíveis problemas quando o escopo cresce mais rapidamente que as entregas, e sugere alternativas como checar impedimentos, alertar o cliente, ou aumentar a equipe.

Cumulative flow diagram (Diagrama de fluxo cumulativo)
É uma ferramenta usada para medir e exibir o progresso de um projeto, especialmente popular entre praticantes do Kanban. Ele exibe o progresso dos itens através de diversas fases até a conclusão, ao contrário do gráfico de burndown, que não mostra o estado dos itens antes de estarem prontos. Para montar um CFD, imagine um processo de produção com várias etapas, como uma confeitaria com fases de preparar massa, assar, rechear e confeitar. O gráfico é construído marcando pontos que representam a quantidade de itens em cada fase ao longo do tempo e preenchendo as áreas entre esses pontos com cores diferentes para cada fase. Este gráfico permite a análise do tempo médio de processamento e entrega (lead time) e o tempo de ciclo (cycle time), além de monitorar a quantidade de trabalho em progresso e a relação entre taxas de entrada e saída de itens. Em um fluxo contínuo, taxas de entrada e saída paralelas são ideais, enquanto em projetos, a taxa de saída deve eventualmente superar a de entrada para completar o projeto.

Entregando o incremento

A revisão da Sprint serve para inspecionar os resultados da Sprint e planejar adaptações futuras. Nessa reunião, o Time Scrum apresenta seu trabalho para as partes interessadas e discute o progresso em direção à meta do produto. A reunião, que pode durar até 4 horas para Sprints de um mês, permite a entrega de incrementos e a coleta de feedback para ajustar o backlog do produto. Apenas itens totalmente finalizados são apresentados em uma demonstração prática. O evento é informal e colaborativo, com o dono do produto geralmente comandando a agenda e os desenvolvedores apresentando os resultados. O ScrumMaster assegura que a reunião ocorra dentro do tempo adequado e orienta os participantes sobre seus objetivos.

Retrospectiva da Sprint
A retrospectiva da Sprint é uma reunião realizada após a revisão da Sprint para identificar lições aprendidas e discutir melhorias. Com duração de até 3 horas para Sprints de um mês, o objetivo é inspecionar aspectos como pessoas, processos, ferramentas e a definição de pronto. A equipe Scrum reflete sobre o que foi bem e o que precisa melhorar, utilizando métodos como post-its para destacar pontos positivos e negativos. A reunião deve resultar em um plano de ações para implementar melhorias. Todos os membros do time Scrum participam igualmente, sem distinção de papéis, em um ambiente colaborativo e informal. Existem diversas formas de realizar essa retrospectiva e trabalhar ela de forma lúdica pode ajudar a quebrar o gelo entre os membros do time scrum e os superiores para entender o que pode ser melhorado, segue alguns exemplos de templates no MIROVERSE.

Speed boat
A retrospectiva da Sprint pode ser realizada de forma lúdica utilizando a ferramenta Speedboat. Neste jogo, a equipe visualiza seu progresso como uma viagem de barco rumo a uma ilha paradisíaca. Os membros anotam em post-its seus objetivos (ilha), forças impulsionadoras (vento), impedimentos (âncoras) e riscos (rochas). A atividade incentiva a reflexão individual e a expressão das frustrações de forma escrita, facilitando a identificação de pontos fortes e áreas de melhoria. Após a análise individual, a equipe discute coletivamente os tópicos mais relevantes, priorizando ações para minimizar riscos e remover impedimentos, promovendo a melhoria contínua de forma divertida e eficaz.

O gerenciamento de projetos ágeis desempenha um papel crucial na entrega bem-sucedida de produtos e serviços. Ele permite que as equipes se adaptem rapidamente às mudanças, respondam às necessidades do cliente e mantenham o foco na criação de valor. Além disso, o gerenciamento ágil promove a colaboração, a transparência e a melhoria contínua.

É óbvio que nem tudo funciona perfeitamente. No entanto, ao monitorar o progresso o projeto, executar as sprints, realizar estimativas de forma assertiva e gerenciar o backlog do produto, podemos fazer com que os incrementos sejam entregues da melhor forma possível e alinhada aos objetivos do negócio. Esses artefatos atuam como facilitadores, promovendo a comunicação entre as partes interessadas, removendo impedimentos e garantindo que a equipe esteja alinhada com o projeto. Em resumo, o gerenciamento ágil é essencial para o melhorar qualquer projeto, permitindo que as organizações se adaptem, inovem e entreguem valor da melhor forma possível.

Gerenciamento de projetos ágeis: Executando a sprint

Lucas Lima — Wed, 07 Aug 2024 12:13:15 +0000

Uma sprint é um período de tempo fixo durante o qual uma equipe de desenvolvimento trabalha em funcionalidades específicas de um projeto. Nesse texto iremos falar o básico sobre incrementos, artefatos e possíveis impedimentos na sprint.

Criando o incremento
O incremento no Scrum é a soma de todos os itens completados do backlog do produto durante uma sprint, junto com incrementos de sprints anteriores. Ele representa uma nova versão do produto com funcionalidades adicionadas, sendo revisado em reuniões de revisão da sprint para fornecer valor aos stakeholders. O incremento deve obrigatoriamente atender à definição de pronto, garantindo que esteja alinhado aos padrões de qualidade estabelecidos pelo time Scrum. Além disso, é essencial que os desenvolvedores possam autogerenciar seu trabalho, decidindo como realizar suas tarefas de maneira eficaz.

Radiadores de informação
Os radiadores de informação são ferramentas visuais fundamentais para a gestão ágil de projetos, criados por Alistair Cockburn para promover a transparência e facilitar a comunicação entre equipes e stakeholders. Esses artefatos são expostos em locais visíveis, como paredes, e incluem elementos como Scrum Task Boards, gráficos de burndown, registros de riscos, métricas de velocidade e mais. Eles permitem uma visão panorâmica das atividades, eventos e progressos do projeto, garantindo que todos tenham acesso fácil às informações necessárias para tomadas de decisão informadas e para manter o alinhamento contínuo entre os envolvidos.

Scrum board
O Scrum Board, derivado do Kanban, é uma ferramenta essencial no método ágil para visualizar e gerenciar o progresso das tarefas do backlog do produto. Organizado em colunas customizáveis como "A Fazer", "Em Andamento" e "Pronto", permite que o time acompanhe visualmente o estado atual de cada item. A prática de limitar o trabalho em andamento ajuda a manter o foco e a concentração, garantindo que poucas histórias sejam iniciadas de uma vez e todas sejam concluídas antes de novas começarem. Além das colunas principais, o quadro pode incluir elementos como gráficos de burndown, metas da Sprint, backlog de impedimentos e raias específicas para diferentes tipos de trabalho. Essa estrutura promove a transparência, a eficiência e facilita a gestão ágil do projeto.

Daily scrum meeting
A reunião diária do Scrum, também conhecida como Daily Scrum, é uma prática essencial para acompanhar o progresso e planejar as atividades do time nas próximas 24 horas. Realizada com um timebox de 15 minutos, esta reunião visa otimizar a colaboração e a performance ao revisar o trabalho desde a última reunião e identificar os próximos passos. Os desenvolvedores respondem a perguntas como "O que eu fiz desde a última reunião?", "O que farei até a próxima reunião?" e "Quais são os impedimentos?". É uma reunião exclusiva para o time de desenvolvimento, embora o Dono do Produto e o Scrum Master possam participar se também forem desenvolvedores. Após a reunião, os membros frequentemente se reúnem para discussões detalhadas ou replanejamento. Essa prática melhora a comunicação, identifica impedimentos, promove decisões rápidas e mantém o progresso da Sprint transparente.

Como atualizar o andamento do projeto?
A atualização do andamento do projeto no Scrum pode ser realizada através do quadro de tarefas durante a reunião diária. Cada membro da equipe descreve o que foi feito desde a última reunião e o que planeja fazer até a próxima, adicionando post-its para novas tarefas ou atualizando estimativas de prazo conforme necessário. Alguns times têm o Scrum Master fazendo essas atualizações, enquanto outros preferem que cada pessoa atualize o quadro antes da reunião. Após a reunião, o progresso é visivelmente registrado no quadro, e é crucial atualizar diariamente o gráfico de burndown para manter a transparência do progresso da Sprint. A rastreabilidade pode ser melhorada tirando fotos diárias do quadro de tarefas, embora seja importante avaliar o valor real dessa prática para o projeto.

Impedimentos
impedimentos no contexto do Scrum são necessidades que o time não pode resolver autonomamente. O Scrum Master é responsável por remover esses impedimentos para garantir o fluxo contínuo do trabalho. É crucial que o time identifique corretamente o que constitui um impedimento real, pois muitas vezes problemas podem ser resolvidos internamente pela equipe sem necessidade de intervenção externa. Exemplos comuns de impedimentos incluem falta de dispositivos para testes, problemas com equipamentos, ambiente de trabalho inadequado, indisponibilidade do Product Owner, interrupções por parte da gerência, entre outros. A prática comum é adicionar uma coluna de impedimentos ao quadro de tarefas para rastrear e resolver esses problemas de forma transparente e eficiente.

Bugs x Backlog do produto
Para controlar erros reportados no incremento liberado, duas estratégias principais podem ser utilizadas:
1. Incluir bugs no backlog do produto: O Product Owner cria histórias de usuário para bugs, priorizando os mais graves para serem tratados na reunião de planejamento da Sprint. Eles são tratados como qualquer outra história do backlog.
2. Alocar tempo específico fora da Sprint para correção de bugs: Neste caso, parte do tempo da equipe é reservado para correções, sem comprometer todo o tempo no desenvolvimento de novos itens. Pode-se reservar horas semanais para correções ou até alocar pessoas dedicadas exclusivamente para essa tarefa.

A escolha entre essas estratégias depende das necessidades específicas da equipe e das demandas do projeto em cada Sprint.

Débito (dívida) técnica

Débito técnico refere-se a implementações ou soluções que não foram realizadas da melhor forma dentro do trabalho esperado. Isso pode incluir falta de cobertura de testes, componentes incompletos, falta de padronização de código, entre outros problemas. As causas para acumular débito técnico podem incluir decisões como design antecipado, sacrificar qualidade para cumprir prazos, implementar funcionalidades não previstas, falta de conhecimento técnico, complexidade do projeto, escolha inadequada de tecnologia, entre outros fatores.

A dívida técnica pode ser classificada em quatro quadrantes: consciente e intencional (sabe-se do problema, mas não se resolve), imprudente e intencional (decide-se deliberadamente deixar o problema para depois), imprudente e não intencional (não se percebe o problema até que seja tarde demais), e consciente e não intencional (agora se reconhece que poderiam ter sido tomadas decisões diferentes). O ideal é minimizar a dívida técnica, preferencialmente mantendo-a nos quadrantes onde há consciência dos riscos assumidos.

Escaped defect
Também conhecido como defeito que escapou, refere-se aos problemas de software que passam pelos processos de teste e controle de qualidade da equipe e são descobertos pelos clientes ou usuários finais. Esses defeitos podem prejudicar a confiança do cliente no fornecedor de software e são geralmente encontrados fora das etapas planejadas de validação. É crucial implementar mecanismos para analisar e mapear esses defeitos, além de adotar estratégias como testes unitários, testes integrados, automação e técnicas do TDD (Test-Driven Development) para minimizá-los no futuro. Essas estratégias geralmente são aplicadas durante a definição de pronto do software.

Integração contínua e refatoração
A integração contínua envolve integrar automaticamente partes de um projeto o mais frequentemente possível, geralmente a cada uma ou duas horas. Isso permite detectar falhas de integração rapidamente, em vez de esperar até o final do projeto (método cascata, Big Bang). É fundamental ter um sistema de controle confiável para gerenciar essas liberações, pois muitas vezes elas vão diretamente para o cliente. As vantagens incluem facilitar a entrega de incrementos reais ao final das iterações ou sprints e evitar problemas de integração de última hora.

A refatoração é o processo de revisar o código para melhorar sua estrutura interna sem alterar seu comportamento externo. O objetivo é manter o código limpo e bem estruturado, o que facilita sua manutenção futura. Essa prática também ajuda a reduzir o débito técnico ao dedicar tempo para melhorar continuamente a qualidade do código.

No próximo e último texto da série sobre o gerenciamento de projetos ágeis iremos abordar sobre como é possível monitorar o progresso e como entregar um incremento para o projeto.

Gerenciamento de projetos ágeis: Realizando estimativas

Lucas Lima — Tue, 06 Aug 2024 12:53:49 +0000

No mundo ágil, estimativas são como bússolas que guiam as equipes de desenvolvimento em direção a entregas bem-sucedidas. Neste texto, falaremos os principais aspectos relacionados a estimativas, desde a definição de velocidade e capacidade até técnicas para estimar o tamanho do trabalho.

Definindo velocidade e capacidade

A velocidade e a capacidade de um time Scrum são métricas cruciais para estimar o tamanho e o tempo necessário para concluir um projeto. Aqui estão os principais pontos sobre esses conceitos:

1. Velocidade e capacidade: A velocidade de um time é a quantidade de pontos de história que ele entrega por sprint. A capacidade é a quantidade máxima de pontos que o time pode absorver por sprint. Ambas estão inter-relacionadas e ajudam a prever o progresso e a duração do projeto.

2. Medição da velocidade: A velocidade é medida com base na experiência prática passada, geralmente após 1 a 3 sprints. A velocidade pode variar devido a fatores como mudanças na equipe ou no projeto, por isso é importante monitorá-la continuamente.

3. Importância da velocidade: Conhecer a velocidade do time permite fazer previsões mais precisas sobre a conclusão do projeto. A velocidade deve ser comparada com o próprio time e não com outros times, pois é única para cada equipe.

4. Sprints e tamanho: As sprints devem ter um tamanho consistente para que a métrica de velocidade seja válida. Se o time entrega, por exemplo, 80 pontos por sprint, pode-se estimar que um projeto de 1000 pontos levará aproximadamente 13 sprints (ou 39 semanas).

5. Times novos: Times recém-formados ou inexperientes podem não ter uma velocidade definida inicialmente. Nesse caso, devem começar com uma estimativa e ajustar a velocidade com base na experiência das primeiras sprints.

6. Ajustes contínuos: É normal ajustar a velocidade e a capacidade conforme o time ganha experiência e enfrenta novos desafios ao longo do projeto.

Esses conceitos ajudam a melhorar a previsibilidade e a gestão dos projetos ágeis, proporcionando uma base sólida para planejamento e ajustes contínuos.

Pontos de história

Os pontos de história são unidades subjetivas utilizadas por times ágeis para estimar o esforço e a complexidade de histórias de usuário. Eles representam a quantidade de esforço necessário para implementar uma história, focando na complexidade da tarefa sem incluir interrupções. Pontos de história são baseados em medidas relativas, comparando uma história com uma história padrão previamente estimada. A sequência de Fibonacci é comumente usada para essas estimativas devido à sua natureza não linear, que evita a tentação de usar a regra de três para calcular horas de trabalho. Isso tende a ser mais assertivo do que estimar isoladamente cada item.

Ao usar pontos de história, o foco está no valor entregue, não no esforço despendido. As estimativas são feitas durante as reuniões de refinamento e planejamento da sprint, baseando-se na priorização do Product Owner. Para começar, escolhe-se uma história padrão e atribui-se um valor a ela; outras histórias são então comparadas com esse padrão para determinar seus pontos de história. Esses pontos ajudam a entender e planejar o esforço necessário para concluir as histórias de usuário, melhorando a gestão e previsibilidade dos projetos ágeis.

Sprint planning

A Sprint Planning é uma reunião crucial no framework Scrum, realizada no início de cada sprint. Seu principal objetivo é definir o trabalho que será realizado durante a sprint e como ele será executado. Na primeira parte da reunião, o Product Owner apresenta as histórias de usuário mais prioritárias do backlog do produto, e, junto com a equipe de desenvolvimento, decide quais itens serão incluídos na sprint. A equipe precisa entender claramente os requisitos e os critérios de aceitação de cada história selecionada. Na segunda parte, a equipe de desenvolvimento planeja como transformar essas histórias em incrementos funcionais de software, decompondo-as em tarefas menores, estimando o esforço necessário e atribuindo responsabilidades.

A Sprint Planning é fundamental para a estimativa de trabalho, pois é nesse momento que a equipe analisa as histórias de usuário em detalhe e faz as estimativas de esforço. Esse processo permite que a equipe identifique possíveis desafios e necessidades de recursos, garantindo que todos tenham uma visão clara e realista do trabalho a ser realizado. As estimativas de esforço são essenciais para o planejamento e a execução eficiente da sprint, ajudando a garantir que os objetivos sejam alcançados dentro do prazo e com a qualidade esperada. Ao final da Sprint Planning, todos os membros da equipe devem estar alinhados sobre o que será entregue e como o trabalho será realizado, proporcionando uma base sólida para a colaboração e o sucesso da sprint.

Técnicas para estimar o tamanho de um trabalho

Abaixo listarei algumas técnicas para ajudar na estimativa de trabalho

T-shirt

A técnica T-Shirt é uma abordagem simples e intuitiva para estimar o tamanho do trabalho em projetos ágeis, utilizando categorias de tamanhos de camisetas, como Pequeno (S), Médio (M), Grande (L), Extra Grande (XL) e assim por diante. Em vez de tentar determinar um número exato de pontos para cada tarefa, a equipe de desenvolvimento classifica as histórias de usuário em uma dessas categorias com base na percepção do esforço necessário. Essa técnica facilita a comunicação e a compreensão das estimativas, permitindo uma comparação relativa entre diferentes tarefas sem a necessidade de precisão numérica. Ao final do processo, essas categorias podem ser convertidas em pontos de história para um planejamento mais detalhado.

Magic estimation

A técnica Magic Estimation é um método rápido e colaborativo para estimar o tamanho do trabalho em projetos ágeis. Os membros da equipe dispõem as histórias de usuário em uma linha de tempo ou escala visualmente, sem discussões iniciais, e depois ajustam as posições com base em um consenso coletivo. Essa abordagem eficiente elimina longas discussões, promove a participação de todos e facilita a obtenção de estimativas compartilhadas, melhorando o planejamento e a execução das sprints.

Planning poker
A técnica Planning Poker é uma prática comum em metodologias ágeis para estimar o tamanho do trabalho de forma colaborativa e baseada no consenso da equipe. Durante uma sessão de Planning Poker, cada membro da equipe recebe um conjunto de cartas com valores de pontos de história, geralmente baseados na sequência de Fibonacci (como 1, 2, 3, 5, 8, 13, etc.). O Product Owner ou facilitador apresenta uma história de usuário, e os membros escolhem uma carta que representa sua estimativa individual para o esforço necessário. As estimativas são então reveladas simultaneamente, permitindo discussões rápidas e focadas em casos de divergência significativa. Esse método não apenas ajuda a obter uma estimativa mais precisa do trabalho, mas também promove a colaboração e o entendimento compartilhado dentro da equipe.

Horas x Pontos de história

Os pontos de história são eficazes para estimar o tamanho relativo das tarefas de desenvolvimento, mas podem ser inadequados para previsões precisas de tempo de entrega futuro. Por isso, muitas equipes convertem pontos de história em horas estimadas de esforço para ter uma visão mais detalhada do trabalho. Por exemplo, uma equipe pode estabelecer que 10 pontos de história equivalem a aproximadamente 8 horas de esforço. Essa conversão não precisa ser exata inicialmente, pois é comum que a equipe ajuste suas estimativas à medida que ganha mais experiência e compreende melhor o esforço necessário. Estabelecer uma equivalência simples entre pontos de história e horas de esforço permite que a equipe tenha um contraponto útil durante o planejamento do projeto, facilitando decisões e ajustes conforme necessário.

Definição de pronto X Definição de preparado

A definição de pronto no Scrum é um conjunto formal de critérios que uma história de usuário deve satisfazer para ser considerada concluída. Estes critérios incluem desde a conclusão de testes unitários e de qualidade até a demonstração para as partes interessadas. A definição de pronto assegura a qualidade e o valor do incremento entregue, sendo criada e mantida pelo time Scrum para garantir consistência e eliminar ambiguidades ao longo do projeto. Por outro lado, a definição de preparado, ou "ready", refere-se à condição em que uma história está clara e pronta para ser desenvolvida dentro do timebox da sprint, com critérios de aceitação bem definidos para validar sua implementação conforme as expectativas do Product Owner.

No próximo texto sobre gerenciamento de projetos ágeis iremos falar sobre sprints e sobre como executá-la.

Gerenciamento de projetos ágeis: Backlog do produto

Lucas Lima — Mon, 05 Aug 2024 16:26:50 +0000

No gerenciamento de projetos ágeis, o backlog do produto desempenha um papel fundamental, pois ele é o repositório central de todas as necessidades, requisitos e funcionalidades que compõem o produto a ser desenvolvido. Abaixo, iremos explorar alguns aspectos desse artefato, desde as histórias de usuário até os épicos e temas. Veremos como criar e refinar os itens do backlog, garantindo que a equipe esteja alinhada com os objetivos e as expectativas dos stakeholders.

Antes de explorarmos o backlog do produto, é importante entender alguns conceitos essenciais relacionados a ele.

Requisitos funcionais e não-funcionais
A construção de um software é a junção de várias fases de desenvolvimento não apenas técnico, mas também de planejamento e estratégia. Saber o que é fundamental baseado nos problemas que o sistema vai resolver pode fazer a diferença em uma ferramenta de sucesso ou outra que está defasada. Entender os requisitos funcionais e não funcionais pode fazer a diferença.
Requisito é uma condição que se deve satisfazer para alcançar um objetivo.

Requisito funcional: Define uma função de um software ou parte dele. Ele é um conjunto de entradas, seu comportamento e sua saída. Envolve cálculos, lógica de trabalho, manipulação e processamento de dados e etc.
Requisito não-funcional: São relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, disponibilidade, segurança e tecnologias envolvidas.

Onde coletar requisitos?

- Wireframes
Ilustrações básicas da estrutura e componentes de uma página ou aplicativo. Geralmente são o primeiro passo no processo do design, após a concepção mental.

- Mockups
Geralmente focam sobre os elementos de design visual do site/aplicativo. São muito próximos ou idênticos ao design final efetivo e incluem todos os gráficos, tipografia e outros elementos da página. São apenas arquivos de imagem.

- Protótipos
São layouts semi-funcionais das páginas e servem para dar um preview de maior fidelidade do site/aplicativo real. Essa fase antecede a programação da lógica de negócios enquanto ele não pode ter todas as funcionalidades , geralmente dão aos clientes a capacidade de interagir com os elementos e simular a forma que o produto irá trabalhar. Eles podem ou não incluir elementos de design finalizados.

- Personas
As histórias de usuário devem ser escritas de acordo com a visão do usuário final, existem diversas técnicas que ajudam a entender melhor esse usuário. A mais utilizada é a criação de personas, elas são modelos descritos de usuários criados de dados de pesquisa que nos fornecem uma forma de entender como os usuários se comportam, pensam o que desejam e porque. É a transformação de todos os dados que você conseguiu através da pesquisa de campo em um personagem fictício.

- Histórias de usuário
São descrições simples de funcionalidades ou requisitos do sistema vistas do ponto de vista do usuário final. Elas capturam o que o usuário deseja fazer com o sistema e por quê, ajudando a equipe de desenvolvimento a entender melhor as necessidades e expectativas dos usuários. As histórias de usuário são uma parte fundamental do desenvolvimento ágil de software, pois ajudam a equipe a entender as necessidades dos usuários e a criar funcionalidades valiosas. A técnica INVEST é uma excelente abordagem para garantir que as histórias de usuário sejam bem definidas e efetivas. Vamos dar uma olhada mais detalhada nos critérios do acrônimo INVEST:

1. Independent (Independente): Cada história de usuário deve ser independente das outras. Isso significa que elas podem ser desenvolvidas e entregues separadamente, sem depender de outras histórias.

2. Negotiable (Negociável): As histórias de usuário devem ser flexíveis e sujeitas a discussão. Elas não devem ser rígidas ou prescritivas, permitindo que a equipe colabore e ajuste os detalhes conforme necessário.

3. Valuable (Valiosa): Uma história de usuário deve trazer valor ao usuário final ou ao cliente. Ela deve resolver um problema real ou atender a uma necessidade específica.

4. Estimable (Estimável): Deve ser possível estimar o esforço necessário para implementar a história. Isso ajuda a equipe a planejar adequadamente e alocar recursos.

5. Small (Pequena): As histórias de usuário devem ser pequenas o suficiente para serem completadas em uma iteração ou sprint. Isso facilita o acompanhamento do progresso e a entrega contínua.

6. Testable (Testável): A história de usuário deve ser testável. Isso significa que deve ser possível verificar se os critérios de aceitação foram atendidos por meio de testes.

Épicos e temas
Épicos são grandes histórias de usuários que compõem o backlog do produto e que ainda não foram decompostas. São histórias de usuário abrangentes, que são divididas em menores e depois se tornam tarefas. Se não cabe em uma sprint é um épico, se consigo decompor em 2 ou mais histórias é um épico. Os temas são coleções ou conjunto de histórias de histórias de usuário que estão relacionados e podem ser agrupadas. Juntos eles definem uma meta de negócio específica. Essa junção de temas é apenas uma forma de organizar melhor o trabalho.

Como criar o backlog do produto?

O backlog do produto é uma origem única dos requisitos do produto que precisam ser entregues, bem como todo entendimento necessário para se atender a esses requisitos, produzir funcionalidades e por fim, entregar um produto completo, incluindo mudanças e evoluções em produtos já existentes.

Ele é referenciado no Guia do Scrum como um artefato. Seu principal objetivo é garantir a transparência, uma vez que a partir dele podemos ver as suas funcionalidades previstas, qual a sequência de entrega, a quantidade de esforço necessária para isso e etc. O dono do produto é o responsável por manter todo o backlog do produto, principalmente porque este é um documento vivo e nunca estará completo, evoluindo à medida que o produto e o ambiente em que ele será utilizado se desenvolvem. Por isso, é possível afirmar que enquanto existir um produto, o backlog deste produto também existirá.

Os itens do backlog do produto serão então ordenados com base em seu valor, de forma que quanto maior for o valor de um item, mais cedo ele será entregue pelo time Scrum. Como os itens localizados na parte superior do backlog do produto serão entregues mais cedo, eles também serão mais detalhados e claros em comparação com os demais itens. Cada item do backlog do produto deve conter uma estimativa de trabalho. Essas estimativas são elaboradas exclusivamente pelos desenvolvedores e são usadas para que se possa avaliar a quantidade de itens que serão comprometidos em uma Sprint. O time Scrum pode adicionar detalhes, estimativas e novos itens ao backlog do produto durante todo o projeto, o que é normalmente chamado de refinamento do backlog. Seu formato é parecido com a imagem abaixo:

Tipos de itens do backlog do produto
O backlog do produto contém um número de itens e cada item descreve um bloco de construção da solução final. De forma geral, existem três possibilidades de se definir um item do backlog do produto:

- Especificação do requisito: O escopo tradicional é definido com termos técnicos claros para desenvolvedores, mas incompreensíveis para clientes, baseado na arquitetura do software e nos relacionamentos entre componentes. Métodos ágeis evitam essa abordagem por ser técnica demais e incluir detalhes de arquitetura desconhecidos no início do projeto.

- Caso de uso: É baseado no entendimento do que o usuário precisa em uma linguagem mais simples e descreve em detalhes um cenário de utilização do software com todas as ações possíveis que um usuário pode ter, bem como os retornos possíveis que o software deve dar a partir de cada uma dessas ações.

- Histórias de usuário: São semelhantes aos casos de uso, mas focam nos objetivos do usuário sem detalhar todo o comportamento. Enquanto casos de uso descrevem interações impessoais entre usuário e sistema, as histórias de usuário são mais simples e pequenas, omitindo detalhes de implementação. Isso as torna preferidas por exigir pouca manutenção e não se tornarem rapidamente obsoletas.

Técnica DEEP
Essa técnica ajuda a manter o backlog do produto organizado e adaptável. É um acrônimo para detalhado, estimado, emergente e priorizado. O backlog deve ser detalhado o suficiente para garantir clareza, mas sem exageros. Os itens próximos de serem executados precisam de mais detalhes, enquanto itens futuros podem ter menos. Cada item deve ter uma estimativa de esforço para facilitar o planejamento e refinamento contínuo, ajudando o produto a se adaptar às mudanças. A priorização é crucial, colocando os itens mais importantes no topo, variando conforme o contexto, mas sempre visando gerar valor para clientes e empresas.

Definição de preparado ou ready
Os requisitos de maior prioridade no backlog do produto são mais detalhados, enquanto os de menor prioridade têm informações básicas. É um erro acreditar que apenas definir uma história de usuário basta para os desenvolvedores criarem a funcionalidade. O dono do produto deve detalhar os itens até atingirem o conceito de "ready", significando que têm informações suficientes para serem desenvolvidos. Cada organização ou time define essa preparação, que pode incluir diagramas, rascunhos de interface e homologações. O refinamento do backlog é contínuo, com o dono do produto idealmente trabalhando uma sprint à frente, mas evitando detalhar muito antecipadamente para não criar documentação desnecessária. Requisitos não detalhados devem ser evitados nas sprints, mantendo a dinâmica de atualização do backlog.

Reunião de planejamento do backlog do produto

Exemplo de agenda para a criação o backlog do produto

Abertura

Scrum Master revisita propósito, estrutura e agenda da reunião.

Visão do Produto

O dono do produto relembra a visão do produto para alinhar expectativas.

Principais Funcionalidades

Lista de funcionalidades desejadas elaborada pelo dono do produto e partes interessadas.
Técnicas de priorização de itens do backlog do produto: Modelo de Kano, Moscow, Monopoly, Scorecard e entre outras.

Priorização de Itens

Dono do produto e cliente identificam itens mais prioritários.
Diversas técnicas de priorização serão discutidas.

Estimativa de Itens do Backlog

Time estima macro a quantidade de esforço para itens priorizados.
Foco nas duas ou três próximas sprints.

Dependências e Preocupações

Identificação de riscos, dependências, impedimentos e desafios.
Elaboração de plano de riscos ou plano de ação, se necessário.

Encerramento

Retrospectiva para avaliar pontos positivos e melhorias da reunião.

Refinamento do backlog do produto

O refinamento do backlog é um processo contínuo, diferente dos eventos time-boxed do Scrum, e é de responsabilidade do dono do produto. Esse processo envolve atualizar, adicionar detalhes, novas estimativas, reordenar e priorizar itens do backlog. Os itens refinados, ou "ready", estão prontos para a Sprint. Embora o dono do produto priorize, os desenvolvedores são responsáveis por estimar o esforço dos itens, participando de sessões de refinamento quando necessário. Em geral, os desenvolvedores dedicam cerca de 10% do tempo da Sprint ao refinamento. A principal diferença é que o refinamento não é um evento formal, mas uma atividade contínua.

Spikes
São exercícios de prova de conceito usados em projetos de alto risco e incerteza, onde requisitos, recursos ou tecnologia são desconhecidos. Spikes permite que a equipe investigue problemas ou riscos, e podem ser histórias de usuário ou um conjunto delas. Eles podem ser desenvolvidos na primeira iteração do projeto para avaliar sua viabilidade. O principal benefício é identificar falhas ou inviabilidade logo no início, evitando gastos desnecessários e promovendo o conceito de "falha rápida"

Dando continuidade ao assunto sobre gerenciamento de projetos ágeis, no próximo texto exploraremos um tópico crucial: estimativas de trabalho. Essas estimativas são essenciais para planejar e alocar tarefas em sprints, garantindo que a equipe possa entregar valor de maneira eficiente.

Gerenciamento de projetos ágeis: O inicio de tudo

Lucas Lima — Thu, 01 Aug 2024 13:25:01 +0000

O gerenciamento de projetos é crucial para garantir que iniciativas sejam concluídas com sucesso. Ele ajuda a organizar recursos, evitar erros e cumprir prazos e orçamentos. Além disso, promove a colaboração e a qualidade das entregas, sendo essencial para qualquer organização que busca eficiência e inovação.

Neste primeiro texto, vamos iniciar falando sobre alguns itens fundamentais para o início de um projeto ágil, como plano de negócios, MVP (Produto Mínimo Viável), MMP (Produto Mínimo Comercializável), meta do produto, ferramentas para fazer o termo de abertura do projeto e como formar um time ágil. Esses elementos são essenciais para estabelecer uma base sólida e garantir que o projeto comece com o pé direito.

Plano de negócios
Instrumento que permite prever os resultados de uma decisão empresarial. Ferramenta de planejamento e suporte a decisões, ela serve para comunicar uma ideia de negócio e permite validar a viabilidade das iniciativas, além de servir de métrica de avaliação pós-implementação. Ele responde a algumas questões como:

Porque o projeto é necessário?
Como o projeto ajudará a resolver os problemas identificados pela organização?
Qual a solução recomendada?
Quais os benefícios esperados?
O que vai/pode ocorrer ao negócio se a solução não for implantada?
Quando a solução será implantada e os recursos necessários para tal?

MVP
O produto mínimo viável é a forma de testar se o produto que será construído será aceito pelo mercado. Ele é uma das primeiras etapas do projeto, serve para testar a eficiência, usabilidade e aceitação do produto. Ele é muito importante, pois se houver alguma discordância é possível ser corrigido nas fases iniciais do projeto, evitando grandes investimentos. Uma frase que pode resumir seria “Não é sobre entregar funcionalidades mal feitas, mas sobre entregar apenas a quantidade necessária e com qualidade”. Muitas empresas utilizam esse processo, um exemplo é o Spotify que usa um ciclo interativo de 4 estágios:

Think it (Pense) - Decidir sobre o produto que vai trabalhar e construir um protótipo.
Build it (Construa) - Construir um MVP real e entregar aos usuários para testar.
Ship it (Entregue) - Colete dados e melhore liberando gradualmente o MVP.
Tweak it (Refine) - Colete feedback e melhore o produto até que esteja completo.

MMP
O produto mínimo comercializável descreve o produto com o mínimo de recursos possível que atenda as necessidades do usuário e pode ser comercializado. É uma ferramenta para diminuir o tempo que o produto pode ser lançado.

Meta do produto
Objetivo ou necessidade de negócios de alto nível que fornece contexto, orientação, motivação e inspiração para o trabalho e desenvolvimento do produto durante todo o projeto. Objetivo maior a ser alcançado pelo time Scrum. A meta do produto é estabelecida antes que o desenvolvimento se inicie e permaneça estável durante todo o projeto. Seu formato é:

PARA [CLIENTE-ALVO], QUE [PROBLEMA OU OPORTUNIDADE] O [NOME DO PRODUTO] É UM [CATEGORIA DO PRODUTO] QUE [BENEFÍCIO-CHAVE, RAZÃO CONVINCENTE PARA UTLIZAR]. AO CONTRÁRIO DE [ALTERNATIVA COMPETIDORA], NOSSO PRODUTO [DIFERENÇA PRIMÁRA].

Um exemplo de meta do produto seria:

PARA ESPORTISTAS AMADORES, QUE DESEJAM APROVEITAR MELHOR SUAS HORAS DE LAZER, O SPORT4U É UM APLICATIVO MÓVEL DE VENDAS DE MATERIAL ESPORTIVO QUE SUGERE ROUPAS E EQUIPAMENTOS DE ACORDO COM SEU PERFIL. AO CONTRÁRIO DE OUTROS SITES DE MATERIAL ESPORTIVO, NOSSO PRODUTO ELABORA SUGESTÕES PERSONALIZADAS E ADAPTÁVEIS DE ACORDO COM O PERFIL DO USUÁRIO.

TAP
O termo de abertura do projeto é um documento fundamental no gerenciamento de projetos. Ele formaliza o início do projeto, definindo seu propósito, objetivos, escopo, principais entregas, cronograma e recursos necessários. O TAP também identifica os principais stakeholders e suas responsabilidades, além de estabelecer a autoridade do gerente de projetos. Esse documento é essencial para alinhar as expectativas e garantir que todos os envolvidos tenham uma compreensão clara do projeto desde o início. Não existe um forma específica de se fazer, mas ele deve fornecer as respostas de algumas perguntas. Abaixo listarei algumas ferramentas que ajudam na criação desse documento.

5w2h
Essa técnica é muito eficaz para orientar as pessoas de forma simples e clara de como entender determinadas informações, necessidades ou problemas, documentá-las, identificar alternativas e gerar um plano de ação para solucioná-las. Deve-se responder as 7 perguntas abaixo:

What (O que se trata o projeto?)
Why (Porque o projeto deve ser desenvolvido?)
Who (Quem serão os beneficiados pelo projeto?)
When (Quando será feito?)
Where (Onde será implementado o projeto?)
How (Como o projeto será planejado/desenvolvido?)
How much (Quanto custa o projeto?)

Elevator statement
O Elevator Statement, ou Pitch de Elevador, é uma ferramenta para apresentar uma ideia, projeto ou proposta de forma clara e persuasiva em um curto período de tempo, geralmente entre 30 segundos e 2 minutos. Ele deve incluir uma breve introdução, a identificação de um problema ou oportunidade, a descrição da solução proposta, os benefícios dessa solução e uma chamada para ação específica.

SMART
Antes de falar sobre a ferramenta devemos deixar claro a diferença entre objetivo e meta. Objetivo é o que se deseja alcançar enquanto as metas são as ações necessárias para alcançar o objetivo. A técnica SMART serve para definir essas metas, boas metas devem ser:

Specific (Específico)
Measure (Mensurável)
Achievable (Alcançável)
Relevant (Relevante)
Time-based (Temporizável)

Partes interessadas (Stakeholders)
São pessoas e organizações ativamente envolvidas no projeto ou cujos interesses podem ser afetados como resultado da sua execução ou do seu término. Elas podem exercer influência sobre os objetivos e resultados do projeto. A equipe de planejamento deve identificá-las, determinar suas necessidades e expectativas e na medida do possível gerenciar sua influência em relação aos requisitos. As classificações para um processo de abordagem desse stakeholder pode ser feita através dessa matriz.

Como formar um time ágil?

Um time ágil é responsável pelo sucesso do projeto e deve garantir que aquilo que deve acontecer realmente aconteça. 2 características essenciais para um time ágil é que seja auto-organizado (gerenciamento de seus próprios esforços) e multifuncional (todo o conhecimento e competências necessárias para realização de tarefas sem qualquer ajuda de fora da equipe).

Não esqueça dos testadores!
Testador = Habilidade primária é testar. Programadores são quase sempre maus testadores, principalmente aqueles que testam seu próprio código. Os testers são as pessoas que aprovam e nada que é considerado “pronto” enquanto ele não diga que está. Enquanto não há nada para testar (geralmente no início da sprint, eles devem estar escrevendo as especificações de teste e preparando o ambiente para tal função).

Divisão de times
Existem 3 formas de se dividir um time:

Formar novas equipes (se a organização conhece os métodos ágeis e já tem equipes formadas, o único problema seria uma ineficiência no início do projeto por não estar familiarizado).
Dividir equipes (split-and-seed) a equipe original é dividida em várias equipes e novos membros são adicionados. O conhecimento do projeto será distribuído em todas as equipes, mas se perde todo o time original.
Dividir equipes (grow-and-split) novos membros são adicionados à equipe original até que atinja a capacidade de 9 membros para o time de desenvolvimento dos desenvolvedores. Após isso a equipe é dividida em 2.

War room
É um espaço dedicado onde a equipe de desenvolvimento se reúne para colaborar intensamente e resolver problemas de forma rápida e eficiente. Este ambiente é projetado para promover a comunicação aberta e a troca de ideias, facilitando a identificação e a solução de obstáculos que possam surgir durante o desenvolvimento do projeto. A sala geralmente está equipada com ferramentas visuais, como quadros brancos e gráficos, que ajudam a equipe a monitorar o progresso e manter o foco nos objetivos do Sprint.

Roadmap de produto
É um plano que combina os objetivos do negócio, as necessidades e o desejo dos clientes em relação ao produto e as tarefas necessárias para atingir os objetivos. Produtos são lançados de forma faseada (com entregas parciais ou releases). O roadmap surge através do backlog do produto e sua responsabilidade também é do dono do produto. Ele é representado por uma linha do tempo com marcos (com datas aproximadas no futuro e o objetivo do produto a ser alcançado). Define uma visão estratégica de onde e para onde o produto está caminhando a médio e longo prazo.

Plano de releases
É a execução do roadmap do produto. O plano de release é um documento que detalha quando e quais funcionalidades de um software serão lançadas (geralmente possui 1 ou mais sprints então é necessário detalhar). Ele ajuda a equipe a saber o que precisa ser feito e quando, garantindo que todos estejam na mesma página e que os lançamentos ocorram de forma organizada e dentro do prazo.

No próximo texto, vamos falar sobre como criar e refinar o backlog do produto, aprofundar alguns conceitos, entender o que são requisitos e aprender algumas técnicas para utilizar nos itens do backlog.

O básico do SCRUM: Um guia simples e rápido

Lucas Lima — Wed, 31 Jul 2024 14:03:38 +0000

Este é um guia simples e rápido sobre Scrum, ideal para quem está se preparando para um teste ou prova. Exploraremos a história do Scrum, seus pilares e valores, e como funciona o ciclo Scrum. Também discutiremos a diferença entre metodologia e framework, os papéis e responsabilidades dentro de uma equipe Scrum, os artefatos essenciais e os eventos que estruturam o processo. Se você está começando sua jornada no mundo ágil ou simplesmente quer entender melhor como o Scrum pode beneficiar sua equipe, este guia é para você!

Empirismo

Empirismo é uma corrente filosófica que se refere à teoria do conhecimento, onde todo o conhecimento é adquirido através da prática e da experiência. Em vez de previsões, a informação é obtida por meio da observação. Essa abordagem divide problemas complexos em partes menores, utilizando equipes pequenas que trabalham em incrementos do produto.

O Scrum adota os princípios do empirismo. Ele opera em ciclos curtos de trabalho, conhecidos como sprints, que permitem a inspeção e adaptação contínuas. Ao fragmentar problemas complexos em partes menores e iterativas, as equipes podem coletar feedback regularmente e ajustar o escopo e o plano de entregas de acordo com as novas informações e mudanças que surgem ao longo do projeto. Isso torna o processo mais flexível e responsivo às necessidades do projeto.

História

O Scrum foi criado por Hirotaka Takeuchi e Nonaka Ikujiro nos anos 80 para o desenvolvimento de produtos. O nome “Scrum” vem de uma formação específica do rugby, utilizada quando o jogo é reiniciado após uma falta. Essa analogia foi escolhida para representar a colaboração e a coesão necessárias em uma equipe de desenvolvimento.

Nos anos 90, Ken Schwaber e Jeff Sutherland desenvolveram o conceito de Scrum e sua aplicação no desenvolvimento de softwares. Eles formalizaram as práticas e princípios que hoje conhecemos, adaptando a abordagem para atender às necessidades específicas do desenvolvimento ágil de software. No Scrum, o desenvolvimento do produto é um esforço conjunto, onde a equipe trabalha de forma colaborativa para atingir um objetivo comum.

Pilares do Scrum

Transparência: Todos os aspectos importantes do processo devem ser visíveis e compreensíveis para todos os envolvidos.
Inspeção: Revisões frequentes do progresso e dos artefatos do Scrum garantem que o trabalho está no caminho certo.
Adaptação: Ajustes contínuos são feitos com base no feedback e nas inspeções para melhorar processos e resultados.

Valores do Scrum

Coragem: O time Scrum precisa ter coragem para fazer a coisa certa e trabalhar com problemas difíceis.
Foco: Todos focam no trabalho da sprint e nos objetivos do time Scrum.
Comprometimento: As pessoas se comprometem pessoalmente em alcançar os objetivos do Scrum.
Respeito: Os membros do time Scrum respeitam uns aos outros para serem pessoas capazes e independentes.
Abertura: O time de Scrum e seus stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a execução dos trabalhos.

O ciclo Scrum

O Scrum é um framework ágil para o gerenciamento e desenvolvimento de produtos complexos, especialmente em projetos de software, que se baseia em equipes pequenas e auto-organizadas que trabalham em ciclos curtos e iterativos, chamados de Sprints, para entregar incrementos de produto potencialmente utilizáveis.

Reunião com stakeholders: Criação de meta do produto.
Roadmap do produto: Representação gráfica das entregas parciais ao longo de uma linha do tempo.
Backlog do produto: Composto por histórias de usuário que são escritas pelo dono do produto através de informações fornecidas por clientes e stakeholders.
Reunião de planejamento da sprint: Onde as histórias de usuário de alta prioridade são escolhidas para serem executadas.
Backlog da sprint: As histórias de usuário são divididas em tarefas menores e mais facilmente gerenciáveis. A sprint tem duração de 4 semanas geralmente. Durante a sprint são realizadas reuniões diárias para discussão de progresso diário.
Reunião de revisão da sprint: Perto do final da sprint a reunião o dono do produto recebe uma demonstração dos entregáveis.
Reunião de retrospectiva da sprint: O ciclo finaliza com uma reunião para o time apresentar maneiras de melhorar processos e seu desempenho para avançar para a próxima sprint.

Metodologia X Framework

Metodologia: Explicação minuciosa, detalhada e exata de todas as ações a serem tomadas para o desenvolvimento ou realização de um trabalho ou pesquisa.

Framework: Estrutura flexível que fornece diretrizes e componentes reutilizáveis para apoiar e organizar o desenvolvimento de projetos, permitindo adaptações conforme necessário.

Papéis e responsabilidades

Time Scrum: Composto por 3 papéis, Product Owner (apenas 1 integrante) que é totalmente voltado a negócios, Scrum master(apenas 1 integrante) especialista nas práticas dos Scrum, não é um líder técnico. Developers pessoas que criam qualquer elemento incrementável na sprint. Um time Scrum deve ter entre 10 ou menos pessoas.

Scrum master: Ë um facilitador, deve garantir ao time Scrum um ambiente propício para a conclusão do projeto. Guia, facilita e ensina as práticas Scrum. Guiar a equipe e eliminar qualquer impedimento que ocorra. Não é a mesma coisa que um gerente de projeto.

Product Owner: Responsável por alcançar um maior valor de negócio do produto e também pela coordenação das necessidades dos clientes. Ele deve garantir uma boa comunicação com o time Scrum sobre requisitos e funcionalidades do produto ou serviço, definindo e garantindo os critérios de aceitação. Resumindo ele é responsável com que o time tenha entregas com valor. Ele é responsável pelo backlog do produto. Não é a mesma coisa que um gerente de projeto.

Desenvolvedores: São pessoas do time Scrum que estão comprometidas em criar um incremento utilizável a cada sprint. Responsáveis pelo desenvolvimento do produto ou serviço. Eles possuem habilidades específicas (geralmente amplas) de acordo com o domínio do trabalho. O grupo deve ser multifuncional e autogerenciado.

Artefatos

São elementos que representam trabalho ou valor e fornecem transparência e oportunidades para inspeção e adaptação.

Backlog do produto: Lista ordenada e emergente do que é necessário construir e/ou melhorar um produto já existente. É dinâmico e está sempre mudando para identificar o que o produto precisa para ser competitivo e útil. Meta do produto é um objetivo ou necessidade de negócio que fornece contexto, orientação, motivação e inspiração para o trabalho.

Backlog da sprint: Plano de trabalho criado pelos desenvolvedores, é uma imagem visível em tempo real do trabalho que eles planejam realizar durante a sprint para atingir a meta. Ele é composto por 3 itens: meta da sprint (porque estamos trabalhando nessa sprint?), conjunto de itens backlog do produto(o que vamos desenvolver para atingir a meta) e o plano de ação(tarefas e atividades para compor o incremento, como vai ser atingida a meta da print).

Incremento: Parte utilizável do produto final. Dentro da sprint, pode-se ter vários incrementos entregues. Ë a forma de entrega de valor e atingir a meta do produto. O incremento só é finalizado com a definição de pronto, que é uma descrição formal do estado do incremento quando ele atinge as medidas de qualidade exigidas. Essa definição de pronto pode fazer parte do padrão da organização, mas se não houver o próprio time deve criar a sua própria, geralmente ela inclui (aprovação do design e usabilidade, testes aprovados em todas as funcionalidades e etc).

Histórias de usuário: Descrição clara e resumida de alguma funcionalidade que deverá ser desenvolvida, sempre com o ponto de vista de um usuário final. Devem possuir uma descrição curta e objetiva. O modelo de história de usuário seria assim:

COMO UM [TIPO DE USUÁRIO], EU QUERO [UM OBJETIVO] PARA QUE [ATENDA UMA NECESSIDADE].

Um exemplo de história de usuário seria:

COMO UM ADMINISTRADOR DO SISTEMA, EU QUERO CONFIGURAR PARÂMETROS PARA QUE FACILITE A VISUALIZAÇÃO DOS RELATÓRIOS.

Épicos: São histórias muito abrangentes, devemos quebrar eles em histórias menores. Se não cabe em uma sprint não é um épico, se é possível quebrar em 1 ou mais post-its é um épico, se a estimativa gerou muita divergência é um épico.

Quadro de tarefas: Scrum board é um quadro que o time coloca as tarefas do backlog. Ele é dividido em histórias do usuário (que compõe o backlog da sprint), a fazer, em andamento, em testes e pronto.

Eventos

São criados para criar regularidade e minimizar a necessidade de reuniões não definidas.

Sprint: Uma Sprint no Scrum é um período de tempo fixo, geralmente de uma a quatro semanas, durante o qual uma equipe de desenvolvimento trabalha para completar um conjunto específico de tarefas do backlog do produto, com o objetivo de entregar uma versão funcional e incrementada do produto.

Reunião de planejamento da Sprint: É uma reunião realizada no início de cada sprint, ela deve deve ser restringida ao máximo de duas horas por cada semana do sprint. participam a equipe de desenvolvimento, o Product Owner e, às vezes, o Scrum Master e ao final da reunião deve-se obter a meta da sprint, o conjunto de itens do backlog do produto e o plano de ação para a entrega do incremento.

Reunião diária: Diariamente a equipe para uma reunião e 15 minutos para acompanhar o progresso do trabalho em relação a meta da sprint e adequar o backlog da sprint, ajustando o próximo trabalho a ser realizado. O formato é definido pelos desenvolvedores e sua condução é livre, mas deve focar no progresso da sprint. Geralmente são respondidas 3 questões: O que eu fiz desde a última reunião? O que irei fazer até a próxima reunião? Quais são os impedimentos?

Revisão da Sprint: Duração de no máximo 4 horas (1 hora para cada semana de sprint). Seu propósito é inspecionar o resultado da sprint e determinar adaptações futuras. O time apresenta os resultados do seu trabalho para as partes interessadas e o progresso é discutido. É revisado o que foi realizado e o que foi mudado em relação às novas funcionalidades disponibilizadas.

Retrospectiva da Sprint: Após a revisão da sprint acontece essa reunião, com duração de no máximo 3 horas para uma sprint de 4 semanas. Seu propósito é inspecionar como ocorreu a última sprint em se tratando de pessoas, relações entre elas, dos processos, das ferramentas e da definição de pronto.

Refinamento de backlog: Não é um evento oficial, pois deve ser feito a todo momento durante o projeto. Ele é um processo contínuo e de responsabilidade do dono do produto. Essa atividade envolve adicionar detalhes, novas estimativas, re-ordenar e re-priorizar itens.

Metodologia Ágil

Lucas Lima — Tue, 30 Jul 2024 14:33:13 +0000

No mundo dinâmico e em constante evolução dos negócios e da tecnologia, a capacidade de gerenciar projetos de forma eficiente e eficaz é essencial. Neste artigo, irei abordar os conceitos fundamentais de um projeto, a essência de ser ágil, entender o modelo cascata, o manifesto ágil e abordar as 3 principais restrições enfrentadas em projetos.

O que é um projeto?
Projetos existem desde a antiguidade, antes mesmo de serem considerados projetos. Grandes exemplos são construções civis, como as pirâmides do Egito. Eles envolvem complexidade, gerenciamento, práticas, princípios, ferramentas, etc. Segundo o PMBOK, um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. São temporários porque têm início e fim definidos, o resultado deve ser duradouro e devem ser exclusivos porque sempre produzem algo novo.

O que é ágil?
Ágil é aquele que se move com facilidade, ligeiro e veloz. Esse termo vem sendo usado para gerenciar projetos, porém, não se tem a preocupação de ser mais rápido, e sim de evitar o desperdício. Ser ágil é realizar entregas com valor, qualidade, ser assertivo e ter planejamento. Adotar um mindset ágil significa ter uma mentalidade de grande adaptação e aprendizado frente aos desafios. É sobre estar preparado para mudanças, aprender com as experiências e ajustar-se rapidamente às novas circunstâncias.

Modelo Cascata
O modelo cascata é uma abordagem tradicional de gerenciamento de projetos, onde uma fase se inicia apenas após a conclusão da anterior. Esse modelo é completamente preditivo e foca em planos detalhados no início do projeto, abrangendo custo, escopo e cronograma. Mudanças são geralmente indesejadas e evitadas. Esse modelo é amplamente utilizado na construção civil devido à sua natureza sequencial e estruturada.

As fases do modelo cascata incluem: requerimento, projeto, implementação, verificação (testes) e manutenção. Cada fase deve ser concluída antes que a próxima possa começar, garantindo que todos os requisitos e especificações sejam atendidos antes de avançar.

Quando se trata de desenvolvimento de software, o modelo cascata apresenta algumas limitações, pois software é uma definição intangível e, muitas vezes, os requisitos podem mudar ao longo do tempo. No modelo cascata, o cliente só vê o resultado final após a conclusão de todas as fases, o que pode levar a desentendimentos e insatisfações se o produto final não atender às expectativas iniciais.

Para contornar essas limitações, muitas equipes de desenvolvimento de software optam por usar ciclos de vida iterativos e incrementais, como o Scrum. Esses ciclos, conhecidos como sprints, permitem a entrega de partes utilizáveis do software em intervalos regulares. Isso possibilita a validação contínua e ajustes conforme necessário, garantindo que o produto final atenda às necessidades e expectativas do cliente.

Manifesto ágil
O Manifesto Ágil é um documento criado em 2001 por um grupo de 17 desenvolvedores de software que propôs uma abordagem mais flexível e colaborativa para o desenvolvimento de software.

Os valores ágeis são:

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 às mudanças mais que seguir um plano.

Os princípios ágeis são:

A principal prioridade é satisfazer o cliente através da entrega contínua e adiantada de software de valor.
Aceitar mudanças de requisitos, mesmo tardiamente no desenvolvimento. Processos ágeis se aproveitam da mudança para proporcionar vantagem competitiva ao cliente.
Entregar software funcionando com frequência, de poucas semanas a poucos meses, com preferência à menor escala de tempo.
Pessoas de negócios e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto.
Construir projetos em torno de indivíduos motivados, dando-lhes o ambiente e o suporte necessários e confiando-lhes na execução do trabalho.
O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é por meio de conversa face a face.
Software funcionando é a principal medida de progresso.
Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
A contínua atenção à excelência técnica e ao bom design aumenta a agilidade.
A arte de maximizar a quantidade de trabalho não realizado é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então, ajusta seu comportamento de acordo.

A Tripla Restrição de um Projeto
Todo projeto é regido por três elementos cruciais que determinam seu sucesso: escopo, custo e tempo. Esses três fatores formam o que é conhecido como a tripla restrição ou triângulo de ferro no gerenciamento de projetos.

Escopo: refere-se ao trabalho a ser realizado, abrangendo todas as tarefas e entregas necessárias para completar o projeto.
Custo: envolve todos os recursos financeiros necessários para executar o projeto, incluindo materiais, mão de obra e outros gastos.
Tempo: é o prazo estipulado para a realização do trabalho, desde o início até a conclusão do projeto.

Na maioria dos casos, o escopo é fixo, enquanto o custo e o tempo são variáveis. Isso significa que, para manter o escopo inalterado, ajustes podem ser necessários no orçamento ou no cronograma do projeto. Entender e gerenciar essas restrições é fundamental para o sucesso de qualquer projeto, pois qualquer alteração em um dos elementos impacta diretamente os outros dois.

No próximo artigo, falaremos sobre o Scrum, uma das metodologias ágeis mais populares para o desenvolvimento de software. Vamos abordar sua criação e sua base.

Affordance nos projetos de interfaces e interações

Lucas Lima — Mon, 14 Aug 2023 21:00:00 +0000

O termo affordance foi criado pelo psicólogo James Gibson em 1977 e tem sido aplicado em áreas como design de produtos, interação humano computador e arquitetura ajudando a criar interfaces mais intuitivas e de fácil usabilidade para os usuários.

Affordance refere às características percebidas de um objeto, ambiente ou sistema que sugerem ações ou comportamentos possíveis para uma pessoa. Resumindo, é a percepção que um usuário tem de como utilizar algo com base nas características físicas ou funcionais desse objeto.

Como usamos isso no dia a dia?

Um exemplo clássico de affordance é um interruptor de luz.

O interruptor de luz é projetado com um botão que pode ser alternado entre duas posições ligado e desligado. A affordance desse interruptor é geralmente alcançada por meio de pistas visuais e táteis. Visuais pois geralmente o interruptor de luz possui uma cor contrastante em relação à parede. Tátil por possuir uma textura diferente ou uma sensação tátil distintiva indicando que o interruptor pode ser pressionado ou movido. Podemos incluir também uma affordance sonora onde ao pressionar o botão conseguimos ouvir um som de "click" fornecendo uma confirmação sonora da ação realizada.

Affordance nas engenharias cognitiva e semiótica

No contexto das engenharias, o conceito tem foco em compreender os processos mentais e cognitivos dos usuários envolvidos na percepção e interpretação da affordance de um objeto ou sistema. De forma resumida, procuramos identificar as propriedades dos objetos que fornecem pistas ou sugestões para o usuário sobre como agir.

Por exemplo, um botão com um ícone de envelope é facilmente associado à ação de enviar um e-mail. Ao projetar a interface, os designers podem criar uma correspondência clara entre o sinal visual e a ação esperada para facilitar o processamento cognitivo dos usuários.

Ambas as engenharias reconhecem que as affordances influenciam a percepção e interpretação devido aos fatores culturais, sociais e cognitivos. Portanto, é importante considerar as habilidades, conhecimentos e experiências do usuário ao projetar interfaces de usuário. Além disso, elas também enfatizam a importância do feedback, pois fornecem informações claras e úteis ao usuário sobre o que pode ser feito e o que acontecerá quando uma ação é realizada. Esse feedback pode ser visual, auditivo ou tátil, dependendo da natureza da interface de usuário.

Heurísticas de Nielsen

Lucas Lima — Mon, 07 Aug 2023 20:30:00 +0000

Jakob Nielsen é Ph.D. em interação humano-computador e pioneiro em pesquisas de usabilidade com contribuições no campo da experiência do usuário. Seu trabalho mais notável é a formulação de um conjunto de princípios de usabilidade conhecidos como "Heurísticas de Nielsen". Essas heurísticas fornecem diretrizes para avaliar a usabilidade de interfaces de usuário e têm sido amplamente adotadas e utilizadas por profissionais de UX. Abaixo, vamos passar pelos 10 princípios e mostrar como foram aplicadas em alguns exemplos.

1. Feedback do sistema
Essa primeira heurística enfatiza a importância do usuário saber sobre o que está acontecendo com o sistema. Ela deve fornecer algum feedback perceptível para cada ação de forma mais rápida possível para evitar a incerteza e confusão. Um exemplo bem simples de feedback do sistema pode ser uma barra de progresso mostrando ao usuário o momento em que ele está.

2. Sincronia entre o mundo real e o sistema
A segunda heurística enfatiza a importância de projetar interfaces que sejam consistentes e que correspondem ao conhecimento dos usuários, pois quando interagimos com um sistema baseamos nossas ações em conhecimentos prévios. Aqui é muito importante usarmos uma linguagem clara, metáforas visuais com uso de ícones e elementos gráficos e etc.

3. Controle e liberdade ao usuário
A terceira heurística enfatiza a importância de dar aos usuários controle sobre suas ações e permitir que eles desfaçam ou saiam de situações indesejadas sem dificuldade. Nesse exemplo podemos selecionar a quantidade, se queremos excluir do carrinho ou salvar para mais tarde.

4. Consistência
A quarta heurística enfatiza a importância de manter a consistência de links, cores, tipografia, formas, textos e espaçamento para facilitar a compreensão e o uso da interface, permitindo que os usuários se familiarizem rapidamente com o sistema e apliquem seu conhecimento prévio.

5. Prevenir erros
A quinta heurística enfatiza a importância de projetar sistemas que evitem erros e que forneçam mecanismos de recuperação para caso aconteça. No GitHub temos a aplicação na parte de exclusão dos diretórios, se o usuário quiser deletar, temos que escrever o nome do diretório e o botão de exclusão fica habilitado.

6. Tornar as ações visíveis
A sexta heurística enfatiza a importância de fornecer feedback claro e visível sobre o estado do sistema e as ações do usuário. Por exemplo, realizando uma compra em um site de roupas, é essencial que as informações dos tamanhos das peças disponíveis e indisponíveis estejam claras e visíveis aos usuários, assim como este exemplo:

7. Atalhos
A sétima heurística enfatiza a importância de fornecer atalhos para os usuários mais experientes. A interface deve ser projetada para acomodar tanto os usuários iniciantes quanto os avançados, oferecendo opções de personalização, atalhos e métodos alternativos de interação.

8. Minimalismo
A oitava heurística enfatiza a importância de fornecer uma interface simples e minimalista. Buscando uma maior consistência, hierarquia visual e feedback visuais sutis. Muitos designers aplicam essa heurística com o conceito de mobile-first para focar apenas no conteúdo principal.

9. Mensagens claras de erro
A nona heurística enfatiza a importância de projetar interfaces que previnam erros sempre que possível e, quando ocorrerem, forneçam mensagens de erro claras e eficazes para orientar os usuários na resolução dos problemas.

10. Instruções
A décima heurística enfatiza a importância de fornecer recursos de ajuda e documentação para os usuários, a fim de auxiliá-los na compreensão e utilização eficaz do sistema. Alguns exemplos de aplicações podem ser uma tour pelo sistema assim que o usuário cria a conta e faz o login pela primeira vez, uma área de perguntas frequentes, tooltips/dicas sobre algumas ferramentas.

Para finalizar esse texto, gostaria de deixar essa frase para nunca esquecer o real propósito do trabalho de um designer pois as heurísticas nesse caso são apenas complementos que ajudam a guiar a criação das interfaces.

"Mesmo os melhores designers só conseguem produzir produtos bem-sucedidos se seus designs resolverem os problemas certos. Uma interface maravilhosa para recursos incorretos resultará em fracasso." – Jakob Nielsen

Tipografia não é só escolher uma fonte…

Lucas Lima — Wed, 26 Jul 2023 15:00:00 +0000

O título pode parecer meio clickbait, mas é bem real na verdade. Em 2006 a empresa Information Architect Inc, publicou um post com o seguinte título "Web Design é 95% Tipografia" e mesmo quase 2 décadas depois de publicado esse artigo é bem atual. Grande parte do conteúdo dos sites são texto e a tipografia desempenha um papel fundamental na comunicação visual, pois a forma que um texto é apresentado influencia a legibilidade e a compreensão da mensagem.

Tipografia vai muito além de simplesmente escolher uma fonte e aplicá-la em todo o texto. Irei listar abaixo alguns dos principais tópicos que devemos considerar ao formatar um texto para web.

Variáveis tipográficas

Escala: Um dos principais itens para montar uma boa hierarquia de informações através de 4 a 6 variações. Uma boa dica é sempre repetir a escala em itens iguais seja título, subtítulo ou corpo de texto. O ponto a levar como atenção é que essa escala deve ter um bom contraste variando o tamanho da fonte.
Tamanho: O principal ponto aqui é a legibilidade das informações, uma fonte de tamanho bem pequena pode afetar a transmissão da informação e perde todo o propósito da mensagem. Sempre trabalhar com pequenos trechos, um texto muito longo pode comprometer a leitura e torná-la cansativa.
Altura de linha: Esse tópico depende muito da fonte e o tamanho que você pretende usar no texto. Porém existe um truque que pode ser aplicado na maiorias das fontes, basta você pegar o tamanho da fonte e multiplicar por 1,5. O resultado é a altura da linha que você pode aplicar na formatação, verificando sempre se o texto fica harmônico não existe regra.
Largura do texto: Aqui a quantidade ideal de palavras por linha no corpo de texto seria 13, textos longos dificultam e muito a leitura.
Alinhamento: 90% dos textos presentes na web estão alinhados a esquerda. Ela facilita a leitura e por padrão o CSS já faz esse alinhamento. O alinhamento a direita não é muito interessante pois sempre inicia uma linha em um novo ponto, dificultando a leitura. outra dica é sempre que possível alinhar o texto a elementos já existentes no site.
Negrito: Muito utilizado para destacar e para trazer um forte contraste. Existem diversas variações, dentre elas a bold, demi bold, black e heavy.
Itálico: Muito utilizado para dar ênfase. Ele é derivado da escrita cursiva e existem os tipos itálicos que só fazem a variação do caractere e o oblíquo inclinam a letras, mas sem nenhuma variação.
Cores: A principal função da cor na tipografia é dar contraste e uma boa leitura depende desse contraste com as dicas acima aplicadas. Um site que recomendo para fazer teste de cor de fundo e cor de texto é o Siege Media.

Classificações tipográficas

Serifadas: Um fonte clássica e elegante, muito atrelada a coisas históricas. Tem boa legibilidade, suas itálicas possuem estilo próprio, além de serem indicadas para o corpo de texto e títulos. Algumas das mais conhecidas são: Georgia, Palatino, Playfair Display e FF Tisa Pro.
Sem serifas: Uma fonte mais neutra, porém moderna. Muito usada em materiais impressos. Possuem boa legibilidade e leiturabilidade.
Não possuem itálicas e sim obliquas e são indicadas para corpo de texto e títulos. Algumas das mais conhecidas são: Helvetica, Roboto, Proxima Nova e Brandon Grotesque.
Serifas grossas: Uma fonte mais impactante e estrutural, pois são criadas a partir de formas geométricas. Muito usada para compor títulos, anúncios, marcas, botões e etc. Algumas das mais conhecidas são: Clarendon, Josefin Slab, Adelle e Chaparral.
Script: Uma fonte mais "natural", parecem feitas a mão. São suaves e geralmente possuem ligaturas. Muito usada em eventos como natal, casamento, páscoa e etc. Não possuem boa leiturabilidade, por isso é indicada para títulos. Algumas das mais conhecidas são: Lavanderia, Salamander, Lobster e Grafolita Script.
Blackletter: Uma fonte com estilo mais medieval. Elas existem desde o século XII e foram utilizadas na primeira prensa tipográfica. Muito usada para representar contexto histórico, tradição, mas tem pouca leiturabilidade por isso é mais visto em títulos e marcas. Algumas das mais conhecidas são: New Rocker, Lucida Blackletter, Cabazon.
Display: Uma fonte sem uma característica padrão, geralmente são criadas de acordo com a necessidade do projeto. Muito utilizada em títulos e marcas pela pouca leituralibidade. Alguma das mais famosas são: Amatic, BlackCasper, Capture It e Silkscreen.

Conhecendo os diferentes sistemas de cores

Lucas Lima — Mon, 24 Jul 2023 20:00:00 +0000

No post anterior vimos que as cores tem significados e como montar uma paleta equilibrada e coerente com cada tipo de projeto, porém precisamos representá-las e assim como tudo em nossa vida, as cores também podem ser mostradas de diversas formas.

- RYB
RYB é um sistema de cores subtrativo que se baseia nas cores primárias (vermelho, amarelo e azul), ou seja, ele descreve a forma como as cores absorvem a luz e partindo delas obtemos as cores secundárias e terciárias. Ele é muito usado na teoria de cores e nas aulas de educação artística quando aprendemos a misturar as cores.

- RGB
RGB sem dúvidas é o sistema de cores mais conhecido. Ele é um sistema de cor aditivo, ou seja, diferentes cores são combinadas para criar uma nova cor por meio da adição de luz. Cada cor é representada por um valor numérico que vai de 0 à 255, onde 0 representa a ausência e 255 sua máxima intensidade. Esse sistema é muito utilizado em monitores e TVs.

- CMYK
CMYK é um acrônimo para a junção de cores utilizada nesse sistema de representação. Temos o C de ciano, M de magenta, Y de amarelo e K de preto. Esse modelo é muito utilizado em impressões e reprodução de cores em meios físicos por ser mais preciso. Com a combinação dessas cores podemos criar uma ampla gama de tons e para representá-las utilizamos o valor em % para cada cor, onde 0% significa ausência dessa cor e 100% a máxima intensidade.

Desvendando as cores: Um guia para os que acreditam que o mundo é apenas em preto e branco

Lucas Lima — Mon, 17 Jul 2023 19:00:00 +0000

As cores estão presentes no nosso cotidiano e mesmo que involuntariamente tem capacidade de comunicar, expressar, influenciar, sinalizar e identificar. Ela trás uma experiência sensorial que nos acompanha a todo momento, se tornando uma linguagem visual tão poderosa que muitas vezes ultrapassa a comunicação verbal. Esse fenômeno quem pode explicar é a psicologia das cores. Através dela podemos entender como, porque e por qual motivo aquelas cores foram utilizadas. Veja alguns significados a seguir:

A paleta de cores perfeita...

O uso estratégico das cores pode criar uma identidade visual marcante, estabelecendo uma conexão instantânea com o público-alvo. Pensando nisso, eu criei um método para a criação de uma paleta de cores. Segue o passo a passo:

1° Passo - Definir as cores de base: Por serem neutras, sempre inicio com preto e branco, elas são curingas e podem ser usadas tanto em detalhes como em textos criando bons contrastes e não deixando a leitura cansativa.

2° Passo - Definir a cor principal: Escolho 1 cor como principal, faço isso de acordo com a área do projeto buscando referências e padrões já usados.

3° Passo - Aplicar a teoria das cores: Escolhido a cor principal, aplico a teoria das cores para escolher mais algumas cores para compor a paleta. Existem vários caminhos a seguir, algumas opções são:

Harmonia monocromática: são variações de uma mesma cor, obtidas pela adição de branco, cinza ou preto na cor escolhida.
Harmonia análoga: aquelas que estão próximas umas das outras no círculo cromático e geralmente criam uma boa harmonia e coesão na junção.
Harmonia complementar: aquelas que estão diretamente opostas no círculo cromático e oferecem um forte contraste entre si.
Harmonia triádica: combinação de cores que utiliza um esquema de cores equidistantes no círculo cromático. Essas três cores formam um triângulo no círculo cromático e oferecem um equilíbrio visual agradável.

Aplicando o método

Agora que já temos os passos do método vamos aplicar... mas de uma forma diferente. Ao invés de criar uma nova paleta de cores trabalharemos com a análise de um projeto já pronto. Nesse caso será o site de uma clínica odontológica. Veja as imagens a seguir e vamos analisar.

Depois de analisar as imagens podemos seguir com o passo a passo.

1° Passo: Analisando o site podemos ver de cara que o branco e o preto são usados como cor de base, principalmente em textos.

2° Passo: Aqui a cor principal sem dúvidas é o azul, porém é nítido que que o azul mais usado é o que tem tom de céu. Ele está em 100% dos botões, links e áreas de destaque. Grandes chances desse azul bastante presente seja uma relação ou referência a área da saúde.

3° Passo: Aplicando a teoria das cores é perceptível que o designer que montou essa cartela brincou com as harmonias utilizando os tons monocromáticos do azul como o ciano que foi aplicado em alguns detalhes e ícones, e o tom mais escuro foi utilizado em áreas onde temos grande concentração de informação e aplicou a harmonia por contrate na cor laranja para botões de função parecida mostrando que não existe regra e que podemos usar mais cores desde que cada uma realmente represente e tenha uma função.

Assim, depois de analisar o site a paleta de cores ficou assim

As cores desempenham um papel essencial no design, elas não estão lá só para deixar colorido ou mais despretensioso, existe uma função, um porquê e eu espero que nesse pequeno texto eu tenha conseguido explicar e mostrar sua devida importância. E agora que já entendemos que as cores tem significados e como montar uma paleta equilibrada e coerente com cada tipo de projeto, como representá-las? (Spoiler do próximo texto :D)