Framework Scrum / Ágil: ajudando a desenvolver produtos

Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para problemas complexos.

Em suma, Scrum requer um Scrum Master para promover um ambiente onde:

1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.

2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor durante uma Sprint.

3. O Scrum Team e seus stakeholders inspecionam os resultados e se ajustam para a próxima Sprint.

4. Repita

Scrum é simples. Experimente como está e determine se sua filosofia, teoria e estrutura ajudam a atingir objetivos e criar valor. O framework Scrum é propositalmente incompleto, apenas definindo as partes necessárias para implementar a teoria Scrum. O Scrum é construído sobre a inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às pessoas instruções detalhadas, as regras do Guia do Scrum orientam seus relacionamentos e interações.

Vários processos, técnicas e métodos podem ser empregados com o framework. Scrum se acopla as práticas existentes ou as torna desnecessárias. Scrum torna visível a eficácia relativa da gestão atual, meio ambiente e técnicas de trabalho, para que melhorias possam ser feitas.

Scrum é baseado no empirismo e lean thinking. O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões com base no que é observado. O lean thinking reduz o desperdício e se concentra no essencial.

Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar o risco. Scrum envolve grupos de pessoas que, coletivamente, possuem todas as habilidades e conhecimentos necessários para fazer o trabalho e compartilhar ou adquirir essas habilidades conforme necessário.

Scrum combina quatro eventos formais para inspeção e adaptação, contidos dentro de um evento, a Sprint. Esses eventos funcionam porque implementam os pilares empíricos do Scrum: transparência, inspeção e adaptação.

A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum Team consiste em um Scrum Master, um Product owner e Developers. Dentro de um Scrum Team, não há sub-times ou hierarquias. É uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto.

Os Scrum Teams são multifuncionais, o que significa que os membros possuem todas as habilidades necessárias para criar valor a cada Sprint. Eles também são autogerenciáveis, o que significa que decidem internamente quem faz o quê, quando e como.

O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral, descobrimos que times menores se comunicam melhor e são mais produtivos. Se os Scrum Teams se tornarem muito grandes, eles devem considerar a reorganização em vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar o mesma meta do produto, Product Backlog e Product Owner.

O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a colaboração com stakeholder, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e qualquer outra coisa que possa ser necessária. Eles são estruturados e empoderados pela organização para gerenciar seu próprio trabalho. Trabalhar em Sprints em um ritmo sustentável melhora o foco e a consistência do Scrum Team.

Todo o Scrum Team é responsável por criar um Incremento valioso e útil a cada Sprint. Scrum define três responsabilidades específicas dentro do Scrum Team: os Developers, o Product Owner e o Scrum Master.

Developers são as pessoas do Scrum Team que estão comprometidas em criar qualquer aspecto de um Incremento utilizável a cada Sprint.

As habilidades específicas necessárias pelos Developers geralmente são amplas e variam de acordo com o domínio de trabalho. No entanto, os Developers são sempre responsáveis por:

● Criar um plano para a Sprint, o Sprint Backlog;

● Introduzir gradualmente qualidade aderindo a uma Definição de Pronto;

● Adaptar seu plano a cada dia em direção à meta da Sprint; e,

● Responsabilizar-se mutuamente como profissionais.

O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma como isso é feito pode variar amplamente entre organizações, Scrum Teams e indivíduos.

O Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog , que inclui:

● Desenvolver e comunicar explicitamente a meta do produto;

● Criar e comunicar claramente os itens do Product Backlog;

● Ordenar os itens do Product Backlog; e,

● Garantir que o Product Backlog seja transparente, visível e compreensível.

O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros.

Independentemente disso, o Product Owner ainda é o responsável.

Para que os Product Owners tenham sucesso, toda a organização deve respeitar suas

decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio do incremento inspecionável na revisão da sprint.

O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar as

necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o

Product Backlog podem fazê-lo tentando convencer o Product Owner.

O Scrum Master é responsável por estabelecer o Scrum conforme definido no Guia do Scrum.

Eles fazem isso ajudando todos a entender a teoria e a prática do Scrum, tanto no Scrum Team quanto na organização.

O Scrum Master é responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas, dentro do framework Scrum Scrum Masters são verdadeiros líderes que servem ao Scrum Team e à organização como um todo.

O Scrum Master serve ao Scrum Team de várias maneiras, incluindo:

● Treinar os membros do time em autogerenciamento e cross-funcionalidade;

● Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto;

● Provocando a remoção de impedimentos ao progresso do Scrum Team; e,

● Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos

dentro do Timebox.

O Scrum Master serve o Product Owner de várias maneiras, incluindo:

● Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;

● Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;

● Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;

e,

● Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário.

O Scrum Master serve a organização de várias maneiras, incluindo:

● Liderar, treinar e orientar a organização na adoção do Scrum;

● Planejar e aconselhar implementações de Scrum dentro da organização;

● Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos; e,

● Remover barreiras entre stakeholders e Scrum Teams.

Sprints são o coração do Scrum, onde ideias são transformadas em valor. São eventos de duração fixa de um mês ou menos para criar consistência. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior.

Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints.

Durante a Sprint:

● Nenhuma mudança é feita que coloque em risco a meta da Sprint;

● A qualidade não diminui;

● O Product Backlog é refinado conforme necessário; e,

● O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido.

Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a uma meta do Produto ao menos uma vez por mês. Quando o horizonte de uma Sprint é muito longo, a meta da Sprint pode se tornar inválida, a complexidade pode aumentar e o risco pode aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado um projeto curto.

Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative flows. Embora comprovadamente úteis, eles não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que já aconteceu pode ser usado para a tomada de decisão voltada para o futuro.

Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint.

A Sprint Planning inicia a Sprint ao definir o trabalho a ser realizado na Sprint. Este plano resultante é criado pelo trabalho colaborativo de todo o Scrum Team.

O Product Owner garante que os participantes estejam preparados para discutir os itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos.

A Sprint Planning aborda os seguintes tópicos:

Tópico um: Por que esta Sprint é valiosa?

O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual. Todo o Scrum Team então colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint deve ser finalizada antes do final da Sprint Planning.

Tópico dois: O que pode ser feito nesta Sprint?

Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança.

Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto, quanto mais os Developers sabem sobre seu desempenho anterior, sua capacidade futura e sua Definição de Pronto, mais confiantes eles estarão em suas previsões quanto a Sprint.

Tópico três: Como o trabalho escolhido será realizado?

Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor.

A Meta da Sprint, os itens do Product Backlog selecionados para a Sprint, mais o plano para entregá-los são chamados juntos de Sprint Backlog.

A Sprint Planning tem um Timebox definido com duração máxima de de oito horas para uma Sprint de um mês. Para Sprints mais curtas, o evento geralmente é mais curto.

Uma das mais populares metodologias de teste de software (usada por 58% das organizações que adotaram o Agile, de acordo com o VersionOne), o Scrum adota uma abordagem altamente iterativa que se concentra na definição dos principais recursos e objetivos antes de cada sprint. Ele é projetado para reduzir o risco e, ao mesmo tempo, fornecer valor rapidamente.

Ademais, o Scrum começa com um requisito ou uma história de usuário que descreve como os recursos devem ser executados e testados. Em seguida, a equipe percorre uma série de sprints para fornecer pequenas explosões de valor depressa. Para ajudar a equipe a trabalhar dessa maneira flexível e evitar a mudança de prioridades, o Scrum requer que as perguntas sejam respondidas desde o início.

Como isso é diferente da Waterfall?

Enquanto inclui vários ciclos de teste e correção de bugs antes de lançar um produto, o Scrum é muito mais colaborativo e iterativo. Uma das maiores diferenças é que a Waterfall exige documentação pesada desde o início, o que dificulta a troca de recursos à medida que o processo avança. Podendo ser negativo em alguns ambientes (como software para consumidor) e positivo em outros (como aqueles em que a equipe está tentando lançar um foguete, ninguém quer requisitos para algo perigoso mudando frequentemente).

Dito isso, você pode pensar em Scrum como muitas “mini cachoeiras”. Já que os requisitos são bem definidos no início de cada sprint e não devem mudar dentro dele. A diferença é que os requisitos detalhados para o próximo sprint não são definidos com meses antes.

Mergulhando mais fundo, o Scrum exige mais colaboração regular entre testadores, desenvolvedores e BAs. Afinal, na forma de testes diários e análises de sprint, para garantir a comunicação e o alinhamento adequados.

Além disso, existe um Scrum Master, que ajuda a manter o projeto na tarefa. removendo os bloqueadores da equipe para garantir que eles sejam mais eficazes. O Scrum Master pode ser qualquer pessoa da equipe, como um desenvolvedor ou um testador.

O que a adoção implica?

O Scrum oferece uma das transições mais fáceis para equipes provenientes de um ambiente do Waterfall. Pois é baseado em tempo com sprints e os lançamentos ainda podem ser planejados antes ainda. Dito isto, exige interações mais rápidas e colaboração mais forte.

Para quem é recomendado?

Por causa de suas iterações rápidas, o Scrum é mais adequado para equipes cujos clientes e partes interessadas desejam estar bem envolvidos. Além disso, estudando com frequência os produtos de trabalho em reuniões de demonstração.

Essa colaboração faz com que a equipe faça alterações para as próximas vitrines. Onde os principais membros da equipe que devem estar envolvidos ao adotar uma abordagem Scrum incluem:

Dono do produto;

Scrum Master;

Desenvolvedores;

Engenheiros de Automação;

Testadores;

Stakeholders.

Quais são as melhores práticas?

Além de uma forte comunicação, colaboração e adaptabilidade, outras práticas recomendadas para testadores seguindo uma metodologia Scrum incluem:

Determinar os critérios de aceitação com base na comunicação (normalmente na forma de uma história do usuário) de um representante de vendas ou cliente;

Nota: Essa conexão direta deve ajudar a reduzir as falhas de comunicação.

Usar os critérios de aceitação para desenvolver código e garantir a sua aprovação pela equipe.

Testar o código em ambientes parecidos à sandbox, bem como em ambientes semelhantes à produção. Antes de implantá-lo em produção.

Pode ser mais fácil entender o modelo cascata quando você o compara com outro processo de desenvolvimento de software chamado Agile. Waterfall e Agile são duas metodologias muito diferentes de gerenciamento de projetos, mas ambas são igualmente válidas dependendo do contexto do projeto.

A maior diferença entre o Agile e o Waterfall é que, normalmente, no Agile, o produto é produzido e aceito de forma incremental, em torno de iterações curtas ou equivalentes (geralmente de 2 a 4 semanas). Além disso, usando o Agile, os requisitos normalmente são totalmente definidos em torno de cada iteração, em vez de no início do projeto em uma única fase de requisitos. Antes disso, itens de nível superior, como recursos, geralmente serão identificados. Eles serão divididos em itens discretos para serem totalmente definidos e desenvolvidos nas iterações.

Um dos principais objetivos do Agile é tentar manter o máximo de flexibilidade possível ao longo do ciclo de desenvolvimento. Certos tipos de projetos nunca se adequam a uma verdadeira abordagem ágil. Por exemplo, se a principal entrega do projeto não puder ser definida, produzida (e aceita) sequencial e incrementalmente, é improvável que o núcleo do Agile possa ser usado. No entanto, qualquer projeto pode se beneficiar de algumas das práticas comumente encontradas no Agile, principalmente na comunicação.