Criando boas metas de Sprint

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

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

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

1 – A Meta da Sprint é muito grande.

Meta da sprint é grande

 

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

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

2 – O objetivo da Sprint é vago.

 

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

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

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

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

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

Distração na sprint

 

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

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

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

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

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

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

Planejamento de sprints de trás para a frente?

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

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

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

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

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

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

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

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

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

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

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

Primeiro, ignore a lista de pendências

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

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

Pegando as principais tarefas

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

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

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

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

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

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

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

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

Foco nos resultados

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

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

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

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

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

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

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

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

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

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

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

Prever como atingir a meta das Sprints

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

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

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

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

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

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

Separando o joio do trigo

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

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

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

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

Decida como medir suas Sprints

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

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

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

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

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

Deixe a equipe decidir

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

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

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

O que fazer com sprints de trás para frente

Também é útil fazer as duas coisas:

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

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

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

Concluindo

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

Ambos são extremamente importantes.

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

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

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

4 tendências em gestão de projetos

4 tendências em gestão de projetos

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

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

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

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

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

Vamos lá? Boa leitura!

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

 

O que é a Gestão de Projetos?

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

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

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

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

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

 

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

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

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

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

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

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

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

 

Importância da Gestão de Projetos

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

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

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

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

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

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

 

4 tendências da Gestão de Projetos

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

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

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

#1 Soft Skills e Métodos Ágeis

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

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

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

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

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

#2 Gerenciamento de Riscos

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

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

 

#3 Transformação Digital

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

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

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

 

#4 Marketing Digital

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

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

É importante saber definir os direcionamentos para a equipe. 

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


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

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

Todo sucesso de um projeto depende de fatores. 

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

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

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

Método DSDM (Dynamic Systems Development Method)

O que é DSDM?

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

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

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

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

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

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

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

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

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

Breve histórico do DSDM

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

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

Princípios do DSDM:

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

dsdm-principios

1. Envolvimento ativo do usuário

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

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

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

2. Equipes Capacitadas (com poderes)

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

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

3. Entrega frequente

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

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

4. Aptidão para negócios

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

5. Desenvolvimento incremental

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

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

6. Alterações reversíveis

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

7. Linha de base para os requisitos

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

8. Teste integrado

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

9. Colaboração das partes interessadas

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

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

Considerações adicionais

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

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

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

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

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

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

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

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

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

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

Quatro valores do DSDM

dsdm-valores

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

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

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

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

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

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

Estrutura do projeto no DSDM

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

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

Papéis e responsabilidades

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

Funções no nível do projeto

Geralmente consiste em

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

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

Funções de desenvolvimento da solução

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

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

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

Funções de suporte

Consiste em papéis como

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

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

Organização e tamanho da equipe

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

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

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

Ferramentas e Técnicas

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

Esses são:

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

Timeboxing

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

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

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

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

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

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

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

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

Vamos entender isso com a ajuda de um exemplo.

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

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

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

Workshops Facilitados

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

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

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

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

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

Os benefícios de ter um workshop incluem:

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

Modelagem

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

Prototipagem

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

Testes

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

Priorização MoSCoW

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

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

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

dsdm-moscow

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

Os benefícios do MoSCoW são:

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

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

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

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

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

Fluxo de processo

DSDM Feasibility

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

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

Fase 1 – O Pré-Projeto 

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

Fase 2 – O Ciclo de Vida 

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

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

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

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

Fase 3 – Pós-projeto 

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

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

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

Estágio 1 A: Análise de Viabilidade

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

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

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

Iteração do Modelo Funcional

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

Abaixo estão os passos que a prototipagem seguirá

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

Análise de negócio

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

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

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

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

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

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

Abaixo estão os passos que a prototipagem seguirá

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

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

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

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

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

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

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

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

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

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

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

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

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

Em cada iteração

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

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

Estágio 4: implantação

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

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

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

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

Nesta fase

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

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

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

Atividade

Sub Atividade

Descrição

Análise

Análise de Viabilidade

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

Análise de Negócio

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

Iteração do Modelo Funcional

Identificar o Protótipo Funcional

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

Agenda

Definir quando e como as funcionalidades serão implantadas.

Criação do Protótipo Funcional

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

Revisão do Protótipo Funcional

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

Iteração de Desenho e Construção

Identificar o modelo do Desenho

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

Agenda

Como e quando serão realizados estes requisitos.

Criação do Protótipo do Desenho

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

Revisão do Protótipo

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

 Implantação

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

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

Treinamento

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

Implantação

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

Revisão de Negócio

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

Fase 3 – Pós-projeto 

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

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

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

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

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

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

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

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

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

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

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

Fatores críticos de sucesso do DSDM

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

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

Comparação com outros tipos de desenvolvimento de software

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

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

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

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

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

Daily Meeting

Daily Meeting: qual é a Anatomia da Daily?

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

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

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

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

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

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

Então, como posso te explicar?

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

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

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

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

O que pode ser “bom”?

Vamos com uma pequena historinha:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Todos

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

Assim sendo

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

Mas

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

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

Itens de trabalho atendidos

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

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

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

Assim sendo

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

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

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

Mas

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

Sobre o que falamos?🟢

Ontem, Hoje e Obstáculos

Também conhecido como: três perguntas

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

Assim sendo

Estruture as contribuições usando o seguinte formato:

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

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

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

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

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

Cada membro da equipe atualiza seus pares:

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

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

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

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

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

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

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

Thomas Cagley6 sugere adicionar riscos .

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

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

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

Mas

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

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

Conselho de Melhorias👌

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

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

Assim sendo

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

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

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

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

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

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

Outro estilo é mais como um quadro de tarefas:

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

Mas

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

Em que ordem falamos?

Quem chega por último fala primeiro

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

Assim sendo

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

Contudo

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

Round Robin (Rodízio)

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

Assim sendo

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

Passe o token🗝️

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

Assim sendo

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

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

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

Mas

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

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

Pegue um cartão🃏

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

Assim sendo

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

Walk the Board🏃

Também conhecido como: Walk the Wall

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

– Bret Pettichord via Twitter

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

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

Assim sendo

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

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

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

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

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

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

Mas

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

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

Onde e quando?

Conheça onde o trabalho acontece

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

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

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

Assim sendo

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

Mas

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

Mesmo Bat-Canal, Mesma Bat-Hora🦇

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

Assim sendo

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

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

Mas

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

Use o Stand-up para começar o dia

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

Assim sendo

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

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

Mas

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

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

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

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

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

Assim sendo

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

Mas

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

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

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

Como podemos manter o nível de energia?

Amontoado 👥

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

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

Assim sendo

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

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

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

Mas

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

Stand Up🧍‍♂️

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

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

Assim sendo

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

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

Mas

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

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

Quinze minutos ou menos

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

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

Entretanto

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

Mas

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

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

Sinalizar o Fim🔴

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

Assim sendo

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

O tempo das reuniões

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

Assim sendo

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

Mas

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

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

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

Take it Offline

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

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

Assim sendo

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

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

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

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

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

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

Mas

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

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

Como incentivamos a autonomia?

Rodízio do Facilitador 🍢

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

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

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

Assim sendo

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

Mas

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

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

Quebrar o contato visual

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

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

Assim sendo

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

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

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

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

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

Focado nos corredores, não no bastão

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

Reportando-se ao Líder🗣️

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

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

As pessoas estão …sempre… atrasadas🐢

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

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

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

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

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

Socializar🤝

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

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

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

Eu não me lembro😧

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

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

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

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

Narrativa (Story Telling)🎙️

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

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

Solução de problemas⚠️

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

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

Energia baixa🔋

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

Obstáculos não levantados📖

Também conhecido como: Travelogue21

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

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

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

Obstáculos não removidos

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

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

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

Daily Assíncrona🕊️

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

Contudo

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

Entretanto

Nem sempre podemos resolver os itens na mesma hora.

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

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

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

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

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

Método AgilePgM®

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

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

O que é o Método AgilePgM?

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

Por que escolher o Método AgilePgM?

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

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

Como funciona o Método AgilePgM?

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

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

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

Como implementar o Método AgilePgM em sua empresa?

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

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

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

Fase 1: Pré-início

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

Fase 2: Início

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

Fase 3: Execução

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

Fase 4: Encerramento

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

O SAFe 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.

Feedback: Bomba ou Presente?

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

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

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

1. Procure feedback

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

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

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

2. Aumente o feedback positivo

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

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

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

3. Forneça feedback saudável

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

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

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

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

Como lidar com o feedback?

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

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

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

Faça perguntas

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

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

Obtenha feedback

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

Método AgilePM®

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

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

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

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

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

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

Quem Criou o AgilePM®?

APMG 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.

Retrospectivas, sua importância e o que fazer depois

Sempre houve uma retrospectiva no final do ano na tv e eu quando criança achava aquilo o máximo, aí veio a agilidade e transformou a inspeção, transparência e adaptação em uma cerimônia que eu adoro!

Ao seguir práticas ágeis, alguns membros da equipe podem achar alguns processos redundantes – possivelmente porque eles não entendem sua importância. Um desses eventos é a retrospectiva, que é conduzida após cada revisão / demonstração do Sprint.

Uma vez que a equipe scrum comece a progredir no caminho da maturidade ágil, certas atividades são realizadas como uma formalidade para transmitir a adesão à mecânica ágil. Pode haver um equívoco aqui, já que a adesão a uma prática ou processo não é para um público maior, mas para o aprimoramento da equipe.

Normalmente, quando uma retrospectiva é conduzida, a equipe se concentra em três pontos principais:

1. O que foi bem?

2. O que não correu bem?

3.  Existem melhorias ou melhores práticas que podem ser implementadas (ou o que a equipe pode fazer de diferente)?

Quando uma retrospectiva é conduzida, o scrum master precisa definir o palco adequadamente para que toda a equipe esteja envolvida. Eles devem colaborar para melhorar o desempenho, discutir como percebem as metas do Sprint e determinar se alcançaram o que se comprometeram.

Não se trata apenas de desempenho, mas de como a coordenação e a colaboração entre vários stakeholders tornaram o Sprint um sucesso ou um fracasso. As retrospectivas normalmente não são uma reunião post-mortem, em que a análise da causa raiz se destina a identificar gargalos e pontos de falha.

Em vez disso, são reuniões colaborativas voltadas para o futuro para refinar as ações a fim de se alinhar aos objetivos.

O papel do scrum master em alinhar a equipe com os eventos scrum é de suma importância para que a equipe não participe dos eventos por uma questão de adesão ao processo, mas sim como um meio de colaborar, melhorar, alcançar e comemorar.

Frequentemente, uma equipe age com pressa ao passar de uma demonstração / revisão de sprint para outra iniciação de sprint.

Mas retrospectiva é tarefa indireta!??

Uma retrospectiva costuma ser vista como uma tarefa indireta, em que a equipe entra com a intenção de terminá-la rapidamente para que possa se concentrar nas metas e resultados finais do próximo sprint.

Normalmente, os sprints são contínuos por natureza (a menos que ocorram em um fim de semana ou feriado). Idealmente, as retrospectivas são conduzidas no mesmo dia em que a revisão do sprint é concluída.

Às vezes, se as histórias confirmadas não são marcadas como “concluídas” (de acordo com a definição de “pronto”) devido a funcionalidade incompleta ou bugs imprevistos, elas são transportadas para o próximo sprint (a menos que o proprietário do produto troque a priorização delas em vez de novas histórias a serem desenvolvidas).

Uma reunião de planejamento para um próximo sprint seguido por uma retrospectiva pode prejudicar a reunião de retrospectiva do sprint anterior porque a equipe, o product owner e o scrum master estão com pressa para completar suas histórias inacabadas.

Aqui, o scrum master atua como uma ponte entre a equipe e o product owner para facilitar e guiá-los na condução da retrospectiva (especialmente quando as histórias estavam inacabadas no sprint que acabou de ser concluído).

O antipadrão das retrospectivas

Um antipadrão comum seguido pelos proprietários do produto é continuar o sprint mesmo depois de sua duração definida devido a histórias incompletas e a meta não ser totalmente cumprida. Uma sprint deve terminar após revisão ou expiração de sua duração.

Este é o aspecto mais importante em termos do primeiro pilar do scrum: transparência. Quando a meta da sprint não é alcançada por qualquer motivo, a equipe, o product owner e o scrum master têm que ser transparentes e declarar que foi uma sprint com falhasem aumentar sua duração ou acarretar os bugs.

O aspecto mais importante de uma meta de sprint é permitir que a equipe e o product owner saibam que o plano de liberação pode precisar de ajustes se um impacto for considerado. Um ponto crucial a lembrar aqui é que a linha do tempo da sprint foi definida tendo em mente a complexidade e o esforço envolvidos para completar as histórias comprometidas em uma sprint com base na capacidade disponível (que normalmente é fixada entre as sprints).

Quando houver histórias inacabadas em sprints consecutivas se torna uma tendência, pode ser revisitado na reunião de retrospectiva – que pode revelar causas potenciais de falha de sprint e histórias inacabadas.

Essas causas incluem:

  • Falta de compreensão da história;
  • Teste impróprio ou bugs imprevistos que resultaram de mudanças sugeridas durante a execução da sprint;
  • Critérios impróprios de sucesso / aceitação para as histórias em questão.

Lembre-se de que uma reunião retrospectiva é para melhorar, aprender, resolver problemas e celebrar as conquistas da equipe durante a execução e revisão da sprint; eles devem ter uma abordagem motivadora.

Mas quando é visto como apenas mais uma parte da mecânica ágil, pode deixar rachaduras dentro da equipe (e entre a equipe e o scrum master e o product owner; e entre o scrum master e o product owner). Não existe uma solução única para todos, mas as retrospectivas devem ser mais participativas – e direcionadas com uma mentalidade focada no crescimento e na inovação.

A retrospectiva: uma prática essencial para equipes ágeis

Conheci muitas equipes que não realizam retrospectivas – a parte inspecionar e adaptar – da abordagem ágil. Às vezes, as pessoas acham que o retrô vai demorar muito ou que não vão aprender rápido o suficiente.

O problema é que as equipes fazem a mesma coisa continuamente. Nada muda.

Costumo recomendar a abordagem de cinco etapas nas Agile Retrospectives: Making Good Teams Great de Derby e Larson, para qualquer equipe, ágil ou não.

  1. Prepare o cenário
  2. Colete dados
  3. Gere percepções
  4. Decida o que fazer
  5. Conclua a retrospectiva

Ou você também pode saber sobre as quatro perguntas mais tradicionais:

  1. O fizemos que foi bom?
  2. Onde falhamos?
  3. O que aprendemos?
  4. O que ainda nos intriga?

Como suspeito que você conheça essas abordagens de retrospectivas, usarei uma estrutura diferente aqui para mostrar como refletir rapidamente logo após realizar algum tipo de atividade.

Essa abordagem de reflexão é extraída do livro The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace, de Brian Stanfield. Costumo usar essa estrutura quando faço um balanço das experiências dos alunos (por exemplo, em uma aula de treinamento ou quando facilito a retrospectiva provisória de uma equipe).

A estrutura é chamada de ORID, como em:

  • O bter os dados
  • R efletir sobre os dados
  • I nterpretar os dados e fazer o que significa que a partir dos dados
  • D ecidir o que fazer

Você pode usar uma estrutura ORID após o planejamento do backlog ou após as histórias de workshopping. Aplique-o a um período de tempo em que a equipe gastou mais de 20 minutos, mas menos de uma ou duas semanas de trabalho.

Obtenha os dados para definir o contexto
Cada pessoa experimenta os projetos de maneira diferente. Precisamos primeiro concordar com o contexto. Os dados nos ajudam a definir o contexto.

  • Quais são os fatos?
  • O que eu vi e ouvi?
  • O que eu percebi?
  • Existe história ou outros fatos?
  • Existem palavras ou dados que se destacam?

Refletir sobre os dados
Quando refletimos sobre os dados, traçamos conexões entre dados díspares. Usamos nossas emoções para fazer essas conexões. Eu faço perguntas como estas para dados reflexivos:

  • O que me surpreendeu?
  • O que isso me lembra?
  • Achei algo refrescante?
  • O que me desafiou ou frustrou?

Interpretar o significado
Gosto de pensar que esta pergunta é o “E daí?” pergunta – o que os dados significam para mim? Que ações posso realizar ou que experimentos posso realizar com base nos dados? Aqui estão algumas perguntas interpretativas que uso:

  • O que eu aprendi?
  • O que mais eu quero explorar?
  • Eu faria algo diferente?
  • Que insights eu ganhei?
  • Existem questões subjacentes que desejo abordar?

Decida o que fazer
Agora que aprendemos, é hora de decidir o que fazer a seguir. Quando eu facilitar a retrospectiva de uma equipe, muitas vezes eu peça às equipes para considerar o que uma coisa que eles vão colocar em prática. Aqui estão algumas perguntas de decisão que uso:

  • Temos frutas ao alcance que seriam fáceis de considerar?
  • O que usaremos como base para um experimento?
  • Qual é o nosso próximo passo?
  • O que vamos parar de fazer?

Não podemos fazer tudo – não ao mesmo tempo. Podemos escolher o que fazer e quando. Posso servir a alguns de vocês escrevendo sobre essas questões. Explorar essas questões pode expandir todo o nosso aprendizado e nossas práticas.

Então, ao aplicar o ORID, espero esclarecer algumas das preocupações que muitos de vocês têm sobre a abordagem ágil para o portfólio de projetos e roteiros de produtos.

Não negligencie as ações pós retrospectiva

Na busca pela melhoria contínua da equipe, identificar ações corretivas por meio de retrospectivas é apenas o primeiro passo. Essas ações precisam ser acordadas pela equipe, tornadas visíveis e rastreadas pelo Scrum Master, revisitadas na próxima retrospectiva e celebradas após a implementação bem-sucedida.

No entanto, aprendi por experiência própria que identificar ações corretivas em uma retrospectiva é apenas parte da batalha. Para garantir que a equipe obtenha todos os benefícios de suas ações propostas, elas devem ser gerenciadas de forma adequada.

Sem esse gerenciamento, ações corretivas valiosas podem se perder ou atrasar desnecessariamente e a equipe pode perder a fé no processo retrospectivo. O resultado final pode ser uma paralisação da melhoria contínua, o que é um desastre para uma equipe ágil.

Concordando com as ações

Inicialmente o ponto de partida para o gerenciamento de ações retrospectivas está na própria retrospectiva. Se a sessão foi bem-sucedida, no final haverá um conjunto de ações corretivas que foram identificadas por um ou mais membros da equipe.

Consequentemente o Scrum Master deve passar por cada ação por vez para confirmar que toda a equipe concorda que ela é válida.

Tendo em vista que uma ação válida é aquela que irá melhorar a produtividade da equipe sem incorrer em custos indevidos. A revisão das ações reforça sua importância e faz com que todos na equipe concordem que vale a pena implementá-las.

Além disso você pode descobrir que a equipe não consegue concordar sobre quais ações valem a pena serem realizadas. Se o debate chegar a um impasse, a votação por pontos pode ser usada para desfazer o impasse. A votação por pontos também pode ser útil se houver muitas ações corretivas para uma equipe realizar. A equipe pode usar a votação por pontos para priorizar as ações mais importantes para implementação de curto prazo.

Logo as ações de baixa prioridade para as quais a equipe não tem largura de banda podem ser descartadas por enquanto. Não se preocupe em perdê-los, pois, se tiverem valor, voltarão a surgir em retrospectivas futuras, quando puderem ser mais viáveis ​​para implementação.

Quadro de ações pós retrospectivas

Nesse ponto, vi equipes criarem histórias para cada uma de suas ações que vão para o backlog do produto. Não faço isso porque as ações não são histórias. Em vez disso, são coisas que a equipe pode fazer para tornar o negócio de implementação de histórias mais rápido ou fácil. Eles podem representar documentação, mudanças no processo, ferramentas aprimoradas e assim por diante.

O que eles não são: funcionalidade para o usuário final. Eles não devem, portanto, ser priorizados com histórias.

Contudo, as ações corretivas precisam ir para algum lugar ou podem ser esquecidas e nunca implementadas. Como acredito que as ações das retrospectivas são tão importantes e sua implementação pode ser tão crucial para o sucesso de um projeto, eu as torno o mais visíveis possível usando um Quadro de Ações das Retrospectivas:

Retrospective Actions

Analogamente um quadro de ações das retrospectivas é como um quadro de tarefas físicas, exceto que os cartões nele contêm as ações retrospectivas acordadas em vez de histórias. Uma vez que as ações que não foram implementadas residem na coluna To Do, aquelas em andamento estão na coluna In Progress e aquelas que a equipe executou estão na  coluna Implemented.

Já que as ações não implementadas ficam bem na frente da equipe todos os dias, elas não podem ser esquecidas. Além disso, todos podem ver quais ações foram realizadas. Isso significa que a equipe pode ver um progresso real em direção à sua própria melhoria contínua.

Nesse sentido, a medida em que tornamos as ações visíveis, será que podemos garantir que elas realmente sejam percebidas? Cabe ao Scrum Master reforçar a mensagem de que qualquer membro da equipe pode escolher uma ação retrospectiva para implementação.

Afinal, a equipe concordou com as ações porque todos acreditavam que as ações tornariam o negócio de implementação de histórias mais rápido, fácil, simples, resultaria em menos bugs, etc. Não há nada de errado em um membro da equipe melhorar a capacidade da equipe de trabalho implementando ações enquanto, ao mesmo tempo, outros realizam esse trabalho implementando histórias.

Inicialmente, o Scrum Master pode ter que se envolver para garantir que o equilíbrio entre as ações e histórias permaneça ideal. Ter um limite de WIP na coluna Em andamento é uma maneira de fazer isso. No entanto, uma equipe auto organizada vai sempre encontrar um equilíbrio produtivo muito rapidamente e essa intervenção raramente será necessária.

Rastreamento eletrônico

Em outras palavras, o  painel de ações retrospectivas é um poderoso radiador de informações para a melhoria contínua, mas não é tudo. Além do quadro físico, acho informativo manter um histórico eletrônico das ações com as quais a equipe concorda. Faço isso porque, com um fluxo constante de ações implementadas, a coluna Implementado no quadro se enche rapidamente e precisa ser limpa.

A história do que a equipe conquistou é então perdida. Além disso, o histórico pode registrar metadados sobre ações, como quando são identificadas e quando foram implementadas. Eu chamo isso de Rastreamento de Ações Retrospectivas e é representado por uma página no wiki da equipe, uma planilha no Gdrive etc..:

Retrospective Actions tracking

Em suma a página de rastreamento é um registro permanente de cada ação retrospectiva acordada e de seu estado atual. Você pode ainda adicionar um código de cores indica as ações que estão aguardando para serem implementadas (vermelho) ou foram implementadas (verde). Além de ter o registro de onde a ação foi implantada e em qual sprint e em qual sprint ela foi acordada.

Também é interessante registrar nos sprints quanto tempo a equipe leva para cumprir as ações (Sprint Lag). Se uma equipe de sucesso precisar de um lembrete da importância das retrospectivas e de seu progresso em direção ao aprimoramento, uma rápida revisão desta página irá tranquilizá-los.

Mas a página de rastreamento também é útil para identificar ações que não estão sendo realizadas. Se uma ação não for implementada por muitos sprints depois de ter sido acordada, vale a pena perguntar por quê. Pode ser que a ação esteja bloqueada. Uma ação bloqueada não é menos impedimento para o sucesso do projeto do que uma história bloqueada e pode exigir a intervenção do Scrum Master para facilitar sua remoção. Como alternativa, você pode descobrir que a ação está simplesmente obsoleta e que a equipe não acredita mais que sua implementação valha a pena. Nesse caso, e com a concordância da equipe, a ação pode ser retirada da página de rastreamento e do quadro de ações físicas.

Ação pós implementação

Finalmente, é importante fechar o círculo na próxima retrospectiva. O Scrum Master deve revisar a página Rastreamento de Ações Retrospectivas antes da retrospectiva para ver quais ações foram implementadas no último sprint. Eles devem usar essas informações na retrospectiva para comemorar o sucesso da melhoria contínua da equipe, ao mesmo tempo em que as histórias concluídas são comemoradas.

Uma vez que isso reforça para a equipe que eles estão cumprindo as ações acordadas antes de identificar outro conjunto. Isso ajuda a manter o fluxo de ações.

Conclusão

Concluindo, às vezes, ações retrospectivas podem ser negligenciadas. Eu mesmo fiz isso com uma crença anteriormente sustentada e incorreta de que as ações seriam simplesmente realizadas porque eram obviamente importantes.

No entanto, não é tão simples assim. As ações precisam ser totalmente acordadas, tornadas visíveis, sua conclusão ativamente encorajada e sua implementação bem-sucedida celebrada.

Somente com essas etapas em vigor uma equipe pode tirar o máximo proveito das grandes ideias que têm em retrospectivas.