O Project Management Blueprint Parte 2: Uma Comparação Abrangente de Waterfall, DAD, SAFe, LeSS e Scrum@Scale

Visão geral

Na Parte 1 do Project Management Blueprint, abordamos as metodologias de desenvolvimento de software Lean, Agile, Scrum e Kanban e como todas elas traçam suas raízes até o Lean Manufacturing. Essas metodologias geralmente são implantadas em um único nível de equipe. No entanto, a complexidade cresce à medida que os projetos e as equipes de projeto se tornam maiores e novas abordagens são necessárias para ser ágil em escala.

Na Parte 2, veremos primeiro como os gerentes de projeto usam a metodologia em cascata, que é a estrutura mais comum para desenvolvimento de software em empresas tradicionais. Justaposto a isso, abordaremos os frameworks mais populares que tentam incorporar princípios ágeis em escala – Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) e Scrum@Scale.

Cachoeira

A metodologia em cascata (também conhecida como modelo de ciclo de vida de desenvolvimento de software (SDLC)) é uma metodologia mais tradicional em que o desenvolvimento de software passa de uma fase para a outra como uma cascata. As fases não se sobrepõem e possuem critérios específicos de entrada e saída para passar de uma fase para a próxima.

Os seis estágios do ciclo de vida do modelo cascata original são:

1. Requisitos: Nesta fase, as expectativas e metas do projeto são definidas e os requisitos são analisados ​​e documentados extensivamente, geralmente por um analista de negócios. Os requisitos são revisados ​​e aprovados antes de sair desta fase.
2. Projeto: Após a aprovação dos requisitos, inicia-se o trabalho de arquitetar e projetar o produto para atender aos requisitos aprovados. A arquitetura física, arquitetura de componentes, projeto de banco de dados, componente detalhado, projeto de módulo e outros aspectos do projeto são documentados por um arquiteto ou designer de software. Em seguida, é revisado e aprovado antes de iniciar a implementação.
3. Implementação: Após a aprovação do projeto, a implementação ou codificação do software de acordo com os requisitos e o projeto é feita pelos desenvolvedores de software.
4. Verificação: Após a conclusão da implementação, o software é testado pela equipe de teste ou QA para garantir que os requisitos e o design sejam atendidos e que o nível de qualidade desejado seja alcançado. Os defeitos são encontrados, registrados, triados e, em muitos casos, corrigidos.
5. Liberação e manutenção: Após a conclusão do teste e da depuração, o produto é liberado para o cliente e instalado. Muitas vezes, uma rodada de testes acontece para garantir que a instalação foi bem-sucedida. Após a entrega do produto, a manutenção e o suporte contínuos ocorrem para garantir que o produto continue funcionando conforme projetado.

Vantagens da Cachoeira

Existem algumas vantagens em cascata e é adequado para certos tipos de projetos, mas também existem algumas desvantagens sérias. O Waterfall é mais adequado para projetos mais curtos, onde os requisitos e a tecnologia são bem compreendidos e provavelmente não serão alterados de maneira significativa.

Se aplicado ao tipo certo de projeto, algumas das vantagens do modelo em cascata:

• Simplicidade: Waterfall é simples de implementar devido à identificação antecipada do escopo e devido às fases rígidas e uma transição clara de uma fase para outra.
• Visibilidade: O progresso é mais facilmente medido e visto pelas partes interessadas, pois o escopo completo do trabalho é conhecido com antecedência e à medida que o projeto passa de um estágio para o próximo.
• Documentação: Escopo, requisitos e planos podem ser cuidadosamente pensados ​​e bem documentados, o que torna mais fácil para equipes menos experientes trabalharem no projeto.
• Trabalho em fases: devido às funções rígidas e à transição entre as fases, é possível que os recursos do projeto trabalhem em outros projetos quando sua fase principal não estiver em andamento.

Desvantagens da Cachoeira

Waterfall não é adequado para projetos mais longos onde os requisitos não são bem compreendidos e/ou passíveis de mudança e/ou onde há risco técnico significativo. Na era atual, em que as condições do mercado mudam constantemente e o tempo de lançamento no mercado é crítico, isso se aplica à maioria dos projetos de software.

As desvantagens do modelo em cascata, que se concentram principalmente em sua incapacidade de se adaptar às mudanças, incluem:

• Escopo monolítico: Recompensa as partes interessadas a pensar em TUDO ao definir o escopo do projeto, levando a um escopo monolítico.
• Feedback tardio do cliente: é difícil para as partes interessadas e especialmente os clientes imaginarem o escopo detalhado completo de um projeto. Como a cascata expõe os clientes aos resultados do projeto principalmente nos últimos estágios do projeto, inevitavelmente torna-se difícil incorporar o feedback do cliente ao projeto
• Mudança de requisitos: Em projetos mais longos, as condições de mercado e, portanto, os objetivos e requisitos do projeto, correm um risco muito alto de mudar durante o projeto.
• Valor criado no final: Waterfall exige muito trabalho inicial, o que significa que o valor não é produzido até o final do projeto.
• Interdependência de fases: A incorporação de mudanças geralmente resulta em requisitos e/ou retrabalho de design que podem afetar outras áreas do projeto. A dependência de estágios posteriores em estágios anteriores pode fazer pequenas mudanças no projeto desproporcionalmente desafiadoras.

Entrega Ágil Disciplinada (DAD)

A entrega ágil disciplinada (DAD) foi formalizada por Scott Ambler na IBM e Mark Lines e expande as estruturas ágil e scrum, reconhecendo que partes não ágeis de uma organização geralmente estão envolvidas em alguma capacidade na entrega de um projeto de software. Essa estrutura inclui explicitamente atividades de operações de TI, arquitetura corporativa, gerenciamento de portfólio, finanças e compras em todo o ciclo de vida da entrega. O DAD visa aumentar a agilidade geral dos negócios de maneira pragmática.

Princípios e Componentes Principais

Funções

O DAD tem consideravelmente mais funções do que o scrum e é dividido em duas categorias de funções de equipe. Os papéis principais são preenchidos por pessoas que trabalham com o projeto em uma base constante. As funções secundárias geralmente são introduzidas temporariamente para ajudar a equipe com dimensionamento ou outros problemas. O DAD tem essas funções adicionais porque aborda todo o ciclo de vida de entrega da solução e porque reconhece os vários tipos de funções temporárias e de suporte necessárias encontradas no mundo real

Funções principais:

1. Stakeholder: Alguém que depende de sua equipe terminar o projeto: cliente, usuário final ou colega interno.
2. Membro da equipe: Pessoas dentro da equipe que realmente fazem o trabalho planejado: desenvolvedores, designers, testadores, etc.
3. Líder de equipe: Análogo ao scrum master, o líder de equipe atua como um líder servidor da equipe removendo impedimentos, facilitando a coesão da equipe e disseminando valores ágeis.
4. Dono do produto: às vezes referido como a “voz do cliente”. O proprietário do produto representa as partes interessadas e mantém a lista priorizada de trabalho que precisa ser feito.
5. Proprietário da arquitetura: Responsável por mitigar o risco da arquitetura em escala. Essa função geralmente é preenchida por um desenvolvedor sênior dentro da equipe, pois requer uma formação técnica profunda e um conhecimento sólido do domínio de negócios.

Funções secundárias:

1. Especialista: Pessoas que se juntam temporariamente à equipe para ajudar em uma função especializada. Por exemplo, um analista de dados pode ingressar para fornecer recursos de pesquisa nos estágios iniciais de um projeto.
2. Especialista de domínio: consultores fiscais, consultores jurídicos e outras pessoas que têm experiência no domínio e ajudam a equipe em desafios relacionados.
3. Especialista técnico: Administrador de banco de dados, mestre de construção especialista em segurança, etc. Essas pessoas ajudam os membros mais generalizados da equipe em pontos-chave do ciclo de vida.
4. Testador independente: Embora os testadores geralmente façam parte da equipe principal, em alguns casos, requisitos regulatórios de vida ou sistemas muito complexos, testadores independentes trabalham em paralelo para validar o trabalho de entrega.
5. Integrador: Em escala, diferentes equipes estão trabalhando em diferentes partes de todo o sistema. Um integrador ajuda a equipe a integrar sua parte com todo o sistema e gerencia as dependências.

Suporte ao ciclo de vida

O DAD promove um ciclo de vida de entrega completo, não apenas a parte de programação e liberação coberta pelo Agile/scrum, mas também a fase de início onde a visão do projeto é definida e aprovada e as fases de suporte e aposentadoria após o lançamento. Atualmente, o DAD suporta 6 ciclos de vida diferentes:

• O ciclo de vida ágil: um ciclo de vida de projeto baseado em Scrum
• O ciclo de vida Lean: um ciclo de vida de projeto baseado em Kanban
• A entrega contínua: ciclo de vida ágil
• A Entrega Contínua: Ciclo de Vida Lean
• O Ciclo de Vida Exploratório (Lean Startup)
• O ciclo de vida do programa para uma equipe de equipes

Esses ciclos de vida levam em conta diferentes estilos de trabalho, níveis de agilidade da empresa e outras situações em que as equipes podem se encontrar. O ponto principal é que esses ciclos de vida funcionam como sugestões. O DAD promove o pragmatismo sobre o purismo, pois cada situação é única e os praticantes ágeis disciplinados devem adotar o processo ágil de acordo com suas necessidades.

Metas do Processo

O DAD usa uma abordagem orientada por objetivos para criar e adaptar processos ágeis. Os autores desta metodologia descrevem 21 processos mais importantes e comuns que a maioria das equipes enfrentará durante seus ciclos de vida.

Todos esses processos têm pontos de decisão documentados que exigirão que a equipe decida como estruturará esse processo. Cada ponto de decisão fornece técnicas ou práticas sugeridas que podem ser usadas para implementar a decisão. Você pode ver um exemplo disso na imagem abaixo. Um processo “Desenvolver Visão Comum” tem 6 decisões que devem ser tomadas. Cada uma dessas decisões tem de 2 a 5 práticas sugeridas. As setas indicam que os autores do DAD ordenaram a lista com o item de cima sendo a melhor prática e o item de baixo sendo a pior prática nesta lista. O texto _ itálico em negrito_ significa bons pontos de partida para novas equipes, que estão apenas começando com o DAD.

Dimensionamento do DAD

A Discipline Agile Delivery aborda o dimensionamento de dois ângulos diferentes:

• Agilidade tática em escala

• Agilidade estratégica em escala

A agilidade tática tenta abordar fatores de dimensionamento de equipes individuais, como tamanho, distribuição geográfica, complexidade do projeto, etc., por meio da aplicação situacional dos objetivos do processo e suas práticas sugeridas.

A agilidade estratégica tenta abordar o dimensionamento através da aplicação de estratégias ágeis e enxutas amplamente em toda a organização, expandindo a estrutura para abordar diferentes áreas da organização:

• DevOps disciplinado: abrange o uso do DevOps para fornecer resultados mais eficazes para uma organização.

• Disciplined Agile IT (DAIT): aborda como aplicar estratégias ágeis e enxutas a todos os aspectos de TI.

• Empresa Ágil Disciplinada:. aborda como aplicar lean e ágil em toda a empresa.

Seguro

O Scaled Agile Framework (SAFe) é o framework Agile dimensionado mais popular, bem como o mais complexo e abrangente do momento. 29% dos entrevistados no Relatório Anual State of Agile afirmam que usam essa estrutura em suas organizações. Por sua vez, existem muitos gerentes de projeto SAFe no mercado.

O início do SAFe foi o livro de Dean Leffingwell “Scaling Software Agility: Best Practices for Large Enterprises”, publicado em 2007. Leffingwell é agora o principal metodologista do SAFe, mas muitas outras pessoas também contribuem para essa estrutura. Atualmente, na versão 4.6, essa estrutura se assemelha a um produto de software com controle de versão, compatibilidade com versões anteriores e vários componentes.

Princípios e Componentes Principais

O objetivo principal do SAFe é facilitar a criação e o crescimento de uma empresa enxuta, pois reconhece que muitos tipos diferentes de empresas são, em parte, empresas de software que precisam entregar valor continuamente no período de tempo mais curto e sustentável.

O SAFe for Lean Enterprises tenta criar uma Lean Enterprise fornecendo uma base de conhecimento de princípios comprovados, competências e melhores práticas.

O SAFe 4.6 define as Cinco Competências Centrais da Empresa Enxuta. Cada competência é um conjunto de conhecimentos, habilidades e comportamentos relacionados, que juntos permitem que as organizações se destaquem:

1. Liderança Lean-Agile : Descreve como os líderes conduzem e sustentam a mudança organizacional por meio do aprendizado, ensino e implementação da mentalidade Lean-Agile da SAFe.

2. Equipe e agilidade técnica : descreve as habilidades, princípios e práticas necessários para criar equipes ágeis de alto desempenho.

3. DevOps e lançamento sob demanda : descreve como a implementação de DevOps e um pipeline de entrega contínua fornece às organizações a capacidade de liberar incrementos de produtos a qualquer momento necessário para atender à demanda.

4. Soluções de negócios e engenharia de sistemas enxutos : Descreve como aplicar princípios e práticas lean-ágeis à especificação, desenvolvimento, implantação e evolução de aplicativos de software grandes e complexos

5. Gerenciamento de portfólio enxuto : Alinha estratégia e execução aplicando abordagens de pensamento enxuto e sistêmico para financiamento de estratégia e investimento, operações ágeis de portfólio e governança.

Cada uma das competências essenciais mapeia diretamente para seu respectivo nível no diagrama de processo SAFe, exceto Liderança Lean-Agile, que abrange todo o processo.

Competência de Liderança Lean-Agile

O objetivo principal da Competência de Liderança Lean-Agile é ajudar a transformar a organização em uma empresa lean-ágil. Isso é feito aprendendo, praticando e ensinando a mentalidade, valores, princípios e práticas Lean-Agile da SAFe.

Os valores centrais do SAFe orientam a transformação para a empresa enxuta. Em todas as oportunidades, o comportamento de um líder desempenha um papel crítico em promovê-los. Os valores fundamentais são:

1. Alinhamento : comunicar a missão, a estratégia do portfólio e a visão da solução. Conduzir briefings relevantes e participar do planejamento do incremento do programa (PI) e da manutenção da lista de pendências.

2. Transparência : Visualize todo o trabalho relevante.

3. Qualidade incorporada : Envolva-se em práticas para fornecer qualidade ao longo do ciclo de vida. Recuse-se a aceitar trabalho de baixa qualidade. Apoiar os investimentos em manutenção e redução da dívida técnica.

4. Execução do programa : Participe como donos de negócios na execução do PI e estabeleça o valor do negócio. Certifique-se de que o escopo esteja alinhado com a demanda e a capacidade. Remova agressivamente os impedimentos e desmotivadores.

Os valores centrais do SAFe são apoiados pela adoção do Lean-Agile Mindset e pela aplicação dos Princípios SAFe:

1. Tenha uma visão econômica

2. Aplique o pensamento sistêmico

3. Suponha variabilidade; preservar opções

4. Crie de forma incremental com ciclos de aprendizado rápidos e integrados

5. Basear marcos em uma avaliação objetiva dos sistemas de trabalho

6. Visualize e limite o WIP, reduza os tamanhos dos lotes e gerencie os comprimentos das filas

7. Aplique cadência, sincronize com planejamento entre domínios

   

8. Desbloqueie a motivação intrínseca dos trabalhadores do conhecimento

9. Descentralize a tomada de decisão

Esses princípios são semelhantes aos princípios Lean e Agile. Finalmente, a transformação da organização é realizada seguindo o roteiro de implementação do SAFe.

Competência de Equipe e Agilidade Técnica/Nível de Equipe

A competência Team and Technical Agility descreve as habilidades, princípios e práticas necessários para criar equipes ágeis de alto desempenho que criam soluções de alta qualidade. Duas características principais são críticas:

• Agilidade da equipe : as equipes adotam práticas e princípios ágeis, que lhes permitem trabalhar, aprender e se adaptar em uma cadência confiável

• Agilidade técnica : as equipes aplicam práticas técnicas ágeis que garantem a qualidade do código e dos componentes, e a manutenibilidade do código que produzem\ A qualidade é um grande foco na competência da equipe e agilidade técnica. Para conseguir isso, técnicas de engenharia ágil como Behavior Driven Development (BDD) e Test-driven development (TDD) são aplicadas para aumentar a qualidade e o fluxo. O fluxo rápido depende da qualidade da construção em todo o sistema, pois os erros podem afetar gravemente o fluxo e atrasar as liberações.

O nível de equipe do diagrama SAFe descreve como as equipes ágeis individuais operam. Todas as equipes fazem parte do Agile Release Train que trabalha para entregar um Incremento de Produto. A maior parte do fluxo ágil/scrum tradicional se aplica, onde as equipes trabalham em iterações para entregar sistemas de trabalho. As funções de mestre scrum, proprietário do produto e membro da equipe são usadas no SAFe, assim como a maioria das atividades e artefatos do scrum. As equipes também são suportadas por funções de nível de programa, como Gerenciamento de Produto, Arquiteto de Sistemas e outros serviços compartilhados. O Kanban é usado para ajudar a visualizar o fluxo de recursos durante o ciclo de vida da entrega e as interações e transferências entre as equipes.

DevOps e Release on Demand Competência/Nível do Programa

A Competência DevOps e Release on Demand descreve como “a implementação de DevOps e um pipeline de entrega contínua fornece à empresa a capacidade de liberar valor, no todo ou em parte, a qualquer momento necessário para atender à demanda do mercado e do cliente”.

O DevOps trabalha para alinhar o desenvolvimento, as operações, os negócios e outras áreas para trabalhar em conjunto para entregar resultados de negócios. Embora nem toda organização precise lançar com a mesma frequência que alguns líderes do setor do movimento DevOps (a Amazon lança a cada poucos segundos), todas as organizações precisam ser capazes de lançar sob demanda.

• O DevOps fornece a abordagem de cultura, automação, fluxo enxuto, medição e recuperação (CALMR) que permite entrega e liberação contínuas sob demanda

• Os trens de liberação ágeis (ARTs) são equipes de equipes ágeis organizadas para fornecer valor sob demanda por meio de um pipeline de entrega contínua

O nível de programa do diagrama descreve as funções e atividades necessárias para entregar continuamente por meio de um Agile Release Train (ART) . Esse nível funciona de maneira iterativa semelhante ao nível de equipe, mas integra várias equipes ágeis e inclui mais ciclos. O ART é uma equipe ágil de equipes composta de 5 a 12 equipes (50 a 125 pessoas), incluindo as funções ágeis tradicionais, bem como funções críticas do programa, como Release Train Engineer (RTE) e Product Management. O ART entrega em incrementos de programa (PI) de 8 a 12 semanas, que são planejados por meio do planejamento de PI e liderados por um gerente de produto .

O progresso dos recursos do PI, épicos, etc. é rastreado e gerenciado por meio de um quadro Kanban do Programa. O RTE atua como o Scrum Master no ART. As reuniões diárias de sincronização incluem reuniões diárias da equipe, Scrum-of-Scrums (RTE e Scrum Masters), PO Sync (Gerenciamento de produtos e proprietários de produtos) e ART Sync (Scrum-of-Scrums e PO Sync juntos). Cada PI tem uma Demonstração do Sistema e uma Retrospectiva.

Competência em soluções de negócios e engenharia de sistemas lean/nível de solução grande

A Competência Business Solutions and Lean Systems Engineering descreve “como aplicar os princípios e práticas Lean-Agile à especificação, desenvolvimento, implantação e evolução de aplicativos de software grandes e complexos e sistemas ciber-físicos”.

Além dos princípios SAFe, aplicar os 8 princípios a seguir ao trabalhar em grandes soluções é fundamental para esta competência:

O Nível de Solução Grande contém as funções, artefatos e processos necessários para construir soluções grandes e complexas. Vários ARTs estão trabalhando juntos em Solution Trains para entregar soluções . Os objetivos primários são:

• Gerencie a integração frequente

• Aborde continuamente as preocupações de conformidade

• Arquiteto para escala, modularidade, capacidade de liberação e facilidade de manutenção

O Solution Management controla o conteúdo de uma solução e o Solution Train Engineer (STE) orienta o trabalho. O Solution Architect é responsável por manter uma boa arquitetura para todos os ARTs na Solução. O planejamento pré e posterior do PI é usado para planejar soluções entregues por meio de vários incrementos de programa. Um Backlog de solução contém recursos e épicos de solução e é rastreado por meio de um quadro Solution Kanban

Nível de Portfólio/Competência de Gerenciamento de Portfólio Lean

A Competência Lean Portfolio Management “alinha estratégia e execução aplicando abordagens Lean e de pensamento sistêmico para estratégia e financiamento de investimentos, operações de portfólio ágil e governança”.

O Lean Portfolio Management concentra-se nas seguintes áreas:

1. Financiamento de estratégia e investimento: conecta o portfólio à estratégia da empresa, financia fluxos de valor e estabelece o fluxo do portfólio

2. Operações de portfólio ágil: coordena os fluxos de valor, apoia a execução do programa e a excelência operacional

3. Governança enxuta: prevê orçamentos, mede o desempenho do portfólio e reforça a conformidade

O Nível do Portfólio contém os princípios, práticas e funções necessárias para iniciar e controlar um conjunto de Fluxos de Valor de desenvolvimento. Um Portfolio Backlog contém Business Epics e Enabler Epics e é rastreado por meio de um quadro Portfolio Kanban*. **Lean Portfolio Management (LPM) decide quais fluxos de valor estão em um portfólio e inclui os mais altos tomadores de decisão em uma empresa. Um Enterprise Architect orienta o trabalho e coordena os fluxos de valor.

Menos

A estrutura de scrum de grande escala (LeSS) foi criada por Craig Larman e Bas Vodde, que a basearam em sua experiência nos setores financeiro e de telecomunicações. Como o nome indica, o LeSS promove ter o menor número possível de processos e procedimentos para que muitas equipes Scrum trabalhem juntas. O dimensionamento é difícil porque as pessoas o tornam complexo, então o objetivo aqui é torná-lo o mais simples possível.

Princípios e Componentes Principais

“LeSS é Scrum, aplicado a muitas equipes, trabalhando juntas, em um produto”. O LeSS é baseado em dez princípios que parecerão familiares para qualquer pessoa que esteja familiarizada com os princípios Lean-Agile:

1. Scrum em grande escala é Scrum

2. Controle de processo empírico

3. Transparência

4. Mais com menos

5. Foco em todo o produto

6. Centrado no cliente

7. Melhoria contínua rumo à perfeição

8. Sistemas a pensar

9. Pensamento enxuto

10. Teoria das filas

O LeSS tem apenas dois papéis principais, ambos emprestados do Scrum:

1. Product owner: Trabalha com 2 a 8 equipes.
2. Scrum master: Trabalha com 1-3 equipes.

Todas as equipes trabalham com o mesmo backlog do produto em sprints de 1 a 4 semanas. As equipes trabalham em paralelo, o que significa que iniciam e terminam os sprints ao mesmo tempo. No final do sprint, as equipes entregam coletivamente um incremento de produto . Pode parecer quase impossível para um proprietário de produto trabalhar com 8 equipes. O LeSS promove a transferência da responsabilidade do esclarecimento do item do backlog do produto para as equipes. Por sua vez, as equipes devem ser multifuncionais e conter não apenas competências de codificação, design e teste, mas também conhecimento do domínio de negócios. Mais importante, as equipes precisam ser capacitadas para alcançar os clientes.

Planejamento de Sprint

O planejamento é dividido em duas partes:

1. Planejamento do Sprint 1: onde os representantes das equipes se reúnem com o proprietário do produto e decidem quais itens do backlog eles assumirão e discutem qualquer cooperação potencial que possa ser necessária entre as equipes durante o sprint.
2. Planejamento do Sprint 2: Igual ao scrum tradicional, cada equipe se reúne separadamente para criar um plano de como os itens do backlog serão feitos.

Refinamento do Backlog do Produto

O refinamento do backlog do produto (PBR) é feito durante o sprint para preparar os itens do backlog do produto para o planejamento do sprint. O LeSS não oferece regras sobre como fazer o PBR e deixa para as empresas descobrirem seu processo mais eficaz. O PBR envolve três atividades principais:

1. Dividindo itens grandes.
2. Detalhando itens até ficar pronto.
3. Estimativa.

Fim do Sprint

No final de cada sprint, três coisas acontecem:

1. Revisão do Sprint: Uma demonstração compartilhada do Sprint, onde equipes e clientes exploram o que foi feito durante o Sprint e o que deve ser feito em seguida.
2. Retrospectiva: Cada equipe realiza sua própria retrospectiva para melhorar seu processo.
3. Retrospectiva geral: equipes, proprietários de produtos e scrum masters se reúnem para inspecionar e adaptar as práticas organizacionais para serem mais eficazes.

Scrum@Scale

Scrum at Scale e Scrum@Scale são usados ​​alternadamente. Essa metodologia foi introduzida por Jeff Sutherland em 2014, que criou a metodologia Scrum e foi um dos signatários do Agile Manifesto.

Scrum@Scale toma o Scrum como ponto de partida e oferece uma estrutura simples e leve para dimensionar o Scrum com uma “burocracia mínima viável”. É menos prescritivo do que as outras metodologias ágeis dimensionadas e pode ser considerado como um meta-framework. Ele destaca os problemas e áreas de dimensionamento e oferece uma estrutura mental de como eles podem ser abordados.

Princípios e Componentes Principais

Scrum@Scale é uma estrutura que simplifica radicalmente o dimensionamento usando Scrum para dimensionar o Scrum. No Scrum, o “o quê” (proprietário do produto) é claramente separado do “como” (scrum master). A mesma estratégia é usada no Scrum@Scale para que a jurisdição e a responsabilidade sejam bem compreendidas, eliminando desperdícios e conflitos.

Scrum@Scale contém dois ciclos para separar claramente as jurisdições: o ciclo do Scrum Master e o ciclo do Product Owner com dois pontos de contato: Processo de Nível de Equipe e Feedback de Lançamento do Produto.

Ciclo do Scrum Master

O ciclo scrum master é responsável por como as coisas que o ciclo do proprietário do produto identificou serão construídas. No Scrum@Scale, as equipes individuais do Scrum têm os mesmos papéis, artefatos, atividades e cerimônias do Scrum tradicional.

As equipes Scrum são agrupadas em um Scrum of Scrums (SoS) que é responsável em conjunto pela produção de um incremento conjunto do produto. Eles participam da preparação e priorização conjunta de pendências, realizam retrospectivas, mantêm pendências de impedimentos e realizam um Scaled Daily Scrum (SDS) (semelhante ao formato do Daily Scrum) para coordenar as equipes e remover obstáculos. A SDS é assistida por pelo menos um representante (geralmente o scrum master da equipe) de cada uma das equipes participantes e é liderada pelo Scrum of Scrums master (SoSM) que é responsável pela coordenação com as equipes scrum e os product owners.

Se for necessário dimensionamento adicional, há um scrum of scrum of scrums (SoSoS) criado a partir de vários SoS que também se reúnem diariamente e assim por diante. O líder geral é o Executive Action Team (EAT) , que é responsável por promover o Agile na organização, coordenar as equipes Scrum conforme necessário e por ser a parada final para remover impedimentos.

Ciclo do proprietário do produto

O Ciclo do Dono do Produto é responsável por qual produto ou serviço será criado e todas as atividades necessárias para dar suporte a isso. Os Product Owners são atribuídos às equipes Scrum e realizam todas as atividades de seu papel conforme definido no Scrum. Os proprietários de produtos são agrupados em equipes de proprietários de produtos que são mapeadas para as equipes de SoS. As equipes de Product Owners se reúnem diariamente em um Meta Scrum para discutir uma estratégia de alto nível para as equipes e coordenar conforme necessário com o SoSM correspondente e outros proprietários de produtos e partes interessadas. Os Meta Scrums são liderados por um Chief Product Owner (CPO) .

Os Product Owners escalam de forma semelhante ao ciclo scrum master, dependendo do tamanho da organização e culmina em um Executive Meta Scrum (EMT) , que é responsável pela definição de prioridades em toda a empresa.

Implementando Scrum@Scale

A implementação do Scrum@Scale começa com a criação de um modelo de referência escalável, ou seja, um pequeno conjunto de equipes usando scrum em pequena escala. Isso é feito para resolver quaisquer políticas organizacionais e práticas de desenvolvimento que impeçam o ágil. Scrum@Scale sugere resolvê-los cedo porque todas as equipes provavelmente enfrentarão esses problemas em toda a organização e as conseqüentes frustrações podem dificultar a adoção do ágil. O modelo de referência é então usado como um padrão para escalar o scrum para outras equipes e departamentos.

A equipe de ação executiva (EAT) deve ser criada inicialmente para implementar o modelo de referência. A EAT é composta por indivíduos com poder político e financeiro dentro da organização, pois serão capazes de implementar as mudanças na política organizacional.

Conclusão

Nesta segunda parte do plano de gerenciamento de projetos, abordamos algumas das estruturas mais populares usadas em projetos ou programas maiores. O Waterfall ainda é amplamente utilizado em muitas organizações e, embora tenha muitas desvantagens devido aos seus processos inflexíveis, às vezes faz sentido usar esse framework quando os projetos são pequenos e o escopo é bem definido e improvável de mudar.

À medida que as empresas encontram projetos maiores e mais complexos com requisitos ou objetivos em constante mudança, elas procuram abordagens mais ágeis. Como o Agile foi originalmente destinado a pequenas equipes de 5 a 9 pessoas, vários praticantes do Agile vieram com várias maneiras de dimensionar o Agile de equipes únicas, várias equipes, para toda a empresa. Neste artigo, abordamos Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) e Scrum@Scale.

Na parte final do projeto de gerenciamento de projetos, abordaremos algumas estruturas específicas de gerenciamento de projetos, como PMP (PMBOK) e PRINCE2. Também abordaremos alguns processos e estruturas de inovação, como “jobs to be done” (JTBD) e “design thinking”.