Arquivo para Tag: agile methods

Método XP (Extreme Programming)

17 de abril de 2023/0 Comentários/em Agile Methods/por coimbra

O Extreme Programming é um dos métodos ágeis. É diferente pois é Leve, Reduz o risco, Eficiente, Flexível, Antecipado, Fácil, E o mais importante, é uma maneira emocionante e divertida de desenvolver software.

O que é o Extreme Programming?

Conforme Wikipedia – Extreme Programming (XP) é uma metodologia de desenvolvimento de software que visa melhorar a qualidade e a capacidade de resposta do software às mudanças nos requisitos do cliente.

Como um tipo de desenvolvimento ágil de software, defende frequentes “libera” em curtos ciclos de desenvolvimento, que visam melhorar a produtividade e introduzir pontos de verificação nos quais novos requisitos de clientes podem ser adotados.

Por que é chamado de “ Extreme? ”

Porque aumenta a eficiência e também garante a aplicação de princípios e valores de maneira extremamente eficaz. É feito por

Em primeiro lugar, revisar o código a cada passo de cada iteração para torná-lo mais eficaz
Em segundo lugar, fazendo testes de regressão em todas as etapas do desenvolvimento para tornar os testes mais eficazes.
Além do acima exposto, a reutilização diária de códigos torna o design mais eficaz.
Além disso, iterações curtas tornam a entrega mais eficaz.

A figura abaixo mostra como as fases e valores típicos de desenvolvimento de software foram levados ao seu nível extremo neste método de desenvolvimento.

Kent Beck originalmente definiu Extreme Programming (XP) em 1996; no entanto, sua segunda versão tinha uma explicação dos princípios, lançados em 1999. O foco principal da Extreme Programming é satisfação do cliente, e suas equipes de desenvolvimento alcançam isso organizando-se.

Eles desenvolvem recursos quando o cliente precisa deles. Além disso, a Extreme Programming leva as melhores práticas do processo de desenvolvimento a um nível extremo. No mercado em rápida mudança de hoje, ele usa o método de iteração para se adaptar rapidamente aos novos requisitos. É uma maneira altamente disciplinada de fornecer continuamente software de alta qualidade mais rapidamente.

Além disso, o cliente está envolvido ativamente com a equipe para executar planejamento, testes e feedback rápidos contínuos para fornecer software de trabalho com frequência.

XP é um dos métodos mais populares. É leve porque

Em primeiro lugar, concentra-se em obter mais feedback, em vez de perguntar aos clientes antecipadamente sobre o que ele quer.
Em segundo lugar, ele agrega valor ao cliente em pequenas iterações ( 1 ou 2 semanas ).
Incentiva a mudança. Em outras palavras, ele tenta acomodar todas as alterações sugeridas pelo feedback do cliente, depois a redesenha, a recodifica e a reteste.
Além disso, tenta eliminar defeitos nos estágios iniciais, reduzindo assim o retrabalho e o custo.
Mantém o cliente envolvido durante todo o projeto.

Quando usar a Extreme Programming:

O aplicativo de Extreme Programming acontece nos projetos em que os requisitos continuam mudando.
Em alguns projetos críticos, mesmo antes de iniciar o projeto, os cronogramas são decididos. É referido como risco do projeto, pois é um desafio cumprir esses prazos. Portanto, a Extreme Programming também aborda o risco do projeto por ciclos de desenvolvimento frequentes e mais curtos e, consequentemente, permitindo feedback antecipado.
O XP é aplicado onde temos um pequeno grupo de programadores, não mais que 12.

Valores, Princípios e Práticas:

Valores

Existem cinco valores de Extreme Programming

1. Comunicação	A comunicação é a parte mais crucial de qualquer projeto. É necessária uma comunicação adequada para preencher as lacunas entre o que o desenvolvedor está fazendo e os requisitos do cliente. Ajudará a reduzir o retrabalho se soubermos a condição exata. Além disso, comunicação adequada dentro da equipe (os desenvolvedores) também é necessário para garantir que todos estejam na mesma página. Por exemplo, digamos em um restaurante se um cliente diz especificamente ao garçom que ele quer que seu prato seja Menos oleoso levemente picante Menos salgado devido a razões médicas. Mas o garçom diz ao chef para tornar o prato menos picante. Depois disso, quando a refeição chega, ela é rejeitada pelo cliente, o motivo é; também tinha óleo e a quantidade usual de sal. E o chef teve que cozinhar novamente. Tudo porque não havia comunicação adequada entre o garçom e o chef.
2. Simplicidade	Precisamos começar a desenvolver os recursos mais diretos primeiro e, posteriormente, devemos passar para as funcionalidades problemáticas e extras. Deve ser simples, e devemos trabalhar na necessidade no momento. Além do acima exposto, não devemos nos preocupar com requisitos futuros e não devemos complicar, assumindo que esse recurso possa ser necessário posteriormente. Os desenvolvedores e testadores entenderão facilmente código e design simples. Por exemplo, quando o chef tem vários pedidos, ele sempre começa com o que acha confortável e está confiante de que pode cozinhar bem. Como, durante os exames, sempre fomos sugeridos por nossos idosos para começar com o que for mais simples.
3. Feedback	O feedback contínuo ajuda a entender o desempenho de você. Funciona como um catalisador para o projeto. Em Extreme Programming, o feedback pode vir de diferentes fontes, como Cliente: Após cada iteração, uma função será entregue ao cliente que executará o teste de aceitação. Com base nos resultados dos testes de aceitação, os desenvolvedores recebem o feedback e trabalham com ele posteriormente. Sistema: O principal motivo para realizar o teste da unidade é obter feedback. Ao escrever o teste da unidade ou realizar um teste de iteração, eles sabem do estado do sistema se há alguma falha na codificação. Dentro da equipe: O objetivo de formar uma equipe é ajudar um ao outro e trabalhar como um. Sempre que o cliente vem com um novo requisito, ele pode fornecer feedback sobre a estimativa do tempo necessário e a criação de uma expectativa com base em suas experiências anteriores. Por exemplo, desenvolvedores são como chefs em um restaurante. Eles devem estar prontos para aceitar feedback de todas as fontes da mesma maneira que um chef pode obter feedback do cliente, de seu chef sênior, do garçom ou da gerência..
4. Coragem	No desenvolvimento de software, coragem significa: Em primeiro lugar, fornecer confiança aos desenvolvedores para tomar decisões corajosas, entendendo todos os aspectos envolvidos. Em segundo lugar, confere confiança ao programador e permite que ele refacte ( reutilize ) o código usado, quando e quando necessário. Em outras palavras, o desenvolvedor analisa o código atual e o altera ou modifica para se adequar a fins futuros. Além do acima, ele suporta os desenvolvedores líderes na decisão de fazer o restante dos desenvolvedores funcionar com mais eficiência. Por exemplo, quando um programador fica preso em um problema difícil por um dia inteiro, ele pode preferir fazer uma pausa e resolvê-lo rapidamente no dia seguinte. No entanto, só será possível se ele for persistente. Por exemplo, em um restaurante, o chef é responsável por decidir os ingredientes, o tempo de cozinhar e o tempero. É o tipo de fé que a equipe mostra no chef e lhe dá coragem para tomar suas próprias decisões.
5. Respeito	No Extreme Programming, todos se respeitam. O respeito é a base dos quatro valores. Podemos ganhar respeito adotando acima os valores no sistema. Além disso, esse valor é mais sobre o trabalho em equipe. Em resumo, esse valor depende dos quatro valores acima. Por exemplo, em um restaurante, todos têm seus papéis específicos e outros valores. Um chef respeitará e valorizará o que o garçom disser; o chef nunca voltará e verificará com o cliente se o garçom está certo ou não? Da mesma forma, o garçom, enquanto serve, nunca perguntará ao chef sobre o prato. O garçom respeitará a experiência e a habilidade do chef.

Princípios

Os princípios abaixo são aplicados durante todo o procedimento de Extreme Programming:

1. Feedback rápido:

Feedback rápido significa que o tempo entre o recebimento do feedback e a implementação no sistema deve ser mínimo.

Os desenvolvedores projetam, implementam e testam as funções. Consequentemente, o feedback é compartilhado imediatamente e é aplicado sem demora.
Além disso, o código também é revisado com o sistema e o feedback é compartilhado instantaneamente.

2. Suponha simplicidade:

Esse princípio sugere que os desenvolvedores devem tentar lidar com todos os problemas com simplicidade, como,

Um código desenvolvido deve refactar facilmente o ( reutilize após algumas modificações ) para realizar testes adicionais realizando testes de unidade.
Tente manter o código simples e siga a regra de “você não vai precisar”. Em outras palavras, significa que, se não precisamos agora, não devemos mantê-lo.
“Não se repita“, os desenvolvedores seguem esse princípio. Ou seja; você não deve manter várias cópias do mesmo documento, código, tarefa ou qualquer coisa.

3. Mudança incremental:

Alterações incrementais significam “mudanças em pequenos passos”. A Extreme Programming suporta alterações incrementais. Significa em um momento apenas muito:

Pequenas mudanças no plano
Alterações mínimas em uma equipe
Pequenas mudanças no design

4. Abraçando a alteração:

É a abordagem que fala sobre adotar e considerar a maioria das mudanças, enquanto o problema real está sendo resolvido simultaneamente. Portanto, abraçando as conversas sobre mudanças

A capacidade de aceitar as alterações no seu trabalho atual.
Adaptar essas mudanças sem prejudicar seu trabalho.
Fornecer o mesmo desempenho na implementação dessas mudanças também.

5. Trabalho de qualidade:

Fornecer o produto da melhor qualidade é o principal motivo. Para esclarecer, a equipe precisa

Trabalhe em equipe
Aproveite seus papéis
Deve ser de suporte
Deve se sentir bem e focado em fornecer um produto de qualidade

Práticas

A Extreme Programming possui as seguintes áreas de práticas –

Feedback em escala fina
Processo contínuo
Compreensão compartilhada
Bem-estar do programador

As Práticas do Extreme Programming

As 12 práticas de Extreme Programming atingem o objetivo de Extreme Programming. A fraqueza de qualquer um dos métodos é composta pela força de outras práticas.

Havia 24 práticas de XP, que mais tarde foram perfuradas por Kent Beck para 12 práticas primárias:

O jogo de planejamento ( histórias de usuários )
Pequenos lançamentos
Metáfora
Design simples
Teste
Refatoração
Programação de pares
Propriedade coletiva
Integração Contínua
Semana de trabalho de 40 horas
Cliente no local
Codificação

A figura acima mostra a aplicação das práticas no Extreme Programming.

Como o uso de terminologias normais e a estrutura do sistema subjacente ( metáfora ), o cliente no local cria as histórias.
Como essas histórias são passadas para os desenvolvedores e, além disso, o desenvolvedor cria um jogo de planejamento baseado nas histórias do usuário e, finalmente, inicia o desenvolvimento de todas as funcionalidades em pequenas iterações.
Os recursos começam a ser lançados em pequenas iterações.
A cor verde escura representa todos os processos pelos quais cada iteração passa. Ou seja, cada funcionalidade, em cada iteração, passa pelo teste de aceitação.
A integração contínua usa os dados dos testes de aceitação. Junto com isso, a metáfora também usa esses resultados para esclarecer requisitos.
Os padrões contínuos de integração e codificação enfatizam a propriedade coletiva. Em outras palavras, se alguém estiver ausente ou não estiver disponível, o trabalho não deve parar.
Devido a requisitos precisos e linguagem fácil na metáfora, o design é simples.
O mesmo design também pode ser refatorado para qualquer outra função.
O teste da unidade é realizado após a conclusão do projeto.
Os resultados dos testes de unidade são usados para integração contínua. Além disso, se houver algum bug, a programação em pares poderá ser feita para resolvê-lo.
A solução da programação de pares pode ser documentada para referência futura, a fim de simplificar o design.
Além disso, os resultados também são usados na definição do padrão de codificação, para que o mesmo problema, na mesma situação, não ocorra novamente.
O padrão e a metáfora da codificação nos falam coletivamente sobre os padrões e a estrutura da organização com base nas práticas e resultados anteriores. E de acordo com isso na indústria de software, não se deve trabalhar mais de 40 horas por semana para trabalhar com eficiência.
Propriedade coletiva

As quatro áreas em que as práticas de Extreme Programming se enquadram são:

1. Feedback em escala fina

Teste:
- O que é – Isso inclui todos os tipos de testes
  - Teste de unidade
  - Primeiro teste de projeto
  - Vários tipos de testes automatizados
  - Vantagens:
- Em primeiro lugar, o teste de unidade é o teste final antes do teste do usuário. Indica que não é necessário mais design ou codificação.
  - Em segundo lugar, a refatoração do código acontece usando os resultados dos testes da unidade. Reduzirá o trabalho à medida que o código for reutilizado novamente.
  - Em terceiro lugar, o teste da unidade indica que o design é claro e não são necessárias mais modificações. Portanto, o desenvolvedor conhece seus objetivos de acordo com o design e sabe o que ele tem que desenvolver.
  - Além disso, a automação fornece uma série de testes de regressão que confirmam que o recurso / função testado está funcionando bem e não há efeito adverso disso.

Cliente no local
- O que é isso?
- Alguém que tem profundo conhecimento do projeto.
- Desempenha papéis significativos durante o “Fase de direção ( a fase em que todas as alterações são feitas, discutida em detalhes posteriormente neste artigo ) ” do projeto.
- Ele fornece feedback rápido, pontual e contínuo à equipe de desenvolvimento.
- Vantagens:
  - Em primeiro lugar, todas as perguntas são respondidas naquele momento; sem necessidade de e-mail ou aprovações.
  - Em segundo lugar, os clientes podem garantir que o produto esteja se moldando de acordo com seus requisitos.
  - Além disso, eles podem priorizar novamente os requisitos.

Programação de pares
- O que é isso?
  - Dois desenvolvedores compartilham uma estação de trabalho.
  - Eles usam seus cérebros para descobrir como fazer a codificação e como os outros codificarão.
  - Consequentemente, eles podem mudar de função, quando e quando necessário.
- Vantagens:
  - Em primeiro lugar, dois cérebros sempre pensam melhor que um.
  - Em segundo lugar, eles trabalham com melhor concentração.
  - Além disso, duas pessoas podem debater e responder abaixo das perguntas de uma maneira melhor
    - Existe uma maneira de executar a tarefa de maneira mais simples?
    - Essa codificação como um todo vai funcionar?
    - Quais são os casos de teste que podem não funcionar e por quê?

2. Processo Contínuo

Integração Contínua
- O que é isso?
  - Adicionando novos recursos ou alterações ao sistema sem demora.
  - Além disso, acontece a aplicação de pequenas integrações ( características adicionais ) às funcionalidades.
  - Para esclarecer, um desenvolvedor estará tirando uma cópia do código base atual e trabalhará para criar um código para alguns recursos diferentes. Da mesma forma, outro desenvolvedor estará trabalhando com a mesma base de código para codificar para outra função. É assim que o código é improvisado ( integrado ) se for usado por mais de um dia.
- Vantagens:
  - Em primeiro lugar, torna o processo menos demorado.
  - Além disso, permite pequenos lançamentos de projetos.

Refatoração
- O que é isso?
  - Processo de alteração do sistema de software para melhorar sua estrutura interna sem alterar o comportamento externo do código.
  - Reutilize o código antigo ( após o teste da unidade ) para codificar algumas outras funcionalidades.
- Vantagens:
  - Em primeiro lugar, ajuda o desenvolvedor a melhorar o produto.
  - Em segundo lugar, permite brainstorming para encontrar diferentes maneiras e, portanto, promove a formação de equipes.
  - Além disso, aumenta o conhecimento do programador sobre o sistema.

Lançamentos curtos
- O que é isso?
  - Funcionalidades entregues em pequenas porções.
  - Menor os recursos, mais rápido o lançamento.
  - Suporte “Jogo de planejamento”.
- Vantagens:
  - Em primeiro lugar, promove uma liberação mais rápida e frequente.
  - Em segundo lugar, é fácil acompanhar o progresso.
  - Em terceiro lugar, reduz as chances de grandes erros.
  - Além do acima, reduz o retrabalho.

3. Entendimento compartilhado −

O jogo de planejamento
- O que é isso?
  - Aprenda histórias de usuários para planejar.
  - Planeje o que será entregue na próxima iteração.
  - Uma pessoa técnica e experiente estimará o custo e o tempo.
  - O jogo Planejamento mostra a ligação entre o desenvolvedor e o customer.
- Vantagens:
  - Em primeiro lugar, evita o desperdício de tempo no desenvolvimento de recursos desnecessários.
  - Em segundo lugar, é uma abordagem planejada, portanto, nenhuma adivinhação.
  - Além disso, todos estão cientes do progresso.

Design simples
- O que é isso?
  - Mantendo o design o mais simples possível.
  - Além do acima, fazendo o mínimo suficiente para agregar valor ao sistema.
- Vantagens:
  - Em primeiro lugar, economiza tempo, porque nenhum recurso adicional é trabalhado.
  - Em segundo lugar, é fácil de entender.
  - Finalmente, trata-se de propriedade coletiva e, portanto, a refatoração será fácil.

Metáfora
- O que é isso?
  - A arquitetura verbal de todo o sistema. Em outras palavras, a metáfora define todo o sistema em seus termos técnicos e é compreensível apenas para aqueles que fazem parte do sistema.
  - Ele usa um conjunto padrão de condições.
  - As metáforas estão comandando ferramentas de ensino. Isso é para dizer; eles se acostumam em um grande número de áreas. Além disso, uma metáfora visa criar uma ponte de entendimento entre duas ou mais partes.
- Vantagens:
  - Em primeiro lugar, inspira terminologias comuns.
  - Em segundo lugar, reduz o uso de jargões técnicos.
  - Além disso, é uma correção rápida e direta para entender o sistema.

Propriedade coletiva
- O que é isso?
  - Fala sobre responsabilizar os desenvolvedores pelo que estão fazendo.
  - Em outras palavras, todos os desenvolvedores da equipe possuem todo o código.
  - Refatorar acontece.
- Vantagens:
  - Em primeiro lugar, não há medo de alguém deixar a equipe, pois todos na equipe conhecem o código completamente.
  - Além disso, torna cada desenvolvedor responsável por cada código no sistema.
  - Além disso, torna o desenvolvedor responsável pelo sistema como um todo e, portanto, não sendo apenas uma parte do sistema.

Padrões de codificação
- O que é isso?
  - Todo código deve seguir os mesmos padrões de codificação, que é uma decisão mútua do desenvolvedor líder e do cliente no momento do planejamento.
  - Além disso, apenas o líder deve saber quem projetou qual código para que a equipe trabalhe em equipe e não como indivíduos.
- Vantagens:
  - Em primeiro lugar, mantém todos na mesma página, pois todos seguirão os mesmos padrões de codificação predefinidos.
  - Em segundo lugar, será fácil encontrar brechas ( se houver ), pois qualquer coisa que não atenda às regras de codificação padrão não será adequada.
- Além disso, diminui o tempo que o desenvolvedor leva para codificar, pois ele conhece o conjunto de regras a seguir.
- Finalmente, a codificação será clara e inconfundível.

4. Bem-estar do desenvolvedor / programador −

Semana 40 horas
- O que é isso?
  - Limitação do horário de trabalho a 40 horas em uma semana.
  - Nenhuma hora extra promovida porque é um sintoma de um problema.
  - Além disso, trabalhar mais de 40 horas por semana não será adequado a longo prazo.
- Vantagens:
  - Em primeiro lugar, menos horas de trabalho mantêm o desenvolvedor ativo.
  - Ao mesmo tempo, eles trabalham com mais eficiência.
  - Além disso, mantém o desenvolvedor livre de estresse e saudável .

Artefatos XP

Dois artefatos principais no XP são

Cartões de história
Cartões de tarefas

Outros artefatos importantes da Extreme Programming são os seguintes

Testes de aceitação
Estimativas
- Plano de liberação
- Plano de iteração
Design
Casos de teste de unidade
Registros de comunicação

Cartões de história

Uma história de usuário não passa de um documento que descreve os requisitos do usuário. As estruturas dos cartões de história do usuário têm os seguintes recursos:

O cliente projeta ou grava um cartão de usuário.
Descreve o sistema do ponto de vista do cliente.
Um cartão de usuário é uma linguagem simples e pouco técnica. Em outras palavras, o cliente usa seus termos para explicar o requisito.
Um cartão de usuário deve ser detalhado o suficiente para que o desenvolvedor possa estimar quanto tempo levará para que uma história específica seja projetada, testada e implementada.
Uma descrição do recurso requer um cartão de usuário no sistema. Em outras palavras, um cartão de usuário para cada requisito.
As estimativas para a entrega do recurso são feitas usando os cartões de histórias do usuário.

Cartões de tarefas

A Cartão de Tarefas é criado pela equipe de desenvolvimento para implementar a tarefa de maneira organizada. Ele terá os seguintes detalhes da tarefa em relação a uma história específica do usuário.

A lista de tarefas necessárias para a implementação de uma História de Usuário é chamada de Cartão de Tarefas.
Além disso, apenas um cartão de tarefa é projetado e emitido contra uma história de usuário.
eualém disso, o Cartões de tarefa trabalhar como base para tarefas e fornecer uma estimativa para concluir uma tarefa.

Testes de aceitação:

O desempenho dos testes de aceitação ocorre para garantir que todas as histórias do usuário sejam adequadamente compreendidas e implementadas. A equipe de testadores faz esses testes.

Estimativas:

Existem duas fases, onde a avaliação da tarefa, a estimativa de tempo e a estimativa de esforço acontecem.

Abaixo estão as duas fases de estimativa e seu planejamento.

Planejamento de Liberação– Nesta fase, a decisão de cada recurso ( iteração ) do “Plano de liberação” ocorre juntamente com a estimativa da duração da entrega e do número de pessoas / esforços necessários. A seguir, estão as razões para esta estimativa:
- Primeiro, para descobrir a data completa de lançamento do objetivo do projeto, executada na fase de exploração.
- Segundo, para descobrir se algum tempo ou ajuste da força de trabalho é planejado na fase de direção.
Plano de Liberação – Plano de liberação é o plano documentado que terá os detalhes de −
- As histórias de usuários que foram selecionadas pela equipe de desenvolvimento para lançamento.
- Estimativas do tempo necessário e dos esforços necessários.
- A data que foi confirmada como a data de lançamento.
Estimativas – Planejamento de Iteração – Na mesma linha do planejamento de liberações, aqui nesta fase, acontece a avaliação das estimativas das tarefas relacionadas ao esforço e duração. Além disso, essa avaliação é usada para atribuir as tarefas no planejamento da iteração e equilibrar uma carga de trabalho por recurso na fase de compromisso.
Plano de Iteração – O projeto é dividido em pequenas iterações e cada iteração terá os planos de iteração. O plano de iteração tem os seguintes detalhes:
- As histórias do usuário selecionadas para essa iteração específica.
- Tarefas atribuídas e os detalhes da pessoa a quem é atribuída.
- Uma estimativa, quando a tarefa for concluída.

Design

O desenvolvedor desenvolve o design referindo-se à história do usuário. O desenvolvedor requer esse design para a implementação da história do usuário.

Casos de teste de unidade

Após o design, o desenvolvedor faz a codificação, seguida pelo teste da unidade.

Para testes de unidade –o caso de teste da unidade é preparado pelo desenvolvedor para garantir que o recurso específico ( unit ) esteja funcionando conforme o esperado. O teste da unidade é um teste escrito pelo desenvolvedor para qualquer funcionalidade específica. Além disso, o caso de teste da unidade leva à codificação e teste da unidade para qualquer tarefa. Em resumo, é o primeiro passo no nível de testes e feito antes Teste de integração.

Registros de comunicação do cliente e do desenvolvedor:

Todas as atividades são baseadas nas histórias.

A história do usuário é a comunicação do usuário para um desenvolvedor.
O cartão de tarefa é a comunicação dentro da equipe.

Portanto, ambas as histórias são documentadas com base na comunicação entre clientes e desenvolvedores ou dentro da equipe.

Como o XP não suporta documentação desnecessária,

Se não for necessário – a comunicação pode ser verbal.
Se necessário – a documentação pode acontecer posteriormente.

Quais são as diferentes atividades da Extreme Programming?

Existem quatro atividades principais da Extreme Programming. Eles são:

Codificação
Teste
Ouvindo
*Projetando

Codificação

Antes de codificar, trata-se de coletar os requisitos e projetar conforme os requisitos. No entanto, uma vez que o design e o teste acontecem, a codificação é iniciada.

Uma equipe de desenvolvedores ou programadores fará a codificação.

Teste:

O teste é de dois tipos, a saber, Manual e Automatizado. Aqui neste método, o teste manual é realizado.

A equipe de testadores realiza testes manuais e, posteriormente, os resultados dos testes serão publicados.

Se os resultados do teste forem positivos, podemos prosseguir com o processo de liberação.
No entanto, se não, o testador precisa aumentar o defeito, classificá-lo e testá-lo novamente.

Ouvindo:

Como o desenvolvedor saberia o que deve ser codificado por ele e testado pelo testador? Ouvir permite que você entenda seu trabalho.

Testadores e desenvolvedores são uma parte crítica do sistema. Portanto, ambos precisam ser um ouvinte ativo para entender o progresso atual e as próximas etapas.

Projetando:

Manter todas as três atividades no design de uma página acontece. Em outras palavras, coloca todas as três atividades sob um guarda-chuva.

Fases de programação

O desempenho de todas as atividades acima ocorre em diferentes fases do desenvolvimento. Essas diferentes fases da programação são −

Planejamento de Liberação
Planejamento de Iteração
Implementação

Planejamento de lançamento

Nesta fase, planejamos o próximo lançamento. As histórias do usuário e a data de lançamento subsequente projetam isso. O planejamento da versão será feito pelo cliente e desenvolvedores mutuamente em três fases.

Fase de Exploração
Fase de Compromisso
Fase de Direção

Planejamento de liberação – Fase de exploração:

Em primeiro lugar, a fase de Exploração é a fase de coleta de requisitos e descoberta do impacto desse requisito no projeto e, portanto, enquadrá-los em uma história de usuário. A seguir, estão as etapas para isso:

Crie uma história:

Os clientes enfrentam alguns problemas e abordam o desenvolvedor com um problema e explicam sua pergunta ao desenvolvedor*.

Posteriormente, o cliente e o desenvolvedor discutem o problema e compreendem os aspectos técnicos dele.
Além disso, o desenvolvedor deve ajudar os clientes a entender os termos técnicos e não deve influenciar os requisitos do cliente.
Por fim, os clientes documentam o problema e fornecem um cartão de história formalmente documentado para suas perguntas.
O cartão de história do usuário deve ser documentado apenas pelo cliente e, posteriormente, o desenvolvedor o obtém.
Em resumo, no cartão de história do usuário, os clientes chamarão seus requisitos e termos exatos.
Estime uma história: Os desenvolvedores farão esta parte. Eles estimarão quanto tempo levará para implementar o trabalho mencionado no cartão de história do usuário. Além disso, eles podem analisar e preparar um layout para resolver o problema, para que todos tenham uma idéia clara sobre o problema e sua solução. Esta solução não deve influenciar os requisitos comerciais ou “Cartão de história do usuário“.
Divida uma história: Antes de passar para a próxima fase, que é “Planejamento de Iteração”, precisamos projetar complexidades críticas primeiro. Se o desenvolvedor não conseguir estimar a história do usuário, ele deverá dividi-la ainda mais e escrever / explicar novamente.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa é crucial nesta fase para:

Atenda adequadamente aos requisitos do cliente
Entenda o cartão de história do usuário
Explique um cartão de história para a equipe de desenvolvimento
Ganhe clareza
Evite incerteza
Expresse-se claramente no caso de interrupções de entendimento.

Fase de compromisso do planejamento de lançamento:

A segunda fase é conhecida como fase de compromisso, porque envolve a resolução de:

Funcionalidades desejadas
Custo estimado
Impacto nos negócios
Lucro e
Data de lançamento

O cliente e o desenvolvedor resolverão isso com base em quatro componentes:

Classificar por valor: O cliente classificará as histórias do usuário de acordo com os valores comerciais pelo cliente.
Por velocidade: Os desenvolvedores tentam descobrir a que velocidade eles podem executar e entregar o projeto.
Classificar por risco: O desenvolvedor classificará as histórias com base no risco.
Escolhendo o escopo: Finalmente, as histórias do usuário com uma data de lançamento serão coletadas primeiro para garantir que sejam entregues a tempo. Em outras palavras, as histórias de usuários que terminarem primeiro no próximo lançamento serão retomadas mais cedo.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: A escuta ativa também é essencial aqui, devido aos seguintes motivos −

Primeiro, o desenvolvedor precisa ter um entendimento claro da funcionalidade exigida na versão atual.
Além disso, é essencial estimar os esforços e a duração necessários para a entrega dessa funcionalidade.
Além disso, o cliente e o desenvolvedor poderão entender e decidir se é possível cumprir a data de lançamento comprometida ou não..

Fase de direção do planejamento de liberação:

Finalmente, chega a fase de direção, que também é conhecida como fase de mudança. Os requisitos de novas mudanças acontecem nesta fase. Em outras palavras, tudo acontece nesta fase, como adicionar um novo recurso, remover ou alterar um recurso existente etc.

Na fase de direção, o cliente pode solicitar ao desenvolvedor que “boi” o processo

Como, traga mudanças nas histórias do usuário.
Priorizar as histórias de diferentes usuários ( alterando a prioridade ).
Ajuste o plano de liberação em caso de estimativas incorretamente estabelecidas.
Para acomodar as alterações sugeridas pelo usuário.

Funções usadas nesta fase: Cliente e Desenvolvedor

Artefatos utilizados: Cartão de história do usuário

Importante: Como todas as fases, a escuta ativa também é essencial nesta fase. É importante:

Entenda a adição dos novos requisitos.
Compreender as alterações necessárias para as necessidades atuais.
Analise o que precisa ser removido e o impacto subsequente da remoção no sistema existente.
Conhecer o trabalho realizado até agora.

Planejamento de Iteração:

Nesta fase, não há envolvimento do cliente. Isso é para dizer; os desenvolvedores planejarão as atividades e tarefas para iteração.

O planejamento de iteração tem três fases

Fase de exploração.
Fase de compromisso.
Fase de direção.

Planejamento de iteração – Fase de exploração:

Na fase de exploração,

Várias tarefas obtêm a interpretação dos requisitos.
O cartão de tarefa registra todas as tarefas.
Além do acima, o desenvolvedor fará uma estimativa do tempo de implementação da tarefa.
Finalmente, trabalhos muito pequenos ou muito grandes são combinados / divididos para obter uma estimativa.

Funções: Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – fase de compromisso:

Na fase de compromisso,

O desenvolvedor recebe as tarefas.
O desenvolvedor reconhece a responsabilidade da tarefa atribuída.
Além disso, o desenvolvedor fornece uma estimativa do tempo necessário para a conclusão da tarefa.
Finalmente, o tempo estimado e a comparação de trabalho ocorrem quando toda a carga ( de trabalho ) ocorre entre os programadores.

Funções: Desenvolvedores

Artefatos: Cartão de tarefa

Planejamento de iteração – Fase de direção:

Na fase de direção,

O desenvolvedor entende o cartão de tarefa da tarefa executada.
A equipe do desenvolvedor executa a tarefa usando as técnicas de programação do Pair.

Funções: Desenvolvedores

Artefato: Cartão de tarefa

Implementação:

A implementação acontece durante a fase de direção da iteração. As atividades que se enquadram nisso são-

Projete a tarefa: O desenvolvedor começa a trabalhar no trabalho escrito no cartão de tarefa e, posteriormente, começa a projetar conforme o cartão.
Escreva um teste de unidade: O programador primeiro grava um teste automatizado conhecido como teste de unidade, antes da codificação real.
Escreva o código: O programador começa a codificar.
Executar teste: Os testes de unidade são executados para verificação de código.
Refatoração: Isso significa reutilizar o código com algumas pequenas alterações.
Execute testes funcionais: Testes integrados e testes de aceitação do usuário estão sob este.

Papel: Desenvolvedores

Funções e responsabilidades extremas:

Na Extreme Programming, três funções são muito críticas e vitais. Da mesma forma, existem outros papéis também, mas eles trabalham sob eles. Esses papéis principais são-

Cliente:

O cliente é quem decide e transmite todo o requisito. Na Extreme Programming, o cliente deve estar em contato contínuo com os desenvolvedores. Além disso, o cliente pode ser

Uma comunidade específica
Um grupo de partes interessadas
- Uma equipe com o membro que inclui
- Gerentes de produtos
- Membros de vendas e marketing
- Usuários e gerentes finais
- Analista de Negócios
- Operações

O cliente será responsável pelo seguinte

Escrevendo histórias de usuários
Testando as funções finais entregues pelos desenvolvedores e escrevendo um teste funcional
Definindo prioridades
Explicando histórias para o desenvolvedor
Decidir se ele se encaixa no requisito do usuário final
Decidindo perguntas sobre as histórias

Programador:

Desenvolvedor ou programador deve ser um comunicador eficaz, porque ele é o único canal de comunicação entre a equipe de desenvolvimento, a equipe de testes e o cliente. Um desenvolvedor terá o direito de fazer o seguinte

Realizar conhecimento de requisitos
Produzir trabalho de qualidade
Gerenciamento de abordagem para obter ajuda, que inclui seus supervisores hieráticos e o cliente
Desenvolver e alterar as estimativas fornecidas
Seja responsável

As principais responsabilidades de um programador são

Primeiro, para entender e estimar histórias de usuários.
Segundo, definir e estimar tarefas com base na história do usuário.
Terceiro, para escrever um teste de unidade.
Além disso, para gravar código para passar no teste da unidade.
Posteriormente, para realizar o teste da unidade.
Refatorar
Finalmente, para integrar e tentar melhorar continuamente.

Treinador:

O papel de um treinador é significativo na Extreme Programming. Um treinador garante que todos estejam trabalhando para fazer a programação para uma Extreme Programming. O treinador deveria ter

Comportamento sutil para ser treinador, mesmo que todos os outros estejam em pânico
Excelente conhecimento da Extreme Programming
Natureza útil, porque ele tem que observar todos e, consequentemente, ajudar.

As responsabilidades de um treinador incluem

Observando todas as atividades e certificando-se de que todo o projeto permaneça no caminho certo.
Ele estará ajudando a equipe com qualquer coisa relacionada ao projeto.
Responsável por descobrir as práticas extremas de programação que ajudam a resolver quaisquer problemas no projeto.
Além do acima, ele garante que a equipe seja auto-suficiente.
Ele estará observando todas as equipes silenciosamente.
Se surgir algum problema, ele pode envolver ou formar qualquer equipe destinada a ajudar.

Alguns outros papéis são:

Testador:

O testador será quem fará o teste após a codificação. As responsabilidades de um testador incluem –

Implementando todos os testes funcionais (, exceto o teste de unidade )
Gráficos de todos os resultados
Informar o cliente e o desenvolvedor quando os resultados do teste não forem possíveis

Rastreador:

O rastreador será a pessoa que garantirá que todos estejam fazendo seu trabalho corretamente, incluindo o desenvolvedor. As responsabilidades de um rastreador incluem:

Organizar reuniões do desenvolvedor com os clientes quando e quando necessário.
Monitorando o progresso do desenvolvedor.
Além disso, marcar uma reunião de equipe e agir se as coisas não estiverem indo tão comprometidas.
Entre em contato com o treinador ou o programador para obter ajuda ( se necessário ).

Doomsayer:

Como o nome sugere, o portador será quem ficará de olho em qualquer desastre. Esses desastres podem ser como não cumprindo cronogramas, um bug devido a um pequeno erro, questões de infra-estrutura, ou algo que possa impactar o projeto de qualquer maneira. Em outras palavras, o portador tentará que nada dê errado. As responsabilidades do porteiro incluem:

Prever o risco, se houver
Garantir que todos os envolvidos nos projetos conheçam o risco envolvido
Manter a transparência de qualquer notícia má
Certifique-se de que todos estejam cientes do impacto, urgência e fatores / atividades que serão afetados.

Gerente:

O gerente é quem passará os relatórios e rastreadores para o progresso do processo. Ele será responsável perante o Proprietário de ouro em caso de problemas (O proprietário do ouro é alguém que financiará o projeto pelo lado do cliente). As responsabilidades de um gerente são as seguintes:

Em primeiro lugar, para garantir que a equipe de Desenvolvimento, assim como o cliente, conheça adequadamente a explicação do Jogo de Planejamento.
Em segundo lugar, observar o Jogo de Planejamento e modificar regras, quando e quando necessário.
Terceiro, para garantir a identificação e rastreamento dos defeitos.
Além disso, para verificar o rastreamento do tempo de resolução e do tempo gasto por cada equipe no defeito.
Além disso, obtenha todas as informações sem perturbar o trabalho atual da equipe.
Por fim, participar das reuniões dos clientes e acompanhar todas as informações úteis discutidas na reunião.

Fases do Extreme Programming

Esta figura nos fala sobre o fluxo da Extreme Programming, em Extreme Programming primeiro.

Inicialmente, os requisitos do usuário são coletados em o cartão da história do usuário.
Posteriormente, o cartão de história do usuário faz o planejamento de iteração. Tempo e esforço estimativas acontecer em Planejamento de iteração.
O desenvolvimento sábio da iteração processo começa após o planejamento.
Além disso, a incorporação de novos requisitos acontecem durante o desenvolvimento.
Além disso, quaisquer alterações necessárias durante teste de iteração estão incluídos apenas nesta fase. Além disso, a adição de Novos requisitos do usuário também acontece nesta fase apenas.
Após testes bem-sucedidos de iteração, ele será desenvolvido UAT ( Teste de aceitação do usuário ).
Depois disso, se os defeitos aumentará, em caso de bugs; voltará na fase de desenvolvimento.
Finalmente, se não houver bugs – Lançamento final, Acabamentos de treinamento do usuário e suporte ao produto fornecido.

Foi um fluxo de programação extremo. Isso nos leva à questão de quantas fases existem no fluxo de trabalho de programação extremo? Existem 6 fases no fluxo de processo da Extreme Programming.

Essas 6 fases são as seguintes:

Planejamento:

Identificação de investidores
Reconhecendo as necessidades de infraestrutura
Estabelecendo necessidades de segurança
Contrato de nível de serviço de assinatura ( i. e um documento formal que fala sobre a prestação de vários serviços ) com todas as restrições.

Análise

Obtendo histórias de usuários do cliente
Analisando histórias de usuários
Priorizando histórias
Matrizes para estimativas
Definindo iteração, por exemplo, qual iteração fornece todas as funcionalidades.
Planejamento para equipes de teste e desenvolvimento

Design

Projeto para a primeira iteração
Preparando um caso de teste para cada tarefa
Estrutura de automação de regressão

Execução

O desenvolvedor fará a codificação.
Após a codificação dos acabamentos, o controle de qualidade realiza o teste de unidade.
Depois disso, o teste manual acontece.
Relatório de defeitos gera ( se os defeitos aumentarem ).
A conversão dos casos de teste de regressão Manual para Automação acontece.
Revisão de média iteração
Revisão do final da iteração

Embrulho

Liberação de iteração acontece
O teste de regressão ocorre
O cliente recebe as demos e as revisa
Posteriormente, se necessário, o cliente desenvolve uma nova história após o teste.
Finalmente, após a revisão da iteração, os planos de melhoria serão preparados com base no feedback.

Encerramento

Treinamento para o usuário final fornecido
Lançamento da produção acontece
Além disso, o desempenho de várias verificações acontece se o desenvolvedor tiver cumprido o SLA.
Finalmente, o suporte à produção é fornecido para o produto desenvolvido.

Agora que entendemos a Extreme Programming, vamos analisar as principais diferenças entre a Extreme Programming e o Scrum.

Diferenças entre Extreme Programming e Scrum

Extreme Programming	Scrum
Um sprint é concluído em 2-10 dias	Um sprint leva duas semanas a 6 semanas para ser concluído
A Extreme Programming permite alterações no sprint em qualquer estágio do desenvolvimento	Por outro lado, em Scrum, quando a reunião de planejamento do sprint terminar e a entrega acontecer, nenhuma alteração poderá ocorrer no sprint.
Os desenvolvedores começam a trabalhar de acordo com a prioridade dada pelos usuários.	Os desenvolvedores decidem a prioridade e, posteriormente, começam a se desenvolver.
O XP possui práticas como TDD, Programação de pares, refatoração etc., que são obrigatórias a seguir	Não recomenda nenhuma prática de engenharia

Por que Extreme pode falhar

Na Extreme Programming, o código ganha importância sobre o design. No entanto, é o design que vende o aplicativo e não o código. Quando os programadores se concentram no código e no design difere um pouco, o produto final pode deixar o cliente insatisfeito. Portanto, para evitar isso, os desenvolvedores precisam se concentrar no design e no código.
A Extreme Programming aceita mudanças em qualquer estágio. Por outro lado, essas alterações não são documentadas adequadamente. Por exemplo, se houver alguma falha na implementação, encontrar seu motivo será extremamente difícil devido à falta de documentação. Portanto, é imperativo ter documentação adequada para cada alteração, a fim de evitar erros.
Além disso, a Extreme Programming limita a gama de projetos porque requer interação cara a cara com projetos XP. Isso é ainda mais desafiador de implementar se o cliente se afastar do local de desenvolvimento.

Conclusão

Para concluir, a Extreme Programming é uma estrutura ágil de desenvolvimento de software. Melhora a qualidade e a capacidade de resposta do software aos requisitos em constante mudança do cliente. Além disso, favorece frequentes “libera” para melhorar a produtividade.

Método AgilePgM®

5 de abril de 2023/0 Comentários/em Agile Methods/por coimbra

O AgilePgM® é uma metodologia ágil de gerenciamento de programas que visa fornecer uma abordagem estruturada para a gestão de programas complexos. Essa metodologia é amplamente utilizada em organizações de todos os tamanhos e setores, e é conhecida por sua eficácia em lidar com projetos complexos e em constante mudança.

Para compreender melhor a metodologia AgilePgM®, é importante entender suas fases. O AgilePgM® é dividido em quatro fases principais: pré-início, início, execução e encerramento. Vamos discutir cada uma dessas fases com mais detalhes.

O que é o Método AgilePgM?

O Método AgilePgM é uma metodologia de gestão de projetos que se concentra na flexibilidade, na velocidade e na eficiência. Ele é baseado nos valores e princípios do Agile Project Management (APM) e permite que as equipes trabalhem de forma colaborativa e adaptativa, garantindo assim a entrega de projetos de alta qualidade.

Por que escolher o Método AgilePgM?

Existem muitas razões pelas quais você deve escolher o Método AgilePgM para gerenciar seus projetos. Aqui estão algumas das principais vantagens:

Flexibilidade: o Método AgilePgM permite que as equipes sejam mais flexíveis e adaptáveis a mudanças, o que é especialmente importante em projetos com prazos apertados e orçamentos limitados.
Colaboração: o Método AgilePgM incentiva a colaboração entre as equipes, o que ajuda a garantir que todos estejam alinhados e trabalhando juntos em direção a um objetivo comum.
Entrega de valor: o Método AgilePgM se concentra na entrega de valor ao cliente, o que significa que as equipes trabalham em estreita colaboração com o cliente para garantir que seus requisitos sejam atendidos.
Feedback contínuo: o Método AgilePgM permite que as equipes recebam feedback constante dos stakeholders, o que ajuda a garantir que as decisões estejam alinhadas aos objetivos do projeto.

Como funciona o Método AgilePgM?

O Método AgilePgM é baseado em ciclos de desenvolvimento ágeis, conhecidos como sprints. Cada sprint é uma pequena iteração do projeto, durante a qual as equipes trabalham em uma parte específica do projeto. Ao final de cada sprint, as equipes revisam

o progresso e ajustam sua abordagem de acordo com o feedback dos stakeholders. Isso permite que o projeto evolua de forma contínua e se adapte às mudanças do mercado ou ao feedback do cliente.

O Método AgilePgM também inclui uma abordagem centrada na equipe, o que significa que as equipes são responsáveis por planejar, executar e monitorar o progresso do projeto. Isso incentiva a colaboração e a responsabilidade coletiva, o que ajuda a garantir o sucesso do projeto.

Como implementar o Método AgilePgM em sua empresa?

A implementação do Método AgilePgM em sua empresa pode ser um processo desafiador, mas também pode ser extremamente gratificante. Aqui estão algumas dicas para ajudá-lo a implementar com sucesso o Método AgilePgM em sua empresa:

Treine sua equipe: é importante que todos na sua equipe estejam cientes do Método AgilePgM e saibam como aplicá-lo aos seus projetos.
Defina objetivos claros: antes de começar a implementar o Método AgilePgM, é importante definir claramente os objetivos do projeto e como o Método AgilePgM irá ajudar a alcançá-los.
Envolva todos os stakeholders: é importante envolver todos os stakeholders, incluindo clientes, equipes e gerentes de projetos, para garantir o sucesso da implementação.
Seja paciente: a implementação do Método AgilePgM pode levar tempo, então é importante ser paciente e manter o foco nos objetivos a longo prazo.

Quais são as fases do Método AgilePgM?

Fase 1: Pré-início

A fase de pré-início do AgilePgM® é essencialmente a fase de planejamento. Durante esta fase, a equipe do programa se reúne para identificar os objetivos do programa, os recursos necessários e os riscos potenciais. A equipe também desenvolve um plano detalhado para as fases seguintes do programa, incluindo a fase de início.

Fase 2: Início

Na fase de início, a equipe do programa começa a trabalhar em conjunto para iniciar a implementação do programa. Durante esta fase, a equipe deve estabelecer uma linha de base clara para o programa, desenvolver um plano detalhado para a execução do programa e identificar as métricas-chave que serão usadas para medir o sucesso do programa.

Fase 3: Execução

A fase de execução é onde a maior parte do trabalho do programa acontece. Durante esta fase, a equipe trabalha para implementar o programa de acordo com o plano desenvolvido na fase de início. A equipe também deve monitorar o progresso do programa regularmente e fazer ajustes conforme necessário para garantir que o programa esteja avançando de acordo com as expectativas.

Fase 4: Encerramento

A fase final do AgilePgM® é a fase de encerramento. Durante esta fase, a equipe conclui a implementação do programa e trabalha para garantir que todos os resultados esperados tenham sido alcançados. A equipe também realiza uma revisão do programa para identificar áreas que possam ser melhoradas no futuro.

Em resumo, o AgilePgM® é uma metodologia ágil de gerenciamento de programas que é dividida em quatro fases principais: pré-início, início, execução e encerramento. Cada uma dessas fases é essencial para garantir o sucesso do programa. Se você estiver pensando em implementar o AgilePgM® em sua organização, é importante que você entenda completamente essas fases e como elas se encaixam no processo geral de gerenciamento de programas.

Quais são os papéis do Método AgilePgM?

Para garantir o sucesso do programa, é importante que os membros da equipe tenham papéis claramente definidos e compreendam suas responsabilidades. Neste artigo, vamos discutir os papéis principais no AgilePgM.

Patrocinador do Programa: O patrocinador do programa é responsável por fornecer a visão geral do programa e garantir que ele esteja alinhado com as metas e objetivos da organização. Eles também são responsáveis por fornecer recursos e apoio financeiro para o programa. O patrocinador do programa é o principal defensor do programa e é responsável por garantir que o programa esteja recebendo a atenção necessária de toda a organização.
Gerente do Programa: O gerente do programa é responsável por liderar a equipe do programa e garantir que o programa esteja sendo implementado de acordo com o plano definido. Eles são responsáveis por coordenar a equipe do programa, definir metas e objetivos claros e garantir que o programa esteja avançando de acordo com o cronograma estabelecido. O gerente do programa também é responsável por gerenciar os riscos associados ao programa.
Equipe do Programa: A equipe do programa é responsável pela implementação do programa. Eles trabalham em conjunto para garantir que o programa esteja sendo executado de acordo com o plano estabelecido e que os objetivos do programa estejam sendo alcançados. A equipe do programa pode ser composta por membros de diferentes departamentos da organização ou até mesmo por membros de diferentes organizações.
Grupo de Fornecedores: O grupo de fornecedores é composto por fornecedores que fornecem recursos, tecnologia ou outros serviços necessários para a implementação do programa. Eles trabalham em conjunto com a equipe do programa para garantir que os recursos necessários estejam disponíveis quando necessário e que os serviços sejam entregues de acordo com os padrões acordados.
Stakeholders: Os stakeholders são indivíduos ou grupos que são afetados pelo programa ou que têm interesse no sucesso do programa. Eles podem incluir clientes, fornecedores, reguladores e outros membros da organização. Os stakeholders são importantes para o sucesso do programa e devem ser mantidos informados sobre o progresso do programa e quaisquer mudanças que possam afetá-los.

Em resumo, os papéis principais no AgilePgM incluem o patrocinador do programa, o gerente do programa, a equipe do programa, o grupo de fornecedores e os stakeholders. Cada um desses papéis é essencial para garantir o sucesso do programa e é importante que os membros da equipe entendam suas responsabilidades e trabalhem juntos para alcançar os objetivos do programa.

Quais são os artefatos do Método AgilePgM?

Existem vários artefatos utilizados no framework AgilePgM para garantir o sucesso do programa de transformação. Alguns dos principais artefatos são:

Visão do programa: Este artefato é desenvolvido durante a fase de pré-início e fornece uma visão geral do programa, incluindo seus objetivos, escopo e benefícios esperados. A visão do programa é atualizada regularmente durante o ciclo de vida do programa, para garantir que o programa permaneça alinhado com as necessidades e objetivos do negócio.
Roadmap do programa: O roadmap do programa é um artefato desenvolvido durante a fase de início e fornece uma linha do tempo de alto nível para as entregas do programa. Ele é atualizado regularmente para refletir as mudanças no programa e garantir que o programa continue no caminho certo.
Arquitetura de negócios: A arquitetura de negócios é um artefato desenvolvido durante a fase de início que define a estrutura do negócio e as funções de negócio envolvidas no programa. Ele fornece um guia para a definição dos requisitos e para a implementação das soluções de negócios no programa.
Blueprint da solução: O blueprint da solução é desenvolvido durante a fase de início e fornece uma descrição detalhada da solução proposta para atender aos objetivos do programa. Ele é atualizado regularmente durante o ciclo de vida do programa para refletir as mudanças na solução e garantir que ela atenda aos requisitos do negócio.
Plano de benefícios: O plano de benefícios é um artefato desenvolvido durante a fase de início que descreve os benefícios esperados do programa. Ele é atualizado regularmente para refletir o progresso do programa e garantir que os benefícios sejam realizados.
Plano de gestão de mudanças: O plano de gestão de mudanças é um artefato desenvolvido durante a fase de início que descreve como as mudanças serão gerenciadas no programa. Ele fornece um guia para a identificação, avaliação e implementação de mudanças no programa.
Plano de qualidade: O plano de qualidade é um artefato desenvolvido durante a fase de início que descreve como a qualidade será gerenciada no programa. Ele fornece um guia para a definição dos padrões de qualidade e para a implementação das atividades de garantia e controle de qualidade.
Plano de riscos: O plano de riscos é um artefato desenvolvido durante a fase de início que descreve como os riscos serão gerenciados no programa. Ele fornece um guia para a identificação, avaliação e mitigação de riscos no programa.

Outro artefato importante do AgilePgM é o Blueprint do Programa, que fornece uma visão geral de alto nível do programa e sua estratégia de implementação. Ele descreve a estrutura organizacional do programa, incluindo a designação de papéis e responsabilidades, e identifica as dependências críticas e os riscos associados.

O Blueprint do Programa também inclui um plano de transição, que descreve como o programa será implementado em fases, e um plano de benefícios, que descreve como os benefícios do programa serão medidos e alcançados.

Outro artefato importante é o Plano do Programa, que é um documento detalhado que descreve como o programa será executado. Ele inclui informações sobre o cronograma do programa, recursos necessários, orçamento, riscos e dependências críticas.

O Plano do Programa também define as metas e objetivos do programa e como eles serão alcançados, ele é atualizado regularmente durante a execução do programa para refletir o progresso e as mudanças na estratégia do programa.

Em resumo, o AgilePgM é uma metodologia ágil de gerenciamento de programas que fornece uma estrutura organizacional e processos para ajudar as equipes do programa a planejar, executar e entregar programas complexos com sucesso. Usando uma abordagem colaborativa e iterativa, o AgilePgM ajuda as equipes do programa a se adaptarem rapidamente às mudanças no ambiente de negócios e garantir que os benefícios do programa sejam alcançados de forma eficaz.

Com seus artefatos e processos bem definidos, o AgilePgM pode ajudar as equipes do programa a superar os desafios do gerenciamento de programas e fornecer valor de negócios real.

Comparação entre o AgilePgM, o SAFe Framework e o PgMP do PMI:

Metodologia	Vantagens	Desvantagens
AgilePgM	Abordagem ágil e iterativa que se adapta rapidamente às mudanças no ambiente de negócios Foco na entrega de valor de negócios real Melhora a colaboração e comunicação entre as equipes do programa Fornece processos e artefatos bem definidos para ajudar a planejar e executar o programa de forma eficaz	Pode ser difícil de implementar para equipes inexperientes em metodologias ágeis Pode ser menos adequado para programas altamente regulamentados e controlados
SAFe Framework	Estrutura escalável que suporta programas maiores e mais complexos Foco na gestão de riscos e dependências críticas Abordagem iterativa e colaborativa que melhora a comunicação entre as equipes Fornece processos e artefatos bem definidos para ajudar a planejar e executar o programa de forma eficaz	Pode ser mais burocrático e menos flexível do que o AgilePgM Pode levar mais tempo para implementar do que outras metodologias de gerenciamento de programas
PgMP do PMI	Reconhecido internacionalmente como um padrão de excelência em gerenciamento de programas Foco na governança e gestão de riscos Fornece processos e ferramentas bem definidos para ajudar a planejar e executar o programa de forma eficaz	Pode ser mais adequado para programas altamente regulamentados e controlados, mas menos adequado para programas menos estruturados Pode ser mais difícil de implementar do que outras metodologias de gerenciamento de programas Pode ser mais caro de implementar do que outras metodologias de gerenciamento de programas

Em resumo, cada uma dessas metodologias tem suas próprias vantagens e desvantagens. O AgilePgM é uma abordagem ágil e iterativa que se adapta rapidamente às mudanças no ambiente de negócios, mas pode ser menos adequado para programas altamente regulamentados e controlados.

O SAFe Framework¹ é uma estrutura escalável que suporta programas maiores e mais complexos, mas pode ser mais burocrático e menos flexível do que o AgilePgM. O PgMP do PMI é reconhecido internacionalmente como um padrão de excelência em gerenciamento de programas, mas pode ser mais difícil e caro de implementar do que outras metodologias de gerenciamento de programas.

O que podemos concluir sobre o Método AgilePgM

Concluindo, o AgilePgM é um método ágil que busca promover a entrega contínua de valor ao cliente. Ele traz várias vantagens e desvantagens em comparação com outros frameworks, como podemos ver abaixo:

Vantagens:

Maior foco no valor entregue ao cliente;
Comunicação e colaboração contínuas entre as equipes;
Respostas mais rápidas às mudanças do mercado;
Maior eficiência na entrega de projetos complexos;
Abordagem flexível que pode ser adaptada a diferentes contextos.

Desvantagens:

Maior necessidade de treinamento e capacitação para implementação;
Menor foco em documentação formal e requisitos estáveis;
Maior dependência de comunicação constante entre as equipes;
Potencial falta de clareza nas responsabilidades dos membros da equipe;
Pode não ser a melhor escolha para projetos muito simples ou com requisitos muito estáveis.

Em geral, o AgilePgM é uma abordagem valiosa para equipes que buscam promover a entrega de valor contínuo e que estão dispostas a se adaptar às mudanças do mercado. No entanto, é importante considerar as suas desvantagens e avaliar se essa é a melhor opção para cada contexto específico.

Método AgilePM®

3 de abril de 2023/0 Comentários/em Agile Methods/por coimbra

O AgilePM® é uma metodologia de gerenciamento de projetos ágil que foi desenvolvida para equipes de projetos em empresas tradicionais que precisam de uma abordagem ágil eficaz. Com o AgilePM®, as equipes podem se adaptar rapidamente a mudanças no projeto e entregar valor para o negócio de maneira rápida e eficiente.

A metodologia AgilePM® é baseada em quatro princípios fundamentais: foco no negócio, adaptabilidade, colaboração e gerenciamento de riscos. Esses princípios são reforçados por oito regras que orientam a equipe do projeto a seguir uma abordagem ágil.

O AgilePM® é composto por um conjunto completo de melhores práticas, incluindo um guia para gerenciamento de projetos, um conjunto de templates e uma estrutura de processos para ajudar as equipes a seguir uma abordagem ágil.

Além disso, a metodologia também inclui uma certificação que ajuda a garantir que as equipes estejam capacitadas para aplicar as melhores práticas do AgilePM® em seus projetos.

Ao adotar o AgilePM®, as equipes podem aumentar sua eficiência e melhorar a qualidade de seus projetos, além de aumentar a satisfação do cliente e a capacidade de adaptação à mudanças.

Se você está procurando uma abordagem ágil eficaz para gerenciamento de projetos, o AgilePM® é uma excelente opção.

Quem Criou o AgilePM®?

APMG International¹ é uma organização que fornece certificações para várias metodologias e processos de gerenciamento de projetos, incluindo certificações ágeis.

Aqui estão algumas das certificações ágeis oferecidas pela APMG International:

Certificação	Descrição
AgilePM®	AgilePM é uma metodologia ágil para gerenciamento de projetos. É projetado para equipes de projetos em empresas tradicionais que precisam de uma abordagem ágil eficaz.
AgilePgM®	AgilePgM é uma metodologia ágil para gerenciamento de programas. Ele se concentra em como gerenciar múltiplos projetos ágeis de maneira eficaz, enquanto segue uma abordagem ágil.
AgileBA®	AgileBA é uma certificação para gerentes de negócios e outros profissionais que precisam entender como aplicar a abordagem ágil em seus projetos de negócios.
DSDM Atern	DSDM Atern é uma metodologia ágil para gerenciamento de projetos. Ele se concentra em entregar valor para o negócio de maneira rápida e eficiente.

Quais são os setores que mais utilizam a metodologia?

O AgilePM® é amplamente utilizado em vários setores, e não há informações precisas sobre quais são os 4 setores mais utilizados.

No entanto, alguns dos setores onde a metodologia é amplamente utilizada incluem:

Tecnologia: O AgilePM® é amplamente utilizado no setor de tecnologia para gerenciar projetos de desenvolvimento de software, hardware, sistemas e aplicativos.
Finanças: A metodologia é utilizada no setor financeiro para gerenciar projetos de transformação digital, implantação de sistemas, projetos de compliance, entre outros.
Saúde: O AgilePM® é utilizado em projetos de saúde para gerenciar projetos de desenvolvimento de sistemas de saúde, automação de processos, entre outros.
Indústria: A metodologia é utilizada em projetos industriais para gerenciar projetos de automação, melhoria de processos, implementação de sistemas de gerenciamento de produção, entre outros.

Existem funções, artefatos, cerimônias, princípios, fases e/ou estágios no AgilePM®?

Existem várias funções, artefatos, cerimônias, princípios, fases e estágios no AgilePM®. Aqui estão algumas das principais características do AgilePM®:

Funções

O AgilePM® define funções específicas para cada membro da equipe do projeto.

Cada função tem responsabilidades específicas e trabalha em conjunto para garantir que o projeto seja bem-sucedido.

A função do Gerente de Projeto é a mais importante pois é quem lidera todas as outras funções e garante que o projeto esteja sempre no caminho certo.

Abaixo está uma tabela que descreve as principais funções do AgilePM® de acordo com o guia:

Função	O que faz?
Gerente de Projeto	Responsável por garantir que o projeto seja entregue no prazo, orçamento e qualidade especificados
Equipe de Projeto	Responsável por desenvolver e entregar o produto final
Proprietário do Produto	Responsável por garantir que o projeto atenda às necessidades do negócio
Gerente de Processo	Responsável por garantir que o processo de gerenciamento de projetos seja seguido
Gerente de Qualidade	Responsável por garantir que o projeto atenda aos padrões de qualidade especificados
Gerente de Risco	Responsável por identificar, avaliar e gerenciar os riscos do projeto

Artefatos

O AgilePM® define vários artefatos para ajudar a equipe do projeto a planejar e gerenciar o projeto, incluindo o plano de projeto, o plano de gerenciamento de riscos e o registro de decisões.

Esses artefatos são usados para planejar, acompanhar e controlar o projeto, e são revisados e atualizados regularmente para garantir que o projeto esteja no caminho certo.

Abaixo está uma tabela que descreve os principais artefatos utilizados no AgilePM®:

Artefato	Pra que serve?
Produto Vision	Um documento curto que descreve a visão e os objetivos do projeto
Produto Backlog	Uma lista de itens de trabalho (requisitos, funcionalidades, etc.) a serem implementados no projeto
Produto Escopo	Um documento que descreve os limites e alcance do projeto
Produto Plano	Um documento que descreve como os itens do Produto Backlog serão entregues
Produto Modelo	Um documento que descreve como o produto final será estruturado e funcionará
Produto Dicionário	Um documento que define os termos e definições utilizados no projeto
Produto Guia de Usuário	Um documento que descreve como o produto final será usado
Produto Estimativa	Um documento que descreve o esforço estimado para cada item do Produto Backlog
Produto Cronograma	Um documento que descreve quando cada item do Produto Backlog será entregue
Produto Relatório de Estado	Um documento que descreve o andamento do projeto

Cerimônias

O AgilePM® define várias cerimônias para ajudar a equipe do projeto a seguir uma abordagem ágil, incluindo a cerimônia de planejamento, a cerimônia de revisão e a cerimônia de retrospectiva.

As cerimônias principais do AgilePM® são:

Cerimônia de planejamento – A cerimônia de planejamento é usada para planejar o trabalho a ser realizado durante o ciclo de vida do projeto. É onde são definidos os objetivos, as entregas e os prazos do projeto.
Cerimônia de revisão – A cerimônia de revisão é usada para revisar o progresso do projeto e os resultados do trabalho realizado. É onde são identificados os problemas e as soluções são discutidas.
Cerimônia de retrospectiva – A cerimônia de retrospectiva é usada para avaliar o desempenho da equipe e identificar áreas para melhoria. É onde as lições aprendidas são discutidas e as ações corretivas são planejadas.
Cerimônia de planejamento de risco – A cerimônia de planejamento de risco é usada para identificar e avaliar os riscos do projeto e planejar medidas para gerenciá-los.
Cerimônia de revisão de risco – A cerimônia de revisão de risco é usada para revisar o progresso do gerenciamento dos riscos.

Princípios do AgilePM®

O AgilePM® se baseia em quatro princípios fundamentais:

Os princípios do AgilePM® são:

Foco no negócio – O projeto deve estar alinhado com os objetivos e necessidades do negócio, entregando valor para o negócio de maneira rápida e eficiente.
Adaptabilidade – O projeto deve ser adaptável às mudanças, permitindo que as equipes se adaptem rapidamente a mudanças no projeto e no ambiente de negócios.
Colaboração – O projeto deve ser baseado em colaboração e comunicação eficaz entre todos os membros da equipe, incluindo o cliente e os interessados.
Gerenciamento de riscos – O projeto deve ser gerenciado de forma a identificar e gerenciar riscos de maneira proativa, para garantir o sucesso do projeto.

Fases do AgilePM®

O AgilePM® é dividido em cinco fases: planejamento, elaboração, construção, transição e operação. Cada fase tem objetivos e entregas específicos.

As fases do AgilePM® são:

Visualização: É a fase inicial do AgilePM, onde membros-chave colaboram para criar a visão do projeto, definir objetivos, identificar recursos e planejar a entrega. Aqui, se busca compreender a visão do cliente e suas expectativas.
Especulação: Nesta fase, os requisitos são traduzidos em uma visão de produto e um plano de liberação de alto nível é apresentado. A equipe apresenta entendimento inicial dos requisitos e prioriza-os, além de determinar um plano baseado em marcos.
Exploração: Aqui, a equipe explora alternativas para atender aos requisitos do projeto, faz entregas e testes. O desenvolvimento é iterativo e trabalha-se com histórias do produto para cada iteração. A fase é conectada com a fase de adaptação, onde a equipe aprende e se adapta com base nas experiências e no feedback do cliente.
Adaptação: Na fase de adaptação, a equipe avalia o desempenho, analisa o resultado da execução e se adapta aos requisitos dos clientes, se necessário, mudando o processo ou objetivos do projeto. A equipe é capaz de reconhecer o feedback e se adaptar à situação.
Entrega: Finalmente, a fase de entrega é onde o projeto é concluído e entregue ao cliente, tendo sido gerenciado ao longo do ciclo de vida do projeto de maneira iterativa e eficaz.

Estágios do AgilePM®

O AgilePM® é dividido em seis estágios: início, planejamento, elaboração, construção, transição e operação. Cada estágio tem objetivos e entregas específicos.

Início – O estágio inicial é onde o projeto é concebido e o case de negócio é criado. É onde se faz a análise de viabilidade e se determina se o projeto é viável e deve ser iniciado.
Planejamento – O estágio de planejamento é onde o projeto é planejado em detalhes. Neste estágio, é criado o plano de projeto e o plano de gerenciamento de riscos, além de definir as entregas e os objetivos do projeto.
Elaboração – O estágio de elaboração é onde o projeto é desenvolvido e detalhado. Neste estágio, são definidos os requisitos do projeto e é criado o design do sistema.
Construção – O estágio de construção é onde o projeto é construído e testado. Neste estágio, o projeto é implementado e testado para garantir que ele atenda aos requisitos.
Transição – O estágio de transição é onde o projeto é entregue e implementado. Neste estágio, o projeto é entregue ao cliente e implementado no ambiente de operação.

Cada uma dessas características são fundamentais para o uso da metodologia AgilePM® e para seguir as boas práticas e regras estabelecidas para garantir uma abordagem ágil eficaz na gestão de projetos.

Existem Certificações e qual formato da prova e o valor?

A prova para obtenção da certificação AgilePM® é composta por duas partes: uma prova teórica e uma avaliação prática. A prova teórica é um exame escrito que testa os conhecimentos teóricos da metodologia AgilePM®, enquanto a avaliação prática é uma avaliação do conhecimento prático da metodologia, através de uma análise de casos de estudo e uma entrevista.

O valor e formato da prova pode variar dependendo da localização e do provedor de treinamento, mas geralmente o custo para a certificação é de cerca de $ 600 a $ 1000.

A prova teórica é geralmente realizada em um ambiente de sala de aula com outros candidatos, enquanto a avaliação prática é realizada individualmente e pode ser realizada presencialmente ou remotamente.

É importante notar que a certificação AgilePM® tem validade de 2 anos, após esse período é necessário realizar a certificação de manutenção para renovar a certificação.

Além disso, é recomendado que os indivíduos mantenham-se atualizados com as novas evoluções da metodologia e participem de treinamentos continuados.

Qual é o Guia (ou guias) utilizados para a certificação AgilePM®?

A certificação AgilePM® é baseada em um guia completo de melhores práticas, chamado de Guia de Projetos Ágeis (Agile Project Framework – APF).

Este guia inclui informações sobre todos os aspectos da metodologia AgilePM®, incluindo princípios, regras, funções, artefatos, cerimônias e estágios.

Ele é projetado para ajudar as equipes a seguir uma abordagem ágil eficaz e a entregar valor para o negócio de maneira rápida e eficiente.

Além do APF, outros guias e ferramentas são utilizados na certificação AgilePM®, incluindo:

O Guia de Gerenciamento de Riscos (Risk Management Guide – RMG)
O Guia de Gerenciamento de Projetos (Project Management Guide – PMG)
Os templates para os artefatos utilizados na metodologia, como o plano de projeto, o plano de gerenciamento de riscos e o registro de decisões.

Esses guias e ferramentas são desenvolvidos pela APMG International, a organização responsável pela certificação AgilePM® e são fornecidos aos candidatos durante o treinamento para a certificação.

Eles são usados durante as aulas e são recursos valiosos para consulta após a certificação, para ajudar os indivíduos a se manterem atualizados com as melhores práticas e a aplicar a metodologia em projetos futuros.

Vantagens e desvantagens do AgilePM®

O AgilePM® é uma metodologia ágil para gerenciamento de projetos de negócios que se baseia em princípios, regras, funções, artefatos, cerimônias e estágios.

Ele é projetado para ajudar as equipes a seguir uma abordagem ágil eficaz e a entregar valor para o negócio de maneira rápida e eficiente.

Uma das principais vantagens do AgilePM® é que ele permite que as equipes se adaptem rapidamente às mudanças no projeto e no ambiente de negócios, garantindo que o projeto esteja sempre alinhado com os objetivos e necessidades do negócio.

Ele também promove a colaboração e a comunicação eficaz entre todos os membros da equipe, incluindo o cliente e os interessados.

Prós	Contras
Permite adaptação rápida às mudanças	Pode ser complexo de implementar
Promove colaboração e comunicação eficaz	Pode requerer alta disciplina e comprometimento

No entanto, uma desvantagem do AgilePM® é que ele pode ser complexo de implementar e requer um alto nível de disciplina e comprometimento da equipe para seguir as regras e as cerimônias estabelecidas. Além disso, pode ser difícil de aplicar em projetos de grande escala e em setores regulamentados.

Metodologia	Scrum	PMI
AgilePM®	– Possui um processo estruturado, proporcionando uma maior previsibilidade e controle dos projetos. – Possui uma ênfase maior na gestão de riscos e qualidade, garantindo que o projeto atenda às necessidades do negócio. – Possui uma abordagem ágil e flexível, possibilitando adaptações rápidas a mudanças no projeto.	– Pode ser considerado menos ágil do que outras metodologias, como o Scrum. – Pode ser mais caro e requerer mais recursos para implementar do que outras metodologias. – Pode ser mais complexo e requerer mais tempo para aprender do que outras metodologias.
Scrum	– Possui uma abordagem altamente ágil, permitindo adaptações rápidas a mudanças no projeto – Possui uma ênfase maior na colaboração e autonomia da equipe, garantindo um alto desempenho. – Possui uma abordagem incremental, permitindo entregas frequentes e valor para o cliente.	– Pode ser menos estruturado do que outras metodologias, como o AgilePM®, o que pode afetar a previsibilidade e o controle do projeto. – Pode ser menos adequado para projetos grandes e complexos. – Pode ser mais difícil de implementar em organizações que não possuem uma cultura ágil.
PMI	– Possui uma abordagem estruturada, proporcionando uma maior previsibilidade e controle dos projetos. – Possui uma grande quantidade de recursos e ferramentas disponíveis para gerenciamento de projetos. – Possui uma grande quantidade de profissionais certificados, garantindo a qualidade do gerenciamento de projetos.	– Pode ser menos ágil do que outras metodologias, como o Scrum. – Pode ser mais caro e requerer mais recursos para implementar do que outras metodologias. – Pode ser mais complexo e requerer mais tempo para aprender do que outras metodologias.

Cada metodologia possui suas próprias vantagens e desvantagens, e a escolha da metodologia a ser utilizada depende das necessidades e características.

Conclusão

Podemos concluir que o AgilePM® é uma metodologia ágil que tem como objetivo ajudar as equipes a entregar projetos de maneira eficiente e eficaz.

Ele se baseia em princípios ágeis, como colaboração, flexibilidade e adaptabilidade, e é composto por fases, cerimônias, artefatos e funções específicas.

É indicado para projetos com alto nível de incerteza e risco e é utilizado em vários setores, como finanças, tecnologia, construção e saúde.

A certificação AgilePM® é oferecida pela APMG International e é uma forma de comprovar a compreensão e a aplicação dessa metodologia.

Siga a Projetos e TI em seu site e nas redes sociais para ter acesso constante às novidades em métodos ágeis e gerenciamento de projetos.

Método 4DX – Four Disciplines of Execution

27 de março de 2023/2 Comentários/em Agile Methods/por coimbra

O Método 4DX é uma abordagem para gerenciamento de tempo e execução de projetos que se concentra em quatro disciplinas principais: foco vencedor, métricas claras, comprometimento pessoal e equipes de alto desempenho. Foi desenvolvido pelos autores Sean Covey, Chris McChesney e Jim Huling e tem sido amplamente utilizado em muitas empresas ao redor do mundo.

No método 4DX, existem três papéis principais: Líder de Equipe, Executor e Líder de Meta Extremamente Importante (WIG). O líder da equipe é responsável por liderar e gerenciar a equipe, enquanto o executor é responsável por implementar as tarefas e atividades necessárias para atingir as metas. O líder de metas extremamente importantes (WIG) é responsável por definir e gerenciar as metas de alto nível da organização.

O método 4DX também inclui quatro artefatos principais: o mapa de execução, o log de execução, o log de escritório e o caderno de campo. Esses artefatos são usados para acompanhar o progresso em relação às metas e manter o foco nas tarefas em mãos.

Há também quatro cerimônias principais no método 4DX: a reunião de abertura, a reunião de desenvolvimento, a reunião de encerramento e a reunião de alinhamento. Essas cerimônias são realizadas regularmente para revisar o progresso em relação às metas e discutir quaisquer ajustes necessários.

Em suma, o método 4DX é uma abordagem eficaz de gerenciamento de tempo e execução de projetos que visa manter a organização focada em metas de alto nível e garantir que a equipe esteja alinhada e comprometida para alcançá-las. Ele inclui três papéis principais, quatro artefatos e quatro cerimônias que ajudam você a manter o foco e garantir o progresso em direção às metas estabelecidas.

Além disso, o método 4DX segue certos fundamentos, como manter o foco em vencer, definir métricas claras e formar equipes de alto desempenho, para garantir o sucesso a longo prazo. Se você está procurando uma abordagem eficiente para gerenciar o tempo e a execução do projeto, o método 4DX pode ser uma opção interessante a ser considerada.

O Método 4DX é uma abordagem para gerenciamento de tempo e execução de projetos com base em quatro disciplinas principais: Concentrar-se no que é mais importante, Agir sobre as principais medidas, Manter um Painel de Avaliação Convincente e Criar cadência de responsabilidade. Essa abordagem foi projetada para ajudar as empresas a atingir metas de alto nível, mantendo um alto nível de eficiência e produtividade.

As quatro disciplinas do método 4DX são:

Disciplina 1: Concentre-se no extremamente importante

Esta é a disciplina de foco. A execução excepcional começa com o estreitamento do foco —, identificando claramente o que deve ser feito. Caso contrário, nada mais que você consiga realmente importa muito.

Disciplina 2: Agir sobre as medidas principais

Esta é a disciplina de alavancagem. 80% dos seus resultados virão de 20% das suas atividades; você está se concentrando nos corretos? A disciplina 2 é baseada no princípio de que nem todas as ações são criadas da mesma forma. Identifique e atue nas atividades com a maior alavancagem.

Disciplina 3: Mantenha um Painel de Avaliação Convincente

Esta é a disciplina de engajamento. Pessoas e equipes jogam de maneira diferente quando mantêm a pontuação, e o tipo certo de placar motiva os jogadores a vencer.

Disciplina 4: Crie um cadência de responsabilidade

Esta é a disciplina de prestação de contas. Cada equipe se envolve em um processo semanal simples que destaca sucessos, analisa falhas e corrige os cursos conforme necessário, criando o melhor sistema de gerenciamento de desempenho.

Quem criou 4DX?

O método 4DX foi desenvolvido pelos autores Sean Covey, Chris McChesney e Jim Huling. Eles são os autores de The 4 Disciplines of Execution: Achieving Your Wildly Important Goals¹, que foi publicado pela primeira vez em 2012 e se tornou um best-seller. O livro descreve o método 4DX em detalhes e fornece exemplos de como pode ser aplicado em uma variedade de contextos de negócios. O método 4DX é amplamente utilizado em muitas empresas ao redor do mundo e tem sido apontado como um fator importante para o sucesso de muitas organizações.

Qual foi o primeiro uso conhecido de 4DX

O método 4DX foi desenvolvido e publicado pela primeira vez em 2012 pelos autores Sean Covey, Chris McChesney e Jim Huling. Desde então, tem sido amplamente utilizado em muitas empresas ao redor do mundo como uma abordagem eficaz para gerenciamento de tempo e execução de projetos. É possível que o método tenha sido usado antes de 2012, mas essa informação não está disponível.

Qual porcentagem de equipes ágeis está usando o 4DX globalmente?

O método 4DX é amplamente utilizado em muitas empresas ao redor do mundo, mas não tenho dados específicos sobre a utilização do método por times ágeis. Além disso, o método 4DX pode ser usado em qualquer tipo de equipe ou organização, não apenas equipes ágeis.

Onde posso encontrar mais informações sobre o método 4DX?

O livro “As 4 Disciplinas da Execução: Atingindo Seus Objetivos Mais Importantes” é a principal fonte de informação sobre o método 4DX. Escrito pelos autores do método Sean Covey, Chris McChesney e Jim Huling, o livro fornece uma visão geral detalhada do método e inclui exemplos de como ele pode ser aplicado em diversos contextos de negócios.

Além disso, o site da FranklinCovey ² possui informações adicionais sobre o método 4DX e oferece treinamento e ferramentas para ajudar as empresas a implementar o método. Eles também oferecem webinars e eventos regulares sobre o método 4DX e outros tópicos relacionados ao gerenciamento de tempo e produtividade.

Quais são os papéis dentro da metodologia?

No método 4DX, existem três papéis principais: Líder de Equipe, Executor e Líder de Meta Extremamente Importante (WIG).

O Líder da equipe é responsável por liderar e gerenciar a equipe e garantir que todos estejam alinhados com as metas e objetivos da organização. Eles são responsáveis por criar um ambiente de trabalho colaborativo e solidário e promover o alto desempenho.
O Executor é responsável por implementar as tarefas e atividades necessárias para atingir os objetivos da equipe. Eles são responsáveis por garantir que as tarefas sejam concluídas de forma eficaz e eficiente e por manter o foco no trabalho em questão.
O Líder de Metas Criticamente Importantes (WIG) é responsável por definir e gerenciar as metas de alto nível da organização, conhecidas como Metas Criticamente Importantes (WIGs). Eles são responsáveis por garantir que a equipe esteja alinhada com esses objetivos e manter o foco neles ao longo do tempo.

Estas são as três principais funções do método 4DX, mas é importante lembrar que todos os membros da equipe são responsáveis por contribuir para o sucesso da organização e alcançar os objetivos estabelecidos.

O que são os Artefatos que o método 4DX utiliza?

No método 4DX, existem quatro artefatos principais: o mapa de execução, o log de execução, o log de escritório e o caderno de campo.

O Mapa de Execução é um gráfico que ajuda a visualizar as metas e objetivos da equipe e como eles se encaixam na estratégia geral da organização. Inclui os objetivos de alto nível da organização, conhecidos como Objetivos Criticamente Importantes (WIGs), bem como as medidas de desempenho usadas para acompanhar o progresso.
O Registro de Execução é um registro diário das atividades da equipe e do progresso em relação às metas estabelecidas. Ele inclui uma lista de tarefas e uma avaliação diária do progresso em relação às metas de alto nível.
O Diário de escritório é um registro dos compromissos e responsabilidades pessoais de cada membro da equipe. Isso ajuda a garantir que os membros da equipe estejam alinhados com as metas da equipe e da organização e cumpram suas responsabilidades pessoais.
O Caderno de campo é um registro das reuniões e discussões da equipe. Inclui notas sobre o progresso em relação aos objetivos, problemas encontrados e soluções propostas.

Estes são os quatro principais artefatos do método 4DX, mas outros artefatos podem ser utilizados dependendo das necessidades da equipe e da organização.

Quais são as cerimônias?

No método 4DX, existem quatro cerimônias principais: a reunião de abertura, a reunião de desenvolvimento, a reunião de encerramento e a reunião de alinhamento.

A reunião inicial é uma reunião semanal em que a equipe analisa o progresso em relação às metas de alto nível da organização, conhecidas como Metas Criticamente Importantes (WIGs). Eles também revisam o roteiro de execução e discutem quaisquer problemas ou desafios encontrados.
A reunião de discussão é uma reunião diária em que a equipe analisa o progresso em relação às tarefas e atividades diárias e discute quaisquer problemas ou desafios encontrados.
A reunião de encerramento é uma reunião semanal em que a equipe analisa o progresso em relação às metas de alto nível da organização e discute quaisquer problemas ou desafios encontrados. Eles também revisam o roteiro de execução e discutem os ajustes necessários.
A reunião de alinhamento é uma reunião mensal em que a equipe analisa o progresso em relação às metas de alto nível da organização e discute quaisquer problemas ou desafios encontrados. Eles também discutem os ajustes necessários no Mapa de Execução e Plano de Ação.

Estas são as quatro cerimônias principais do método 4DX, mas outras cerimônias podem ser realizadas dependendo das necessidades da equipe e da organização.

Quais são os princípios do 4dx?

Sim, para utilizar o método 4DX existem alguns princípios fundamentais que devem ser seguidos:

Concentre-se em vencer: mantenha o foco nas metas de alto nível da organização, conhecidas como Metas Criticamente Importantes (WIGs), e não deixe que outras tarefas ou distrações afetem o progresso.
Métricas claras: defina métricas claras para acompanhar o progresso e determinar o sucesso.
Compromisso Pessoal: Envolver toda a equipa no processo de definição de objetivos e comprometer-se a alcançá-los.
Equipes de alto desempenho: crie um ambiente de trabalho colaborativo e solidário que promova o alto desempenho.
Gestão do tempo: gerencie seu tempo de forma eficaz e eficiente, concentrando-se nas tarefas mais importantes.
Execução diária: Ter uma execução diária consistente para atingir as metas ao longo do tempo.
Comunicação Eficaz: Manter uma comunicação clara e eficaz entre todos os membros da equipe e garantir que todos estejam alinhados com as metas e objetivos.

Estes são alguns dos princípios fundamentais que devem ser seguidos no método 4DX. É importante documentar esses princípios e consultá-los regularmente para garantir que a equipe esteja alinhada e focada em atingir as metas estabelecidas.

O 4DX tem fases ou etapas?

O método 4DX não tem uma sequência definida de fases ou passos. Em vez disso, é uma abordagem contínua que visa manter o foco nas metas de alto nível da organização, conhecidas como Objetivos Criticamente Importantes (WIGs), e garantir que a equipe esteja alinhada e comprometida em alcançá-los.

No entanto, alguns elementos chave podem ser considerados parte de um ciclo de execução no método 4DX:

Defina metas: defina metas claras e mensuráveis e mantenha o foco nelas ao longo do tempo.
Acompanhe o progresso: defina métricas precisas para acompanhar o progresso e determinar o sucesso.
Ajustar curso: Revise o progresso em relação às metas e faça ajustes no plano de ação, se necessário.

Estes elementos podem ser considerados parte de um ciclo de execução no método 4DX, mas não há uma sequência definida de fases ou passos. O objetivo é manter o foco em metas de alto nível e garantir que a equipe esteja alinhada e comprometida em alcançá-las.

Quais são os desafios para implementar o 4DX?

Aqui estão alguns dos desafios comuns que as equipes podem enfrentar ao tentar implementar o método 4DX.

No método 4DX, existem quatro desafios comuns que as equipes podem enfrentar ao tentar implementar o método:

Falta de foco: pode ser difícil manter o foco nas metas organizacionais de alto nível, conhecidas como Metas Criticamente Importantes (WIGs), especialmente se houver muitas tarefas e distrações competindo para atrair a atenção.
Dificuldade em estabelecer métricas claras: definir métricas específicas para acompanhar o progresso e determinar o sucesso pode ser um desafio, principalmente se a equipe não tiver experiência em estabelecer metas mensuráveis.
Falta de comprometimento pessoal: Envolver toda a equipe no processo de definição de metas e comprometimento para alcançá-las pode ser difícil, principalmente se houver diferenças de opinião ou falta de comunicação clara.
Falta de equipes de alto desempenho: pode ser difícil criar um ambiente de trabalho colaborativo e solidário que promova o alto desempenho, especialmente se houver conflitos ou problemas de liderança.

É importante reconhecer esses desafios e trabalhar para superá-los para garantir o sucesso na consecução dos objetivos organizacionais.

O que concluímos sobre o Método 4DX

Concluindo, o Método 4DX é uma abordagem eficaz para gerenciar o tempo e a execução de projetos, mas pode apresentar alguns desafios, como manter o foco nas metas de alto nível da organização, estabelecer medidas claras e criar equipes de alta performance. No entanto, se esses desafios forem superados, o Método 4DX pode ajudar a manter o foco nas metas e garantir o sucesso na execução de projetos.

Alguns dos benefícios incluem o envolvimento de toda a equipe no processo de definição de metas e o uso de artefatos e cerimônias para acompanhar o progresso e fazer ajustes se necessário. Se você está procurando uma abordagem eficaz para avaliar o progresso em relação às metas e garantir a execução bem-sucedida de projetos, o Método 4DX pode ser uma opção valiosa a considerar.

Lembre-se que a Projetos e TI vai sempre trazer novidades sobre métodos ágeis e de gestão de projetos.

Arquivo para Tag: agile methods

O que é o Extreme Programming?

Por que é chamado de “ Extreme? ”

XP é um dos métodos mais populares. É leve porque

Quando usar a Extreme Programming:

Valores, Princípios e Práticas:

Valores

1. Comunicação

2. Simplicidade

3. Feedback

4. Coragem

5. Respeito

Princípios

1. Feedback rápido:

2. Suponha simplicidade:

3. Mudança incremental:

4. Abraçando a alteração:

5. Trabalho de qualidade:

Práticas

As Práticas do Extreme Programming

1. Feedback em escala fina

2. Processo Contínuo

3. Entendimento compartilhado −

4. Bem-estar do desenvolvedor / programador −

Artefatos XP

Cartões de história

Cartões de tarefas

Testes de aceitação:

Estimativas:

Design

Casos de teste de unidade

Registros de comunicação do cliente e do desenvolvedor:

Quais são as diferentes atividades da Extreme Programming?

Codificação

Teste:

Ouvindo:

Projetando:

Fases de programação

Planejamento de lançamento

Planejamento de liberação – Fase de exploração:

Fase de compromisso do planejamento de lançamento:

Fase de direção do planejamento de liberação:

Planejamento de Iteração:

Planejamento de iteração – Fase de exploração:

Planejamento de iteração – fase de compromisso:

Planejamento de iteração – Fase de direção:

Implementação:

Funções e responsabilidades extremas:

Cliente:

Programador:

Treinador:

Alguns outros papéis são:

Testador:

Rastreador:

Doomsayer:

Gerente:

Fases do Extreme Programming

Planejamento:

Análise

Design

Execução

Embrulho

Encerramento

Diferenças entre Extreme Programming e Scrum

Por que Extreme pode falhar

Conclusão

O que é o Método AgilePgM?

Por que escolher o Método AgilePgM?

Como funciona o Método AgilePgM?

Como implementar o Método AgilePgM em sua empresa?

Quais são as fases do Método AgilePgM?

Fase 1: Pré-início

Fase 2: Início

Fase 3: Execução

Fase 4: Encerramento

Quais são os papéis do Método AgilePgM?

Quais são os artefatos do Método AgilePgM?

Comparação entre o AgilePgM, o SAFe Framework e o PgMP do PMI:

O que podemos concluir sobre o Método AgilePgM

Vantagens: