Mais lidas:

Início Site Página 3

Os papéis no Scrum

Existem três papéis na estrutura do Scrum. Estes são idealmente colocados para garantir a comunicação ideal entre os membros da equipe. Enquanto muitas organizações têm outras funções envolvidas na definição e entrega do produto, o Scrum define apenas essas três.

Product Owner

O Product Owner, representando as partes interessadas do produto e a voz do cliente, é responsável por fornecer bons resultados comerciais. Portanto, o Product Owner é responsável pelo Product Backlog e por maximizar o valor que o time entrega. O Product Owner define o produto em termos centrados no cliente (geralmente histórias de usuários), adiciona-os ao Product Backlog e os prioriza com base na importância e nas dependências.

Um time de scrum deve ter apenas um Product Owner (embora um Product Owner possa suportar mais de uma equipe). Essa função não deve ser combinada com a do Scrum Master. O Product Owner deve se concentrar no lado comercial do desenvolvimento do produto e passar a maior parte do tempo em contato com as partes interessadas e o time.

O Product Owner não deve ditar como o time deverá alcançar uma solução técnica, mas buscará consenso entre os membros do time. Essa função é crucial e requer um entendimento profundo de ambos os lados. Deve ser capaz de comunicar o que a empresa precisa, perguntar por que ele precisa (porque pode haver melhores maneiras de conseguir isso) e transmitir a mensagem a todas as partes interessadas, incluindo o Time de Desenvolvimento, usando uma linguagem técnica, conforme necessário.

A comunicação é uma responsabilidade central. A capacidade de transmitir prioridades e ter empatia com os membros do time e as partes interessadas é vital para orientar o desenvolvimento do produto na direção certa. A função de Product Owner preenche a lacuna de comunicação entre o time e suas partes interessadas, servindo como proxy para as partes interessadas do time, e como representante do time para as partes interessadas.

Como o rosto da equipe para as partes interessadas, a seguir estão algumas das tarefas de comunicação do Product Owner para as partes interessadas:

  • Definir e anunciar lançamentos.
  • Comunicar o status da entrega e do time.
  • Compartilhar o progresso durante as reuniões de governança.
  • Compartilhar dados significativos (riscos, impedimentos, dependências e premissas) com as partes interessadas.
  • Negociar prioridades, escopo, financiamento e cronograma.
  • Verificar se o Product Backlog é visível, transparente e claro.

A empatia é um atributo essencial para o Product Owner – a capacidade de se colocar no lugar do outro. O Product Owner conversa com diferentes partes interessadas, que têm uma variedade de origens, funções e objetivos. Ele deve poder ver esses diferentes pontos de vista. Para ser eficaz, é aconselhável que conheça o nível de detalhe que o público precisa.

O time desenvolvimento precisa de feedback e especificações completas para que possa criar um produto de acordo com as expectativas, enquanto um patrocinador executivo pode precisar apenas de resumos de progresso. Fornecer mais informações do que o necessário pode perder o interesse das partes interessadas e perder tempo. Um meio direto de comunicação é o mais preferido pelos proprietários de produtos ágeis experientes.

A capacidade de se comunicar efetivamente também é aprimorada por ser hábil em técnicas que identificam as necessidades das partes interessadas, negociam prioridades entre os interesses das partes interessadas e colaboram com os desenvolvedores para garantir a implementação eficaz dos requisitos.

Scrum Master

O scrum é facilitado por um Scrum Master, responsável por remover os impedimentos para que não afetem a capacidade do time de entregar as metas e os resultados do produto. O Scrum Master não é um líder de equipe ou gerente de projetos tradicional, mas atua como um amortecedor entre a equipe e quaisquer influências adversas.

O Scrum Master garante que a estrutura do scrum seja seguida. Ele ajuda a garantir que o time siga os processos acordados na estrutura do Scrum, muitas vezes facilita as sessões principais e incentiva a equipe a melhorar. O papel também foi referido como facilitador de equipe ou líder de servidor para reforçar essas perspectivas duplas.

  • As principais responsabilidades atribuídas a um Scrum Master incluem (mas não estão limitadas a):
  • Ajudar o Product Owner a manter o backlog do produto de uma maneira que garanta que o trabalho necessário seja bem compreendido de forma que o time possa progredir continuamente;
  • Ajudando o time a determinar a definição de feito para o produto, com a contribuição dos principais interessados;
  • Treinar o time, dentro dos princípios Scrum, a fim de fornecer recursos de alta qualidade para seu produto;
  • Promovendo a auto-organização dentro do time;
  • Ajudar a equipe de scrum a evitar ou remover impedimentos ao seu progresso, interno ou externo ao time;
  • Facilitar eventos do time para garantir progresso regular;
  • Educar as principais partes interessadas sobre os princípios Ágil e Scrum;
  • Treinar o time de desenvolvimento para que sejam auto-organizados.

Uma das maneiras pelas quais a função de Scrum Master difere de um gerente de projeto é que este pode ter responsabilidades de gerenciamento de pessoas. Um Scrum Master fornece uma quantidade limitada de direção, já que se espera que a equipe seja capacitada e auto-organizada. O Scrum não reconhece formalmente o papel de gerente de projetos, pois as tendências tradicionais de comando e controle causariam dificuldades.

Time de Desenvolvimento

O Time de Desenvolvimento tem de três a nove membros que realizam todas as tarefas necessárias para criar incrementos de produção valiosos a cada sprint.

Embora os membros do time sejam referidos como desenvolvedores em alguma literatura, o termo refere-se a qualquer pessoa que desempenhe um papel no desenvolvimento e suporte do sistema ou produto, e pode incluir pesquisadores, arquitetos, designers, especialistas em dados, estatísticos, analistas, engenheiros, programadores e testadores, entre outros.

No entanto, devido à confusão que pode surgir quando algumas pessoas não sentem que o termo ‘desenvolvedor’ se aplica a elas, elas geralmente são chamadas apenas de membros do time.

O time é auto-organizado. Embora nenhum trabalho deva chegar à equipe, exceto através do Product Owner, e espera-se que o Scrum Master proteja o time de muita distração, o time ainda deve ser incentivada a interagir diretamente com os clientes e /ou partes interessadas para obter o máximo entendimento e imediatismo de feedback.

O Scrum

Scrum team discussing tasks. Arrow, report, working on laptop, conversation. Business concept. Vector illustration can be used for topics like agile management, teamwork, communication

O que é?

“Uma maneira melhor de construir produtos” (scrum.org)

O Scrum é um framework no qual as pessoas podem lidar com problemas complexos de adaptação, ao mesmo tempo em que fornecem produtos de maneira mais produtiva e criativa.

O Scrum em si é uma estrutura simples para colaboração eficaz da equipe em produtos complexos. Os co-criadores do Scrum, Ken Schwaber e Jeff Sutherland escreveram o Guia do Scrum para explicar o Scrum de forma clara e sucinta. Este guia contém a definição de Scrum. Essa definição consiste nos papéis, eventos, artefatos e regras da metodologia.

Scrum é:

  • Leve
  • Simples de entender
  • Difícil de dominar

A estrutura desafia as premissas da abordagem tradicional e sequencial do desenvolvimento de produtos e permite que as equipes se organizem, incentivando a localização física ou a colaboração online estreita de todos os membros da equipe, bem como a comunicação cara-a-cara diária entre todos os membros da equipe e disciplinas envolvidas.

Um princípio chave do Scrum é o duplo reconhecimento de que os clientes mudam de idéia sobre o que desejam ou precisam (geralmente chamado de volatilidade de requisitos) e que haverá desafios imprevisíveis – para os quais uma abordagem preditiva ou planejada não é adequada.

Dessa forma, o Scrum adota uma abordagem empírica baseada em evidências – aceitando que o problema não pode ser totalmente entendido ou definido com antecedência, e focando em como maximizar a capacidade da equipe de entregar rapidamente, responder a requisitos emergentes e adaptar-se à evolução. tecnologias e mudanças nas condições de mercado.

Quais seus valores?

O Scrum é uma abordagem orientada a feedback que, como todo controle de processo empírico, é sustentada pelos três pilares da transparência, inspeção e adaptação. Todo o trabalho dentro da estrutura do Scrum deve estar visível para os responsáveis ​​pelo resultado: o processo, o fluxo de trabalho, o progresso etc.

Para tornar essas coisas visíveis, os times do scrum precisam inspecionar frequentemente o produto que está sendo desenvolvido e quão bem o time está trabalhando. Com uma inspeção frequente, a equipe pode identificar quando seu trabalho se desvia dos limites aceitáveis ​​e adaptar seu processo ou o produto em desenvolvimento.

Esses três pilares exigem confiança e abertura no time, que os cinco valores seguintes do Scrum permitem:

  • Compromisso: Os membros do time comprometem-se individualmente a atingir seus objetivos a cada sprint.
  • Coragem: Os membros do time sabem que têm a coragem de lidar juntos com conflitos e desafios para que possam fazer a coisa certa.
  • Foco: Os membros do time se concentram exclusivamente nos objetivos de sua equipe e no backlog do sprint; não deve haver outro trabalho além da lista de pendências.
  • Abertura: os membros do time e seus stakeholders concordam em ser transparentes quanto ao trabalho e aos desafios que enfrentam.
  • Respeito: Os membros do time se respeitam por serem tecnicamente capazes e por trabalhar com boas intenções.

Como funciona?

Como uma metodologia ágil, o Scrum possui iterações chamadas de Sprint, onde representam ciclos de duas a quatro semanas, dentro do qual um conjunto de atividades deve ser executado.

O escopo destas iterações é gerenciado em um artefato conhecido como Product Backlog. Ao início de cada Sprint, é realizada uma cerimonia chamada Sprint Planning, onde o Product Owner prioriza os itens mais importantes do backlog e o time seleciona as atividades que serão capazes de implementar durante a Sprint. Estas atividades, por vez, são estimadas e gerenciadas através do Sprint Backlog.

Diariamente a equipe realizar uma cerimonia de acompanhamento chamada Daily Scrum. O objetivo é de compartilhar o status das atividades do time de desenvolvimento, informando o andamento do que já foi feito e do que está em andamento, afim de identificar possíveis impedimentos.

Ao fim de cada Sprint, o time se reúne, apresenta o incremento entregue e realizar a cerimonia de Sprint Review, onde irá coletar o feedback do Product Owner sobre o esperado. Esta talvez seja a cerimônia mais importante, já que serve como termômetro para o time quanto à maturidade entre time e o objetivo esperado pelo cliente.

Por fim, após a realização da Sprint Review, o time realiza a Sprint Retrospective, onde é feita uma retrospectiva com base nos acontecimentos durante a sprint. Os ponto são levantados e discutidos entre o atim afim de que ocorra uma melhoria contínua que possa amadurecer o time.

Assim o ciclo se reinicia por todos os passos enquanto perdurar o deadline do projeto.

Quais são as limitações?

O Scrum pode ser ineficiente quando:

  • Times cujos membros estão isolados de alguma maneira. O time de desenvolvimento deve possuir interação próxima e contínua, idealmente trabalhando juntos no mesmo espaço na maioria das vezes. Embora as recentes melhorias na tecnologia reduzam o impacto dessas barreiras (por exemplo, poder colaborar em board digital, kanban,…), o manifesto ágil prega que a melhor comunicação é cara-a-cara.
  • Times cujos membros possuem habilidades muito específicas. O time deve ser multidisciplinar, permitindo que trabalhem em tarefas fora de sua especialidade. Isso pode ser incentivado pela boa liderança do facilitador. Embora os membros da equipe com habilidades muito específicas possam e contribuam bem, eles devem ser incentivados a aprender mais e colaborar com outras disciplinas.
  • Produtos com muitas dependências externas. No Scrum, dividir o desenvolvimento do produto em sprints curtos requer um planejamento cuidadoso; dependências externas, como testes de aceitação do usuário ou coordenação com outras equipes, podem levar a atrasos e falhas de sprints individuais.
  • Produtos maduros, herdados ou com controle de qualidade regulamentado. No Scrum, os incrementos do produto devem ser totalmente desenvolvidos e testados em um único sprint; os produtos que precisam de grandes quantidades de testes de regressão ou de segurança para cada versão, são menos adequados para sprints curtos do que para versões mais longas em cascata.
  • Da perspectiva dos negócios, o Scrum tem muitas virtudes, uma das quais é que foi projetado para oferecer as melhores soluções de negócios. No entanto, a eficiência com que o faz em qualquer organização pode variar bastante e depende em grande parte da capacidade da organização de aderir às diretrizes de implementação. Toda empresa tem sua própria estrutura organizacional, cultura e conjunto de práticas comerciais distintas, e algumas são mais naturalmente acessíveis a essa metodologia do que outras.

A origem do Scrum

O surgimento

Ao contrário do que muitos imaginam, as primeiras idéias do que viria a ser o Scrum começaram a ser introduzidas em um artigo publicado no The Harvard Business Review intitulado “The new new product development game” escrito por Hirotaka Takeuchi e Ikujiro Nonaka. No artigo, os autores utilizam analogias entre a gestão de produtos e o Rugby, esporte de origem inglesa.

Os autores comparam os times como corredores em uma corrida de revezamento, passando o bastão a cada meta e trabalhando assim, de forma linear. Por outro lado, existiam outros times que eram comparados a jogadores de Rugby, realizando jogadas únicas e passando as jogadas somente para frente ou para trás, de acordo com a necessidade do time.

Então, notaram que em grande parte dos projetos onde times pequenos e multidisciplinares conseguir ser mais produtivos quando trabalhavam como a analogia citada do Rugby. Associando então estes times eficazes à formação “Scrum” utilizada no esporte.

Nesta formação, um certo grupo de jogadores se reúne para iniciar uma jogada onde o trabalho em grupo é importante, pois se algum jogador deixar a formação, a jogada é desarmada.

O nome “Scrum” passou a ser utilizado no livro “Wicked problems, righteous solutions” de DeGrace e Stahl.

Trazendo o contexto para o desenvolvimento de software, Jeff Sutherland, John Scumniotales e Jeff McKenna decidiram testar a metodologia em 1993 na Scrum na Easel Corp. Já em 1996, Schwaber, Sutherland, McKenna e Scumniotales publicaram um livro chamado “SCRUM Development Process”. Foi a partir deste momento que os profissionais começaram a colocar a eficiência o modelo Waterfall em dúvida.

Referência

TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard Business Review, Boston, MA, Estados Unidos, v. 64, n. 1, p. 137-146, jan./fev. 1986.

DEGRACE, P.; STAHL L. H. Wicked problems, righteous solutions: a catalogue of modern software engineering paradigms. Nova Jersey: Yourdon Press, 1990.

SUTHERLAND, J.; SCHWABER, K. A Guide to the SCRUM Development Process. 1996.

Jornada de Usuário

O que é?

O mapeamento da Jornada de Usuário é uma ferramenta capaz de identificar todos os pontos de contato de um usuário ao realizar uma atividade. Toda interação pode ser traduzida em uma história sobre a relação do usuário com seu produto ou serviço.

É importante frisar que a Jornada do Usuário é uma ferramenta não padronizada. Ela pode ter diferentes formas, formatos e cores. Seu modelo mais simples deve conter:

  • o que as pessoas esperam em cada um desses momentos?
  • o que elas precisam?
  • suas habilidades estão coerentes com os desafios cognitivos envolvidos?
  • o próximo passo está claro?

Por que é importante?

A Jornada do Usuário une duas ferramentas fundamentais no trabalho de um Product Designer: Storytelling e Visibilidade.

  • Storytelling: é a capacidade de contar histórias de maneira relevante, onde os recursos audiovisuais são utilizados juntamente com as palavras.
  • Visibilidade: é transformar dados brutos em informação visual. Essa ferramenta traz a possibilidade de uma análise mais eficaz, identificando outliers, tendências e padrões.

Portanto, a Jornada do Usuário é importante porque ela é capaz de ilustrar todo o caminho do usuário, permitindo a identificação de oportunidades, gaps e insights de uma forma mais rápida.

Como é feito o processo de mapeamento da jornada do usuário?

A Jornada do Usuário não possui um modelo padrão. Diferentes empresas usam diferentes formatos para esta ferramenta. Contudo, existem alguns componentes-chave que não podem faltar em sua elaboração.

  • Ponto de vista: antes de tudo é necessário definir a persona da jornada. Ela será o ator, o protagonista do processo. Não se esqueça de que a Jornada do Usuário deve ser elaborada a partir do ponto de vista da persona;
  • Cenário: determine por qual experiência o seu ator está passando. Pode ser uma jornada já existente ou, então, a definição de uma nova experiência. É importante sempre deixar claro qual o objetivo do usuário nesse processo;
  • Ações, mindsets, emoções: esse elemento é crucial. O coração da jornada do usuário deve ser o que ele faz, sente e pensa durante a experiência. Essas informações não são aleatórias. Pesquisas devem ser aplicadas para compilar informações relevantes para compor esse elemento;
  • Pontos de contato e canais de comunicação: a Jornada deve conter os pontos de interação do usuário bem como o canal aonde esse contato é realizado. Por exemplo: websites, aplicativos, lojas físicas. Esse elemento é importante porque é onde geralmente existem inconsistências e más experiências;
  • Insights e responsabilidades: o objetivo da Jornada é descobrir falhas no processo de experiência do usuário. Portanto, todo e qualquer Insight deve ser listado e mostrado para a equipe. Além disso, é importante determinar papéis e responsabilidades para as diferentes partes da Jornada. Dessa forma, há clareza de quem é o “dono”de cada parte do processo.
Itaú Jornada do usuário Projeto interno Itaú Ilustração 2012 (com ...

Dicas essenciais para uma Jornada de Usuário eficaz

O sucesso na elaboração da Jornada do Usuário vai além da inserção dos componentes-chave acima listados. Essa é uma ferramenta que requer bastante trabalho para que seu processo continue no caminho certo. Confira algumas dicas de ouro:

  • Defina o “porquê” e “o que”: identifique e deixe claro os objetivos os quais a Jornada do Usuário irá ajudar. Saiba qual objetivo; quem irá usar a Jornada do Usuário; quem são as personas e suas necessidades; como será compartilhada;
  • A verdade é a base: apesar da Jornada contar um a história, esta não pode ser uma ficção. É necessário efetuar pesquisas — qualitativas e quantitativas — diversas que irão embasar a sua ferramenta;
  • Colaboração: a construção da Jornada do Usuário é algo valioso, portanto é importante que seja compartilhada e feita em conjunto com os demais stakeholders;
  • Não seja ansioso: tenha todas as informações necessárias antes de partir para a elaboração do template/ design da Jornada. Caso contrário você terá uma ferramenta com diversas falhas;
  • Promova o engajamento com a ferramenta: promova a Jornada do Usuário para os demais stakeholders. Faça apresentações, reuniões e encontros para compartilhar e trazer engajamento para com a ferramenta;
  • Foco no usuário: a Jornada do Usuário é uma ferramenta que pretende identificar e sanar necessidades do usuário/consumidor. Portanto, não o perca de vista. Ele é o protagonista e o motivo da elaboração dessa ferramenta.
O que é Mapa de Empatia e o passo a passo para criar um

Quais os benefícios?

A Jornada do Usuário traz uma série de benefícios, tais quais:

  • suporte para os objetivos da empresa: a experiência do usuário deve estar alinhada com os objetivos da empresa. Más experiências afetam o faturamento, a imagem e a reputação de uma empresa. Dessa forma, a Jornada do Usuário ajuda a identificar oportunidades importantes em UX Design;
  • alinhamento dos objetivos: a Jornada deve ser compartilhada para os diversos stakeholders da organização. Isso permite que a comunicação e o entendimento dos objetivos esteja claro para todos, não havendo falhas e fragmentos desconexos;
  • facilitam insights: a Jornada do Usuário é uma ferramenta visual. Sendo assim, é muito mais fácil a identificação dos pontos fortes e pontos fracos de uma interação. Isso abre portas para a geração de mais ideias e insights;
  • facilitam as interfaces entre áreas: a Jornada do Usuário ajuda na interface e na comunicação entre as áreas da empresa por ser um documento compartilhado e que contém informações importantes para a empresa como um todo;
  • não deixa o usuário sair do foco: A Jornada do Usuário é sobre a experiência dos clientes/consumidores de algum produto. O usuário é o protagonista e a Jornada deve sempre mantê-lo em foco;
  • visibilidade dos trabalhos individuais: a Jornada do Usuário permite a fácil identificação dos impactos do trabalho de cada pessoa envolvida no projeto. Cada colaborador consegue perceber onde e como o seu trabalho interfere na experiência do usuário. Essa visibilidade aumenta a satisfação e o engajamento da equipe.

Fontes: Jornada do Usuário — O que é e Sua Importância em UX Design | Mapeando a jornada e a experiência do usuário

O que é BDD?

O Behavioral Driven Development (BDD) é uma abordagem de desenvolvimento de software que evoluiu do TDD (Test Driven Development). Difere por ser escrito em um idioma compartilhado, o que melhora a comunicação entre equipes e partes interessadas, técnicas e não técnicas. Nas duas abordagens de desenvolvimento, os testes são escritos à frente do código, mas no BDD, os testes são mais focados no usuário e baseados no comportamento do sistema.

O BDD aumenta o TDD e o ATDD com as seguintes táticas:

  • Aplique o princípio “Five whys” a cada história de usuário proposta, para que seu objetivo esteja claramente relacionado aos resultados dos negócios;
  • pensar “de fora para dentro”, ou seja, implementar apenas os comportamentos que contribuem mais diretamente para esses resultados de negócios, de modo a minimizar o desperdício;
  • descrever comportamentos em uma única notação que seja diretamente acessível a especialistas, testadores e desenvolvedores de domínio, para melhorar a comunicação;
  • aplique essas técnicas até os níveis mais baixos de abstração do software, prestando atenção especial à distribuição do comportamento, para que a evolução permaneça barata.

Porquê usar o BDD?

O TDD funciona satisfatoriamente, desde que o proprietário da empresa esteja familiarizado com a estrutura de teste de unidade sendo usada e suas habilidades técnicas sejam suficientemente fortes, o que nem sempre é o caso. Nessas circunstâncias, o BDD tem a vantagem porque os casos de teste podem ser escritos em um idioma comum usado pelas partes interessadas, como, por exemplo, o inglês. Esse acesso a uma comunicação mais clara e com pouco jargão é provavelmente a maior vantagem do uso do BDD, possibilitando que a colaboração entre as equipes técnica e não técnica funcione com maior eficiência.

O que esperar do BDD?

Como descrito acima, a vantagem de os casos de teste do BDD serem escritos em um idioma comum é que os detalhes de como o aplicativo se comporta podem ser facilmente compreendidos por todos. Por exemplo, os casos de teste podem ser escritos usando exemplos em tempo real dos requisitos reais, para explicar o comportamento do sistema.

As equipes que já usam TDD ou ATDD podem considerar o BDD por vários motivos:

  • O BDD oferece orientação mais precisa sobre a organização da conversa entre desenvolvedores, testadores e especialistas em domínio;
  • As notações originárias da abordagem BDD, em particular a tela dada quando, estão mais próximas da linguagem cotidiana e têm uma curva de aprendizado mais rasa em comparação com as de ferramentas como Fit / FitNesse;
  • As ferramentas direcionadas a uma abordagem BDD geralmente oferecem a geração automática de documentação técnica e do usuário final a partir das “especificações” do BDD.

Quais os pré requisitos para utilização do BDD?

  • Os requisitos devem ser convertidos em histórias de usuários que possam definir exemplos concretos;
  • Cada exemplo deve ser um cenário de usuário válido, em vez de um mero caso de teste;
  • Um entendimento da matriz “função-recurso-razão” e a fórmula “determinado quando então”;
  • Consciência da necessidade de escrever “a especificação do comportamento de uma classe” em vez de “o teste de unidade de uma classe”.

Quais as possíveis armadilhas?

Embora Dan North, que formulou a abordagem do BDD pela primeira vez, afirme que ela foi projetada para abordar questões recorrentes no ensino do TDD, é claro que o BDD exige familiaridade com uma gama maior de conceitos do que o TDD, e parece difícil recomendar a um programador iniciante que deve primeiro aprender BDD sem exposição prévia aos conceitos de TDD.

O uso do BDD não requer ferramentas ou linguagens de programação específicas e é principalmente uma abordagem conceitual; torná-lo uma prática puramente técnica ou que depende de ferramentas específicas seria errar completamente o ponto.

Ferramentas BDD

Cucumber

Cucumber é uma estrutura de teste que suporta BDD. No Cucumber, as especificações do BDD são escritas em inglês simples e prático, definido pela linguagem Gherkin. Gherkin apresenta o comportamento do aplicativo usado, a partir do qual o Cucumber pode gerar os casos de teste de aceitação. Ele possui uma estrutura desenvolvida por Ruby que pode funcionar em diferentes tecnologias.

Speckflow

O Specflow evoluiu da estrutura do Cucumber usando Ruby on Rails e é usado principalmente para projetos .Net. Ele usa também a linguagem Gherkin.

Resumindo… Vale a pena?

O BDD nos permite desenvolver, testar e pensar sobre o código do ponto de vista do proprietário da empresa. Você precisa ter a mentalidade de implementar “exemplos em tempo real” em vez de implementar apenas “funcionalidades”. Experimente!

Product Backlog

Um backlog ágil bem priorizado não apenas facilita o planejamento de liberação e iteração, mas também transmite tudo o que sua equipe pretende gastar, incluindo o trabalho interno que o cliente nunca notará. Isso ajuda a definir expectativas com as partes interessadas e outras equipes, especialmente quando trazem trabalho adicional para você, e torna o tempo de desenvolvimento um ativo fixo.

Uma lista de Product Backlog é uma lista de trabalho priorizada para a equipe de desenvolvimento derivada do roteiro e de seus requisitos. Os itens mais importantes são mostrados na parte superior da lista de pendências do produto para que a equipe saiba o que entregar primeiro. A equipe de desenvolvimento não trabalha com o backlog no ritmo do Product Owner e nem está enviando trabalho para a equipe de desenvolvimento. Em vez disso, a equipe de desenvolvimento extrai o trabalho do Product Backlog, pois há capacidade para ele, continuamente (kanban) ou por iteração (scrum).

O princípio dos dois “R”s

O Roadmap e os Requisitos de uma equipe fornecem a base para o Product Backlog. As iniciativas do roteiro são divididas em vários épicos, e cada épico terá vários requisitos e histórias de usuários.

O roteiro e os requisitos de uma equipe fornecem a base para o backlog do produto. As iniciativas do roteiro são divididas em vários épicos, e cada épico terá vários requisitos e histórias de usuários. Vamos dar uma olhada no roteiro de um produto fictício chamado “Comida Express”.

Como o site é a primeira iniciativa no roteiro, queremos dividir essa iniciativa em épicos (mostradas aqui em azul, verde e roxo) e histórias de usuários para cada uma dessas épicas.

O Product Owner organiza cada uma das histórias de usuários em uma única lista para a equipe de desenvolvimento. Podendo optar por entregar um épico completo primeiro (à esquerda). Ou talvez seja mais importante para a aplicação, testar a realização de um pedido, o que exige histórias de vários épicos (à direita). Veja os exemplos abaixo:

O que pode influenciar a priorização de um Product Owner?

  • Prioridade do cliente
  • Urgência de obter feedback
  • Dificuldade de implementação relativa
  • Relações simbióticas entre itens de trabalho (por exemplo, B é mais fácil se fizermos A primeiro)

Embora o Product Owner tenha a tarefa de priorizar a lista de pendências, isso não é feito em vão. Product Owners eficazes buscam informações e feedback de clientes, designers e equipe de desenvolvimento para otimizar a carga de trabalho de todos e a entrega do produto.

Mantendo o backlog vivo

Depois que o backlog do produto é criado, é importante mantê-lo regularmente para acompanhar a aplicação. Os Product Owners devem revisar a lista de pendências antes de cada reunião de planejamento da iteração para garantir que a priorização esteja correta e que o feedback da última iteração tenha sido incorporado. A revisão regular do backlog é frequentemente chamada de “backlog grooming” em círculos ágeis (alguns usam o termo refinamento do backlog).

Quando a lista de pendências aumenta, os Product Owners precisam agrupar a lista de pendências em itens de curto e longo prazo. Itens de curto prazo precisam ser totalmente detalhados antes de serem rotulados como tal. Isso significa que histórias completas de usuários foram elaboradas, a colaboração com o design e o desenvolvimento foi resolvida e estimativas do desenvolvimento foram feitas.

Itens de longo prazo podem permanecer um pouco vagos, embora seja uma boa idéia obter uma estimativa aproximada da equipe de desenvolvimento para ajudar a priorizá-los. A palavra-chave aqui é “aproximada”: as estimativas mudarão quando a equipe entender completamente e começar a trabalhar nesses itens de longo prazo.

O backlog serve como a conexão entre o Product Owner e a equipe de desenvolvimento. O Product Owner pode re-priorizar o trabalho na lista de pendências a qualquer momento, devido ao feedback do cliente, estimativas de refino e novos requisitos. Quando o trabalho estiver em andamento, mantenha as alterações no mínimo, pois elas “perturbam” a equipe de desenvolvimento e afetam o foco, o fluxo e o moral.

Depois que o backlog crescer além da capacidade de longo prazo da equipe, não há problema em fechar problemas que a equipe nunca alcançará. Sinalize esses problemas com uma resolução específica, como “fora do escopo”, no rastreador de problemas da equipe, para usar posteriormente em pesquisas.

Pontos a serem observados constantemente

  • O Product Owner prioriza o backlog no início do projeto, mas não o ajusta à medida que o feedback chega dos desenvolvedores e das partes interessadas.
  • A equipe limita os itens da lista de pendências àqueles voltados para o cliente.
  • O backlog é mantido como um documento armazenado localmente e compartilhado com pouca frequência, impedindo que as partes interessadas obtenham atualizações.

Como os backlogs de produtos mantêm uma equipe ágil?

Os Product Owners experientes cuidam rigorosamente da lista de pendências de produtos de seu programa, tornando-o um esboço confiável e compartilhável dos itens de trabalho de um projeto.

Os pedidos em atraso estimulam debates e escolhas que mantêm um programa saudável – nem tudo pode ser a principal prioridade.

As partes interessadas desafiarão as prioridades, e isso é bom. A promoção da discussão sobre o que é importante coloca as prioridades de todos em sincronia. Essas discussões promovem uma cultura de priorização de grupo, garantindo que todos compartilhem a mesma mentalidade no programa.

O backlog do produto também serve como base para o planejamento da iteração. Todos os itens de trabalho devem ser incluídos no backlog: histórias de usuários, bugs, alterações de design, dívida técnica, solicitações de clientes, itens de ação da retrospectiva etc. Isso garante que todos os itens de trabalho sejam incluídos na discussão geral de cada iteração. Os membros da equipe podem fazer trocas com o Product Owner antes de iniciar uma iteração com conhecimento completo de tudo o que precisa ser feito.

Os product owners determinam a prioridade dos itens de trabalho na lista de pendências, enquanto a equipe de desenvolvimento determina a velocidade através da lista de pendências. Esse pode ser um relacionamento tênue para novos product owners que desejam “enviar” trabalho para a equipe. Saiba mais em nosso artigo sobre limites e fluxo de trabalho em andamento.

Kanban

Vamos falar de um dos métodos mais conhecidos, principalmente por quem conhece o Sistema Toyota de Produção. Foi como parte do sistema onde se deveria controlar estoque de materiais, que o Kanban nasceu.

Na década de 60, os japoneses criaram um quadro com colunas e cartões coloridos para que pudessem controlar o estoque de materiais para não exceder nem faltar produtos, provocando um equilíbrio entre o estoque e a linha de produção.

Hoje, o método se tornou uma ferramenta universal para gestão de tarefas. Mas afinal, o que é o Kanban?

O que é Kanban?

Oriunda do Japão, o termo significa “cartão”, e recebeu este nome pela sua criadora, a Toyota. Ele nada mais é do que um um sistema ágil e visual para controle de produção ou gestão de tarefas.

Qual é a proposta do Kanban?

Quais os tipos de Kanban?

Há dois tipos de Kanban:

Kanban de Produção

Este talvez seja o tipo mais utilizado nas empresas. Consiste em uma gestão de atividades. É separado por três colunas: A Fazer, Em Execução e Feito. Nada impede que outras colunas possam ser criadas de acordo com a necessidade.

Cada uma dessas colunas possuirá cartões que ilustrarão as atividades em movimento do time de acordo com o fluxo que está sendo trabalhado. Abaixo podemos ver uma imagem que poderá ilustrar melhor:

Kanban de Movimentação

Este segundo tipo é mais comum no setor industrial. Ele basicamente consiste em uma gestão de controle e acompanhamento. Não há um “padrão” a ser seguido, já que cada coluna é criada de acordo com a necessidade da empresa.

Nestas colunas, geralmente separadas por produtos ou segmentos de produtos, os cartões podem corresponder à produção e o controle de entrada e saída dos produtos. Abaixo temos um exemplo ilustrativo:

Como funciona?

Inicialmente o Kanban Board foi utilizado como um item físico, mas hoje temos várias ferramentas online que oferecem um leque de funcionalidades para complementar o quadro. Eu particularmente prefiro utilizar o quadro físico, já que considero que o Kanban tem um proposta bastante visual, onde o time estará sempre de olhos nos cartões.

Independente de ser digital ou físico, ele se divide em três partes:

Quadro

Este é simplesmente a base. Onde as colunas e os cartões estarão disponíveis. Um time poderá ter um ou mais quadros, dependendo da necessidade.

Coluna

Esta parte vai variar um pouco dependendo do tipo de Kanban estamos trabalhando.

Quando é o modelo de produção, cada coluna corresponde a um status do fluxo de entrega. Mas quando estamos falando do modelo de movimentação, cada coluna pode ser, por exemplo, um produto diferente.

Cartão

O item de movimentação do quadro, as tarefas. Para organizar e facilitar a leitura, usa-se cartões de várias cores para que também possa ilustrar por exemplo, o nível de prioridade, categoria da tarefa, o responsável… Por aí vai.

Manifesto Ágil

Imagem: katemangostar
Imagem: katemangostar

O que é Manifesto Ágil?

O Manifesto ágil é basicamente um guia de valores e princípios a serem seguidos durante o processo de desenvolvimento ágil de software.

Entre os dias 11 e 13 de fevereiro de 2001, no resort de esqui The Lodge at Snowbird, nas montanhas Wasatch, Utah, dezessete pessoas se encontraram para conversar, esquiar, relaxar e tentar encontrar um terreno comum. O que surgiu foi o Manifesto Ágil de ‘Desenvolvimento de Software’. Representantes da Extreme Programming, SCRUM, DSDM, Desenvolvimento de Software Adaptável, Crystal, Desenvolvimento Orientado a Recursos, Programação Pragmática e outros simpatizam com a necessidade de uma alternativa aos processos de desenvolvimento de software pesado, orientados por documentação.

Agora, seria difícil encontrar uma reunião maior de anarquistas organizacionais; portanto, o que emergiu dessa reunião foi simbólico – um Manifesto para o Desenvolvimento Ágil de Software – assinado por todos os participantes. Assim surge também a Agile Alliance (Aliança Ágil).

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo.

Quem foram estes autores do documento?

Os 17 integrantes da reunião foram: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland e Dave Thomas.

Quais são os valores descritos no manifesto?

Em um texto enviado para a Agile Alliance, Jim Highsmith diz o seguinte:

O movimento Agile não é anti-metodologia, de fato, muitos de nós querem restaurar a credibilidade da palavra metodologia. Queremos restaurar um equilíbrio. Adotamos a modelagem, mas não para registrar algum diagrama em um repositório corporativo empoeirado. Adotamos a documentação, mas não centenas de páginas de volumes nunca mantidos e raramente usados. Planejamos, mas reconhecemos os limites do planejamento em um ambiente turbulento. Aqueles que marcariam os defensores do XP ou SCRUM ou de qualquer outra Metodologia Ágil como “hackers” ignoram as metodologias e a definição original do termo hacker.

Assim, foram definidos quatro valores essenciais para que houvesse um equilíbrio metodologia criada dentro da cultura ágil.

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

O que cada valor quer agregar?

Indivíduos e interações mais que processos e ferramentas

O desenvolvimento de software é uma atividade humana. A comunicação é um fator primordial para que time e cliente possam chegar ao mesmo caminho. Processos e ferramentas são sempre necessários, mas de maneira mais leve.

Software em funcionamento mais que documentação abrangente

Aqui vai a maior cutucada ao modelo cascata. O resultado mais esperado pelo cliente, é o software funcionando e agregando valor ao seu negócio. Documentos são também importantes desde que possam de fato agregar valor.

Colaboração com o cliente mais que negociação de contratos

Para que possamos agregar o valor esperado pelo cliente, nada é mais essencial do que a união e colaboração. Decisões sendo feitas em conjunto levam o projeto a uma maturidade que tende a beneficiar o sucesso do projeto.

Responder a mudanças mais que seguir um plano

A palavra chave para este valor é Feedback. O time deve aprender com os erros e acertos durante o percurso. Assim, podendo se adaptar de maneira mais fácil e rápida aos caminhos do projeto.

O que é o agil?

Muito se houve falar sobre as “metodologias” ágeis para gestão de projetos modernos. Mas sabemos mesmo o que significa o ágil?

Já inicio discordando em chamar o Ágil de metodologia. O vejo como um mindset.

Mindset é oriundo da língua inglesa que significa “Mentalidade” ou “Atitude Mental”, ou ainda, “Modelos Mentais

Logo, concluímos que o Ágil nada mais é do que uma mentalidade de gerenciar um projeto. Quando pensamos dessa forma, podemos dizer resumidamente que o mindset ágil é uma forma de entregar um valor de uma maneira mais rápida.

Ótimo! Mas quando e como essa mentalidade iniciou?

Em meados dos anos 90, quando os gestores começaram a avaliar os grande problemas do uso do modelo cascata (waterfall) como uma ferramente altamente burocrática e que não oferecia muita eficiência. Começaram então a estudar uma nova abordagem onde os engenheiros pudessem trabalhar de forma mais eficiente e que conseguissem entregar ao cliente algo que realmente pudesse agregar valor. Surgiu então os métodos leves.

Manifesto Ágil

Após realizarem testes com os métodos leves e começarem a colher frutos, várias metodologias diferentes começaram a surgir: Scrum, XP (Extreme Programming), FDD (Featuren Driven Development), Crystal Clear, ASD (Adaptive Software Development) e DSDM (Dynamic Systems Development Method).

Com essa evolução crescente, em 2001, nas montanhas nevadas em Utah, Estados Unidos, 17 profissionais se juntaram para criar o que chamamos de Manifesto Ágil. Um documento que simboliza a evolução do desenvolvimento de software. Assim nasce o Ágil.

O documento expressa a crença dos valores fundamentais para cultura do Ágil:
– Indivíduos e interações mais que processos e ferramentas
– Software em funcionamento mais que documentação abrangente
– Colaboração com o cliente mais que negociação de contratos
– Responder a mudanças mais que seguir um plano

Em Resumo…

O mindset ágil veio para que os profissionais possam de fato entender melhor o cliente e entregar algo de valor. Mas ainda existe muita discussão sobre o modelo tradicional de gestão de projetos (Cascata).

O ágil se divide em fases que representam um conjunto de atividades relacionadas de maneira lógica.Esta estrutura de permite um melhor controle da gestão do projeto. Normalmente, o ciclo de um projeto possui as seguintes fases:
– Início do projeto
– Organização e preparação
– Execução do trabalho
– Encerramento do projeto

Quando uma fase chega ao fim, um produto é migrado para a fase seguinte. Quando falamos de um ciclo de vida de projetos ágeis, o início e fim de cada fase representa um ponto de reavaliação do trabalho que será e já foi realizado, assim tonando mais fácil e rápido diagnosticar e corrigir erros que impactam na performance. do time.