O livro "O brilhante ágil. Gerenciamento flexível de projetos com Agile, Scrum e Kanban »

O que é gerenciamento flexível de projetos?

O seu projeto precisa?

Haverá algum benefício com isso?

Deseja entender como o gerenciamento de projetos flexível funciona e adotar essa abordagem poderosa? Então você escolheu o livro certo.

“Brilliant Agile” não é apenas mais uma história sobre métodos e processos, o foco está em exemplos da vida real do uso do Agile em ambientes de negócios.

Aqui você encontrará dicas práticas e técnicas específicas de implementação Agile para tornar seu projeto um sucesso e implementar um gerenciamento flexível em sua organização.

SOBRE AUTORES

Rob Cole é consultor de gerenciamento de projetos com mais de 20 anos de experiência. Ele é especialista em solução de problemas de projetos e mentoria. Rob está envolvido na comunidade Agile desde os primeiros dias e é um Scrum Master praticante.

Edward Scotcher é gerente de produto, gerente de projeto, treinador e coach da Agile. Ele é especialista em ajudar organizações, equipes e indivíduos a adaptar o Agile para uso prático e de longo prazo.

PREFÁCIO DO EDITOR CIENTÍFICO

Quando me pediram para revisar este livro, fiquei muito feliz porque sempre fiquei feliz com qualquer oportunidade de dar suporte ao desenvolvimento do Agile fora de um aplicativo de TI. E é exatamente isso que este livro faz.

Ela:

• sobre o ágil que todo mundo está falando;
• Necessidade de quem não conhece nada sobre o Agile e realmente deseja se familiarizar com essas abordagens;
• escrito por adeptos absolutos de abordagens flexíveis;
• escrito no estilo Agile (os autores usam imagens, exemplos e ilustrações muito interessantes, que raramente são encontradas na literatura acadêmica);
• adequado para leitura e aplicação universal;
• Ele não contém o idioma e a terminologia que nos assustam na literatura técnica de TI e é fácil de ler.

Você receberá respostas para várias perguntas:

• O que é gerenciamento flexível de projetos e isso beneficiará você?
• Como se beneficiar do uso do Agile?
• Quais métodos e processos são executados no Agile?
• Sua organização ou projeto é adequado para o uso do Agile?
• Como resolver os problemas mais comuns associados ao Agile?

E como, no final, implementá-lo em qualquer projeto?
Eu sinceramente recomendo o Brilliant Agile para leitura e uso. É uma pena que eu não tivesse esse livro em minhas mãos cerca de cinco anos atrás, quando comecei a usar tudo no meu trabalho ...

Funtov Valery Nikolaevich
e N., PMP, treinador e treinador ágil

PASSAGEM. FORMAÇÃO DE EQUIPE DE PROJETO

Muitas pessoas reunem diligentemente as melhores pessoas que podem encontrar em uma equipe - profissionais com experiência relevante, especialistas em seu campo - e depois estragam tudo sem fornecer um entendimento adequado dos negócios e da liderança. Não coloque a carroça diante do cavalo! É importante alcançar o nível certo de participação comercial no projeto - incluir uma pessoa que entenda a visão do negócio. Isso não é apenas prático e pragmático, mas também lógico do ponto de vista do senso comum.

No Agile, essa pessoa geralmente é chamada de "Dono do produto", mas há variações do nome. É claro que, neste livro brilhante, ele deveria ser chamado de "gerente de produtos", mas, para começar, insistimos em uma definição simples. O proprietário do produto representa os interesses da empresa e do usuário final. O proprietário do produto vive, respira e sonha com o produto e como deve ser. Essas pessoas sabem exatamente o que querem, mesmo que não saibam como conseguir isso. Eles são líderes que podem tomar decisões rapidamente e defendê-las.

Uma equipe Agile é um grupo diversificado e multifuncional de indivíduos capazes de traduzir uma visão em nome de uma empresa. Simplificando, eles têm tudo para fazer o trabalho corretamente. O proprietário do produto indica o caminho apenas em termos de visão de negócios, mas essa é uma grande contribuição para o trabalho da equipe. A equipe é formada por pessoas com pensamento flexível, sem medo de mudar e sem acreditar que a burocracia é a solução para todos os problemas. Tomadores de decisão confiantes, pessoas ativas e proativas funcionarão melhor.

Toda a equipe deve estar envolvida na definição da visão e de todos os aspectos relacionados ao lançamento do produto. Se você não fizer isso, surgirão dificuldades.

CRIANDO UMA REVISTA DE REQUISITOS

Quando a visão e os benefícios que o projeto deve trazer são definidos, o próximo passo para a equipe do projeto é anotar os requisitos em detalhes possíveis. No centro de cada projeto, há uma lista de requisitos, que no Agile é chamado de log de requisitos do produto ou backlog (Product Backlog). Ele substitui os termos de referência detalhados e tradicionais e é uma lista de importantes idéias de negócios. Os elementos da revista estão sempre focados no usuário final do produto, mesmo quando se trata da parte técnica do projeto. Eles devem ser claros para qualquer um.

É importante que, desde o início, a equipe do projeto desenvolva uma visão coletiva para garantir que todos entendam os objetivos, o conteúdo do projeto e como conceituá-los. Verifique se tudo está no mesmo comprimento de onda desde o início - é mais fácil do que tentar consertar um produto pronto para dois terços depois. A diversidade da equipe também é importante, porque é importante poder analisar o problema de diferentes ângulos. Se necessário, os especialistas se ajudarão.

Como fazer as coisas darem errado desde o início

• Declare que o Agile é uma ferramenta universal, mesmo para áreas não destinadas a ele.
• Dizer que tudo é óbvio aqui e que qualquer tolo pode lidar com isso, portanto, não é necessário treinamento.
• Acredite que o Agile é infalível e o fracasso se deve a falhas pessoais.
• Estabeleça metas e prazos irrealistas, justificando isso com o fato de que tudo é possível no admirável mundo novo do Agile.

Definir funcionalidade básica

O objetivo é compilar uma lista do que é necessário para traduzir a visão do projeto. Existem várias maneiras de fazer isso, e nossa abordagem favorita é pensar em cada etapa do cliente para planejar seu fluxo de trabalho .


Criar grupos funcionais

Depois que o fluxo de trabalho estiver definido ou compilado, reúna todas as idéias para o que precisa ser feito a cada passo do caminho. Esse agrupamento desses elementos fornece uma descrição da funcionalidade da etapa e pode ser chamado de grupos funcionais. Alguns detalhes serão absolutamente necessários, enquanto outros podem ser atribuídos à categoria de adições agradáveis. Eles devem ser encomendados desde o início.


Características prioritárias

Com base na visão do projeto e no senso comum, determine a prioridade de cada elemento em uma ordem decrescente - a partir dos mais importantes em cada lista.


Definição da primeira edição

Uma vez feito o exposto, considere todas as etapas importantes para avançar em direção ao cliente desde o primeiro dia até a implementação e qual é a parte mais valiosa da ideia nessas etapas. Essa escolha pode ser difícil e, em última análise, depende da opinião, mas a opinião do cliente - ou de quem representa o seu negócio - tem um papel decisivo. O resultado final das etapas é o mínimo aceitável para o cliente que o projeto deve atingir nesta etapa. Isso geralmente é chamado de produto mínimo viável (MVP) ou uma liberação mínima viável (MVR).


Uma das grandes vantagens é o rápido recebimento de feedback importante dos usuários finais; no entanto, para formar uma opinião, eles precisam de algo bastante substancial. É impossível obter feedback significativo sobre o processo técnico, mas o novo formulário de pedido da VegBox está completo. Naturalmente, isso fará parte de um produto minimamente viável.

Vale lembrar que quanto mais houver em um produto minimamente viável, mais tempo levará para obter feedback, enquanto que se o produto for muito pequeno, não haverá informações suficientes para obter feedback. Você terá que encontrar um equilíbrio entre lucro e risco - não há regra universal aqui. Tente encontrar um ponto em que você receberá feedback útil sobre algo que o ajudará a tomar decisões informadas. Isso será útil para análise de mercado.

Também preste atenção aos termos. Para alguns, a palavra “release” significará um produto disponível para uso, para outros - um produto destinado ao teste por um grupo fechado. Lembre-se de que sempre há a oportunidade de apresentar o produto primeiro a um pequeno grupo e somente depois liberá-lo adequadamente. Mais importante ainda, não assuma que todos entendem os termos da mesma maneira! Não há abordagens absolutamente corretas - escolha a que melhor lhe convier.

Adicionando recursos

Uma vez determinado o que acontecerá em um produto mínimo viável (MVP) ou em liberação mínima viável (MVR), a verdadeira diversão começa. Funcionalidades adicionais ou novos recursos do produto podem ser adicionados em partes ou fazer parte de uma versão maior. Isso se chama entrega incremental e os empresários adoram muito. Não há mais longos anos de espera por um grande lançamento com todos os sinos e assobios. O lançamento do produto ágil é rápido e frequente. E, novamente, é o cliente quem determina o que e quando liberar. No mínimo, um único problema deve conter um recurso que foi comprovado pela prática.

OBTER INFORMAÇÕES

Os resultados do nosso primeiro lançamento - nosso MVP - são efêmeros o suficiente, e precisamos de mais detalhes para transformá-los em um produto completo. O benefício desses resultados é que, nesse estágio, formulamos idéias, portanto, seria inútil desenvolver um perfil de produto completo, que não será necessariamente usado. É mais do que suficiente desenvolver uma visão comum e formular um MVP, sem perceber o próprio produto. No próximo estágio, temos que descobrir os lados positivo e negativo do produto. Uma ferramenta clássica para resolver esse problema é uma história de usuário.

Me conte uma história

Histórias de usuários são pequenas descrições simples das características de um produto do ponto de vista da pessoa que o usará. Geralmente, é um usuário ou comprador. As histórias de usuários geralmente seguem um formato simples.
Sendo <tipo de usuário>, preciso de <alvo> para <razão>.


Uma história de usuário é um conceito abstrato que fornece informações suficientes para que uma equipe possa avaliar realisticamente os recursos necessários para implementar um projeto. As histórias de usuários são frequentemente gravadas em adesivos ou cartões, que são pendurados nas paredes ou dispostos em mesas para facilitar o processo de planejamento.

A história do usuário permite que você se concentre na discussão das características do produto, que é uma etapa importante após o desenvolvimento de uma idéia básica dessas características.

Ninguém o força a usar histórias personalizadas. No entanto, essas histórias nos lembram a importância das discussões coletivas, e os resultados dessas discussões coletivas geralmente são mais importantes do que um plano de trabalho detalhado.


Durante essas discussões, são identificados os principais aspectos das características mais importantes do produto. Lembre-se de que as próprias gravações não significam nada, mas a comunicação coletiva animada nos permite não apenas desenvolver os detalhes fundamentais, mas também manter uma nova visão do projeto. Vencer em todos os sentidos.

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

20% de desconto no cupom para Agroagentes - Agile