Metas SMART: O que são e como usar?

Você já se pegou criando uma lista de objetivos, apenas para perceber semanas ou meses depois que muitos deles ficaram pelo caminho?

 

Isso é um fenômeno comum. 

 

Às vezes, nossa aspiração de alcançar grandes coisas pode nos levar a estabelecer metas vagas, inalcançáveis ou irrelevantes.

 

E que eventualmente nos deixam frustrados e desmotivados.

 

Agora, imagine um método que te ajuda a definir metas de forma estruturada e eficiente, aumentando drasticamente suas chances de sucesso.

 

Esse método existe e é conhecido como metas SMART!

 

Ele é uma ferramenta poderosa para transformar aspirações em realizações, seja em nossas vidas pessoais ou profissionais.

 

Ao longo deste artigo, vamos mergulhar no universo das metas SMART: o que são, como são estruturadas e como você pode usá-las.

 

Para aprimorar seus projetos pessoais e profissionais.

 

Acompanhe e veja também: 4 TENDÊNCIAS EM GESTÃO DE PROJETOS.

 

O que são metas SMART?

As metas SMART são um método eficiente e detalhado para definir objetivos.

 

A abordagem SMART é uma ferramenta de gestão que originou na década de 1980 e tem se provado útil para estabelecer objetivos claros e atingíveis.

 

A sigla SMART significa Specific (Específico), Measurable (Mensurável), Achievable (Atingível), Relevant (Relevante) e Time-based (Temporal).

 

Esses critérios garantem que suas metas sejam claras, rastreáveis, realistas e alinhadas com suas prioridades.

Specific (Específico)

A primeira letra, S, refere-se a específico. Para que uma meta seja eficaz, é importante ser específico sobre o que você quer alcançar.

 

Evite metas genéricas ou amplas, pois elas podem ser difíceis de medir e podem levar à frustração.

 

Em vez disso, tente detalhar o máximo possível sua meta.

 

Responda a perguntas como: O que eu quero alcançar? Por que isso é importante para mim? Quem estará envolvido? Onde isso ocorrerá?

Measurable (Mensurável)

A segunda letra, M, é de mensurável. Uma meta eficaz precisa ser mensurável, ou seja, deve haver alguma maneira de rastrear seu progresso.

 

Isso pode incluir marcos específicos, prazos ou métricas que possam ajudá-lo a determinar se você está se movendo na direção certa.

 

No âmbito profissional, isso é particularmente importante.

 

Já que objetivos de desempenho, tais como aumentar a base de clientes ou a receita, devem ser avaliados para determinar o êxito.

 

Acompanhe: PARTE 1: Definição de DoR e DoD.

 

Achievable (Atingível)

A, de atingível, refere-se a definir metas realistas e alcançáveis.

 

Embora seja importante estabelecer metas que o desafiem, definir metas além do seu alcance pode resultar em desapontamento e desmotivação.

 

Pense cuidadosamente sobre o que é necessário para alcançar sua meta e se você tem os recursos e habilidades necessários.

 

Talvez seja necessário buscar mais formação, obter recursos adicionais ou fazer ajustes em outros aspectos da sua vida para tornar sua meta atingível.

Relevant (Relevante)

R, de relevante, enfatizar a importância de definir metas que sejam pertinentes para você e seus objetivos de longo prazo.

 

Uma meta relevante é aquela que tem um propósito claro e que se alinha com seus outros objetivos e valores.

 

Por exemplo, se você deseja avançar em sua carreira, uma meta relevante pode ser obter uma certificação ou aprender uma nova habilidade relacionada ao seu campo.

Time-based (Temporal)

Por último, mas não menos importante, T, de temporal, destaca a importância de estabelecer um prazo claro para sua meta.

 

Ter um prazo definido ajuda a manter a motivação e fornece um senso de urgência.

 

Além disso, permite que você divida sua meta em tarefas menores ou etapas que podem ser concluídas em um determinado período.

Como criar metas SMART para seus projetos pessoais ou profissionais

Definir metas SMART para seus projetos pessoais ou profissionais requer um pouco de reflexão e planejamento.

 

Aqui está um passo a passo de como você pode fazer isso:

 

  1. Comece identificando o que você quer alcançar. Seja tão específico quanto possível. Se você deseja obter uma promoção no trabalho, por exemplo, identifique o cargo específico para o qual você está mirando.
  2. Em seguida, pense em como você pode medir seu progresso em direção a essa meta. Quais serão as evidências de que você está progredindo? Para o exemplo da promoção, isso pode incluir feedback positivo de superiores ou aumento de responsabilidades.
  3. Avalie se a meta é atingível com base em seus recursos e habilidades atuais. Se não for, você pode precisar ajustar a meta ou identificar maneiras de adquirir os recursos ou habilidades necessárias.
  4. Considere a relevância da meta em relação aos seus objetivos de longo prazo e valores pessoais. Isso ajudará a garantir que você permaneça motivado e comprometido com a meta.
  5. Finalmente, defina um prazo para a meta. Certifique-se de que o prazo seja realista, mas também desafiador.

 

Imagine que você é um profissional de marketing com a tarefa de desenvolver um novo planejamento de marketing de conteúdo.

 

Definir metas SMART pode ser o elemento diferenciador que levará esse projeto ao sucesso.

 

Uma meta SMART poderia ser “aumentar o tráfego orgânico do blog em 20% nos próximos 6 meses através da publicação de 3 novos artigos otimizados para SEO por semana”.

 

Ao invés de ter uma meta vaga como “aumentar o tráfego do blog”.

 

Essa abordagem deixa claro muitos objetivos, como o que precisa ser feito, como será medido.

 

Bem como se é alcançável com os recursos disponíveis, por que é importante para a estratégia geral de marketing de conteúdo e quando deve ser alcançado.

Como acompanhar e avaliar as metas SMART

Manter o controle de suas metas SMART é crucial para garantir que você esteja fazendo progresso. 

 

Aqui estão algumas maneiras de fazer isso:

 

  • Estabeleça um sistema de acompanhamento: Isso pode ser tão simples como uma lista de tarefas no seu diário ou um aplicativo de gestão de tarefas no seu smartphone. O importante é ter um lugar onde você possa registrar e acompanhar suas metas.
  • Realize avaliações regulares: Dedique um tempo regularmente (por exemplo, semanal ou mensalmente) para revisar suas metas e avaliar seu progresso. Isso pode ajudar a identificar qualquer obstáculo que possa estar impedindo seu progresso e permitir que você faça ajustes conforme necessário.
  • Comemore suas conquistas: Quando você alcançar uma meta ou um marco importante, comemore! Isso pode ajudar a aumentar sua motivação e confiança.

 

Por exemplo, se considerarmos a meta SMART que mencionamos anteriormente, é possível acompanhar o progresso observando regularmente as métricas de tráfego do blog.

 

E também o número de novos artigos publicados e sua otimização para SEO.

 

Se, depois de três meses, você perceber que o tráfego orgânico do blog só aumentou 5%, talvez seja necessário ajustar a estratégia ou o plano de implementação.

 

Talvez você precise investir mais em pesquisa de palavras-chave para melhorar a otimização de SEO.

Ou talvez você precise alterar a frequência ou o tipo de conteúdo publicado.

 

O acompanhamento regular permitirá que você faça ajustes conforme necessário para manter seus esforços de marketing de conteúdo no caminho certo.

Conclusão

As metas SMART são uma ferramenta valiosa para ajudar você a definir, perseguir e alcançar seus objetivos sejam pessoais ou profissionais.

 

Ao ser específico, mensurável, atingível, relevante e temporal, você pode aumentar significativamente suas chances de sucesso.

 

Lembre-se, o progresso é muitas vezes uma série de pequenas vitórias.

 

Então, estabeleça suas metas SMART e comece a avançar em direção ao objetivo desejado!

 

Gostou desse conteúdo? Veja também: CRIANDO BOAS METAS DE SPRINT.

Guia Definitivo para Iniciantes em PI Planning

Introdução ao PI Planning

O PI Planning é uma metodologia crucial para equipes ágeis que buscam melhorar seu desempenho e colaboração. Neste guia definitivo, abordaremos os conceitos essenciais do PI Planning para iniciantes.

O que é o PI Planning?

O PI Planning, ou Planejamento de Programa Incremental, é um evento crucial dentro da estrutura SAFe (Scaled Agile Framework). É uma reunião que ocorre regularmente, onde todas as equipes ágeis envolvidas no programa se unem para sincronizar seus objetivos e prioridades. O objetivo é estabelecer uma visão compartilhada, alinhar as atividades e garantir que todas as equipes estejam no mesmo caminho para o sucesso.

Benefícios do PI Planning

O PI Planning oferece diversos benefícios para as equipes e organizações que o adotam. Alguns dos principais benefícios incluem:

1. Alinhamento Estratégico

O PI Planning permite que todas as equipes trabalhem em direção aos mesmos objetivos estratégicos. Isso ajuda a evitar o desperdício de recursos em atividades não prioritárias e melhora a eficiência geral do programa.

2. Melhor Colaboração

Ao reunir todas as equipes em um evento presencial, o PI Planning promove a colaboração e a comunicação entre os membros. Isso leva a uma melhor compreensão das dependências entre as equipes e aumenta a sinergia entre elas.

3. Identificação Antecipada de Problemas

Durante o PI Planning, as equipes têm a oportunidade de identificar possíveis problemas e obstáculos. Isso permite que eles tomem medidas corretivas antecipadamente, evitando atrasos e falhas futuras.

4. Aumento da Transparência

Através do PI Planning, todas as partes interessadas têm uma visão clara das atividades planejadas e dos resultados esperados. Isso aumenta a transparência em toda a organização e melhora a confiança entre as equipes.

Etapas do PI Planning

O PI Planning geralmente ocorre em um período de dois dias. Abaixo estão as principais etapas envolvidas no processo:

1. Preparação

Antes do evento, as equipes devem se preparar revisando suas metas e objetivos individuais. Também é importante identificar quaisquer dependências externas e preparar uma lista de discussão para o evento.

2. Reunião de Abertura

O evento começa com uma reunião de abertura, onde a alta administração define a visão geral e as metas estratégicas. Isso estabelece o tom para o restante do planejamento.

3. Planejamento Detalhado

As equipes se reúnem para um planejamento detalhado, onde discutem suas metas específicas para o próximo Program Increment (PI). Elas também identificam e abordam possíveis problemas e riscos.

4. Cerimônia de PI Planning

Durante esta cerimônia, cada equipe apresenta seus planos e objetivos para todo o grupo. As dependências são identificadas e resolvidas, e as prioridades são estabelecidas para o próximo PI.

5. Retrospectiva

Após o evento, as equipes realizam uma retrospectiva para revisar o PI Planning e identificar áreas de melhoria para o próximo ciclo.

Conclusão

O PI Planning é uma prática essencial para equipes ágeis que desejam alcançar uma maior colaboração, alinhamento e eficiência. Ao seguir as etapas descritas neste guia, as equipes poderão maximizar os benefícios dessa metodologia e impulsionar o sucesso de seus programas. Portanto, é fundamental investir tempo e esforço adequados no PI Planning para colher os frutos a longo prazo.

Quer saber como realizar uma PI Planning de sucesso?

Vou dar um treinamento exclusivo sobre PI Planning em 02/09/2023 junto com Leandro Goor onde vamos entender e simular toda uma PI Planning, quer mais informações clique neste link https://www.sympla.com.br/evento-online/pi-planning-bootcamp-pragma/2066881

User Story – O que preciso saber sobre histórias de usuário

User Story (histórias de usuários) fazem parte de uma abordagem ágil que ajuda a mudar o foco de escrever sobre requisitos para falar sobre eles. Cada história ágil do usuário inclui uma ou duas frases escritas e, mais importante, desencadeia uma série de conversas sobre os recursos e funcionalidades que a história do usuário representa.

As histórias do usuário são uma maneira de descrever a funcionalidade desejada dos itens de lista de pendências do produto. Histórias de usuários de alta prioridade tendem a ser mais detalhadas; histórias de usuários de baixa prioridade tendem a ser menos detalhadas.

As equipes adicionam detalhes à medida que as histórias aumentam em prioridade, criando critérios de aceitação ou dividindo grandes histórias em pedaços menores ( ou ambos ).

O que é uma User Story?

Uma história de usuário é uma descrição curta e simples de um recurso contado da perspectiva da pessoa que deseja o novo recurso, geralmente um usuário ou cliente do sistema. As histórias do usuário geralmente seguem um modelo simples:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Historicamente, as histórias dos usuários eram deliberadamente mantidas informais, escritas em cartões de índice ou notas adesivas, armazenadas em uma caixa de sapatos e dispostas em paredes ou mesas para facilitar o planejamento e a discussão.

Sua impermanência facilitou rasgá-los, jogá-los fora e substituí-los por novas histórias, à medida que se aprendeu mais sobre o produto que está sendo desenvolvido.

Atualmente, as histórias dos usuários podem ser facilmente armazenadas em um problema de Jira ou no quadro de Trello.

Não deixe que o fato de uma história de usuário existir em uma ferramenta o torne menos disposto a descartar histórias quando elas não forem mais necessárias!

As histórias de usuários são projetadas para mudar fortemente o foco, da escrita de recursos para a discussão deles. De fato, essas discussões são mais importantes do que qualquer texto escrito.

O que é uma boa User Story?

As histórias ágeis dos usuários são compostas por três aspectos que Ron Jeffries nomeou em 2001 com a maravilhosa aliteração de cartão, conversa e confirmação:

  1. Cartão: Descrição escrita da história, usada para planejamento e como lembrete
  2. Conversa: Conversas sobre a história que servem para detalhar os detalhes da história
  3. Confirmação: Testes que transmitem e documentam detalhes que podem ser usados para determinar quando uma história está concluída.

As histórias de usuários têm muitas vantagens, mas o mais importante pode ser que toda história de usuário seja um espaço reservado para uma conversa futura.

Como escrever uma história de usuário

Escrever boas histórias de usuários no Scrum requer uma compreensão do modelo básico de história do usuário, um foco no usuário ou cliente e uma imagem clara da funcionalidade desejada.

Modelo de história do usuário

Ao escrever uma história de usuário, lembre-se de que as histórias de usuário seguem um modelo padrão:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Exemplos de histórias de usuários

Uma das melhores maneiras de aprender a escrever uma história de usuário em ágil é ver exemplos. Abaixo está um exemplo de história ou duas de usuário. Estes são alguns exemplos reais de histórias de usuários que descrevem a funcionalidade desejada em uma versão inicial do site da Scrum Alliance.

  • Como membro do site, posso preencher um aplicativo para me tornar um instrutor certificado de scrum para poder ensinar  e certificar outros Scrum Masters ( PSM ) e Product Owners ( PSPO ).
  • Como treinador, quero que meu perfil liste minhas próximas aulas e inclua um link para uma página detalhada sobre cada uma, para que os possíveis participantes possam encontrar meus cursos.
  • Como visitante do site, posso acessar notícias antigas que não estão mais na página inicial, para poder acessar as coisas que me lembro do passado ou que outras pessoas mencionam para mim.
  • Como visitante do site, posso ver uma lista de todos os próximos cursos de certificação “ ” e posso paginar por eles se houver muito, para que eu possa escolher o melhor curso para mim.

Observe que você não vê nenhuma história de usuário: “Como proprietário do produto, quero uma lista de cursos de certificação para que…” O proprietário do produto é uma parte interessada essencial, mas não é o usuário / cliente final. Ao criar histórias de usuários, é melhor ser o mais específico possível sobre o tipo de usuário.

Quem escreve histórias de usuários?

Quem escreve histórias de usuários? Qualquer pessoa pode escrever histórias de usuários.

O proprietário do produto escreve histórias de usuários?

É responsabilidade do proprietário do produto garantir a existência de um acúmulo de histórias ágeis de usuários, mas isso não significa que o proprietário do produto seja quem as escreve. Ao longo de um bom projeto ágil, você deve esperar ter histórias de usuários escritas por cada membro da equipe.

Observe também que quem escreve uma história de usuário é muito menos importante do que quem está envolvido nas discussões.

Quando as histórias dos usuários são escritas?

As histórias dos usuários são escritas em todo o projeto ágil. Normalmente, um workshop de redação de histórias é realizado perto do início do projeto ágil.

Todos na equipe participam com o objetivo de criar um backlog do produto que descreva completamente a funcionalidade a ser adicionada ao longo do projeto ou um ciclo de lançamento de três a seis meses dentro dele.

Algumas dessas histórias ágeis de usuários serão, sem dúvida, épicas. Mais tarde, as épicas serão decompostas em histórias menores que se encaixam mais rapidamente em uma única iteração.

Além disso, novas histórias podem ser escritas e adicionadas ao backlog do produto a qualquer momento e por qualquer pessoa.

Você pode mostrar outros exemplos de user history?

Como um exemplo mais genérico de escrever histórias de usuários no Scrum, essas são algumas histórias típicas de usuários para um site de postagem e pesquisa de empregos:

  • Um usuário pode postar seu currículo no site.
  • Um usuário pode procurar empregos.
  • Uma empresa pode postar novas vagas.
  • Um usuário pode limitar quem pode ver seu currículo.

Como os detalhes são adicionados às user historys?

Os detalhes podem ser adicionados às histórias do usuário de duas maneiras:

  • Dividindo uma história de usuário em várias histórias menores de usuário.
  • Adicionando condições de satisfação: Critérios de aceitação ( ).

Quando uma história relativamente grande é dividida em várias histórias de usuários ágeis menores, é natural supor que os detalhes foram adicionados. Afinal, mais foi escrito.

As condições de satisfação são simplesmente um teste de aceitação de alto nível que será verdadeiro após a conclusão da história ágil do usuário. Considere o seguinte como outro exemplo ágil da história do usuário:

Como vice-presidente de marketing, quero selecionar uma temporada de férias a ser usada ao revisar o desempenho de campanhas publicitárias anteriores, para que eu possa identificar as lucrativas.

Detalhes podem ser adicionados a esse exemplo de história do usuário adicionando as seguintes condições de satisfação:

  • Certifique-se de que funcione com as principais férias de varejo: Natal, Páscoa, Dia do Presidente, Dia das Mães, Dia dos Pais, Dia do Trabalho, Dia de Ano Novo.
  • Suporte a feriados que abrangem dois anos civis ( nenhum intervalo três ).
  • As estações de férias podem ser definidas de um feriado para o próximo (, como Ação de Graças ao Natal ).
  • As estações de férias podem ser definidas para vários dias antes do feriado.

As user history substituem um documento de requisitos?

Projetos ágeis, especialmente os Scrum, use um backlog do produto, que é uma lista priorizada da funcionalidade a ser desenvolvida em um produto ou serviço. Embora produto itens de lista de pendências pode ser o que a equipe deseja, as histórias dos usuários surgiram como a melhor e mais popular forma de itens de lista de pendências de produtos.

Enquanto um atraso do produto pode ser considerado um substituto para o documento de requisitos de um projeto tradicional, é importante lembrar que a parte escrita de uma história de usuário ágil ( “ Como usuário, Eu quero … ” ) está incompleto até que as discussões sobre essa história ocorram.

Muitas vezes, é melhor pensar na parte escrita como um ponteiro para o requisito real. As histórias do usuário podem apontar para um diagrama que descreve um fluxo de trabalho, uma planilha mostrando como executar um cálculo ou qualquer outro artefato que o proprietário ou a equipe do produto deseje.

Vantagens do “ Como, quero, para, ”

“Como um , Eu quero,  Para que que .” Embora eu considere a cláusula opcional, eu realmente gosto desse modelo. Em uma conferência, alguém me perguntou o porquê. Como recebo essa pergunta com bastante frequência, quero dar três razões pelas quais aqui:

Razão 1

Algo significativo e estou tentado a dizer que mágico acontece quando os requisitos são colocados na primeira pessoa. Obviamente, dizendo “Como tal e tal, eu quero …”, você pode ver como a mente da pessoa se move instantaneamente para imaginar que ela é uma pessoa assim. Quanto à mágica, Paul McCartney foi entrevistado e perguntado sobre por que as músicas dos Beatles eram tão incrivelmente populares. Uma de suas respostas foi que suas músicas foram as primeiras a usar muitos pronomes.

She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. Seu argumento era que isso ajudava as pessoas a se identificarem mais de perto com as músicas.

Você pode ler mais sobre o Uso de pronomes pelos Beatles neste artigo.

Razão 2

Ter uma estrutura nas histórias realmente ajuda o proprietário do produto a priorizar. Se o backlog do produto for uma mistura de coisas como:

  • Entrega de exceção fixa
  • Deixe os usuários fazerem reservas
  • Os usuários querem ver fotos
  • Mostrar opções de tamanho do quarto

… e assim por diante, o proprietário do produto precisa trabalhar mais para entender qual é o recurso, quem se beneficia e qual é o valor dele.

Razão 3

Ouvi um argumento de que escrever histórias com esse modelo suprime o conteúdo informativo da história, porque há muito texto comum. Se você achar isso verdade, corrija-o na maneira como apresenta a história. Vi atrasos no Word que apresentam o texto comum em texto acinzentado com as partes exclusivas em preto.

Criei backlogs de produtos no Excel que usam títulos de colunas para filtrar o texto comum.

Olhe aqui e verá o que quero dizer:

COMO / UM EU QUERO… PARA QUE ENTÃO…
moderador criar um novo jogo digitando um nome e uma descrição opcional Posso começar a convidar jogadores
moderador convidar os jogadores, dando-lhes um URL onde eles possam acessar o jogo podemos começar o jogo
jogador participar de um jogo digitando meu nome na página em que recebi o URL Eu possa participar
moderador iniciar uma rodada inserindo um item em um único campo de texto com várias linhas podermos estimar
jogador ver o item que estamos estimando eu dê minha estimativa para o item
jogador ver todos os itens que tentaremos estimar nesta sessão coletar o tamanho dos vários itens
moderador ver todos os itens que tentamos estimar nesta sessão Eu possa responder perguntas sobre a história atual, como “isso inclui _____”
moderador selecionar um item a ser estimado ou reestimado a equipe veja esse item e poder estimá-lo

Sério, dê uma olhada na tabela acima antes de continuar … Eu vou esperar … Por favor, olhe para ela antes de ler mais.

OK, aqui está como eu aposto que você leu a planilha

Aposto que, ao ler a maioria das linhas que você adicionou no texto “Como um …”, “Eu quero …” e “para que então…”, possivelmente até olhando para o cabeçalho enquanto você lê em cada linha. Eu experimentei perguntando às pessoas, e é isso que a maioria das pessoas faz.

Se esse texto é desnecessário, por que mentalmente expressamos as palavras para nós mesmos ou até olhamos para o cabeçalho enquanto lemos a linha? Talvez não seja tão não essencial, afinal.

Por enquanto, e provavelmente por muito tempo, continuarei com o modelo “Como um …”, “Eu quero …” e “para que então…” por esses e outros motivos.

Por que o modelo de história de usuário de três partes funciona tão bem

Não há modelo mágico que deva ser usado para histórias de usuários. Eles podem ser escritos de várias maneiras. Mas a maneira mais popular de escrever histórias de usuários é com este modelo:

Como um tipo de usuário < >,
quero < algum objetivo >
para que < seja um motivo >.

Esse modelo se originou com a treinadora ágil Rachel Davies em uma empresa inglesa, Connextra, no início dos anos 2000. Desde então, tornou-se um padrão reconhecido para expressar histórias de usuários.

Os três elementos do modelo padrão

Descrevi as três partes do modelo padrão de várias maneiras ao longo dos anos. No Livro Histórias de usuários aplicadas de Mike Cohn1, ele descreve os três elementos desta maneira:

  • Como um papel ( ), quero uma função ( ) para que ( valor comercial ).

Mais tarde, ele mudou para que ao se referir aos três elementos como papel, objetivo e razão. Por fim, decidiu apenas se referir a eles de maneira muito mais simples como quem, o quê e por quê. Os três elementos do endereço do modelo de história do usuário padrão:

  • Quem quer a funcionalidade
  • O que eles querem
  • Por que eles querem

Vejamos cada uma dessas partes do modelo de história do usuário.

Quem: o primeiro elemento do modelo de história do usuário

Os usuários de um produto ou sistema típico geralmente podem ser categorizados. Como exemplo, estou digitando isso no Google Docs agora. Eu poderia ser considerado um usuário casual de Docs.

Não uso a maioria de seus recursos. Nunca cliquei no menu Complementos para ver o que há lá. Não faço muita formatação sofisticada porque a maior parte do que escrevo é movida para o meu site e é formatada lá. Então, vamos me chamar de Usuário casual.

Outros que usam esses recursos podem ser chamados Usuários de energia.

Normalmente, envio meus rascunhos de blog para um editor. E assim, Editor poderia ser outra função ao identificar os vários tipos diferentes de usuários do Google Docs.

Essas funções de usuário formam a primeira parte do modelo padrão de história do usuário. Portanto, alguém que desenvolve um processador de texto pode ter uma história de usuário de “ Como um usuário de energia, Eu quero um corretor ortográfico … ”

O que: o segundo elemento do modelo de história do usuário

A segunda parte do modelo padrão indica o que é desejado ou necessário. Isso é comumente declarado como “ eu quero …. ” De fato, durante anos minhas apresentações em conferências e outros treinamentos sobre histórias de usuários tiveram um slide dizendo “ Eu quero … ”

Acabei percebendo que isso era impreciso. Às vezes, a funcionalidade descrita não é algo que a função do usuário deseja. Por exemplo:

  • Como membro, sou obrigado a inserir uma senha forte….

Nenhum usuário ( normal ) quer para inserir uma senha com muitos caracteres, três símbolos especiais, sem caracteres repetidos e pelo menos algumas letras maiúsculas. Na melhor das hipóteses, entendemos por que é necessário, mas pessoalmente prefiro que o sistema saiba magicamente que sou eu e deixe-me entrar.

Então, hoje em dia eu não incluo mais quer ao mostrar o modelo em cursos ou apresentações. Em vez de sempre ser eu quer, às vezes sou eu necessário, forçado, precisa ou mais.

Por que: o terceiro elemento do modelo de história do usuário

A parte final do modelo padrão é porque o usuário deseja que a funcionalidade seja descrita na história do usuário. Isso é fornecido após o para que parte do modelo. Por exemplo, uma versão totalmente expressa da história anterior do verificador ortográfico pode ser “ Como usuário de energia, quero um verificador ortográfico para não precisar me preocupar com erros ortográficos. ”

para que a cláusula de uma história é importante porque entender por que um usuário deseja o que é descrito no o que parte da história ajuda a equipe a decidir qual a melhor forma de implementar a funcionalidade.

Como exemplo, não procure mais do que a nossa história de corretor ortográfico. Suponha que tenha sido fornecido a uma equipe sem uma cláusula simples: Como usuário de energia, quero um corretor ortográfico. Isso provavelmente levaria uma equipe a desenvolver o que eram todos os verificadores ortográficos iniciais: As ferramentas posteriores são executadas em um documento após a escrita.

Mas nosso usuário de energia não deseja um passo extra depois de terminar de escrever um documento. Em vez disso, o usuário de energia quer o que parece mais padrão hoje: correção em tempo real dos erros à medida que são cometidos. O que o usuário realmente deseja é dado pela cláusula: o usuário não quer se preocupar com erros de ortografia.

A cláusula ‘para que’ deve ser opcional?

Quando apresento histórias de usuários durante cursos presenciais, Muitas vezes me pedem para justificar minha visão aparentemente contraditória de que a cláusula é a parte mais importante de uma história, mas não deve ser obrigatória.

Não considero obrigatório porque, às vezes, simplesmente não agrega valor. Considere uma história sobre o login: Como membro, sou obrigado a fazer login.

Que cláusula você pode adicionar a essa história que agrega valor ou esclarece a intenção da história? Alguma dessas coisas realmente ajuda ou são apenas texto supérfluo adicionado para cumprir um modelo:

  • Como membro, sou obrigado a fazer login para que somente eu possa acessar meus dados pessoais.
  • Como membro, sou obrigado a fazer login para que outras pessoas não possam acessar meus dados pessoais, a menos que eu tenha fornecido minhas credenciais.
  • Como membro, sou obrigado a fazer login para que o sistema saiba que sou eu.
  • Como membro, sou obrigado a fazer login para que os hackers sejam mantidos de fora.

Enquanto eu não considero o para que cláusula obrigatória, eu escrevo quase o tempo todo. Revisei um atraso recente que escrevi e 62 de 64 histórias ( 97% ) tiveram cláusulas para que. Um pequeno número de ocasiões me impede de considerá-lo obrigatório.

Pontos fortes do modelo de história de usuário de três partes

Então, o que há de tão bom nesse modelo que ele resistiu ao teste do tempo? Afinal, uma prática introduzida no início dos anos 2000 e crescendo em aceitação tantos anos depois deve ter algo a seu favor. Eu acho que existem quatro pontos fortes principais no modelo.

Abrange três dos cinco Ws

Comecei a universidade como especialista em jornalismo. Acho que romantizei filmes cheios de repórteres de jornais que mastigam charutos e filmes como Ás no buraco, cidadão Kane, aconteceu uma noite, Todos os homens do presidente. Os jornalistas são treinados para que qualquer artigo de jornal precise responder cinco perguntas que começam com um W:

  • Quem? (Who?)
  • O que? (What?)
  • Quando? (When?)
  • Onde? (Where?)
  • Por quê? (Why?)

As histórias dos usuários abordam três dos cinco – Quem, O quê e Por quê. Ao discutir os requisitos do produto ou sistema, parece razoável deixar Quando e Onde, pois as respostas geralmente seriam “ agora ” e “ no produto. ”

Os elementos são apresentados na ordem certa

Eu acho que os elementos – quem, o quê e por quê – são apresentados na ordem certa. Pense em qualquer história – não em uma história de usuário, mas em um filme, um romance ou uma anedota ou piada que você deseja contar a um amigo. A coisa mais importante nessa história é quase sempre quem está fazendo isso. Chamamos essa pessoa de protagonista.

Quando assistimos a um filme, precisamos nos preocupar com o protagonista antes de nos preocuparmos com a trama. Eu não me importo de um jeito ou de outro com a Estrela da Morte sendo explodida até me ver um pouco em Luke, Han ou Leia e posso relacionar para eles.

Só depois que eu sei quem, eu me preocupo com o que e porque. O modelo padrão de história do usuário os coloca nessa ordem.

A história é contada a partir de uma perspectiva de primeira pessoa

Nós gostamos de histórias sobre nós mesmos. ( Bem, a menos que sejamos adolescentes e nossos pais estejam contando histórias sobre as coisas não tão fofas que fizemos quando éramos bebês. ) A próxima melhor coisa para uma história sobre mim é uma história sobre você.

O menos interessante é uma história sobre o cara do outro lado da cidade que eu nunca conheci.

Histórias sobre eu e você e nós e ela e ele são interessantes.

Os Beatles sabiam disso. Eles deliberadamente colocaram o maior número possível de pronomes pessoais em seus títulos de músicas. E se eles não conseguissem encaixar um pronome pessoal no título da música, colocariam o máximo que pudessem nas letras da música.

O primeiro álbum britânico dos Beatles ’ teve pronomes em 8 dos 14 títulos de músicas ( 57% ). Nos 19 minutos e 30 segundos dessas oito músicas, os Beatles usavam 325 pronomes pessoais, um pronome a cada 3,6 segundos.

Isso funcionou tão bem que seu segundo álbum teve pronomes em 64% dos títulos. Os Beatles então aumentaram para 79% em seu terceiro álbum.

Em entrevista à revista Billboard, o Beatle Paul McCartney disse que isso era muito deliberado: “ Todas as nossas primeiras músicas continham ‘eu’ ou ‘você.’ Fomos completamente diretos e sem vergonha para os fãs: Me ame, por favor, por favor, eu quero segurar sua mão.

O modelo padrão de história do usuário começa com eu, o mais pessoal dos pronomes pessoais. Não tenho base para essa afirmação – não sou neurologista -, mas juro que algo acontece quando temos uma história de usuário que começa com eu.

Nos relacionamos com essa história mais de perto do que se o mesmo fosse escrito como um tradicional O sistema deve… declaração.

Paul McCartney e John Lennon sabiam disso e o usavam para impulsionar suas carreiras. As equipes ágeis fazem o mesmo ao usar o modelo de história de usuário em três partes.

Nossas partes interessadas são imediatamente confortáveis preenchendo

Os espaços em branco Antes das histórias dos usuários aparecerem, adorei usar casos. Ou tentei amar casos de uso. Eu realmente os amava. Mas nunca consegui convencer as partes interessadas com quem trabalhei para amá-las tanto quanto eu.

Eles estavam muito longe de como as partes interessadas pensavam sobre seu trabalho. As partes interessadas não pensam em atores secundários, pré-condições ou pós condições. E assim, os casos de uso nunca funcionaram tão bem na prática quanto eu pensava que deveriam.

Eu nunca tive esse problema com histórias de usuários. Posso realizar um workshop de redação de histórias com as partes interessadas simplesmente escrevendo Como um _____, Eu ______ para que _______ em um quadro branco e dizendo a eles que nos reunimos para preencher os espaços em branco o máximo que pudermos.

As partes interessadas entendem. É uma maneira natural de falar por eles.

Outros modelos para expressar histórias foram propostos, e alguns têm vantagens, mas a maioria são maneiras menos naturais de falar. Por exemplo, o desenvolvimento orientado a comportamentos é uma ótima maneira de expressar testes ou especificar por exemplo. Martin Fowler descreve sua sintaxe dada quando e depois como “ um estilo de representação de testes. ” E é fantástico para escrever especificações de teste mas não é tão bom para se comunicar com os clientes.

Em parte, isso ocorre porque seu modelo é menos natural. Falo desde os 2 ou 3 anos. Não sei se já iniciei uma frase com dado. Definitivamente nunca usei dado, quando e então nessa ordem em uma frase. Eu disse sem conta “ eu quero isto de modo que aquilo.”

Desvantagens do modelo de user story de três partes

Há duas desvantagens no modelo padrão de história do usuário que merecem destaque.

Muitas histórias são escritas apenas como “ Como usuário … ”

Com demasiada frequência, os membros da equipe têm o hábito de iniciar cada história de usuário com “ Como usuário…” Às vezes, esse é o resultado de um pensamento preguiçoso e os escritores de histórias precisam entender melhor os usuários do produto antes de escrever tantas histórias “ como usuário … ”.

Mas outras vezes, pode indicar um sistema não adequado para histórias de usuários. Isso acontece porque muitas pessoas associam ser ágil com a escrita de histórias de usuários. Para ser ágil, eles raciocinam, você precisa escrever histórias de usuários, mesmo quando não há usuários.

Eu trabalhei em um sistema de rastreamento de conformidade financeira. A grande maioria do que o sistema fez nunca seria vista ou relatada. Se um problema de conformidade fosse descoberto, no entanto, os relatórios seriam gerados e os indivíduos seriam notificados. Esse sistema se beneficiou de histórias de usuários para esse pequeno subconjunto da funcionalidade geral do produto. Mas as histórias dos usuários eram inadequadas para o resto do sistema.

Em casos como esses, as equipes precisam usar maneiras alternativas de expressar o que o produto precisa fazer. A sintaxe usada por histórias de trabalho ou desenvolvimento orientado a recursos recursos podem ser melhores escolhas.

O modelo é muito frequentemente seguido de maneira eslava

Por todos os meios, o senso comum precisa ser um princípio norteador para equipes ágeis. Ao expressar algo no modelo de história do usuário padrão, não faz sentido, não use esse modelo. Escreva de outra maneira, incluindo muito possivelmente apenas texto de forma livre.

Hoje cedo, escrevi um item de lista de pendências do produto “ Altere como os lembretes de reprodução de webinar são enviados no último dia da maneira como discutimos na ligação de sexta-feira. ”

Como um item de lista de pendências do produto, isso é péssimo. Não é uma história de usuário. Não é BDD ou mesmo uma história de trabalho. É horrível. E se não for corrigido em breve, ninguém se lembrará do bug que foi discutido em uma ligação esquecida.

Mas eu sabia que a equipe iria consertar isso em breve e, portanto, o que escrevi foi bom o suficiente. A última coisa que eu preciso seria de um Scrum Master insistindo em escrevê-lo para seguir um modelo criado na virada do milênio, não importa o quão bem esse modelo funcione para a maioria dos itens de lista de pendências do produto.

Vantagens das histórias de usuários sobre requisitos e casos de uso

A programação extrema ( XP ) introduziu a prática de expressar requisitos na forma de histórias de usuários. A história do usuário é uma breve descrição da funcionalidade – contada da perspectiva de um usuário – que é valiosa para um usuário do software ou para o cliente do software, e normalmente assume a forma de um Modelo de 3 partes.

caso de uso, por outro lado, é uma descrição generalizada de um conjunto de interações entre o sistema e um ou mais atores, onde um ator é um usuário ou outro sistema. Os casos de uso podem ser escritos em texto não estruturado ou em conformidade com um modelo estruturado.

Requisitos são tipicamente uma lista de instruções “ O sistema deve … ”, como:

  • O sistema deve permitir que uma empresa pague por um anúncio de emprego com cartão de crédito.
  • O sistema deve aceitar cartões Visa, MasterCard e American Express.
  • O sistema cobrará o cartão de crédito antes que o anúncio de emprego seja colocado no site.
  • O sistema deve fornecer ao usuário um número de confirmação exclusivo.

Histórias de usuários normalmente (mas nem sempre e não em todos os casos) são a melhor escolha para equipes que usam Scrum porque oferecem várias vantagens em casos de uso, requisitos e outras opções.

Benefícios das histórias de usuários

As histórias de usuários exibem algumas das mesmas características dos casos de uso ou declarações de requisitos tradicionais, mas são as maneiras pelas quais elas são diferentes que dão tantas vantagens às histórias de usuários.

User Story Benefício 1: Exigem conversas

Talvez o benefício mais importante das histórias dos usuários no desenvolvimento ágil de produtos seja que, diferentemente dos requisitos ou casos de uso, as histórias dos usuários não devem se sustentar por si mesmas.

Em vez disso, cada história de usuário é um espaço reservado para uma conversa futura com a equipe de desenvolvimento.

O texto de alto nível armazenado em um cartão de índice, problema de Jira, célula de planilha ou nota adesiva pode ser a manifestação mais visível de uma história de usuário, mas não é a mais importante.

A parte mais importante de qualquer história de usuário é que um entendimento compartilhado do que é necessário é elaborado em uma conversa futura.

User Story Benefício 2: São verbais, muito mais precisas

As histórias dos usuários enfatizam a comunicação verbal, para que sejam mais precisas. O idioma escrito geralmente é muito impreciso e não há garantia de que um cliente e desenvolvedor interpretem uma declaração da mesma maneira.

Agimos como se as palavras escritas fossem precisas, mas geralmente não são. Por exemplo, no almoço recentemente, li isso no meu menu: “ Entrada: vem com uma escolha de sopa ou salada e pão. ”

Essa não deveria ter sido uma frase difícil de entender, mas foi. Qual deles você escolhe?

  • Sopa ou ( salada e pão )
  • ( Sopa ou salada ) e pão

Compare as palavras escritas nesse menu com a garçonete ’ palavras faladas: “ Você gostaria de sopa ou salada? ” Melhor ainda, ela removeu toda a ambiguidade colocando uma cesta de pão na mesa antes de fazer meu pedido.

User Story Benefício 3: Têm estimativas e priorização fáceis

Uma terceira vantagem de escrever histórias de usuários é que elas recebem estimativas que tornam a priorização e o planejamento mais tranquilos. Cada história de usuário pode receber uma estimativa do esforço necessário para desenvolvê-lo; os casos de uso, por outro lado, são geralmente grandes demais para receber estimativas úteis.

Da mesma forma, quando você considera as milhares ou dezenas de milhares de instruções em uma especificação de requisitos de software ( e os relacionamentos entre elas ) para um produto típico, é fácil ver a dificuldade inerente em priorizá-los.

Se os requisitos não puderem ser priorizados além do alto, médio e baixo comuns, eles não serão adequados para um processo de desenvolvimento altamente iterativo e incremental que fornecerá software de trabalho a cada duas a quatro semanas.

User Story Benefício 4: Incentive as equipes a adiar detalhes

Uma quarta vantagem é que as histórias dos usuários incentivam a equipe a adiar detalhes da coleta.

Uma história inicial  épica – de nível ( “ Um recrutador pode postar uma nova vaga ” ) pode ser escrita, estimada e colocada no backlog do produto. Mais tarde, ele pode ser substituído por várias histórias menores, mais detalhadas, com DoR, DoD e Critérios de aceitação que é quando se torna importante ter esses detalhes.

Essa técnica torna as histórias dos usuários perfeitas para projetos com restrição de tempo – Uma equipe pode escrever rapidamente algumas dezenas de histórias de usuários para dar uma sensação geral pelo sistema. Eles podem mergulhar nos detalhes de algumas histórias e começar a codificar muito mais cedo do que uma equipe que se sente compelida a concluir uma especificação de requisitos funcionais.

User Story Benefício 5:  Oferecer um entendimento geral do produto

A quinta vantagem é um pouco mais sutil. As listas de requisitos que um analista de negócios pode apresentar não dão ao leitor o mesmo entendimento geral de um produto que as histórias de usuários fazem.

É muito difícil ler uma lista de requisitos sem considerar automaticamente as soluções em sua cabeça enquanto você lê.

Por exemplo, considere os seguintes requisitos, adaptados dos de Alan Cooper2 The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity 1ª Edição.

  • O produto deve ter um motor a gasolina.
  • O produto deve ter quatro rodas.
  • O produto deve ter um pneu de borracha montado em cada roda.
  • O produto deve ter um volante.
  • O produto deve ter uma carroceria de aço.

A essa altura, suponho que imagens de um automóvel estejam flutuando em torno de sua cabeça. Obviamente, um automóvel atende a todos os requisitos listados acima. O da sua cabeça pode ser um conversível vermelho brilhante, enquanto eu posso imaginar uma picape azul. Presumivelmente, as diferenças entre o seu conversível e a minha picape são cobertas por declarações de requisitos adicionais.

Mas suponha que, em vez de escrever uma especificação de requisitos de estilo IEEE 830 –, as histórias foram escritas da perspectiva do usuário.

  • Como proprietário de casa, quero algo que facilite e agilize a cortar a grama.
  • Como proprietário de casa, quero uma maneira de cortar a grama, onde possa me sentar, em vez de me levantar.

Ao olhar para as metas, temos uma visão completamente diferente do produto: o cliente realmente quer um cortador de grama, não um automóvel!

Histórias descrevem os objetivos de um usuário. Ao focar nos objetivos do usuário para o novo produto, em vez de uma lista de atributos do novo produto, podemos criar uma solução melhor para as necessidades do usuário.

User Story Benefício 6: Sugerem um custo

Um benefício final das histórias do usuário sobre as especificações de requisitos é que o custo de cada requisito não seja visível até que todos os requisitos sejam escritos.

O cenário típico é que um ou mais analistas passam dois ou três meses ( geralmente mais ) escrevendo um documento de requisitos demorado. Este documento é entregue aos programadores, que informam aos analistas ( que transmitem a mensagem ao cliente ) que o projeto levará 24 meses, em vez dos seis meses que eles esperavam.

Nesse caso, perdeu-se tempo escrevendo os três quartos do documento que a equipe não terá tempo para desenvolver e mais tempo será desperdiçado como desenvolvedores, analistas, e iterar o cliente sobre qual funcionalidade pode ser desenvolvida a tempo.

Na boa prática de histórias de usuários, um estimativa está associada a cada história. O cliente / proprietário do produto conhece a velocidade da equipe e o custo relativo de cada história, e pode decidir rapidamente se o produto que eles desejam pode ser entregue no tempo que eles tiverem.

Kent Beck me disse uma vez que essa diferença era como se registrar para presentes de casamento. Quando você se registra, não vê o custo de cada item. Você apenas faz uma lista de desejos de tudo o que deseja.

As listas de desejos cegas podem funcionar para casamentos, mas não funcionam para o desenvolvimento de produtos. Quando um cliente, proprietário do produto ou parte interessada coloca um item em sua lista de desejos do projeto, ele precisa saber seu custo.

Requisitos não funcionais como histórias de usuários

Um desafio comum com a escrita histórias de usuários é como lidar com os requisitos não funcionais de um produto. Esses são requisitos que não tratam de funcionalidade específica ( “Como usuário de um processador de texto, quero inserir uma tabela no meu documento”. ), mas são mais sobre um atributo ou característica do sistema.

Os exemplos incluem confiabilidade, disponibilidade, portabilidade, escalabilidade, usabilidade, manutenção.

Como você pode ver nessa lista de exemplos, os requisitos não funcionais são frequentemente referidos como “-ilidade.” Obviamente, nem todos os requisitos não funcionais terminam em “-ilidade.” Também temos segurança, desempenho, robustez e assim por diante.

Pensando na idade das trevas, lembro-me de quando li pela primeira vez sobre “requisitos não funcionais.” O termo me deu um nó. Se não é funcional, por que me preocupo com isso? Tenho certeza de que o autor desse livro esclareceu isso para mim uma página mais tarde, mas o termo sempre me pareceu estranho.

Prefiro pensar em requisitos não funcionais como “restrições” que colocamos no sistema.

Quando o proprietário do produto diz: “este sistema deve ter um desempenho adequado com 100.000 usuários simultâneos”, o proprietário do produto está colocando uma restrição no equipe.

O proprietário do produto está efetivamente dizendo: “Desenvolva este software da maneira que desejar, desde que alcance 100.000 usuários simultâneos.”

Cada restrição que colocamos em um sistema restringe um pouco as opções de design; chamar essas “restrições” em vez de “requisitos não funcionais” nos ajuda a lembrar disso. Felizmente, restrições / requisitos não funcionais podem ser facilmente expressos como histórias de usuários:

  • Como cliente, quero poder executar seu produto em todas as versões do Windows a partir do Windows 95.
  • Como CTO, quero que o sistema use nosso banco de dados de pedidos existente em vez de criar um novo, para que não tenhamos mais um banco de dados para manter.
  • Como usuário, quero que o site esteja disponível 99.999% do tempo em que tento acessá-lo, para não ficar frustrado e encontrar outro site para usar.
  • Como alguém que fala um idioma latino, talvez eu queira executar seu software algum dia.
  • Como usuário, quero que as instruções de direção sejam os melhores 90% do tempo e razoáveis 99% do tempo.

Como você pode ver nesses exemplos de histórias de usuários, eu pude facilmente ficar com o “Como um , Eu quero , de modo que ” modelo de história do usuário, que eu prefiro para a maioria das histórias de usuários. Faço isso por algumas razões, mas quero comentar mais sobre apenas uma delas aqui.

Considere o exemplo do CTO que restringe a equipe a usar o banco de dados de pedidos existente. ( Esta era a situação real; a equipe estava considerando um banco de dados de segundos pedidos que seria sincronizado à noite. O CTO ouviu isso e disse: “Não!” )

Se escrevêssemos esse requisito da mesma forma: “Deve usar o banco de dados de pedidos existente,” seria inteiramente possível que, alguns meses depois, não nos lembrássemos por que deveríamos ser restringidos dessa maneira. Perguntaríamos ao proprietário do produto se ela se importava se usássemos um banco de dados secundário e ela diria que não tinha objeções. E cometeríamos um erro de usar um.

Incorporar a pessoa que quer algo pode ser muito útil. Mas, tome cuidado para não ficar obcecado com esse modelo. É apenas uma ferramenta de pensamento.

Tentar colocar uma restrição no modelo de história de usuário em três partes é um bom exercício, pois ajuda a entender quem quer o quê e por quê. Se você terminar com uma instrução confusa, largue o modelo. Você pode achar que o modelo de história de trabalho funciona melhor para o seu contexto. Ou você pode achar que os modelos não funcionam. Se você não conseguir encontrar uma maneira de expressar a restrição, basta escrever a restrição da maneira que parecer natural.

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.

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.

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.

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 Framework1 é uma estrutura escalável que suporta programas maiores e mais complexos, mas pode ser mais burocrático e menos flexível do que o AgilePgM. O PgMP do PMI é reconhecido internacionalmente como um padrão de excelência em gerenciamento de programas, mas pode ser mais difícil e caro de implementar do que outras metodologias de gerenciamento de programas.

O que podemos concluir sobre o Método AgilePgM

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

Vantagens:

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

Desvantagens:

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

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

Método AgilePM®

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 International1 é 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 mais1.
  • 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.

Agile Waterfall Hybrid

Método Agile-Waterfall Hybrid

Agile-Waterfall Hybrid é uma metodologia híbrida que combina elementos da metodologia ágil com elementos da metodologia cascata. Isso geralmente envolve a divisão de um projeto em fases, com cada fase tendo um objetivo específico e um conjunto de entregas, como na metodologia Waterfall.

No entanto, a equipe também segue princípios ágeis, como colaboração constante com o cliente e capacidade de adaptação às mudanças do projeto. Isso pode permitir que a equipe se beneficie da estrutura progressiva do Waterfall, mantendo a flexibilidade para lidar com imprevistos e mudanças no projeto.

O Agile-Waterfall Hybrid é também conhecido como:

  • Metodologia híbrida ágil-cascata
  • Metodologia de desenvolvimento híbrida
  • Metodologia ágil-estruturada
  • Metodologia ágil-Waterfall
  • Metodologia de gerenciamento de projetos híbrida
  • Metodologia de gerenciamento híbrida ágil-Waterfall

É importante observar que esses termos são frequentemente usados ​​de forma intercambiável para se referir à abordagem combinada de metodologias ágeis e em cascata, mas isso pode variar dependendo do contexto e pode haver outros nomes para a abordagem.

Quais metodologias Waterfall podem ser utilizadas?

Existem várias metodologias Waterfall que podem ser usadas no Agile-Waterfall Hybrid, incluindo:

  1. Waterfall tradicional: É a metodologia cascata mais antiga e básica, que segue uma sequência linear de fases, começando pelo planejamento e terminando no suporte e manutenção. Uma metodologia que segue esse modelo é o PMI (Project Management Institute).
  2. Waterfall Incremental: É uma variação da metodologia tradicional em cascata, onde cada fase é dividida em etapas menores, permitindo que o projeto seja dividido em incrementos menores. Um exemplo de metodologia incremental é o Rational Unified Process (RUP).
  3. Waterfall Spiral: É uma metodologia híbrida que combina elementos da metodologia Waterfall e da metodologia Spiral. Segue uma sequência de fases, mas também permite que o projeto seja decomposto em incrementos menores e inclui ciclos de revisão e risco. Um exemplo é o modelo de processo espiral de software, desenvolvido por Barry Boehm.
  4. Waterfall V-Model: É uma metodologia Waterfall que segue uma sequência linear de fases, mas também inclui um processo de teste formalizado em cada fase. O V-Model é uma metodologia amplamente utilizada em projetos de desenvolvimento de software.

Essas metodologias Waterfall são as mais comuns, mas também existem outras metodologias Waterfall que podem ser utilizadas no Agile-Waterfall Hybrid, como o Unified Process (UP). O importante é que a equipe consiga adaptar a metodologia utilizada para combinar com a metodologia ágil e atender as necessidades do projeto.

A metodologia Agile-Waterfall Hybrid não tem um criador específico, mas sim uma abordagem ou conceito que surgiu como uma forma de combinar os benefícios das metodologias Agile e Waterfall. Em vez de uma única metodologia, é mais uma abordagem adaptável que pode ser personalizada para atender às necessidades específicas de um projeto ou organização. A ideia de combinar as metodologias Agile e Waterfall cresceu ao longo do tempo, pois equipes e organizações começaram a experimentar diferentes abordagens e encontrar maneiras de combinar os benefícios de ambas as metodologias.

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

Não há dados concretos sobre a porcentagem exata de equipes ou empresas que usam o Agile-Waterfall Hybrid globalmente. De fato, como mencionei anteriormente, a metodologia Agile-Waterfall Hybrid é uma abordagem adaptativa, em vez de uma metodologia de tamanho único, portanto, pode ser difícil medir quantas equipes ou empresas a estão realmente usando. Além disso, equipes e empresas podem usar diferentes combinações de metodologias ágeis e em cascata, dificultando a medição exata de quantas estão usando o híbrido Agile-Waterfall.

Porém, é comum equipes e empresas utilizarem metodologias híbridas, entre elas o Agile-Waterfall Hybrid. De acordo com uma pesquisa realizada pela Forrester em 2020, cerca de 56% das equipes de TI usam metodologias híbridas, enquanto apenas cerca de 44% usam metodologias puras (como Scrum ou Waterfall). Isso indica que a maioria das equipes de TI usa algum tipo de metodologia híbrida, incluindo o Agile-Waterfall Hybrid.

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

Existem funções, artefatos, cerimônias, princípios e estágios no Agile-Waterfall Hybrid que são combinações de elementos das metodologias Agile e Waterfal. Entre eles temos:

  • Papéis: gerente de projeto, líder de equipe, scrum master, gerente de produto, cliente e membros da equipe de desenvolvimento.
  • Artefatos: Plano do Projeto, Documento de Requisitos, Backlog do Produto, Quadro de Progresso, Relatório de Progresso e Relatório de Risco.
  • Cerimônias: reunião de planejamento, reunião diária, revisão de incremento, reunião de retrospectiva, reunião de planejamento de liberação e reunião de encerramento do projeto.
  • Princípios:  entrega contínua de valor, a colaboração constante com o cliente, a capacidade de adaptação à mudança e a melhoria contínua.
  • Etapas:   As etapas incluem a fase de projeto, a fase de desenvolvimento, a fase de construção, a fase de transição e a fase de operação.

Tabela de prós e contras do uso desta metodologia:

É importante notar que esses elementos podem variar dependendo da metodologia ágil ou Waterfall que está sendo utilizada, e a combinação pode ser adaptada para atender às necessidades específicas do projeto ou da equipe.

A metodologia Agile-Waterfall Hybrid é uma abordagem híbrida que combina elementos das metodologias ágeis e Waterfall. Ela é baseada na ideia de que cada metodologia tem suas próprias vantagens e desvantagens e que combiná-las pode permitir que a equipe se beneficie das melhores características de ambas.

A metodologia ágil, por exemplo, é conhecida por sua flexibilidade e capacidade de lidar com mudanças, enquanto a metodologia Waterfall é conhecida por sua estrutura de fases e entregas claras. Ao combinar essas duas abordagens, é possível obter a estrutura de fases da Waterfall enquanto se mantém flexível para lidar com mudanças no projeto, como é o caso do Agile.

Entretanto, é importante notar que essa combinação também pode trazer desvantagens, como a complexidade adicional de combinar dois conjuntos diferentes de regras e processos. Além disso, pode ser difícil para equipes menos experientes equilibrar essas duas abordagens diferentes e adaptá-las para atender às necessidades específicas do projeto.

Em resumo, o Agile-Waterfall Hybrid pode ser uma excelente abordagem para equipes que desejam combinar as vantagens das metodologias ágeis e Waterfall, mas é importante levar em conta as desvantagens também, como a complexidade adicional e a dificuldade de adaptação.

Prós

Contras

Combinação de vantagens das metodologias ágeis e Waterfall Complexidade adicional de combinar dois conjuntos diferentes de regras e processos
Estrutura de fases e entregas claras Dificuldade de adaptação para equipes menos experientes
Flexibilidade para lidar com mudanças no projeto

Onde posso encontrar mais informações sobre o método Agile-Waterfall Hybrid?

  1. Livros: Há vários livros escritos sobre metodologias híbridas, incluindo o Agile-Waterfall Hybrid. Alguns exemplos incluem “Agile and Waterfall in Harmony” de Michael James e “Agile Estimating and Planning” de Mike Cohn.
  2. Artigos e blogs: Existem muitos artigos e blogs escritos por especialistas em metodologias híbridas, como por exemplo: Hybrid waterfall agile development for the federal space  (Salinas, Erica M | Boyne, Loraine, 2012) e Blending Agile and Waterfall – The Keys to a Successful Implementation (Rodov, Alexander | Teixidó, Jordi, 2016).

Conclusão

O Agile-Waterfall Hybrid pode ser uma excelente opção para equipes que desejam combinar as vantagens das metodologias ágeis e Waterfall, mas é importante considerar todos os prós e contras antes de decidir utilizá-lo. É fundamental que a equipe esteja ciente das complexidades e dificuldades que podem surgir e esteja preparada para lidar com elas, e escolher a metodologia que melhor atende as necessidades do projeto e da organização.

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

Método 4DX – Four Disciplines of Execution

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

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

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

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

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

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

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

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

Disciplina 1: Concentre-se no extremamente importante

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

Disciplina 2: Agir sobre as medidas principais

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

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

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

Disciplina 4: Crie um cadência de responsabilidade

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

Quem criou 4DX?

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

Qual foi o primeiro uso conhecido de 4DX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quais são as cerimônias?

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

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

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

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

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

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

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

O 4DX tem fases ou etapas?

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

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

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

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

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

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

Implementação 4DX

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

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

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

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

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

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

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