Uma visão panorâmica da floresta de estruturas ágeis
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Alguns anos atrás, você poderia dizer “Scrum é ágil” e pergunta “Scrum ágil?Agora sabemos que há mais carne nos ossos. Neste momento, existem mais de cinquenta estruturas ágeis conhecidas e menos conhecidas disponíveis.

Para obter uma primeira impressão dos diferentes frameworks, tento trazer alguma estrutura na selva para métodos e frameworks. Na Figura 1, posiciono as estruturas ágeis mais conhecidas em uma estrutura. As estruturas estão posicionadas nas seções “Programas / projetos únicos” ou em “Negócios como de costume” / por tempo indeterminado, ou ambos.

estrutura ágil

Fig. 1 Visão geral da estrutura ágil[1]

Por outro lado, as estruturas estão agrupadas em torno de equipe, produto ou programa e nível de portfólio. Nas caixas azuis escuras da Figura 1, vemos estruturas ágeis aplicáveis ​​apenas em organizações focadas em TI.

Todas as outras estruturas podem ser usadas em organizações de TI e não orientadas a TI (azul claro).

Não mapeei todas as estruturas conhecidas nesta figura e, para ser honesto, acho que há muita duplicação e provavelmente os drivers comerciais também desempenham um papel importante em ‘desenvolver’ o próximo garoto do quarteirão sem valor agregado em comparação com os quadros existentes.

O nível da equipe, incluindo Scrum e Kanban, é aplicável no desenvolvimento e operações de produtos e serviços orientados a TI e não orientados a TI. O nível de engenharia se concentra especificamente no desenvolvimento de produtos orientados a TI.

Os projetos e estruturas de programa temporários e únicos são adequados para TI e não TI. As estruturas guarda-chuva permanentes (voltadas para produtos e equipes) se concentram especificamente no desenvolvimento de produtos e TI, e as estruturas voltadas para negócios ajudam as organizações a aumentar sua agilidade.

Equipe nível

Se começarmos no nível da equipe na Figura 1, veremos, é claro Scrum conforme descrito por Ken Schwaber e Jeff Sutherland em seu Scrum Guide. Além disso, você verá estruturas como Kanban (conforme descrito no Guia Kanban para equipes Scrum), Scrumban e DevOps ou BusDevOps.

O nível da equipe pode ser usado tanto no ambiente de TI quanto no ambiente que não é de TI. Se você deseja oferecer qualidade como uma equipe no mundo de TI, apenas seguir essas estruturas não é suficiente.

Para melhorar a qualidade e minimizar a dívida técnica (por exemplo, código ineficiente devido a muitos ajustes iterativos), você pode usar a eXtreme Programming (XP) com Programação em Par, Desenvolvimento Orientado a Testes (TDD), Desenvolvimento Orientado a Comportamentos (BDD), Desenvolvimento Orientado a Recursos (BDD), Desenvolvimento Orientado a Recursos (FDD), design de experiência do usuário (UX), integração contínua e implantação contínua. O AgileBA fornece as técnicas para realizar análises de negócios.

Scrum ou Kanban?

Quando as equipes começam a trabalhar com o Agile, o Scrum geralmente é escolhido. Uma escolha óbvia, mas a questão é se essa é sempre a escolha certa. Em um Roman Pichler[2] blog o link foi feito com a fase de vida de um produto.

Durante a primeira fase de um ciclo de vida do produto comercial, em que o produto comercial é finalmente colocado no mercado pela primeira vez, a incerteza é alta e o foco está na entrega pontual do primeiro produto pronto para o mercado.

Um prazo foi definido e essa data deve ser cumprida. Durante essa fase, o foco de toda a equipe está no fornecimento de um produto comercialmente comercializável.

Esse desenvolvimento é perfeito para o Scrum com sua abordagem iterativa, capaz de lidar com a incerteza e trabalhar em conjunto no resultado (o produto comercial). Opcionalmente, um segundo lançamento pode ocorrer com um próximo conjunto de funcionalidades importantes, para que, eventualmente, um produto maduro seja colocado no mercado.

Durante o curso adicional do ciclo de vida do produto, vemos a quantidade de incerteza e as alterações solicitadas diminuírem. Neste momento, você pode fazer bom uso do Kanban. Em um fluxo contínuo, as Histórias de Usuário podem ser coletadas, desenvolvidas e implantadas uma a uma pelos membros da equipe.

READ  Mais de 70 lugares para promover seu conteúdo para marketing digital - Yodiz Project Management Blog

Se observarmos a transferência frequentemente difícil para os ambientes de produção, o tempo de colocação no mercado pode ser reduzido organizando-a adequadamente e reduzindo o número de erros de transferência quando as equipes de desenvolvimento e produção são mescladas e os testes e implantação de integração são automatizados ( CI / CD de Integração Contínua e Implantação Contínua).

Desta forma, um DevOps equipe é criada.

Scrumban é a combinação de Scrum e Kanban. No primeiro caso, pretendia-se como um modelo de transição mudar do Scrum para o Kanban e deixar a equipe experimentar os conceitos de Lean e Kanban.

Atualmente, é uma abordagem na qual a equipe optou por trabalhar de acordo com o Scrum com Sprints, mas usar o sistema Kanban para visualizar e melhorar continuamente seu método de trabalho para otimizar o fluxo de unidades de trabalho (por exemplo, histórias de usuário).

Escalando para produtos ou programasnível m

Para poder usar uma maneira ágil de trabalhar em uma organização de algum tamanho, basta ter equipes ágeis individuais. A maneira ágil de trabalhar precisa ser ampliada e, sempre que possível, o alinhamento abrangente precisa ser institucionalizado.

Para institucionalizar a coordenação, o gerenciamento de dependências e a integração entre as diferentes equipes ágeis permanentes do lado “administre os negócios” / “negocie como de costume”, existem várias estruturas disponíveis, incluindo:

  • Nexo, conforme descrito no Guia do Nexus, é uma estrutura para o desenvolvimento de iniciativas de desenvolvimento de produtos ou software com três a nove equipes Scrum, em Sprints de até trinta dias. Nexus é a resposta de Ken Schwaber, um dos pais fundadores do Scrum, à escalabilidade do Scrum.

    Requer mais do que apenas a vontade e o comportamento ágil das diferentes equipes de Scrum para trabalharem juntos para fornecer um produto integrado. O Nexus baseia-se e baseia-se no Scrum e nas regras e funções formuladas no Guia do Scrum. Podemos posicionar o Nexus sobre os níveis de equipe e programa do SAFe, mas ele não oferece provisões no nível do portfólio.

  • Scrum em escala (S @ S, desenvolvido por Jeff Sutherland e Alex Brown) é uma estrutura modular. O ponto de partida no S @ S é que não é possível uma estrutura abrangente de tamanho único, mas toda vez que precisamos analisar o dimensionamento dos princípios subjacentes do Scrum.

    A estrutura pode ser personalizada para sua própria organização, adicionando os módulos S @ S necessários. O S @ S baseia-se na conhecida estrutura Scrum. Por analogia com o Nexus, você poderia dizer que S @ S é a resposta de Jeff Sutherland, ao lado de Ken Schwaber, o outro pai fundador do Scrum, sobre a escalabilidade do Scrum.

  • Scrum em larga escala (Menos, desenvolvido por Craig Larman e Bas Vodde) é uma estrutura ágil com regras, baseada em princípios e em experiências.

    A LeSS Company oferece uma base de conhecimento livremente acessível (less.works) contendo a abordagem integrada, princípios, descrições de processos, definições, funções, exemplos, etc., para o desenvolvimento de produtos em larga escala, principalmente relacionados à TI.

    cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

    Transparência também é um conceito-chave no LeSS. A primeira versão data de 2005 e, desde então, o trabalho está sendo feito constantemente no uso e desenvolvimento do LeSS.

  • Estrutura ágil em escala (Seguro, desenvolvido por Dean Leaffingwell) é uma estrutura para permitir o escalonamento de equipes ágeis, a fim de criar melhores sistemas, criar maior envolvimento dos funcionários e usar considerações de custo corretas.

    Essa é a missão da organização ágil em escala e do fundador da SAFe, Dean Leffingwell. A organização ágil em escala oferece uma base de conhecimento acessível gratuitamente a todos (www.scaledagileframework.com) com uma abordagem integrada na forma de descrições de processos, definições, funções, exemplos etc. para o desenvolvimento de produtos Lean / Agile.

    O SAFe é baseado em cinco competências principais: Liderança Lean-Agile, Equipe e Agilidade Técnica, DevOps e Release on Demands, Soluções de Negócios e Sistemas Lean e gerenciamento de Portfólio Lean.

A Figura 1 (consulte o bloco “Negócios como de costume” / indefinido) faz uso de uma divisão entre produto e metas de equipe, nomeadamente com base na cooperação, se necessário, de equipes ou não. Ou, com outras palavras, as equipes individuais podem trabalhar de forma autônoma (foco da equipe) ou precisam trabalhar juntas para fornecer um produto novo ou modificado (foco do produto).

As estruturas mencionadas acima se referem a exemplos em que várias equipes trabalham em um único produto complexo ou fluxo de valor (estruturas direcionadas ao produto).

Não visual na figura, várias estruturas fazem uma distinção entre produtos em que você trabalha em conjunto com um máximo de nove equipes (no total, a equipe de equipes não deve exceder o número Dunbar de 125 a 150 pessoas) e uma equipe de equipes de equipes (por exemplo, grandes soluções SAFe, Nexus +, LeSS Huge).

O outro grupo diz respeito a estruturas para dar suporte aos departamentos de TI que precisam manter dezenas ou centenas de aplicativos ou serviços, nos quais as dependências entre as equipes são mínimas (várias estruturas direcionadas para equipes).

Aqui o Modelo Spotify (desenvolvido por Henrik Kniberg, Anders Ivarsson e Joakim Sundén) pode ser posicionado, mas também o Scaled Agile Lean Development (ScALeD, desenvolvido por Peter Beck, Markus Gartner, Christoph Mathis, Stefan Roock e Andreas Schliep).

Para ambos os grupos, há interfaces essenciais entre as equipes em áreas como integridade de dados, segurança e arquitetura que podem ou não exigirem coordenação às vezes na implementação de alterações.

Além disso, existem muitas estruturas menos conhecidas que podem oferecer suporte no nível do produto, incluindo AIF (Agile Integration Framework), Agile Team Portfolio Management (AgileTPM), AgilePath, Agile contínuo, Agile disciplinado (DA), Enterprise Scrum, Agilidade corporativa, FAST Agile, RAGE, Surge, XSCALE, XP industrial e AgileDS.

No lado esquerdo da figura 1, vemos os projetos e programas únicos como parte de “mudar os negócios”. Aqui é feita uma distinção entre projetos e programas. Dentro do bloco do projeto, vemos três estruturas e / ou métodos, os quais são um desenvolvimento adicional das estruturas mais tradicionais de gerenciamento de projetos:

  • Gerenciamento Ágil de Projetos (AgilePM, que é derivado do DSDM);
  • PRINCE2 Agile (derivado de PRINCE2 de AXELOS)
  • PMI-ACP (além do Guia PMBoK do PMI)
  • Projeto Meio Duplo (O Projeto Half Double é administrado por uma comunidade de profissionais dedicados ao gerenciamento de projetos, apaixonados pelo que fazem)
  • O Agile Project Management (APM), não mencionado na figura, também pode ser posicionado aqui.

No lado do programa, vemos:

  • Gerenciando programas bem-sucedidos (MSP do AXELOS), que é muito ágil por si só, com o crescimento passo a passo (via tranches) em direção à meta pretendida (e se conecta ao PRINCE2 (Agile)) e
  • AgilePgM (Agile Program Management do Agile Business Consortium) que se conecta ao AgilePM, por um lado, e é comparável ao MSP, por outro.

Praxis cobriu os níveis de portfólio, programa e equipe. O Praxis é um framework gratuito para o gerenciamento de projetos, programas e portfólios (baseado em PRINCE2, MSP, MoP, AgilePM e outros frameworks).

Inclui um conjunto de conhecimentos, metodologia, estrutura de competências e modelo de maturidade de capacidade. A estrutura é suportada por uma base de conhecimento de recursos e uma enciclopédia.

Gerenciamento de portfólio nível

O gerenciamento tradicional de portfólio se concentra em ‘mudar os negócios’. Nos capítulos anteriores, ficou claro que mais e mais mudanças estão sendo tratadas pela organização de linha, ou seja: pelas equipes ágeis permanentes.

Isso significa que agora o gerenciamento de portfólio também deve fornecer uma visão geral do que ocorre em ‘administrar os negócios’ / ‘negócios como sempre’ para que sejam implementadas iniciativas de mudança.

Estruturas de portfólio existentes, como Gerenciamento ou Portfólios (Esfregão AXELOS) e Standard for Portfolio Management (SfPfM PMI) abrangem apenas a parte de mudar de negócio. Gerenciamento ágil de portfólio (AgilePfM da ABC) abrange “administrar os negócios” / “negócios como de costume” e “alterar os negócios”.

Além disso, existem várias estruturas ágeis que também incluem um componente de gerenciamento de portfólio:

  • Seguro oferece uma camada de gerenciamento de portfólio para controlar a (s) equipe (s) permanente (s) de negócios.
  • Agile disciplinado (DA) oferece um processo de portfólio no qual, além dos projetos, são levados em consideração vários aspectos de ‘executar os negócios’ / ‘como sempre’, como as equipes permanentes e o gerenciamento operacional das soluções de TI existentes .
  • Scrum @ Scale contém módulos Visão estratégica e desenvolvimento organizacional aos quais o gerenciamento de portfólio pode estar relacionado.
  • O Spotify também fornece sua própria abordagem de gerenciamento de portfólio com seu planejamento estratégico.
  • AgilePfM use alguns conceitos básicos de um centro de inovação, um processo ágil de portfólio, maturidade das iniciativas no portfólio e horizontes para um portfólio ágil.

No momento (2018), não existem estruturas maduras de gerenciamento de portfólio que incluam ‘alterar os negócios’ e ‘administrar os negócios’ / ‘negócios como de costume’.

O AgilePfM foi lançado pelo Agile Business Consortium (anteriormente DSDM Consortium) como parte de sua Agile Business Change Framework. No entanto, está ficando cada vez mais claro que os princípios gerais de gerenciamento de portfólio ágil são baseados em estruturas como SAFe, Agile PfM e Disciplined Agile.

Nível de negócios

O foco nos negócios fornece estruturas para aumentar a agilidade dos negócios, alterando a mentalidade de todos os funcionários da organização. O que significa trabalhar de forma ágil?

Como podemos garantir que os valores e princípios do Manifesto Ágil sejam entendidos e aplicados, e os valores Scrum (coragem, foco, comprometimento, respeito e abertura) fazem parte do que estamos fazendo?

Se a mentalidade correta estiver em vigor, será muito mais fácil implementar uma estrutura ágil. Na figura 1, as seguintes estruturas são mencionadas:

  • Agilidade em espaço aberto (OSA) é uma técnica segura, pragmática e repetível para obter uma adoção rápida e duradoura do Agile. Ele funciona com a estrutura que você está usando no momento e o OSA pode ser adicionado a qualquer momento. O OSA é usado para envolver ativamente o maior número possível de funcionários em seu programa Agile.
  • AgileSHIFT (desenvolvido pela AXELOS) é uma estrutura que prepara as pessoas para mudanças transformacionais, criando uma cultura de agilidade da empresa. A estrutura AgileSHIFT ajuda as organizações a sofrer uma mudança transformacional, a adotar uma mentalidade de ‘sobreviver, competir e prosperar’.

    Isso ajudará a preencher a lacuna entre o estado atual e o destino (o Delta no AgileSHIFT), adotando uma variedade de abordagens ágeis, estruturadas e híbridas em toda a organização. A divisão grave existente entre “administrar os negócios” e “alterar os negócios” desaparecerá.

  • Escalas de agilidade (desenvolvido por Jurgen Appelo) ajuda as organizações a obter agilidade em escala de baixo para cima – com evidências mensuráveis ​​de transformação organizacional.
  • Agile orientado a objetivos (GDA) assenta em três pilares principais: autonomia, alinhamento e melhoria estruturada. É uma estrutura muito simples e consiste em apenas uma estrutura base, o diamante, cinco funções e dez blocos de construção.

Já são mais de 50 estruturas ágeis e ainda estão crescendo. A figura pode ajudá-lo em seu processo de seleção de estrutura ágil, mas não pode ser dito com bastante frequência, não aja dogmaticamente, veja uma estrutura não como uma panacéia que pode ser implementada imediatamente. O senso comum também ajuda a obter mais agilidade.

Henny Portman é blogueiro / revisor (hennyportman.wordpress.com), autor, palestrante e parceiro internacional, instrutor e consultor sênior P3M3 Maturity da HWP Consulting.

  1. Esta imagem é baseada em uma versão mais simples do livro Scaling Agile in organizaties (Portman, 2017)

2. Pichler, Roman, ‘Scrum é adequado para o seu produto?’, 19 de setembro de 2016, consulte: www.romanpichler.com

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *