Visão geral

Dentro Parte 1 do Blueprint de gerenciamento do projeto cobrimos as metodologias de desenvolvimento de software Lean Software, Agile, Scrum e Kanban e como todas elas traçam suas raízes até a Manufatura Enxuta. Essas metodologias geralmente são implantadas em um único nível de equipe. No entanto, a complexidade aumenta à 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, vamos primeiro mergulhar em como gerentes de projeto utilizar a metodologia em cascata, que é o framework mais comum para desenvolvimento de software em empresas tradicionais. Em contraposição a isso, cobriremos os frameworks mais populares que tentam incorporar princípios ágeis em escala - Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Scrum em larga escala (LeSS) e [email protegido]

Cascata

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 em cascata de uma fase para a próxima como uma cascata. As fases não se sobrepõem e têm 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 em cascata original são:

1. Requisitos: Nesta fase, as expectativas e objetivos do projeto são definidos 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: Depois que os requisitos são aprovados, o trabalho começa na arquitetura e no projeto do produto para atender aos requisitos aprovados. A arquitetura física, a arquitetura do componente, o design do banco de dados, o componente detalhado, o design do módulo e outros aspectos do design são documentados por um arquiteto ou designer de software. Em seguida, é revisado e aprovado antes de iniciar a implementação.
3. Implementação: Depois que o design é aprovado, a implementação ou codificação do software de acordo com os requisitos e design é feita por 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. Freqüentemente, uma rodada de testes acontece para garantir que a instalação foi bem-sucedida. Depois que o produto é entregue, a manutenção e o suporte contínuos ocorrem para garantir que o produto continue a funcionar 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 não têm probabilidade de mudar de maneira significativa.

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

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

Desvantagens da Cachoeira

A cascata não é adequada para projetos mais longos onde os requisitos não são bem compreendidos e / ou têm probabilidade de mudar e / ou onde há risco técnico significativo. Na era de hoje, onde as condições de mercado estão mudando 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 atrasado do cliente: É difícil para as partes interessadas e, especialmente, para os clientes, imaginar o escopo completo e detalhado de um projeto. Uma vez que a cascata expõe os clientes aos resultados do projeto principalmente nos últimos estágios do projeto, então, 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 alteração durante o projeto.
• Valor criado no final: A cascata exige muito trabalho inicial, o que significa que o valor não é produzido até o final do projeto.
• Interdependência de fase: A incorporação de mudanças freqüentemente resulta em requisitos e / ou retrabalho de design que podem impactar outras áreas do projeto. A dependência de estágios posteriores de estágios anteriores pode tornar pequenas mudanças no projeto desproporcionalmente desafiadoras.

Entrega ágil disciplinada (DAD)

Entrega ágil disciplinada (DAD) foi formalizado por Scott Ambler na IBM e na Mark Lines e expande os frameworks Agile e Scrum, reconhecendo que as 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 de entrega. O DAD visa aumentar a agilidade geral dos negócios de forma pragmática.

Princípios e componentes principais

Funções

O DAD tem muito mais funções do que o scrum e é dividido em duas categorias de funções de equipe. As funções principais são desempenhadas 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 apoio encontradas no mundo real

Funções principais:

1. Parte interessada: Alguém que dependa da finalização do projeto por sua equipe: 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. Liderança da equipe: Analogamente ao scrum master, o líder da equipe atua como um líder-servidor para a equipe removendo impedimentos, facilitando a coesão da equipe e disseminando valores ágeis.
4. Proprietário do produto: Às vezes chamada de '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 de arquitetura em escala. Essa função é normalmente 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 se associar para fornecer recursos de pesquisa nos estágios iniciais de um projeto.
2. Especialista em domínio: Consultores tributários, consultores jurídicos e outras pessoas com experiência de domínio e ajudam a equipe em desafios relacionados.
3. Técnico especializado: Administrador de banco de dados, mestre de construção especialista em segurança, etc. Essas pessoas ajudam os membros da equipe mais generalizados em pontos-chave do ciclo de vida.
4. Testador independente: Embora os testadores geralmente façam parte da equipe principal, em alguns casos, requisitos regulamentares de vida ou sistemas muito complexos, os testadores independentes trabalham em paralelo para validar o trabalho entregue.
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 completo de entrega, não apenas a parte de programação e liberação coberta pelo agile / scrum, mas também a fase de iniciação onde a visão do projeto é definida e aprovada e as fases de suporte e retirada após a liberação. 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 enxuto: um ciclo de vida de projeto baseado em Kanban
• A entrega contínua: ciclo de vida ágil
• A entrega contínua: ciclo de vida enxuto
• O Ciclo de Vida Exploratório (Lean Startup)
• O ciclo de vida do programa para uma equipe de equipes

Esses ciclos de vida são responsáveis ​​por 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 agem como sugestões. O DAD promove o pragmatismo sobre o purismo, uma vez que cada situação é única e os praticantes ágil disciplinados devem adotar o processo ágil de acordo com suas necessidades.

Objetivos do Processo

O DAD usa uma abordagem orientada a 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 superior sendo a melhor prática e o item inferior sendo a pior prática nesta lista. o _ negrito itálico_ texto significa bons pontos de partida para novas equipes, que estão apenas começando com o DAD.

Dimensionamento de DAD

A entrega ágil disciplinada aborda o dimensionamento de dois ângulos diferentes:

• Agilidade tática em escala

• Agilidade estratégica em escala

A agilidade tática tenta abordar os fatores individuais de dimensionamento da equipe, 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 de DevOps para fornecer resultados mais eficazes para uma organização.

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

• Empresa Agile Disciplinada: . aborda como aplicar o lean e o ágil em uma empresa.

Seguro

Estrutura Agile Escalada (SAFe) é o framework Agile escalado mais popular, bem como o mais complexo e abrangente no momento. 29% dos entrevistados no Relatório Anual do Estado do 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 “ Escalando a agilidade do software: melhores práticas para grandes empresas , ”Publicado em 2007. Leffingwell é agora o metodologista-chefe da SAFe, mas muitas outras pessoas também contribuem para essa estrutura. Atualmente, na versão 4.6, esta 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 menor período de tempo sustentável.

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

O SAFe 4.6 define as cinco competências essenciais 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 impulsionam 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 que são necessários para criar equipes Agile de alto desempenho.

3. DevOps e lançamento sob demanda : Descreve como a implementação de DevOps e um pipeline de entrega contínua fornecem à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 os princípios e práticas lean-agile para a especificação, desenvolvimento, implantação e evolução de aplicativos de software grandes e complexos

5. Gestão enxuta de portfólio : Alinha estratégia e execução aplicando abordagens enxutas e de pensamento sistêmico à estratégia e financiamento de investimentos, operações de portfólio ágil e governança.

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

Competência de liderança Lean-Agile

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

Valores Essenciais da SAFe guiar a transformação para a empresa enxuta. Em todas as oportunidades, o comportamento de um líder desempenha um papel crítico em sua promoção. Os valores centrais são:

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

2. Transparência : Visualize todos os trabalhos relevantes.

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

4. Execução do programa : Participar como proprietários de negócios na execução de PI e estabelecer o valor do negócio. Certifique-se de que o escopo esteja alinhado com a demanda e a capacidade. Remova agressivamente impedimentos e desmotivadores.

Os valores fundamentais da SAFe são apoiados pela adoção de Mentalidade Lean-Agile e aplicando Princípios SAFe :

1. Tenha uma visão econômica

2. Aplicar pensamento sistêmico

3. Assuma variabilidade; preservar opções

4. Construa de forma incremental com ciclos de aprendizagem rápidos e integrados

5. Baseie os 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. Aplicar cadência, sincronizar com planejamento de domínio cruzado

8. Desbloquear 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

o Competência de equipe e agilidade técnica descreve as habilidades, princípios e práticas necessárias 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 Agile, 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 Agile 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 scrum master, product owner 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 apoiadas por funções de nível de programa, como Gerenciamento de Produto, Arquiteto de Sistema e outros serviços compartilhados. Kanban é usado para ajudar a visualizar o fluxo de recursos através do ciclo de vida de entrega e interações e transferências entre equipes.

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

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

DevOps trabalha para alinhar o desenvolvimento, as operações, os negócios e outras áreas para trabalharem juntos para entregar resultados de negócios. Embora nem toda organização precise lançar com tanta frequência quanto alguns dos 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 a entrega contínua e a liberação sob demanda

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

o Nível do programa do diagrama descreve as funções e atividades necessárias para entregar continuamente por meio de um Agile Release Train (ART) . Este nível funciona de maneira iterativa semelhante ao nível da equipe, mas integra várias equipes ágeis e inclui mais ciclos. A 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 Engenheiro de trem de liberação (RTE) e Gestão de Produtos. O ART entrega em 8-12 semanas Incrementos do programa (PI) que são planejados via Planejamento PI e liderado por um Gerente de Produto .

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

Competência em Soluções de Negócios e Engenharia de Sistemas Enxutos / Grande Nível de Solução

o Competência Soluções de Negócios e Engenharia de Sistemas Enxutos 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 ciberfísicos”.

Além dos princípios SAFe, a aplicação dos 8 princípios a seguir ao trabalhar em soluções de grande porte é a chave para esta competência:

o Grande Nível de Solução 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 Trens de solução entregar Soluções . Os objetivos principais são:

• Gerenciar integração frequente

• Aborde continuamente as questões de conformidade

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

Gestão de Soluções controla o conteúdo de um Solução e o engenheiro de treinamento de soluções (STE) orienta o trabalho. Solução de arquitetura é responsável por manter uma boa arquitetura para todos os ARTs da Solução. Planejamento Pré e Pós PI é usado para planejar soluções entregues por meio de vários incrementos de programa. UMA Backlog da solução contém Capacidades e Solução épicas e é rastreado por meio de um Kanban de solução borda

Nível de portfólio / Competência de gerenciamento de portfólio enxuto

o 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 investimento, operações de portfólio ágil e governança.”

O Lean Portfolio Management foca nas seguintes áreas:

1. Estratégia e financiamento de 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 Agile: coordena os fluxos de valor, apóia a execução do programa e a excelência operacional

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

o Nível de portfólio contém os princípios, práticas e funções necessárias para iniciar e governar um conjunto de fluxos de valor de desenvolvimento. UMA Carteira em carteira contém Epopéias de negócios e Enabler Epics e é rastreado por meio de um Quadro Kanban * do portfólio. ** Gestão Enxuta de Portfólio (LPM) decide quais fluxos de valor estão em um portfólio e inclui os maiores tomadores de decisão em uma empresa. A Arquiteto empresarial orienta o trabalho e coordena os fluxos de valor.

Menos

Scrum em grande escala (LeSS) O framework foi criado por Craig Larman e Bas Vodde, que o basearam em sua experiência nos setores financeiro e de telecomunicações. Como o nome indica, o LeSS promove o mínimo de processos e procedimentos possíveis para que muitas equipes Scrum trabalhem juntas. O dimensionamento é difícil porque as pessoas o tornam complexo, portanto, o objetivo aqui é torná-lo o mais simples possível.

Princípios e componentes principais

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

1. Scrum em larga escala é Scrum

2. Controle de processo empírico

3. Transparência

4. Mais com menos

5. Foco no produto inteiro

6. Centrado no cliente

7. Melhoria contínua em direção à perfeição

8. Sistemas a pensar

9. Pensamento enxuto

10. Teoria das filas

LeSS tem apenas duas funções principais, ambas emprestadas do Scrum:

1. Proprietário do produto: Trabalha com 2 a 8 equipes.
2. Scrum Master: Trabalha com 1-3 equipes.

Todas as equipes trabalham com o mesmo carteira de produtos em sprints de 1-4 semanas. As equipes trabalham em paralelo, o que significa que começam e terminam os sprints ao mesmo tempo. No final do sprint, as equipes coletivamente entregam um incremento de produto . Pode parecer quase impossível para um product owner 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 devem ser capacitadas para chegar aos clientes.

Sprint Planning

O planejamento é dividido em duas partes:

1. Planejamento de Sprint 1: Onde os representantes das equipes se reúnem com o product owner e decidem sobre quais itens do backlog eles assumirão e discutam qualquer possível cooperação que possa ser necessária entre as equipes durante o sprint.
2. Planejamento de Sprint 2: Da mesma forma que no 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 definirem por si mesmas o processo mais eficaz. PBR envolve três atividades principais:

1. Dividindo itens grandes.
2. Detalhando itens até estar pronto.
3. Estimando.

Fim da Sprint

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

1. Revisão de 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 a seguir.
2. Retrospectivo: 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.

[email protegido]

Scrum em escala e [email protegido] são usados ​​indistintamente. Esta metodologia foi introduzida por Jeff Sutherland em 2014, que criou a metodologia Scrum e foi um dos signatários do Manifesto Ágil.

[email protegido] toma o Scrum como ponto de partida e oferece uma estrutura simples e leve para escalar o Scrum com uma “burocracia mínima viável”. É menos prescritivo do que as outras metodologias ágeis escaladas e pode ser considerado uma meta-estrutura. Ele destaca as questões e áreas de dimensionamento e oferece uma estrutura mental de como elas podem ser tratadas.

Princípios e componentes principais

[email protegido] é um framework que simplifica radicalmente o escalonamento usando Scrum para escalar o Scrum. No Scrum, o “o quê” (product owner) é claramente separado do “como” (scrum master). A mesma estratégia é usada em [email protegido] para que a jurisdição e a responsabilidade sejam bem compreendidas, eliminando desperdícios e conflitos.

[email protegido] contém dois ciclos para separar claramente as jurisdições: o Ciclo Scrum Master e a Ciclo do Dono do Produto com dois pontos de contato: Processo no nível da equipe e Feedback sobre a versão do produto.

Ciclo Scrum Master

o ciclo do scrum master é responsável por como as coisas que o ciclo do product owner identificado serão construídas. Dentro [email protegido] , equipes Scrum individuais têm as mesmas funções, artefatos, atividades e cerimônias que o Scrum tradicional.

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

Se for necessária uma escala adicional, há um scrum de scrum de scrums (SoSoS) criado a partir de vários SoS que também seriam atendidos diariamente e assim por diante. O líder geral é o Equipe de Ação Executiva (EAT) que é responsável por promover o Agile na organização, coordenando times Scrum conforme necessário, e por ser a última parada para a remoção de impedimentos.

Ciclo do Dono 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 Proprietários do Produto são atribuídos a equipes Scrum e realizam todas as atividades de sua função, conforme definido no Scrum. Os proprietários do produto são agrupados em Equipes de Product Owner que mapeiam para as equipes de SoS. As equipes do Dono do Produto se encontram diariamente em um Scrum meta 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. Meta Scrums são liderados por um Dono do produto chefe (CPO) .

Os Proprietários do Produto escalam de forma semelhante ao ciclo do Scrum Master, dependendo do tamanho da organização e culmina em um Meta Scrum Executivo (EMT) , que é responsável pela definição de prioridades em toda a empresa.

Implementando [email protegido]

Implementação de [email protegido] começa com a criação de um modelo de referência escaloná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 prejudiquem a agilidade. [email protegido] sugere resolvê-los cedo porque todas as equipes provavelmente enfrentarão esses problemas gerais da organização e as frustrações consequentes podem impedir a adoção do Agile. 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 poderes política e financeiramente 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 projeto, cobrimos algumas das estruturas mais populares usadas em projetos ou programas maiores. A cascata ainda é amplamente usada em muitas organizações e, embora tenha muitas desvantagens devido a seus processos inflexíveis, às vezes faz sentido usar essa estrutura 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 metas em constante mudança, elas procuram abordagens mais ágeis. Como o Agile foi originalmente concebido para pequenas equipes de 5 a 9 pessoas, vários praticantes do Agile vieram com várias maneiras de dimensionar o Agile, de equipes únicas a várias equipes e em toda a empresa. Neste artigo, cobrimos o Disciplined Agile Delivery (DAD), o Scaled Agile Framework (SAFe), o Scrum de grande escala (LeSS) e [email protegido]

Na parte final do plano de gerenciamento de projeto, cobriremos algumas estruturas específicas de gerenciamento de projeto, como PMP (PMBOK) e PRINCE2. Também abordaremos alguns processos e estruturas de inovação como 'tarefas a serem realizadas' (JTBD) e 'design thinking'.

Compreender o básico

Qual é a diferença entre as metodologias cascata e agile?

A metodologia em cascata envolve muito planejamento inicial e os resultados são entregues no final de um projeto. A metodologia ágil promove planejamento leve e múltiplas iterações para entregar resultados em pequenos incrementos.

O Waterfall e o Agile podem ser usados ​​juntos?

Sim. Dividir um projeto em cascata em partes, onde parte do trabalho seria feito iterativamente em sprints, seria um exemplo das duas metodologias usadas em conjunto. As metodologias híbridas também ajudam a combinar as duas abordagens para obter o máximo de benefícios.

O que é uma metodologia híbrida?

Uma metodologia híbrida significa que alguns componentes de cascata e ágil são usados ​​no mesmo projeto ou na mesma empresa. É uma abordagem comum para empresas em transição de cascata para agile.