Método XP (Extreme Programming)

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.

Sumário

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.

XP Praticas

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 XPValores

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

XP Práticas

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:

  1. O jogo de planejamento ( histórias de usuários )
  2. Pequenos lançamentos
  3. Metáfora
  4. Design simples
  5. Teste
  6. Refatoração
  7. Programação de pares
  8. Propriedade coletiva
  9. Integração Contínua
  10. Semana de trabalho de 40 horas
  11. Cliente no local
  12. Codificação

XP Atividades

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

XP Fases

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.

Criando boas metas de Sprint

Se temos um Sprint Backlog, essencialmente o plano para o Sprint, por que precisamos de uma meta da Sprint? 

Essa é a pergunta que recebo várias e várias vezes em treinamentos e no trabalho. Lembre-se de que o desenvolvimento de software é complexo e não podemos planejar perfeitamente o desconhecido. Quando criamos o Sprint Backlog, existe a expectativa de que mais trabalho surja durante a Sprint. O escopo pode precisar ser renegociado. A Meta Sprint ajuda a focar em um objetivo que queremos alcançar e permite a flexibilidade para negociar o trabalho para atingir esse objetivo.

Criar um objetivo claro da Sprint pode ser um desafio para os times Scrum. Aqui estão quatro problemas comuns com as metas da Sprint e algumas dicas para melhorá-las.

1 – A Meta da Sprint é muito grande.

Meta da sprint é grande

 

Quando temos metas de Sprint compostas (por exemplo, atingir X e Y e Z), estamos- dividindo o foco e não permitindo muita flexibilidade.- – Aqui estão algumas razões pelas quais acabamos nessa situação e sugestões de como pensar de maneira diferente.

  • Estamos trabalhando em vários projetos ou iniciativas não relacionadas. – Quando estamos ordenando o Product Backlog e fazendo o Sprint Planning, considere tanto a coesão do trabalho quanto a iniciativa de prioridade máxima (singular).- Quando colocamos muito em uma Sprint, estamos nos preparando para o fracasso. Acabamos com o desperdício devido í  mudança de contexto e pouco espaço para o trabalho emergir í  medida que aprendemos.- Se parecer impossível escolher um, talvez nossas Sprints sejam muito longas e não ofereçam ao negí³cio a oportunidade de mudar o foco e a direção com a frequência suficiente.
  • Tentamos abranger todos os itens do Product Backlog (PBI).- Quando dou cursos de Scrum, muitas vezes ouço que as equipes consideram sua Meta da Sprint como “completar todos os PBIs”. Isso é o equivalente a não ter uma meta da sprint. Isso parece um pouco preguiçoso.- Sim, chegar a bons objetivos de sprint é difícil.- Aproveite o tempo para fazê-lo.
  • Achamos que a equipe pode não trabalhar tanto se o desafio não for grande o suficiente.- Esse sentimento me lembra um pouco de comando e controle.- Para que equipes auto organizadas- e capacitadas sejam eficazes, devemos acreditar que as pessoas estão comprometidas em fazer o melhor.- Se a meta da Sprint for atingida antes do final da Sprint, os profissionais descobrirão o que mais podem fazer para contribuir de maneira significativa. Isso pode significar entregar mais funcionalidade.- Isso pode significar trabalhar em itens de melhoria contínua.- Confie neles para descobrir.

2 – O objetivo da Sprint é vago.

 

Quando chegamos ao final de um Sprint, toda a equipe está de acordo se o objetivo da Sprint foi ou não alcançado? Caso contrário, o objetivo da Sprint pode ser muito vago. Aqui estão algumas dicas para criar metas de sprint mais claras.

  • Durante o planejamento da Sprint, pergunte “como saberemos se alcançamos a meta da Sprint?” – Se tivermos respostas diferentes ou olhares confusos do Product Owner ou de qualquer membro da equipe de desenvolvimento, precisamos de mais discussão e refinamento da Meta da Sprin.
  • Torne o Objetivo da Sprint mensurável. – Isso ajuda a reduzir a subjetividade, ou opinião.
  • Durante o Planejamento do Sprint, use uma técnica de consenso para- confirmar a compreensão e o comprometimento de todos com o Objetivo da Sprint.- Essa também é uma maneira de ajudar a- incentivar a propriedade da equipe- .

Aqui estío alguns exemplos de objetivos de sprint pouco claros e modificações para torná-los mais claros.

Objetivo de sprint pouco claro Objetivo de Sprint mais claro
Melhore a funcionalidade do carrinho de compras. Simplifique o processo de compra para permitir um aumento nas taxas de conversão.
Melhorar o desempenho. Aumente o tempo de carregamento da página em 10%.
Novo segmento de mercado a bordo. Permita que um novo segmento de mercado adquira o Serviço Y.

3 – A equipe não presta atenção ao objetivo do Sprint durante o Sprint.

Distração na sprint

 

Lembre-se de que temos que realmente prestar atenção a ele para ajudar a fornecer foco.

  • Torne-o visível.
    Escreva a Meta da Sprint no Scrum Board ou prí³ximo dele. Faça-o grande.
    – Use uma cor ou borda que se destaque.
  • Ensine a equipe a- falar sobre o progresso em direção a Meta da Sprint na Reunião Diária.
    – Os membros da equipe de desenvolvimento geralmente fornecem atualizações sobre os itens do backlog do produto em que estão trabalhando, e o objetivo do Sprint nunca é discutido.
    – Faça parte do Daily Scrum.
    – O facilitador pode perguntar í  equipe no final da Reunião Diária como eles se sentem sobre a probabilidade de atingir a Meta da Sprint, se são necessários ajustes no plano diário para reorientar ou se o escopo precisa ser negociado.
    – Isso pode ajudar a melhorar a colaboração da equipe .
  • Faça da Meta da Sprint uma medida de equipe e mantenha-a visível no espaço da equipe.
    – Semelhante à  forma como uma equipe pode rastrear sua velocidade ou cobertura de teste automatizado ao longo do tempo, uma equipe também pode rastrear a conquista da meta do Sprint ao longo do tempo.
    – Manter essas informações visíveis ajuda a equipe a pensar sobre elas.
    – Dados históricos e tendências podem ser usados  para discussão na Sprint Retrospective.
  • Uma palavra de cautela: atingir uma meta de Sprint é passar/falhar.
    – Não existe 85% alcançado.

4 – A Meta da Sprint não parece significativa.

Uma meta de sprint deve fornecer propí³sito.- Isso ajuda a equipe a saber por que eles estão construindo o incremento.- As pessoas querem fazer um trabalho significativo.- As pessoas querem fazer um trabalho que tenha impacto.- Este é um driver para a- motivação intrínseca.- Vamos pensar em maneiras de tornar as metas da Sprint mais significativas para as pessoas que estão construindo o produto.

  • Torne-a focada no negí³cio ou no usuário quando possível. – O que um usuário poderá fazer quando implementarmos esse recurso?- O que uma área de negí³cio poderá alcançar quando implementarmos uma melhoria?
  • Concentre-se em testar suposições de negí³cios e obter feedback.- Muitas vezes não sabemos o que os usuários realmente precisam ou estão dispostos a fazer (porque nem os usuários sabem).
    – Um Product Owner precisa de feedback antecipado para testar suposições sobre valor para os usuários.
  • Torná-la focada na redução do risco.- Provar uma tecnologia ou design é uma parte importante da redução de riscos.- Se soubermos que uma tecnologia não vai atender í s nossas necessidades de desempenho, segurança ou escalabilidade, podemos mudar de direção.- Quanto mais cedo mudarmos de direção, mais barato será o custo da mudança.
Em resumo, uma boa Meta da Sprint pode ajudar uma equipe a se concentrar e ter a flexibilidade de criar um Incremento Feito ao final de uma Sprint.
Uma boa Meta da Sprint ajuda uma equipe a entender o propósito e o impacto do trabalho que está fazendo, o que é um fator determinante para a motivação intrínseca. Roman Pichler fornece um modelo útil- para criar metas de sprint eficazes– .

Se você acha que um desses problemas está afetando sua equipe, escolha uma técnica e experimente, entre em contato e comente aqui!

Planejamento de sprints de trás para a frente?

Sprints, aqui está o problema: muitas equipes planejam suas sprints completamente de trás pra frente. Isso não é totalmente inesperado.

Guia do Scrum é bastante escasso quando se trata do tópico de criar a meta para as sprints, basicamente afirmando que o objetivo da sprint é a meta do sprint, e serve para informar, inspirar e orientar a equipe com relação ao que mesmo explicando por que a equipe está trabalhando no produto.

No entanto, tudo isso parece um pouco autorreferencial – a meta é o que eles estão trabalhando e o que a equipe está trabalhando os traz para o objetivo? – Isso não parece fornecer muita orientação para a equipe.

Não é de surpreender que muitas equipes consigam atingir seus objetivos de maneira ascendente. A equipe examina o que está no topo da lista de pendências, com talvez um pouco de acréscimo do Product Owner e de outras partes interessadas, e estabelece o objetivo ao compilar as histórias e tarefas adicionadas ao sprint.

Para um exemplo simples, imagine que eu quero estar preparado para uma festa que estou organizando hoje à noite. Meu backlog pessoal pode conter tarefas como:

  1. Pegar gelo;
  2. Fazer lanches;
  3. Selecionar músicas; e
  4. Aspirar o tapete.

Acrescento essas quatro tarefas à minha lista diária e decido que meu objetivo é pegar gelo e comida, limpar a casa e escolher algumas músicas.

Fácil de entender e parece muito com uma lista de tarefas simples. E, no entanto, eu posso fazer todas essas coisas e ainda não estar pronto para a festa.

É assim que parece um objetivo de baixo para cima – uma lista de tarefas que, se concluídas, significa que podemos verificar tudo e encerrar o dia – Isso é inútil quando se trata de saber se você está fazendo as coisas corretas; não é uma maneira eficaz de inspirar uma equipe; e não oferece muita flexibilidade caso a situação mude ou novas informações sejam descobertas.

Essas são as razões pelas quais a missão para os sprints devem ser criada de cima para baixo – determinando como seria uma iteração bem-sucedida (“Estou preparado para a festa”), e não como a agregação das tarefas envolvidas.

Deve incluir todos os itens que já são conhecidos e vários que não são. Vejamos como uma equipe pode fazer um melhor objetivo de sprint.

Primeiro, ignore a lista de pendências

Quando a equipe inicia a sessão de planejamento, é tentador simplesmente abrir a lista de pendências, ver quais histórias estão no topo e perguntar ao proprietário do produto se essas histórias ainda são importantes.

Se o Product Owner e o Scrum Master tiverem realizado seu trabalho corretamente, um backlog bem preparado terá os itens mais críticos no topo e estarão prontos para desenvolvimento com requisitos e definições  de pronto claramente definidos.

Pegando as principais tarefas

Em seguida, é um exercício simples arrastar as principais histórias para o sprint, até que a capacidade seja esgotada e concluir o planejamento.

De fato, dada uma ferramenta sólida o suficiente e com uma lista de pendências mantida em boa forma, esse método de planejamento pode ser feito sem uma reunião ou mesmo sem a interação humana. O que também seria completamente errado.

É assim que o planejamento de baixo para cima opera; a equipe “descobre” a meta observando as tarefas que estão prestes a serem concluídas.

Embora isso atenda a todos os critérios de planejamento e, de fato, crie um sprint devidamente formado e cheio de trabalho, não criará um objetivo ou direção para a equipe.

Para usar outro exemplo simples, uma decisão que a maioria das pessoas toma diariamente é decidir o que elas querem comer no jantar.

Às vezes, o método para fazer essa determinação envolve abrir os armários, ver o que está armazenado lá e decidir o que eles querem é uma tigela de sopa, ou as sobras da noite passada.

Certamente, isso servirá ao propósito de deixar a pessoa com menos fome, e pode até ser satisfatória o suficiente, estará longe do que eles “queriam” para o jantar.

Da mesma forma, o objetivo dos sprints devem ser algo que motive a equipe, dê um objetivo à equipe e ajude com as milhares de micro decisões que precisam ser tomadas ao longo do sprint.

Foco nos resultados

Em vez de prestar atenção no que itens individuais precisam ser feitos, a equipe deve se concentrar no resultado que espera obter do sprint.

Essa seria a abordagem de cima para baixo para criar uma meta, prestando atenção ao que a equipe está tentando realizar.

Em nosso exemplo, isso seria garantir que eles estejam preparados para a festa ou que tenham uma refeição satisfatória; em um exemplo real, serão coisas como garantir que um cliente possa entrar em um site, fazer um pedido ou entrar em contato com o atendimento ao cliente para obter suporte.

Com esse objetivo em mente, a equipe pode decidir quais histórias e tarefas serão necessárias para alcançar esse resultado e adicioná-las aos sprints.

A importância das histórias e o que adiar nas sprints

Histórias importantes, mas que não ajudam a atingir o objetivo do sprint atual, podem ser adiadas por enquanto.

À medida que o sprint progride, novas tarefas, cenários e até obstáculos surgirão e precisarão ser trabalhados.

Isso não é incomum; a adição de tarefas (embora geralmente não sejam histórias) ao sprint atual acontece com frequência e pode até ser representada em um gráfico de detalhamento padrão.

Com a compreensão de qual é o objetivo do sprint, adicionar coisas que ajudem a alcançar os critérios de saída pode ser comunicado de uma maneira que faça sentido para todos.

Também ajuda a agir como uma barreira para adicionar coisas que não parecem relevantes ou urgentes.

Certamente, itens de missão crítica e coisas necessárias para manter as luzes acesas entrarão na fila, mas isso ajuda a definir um nível alto para o quão difícil deve ser a inserção de novos trabalhos nos sprints depois de ter sido concluído e planejado considerando o objetivo principal do sprint,

Prever como atingir a meta das Sprints

Depois que o objetivo do sprint é determinado, a próxima tarefa é descobrir como alcançá-lo. Um mecanismo para fazer isso é pensar no que a equipe gostaria de apresentar no final das sprints em uma demonstração.

Ao determinar o que deve estar funcionando, o que deve estar visível e como isso será mostrado, pode ajudar a esclarecer quais tarefas precisam ser trabalhadas.

A equipe pode trabalhar de trás para frente a partir dessa descrição para ajudar a identificar o que não precisa ser desenvolvido imediatamente, especialmente se puder ser mostrado de uma maneira alternativa.

Vi demonstrações em que, depois de inserir alguns dados em um formulário da web, a próxima parte da apresentação foi a saída de uma consulta SQL escrita em um editor de banco de dados.

Não é bonito, mas prova suficiente de que a capacidade estava funcionando.

Parte disso envolve uma boa fatia vertical, mas o objetivo real é fornecer uma visão do que a equipe precisa fazer. A lista de trabalhos que precisam ser concluídos – como feito, feito, feito – deve ficar claro na mente de todos.

Separando o joio do trigo

Desde o final da reunião de planejamento até a extensão completa do sprint, a equipe deve ter uma imagem mental de exibição de seu trabalho e saber como o que eles estão trabalhando ajudará a alcançar esse objetivo.

Se um desenvolvedor se encontrar trabalhando em algo que não considera que impeça a apresentação do recurso, esse trabalho deverá ser deixado de lado para se concentrar ainda mais nos principais componentes do recurso.

Afinal, um bom objetivo do sprint ajuda a inspirar a equipe, dando-lhes algo para visualizar, além de conectar o trabalho que está sendo concluído ao resultado desejado.

Ele deve ser usado tanto taticamente, na determinação da lista de histórias que a integram quanto na estratégia, motivando a equipe para a conclusão.

Decida como medir suas Sprints

Uma vez que a última parte a descobrir é como a meta será avaliada e, em particular, o que a equipe deve acompanhar para determinar o sucesso.

Entretanto, o resultado de um sprint é redigido no tempo futuro, como em que funcionalidade estará disponível no final.

Pode ser que um cliente possa efetuar login ou fazer um pedido, mas o termo operacional é que ele é capaz de fazê-lo, e não o que realmente faz.

Em geral, a equipe de desenvolvimento não é responsável por gerar interesse ou demanda por um recurso ou produto; é mais seu objetivo disponibilizar recursos e produtos.

No entanto, isso não impede a equipe de desenvolvimento de apresentar métricas de sucesso para o que está construindo.

Deixe a equipe decidir

Dependendo do recurso, a equipe pode decidir que, dentro de uma semana após o lançamento, pelo menos uma pessoa utilizará a função em um ambiente de produção.

Contanto que o próprio Product Owner o faça, isso será fácil de conseguir.

Se houver uma melhoria em algo existente, a equipe poderá observar taxas de sucesso, desempenho ou alguma medida existente, e dizer que dentro de um certo período de tempo, isso mudará para melhor.

O que fazer com sprints de trás para frente

Também é útil fazer as duas coisas:

  1. Dizer que dentro de uma semana, um certo número de pessoas usará um recurso com sucesso e,
  2. Dentro de um mês, um número ainda maior o usará.

Pode ser uma combinação de tipos diferentes, medindo o uso e o desempenho, de modo que um número de clientes use o recurso e ele tenha características de desempenho.

Qualquer que seja o pensamento por trás da métrica, o objetivo principal é pensar em primeiro lugar.

Concluindo

Em suma, definir uma meta ajuda a criar uma visão sobre o que a equipe está trabalhando, definindo a métrica ainda mais na mente da equipe de desenvolvimento.

Ambos são extremamente importantes.

Então para criar uma meta de sprint de cima para baixo não é apenas uma parte necessária do processo, pode ser a parte mais importante.

Em conformidade a essa criação que ajuda a orientar tudo, desde a decisão do que fazer nos sprints, até o que precisa ser adicionado e o que não é necessário, e permite que as pessoas se concentrem no que será demonstrado quando tudo terminar.

Em suma, ao iniciar uma sessão de planejamento, decidindo o que você está tentando realizar, levará a um resultado melhor para todos.

4 tendências em gestão de projetos

4 tendências em gestão de projetos

Uma gestão de projetos faz total diferença na busca por objetivos. 

São estratégias que valem para vida pessoal e profissional, quando lançamos um produto ou serviço, por exemplo.

E por meio delas é possível alinhar tecnologia e gestão para promover bons resultados.

No entanto, a partir do momento que os projetos proporcionam objetivos certeiros, fica mais fácil entender a importância de uma gestão de projetos para a sua empresa.

Nesse artigo, iremos abordar mais a fundo a gestão de projetos e apresentar 4 tendências que estão em alta. 

Vamos lá? Boa leitura!

E caso precise de apoio em serviços de gestão de projetos, entre em contato com a gente.

 

O que é a Gestão de Projetos?

De antemão, a gestão de projetos é a aplicação de técnicas, conhecimentos e habilidades para que um projeto alcance sucesso. 

Esse gerenciamento tem como função fazer com que o objetivo seja atingido, seguindo os requisitos estabelecidos durante todo o planejamento.

Ela visa a garantia de resultados satisfatórios para a empresa, prazos e custos estabelecidos até o cliente final. 

A gestão de projetos tem como foco, viabilizar o alcance dos objetivos de uma forma ordenada e limitada de execução. 

Com as metas delineadas permite programações prévias de cada ação.

 

Como a pandemia impactou a área de Gestão de Projetos

As mudanças geradas pela pandemia, afetaram todo o desempenho profissional em diversos setores. 

Sendo inclusive relevante fazer retrospectivas para entender o que fazer depois dos resultados atingidos.

O modelo de atuação home office, que é baseado em um trabalho remoto e inovações de gestores de equipes, precisou ser implantado.

Isso para garantir pleno funcionamento das organizações em todo o período.

Tecnologias foram adotadas e irão permanecer, a fim de reduzir custos. 

Outro impacto foi a busca por divisão de contas, fazendo com que várias empresas fossem alocadas para um mesmo espaço.

 

Importância da Gestão de Projetos

A gestão de projetos é fundamental para a redução de riscos e controle das etapas envolvidas.

Para garantir qualidade de todos os resultados, tornando possível gerenciar projetos de forma ágil, otimizando recursos.

É indicado ainda investir em OKR, uma ferramenta poderosa para aumentar o foco, engajamento e agilidade.

Isso através de objetivos e resultados chave que representam os resultados mais importantes para o negócio e para os clientes.

Para diminuir as chances das falhas comprometerem a execução dos projetos e afetarem todo o desempenho da empresa, a gestão de projetos ajuda a prevenir riscos e analisá-los.

E dessa forma, encontrando maneiras de retornar a situação. 

 

4 tendências da Gestão de Projetos

A pandemia fez com que várias organizações se desafiassem. 

O mundo se tornou ainda mais digital, mesmo empresas não habituadas com o virtual tiveram que de alguma forma se adaptarem.

Por esse motivo, separamos 4 tendências de gestão de projetos para que você se prepare e realize as escolhas corretas para crescer e se destacar no mercado. 

#1 Soft Skills e Métodos Ágeis

As inovações estão surgindo com base em metodologia ágil, conhecida por ser mais adaptável a mudanças e acelerar a performance como um todo.

Refletindo, assim,  em entregas constantes e rápidas. 

Por outro lado, o soft skills auxilia na busca por definições de habilidades comportamentais e difíceis de avaliar.

O soft skills atua junto aos recursos humanos e gestão estratégica de pessoas, afinal, o modo em que os profissionais são tratados, faz toda diferença nos resultados obtidos. 

Aproveite e veja também: MÉTODO AGILE-WATERFALL HYBRID.

#2 Gerenciamento de Riscos

Método de planejar, organizar, dirigir e controlar os recursos humanos e materiais de toda uma organização.

Como ele é possível minimizar e até mesmo aproveitar os riscos e incertezas para promover benefícios significativos para a instituição. 

 

#3 Transformação Digital

Essa mudança é uma mentalidade que as empresas passam com o objetivo de se tornarem ainda mais modernas.

E para também acompanhar todos os avanços tecnológicos que não pararem de aparecer. 

Dessa forma, acaba sendo uma transformação sobre um contexto geral da modernidade e tecnologia.

 

#4 Marketing Digital

A forma mais eficaz de se preparar para o mercado competitivo é através do marketing digital.

Recurso este que vem ganhando cada vez mais força dentro das empresas e que auxilia na automação de vendas. 

É importante saber definir os direcionamentos para a equipe. 

Deixando tudo mais simples, dinâmico e aprimorado para as experiências dos usuários.


Sim! o marketing digital é importante para o processo com os clientes.

Ademais, uma pesquisa realizada pela Deloitte Access Economics, afirma que dois terços dos empregos até 2030 serão compostos por ocupações relacionadas a estas tendências.

Todo sucesso de um projeto depende de fatores. 

Planeje bem, busque capacitações e reveja todas as ações. 

Uma gestão de projetos é o meio mais certo para atingir objetivos dentro de um orçamento correndo menos riscos.

Ainda ficou dúvidas? Acompanhe o Projetos e Ti e veja tudo sobre consultoria e treinamento, outsourcing de gestão e transformação ágil.  

Método DSDM (Dynamic Systems Development Method)

O que é DSDM?

Inicialmente o acrônimo DSDM vem de Dynamic Systems Development Method surge como uma extensão do RAD, o DSDM é aplicado em projetos de Sistemas caracterizados pelos cronogramas e custos limitados. Aponta falhas de informação mais comuns destes projetos, incluindo custos excedentes, perda de prazos, falta de envolvimento de usuários e acompanhamento da alta gerência.

Através do uso do RAD, contudo, sem os devidos cuidados o DSDM pode aumentar ainda mais o risco em outros quesitos, o DSM consiste em:

  • 3 fases: pré-projeto, ciclo de vida, e pós-projeto.
  • A fase ciclo de vida é subdividida em 5 estágios: análise de viabilidade, análise de negócio, Iteração do Modelo Funcional, iteração de elaboração e construção e, por fim, implantação.

Em alguns casos, é possível integrar práticas de outras metodologias, como do Rational Unified Process (RUP), Programação Extrema (XP) e PRINCE2, como complemento ao DSDM. Outro método ágil que o DSDM possui muita similaridade quanto ao processo e conceitos é o Scrum.

O DSDM é de natureza dinâmica, pois é uma abordagem RAD (Rapid Application Development) para desenvolvimento de software. É uma abordagem iterativa e incremental que enfatiza o envolvimento contínuo do cliente/equipe.

O que diferencia o DSDM é o envolvimento ativo do usuário e o poder de tomada de decisão com as equipes que trabalham nele.

As equipes têm poderes para tomar decisões.

Ele se concentra na fórmula: 80% de implantação do sistema em 20% do tempo, ou seja, não demora muito para atingir uma fase de trabalho ou para chegar a uma fase em que você pode dizer que funcionará.

Este método é usado principalmente para o sistema em que os requisitos de entrega de software ocorrem em um curto espaço de tempo. Seu objetivo é fornecer software dentro do prazo e do orçamento, enquanto ainda se ajusta a novas condições ou mudanças ao longo do caminho.

Breve histórico do DSDM

O DSDM (Dynamic Systems Development Method) foi desenvolvido no Reino Unido em 1990 para atender à necessidade de negócios rápidos, mas foi oficialmente originado em janeiro de 1994 por um grupo sem fins lucrativos através do DSDM Consortium, (atual Agile Consortium1) uma associação de consultores e especialistas no ramo de Engenharia de Software, partilharam e combinaram as suas melhores técnicas e experiências para fornecer uma estrutura padrão do setor para entrega de projeto.

Sua primeira versão foi concluída em janeiro de 1995 e a versão mais recente, atualmente em uso, é 4.2, desenvolvida em 2003.

Princípios do DSDM:

DSDM tem  nove Princípios Fundamentais  girando em torno das necessidades de negócios:

dsdm-principios

1. Envolvimento ativo do usuário

o primeiro e mais importante princípio é o envolvimento do usuário. O usuário, as pessoas que usarão o produto final, deve estar envolvido ativamente durante todo o desenvolvimento do projeto.

Ajuda a reduzir os erros que podem ocorrer devido à percepção do usuário e, portanto, reduz também o custo do retrabalho.

O DSDM enfatiza o trabalho com um grupo pequeno e selecionado de usuários e mantém contato com eles continuamente, em vez de encontrá-los ocasionalmente em reuniões periódicas e sessões de revisão.

2. Equipes Capacitadas (com poderes)

Para proceder de forma rápida e sem problemas, este modelo incentiva e capacita as equipes a tomar decisões. Abaixo estão algumas áreas em que a tomada de decisões em equipe é muito crítica

  • Decisão de requisitos
  • Priorizando a entrega de atividades e recursos
  • Detalhes dos requisitos técnicos
  • Qual funcionalidade precisa adicionar em um determinado incremental

3. Entrega frequente

Já uma entrega frequente de valor ao cliente garante que os erros / bugs sejam identificados, trabalhados e resolvidos / revertidos / corrigidos em um estágio inicial. A fonte do erro e da causa raiz também é encontrada e corrigida.

Aplica-se a todos, documentos de requisitos (histórias de usuários), modelos de trabalho e códigos de programa.

4. Aptidão para negócios

No DSDM, nosso foco é fornecer software eficiente o suficiente para resolver uma necessidade de negócios e aceitar alterações ou aprimoramentos em uma iteração posterior. O DSDM se concentra em satisfazer primeiro as necessidades comerciais e não permite criar software ad-hoc. Mantém o fluxo do processo simples e eficaz.

5. Desenvolvimento incremental

Para manter o grande projeto simples e menos complicado, torna-se crucial decompô-lo em vários projetos de pequenos recursos. Cada entrega garante que um novo recurso seja entregue ao cliente.

Esse desenvolvimento e entrega incrementais continuam até a entrega do conjunto completo de recursos necessários aos negócios.

6. Alterações reversíveis

No DSDM, a iteração ocorre através de pequenos incrementos. Como todos os estágios de desenvolvimento são bem conhecidos pelos desenvolvedores, as alterações aqui são reversíveis. Portanto, o medo da perda total de trabalho também é muito menor.

7. Linha de base para os requisitos

Algumas linhas de base de alto nível precisam ser definidas para limitar o grau de liberdade para fazer alterações. Durante a fase do contrato comercial, a equipe de negócios e desenvolvimento discute e concorda com a linha de base quando os pedidos e requisitos de mudança seriam “congelados”.

8. Teste integrado

No DSDM, o teste é realizado logo no início da fase de desenvolvimento para garantir que o produto não tenha falhas técnicas. Os desenvolvedores e os líderes da equipe verificam até os documentos de teste. Ajuda na correção de problemas em um estágio muito inicial e reduz o retrabalho e, portanto, reduz o custo e o tempo.

9. Colaboração das partes interessadas

É crucial ter uma atmosfera de confiança e honestidade para obter requisitos precisos e feedback honesto sobre um produto resultante. No DSDM, a equipe de negócios e a colaboração do desenvolvedor são muito cruciais para agregar valor.

Requisitos de negócios claros e feedback honesto ajudam no desenvolvimento rápido, o que leva ainda mais à entrega oportuna do projeto.

Considerações adicionais

Prioridades: nenhum sistema é construído perfeitamente logo de início. Em geral, 80% do resultado final são oriundos de 20% dos requisitos, por esta razão o DSDM inicia pela implementação bem sucedida destes 20% críticos.

Desta forma pode produzir um sistema que ofereça funcionalidades suficientes para satisfazer usuários finais e os 80% restantes podem ser distribuídos nas demais iterações, além de reduzir o risco do projeto ultrapassar seus limites de prazo e orçamento.

Tripé de qualidade: a entrega do projeto deve ser feita a tempo, custo e de ser de boa qualidade.

Interseções: cada passo do desenvolvimento deve estar completo apenas o suficiente para que se inicie o próximo passo. Isto permite que a nova iteração seja iniciada sem atrasos desnecessários.

Maleabilidade: alterações no design podem coincidir com alterações na demanda de usuários finais, uma vez que cada iteração do sistema é aprimorada de forma incremental.

Gerenciamento: técnicas de Gerência de Projeto e Desenvolvimento de Sistemas são incorporadas.

Híbrido: DSDM pode ser aplicado tanto em novos projetos quanto em aprimoramento de sistemas já existentes.

Objetividade: a gerência de risco deve focar nas funcionalidades a serem entregues, não no processo de desenvolvimento e nem em artefatos (como requisitos e criação de documentos).

Foco na entrega: gerenciamento valoriza muito mais entrega do produto que tarefa cumprida.

Funcionalidade: estimativa deve se basear na funcionalidade de negócios em vez de em linhas de código.

Quatro valores do DSDM

dsdm-valores

Individual: como o Agile no DSDM também valoriza as pessoas. No final, essas são as pessoas que estão trabalhando fisicamente no projeto e conhecem melhor a parte prática. Sua experiência e conhecimento agregam mais valor ao projeto em comparação com ferramentas, documentos ou fluxos de processos.

Software de trabalho: É muito crucial que exista um entendimento compartilhado e uma definição padrão de “Software de trabalho” entre todas as partes interessadas no software.

Nota – O software de trabalho é o software que passou por todas as etapas de desenvolvimento e teste e está pronto para chegar ao mercado agora. Será a versão do software que será usada pelo usuário final

Colaboração: é um dos valores essenciais para uma entrega eficaz. É porque levar as pessoas em uma sala para tomar uma decisão será mais produtivo, menos demorado e eficiente do que compartilhar e-mails por semanas para tomar uma decisão. Aqui estão alguns exemplos de colaboração –

  • Equipe multifuncional;
  • Co-localização com o cliente;
  • Workshop de facilitação.

Resposta a mudanças: O DSDM aceita todas as modificações necessárias e as acomoda. Valoriza e responde a todas as mudanças de uma maneira muito inovadora, principalmente pela priorização .

Estrutura do projeto no DSDM

O fluxo do processo do projeto DSDM consiste em 7 fases, organizadas em um rico conjunto de funções e responsabilidades e suportadas por algumas técnicas principais. Abaixo está a parte da estrutura de um fluxo de processo do sistema DSDM.

  • Papéis e responsabilidades;
  • Organização e tamanho da equipe;
  • Ferramentas e técnicas;
  • Fase para governá-los / Fluxo do processo.

Papéis e responsabilidades

Existem alguns papéis aplicados junto ao ambiente DSDM. É interessante que seja definido previamente os papéis que cada membro do projeto irá representar antes de se iniciar as atividades. Cada papel tem sua própria responsabilidade. São eles:

Funções no nível do projeto

Geralmente consiste em

  • Gerente executivo: também chamado de “Campeão do Projeto”. Papel importante para usuários os quais possuem habilidades e responsabilidades em cumprir determinados prazos e recursos. Este papel é a ultima palavra na tomada de decisões.
  • Líder de time: lidera seu time e mantém a harmonia do projeto e trabalho em grupo.
  • Gerente de projeto: pode ser qualquer do grupo de usuários ou Gerencia de TI que gerenciará o projeto como um todo.
  • Visionário: aquele que tem a responsabilidade de iniciar projeto certificando que os requisitos essenciais foram definidos. O visionário tem a percepção acurada dos objetivos de negócio do sistema e projeto. Outra tarefa é supervisionar e manter o desenvolvimento do processo “na linha”.
  • Intermediador: usuário que traz o conhecimento de outras áreas para o projeto, certifica que os desenvolvedores receberam quantidade suficiente de feedback de usuários durante o processo de desenvolvimento.
  • Anunciante: qualquer usuário que represente um importante ponto de vista e traga diariamente conhecimento ao projeto.

Sua responsabilidade é controlar o projeto como um todo. Eles não trabalharão no projeto, mas serão responsáveis ​​por concluir o trabalho e manter os negócios atualizados sobre a situação atual. Eles agem como uma conexão entre a equipe de usuário e desenvolvimento. Geralmente, são pessoas de nível executivo e trabalham diretamente com os negócios. Eles também são chamados de embaixadores.

Funções de desenvolvimento da solução

As funções de desenvolvimento da solução geralmente consistem em

  • Coordenador Técnico: responsável no desenho da arquitetura do Sistema e controle da qualidade técnica do projeto.
  • Líder de time: lidera seu time e mantém a harmonia do projeto e trabalho em grupo.
  • Desenvolvedor: interpreta o modelo e requisitos do sistema incluindo desenvolvimento de artefatos de código e construção de protótipos.
  • Testador: Confere o funcionamento da parte técnica através da execução de algumas tarefas. O Testador deverá possuir alguns comentários e documentação.
  • Escrivão: Responsável por recolher e armazenar requisitos, acordos e decisões tomadas entre todos os grupos de trabalho.
  • Facilitador: Gerencia progresso dos grupos de trabalho, age como motor de preparação e comunicação.
  • Papéis específicos: Arquiteto de negócios, Gestor de Qualidade, Integrador de Sistema, etc.

Eles funcionam como o “coração” do projeto. Eles são a principal força motriz, pois trabalham no marco zero e são responsáveis ​​pelo desenvolvimento do produto / solução.

Funções de suporte

Consiste em papéis como

  • Treinador DSDM: Responsável por treinar os usuários na metodologia.
  • Facilitador do Workshop: Cria e facilita o treinamento.

Essas pessoas têm um bom conhecimento prático de todas as áreas de negócios. Eles ajudam e orientam todos os que trabalham nela continuamente durante todo o projeto até a entrega. Eles têm um bom entendimento da estrutura do DSDM, bem como do desenvolvimento.

Organização e tamanho da equipe

No DSDM, uma equipe de projeto pode consistir em um ou dois grupos, nos quais um grupo assume a responsabilidade de executar os testes na entrega de outro grupo.

De acordo com a pesquisa organizacional, o tamanho da equipe não deve ser inferior a cinco membros, excluindo especialistas externos. Especialistas externos são pessoas experientes no nível executivo que apoiam projetos externamente.

E se o projeto for grande e mais trabalho for entregue, será necessária uma estrutura de várias equipes.

Ferramentas e Técnicas

O foco principal do DSDM é que o produto seja entregue com frequência em cada iteração. Diferentes ferramentas, técnicas e práticas são usadas para apoiar todo o processo do DSDM.

Esses são:

  • O Timeboxing;
  • A priorização do MoSCow;
  • Workshops facilitadas;
  • Desenvolvimento iterativo;
  • Técnicas de modelagem e prototipagem.

Timeboxing

O timeboxing é uma das práticas essenciais mais cruciais. É semelhante ao que é um marco nos métodos tradicionais de desenvolvimento de software como um sprint no Scrum. Timeboxing é a quantidade de trabalho a ser realizado em um tempo determinado.

Utilizada no suporte aos objetivos principais para realização do desenvolvimento do sistema no prazo estimado, além de manter o custo e qualidade desejados. A principal ideia por trás do timeboxing é a divisão do projeto em porções, cada um com um orçamento e prazo estimados.

Para cada porção um número de requisitos são selecionados e priorizados de acordo com o princípio de MoSCoW. Devido ao tempo e custo serem fixos, as variáveis remanescentes são os requisitos. Desta forma se o prazo ou o custo está se esgotando requisitos de baixa prioridade são omitidos.

Isto não significa que o produto ficará inacabado ou será entregue pela metade, pois de acordo com o Princípio de Pareto, onde 80% do projeto vem de 20% dos requisitos do sistema, assim uma vez que os 20% dos requisitos mais importantes forem implementados no sistema será possível atender as necessidades do negócio além do que nenhum sistema é construído em sua total perfeição logo de início.

Um projeto de desenvolvimento de software terá várias caixas de horário e a cada caixa de tempo é atribuído um objetivo específico. O Timeboxing ajuda a atingir a meta a tempo. Geralmente, para um projeto, a duração de um período pode variar de duas semanas a um máximo de 6 semanas, mas não mais do que isso.

Benefícios da utilização do Time Boxing:

  • Concentre-se em entregar o produto no prazo.
  • As pessoas permanecem focadas conforme a prioridade e não se desviam, melhorando assim a produtividade.
  • Todos os membros sabem o que a outra pessoa está fazendo e quanto tempo levará para concluir essa atividade.
  • Diminui a dependência e a delegação de trabalho à medida que todos os membros estão ocupados e precisam fornecer resultados a tempo.

É como um hábito alimentar saudável: “Coma uma pequena porção de comida em pequenos intervalos”.

Vamos entender isso com a ajuda de um exemplo.

Todos nós amamos nossa vida estudantil e todos passamos por isso. Durante os exames, mesmo que haja um período suficiente de tempo entre as provas, sempre estudávamos nos últimos 1 ou 2 dias. E nossos pais costumavam nos dizer para estudar sempre um pouco todos os dias. A abordagem correta teria sido:

  • Faça uma programação;
  • Divida seu plano de estudos em pequenas porções;
  • Priorize-os;
  • Atribuir cronogramas a todas as partes;
  • Terminar parte no tempo atribuído.

Essa abordagem sistemática para concluir o trabalho atribuído no tempo comprometido é chamada de Timeboxing .

Workshops Facilitados

Uma das técnicas do DSDM que objetiva e permite que diferentes envolvidos discutam juntos requisitos, funcionalidades e entendimento mútuo. Num grupo de trabalho os envolvidos se unem a discutir apenas sobre o projeto.

As oficinas facilitadas significa oferecer uma oficina em que os membros da equipe e os desenvolvedores possam trabalhar em um claro conjunto predefinido de resultados. Para ter acesso a este workshop, eles coordenam uma pessoa neutra chamada facilitador do workshop . O facilitador orientará a equipe através de um processo para atingir seus objetivos, habilmente. Esse processo que o facilitador guia através de

  • Definindo o objetivo,
  • Identificando participantes apropriados,
  • Criando uma agenda,
  • Gerenciando a logística e
  • Distribuir qualquer pré-leitura aos participantes.

O motivo por trás de um workshop é incentivar o trabalho colaborativo e permitir decisões da equipe em um curto espaço de tempo. Também permite o compartilhamento de conhecimento.

É como uma sala de aula, você pode discutir apenas um tópico de um assunto específico em um momento específico, e o objetivo dessa discussão será focado, ou seja, para fazer a sala de aula entender esse tópico em particular.

Os benefícios de ter um workshop incluem:

  • Forneça um ambiente ideal para explorar novas ideias e incentive o crescimento rápido e sistemático dessas ideias.
  • Uma gama mais ampla de partes interessadas pode tomar decisões.
  • Todo mundo está ciente de discussões e decisões.
  • A tomada de decisão é rápida e precisa.

Modelagem

Esta técnica é essencial e propositalmente utilizada para visualizar uma representação gráfica de aspectos específicos do sistema ou área de negócio que será trabalhado. Modelagem permite um melhor entendimento para o time do projeto do DSDM que está fora do domínio do negócio.

Prototipagem

Se refere à criação de protótipos do sistema em desenvolvimento em estágios iniciais do projeto. Isto permite descobrir rapidamente falhas no sistema e permitir um ‘test-drive’ aos usuários do sistema, o que vem a ser uma ótima maneira de se realizar o envolvimento do usuário, um dos fatores chave do DSDM.

Testes

Um terceiro aspecto importante do DSDM é a criação de um sistema de boa qualidade. Para alcançar este quesito, DSDM aplica testes ao longo de cada iteração. Considerando que o DSDM é um método e ferramenta independente, o time de projeto é livre para escolher por conta própria o Método de gerenciamento de teste.

Priorização MoSCoW

MoSCoW Representa a forma de priorização de itens. No contexto do DSDM o método MoSCoW é utilizado para priorizar requisitos.

Além disso é uma técnica simples de priorização, que ajuda a entender e priorizar as tarefas a serem executadas, as letras aqui representam:

  • Must-Have: Os requisitos que são fundamentais e devem estar em conformidade com a solução.
  • Deveria ter: O que é importante para a solução de negócios.
  • Poderia ter: Os requisitos que são importantes, mas que podem ser facilmente deixados de lado por um curto período de tempo.
  • Não terá: os requisitos que podem esperar e incluir no desenvolvimento posterior.

dsdm-moscow

A priorização do MoSCoW é essencial porque nem sempre há tempo suficiente para fazer tudo, e as coisas vitais não devem ser deixadas para trás.

Os benefícios do MoSCoW são:

  • Ele permite que as expectativas dos negócios sejam definidas no nível do projeto.
  • Garante que a equipe entregue primeiro os itens indispensáveis
  • Garante que eles entreguem a maioria ou todos os Dever Haves
  • Se o tempo permitir, os desenvolvedores também podem fornecer alguns dos Haves que poderiam.

Você deseja comprar um carro grande com os seguintes recursos:

  • Carros de sete lugares – Para acomodar um número máximo de amigos para um passeio nos fins de semana.
  • O carro deve ter um motor de 2000 cc, pois é essencial ter motores potentes para off-road e viagens rodoviárias.
  • O carro deve ter espaço de inicialização funcional
  • Sistema de navegação
  • Boa quilometragem
  • Sua cor favorita é amarela, então você quer comprar um carro de cor amarela.
  • Você também pode querer ter um teto solar para aproveitar o clima
  • Você prefere ter conectividade Bluetooth para o seu iPod e outros dispositivos.
  • Você também pode preferir ter uma cadeira de criança.

Vamos definir a priorização no caso acima, conforme MoSCoW:

  • Deve ter
    • Carro de sete lugares para off-road e viagens
  • Deveria
    • Motor de 2000cc
    • Boa quilometragem
    • Sistema de navegação
    • Bom espaço de inicialização
  • Poderia ter
    • Carro cor amarela
    • Teto solar
  • Não terá
    • Bluetooth
    • Cadeira de criança.

Fluxo de processo

DSDM Feasibility

O framework DSDM consiste de 3 fases sequenciais, nomeadas de pré-projeto, ciclo de vida e pós-projeto. O ciclo de vida é a fase mais elaborada das 3. Consiste em 4 estágios que formam o passo-a-passo das iterações aplicadas ao desenvolvimento do sistema. Estas 3 fases e seus respectivos estágios serão abrangidos nas seções subsequentes, veja abaixo as atividades principais de cada fase/etapa:

Abaixo estão todas as fases e estágios de um fluxo de processo no DSDM

Fase 1 – O Pré-Projeto 

No pré-projeto são identificados os projetos candidatos, aqui é realizada a conceituação do projeto, são definidos orçamento e assinatura do contrato. Controlando estes critérios antecipadamente pode-se evitar problemas futuros e em estágios mais críticos. E aqui garantimos que todos os envolvidos no projeto estejam cientes dos objetivos e decidimos iniciá-lo.

Fase 2 – O Ciclo de Vida 

Análise de viabilidade e negócios são fases sequenciais que se completam entre si. Após a conclusão destas fases, o sistema é desenvolvido iterativamente e incrementalmente segundo as iterações do Modelo Funcional, desenho e construção, até à implementação. A iteração e natureza incremental do DSDM serão citadas mais a frente.

Na fase de viabilidade, ocorre a análise dos aspectos técnicos, financeiros e da força de trabalho. Aqui, as restrições de entrega do projeto são calculadas quanto ao tempo e recursos. Essa fase é crítica, pois as decisões mais importantes estão sendo tomadas nessa fase, incluindo o cancelamento do projeto.

Fase de estudo de negócios – Explorando o aspecto comercial do projeto . Nesta etapa, a identificação dos aspectos comerciais do projeto ocorre. As perguntas a seguir são discutidas e respondidas nesta fase

  • Quem serão os participantes?
  • O projeto fará sentido do ponto de vista comercial?
  • Será rentável?
  • Qual será o melhor plano de trabalho?
  • Quais recursos são necessários durante o ciclo de desenvolvimento?
  • Quais ferramentas e tecnologias serão necessárias para a construção e implantação?

Fase 3 – Pós-projeto 

Esta fase garante a eficiência e eficácia do projeto. Através de manutenções, melhorias e ajustes de acordo com os princípios do DSDM. A manutenção pode ser vista como um contínuo desenvolvimento.

Invés de finalizar o ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas anteriores a fim de refinar ainda mais o passo concluído.

Os 4 estágios do ciclo de vida do projeto no DSDM

Estágio 1 A: Análise de Viabilidade

Durante este estágio do projeto, a viabilidade de uso do DSDM é examinada. Pré-requisitos para o uso do DSDM são avaliados respondendo-se algumas questões como: ‘Pode este projeto atender as necessidades do negócio?’, ‘Este projeto é próprio para o DSDM?’ e ‘Quais os riscos mais importantes que estão envolvidos?’. A técnica fundamental desta fase é a utilização dos Workshops facilitados (Grupos de trabalho).

Os artefatos para este estágio são Relatório de viabilidade e Protótipo da Viabilidade. São estendidos até o Planejamento de Definições Gerais até o resto do projeto, e além deste um controle de Risco identifica os riscos mais impactantes do projeto.

Essa análise não deve passar de algumas semanas; duas ou três são consideradas tempo suficiente para deliberar sobre a viabilidade. como produto final, são criados um relatório de viabilidade e um plano geral de desenvolvimento.

Iteração do Modelo Funcional

Todas as fases funcionais discutidas nos estágios anteriores, todos os requisitos técnicos são decididos e priorizados. Um protótipo funcional é criado neste estágio, em que um modelo de um requisito após o outro é construído de forma incremental. Esse protótipo funcional, em seguida, verificou a qualidade e o escopo da melhoria por especialistas técnicos e, às vezes, pelos usuários finais.

Abaixo estão os passos que a prototipagem seguirá

  • Investigar: Com base na priorização feita no estágio anterior, neste estágio, identificaremos as principais funcionalidades necessárias.
  • Aceitar plano e cronograma: depois que a equipe decidir os recursos finais,
    • gerente de projeto identificará os membros da equipe.
    • Os membros da equipe recebem as tarefas atribuídas.
    • Os cronogramas também serão anexados aqui.
  • Criar: o desenvolvedor criará o protótipo / modelo com base nos requisitos funcionais, testará e melhorará ainda mais (se necessário)
  • Revisão: O usuário testa no final e discute as funcionalidades. As áreas de melhoria são discutidas com base no feedback do usuário .

Análise de negócio

Oriundo da Análise de Viabilidade. Após o projeto ser deferido viável para o uso do DSDM, este estágio examina a influência dos processos do negócio, usuários envolvidos e seus respectivos desejos e necessidades.

Novamente os Grupos de Trabalho são uma das mais valiosas técnicas, Grupos de Trabalho juntam diferentes envolvidos para discutir o propósito do sistema. A informação gerada nestas sessões é combinada com a lista de requisitos. Uma propriedade importante da lista de requisitos é o fato dos requisitos estarem (ou poderem) ser priorizados.

Geralmente este requisitos são priorizados segundo o método de MoSCoW. Baseados nestas prioridades, o plano de desenvolvimento é construído como base para o resto do projeto.

Uma técnica importante utilizada no desenvolvimento do plano é a Timeboxing. Esta técnica é essencial para alcançar os objetivos do DSDM, baseados e custo e prazo, garantindo a qualidade desejada. A Arquitetura do Sistema é outro documento fundamental no auxilio do sistema.

Os artefatos para este estágio são definições que relatam o contexto do projeto dentro da companhia. A Arquitetura do Sistema, fornece a arquitetura global inicial do Sistema em desenvolvimento junto com um plano de desenvolvimento que destaca os pontos mais importantes num processo de desenvolvimento.

Na base destes 2 documentos encontra-se a lista de priorização de requisitos. O que define todos os requisitos do sistemas. E por último, o controle de Risco é atualizado com os fatos que forem identificados durante esta fase do DSDM.

Abaixo estão os passos que a prototipagem seguirá

  • Investigar: Com base na priorização feita no estágio anterior, neste estágio, identificaremos as principais funcionalidades necessárias.
  • Aceitar plano e cronograma: depois que a equipe decidir os recursos finais,
    • O gerente de projeto identificará os membros da equipe.
    • Os membros da equipe recebem as tarefas atribuídas.
    • Os cronogramas também serão anexados aqui.
  • Criar: o desenvolvedor criará o protótipo / modelo com base nos requisitos funcionais, testará e melhorará ainda mais (se necessário)
  • Revisão: O usuário testa no final e discute as funcionalidades. As áreas de melhoria são discutidas com base no feedback do usuário .

Estágio 2: Iteração do Modelo Funcional

Os requisitos identificados nos estágios anteriores serão convertidos em modelos funcionais. Este modelo consiste tanto do funcionamento do protótipo quanto do modelo. Prototipar é uma saída para técnicas de projeto em que neste estágio auxilia num verdadeiro envolvimento do usuário no projeto.

O protótipo desenvolvido é revisado por diferentes grupos. De forma a garantir qualidade, os testes são efetuados ao longo de cada iteração. Uma parte importante do teste é realizada na Iteração do Modelo Funcional.

O Modelo Funcional pode ser dividido em 4 sub-estágios:

  • Identificação do protótipo funcional: determina funcionalidades a serem implementadas resultantes desta iteração.
  • Agenda: concilia como e quando serão feitas estas funcionalidades.
  • Criação do protótipo funcional: desenvolver o protótipo. Investigar, refinar e consolidar com os protótipos funcionais das iterações anteriores.
  • Revisão do protótipo: efetuar correções no desenvolvimento do projeto. Isto pode ser feito através de testes de usuários, através destas evidências e feedbacks dos usuários é gerado o documento de revisão do Protótipo.

Os artefatos desta etapa são Modelo Funcional e Protótipo Funcional os quais juntos representam as funcionalidades que serão trabalhadas nesta iteração, prontas para serem testadas por usuários. Depois disso, a lista de requisitos é atualizada, removendo-se os itens entregues e refazendo a lista de prioridades dos requisitos remanescentes. Além disso o Log de Riscos também é atualizado por uma análise de riscos do conteúdo desenvolvido após a revisão do documento da prototipação.

Estágio 3: iteração de desenho e construção

O maior intuito desta Iteração do DSDM é integrar os componentes funcionais de fases anteriores em um sistema que satisfaça as necessidades do usuário. Ele também controla os requisitos não funcionais que foram definidos para o Sistema. Novamente Testes vem a ser uma atividade fundamental no andamento deste estágio. A iteração de Desenho e Construção também pode ser dividida em 4 sub-estágios:

  • Definir desenho do protótipo: Identificar requisitos funcionais e não funcionais que precisam ser testados no sistema.
  • Agenda: Definir quando e como serão realizados estes requisitos.
  • Criação do desenho do protótipo: criar um sistema que possa ser seguramente manipulado por um usuário no uso diário. Investigar, refinar e consolidar o protótipo da iteração atual dentro do processo de prototipação é um ponto essencial.
  • Revisar o protótipo desenhado: efetuar ajustes no desenho do sistema, novamente testando e revisando com as principais técnicas já utilizadas, uma vez que os feedbacks dos usuários e as evidências de teste são necessárias para geração da documentação do usuário.

Os artefatos a serem entregues neste estágio são Desenho do Protótipo que os usuários testaram e ao final desta Iteração o sistema testado é transferido para a próxima fase. Neste estágio, o sistema é construído exatamente de acordo com o desenho e funções consolidadas e integradas no protótipo. Outro artefato desta iteração é a Documentação de Usuário.

Fase de Design e Construção – um produto projetado e implementado em iterações – Aqui nesta etapa

    • Inicia o desenvolvimento de software
    • Os produtos serão criados e implantados em pequenas iterações.

Em cada iteração

    • Decida qual funcionalidade será entregue primeiro com base na prioridade
    • Projete essa funcionalidade
    • Codificando
    • Em seguida, implante a funcionalidade

O processo acima entra em um ciclo para cada iteração e uma funcionalidade é entregue no final de cada iteração.

Estágio 4: implantação

Na fase de Implantação, o sistema testado e mais a documentação de usuário é entregue aos usuários e treinos à estes futuros usuários são aplicados. O sistema para ser entregue deve ter seus requisitos revisados de acordo com o que foi definido nas etapas iniciais do projeto. O estágio de implantação é dividido em 4 sub-estágios:

  • Orientações e aprovação do usuário: usuários aprovam o sistema testado e algumas orientações de uso e implantação do sistema são definidas.
  • Treinamento: treinamento de futuros usuários no uso do sistema.
  • Implantação: implantar propriamente o sistema concluído na localidade dos usuários.
  • Revisão de Negócios: rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO.

Os artefatos deste estágio consistem em Entrega do Sistema no Local, pronto para utilização dos usuários finais, Treinamento de usuários e Documento de Revisão do Projeto do sistema entregue.

Fase de implementação – A segunda última fase do processo do ciclo de vida é a implantação. No estágio anterior, fizemos a implantação em pequenas iterações, mas aqui o produto como um todo ficará operacional. Após essa etapa, o produto estará pronto para ser lançado no mercado.

Nesta fase

    • O produto estará em sua fase final
    • Toda a documentação é finalizada
    • Comentários terminaram
    • Os usuários serão treinados para usar o produto, e está tudo pronto para chegar ao mercado

O processo de implementação ou implantação possui vários estágios.

    • Montagem : monte todas as aprovações e diretrizes relacionadas aos projetos.
    • Revisão : avalie e revise se a qualidade fornecida é de acordo com a qualidade documentada predefinida, finalizada com os negócios na fase de iteração funcional do processo de desenvolvimento.
    • Implantar : coloque o produto em uso operacional (mercado) após treinar os usuários no produto e fazer a configuração necessária, etc.

Atividade

Sub Atividade

Descrição

Análise

Análise de Viabilidade

Estágio onde a utilização do DSDM é avaliada. Analisando o tipo de projeto, problemas organizacionais e de pessoas, é tomada a decisão de se utilizar ou não o DSDM. Por esta razão são gerados artefatos de RELATÓRIO DE VIABILIDADE, PROTÓTIPO DE VIABILIDADE, e um PLANO DE DETALHAMENTO GLOBAL que inclui o PLANO DE DESENVOLVIMENTO e CONTROLE DE RISCO.

Análise de Negócio

Onde são analisadas características essenciais do negócio e tecnologias a serem empregadas. Capacidade de se montar grupos de trabalho, onde existam clientes experts suficientes para fornecer maiores peculiaridades do sistema e concordarem com as prioridades de desenvolvimento.

Iteração do Modelo Funcional

Identificar o Protótipo Funcional

Determinar as funcionalidades que serão implementadas é o resultado desta iteração. Neste sub-estágio, um MODELO FUNCIONAL é desenvolvido de acordo com o resultado com o artefato resultante do estágio de Análise do negócio.

Agenda

Definir quando e como as funcionalidades serão implantadas.

Criação do Protótipo Funcional

Desenvolver um PROTÓTIPO FUNCIONAL, de acordo com a Agenda e o MODELO FUNCIONAL.

Revisão do Protótipo Funcional

Efetuar correções do protótipo desenvolvido. Isto pode ser feito através de testes dos usuários finais ou por análise da documentação. O artefato gerado aqui é o DOCUMENTO DE REVISÃO DO PROTÓTIPO FUNCIONAL.

Iteração de Desenho e Construção

Identificar o modelo do Desenho

Identificar requisitos funcionais e não-funcionais que devem estar no sistema testado. Baseado nestas identificações, uma ESTRATÉGIA DE IMPLANTAÇÃO é gerada e caso haja EVIDÊNCIAS DE TESTE de iterações anteriores, estas serão utilizadas para criação desta estratégia.

Agenda

Como e quando serão realizados estes requisitos.

Criação do Protótipo do Desenho

Criar um sistema (PROTÓTIPO) que pode tranquilamente ser manipulado pelos usuários finais no uso diário, também para razões de teste.

Revisão do Protótipo

Efetuar correções no sistema desenhado. Novamente testando e revisando através das técnicas mais utilizadas. Uma DOCUMENTAÇÃO PARA USUÁRIO e EVIDÊNCIA DE TESTE serão gerados.

 Implantação

Orientações e Aprovação do usuário

Usuários finais aprovam o sistema testado (APPROVAL) pela implantação e orientação fornecida pelo respectivo sistema criado.

Treinamento

Treinar futuros usuários finais no uso do sistema. USUÁRIOS TREINADOS é o artefato entregue neste sub-estágio.

Implantação

Implantar o sistema testado e liberar aos usuários finais, chamado SISTEMA ENTREGUE.

Revisão de Negócio

Rever o impacto que o sistema implantado causa sobre o negócio, pode-se utilizar o cruzamento dos objetivos iniciais com a análise atual como termômetro. Dependendo do resultado o projeto passa para o próximo estágio ou reinicia este estágio a fim de refinar e melhorar os resultados. Esta revisão será documentada através do DOCUMENTO DE REVISÃO DO PROJETO.

Fase 3 – Pós-projeto 

Na última fase, após a entrega do produto ao cliente, será necessária manutenção. A manutenção geralmente é feita periodicamente de maneira cíclica.

Para uma melhor compreensão dessas fases de desenvolvimento, vamos considerar um exemplo

Todo o procedimento de admissão é explicado com a ajuda dessas fases sempre que você escolhe uma escola infantil para seu bebê.

  1. Como pais, a primeira decisão que precisamos tomar é que é um bom momento para enviar uma criança para a escola. Esta decisão, se a educação para a criança for iniciada ou não, pode ser referida como a fase Pré-projeto. Em seguida, verificaremos mais alguns fatores, como:
  • Lista de escolas de educação infantil perto de sua casa nas quais as admissões estão acontecendo
  • Taxas e valores.

Com base nessas informações, decidiremos ainda mais se devemos continuar com a admissão de uma criança ou não.

  1. Em seguida, faremos uma lista de verificação, importante ao selecionar uma escola
  • Pessoal docente;
  • A infraestrutura;
  • Segurança;
  • Creche;

Na linguagem de desenvolvimento de software, eles são chamados de estudo dos aspectos comerciais.

  1. Nos estágios anteriores – você decidiu fatores de alto nível; agora você vai mergulhar nele e coletar informações mais detalhadas para finalizar a escolha da escola
  • Pessoal docente
    • Deve ser bem qualificado
    • A proporção de Alunos e Professores não deve exceder 1:10
  • A infraestrutura
    • A instalação de transporte está disponível?
    • Higiene de banheiros, salas de jogos devem ser bem mantidas?
  • Segurança
    • CCTV instalado?
    • A equipe passou pelo processo de verificação de antecedentes?
  • Creche
    • Instalação de refeitório
    • Horários da creche

Isso é chamado de iteração de modelo funcional. Aqui você coletará todos os artefatos

  1. Baseando-se em todas essas informações, você selecionará a escola e começará a enviar seu filho para teste por uma hora na primeira semana e aumentará o tempo a cada semana que passa. Essa implantação em fases é conhecida como fase Design e Build em termos de desenvolvimento de software.
  2. Depois de um mês, considerando que a criança começou a passar uma quantidade considerável de tempo na escola e parece feliz, finalmente decidiremos deixá-lo ir em período integral. Essa fase de ficar totalmente operacional é chamada de Implementação  no mundo do desenvolvimento de software.
  3. Continuamos recebendo feedback diário da criança, observamos todos os sintomas de abstinência, verificamos sua curva de aprendizado com base na qual decidimos se devemos continuar com a mesma escola no próximo ano ou não. É a  fase pós-projeto .

Com a abordagem DSDM , você terá qualquer projeto mais rápido “em funcionamento” e entregue mais cedo aos negócios com um esforço de implementação mais enxuto.

Fatores críticos de sucesso do DSDM

No DSDM uma série de fatores são identificados como sendo de grande importância para garantir o sucesso do projeto.

  • Fator 1: Inicialmente há a aceitação do DSDM pelo gerente Sênior e outros colaboradores. Isto garante que diferentes atores do projeto sejam motivados pelo início e demais envolvidos no projeto.
  • Fator 2: O segundo fator segue diretamente daqui e é o que a gerência de empenho garante como envolvimento do usuário final. A prototipagem requer um forte e dedicado envolvimento do usuário em testar e avalizar os protótipos funcionais.
  • Fator 3: Aqui se encontra o time do projeto. Este time deve ser composto por membros capacitados, um ponto importante é o empenho deste time. Significa que o time (um ou mais membros) possuem poder e permissões de tomar decisões importantes com relação ao projeto sem a necessidade de se formalizar propostas à alta gerência, o que seria um grande consumidor de tempo. De forma ao time estar apto a concluir um projeto com sucesso, é necessário também a escolha adequada da tecnologia. O que se refere ao ambiente de desenvolvimento, ferramentas de gerenciamento de projeto, etc.
  • Fator 4: Finalmente o DSDM define um relacionamento de suporte necessário entre o cliente e fornecedor. Isto vale para projetos que estão sendo realizados dentro da empresa ou por fornecedores. O documento que relata este suporte de relacionamento vem a ser o ISPL.

Comparação com outros tipos de desenvolvimento de software

Durante anos um grande número de métodos de desenvolvimento de sistemas tem sido desenvolvidos e aplicados, divididos em Métodos estruturados, métodos RAD e Métodos orientado a objetos. Muitos destes métodos demonstram similaridades um com outro e também com o DSDM. Por exemplo Programação Extrema(XP) também possui um formato iterativo ao desenvolvimento baseado com envolvimento do usuário.

O Rational Unified Process (RUP) é provavelmente o método mais similar ao DSDM assim é também o formato mais dinâmico de desenvolvimento de sistema de informação. Novamente o formato iterativo é utilizado neste método de desenvolvimento.

Como o XP e o RUP existem muitos outros métodos de desenvolvimento que demonstram similaridades com o DSDM, mas DSDM se diferencia por si só pelo número de caminhos que pode adotar. Primeiro temos um fato que produz uma ferramenta e um framework técnico independente.

Isto permite usuários preencherem etapas específicas do processo om suas próprias técnicas e escolhas de documentação de software. Outra funcionalidade exclusiva é o fato de que variáveis no desenvolvimento não são considerados recursos ou tempo, mas requisitos.

Assim garantimos os pontos principais do DSDM, marcados para se manterem no custo e prazo definidos. E por último o forte foco na comunicação entre e no envolvimento de todos responsáveis pelo sistema. Contudo isso é encontrado em outros métodos, DSDM acredita fortemente no comprometimento do projeto para garantir o sucesso do projeto.

Daily Meeting

Daily Meeting: qual é a Anatomia da Daily?

As daily meetings ou  stand-up tornaram-se um ritual comum de muitas equipes, especialmente no desenvolvimento de software Ágil. No entanto, existem muitos detalhes sutis que distinguem os stand-ups efetivos de uma perda de tempo.

Daily Meeting: Ficar de pé para manter uma reunião curta

A reunião diária stand-up (também conhecida como “daily scrum”, “daily huddle”, “morning roll-call”, etc.) é simples de descrever:

Toda a equipe se encontra todos os dias para uma rápida atualização de status. Nós nos levantamos para manter a reunião curta.

É isso aí, li o Scrum Guide e já sei fazer essa reunião. #SQN

Mas esta curta definição não lhe diz realmente os detalhes sutis que distinguem um stand-up efetivo de uma perda de tempo.

Então, como posso te explicar?

Para praticantes experientes, quando as coisas dão errado com o stand-up, eles vão saber instintivamente o que ajustar para corrigir a situação.

Para os novatos, quando as coisas dão errado, é muito menos provável que eles descubram o que fazer … e é muito mais provável que, sem assistência, eles simplesmente abandonem completamente a prática.

Isso seria uma pena, já que stand-ups bem administrados adicionam valor significativo às equipes.

Para lidar com isso, é importante explicitar os benefícios e as consequências de práticas comuns para os levantamentos diários. Esses padrões de reuniões diárias podem ajudar os praticantes menos experientes, bem como lembrar os praticantes mais experientes das razões por trás de sua intuição.

O que pode ser “bom”?

Vamos com uma pequena historinha:

O “Get Up Stand Up” de Bob Marley começa… agindo como um sino pavloviano quando a equipe se levanta para passear na frente da parede de cartões sem qualquer aviso adicional.

Essa música em particular faz parte de uma rotação programada que toca na mesma hora da manhã, todos os dias.

Algumas pessoas estão movendo cartões para seus pontos corretos no fluxo de trabalho, incluindo a afixação de Post-Its coloridos diferentes com notas adicionais. Algumas pessoas interessadas fora da equipe direta do projeto também perambularam para ver como as coisas progrediram.

Percebendo que a atividade na parede parou, o líder da equipe inicia um cronômetro grande que a equipe havia comprado anteriormente; Eles estavam interessados ​​em quanto tempo a reunião diária de stand-up realmente levaria.

Um dos membros da equipe se aproxima para falar sobre o cartão na parte mais à direita do quadro, mais próximo do ponto de implantação. Ele ainda está tendo alguns problemas com o script de implantação. Outro membro da equipe sugere que ela pode ajudar a resolver isso. A sequência continua da direita para a esquerda, de cima para baixo, pessoas descrevendo o que está acontecendo com cada um dos itens de trabalho e outras entrando em contato se puderem ajudar a resolver obstáculos. Do outro lado, o líder da equipe está registrando os obstáculos levantados no quadro de melhorias.

Em um ponto, há uma discussão um pouco mais longa que explora como lidar com um problema específico. Percebendo que vão se estender, o líder da equipe sutilmente levanta um dedo para interromper … pouco antes de uma das pessoas sugerir que eles devam falar sobre isso depois da reunião.

Pouco tempo depois, todos os cartões são cobertos e o líder da equipe pergunta se alguém tem mais alguma coisa para compartilhar. Alguém aponta uma ideia interessante que ela tinha sobre um novo recurso que tornaria obsoleto algo do que foi planejado. Isso desperta o interesse do Product Owner que sempre tenta comparecer aos stand-ups e ambos concordam em falar sobre isso depois.

O líder da equipe então revira os olhos enquanto a equipe inicia a tradicional cerimônia de encerramento “… 1 … 2 … 3 … Excelsior!” Não é coisa dele, mas ele teve que admitir, a reunião termina com uma nota alta.

As pessoas se separam e começam a discutir várias coisas que foram levantadas, incluindo os obstáculos, as novas ideias e perguntas sobre determinados itens de trabalho.

O conjunto particular de problemas que ocorrem quando as pessoas tentam trabalhar juntas

Reuniões em stand-up diárias são uma solução recorrente para um conjunto particular de problemas que ocorrem quando um grupo de pessoas tenta trabalhar em equipe.

Os stand-ups são um mecanismo para sincronizar regularmente para que as equipes …

  • Compartilhem a compreensão dos objetivos. Mesmo se pensássemos que nos entendíamos no começo (o que provavelmente não), nossa compreensão se desvia, assim como o contexto em que estamos operando. Uma “equipe” em que cada membro da equipe está trabalhando em direção a objetivos diferentes tende a ser ineficaz.
  • Coordenem os esforços. Se o trabalho não precisa ser coordenado, você não precisa de uma equipe. Por outro lado, se você tem uma equipe, eu assumo que o trabalho requer coordenação. A falta de coordenação entre os membros da equipe tende a levar a resultados ruins.
  • Compartilhem problemas e melhorias. Um dos principais benefícios de uma equipe versus trabalhar sozinho é que os membros da equipe podem ajudar uns aos outros quando alguém encontra um problema ou descobre uma maneira melhor de fazer algo. Uma “equipe” em que os membros da equipe não se sentem à vontade para compartilhar problemas e / ou não se ajudam mutuamente tende a ser ineficaz.
  • Identifiquem-se como uma equipe. É muito difícil se identificar psicologicamente com um grupo se você não se envolver regularmente com o grupo. Você não desenvolverá um forte senso de parentesco mesmo se acreditar que eles são capazes e que perseguem os mesmos objetivos.

Padrões de reuniões diárias de stand-up

Eu organizei os padrões para responder às seguintes perguntas:

  1. Quem atende?
  2. Sobre o que falamos?
  3. Em que ordem falamos?
  4. Onde e quando?
  5. Como podemos manter o nível de energia?
  6. Como incentivamos a autonomia?

Quem atende?🙋‍♀️🙋‍♂️🙋

Todos

Pessoas e representantes de várias áreas (por exemplo, marketing, apoio à produção, alta gerência, treinamento, etc.) desejam conhecer e / ou contribuir para o status e o progresso do projeto. A comunicação do status em várias reuniões e relatórios requer muito esforço duplicado.

Assim sendo

Substitua algumas ou todas as reuniões e relatórios pelo stand-up diário. Qualquer pessoa que esteja diretamente envolvida ou queira saber sobre o funcionamento diário do projeto deve participar da única reunião diária em pé.

Mas

As pessoas não envolvidas diretamente podem interromper o stand-up se não estiverem claras sobre o comportamento esperado. Isso pode ser resolvido simplesmente informando novos participantes e observadores das normas esperadas de antemão.

Nem todas as formas de relatórios serão, nem devem, ser cobertas pelo formato de stand-up. Por exemplo, o progresso geral do projeto seria melhor comunicado com um Gráfico grande e visível, como burn-up, diagrama de fluxo cumulativo, etc.

Itens de trabalho atendidos

Também conhecido como: stand-up com foco na história

se as histórias são tão importantes para o projeto, elas deveriam ser aquelas falando no standup – Brian Marick, “Latour 3: Anthrax e standups2

As pessoas estão muito concentradas nos corredores, não no bastão . Ou seja, todo mundo está ocupado, mas não necessariamente progredindo nos itens de trabalho.

Assim sendo

Em vez de pensar no stand-up diário como um ritual para as pessoas, pense nele como um ritual onde os Itens de Trabalho são atendidos (por exemplo, Histórias de Usuários em um contexto Ágil) e as pessoas só atendem para falar sobre itens de trabalho. Afinal, os itens de trabalho não podem realmente falar.

As perguntas dos Obstáculos de Ontem e de Hoje ainda podem ser usadas, mas serão da perspectiva do item de trabalho, e não da pessoa. Isso também significa que nem toda pessoa pode falar. Não há senso de obrigação de dizer qualquer coisa que não seja relevante para progredir no trabalho.

Por causa do foco mais claro, é mais provável que as pessoas aumentem e comecem a se levantar para remover os obstáculos sem avisar.

Mas

A falta de obrigação de falar pode esconder problemas com pessoas que são tímidas ou que não estão inclinadas a dizer qualquer coisa. Isso é mais difícil de detectar com um foco de item de trabalho.

Sobre o que falamos?🟢

Ontem, Hoje e Obstáculos

Também conhecido como: três perguntas

Algumas pessoas são falantes e tendem a se perder em Story Telling . Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema. Reuniões que demoram muito tendem a ter pouca energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Assim sendo

Estruture as contribuições usando o seguinte formato:

  1. O que eu fiz ontem?
  2. O que farei hoje?
  3. Quais obstáculos estão impedindo meu progresso?

Este é o número mínimo de perguntas que satisfazem os objetivos dos stand-ups diários. Outros tópicos de discussão (por exemplo, discussões de design, fofocas, etc.) devem ser adiados até depois da reunião.

Olve Maudal3 sugeriu que as perguntas fossem invertidas para enfatizar a ordem correta de importância:

  1. Quais os impedimentos no seu caminho?
  2. O que você está trabalhando hoje?
  3. O que você terminou desde ontem?

Lasse Koskela4 propôs outra forma dessas perguntas para enfatizar que os membros da equipe não devem se reportar ao líder:

Cada membro da equipe atualiza seus pares:

Por sua vez, cada membro da equipe fornece a seus colegas 3 informações:

  1. Coisas que fiz desde a reunião de ontem
  2. Coisas que vou fazer hoje
  3. Obstáculos que eu preciso de alguém para remover

Jonathan Rasmussen5 ofereceu uma redação diferente para mudar a dinâmica do stand-up:

  • O que você fez para mudar o mundo ontem
  • Como você vai “esmagar” hoje
  • Como você está indo para atravessar quaisquer obstáculos infelizes o suficiente para estar em seu caminho

Responder a esses tipos de perguntas muda completamente a dinâmica do stand-up. Em vez de apenas ficar lá e dar uma atualização, você está colocando tudo em linha e declarando sua intenção para o universo.

Há também várias equipes que adicionaram perguntas adicionais.

A empresa Buffer6 adicionou uma seção onde as pessoas compartilham algo em que estão trabalhando para melhorar a si mesmas.

Thomas Cagley7 sugere adicionar riscos .

Mark Levison8 achou útil adicionar mais perguntas de melhoria direcionadas.

As duas últimas perguntas seriam alteradas para corresponder ao contexto específico.

  1. O que você completou ontem?
  2. Com o que você se compromete hoje?
  3. Quais são seus impedimentos / obstáculos?
  4. Que código vamos “botar o nariz” / teste de unidade ausente / … você viu ontem?
  5. Que melhoria você fez no código ontem?

Mas

A estrutura não é tão importante quanto as informações fornecidas pelas respostas às perguntas. Se as informações forem fornecidas em um protocolo menos estruturado, não é importante se ater a uma lista de verificação. À medida que as equipes amadurecem, você pode achar que deseja ajustar a estrutura, o que é reflexo de como esse padrão já evoluiu.

A questão mais importante é se os Obstáculos do Ontem de Hoje estão criando um foco muito grande no compromisso pessoal versus prestar atenção nas coisas certas … o que leva ao Walk the Board .

Conselho de Melhorias👌

Também conhecido como: A placa de bloqueio, placa de impedimento, o jornal Kaizen. (sabe aquela equipe de transformação ágil? Então é essa mesmo!)

Obstáculos levantados no stand-up não são removidos ou resolvidos em tempo hábil.

Assim sendo

Postar obstáculos levantados para um Conselho de Melhorias. Este é um quadro branco visível publicamente ou gráfico que identifica obstáculos levantados e controla o progresso de sua resolução.

Um Conselho de Melhorias pode ser atualizado fora de stand-ups e serve como uma maneira mais imediata e talvez menos confrontante de inicialmente levantar obstáculos. Um erro comum é não escrever grande o suficiente para permitir que as pessoas leiam os bloqueios à distância.

O simples ato de escrever um problema e, portanto, reconhecê-lo explicitamente, é uma maneira muito confiável de reduzir conversas prolongadas. Assim, mesmo que nem todos concordem que qualquer item em particular é um obstáculo, vale a pena simplesmente escrevê-lo para discussão após o término da reunião.

Incluindo uma contagem de ocorrências com cada obstáculo aumentado destaca quais questões são geralmente mais importantes para lidar primeiro.

O design da placa pode variar de algumas maneiras. Por exemplo, uma estrutura de tabela como a seguinte:

Problema Contagem Contenção Contramedida Status
Nome do problema Contagem Contínua de Ocorrências Solução a curto prazo Solução de longo prazo baseada na análise de causa raiz A planta faz o ato de verificação

Outro estilo é mais como um quadro de tarefas:

To Do In Progress Done
Cartões de índice representando obstáculos levantados Cartas de obstáculos movem-se aqui quando estamos trabalhando ativamente nelas Cartas de obstáculos se movem aqui quando as resolvemos

Mas

O Conselho de Melhoria corre o risco de se transformar em um conselho de disputa se muitos obstáculos forem levantados sobre ele que a equipe não tem influência na resolução.

Em que ordem falamos?

Quem chega por último fala primeiro

Durante um stand-up, os participantes precisam saber quem deve falar primeiro. Fazer com que o facilitador decida quem deve falar primeiro é uma força sutil, mas definida, contra a auto-organização. A equipe deve saber sem intervenção que fala primeiro.

Assim sendo

Concordamos que a Última pessoa que chegar Fala Primeiro. Esta é uma regra simples que também tem o benefício adicional de incentivar as pessoas a serem pontuais em aparecer para o stand-up.

Contudo

A última pessoa a chegar acaba sendo a pessoa menos preparada para começar bem a reunião.

Round Robin (Rodízio)

Durante um stand-up, os participantes precisam saber quem deve falar em seguida. Ter um facilitador decidir quem fala a seguir é uma força sutil, embora definida, contra a auto-organização. A equipe deve saber sem intervenção que fala em seguida.

Assim sendo

Use uma regra predeterminada simples como um Round Robin para determinar quem deve ir em seguida. Não importa se é no sentido horário ou anti-horário. O que importa é que a equipe conduz a reunião, não o facilitador ou o gerente.

Passe o token🗝️

Com mecanismos de ordenação simples e previsíveis (por exemplo, Rodízio), é muito fácil para os participantes ignorarem outros oradores até que esteja mais próximo do seu turno. Pode haver uma tendência a pensar em outras coisas em vez de prestar atenção ao que os outros estão dizendo.

Assim sendo

Apresente um mecanismo de ordenação imprevisível, como jogar um token de fala (por exemplo, uma bola) para determinar quem deve falar em seguida. Ter um token de fala também simplifica a decisão de quem fala primeiro, pois será a pessoa que por acaso pegou o token (ou a primeira pessoa que jogar o token).

Jogar algo ao redor apresenta um pouco de diversão ao ritual de stand-up diário e, portanto, serve como um bom mecanismo de infecção para outras equipes de observação.

Eu aprendi primeiro sobre esse padrão em um projeto que eu estava onde usamos uma pequena bola de malabarismo, mas quase tudo pode ser usado como símbolo. Outras equipes usaram bolas de rugby9  ou até mesmo brinquedos de pelúcia10 .

Mas

Com equipes maiores, pode ser difícil lembrar quem já falou. Nesses casos, pode ser mais fácil manter mecanismos mais simples, como o Round Robin .

Dependendo da cultura da organização ou mesmo da equipe, jogar uma bola ao redor também pode ser visto como não profissional e criaria uma percepção negativa desnecessária do ritual.

Pegue um cartão🃏

Durante um stand-up, os participantes precisam saber quem deve falar primeiro e depois disso, quem deve falar em seguida. Ter um facilitador decidir quem deve falar é uma força sutil, mas definida, contra a auto-organização. A equipe não está interessada em passar o token, porque eles normalmente têm copos de café nas mãos.

Assim sendo

Peça a cada membro da equipe que pegue um cartão11 para determinar qual ordem falar. Imagine uma pilha de cartas, cada uma com um número. À medida que cada membro da equipe chega à reunião, eles podem selecionar um cartão que, em seguida, diz a eles em que ordem falar.

Walk the Board🏃

Também conhecido como: Walk the Wall

[S]tandups mantêm todos ocupados. [W]alking the board mantém todos focados nas coisas mais importantes.

– Bret Pettichord via Twitter

Outra questão com o formato convencional é que as tarefas ou fluxos de trabalho não são discutidos de forma coerente; em vez disso, cada assunto surge brevemente, dependendo da ordem em que os membros da equipe falam. Isso pode tornar difícil dizer o que realmente está acontecendo12 – Dave Nicolette.

As pessoas estão mais focadas em estar ocupadas do que realmente progredindo no trabalho, então você mudou para um modelo onde Atendem-se os Itens de Trabalho ao invés de pessoas, no entanto, mesmo com este item de trabalho focado em pé, ainda é difícil entender o que está acontecendo e encomendar mecanismos como Rodízio ou Passe o Token .

Assim sendo

Walk the board , ou seja, a estrutura do stand-up que percorre cada item de trabalho exibido em sua placa de gerenciamento visual.

A maioria das equipes Agile e Lean usará um sistema de gerenciamento visual para expor o que está sendo trabalhado. Para o desenvolvimento de software Ágil, isso pode ser chamado de “quadro de tarefas”, “parede da história” ou “quadro Kanban”.

Essas placas apresentarão um processo pelo qual os itens de trabalho serão movidos. O progresso é tipicamente representado por cartões que se movem fisicamente pelo tabuleiro. Idealmente, o posicionamento vertical indicará prioridade.

Com esta placa no lugar, o stand-up se move através de cada item de trabalho do fim do processo para o início do processo (por exemplo, da direita para a esquerda) e da maior para a menor prioridade (por exemplo, de cima para baixo). Você pode até mesmo indicar explicitamente no quadro-negro qual sequência deve ser usada.

Pawel Brodzinski13 propôs uma sequência padrão :

  1. Bloqueadores
  2. Expedir ou itens de emergência
  3. Itens que não foram movidos desde o último standup (provavelmente emperrados)
  4. Tudo que houver mais por prioridade

Mas

Obviamente, ter uma placa (lousa, quadro branco, parede de histórias)é um pré-requisito que nem todas as equipes terão. Nesse caso, uma estrutura pessoa por pessoa é mais apropriada.

Walk the Board tem uma tendência muito maior a sucumbir ao Reporte ao Líder se o Rotate the Facilitator ou algum outro padrão de auto-organização não for aplicado.

Onde e quando?

Conheça onde o trabalho acontece

Faça a reunião no gemba, não uma sala de conferências. – Marc Graban14

O local de trabalho tem muitos gatilhos de memória sobre o que está acontecendo.

Também não queremos que a reunião diária exija muita coordenação, localização e caminhada nas salas.

Assim sendo

Conheça onde o trabalho acontece , não em uma sala de reunião. Se você tem uma “parede de história” ou “quadro Kanban”, encontre-se em frente a isso.

Mas

Outras pessoas próximas podem achar o barulho da reunião perturbador. Isso normalmente indica um design de espaço de trabalho subjacente ruim, mas ainda deve ser reconhecido.

Mesmo Bat-Canal, Mesma Bat-Hora🦇

Queremos que a equipe tenha um senso de propriedade do stand-up. Também queremos que as partes interessadas possam aparecer para observar um stand-up para evitar a necessidade de agendar outra reunião de status. Isso é difícil se qualquer membro específico da equipe puder forçar um atraso ou uma mudança de local do stand-up.

Assim sendo

Faça com que a equipe concorde e execute o stand-up diário no mesmo local, na mesma hora . Não espere por retardatários, incluindo arquitetos e gerentes. A reunião é para toda a equipe, não para qualquer indivíduo em particular. Isto é especialmente importante se você usar o Stand-up para começar o dia .

Algumas equipes mais rigorosas podem impor uma “multa” aos retardatários. Eu tenho a tendência de desconfiar de qualquer tipo de mecanismo de punição e prefiro discutir.

Mas

Mesmo Lugar, Mesmo Tempo não se destina a ser cegamente inflexível. O importante é que a hora de início seja mais consistente e o reescalonamento seja raro. Se o reagendamento for solicitado com frequência, pode ser uma indicação de que o horário de início deve mudar. Se um local específico é inconveniente para todos, provavelmente é uma indicação de que o local deve mudar.

Use o Stand-up para começar o dia

A reunião diária stand-up fornece foco e consciência de questões pendentes. Se ocorrer no final do dia, esse foco e consciência são desperdiçados.

Assim sendo

Use o Stand-up para começar o dia . Com horários de trabalho flexíveis, nem todos os membros da equipe chegam ao trabalho ao mesmo tempo. Uma prática comum com “flex-time” é usar um conjunto de horas de trabalho básicas.

O horário de início deve estar no início dessas horas de trabalho principais. Da mesma forma, se os membros da equipe precisarem chegar mais tarde por motivos pessoais (por exemplo, precisar deixar as crianças na escola), a hora de início deve ser definida para que todos possam comparecer.

Mas

Pode haver uma tendência para não trabalhar em qualquer tarefa relacionada ao projeto até o stand-up. Se a reunião stand-up começar o dia … Mais tarde, esse tempo de folga pode ser significativo.

Até certo ponto, isso pode simplesmente ser usado como uma oportunidade para verificar e-mails, preencher planilhas de horas, etc., mas pode valer a pena investigar a remoção do stand-up como um ritual de “início do dia”, agendando-o no final do dia. .

Não use o stand-up para começar o dia

O stand-up tende a servir como o ritual para definir o foco do dia, especialmente se você usar o stand-up para começar o dia . Por causa disso, os membros da equipe tendem a não trabalhar em recursos até o stand-up.

Quando a reunião não é realmente realizada em primeiro lugar, essa tendência pode ter um impacto significativo na produtividade.

Assim sendo

Não use o stand-up para começar o dia . Programe a reunião diária até o dia em que ela não estará psicologicamente associada ao início do dia.

Mas

Se a reunião diária não começar o dia, ela não poderá mais ser usada como um ritual compartilhado para definir o foco da equipe no início do dia. Dependendo da equipe, esse preço pode não valer o aparente aumento de eficiência.

Quando há muitos projetos usando stand-ups, é possível que vários stand-ups estejam ocorrendo simultaneamente. Observadores interessados ​​em múltiplos projetos podem querer mudar os tempos de stand-up para permitir que eles possam participar.

Isso é problemático, pois arrisca o senso de propriedade da equipe se um observador forçar um stand-up a se ajustar à sua agenda. No entanto, isso também deve ser uma consideração ao decidir quando ter o stand-up diário.

Como podemos manter o nível de energia?

Amontoado 👥

O problema que eu frequentemente vejo surgir é que as pessoas tendem a tratar o Daily Stand-up como simplesmente reportagem individual. “Eu fiz isso . . . Eu farei isso – então, para a próxima pessoa. A abordagem mais otimista está mais próxima de um amontoado de futebol. – Jeff Sutherland15

O volume de fala afeta a atenção, bem como a eficácia da comunicação. A distância física altera o nível de volume necessário para se comunicar bem. Algumas pessoas não falam alto e não se sentem à vontade tentando.

Assim sendo

O stand-up deve ser mais de um Huddle do que uma reunião. Se é difícil ouvir, aproxime todos. Além de permitir um volume de fala mais descontraído, estar fisicamente mais próximo tende a fazer com que os participantes fiquem mais atentos por conta própria.

Ser capaz de ficar fisicamente mais próximo também é uma expressão de maior confiança dentro da equipe. Se o stand-up é uma coisa nova, geralmente é o suficiente para usar gestos de mão para acenar para as pessoas e dizer algo para o efeito de “Vamos trazê-lo”.

Agora se o tamanho do círculo tiver sido estabelecido por algum tempo, pense em explicar as razões para fechar o círculo antes de tentar reduzi-lo.

Mas

A equipe deve equilibrar a proximidade com as zonas de conforto pessoal. Mesmo em uma equipe muito confiante, há um ponto em que as pessoas estão apenas perto demais para o conforto. Os sintomas tendem a ser participantes tensos e / ou inquietos.

Stand Up🧍‍♂️

Algumas pessoas são falantes e tendem a se perder em Story Telling . Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema.

Reuniões que demoram muito tendem a ter baixa energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Assim sendo

Peça a todos os participantes que se levantem durante a reunião. Ficar de pé faz uma ligação física com a prontidão mental. O desconforto físico também lembrará os participantes quando uma reunião estiver demorando demais.

Sobretudo uma maneira simples de encorajar isso é simplesmente realizar a reunião onde não há cadeiras.

Mas

Levantar-se tende a fazer com que as reuniões diminuam, mas não garante que elas encurtarão para uma duração ideal. As pessoas podem aprender a lidar com o desconforto em vez de tomar uma resposta mais apropriada.

Além disso, se as reuniões não estão demorando muito, nem se afastando do assunto, ficar de pé é um ritual desnecessário.

Quinze minutos ou menos

A maioria das pessoas vai vagar mentalmente quando estão em longas reuniões. Um longo e monótono encontro é uma maneira horrível e desgastante de começar o dia.

Portanto um número específico ajuda a lembrar-nos quando considerar o ajuste para reduzir o tempo da reunião.

Entretanto

Mantenha os stand-ups diários para quinze minutos ou menos . Como regra geral, depois de quinze minutos, a mente da pessoa média vai vagar, o que não ajuda a manter o foco.

Mas

Quinze minutos podem ser longos demais para equipes menores. Por causa do efeito “Dory” (vaguear pela mente e se esquecer da busca ao Nemo), mesmo para equipes maiores, quinze minutos é um bom limite.

Além disso, também é possível ter uma reunião que é muito curta, e no final, os participantes ainda não terem ideia do que está acontecendo ou com quem conversar para descobrir.

Sinalizar o Fim🔴

Depois que a última pessoa tiver falado, a equipe pode não perceber imediatamente que a reunião acabou. A percepção gradual de que é hora de ir embora não encerra a reunião com uma nota alta e pode contribuir para a Baixa Energia.

Assim sendo

Sinalize o fim do stand-up com uma frase descartável16 (por exemplo, “Bem, aproveitem seu café/almoço”, “3…2…1….Excelsior!” ) ou alguma outra ação.

O tempo das reuniões

É difícil julgar qualitativamente se um stand-up está demorando demais, especialmente se ele só aumenta gradualmente de tamanho.

Assim sendo

Anote o tempo das Reuniões e publique os resultados. Na maioria das vezes, os participantes simplesmente não percebem o impacto do Story Telling, não estão preparados para o Take Off Offline ou não estão preparando o tempo de duração da reunião. Faça de modo quantificável.

Mas

Tal como acontece com todas as medidas, o calendário das reuniões não deve ser introduzido a menos que exista uma meta real a cumprir devido a um problema com os níveis de energia. Uma vez que o objetivo seja alcançado, a medição deve ser descartada.

Medir sem nenhuma razão específica leva à suspeita e à métrica da apatia.

O tempo é um proxy para energia, atenção e ritmo. Preste mais atenção a essas coisas do que ao tempo.

Take it Offline

Algumas pessoas querem se envolver na Solução de Problemas imediatamente após ouvir um problema. Reuniões que demoram muito tendem a ter baixa energia e os participantes não diretamente relacionados a uma longa discussão tendem a se distrair.

Ainda é importante reconhecer que mais discussões serão necessárias para resolver o problema levantado. Algumas pessoas podem achar desconfortável reforçar a estrutura do stand-up fazendo uma interrupção.

Assim sendo

Use uma frase simples e consistente como “Falamos Offline” como um lembrete de que tais discussões devem ocorrer fora do stand-up diário.

Se a discussão foi Socializar , nada mais é necessário. Se a discussão foi sobre Solução de Problemas, o facilitador (e eventualmente apenas a equipe) deve garantir que as pessoas certas sejam nomeadas ou se inscrevam para lidar com a questão mais tarde.

Alternativamente, algumas equipes usam mais sinalização indireta.

Por exemplo, Mike Cohn17 descreveu um que usa um rato de borracha para indicar “estamos caindo em um buraco” .

Já Benjamin Mitchell descreveu uma Regra de Duas Mãos18

… se alguém acha que a conversa atual saiu do assunto, ou não é mais eficaz, então eles levantam a mão. Uma vez que uma segunda pessoa levanta a mão, isso é um sinal para parar a conversa e continuar com o resto do stand up. Aqueles que falam podem continuar a conversa depois que o stand up terminar.

Mas

Existe uma diferença entre a Solução de Problemas e uma questão de esclarecimento. Informações que não são compreendidas não são úteis.

Já a extensão em que as perguntas esclarecedoras são permitidas deve variar dependendo de quão grande é a equipe, e se afetará os 15 minutos ou menos .

Como incentivamos a autonomia?

Rodízio do Facilitador 🍢

Os membros da equipe estão se reportando ao líder , ou seja, eles estão conversando apenas com o facilitador da reunião, em vez de um com o outro.

Somente o facilitador da reunião está levantando e abordando questões relacionadas ao processo de stand-up.

Da mesma forma queremos que a equipe se aproprie do stand-up e isso requer a remoção de qualquer dependência de um único facilitador.

Assim sendo

Troque sempre o Facilitador . Gire a atribuição de uma função responsável por garantir que as pessoas assistam ao stand-up e cumpram as regras acordadas.

Mas

Equipes que não são experientes com stand-ups se beneficiam muito de ter um coach experiente no processo. É mais que a equipe deva ser levada a assumir maior controle do stand-up.

Eventualmente em algum momento, nenhum facilitador explícito deve ser exigido.

Quebrar o contato visual

Os membros da equipe estão se reportando ao líder , ou seja, eles estão conversando apenas com o facilitador da reunião, em vez de um com o outro.

Queremos que a equipe se aproprie do stand-up e isso requer a remoção de qualquer dependência de um único facilitador.

Assim sendo

O facilitador deve quebrar o contato visual como uma maneira sutil de lembrar ao palestrante que ele / ela deve estar se dirigindo à equipe, não apenas a uma pessoa. Uma maneira de fazer isso é se movimentar para que o orador atual não possa ver o facilitador.

Como sabemos quando um stand-up está indo mal?

Eu suportei reuniões stand-up regulares por três anos. O que tornou as reuniões mais dolorosas foi meu chefe (vou chamá-lo de Wally). Sua principal razão para a reunião de stand-up não era aumentar a eficiência ou abraçar o XP tanto quanto encurtar a interação humana além de qualquer coisa diretamente relacionada ao produto de trabalho. … Para Wally, no entanto, a reunião stand-up (como a reunião de segunda-feira às 7 da manhã e a reunião de sexta-feira às 5 da tarde) foi um teste de lealdade destinado a reforçar a relação empregador-empregado. – Phillip A. Laplante19

Há “cheiros” quando você está de pé que são indicadores muito bons de que as coisas estão dando errado. É importante notar que, mesmo que você não tenha sentido nenhum, isso não significa que o stand-up está dando certo. Significa apenas que ele ainda não fede.

Eventualmente a maioria dos odores a seguir está vinculada aos padrões anteriores. Para aqueles que não o são, os problemas subjacentes tendem a ser mais sutis ou fora do escopo do stand-up diário, e as pessoas terão que criar suas próprias soluções.

Focado nos corredores, não no bastão

As pessoas estão muito concentradas no que estão fazendo, mas negligenciam considerar se suas atividades estão realmente progredindo no trabalho. Renove o stand-up de tal forma que seja focado no Atendimento dos Itens de Trabalho.

Reportando-se ao Líder🗣️

Os membros da equipe estão enfrentando e conversando com o gerente ou com o facilitador da reunião, em vez de com a equipe. Isso indica que o stand-up diário é para o gerente / facilitador quando na verdade deveria ser para a equipe.

Contudo existem várias maneiras de quebrar essa dependência: Troque o Facilitador , Interrompa o contato visual, mude a forma dos Obstáculos de Ontem Hoje, use Passar o Sinal, etc.

As pessoas estão …sempre… atrasadas🐢

Isto é endereçado diretamente pelo Mesmo Lugar, Mesmo Tempo , mas como mencionado pode indicar que o stand-up está sendo realizado na hora errada ou no lugar errado.

Existem outros padrões para responder a isso, como impor uma multa. No entanto, eu geralmente não os recomendaria, pois implicam que a questão é sobre motivação extrínseca quando é muito mais provável que seja outra coisa.

Stand-up de início do dia … Antes tarde do que nunca? #SóQueNão

Porque o stand-up é visto como uma boa prática para começar o dia de trabalho, nenhum trabalho é realizado antes do stand-up.

Dependendo de como é o final da manhã, isso pode ter um impacto significativo nas horas de trabalho disponíveis. Isso leva a Não usar o stand-up para começar o dia .

Socializar🤝

Um dos objetivos do stand-up é aumentar a socialização da equipe. No entanto, o stand-up diário não se destina a que os membros da equipe “acompanhem” uns aos outros sobre assuntos não relacionados ao projeto.

É difícil fornecer exemplos disso, pois o grau em que a socialização passa de criação de equipe a distração varia de equipe para equipe. O limiar pode ser detectado a partir dos comportamentos dos participantes não envolvidos diretamente na socialização.

Portanto se os níveis de energia deles permanecerem altos, então provavelmente é apenas formação de equipe; Se os níveis de energia caírem, então use o Take It Offline e talvez forneça outro fórum para atuar como um Water Cooler20.

Eu não me lembro😧

O que eu fiz ontem? … Eu não consigo lembrar … O que eu estou fazendo hoje? … Eu não sei …

A falta de preparação causa um ritmo mais lento, o que causa menos energia. Também corre o risco de falhar quinze minutos ou menos , o que reduz ainda mais os níveis de energia.

Da mesma forma, uma boa maneira de contornar esse problema é mudar para um stand-up onde os Itens de Trabalho são atendidos e Nós Walk the board.

Caso contrário, é uma questão de expectativa de responsabilidade saber as respostas para os Obstáculos Ontem de Hoje .

Narrativa (Story Telling)🎙️

Em vez de fornecer uma breve descrição de um problema, o participante fornece detalhes e contexto suficientes para fazer os outros se sintonizarem.

Então a regra geral é identificar os obstáculos durante o stand-up e discutir os detalhes após o stand-up. Isso pode ser resumido como “Diga o título, não toda a história” ou ” Take it Offline” .

Solução de problemas⚠️

É hora de levantar questões e idéias superficiais, não é hora de resolver problemas em profundidade. – Marc Graban21

Inclusive a chave para manter os Stand-up Com 15 minutos ou menos é limitar o Story Telling e não sucumbir à Solução de Problemas durante a reunião. Coloque-o offline .

Energia baixa🔋

Pode indicar um abrandamento do ritmo devido a narração de histórias, resolução de problemas, etc. Nesse caso, coloque-o offline. Poderia ser simplesmente uma questão do tamanho da equipe. Pode ser a hora do dia que sugere tentar a alternativa de usar o stand-up para começar o dia e não usar o stand-up para começar o dia .

Obstáculos não levantados📖

Também conhecido como: Travelogue22

Pode haver várias razões para os obstáculos não serem levantados. Não lembrando, o alto limiar de dor, falta de confiança em levantar questões (porque os Obstáculos não são Removidos ), nenhuma maneira conveniente de levantar questões, etc.

Contudo o facilitador deve ter o cuidado de encorajar as pessoas a levantar obstáculos.

Já a introdução de um Conselho de Melhorias também pode fornecer um meio menos confrontante. Retrospectivas são uma forma eficaz de descobrir a razão subjacente pela qual os Obstáculos não são levantados .

Obstáculos não removidos

Com a exceção de um ambiente de culpabilização, o caminho mais seguro para impedir que as pessoas levantem mais obstáculos é simplesmente não removê-las. Para dificultar o esquecimento e/ou ignorar os obstáculos, acompanhe-os publicamente com um Conselho de Melhorias .

Obstáculos só são levantados no stand-up

Os stand-ups funcionam como uma rede de segurança. Na pior das hipóteses, um obstáculo maior será comunicado à equipe um dia. No entanto, fazer stand-ups não se destina a impedir que os problemas sejam levantados e resolvidos durante o dia. A introdução de um meio alternativo para levantar obstáculos, como um Conselho de Melhorias, pode ajudar. Se não, as razões subjacentes podem ser descobertas usando retrospectivas.

Daily Assíncrona🕊️

Recentemente adotamos a daily assíncrona na Agile Practice Center. Após o hiato de 2 anos em times remotos na pandemia, e como os fusos horários são diferentes adotamos a daily escrita em uma plataforma.

Contudo

É preciso ficar de olho para não deixar pessoas de fora e tratar os impedimentos assim que possível.

Entretanto

Nem sempre podemos resolver os itens na mesma hora.

No final o que fazemos é realmente apenas ficar de pé todos os dias

Espero que este artigo forneça mais detalhes sobre os detalhes sutis de práticas de stand-up efetivas e também indicadores comuns de problemas. Deve ficar claro que um stand-up diário não é apenas ficar juntos todos os dias.

No final do dia, é importante não estar muito preocupado em ter todos os padrões ou até mesmo “sentir alguns dos cheiros”.

Lembre-se dos problemas que estamos tentando resolver. As pessoas estão energizadas? As pessoas compartilham problemas e ideias? As pessoas estão focadas em nossos objetivos? As pessoas estão trabalhando juntas como uma equipe? Todo mundo sabe o que está acontecendo?

Se você puder responder a essas perguntas afirmativamente, a reunião provavelmente está indo bem. Afinal, é só ficar de pé todos os dias.

Método AgilePgM®

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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 Framework21 é 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.

Feedback: Bomba ou Presente?

Acredito firmemente que o feedback é uma dádiva. Muitas pessoas, líderes de projeto inclusive, se enterram em um buraco e continuam cavando e cavando. Em vez disso, eles precisam largar a pá e agarrar a escada.

Essa escada é o feedback. É o melhor lugar para começar quando você não tem nenhum outro lugar para ir e se encontra em um ponto crítico. O feedback é a oferta definitiva e, quando utilizado corretamente, irá impulsionar você e sua equipe para o sucesso.

Mas existe realmente um segredo para fazer isso com eficácia? Ai sim. Em minha experiência, os líderes mais bem-sucedidos fazem essas três coisas ao dar feedback.

1. Procure feedback

Em primeiro lugar, os líderes buscam seu próprio feedback. Como gerente de projeto, scrum master, product owner, product manager, etc. …, você é responsável pelo sucesso de sua equipe, e é por isso que precisa começar melhorando suas habilidades antes de passar para as deles. Ao solicitar uma avaliação de seu desempenho, você poderá se comunicar com sua equipe de forma mais eficaz e, o mais importante, demonstrar que a responsabilidade é uma via de mão dupla .

Entretanto você precisará fazer isso sabendo que os resultados provavelmente serão difíceis de ouvir. No início de minha carreira, trabalhei meu caminho até me tornar um dos gerentes de topo em minha empresa, mas como líder, eu estava lutando. Meu gerente direto me disse sem rodeios: “Você é excelente e um dos melhores que temos; no entanto, ninguém quer trabalhar com você.” Ai. Por mais difícil que seja para mim ouvir, aquele feedback foi um dos maiores presentes que já recebi em minha carreira. Isso me levou a agir e a buscar uma maneira melhor de administrar.

Ou seja, ao pedir feedback à sua equipe, não discuta, não defenda. Ouça e use o que eles estão dizendo como um meio de melhorar. O que eles estão dando a você é um presente que você pode usar para impulsionar a si mesmo e a sua equipe. E em breve sua equipe também solicitará feedback.

2. Aumente o feedback positivo

Os membros da equipe precisam ouvir o que estão fazendo bem. Nem todo feedback pode ser positivo, mas é vital destacar as vitórias sobre as derrotas. Pode ser fácil focar nas deficiências ao fornecer feedback, mas o pessimismo pode ser prejudicial no local de trabalho. Isso não significa que você não possa sugerir áreas para melhorar, mas quem aspira à grandeza quando parece infrutífero de qualquer maneira? Existe um equilíbrio. Felizmente, uma atmosfera de trabalho negativa pode ser revertida e a maneira mais fácil de fazer isso é com positividade.

De acordo com a Harvard Business Review , “Um grande e crescente corpo de pesquisas sobre psicologia organizacional positiva demonstra que … um ambiente positivo levará a benefícios dramáticos para empregadores, funcionários e resultados financeiros.”

Como isso se traduz em feedback eficaz? Simples: “pegue” as pessoas fazendo as coisas certas . Comemore essas vitórias e amplie os pontos positivos. Deixe seus colegas de equipe saberem o quanto você valoriza a contribuição deles. Isso não apenas os inspira a desenvolver seus pontos fortes, mas também permite que eles sintam autonomia e propriedade nas organizações. Eles vão querer ver a equipe como um todo prosperar.

3. Forneça feedback saudável

Enfim, fornecer um relatório positivo é vital – ele prepara você para fornecer um feedback saudável . Ninguém quer ouvir feedback apenas por feedback. Este processo deve ser intencional com o objetivo final de ver a melhoria. Será fácil para você ou para o membro da equipe? De jeito nenhum, mas vai valer a pena.

Ainda assim considere quando você entrar em uma academia. Seu treinador é sua pessoa favorita quando o está empurrando para correr mais um quilômetro ou fazer mais uma flexão? Provavelmente não. No entanto, eles sabem que o resultado desejado de sua jornada de fitness não é apenas transformar seu corpo. É viver a vida em sua plenitude. Poder correr com seus filhos, curtir suas roupas, se sentir mais forte e fazer o que quiser.

Da mesma forma como líderes de projeto, temos a tarefa de liderar nossas equipes de maneira semelhante – responsabilizá-los e fornecer motivação, especialmente quando é difícil para que possam ter sucesso. Isso é o que considero um feedback saudável. É intencional e exige que ambas as partes superem as dificuldades como meio de crescimento.

Da mesma forma: Você pode empregar feedback sem afastar sua equipe? Absolutamente. Lembre-se de que você está dando um presente a eles. Pode não ser um presente que eles acham que querem, mas é para o bem maior. Se você se concentra no positivo e é deliberado com suas palavras, não vai esmagar a alma deles com críticas; você fornecerá feedback para liberar todo o seu potencial.

Como lidar com o feedback?

Da mesma forma como a cultura do escritório, o feedback sobre o seu trabalho vem de várias formas (nem todas agradáveis). Você pode apresentar seu primeiro plano de projeto a um comitê de direção e tê-lo feito em pedaços porque não considerou algum fator do qual você nem mesmo está ciente.

Ainda assim aprender como lidar com o feedback é uma habilidade importante. Verifique que deixou seu ego na porta quando alguém critica seu trabalho – e nunca responda imediatamente. Às vezes, “não” significa “não”. Resista à tentação de discutir; os tomadores de decisão podem ter uma série de motivações sobre as quais você pouco sabe. Em vez disso, reserve um tempo depois para se conectar com pessoas que podem fornecer feedback.

Portanto ao encontrar pessoas que fornecem feedback valioso de forma consistente, considere pedir-lhes que ajam como mentores que podem ajudá-lo a aumentar suas habilidades e valor dentro da organização.

Faça perguntas

Há tanto que você pode não saber sobre diferentes grupos. Pergunte. Vamos começar conversas de aprendizagem e ouvir sem julgamento. Lembre-se: nossas experiências e realidades são diferentes. Reconheça que uma pessoa não pode falar por todos aqueles “como eles” porque existem subculturas dentro de diversas culturas.

Mas não há nada de errado em ampliar sua perspectiva. Será mais confortável fazer perguntas se você já estiver praticando ser um gerente e colega inclusivo. Se não, comece com algumas das outras estratégias primeiro para criar um ambiente de confiança.

Obtenha feedback

Em suma como líder, obtenha feedback. Considere uma pesquisa anônima anual ou semestral para descobrir o que você poderia fazer melhor nessa área. É tudo uma questão de aprender e crescer profissionalmente e como pessoa. Comece sendo atento, aberto, transparente e emocionalmente inteligente. Seja um apoiador, um aliado e um defensor de sua equipe em termos de oportunidades. Quando um membro da equipe sente que pode ser “quase todo o seu eu” com você, ele se entregará totalmente ao trabalho também.

Método AgilePM®

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 International23 é 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

AgilePM®

As fases do AgilePM® são:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Agile-Agile Blended

Método Agile-Agile Hybrid ou Agile Blended

Agile-Agile Hybrid é uma combinação de diferentes metodologias ágeis, como Scrum e Kanban, que são adaptadas para atender às necessidades específicas de um projeto ou equipe.

Ele permite que as equipes utilizem as melhores práticas de cada metodologia para criar um processo de trabalho personalizado e flexível que atenda às suas necessidades específicas.

O objetivo do híbrido Agile-Agile é maximizar a eficiência e eficácia do processo de desenvolvimento, garantindo a entrega de valor ao cliente de forma rápida e contínua.

Agile-Agile Hybrid também é conhecido como Agile Blended. A origem do termo “Agile Blended” não é conhecida com precisão, mas surgiu mais ou menos no início dos anos 2000,  este termo “Agile Blended” é usado como uma forma de descrever uma abordagem de combinação de metodologias ágeis para atender às necessidades específicas de um projeto ou de uma equipe e obter o melhor disso. metodologias ágeis existentes.

Além do Scrum e do Kanban, outras metodologias ágeis que podem ser utilizadas no Agile-Agile Hybrid e incluem:

  • Extreme Programming (XP): Uma metodologia ágil que enfatiza a programação em equipe, comunicação aberta e simplicidade.
  • Lean: metodologia baseada na filosofia da manufatura enxuta, que tem como foco a maximização do valor para o cliente e a minimização de desperdícios.
  • Crystal: Uma metodologia ágil que se concentra em atender às necessidades do cliente, adaptando-se às mudanças e garantindo a qualidade do software.
  • Dynamic System Development Method (Método de Desenvolvimento de Sistemas Dinâmicos) (DSDM): é uma metodologia ágil que enfatiza a entrega de projetos no prazo, no orçamento e na qualidade, por meio do uso de equipes multidisciplinares e colaboração constante com o cliente.
  • Feature-Driven Development (FDD): é uma metodologia ágil que foca na entrega de pequenos incrementos de funcionalidade, com o objetivo de entregar continuamente valor ao cliente.

Estas são algumas das metodologias ágeis que podem ser utilizadas no Agile-Agile Hybrid, mas existem muitas outras opções disponíveis, e quais metodologias utilizar dependerão das necessidades específicas do projeto e da equipe.

 

Quem criou o Agile-Agile Hybrid?

A metodologia híbrida Agile-Agile não foi criada por uma pessoa ou organização específica. Em vez disso, é uma abordagem nascida da necessidade de equipes e organizações adaptarem diferentes metodologias ágeis para atender às suas necessidades específicas.

Não há uma data específica para a criação da metodologia híbrida Agile-Agile, pois é uma evolução das metodologias ágeis existentes como Scrum, Kanban, XP e outras, e vem sendo desenvolvida gradativamente ao longo do tempo. a maioria dessas metodologias em um processo.

Qual a porcentagem de equipes ágeis que usam o Agile-Agile Hybrid?

Não há dados concretos sobre quantas equipes ou empresas estão usando o Agile-Agile Hybrid, mas o número provavelmente será significativo, pois muitas equipes e empresas estão adotando abordagens ágeis para desenvolvimento de software e outros projetos.

De acordo com uma pesquisa realizada pela VersionOne em 2019, cerca de 85% das equipes de desenvolvimento de software usaram alguma forma de metodologia ágil. Destes, 37% usaram Scrum, 35% usaram uma abordagem híbrida e 11% usaram Kanban.

Além disso, uma pesquisa realizada pela Scrum Alliance em 2018 mostrou que 85% das equipes de desenvolvimento de software usavam Scrum, enquanto outros 15% usavam outras metodologias ágeis, incluindo Agile-Agile Hybrid.

Essas pesquisas mostram que o Agile-Agile Hybrid é uma abordagem cada vez mais usada, mas ainda não há dados concretos sobre a porcentagem de equipes ou empresas que usam essa metodologia.

Onde posso encontrar mais informações sobre o método híbrido Agile-Agile?

Existem várias fontes onde você pode encontrar mais informações sobre o Agile-Agile Hybrid, algumas das quais incluem:

  • Artigos de especialistas e postagens de blog sobre metodologias ágeis: Muitos especialistas e autores escrevem sobre Agile-Agile Hybrid e outras metodologias ágeis. Alguns deles incluem Alistair Cockburn, Jim Highsmith, Mike Cohn, Ken Schwaber, Dave West e muitos mais24.
  • Comunidades online: Existem várias comunidades online, como LinkedIn, Agile Alliance e Scrum Alliance, onde você pode encontrar informações sobre o Agile-Agile Hybrid, bem como discussões e dúvidas sobre a metodologia.
  • Conferências e Conferências: Existem várias conferências e eventos relacionados a metodologias ágeis, como Global Agile Alliance Conference, Global Scrum Alliance Summit e Agile Development Conference, onde você pode ouvir especialistas falarem sobre Agile-Agile Hybrid e outras metodologias ágeis.
  • Cursos e treinamentos: diversos cursos e treinamentos estão disponíveis online e presenciais sobre Agile-Agile Hybrid e outras metodologias ágeis, oferecidos por organizações como Scrum Alliance, Agile Alliance, International Institute for Learning (IIL) e muitas outras.
  • Effective Project Management: Traditional, Agile, Extreme, Hybrid Livro

Além disso, há também uma série de livros escritos por especialistas no assunto, um deles é “Hybrid Agile: Achieving Enterprise Agility” de Scott Ambler e Mark Lines.

Existem funções, artefatos, cerimônias, princípios, fases e/ou estágios no híbrido Agile-Agile?

Sim, existem funções, artefatos, cerimônias, princípios, fases e estágios no híbrido Agile-Agile, embora possam variar dependendo da metodologia ágil específica utilizada.

Alguns exemplos de papéis comuns incluem:

  • Scrum Master
  • Product Owner
  • Desenvolvedores

Alguns exemplos de artefatos comuns incluem:

  • Product Backlog
  • Sprint Backlog
  • Incremento

Algumas cerimônias comuns incluem:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Alguns princípios comuns incluem:

  • Entregar valor para o cliente de forma rápida e contínua
  • Se adaptar a mudanças
  • Trabalhar em equipe
  • Comunicação aberta e transparência

Algumas fases comuns incluem:

  • Planejamento
  • Desenvolvimento
  • Entrega
  • Manutenção

Alguns estágios comuns incluem:

  • Análise
  • Projeto
  • Construção
  • Implantação
  • Manutenção

É importante observar que essas funções, artefatos, cerimônias, princípios, fases e estágios podem variar dependendo da metodologia ágil específica que está sendo usada, e algumas metodologias ágeis não utilizam todos esses elementos.

Quantos métodos ágeis posso misturar no Agile-Agile Hybrid?

Não há um número específico de metodologias ágeis que você pode combinar no Agile-Agile Hybrid, mas é recomendável usar apenas metodologias ágeis relevantes para seu projeto e sua equipe. O uso de muitas metodologias diferentes pode tornar o fluxo de trabalho complexo e difícil de gerenciar.

Ao misturar metodologias ágeis, é importante garantir que elas se complementem e não sejam redundantes, e que você esteja ciente das implicações de usar essas metodologias juntas. Além disso, é importante que as metodologias sejam adaptadas para atender às necessidades específicas do projeto e da equipe.

Ao decidir quais metodologias ágeis usar, é importante considerar as necessidades do projeto, como tamanho, complexidade, duração e finalidade, bem como as necessidades da equipe, como habilidades, experiência e preferências. Em geral, recomenda-se usar apenas o número necessário de metodologias para atender às necessidades do projeto e da equipe sem tornar o processo de trabalho muito complexo.

Vantagens e Desvantagens do Uso do Agile-Agile Hybrid

Agile-Agile Hybrid é uma abordagem ágil que combina diferentes metodologias ágeis como Scrum, Kanban e outras para atender às necessidades específicas de um projeto ou equipe. Ele permite que as equipes utilizem as melhores práticas de cada metodologia para criar um processo de trabalho personalizado e flexível que atenda às suas necessidades específicas.

Um dos principais benefícios do híbrido Agile-Agile é que ele permite que as equipes se adaptem às mudanças e entreguem valor ao cliente de forma rápida e contínua. Isso é possível por meio do uso de metodologias ágeis, que enfatizam o trabalho em equipe, a comunicação aberta e a transparência e a criação de valor para o cliente de forma rápida e contínua. Além disso, o híbrido Agile-Agile permite que as equipes aproveitem o melhor de diferentes metodologias ágeis, como Scrum, Kanban e outras, para atender às necessidades específicas do projeto e da equipe.

No entanto, é importante observar que o híbrido Agile-Agile também apresenta algumas desvantagens. A primeira é que pode ser difícil de gerenciar e implementar, especialmente se você usar muitas metodologias diferentes. Além disso, pode ser difícil garantir que as diferentes metodologias se complementem e não sejam redundantes.

Para garantir o sucesso do Agile-Agile Hybrid, é importante escolher as metodologias ágeis certas e adaptá-las para atender às necessidades específicas do projeto e da equipe. É importante ter em mente que o objetivo final é entregar valor ao cliente de forma rápida e contínua, e que as metodologias escolhidas devem ser capazes de fazer isso. Além disso, é importante contar com uma equipe multidisciplinar qualificada para trabalhar com diferentes metodologias.

Em resumo, Agile-Agile Hybrid é uma abordagem ágil que permite que as equipes se adaptem às mudanças e entreguem valor ao cliente de forma rápida e contínua, mas é importante escolher as metodologias ágeis certas e adaptá-las para atender às necessidades específicas. do projeto e da equipe.

Tabela de vantagens e desvantagens do uso do Agile-Agile Hybrid:

Prós

Contras

Permite que as equipes entreguem valor ao cliente de forma rápida e contínua Pode ser difícil de gerenciar e implementar
Permite que as equipes aproveitem ao máximo diferentes metodologias ágeis Pode ser difícil garantir que diferentes metodologias se complementem e não sejam redundantes
Fornece flexibilidade para atender às necessidades específicas do projeto e da equipe Pode ser necessário treinar a equipe para trabalhar com as diferentes metodologias

Conclusão

Em conclusão, Agile-Agile Hybrid é uma abordagem ágil que permite que as equipes se adaptem às mudanças e entreguem valor ao cliente de forma rápida e contínua. Ele fornece a flexibilidade para atender às necessidades específicas do projeto e da equipe e permite que as equipes aproveitem ao máximo as diferentes metodologias ágeis. No entanto, é importante considerar as desvantagens, como a dificuldade de gerenciamento e implementação, e garantir que as metodologias escolhidas se complementem e não sejam redundantes. Não se esqueça que    Projetos e TI    sempre trará novidades em métodos ágeis e gerenciamento de projetos.