Agile for All Book

O Agile fornece respostas reais e eficazes para uma pergunta que mantém os executivos acordados: “Como manter o sucesso em um mundo em rápida mudança e imprevisível?” Essa metodologia já conquistou o mercado, provando que é uma das melhores abordagens para criação e entrega de software. O Agile for All é dirigido aos profissionais. Neste livro, você aprenderá como organizações inteiras - de gerentes e desenvolvedores de produtos a profissionais de marketing e executivos - podem usar uma abordagem "flexível".

Matt LeMay, de maneira simples e sem gírias, explica o que é Agile e oferece etapas concretas e eficazes que permitem a qualquer equipe realizar suas tarefas da maneira mais eficiente possível. Você encontrará muitos exemplos adequados para qualquer tipo e tamanho de organização - desde startups a grandes empresas - que permitem implementar a abordagem Agile em vários campos de atividade.

Mergulhe na prática ágil: "whoopee!"

Quando trabalhei como gerente de produto, tinha muitas práticas e estruturas ágeis prontas em mãos que eu poderia usar como equipe. Essas estruturas se referem exclusivamente às necessidades das equipes de desenvolvimento de software e foram testadas na prática por milhares de especialistas, muitos dos quais compartilharam suas experiências na forma de publicações acessíveis e publicações em blogs.

No entanto, quando comecei a trabalhar como consultor, não conseguia entender imediatamente como usar esses métodos com relação a objetivos completamente diferentes das novas equipes. Os resultados de nosso trabalho - relatórios analíticos obtidos após meses de longas consultas, seminários sobre a formação da imagem do cliente - foram significativamente diferentes dos produtos de software, uma vez que não tínhamos mais uma maneira clara e objetiva de verificar o desempenho desses resultados. Além disso, em nossos papéis, todos os limites foram apagados em comparação aos papéis da equipe de desenvolvimento, porque agora todos fizemos uma coisa comum, não nos escondendo sob os títulos de "designer visual" ou "desenvolvedor front-end".

Presos nessa confusão processual, tentamos lidar com um conjunto padrão de problemas que surgem para as equipes que fornecem resultados não técnicos. O assunto desses resultados se expande imperceptivelmente e inevitavelmente à medida que trabalhamos, especialmente quando passamos de estados intermediários (esboços) para documentos e apresentações completos. O objetivo de cada resultado, orientado para o cliente, às vezes permaneceu incerto para nós; portanto, nesses casos, expandimos o assunto da pesquisa para não "perder" nada. Apesar de gostarmos de trabalhar juntos, nem sempre entendemos quem, por quê, quando e por que era responsável.

Vale ressaltar que os métodos ágeis “estatutários” nem sempre se encaixam perfeitamente na estrutura de nossa equipe ou nos resultados, no entanto, entendemos que os princípios básicos do Agile poderiam nos manter na direção certa. Portanto, começamos a nos perguntar questões que formaram a base deste livro: com que clareza entendemos as necessidades de nosso cliente? Podemos eliminar todos os mal-entendidos por meio de cooperação oportuna? Garantimos que a introdução de novas informações no fluxo de trabalho não se transforme em um processamento completo do material?

Começamos a fazer essas perguntas regularmente em reuniões de planejamento e retrospectivas, alterando o fluxo de trabalho para refletir nossas idéias e respostas. Depois de experimentar por cerca de um ano, transformamos nossa abordagem em uma prática de WHPI (lida como “woooops!” Ou “Por que, como, protótipo, iteração”). O WHPI consiste em quatro etapas, que são fornecidas na tabela. 6.3 Para começar, você decide coletivamente por que coloca o resultado em primeiro lugar, qual o impacto que espera e qual o valor que seu cliente receberá. Então você decide como fornecerá esse valor, como será o resultado final. Por fim, você confia a um dos membros da equipe por um período limitado de tempo para criar um protótipo que reflete a experiência que você deseja criar para o cliente, em seguida, repita esse protótipo e verifique se ele foi capaz de atingir os objetivos que você definiu na primeira etapa.


Descobrimos que o WHPI é uma ferramenta Agile poderosa que pode ser incorporada em qualquer equipe, independentemente de suas tarefas e objetivos. Abaixo está uma breve descrição de cada etapa do WHPI e algumas dicas para implementar e usar esses métodos como parte de sua equipe.

PASSO 1: Por quê

Para esta etapa, reunimos vários participantes importantes do projeto (2–4) e discutimos rapidamente um conjunto de metas ou resultados do projeto. Se possível, reunimos em um único espaço físico (ou virtual) e elaboramos todas as idéias registradas nos adesivos durante o processo de trabalho. Normalmente, essas reuniões duram de 15 a 30 minutos. Embora esses prazos possam parecer difíceis e inconvenientes para reuniões tão importantes, eles refletem uma verdade significativa: se você não conseguir determinar os objetivos principais em 15 a 30 minutos, precisará obter mais informações antes de avançar. Várias vezes, nessa fase, percebemos que era necessário realizar pesquisas básicas para confirmar nossas suposições ou fazer perguntas esclarecedoras aos nossos clientes. Tendo criado um único conjunto inicial de objetivos do “porquê”, colocamos-os no centro das atenções, para que eles direcionem o restante do processo de trabalho.

Por exemplo, quando desenvolvemos um relatório analítico após uma reunião, geralmente escrevemos três principais "por que" em adesivos:

• Transmitir um entendimento da força motriz do projeto à gerência sênior.
• Lembre os participantes das principais informações da reunião.
• Desperte o interesse entre os funcionários que não compareceram à reunião.

Observe que nenhum desses pontos indica diretamente como vamos alcançar nossos objetivos - mais sobre isso mais tarde!

PASSO 2: Como

Depois de definir as metas do projeto, passamos à difícil tarefa de determinar como alcançá-las. Costumamos chamar essa etapa de "definição de ferramentas" - isto é, quando sabemos o que faremos, precisamos pensar em ferramentas e abordagens. Eu recomendo passar de "por que" para "como" com os mesmos participantes da reunião. Freqüentemente, ao definir "como", você entende por que pelo menos um objetivo principal da equipe "por que" é na verdade um passo de "como" no nível executivo.

Na seção anterior, identificamos o seguinte "por quê": "Desperte o interesse entre os funcionários que não compareceram à reunião". Antes de usar esse método, definimos um objetivo semelhante da seguinte maneira: “Explique aos participantes o idioma e as estruturas para que eles possam compartilhar informações com seus colegas.” Mas depois que começamos a separar o “porquê” do “como”, percebemos que tínhamos perdido duas perguntas-chave: por que é importante que as pessoas compartilhem essas tarefas com os colegas e como podemos simplificar o processo de alcançar metas? Linguagem e estruturas são realmente necessárias para as pessoas? Como conseguimos discutir neste livro, a atenção prioritária aos clientes e suas necessidades geralmente ajuda a reduzir a quantidade de trabalho que esperávamos ou a entender que o resultado desejado é significativamente diferente do que planejávamos alcançar.

Dado o "porquê" da última seção, podemos identificar o seguinte "como" para direcionar o fluxo de trabalho:

• Crie um breve relatório de análise de duas páginas que possa ser facilmente compreendido e disseminado.
• Use citações memoráveis ​​dos participantes para transmitir o entendimento da força motriz à gerência sênior.
• Use as fotos da reunião para lembrar os participantes de momentos interessantes.
• Promova resultados positivos e limite a quantidade de detalhes para manter o resultado focado e gerar interesse generalizado.

Como você pode ver, "como" fornece um plano ou plano de ação para criar todas as condições necessárias para atingir os objetivos pretendidos. Esta etapa determina a forma do nosso resultado, aborda diretamente o nosso "porquê" e fornece limites claros e móveis para evitar a perda de controle sobre os resultados desejados. Um plano tão claro permite delegar tarefas para obter resultados muito mais rapidamente, independentemente da abordagem usada nas próximas etapas.

PASSO 3: Protótipo

Ao definir "por que" e "como", estamos prontos para criar um protótipo com tempo limitado. A palavra "protótipo" pode significar muitas coisas em diferentes contextos. No contexto deste método, definimos um protótipo da seguinte maneira:

• Um protótipo não é um modelo ou um documento de planejamento; é criado no mesmo formato que o resultado ou resultado desejado. Por exemplo, o "protótipo" de uma apresentação com slides é uma apresentação com slides. O "protótipo" de uma brochura impressa é uma brochura impressa.
• Um protótipo é criado em um período de tempo limitado e predeterminado. (Criado como parte do time-boxing.)

Em outras palavras, “criamos condições para atingir o número máximo de metas do projeto (“ por quê ”) usando abordagens e ferramentas aprovadas (“ como ”), no mesmo formato e com o mesmo prazo do resultado desejado. No caso de pequenos projetos, como pôsteres, o protótipo inicial pode parecer um resultado final. No caso de grandes projetos, como um relatório de quarenta páginas, o protótipo inicial pode ter 20 páginas inteiras dobradas ao meio, grampeadas e preenchidas à mão (com páginas numeradas, títulos, breves resultados e locais para imagens).

Como discutimos no Capítulo 3, nosso objetivo aqui é chegar o mais próximo possível da experiência do cliente, criando nossa própria versão do "software de trabalho". Coisas que parecem ótimas em modelos e documentos de planejamento não funcionam em apresentações, relatórios e reuniões. A verificação dos resultados iniciais usando o método prototype nos ajudou a penetrar na experiência do cliente, reduzir o número de melhorias e analisar as premissas iniciais com mais detalhes.

Como regra, designamos um membro da equipe como responsável pela criação do protótipo primário. Muitas vezes, isso se torna uma questão de tempo livre: quem pode reservar várias horas nos próximos dias para fazer a primeira tentativa? Descobrimos que duas horas de trabalho são a limitação padrão para a criação de um protótipo, que permite criar uma base de comparação com os objetivos do projeto e deixa espaço para desenvolvimento e iteração.

PASSO 4: Iteração

Após criar o primeiro protótipo com limite de tempo, a equipe original de participantes (ou parte da equipe) é montada para analisar o protótipo e discutir a próxima iteração. Nossas primeiras discussões foram realizadas no formato mais / sugerir, no qual cada membro da equipe fala sobre aspectos bem-sucedidos e sobre elementos que precisam ser aprimorados. (Usamos exatamente o mesmo formato em nossas retrospectivas, e rapidamente voltamos a ele.) Gradualmente, refizemos esse formato na chamada discussão de “proteger, excluir, melhorar”. Após a apresentação do protótipo, os participantes compartilham três tipos de revisões:

• O que deve ser deixado para as próximas iterações, pois corresponde a todo o "porquê", tanto quanto possível.
• O que pode ser excluído das seguintes iterações, pois não corresponde a todo o "porquê".
• O que deve ser aprimorado para as próximas iterações, pois ainda pode ajudar a alcançar o "porquê" necessário.

A principal diferença entre essa abordagem e o formato tradicional de mais / oferta é uma discussão aberta sobre o que precisa ser excluído das iterações a seguir. Começamos a usar essa abordagem depois que descobrimos que as alterações mais bem-sucedidas das iterações ocorrem após a exclusão, não a adição, mesmo nos maiores projetos. Uma "exceção" aberta durante as discussões permite que os participantes rastreiem aspectos que podem ser removidos, o que fornece resultados mais precisos e focados. Alinhando todos os três tipos de revisões com o "porquê" previamente acordado, resolvemos todos os conflitos em potencial, evitamos momentos embaraçosos e mantemos o projeto na direção certa.

Depois de coletar feedback, um dos membros da equipe transforma essas revisões em outro iteração por tempo limitado de protótipo. Em alguns casos, isso leva a uma revisão completa do último protótipo (por exemplo, uma revisão da apresentação). Em outros casos, isso leva à criação de um novo protótipo baseado em protótipos antigos (por exemplo, um relatório sobre os resultados no Word com base em protótipos manuscritos). Essas rodadas consecutivas de iteração podem ser controladas por uma pessoa que criou o protótipo inicial ou por qualquer outro membro da equipe. Na segunda ou terceira iteração, o protótipo geralmente está nas mãos da pessoa que é responsável por apresentar o produto modificado. Além disso, na segunda ou terceira iteração, o protótipo parece quase completo e pronto para a revisão final.

»Mais informações sobre o livro podem ser encontradas no site do editor
» Conteúdo
» Trecho

Cupom de 25% para vendedores ambulantes - Agile

Após o pagamento da versão impressa do livro, um livro eletrônico é enviado por e-mail.