O breve

Você é responsável por entregar a maior e mais recente iniciativa da sua empresa que mudará a cara da 'Widgets International' para sempre. É um projeto de software que vai envolver e cativar seus clientes, tornar a vida de seus colegas mais fácil e tornar a empresa milhões em receita. Há muita expectativa, fervor, entusiasmo e expectativa. Você precisa fazer isso o mais rápido possível para que sua empresa comece a colher os benefícios. O sucesso futuro da empresa depende de você. Todos os olhos estão em você. Você não pode falhar.

No início, você pensa consigo mesmo: 'Ótimo, estou pronto para o desafio. Vamos fazer isso! ” Você faz uma pausa por um momento, dá um passo para trás e pensa consigo mesmo: 'Ok, então como faremos isso?' Você começa a conversar com seus colegas e colegas. Você gasta tempo procurando as melhores práticas desenvolvimento de software e Gerenciamento de Projetos técnicas, mas as opções e abordagens são inúmeras. Existem siglas e metodologias em grande quantidade. Os notáveis ​​chegam ao topo. A dúvida se insinua. Qual devemos usar? Como posso garantir o sucesso? E se eu tomar decisões erradas?

Quando se trata de gerenciar projetos de software, há uma mistura inebriante de opções apoiadas por uma miríade de opiniões. Vozes nos cantos da sala sussurram: “Tente fazer desta forma”; outros gritam: “Esta é a única maneira de fazer isso”; e o resto apenas choraminga: 'Não administre isso, apenas siga em frente'. Na realidade, todas essas vozes falam alguma verdade. Mas o importante é descobrir o que é certo para suas necessidades, sua equipe, sua empresa e seus clientes.

Preparando a cena

Houve uma época em que o gerenciamento de projetos de software se encaixava perfeitamente em um dos três campos. Havia estruturas pesadas que permitem tomar decisões sobre como executar e entregar, ao mesmo tempo que oferecem uma estrutura para manter o controle e a governança. Havia metodologias sequenciais prescritivas como cascata que forçou você a planejar projetos longos, entender e se comprometer com todos os seus requisitos, projetar e aprovar sistemas complexos, escrever muitos códigos e, em seguida, testar (tudo antes que seu cliente os veja pela primeira vez). E, finalmente, os ciclos de vida de desenvolvimento de software menos prescritivos, mas iterativos ( SDLC ) que incentivam a prototipagem rápida ou sistemas maiores a serem projetados, construídos e entregues em etapas incrementais, cada um construindo sobre o outro.

Desenvolvimento ágil de software e o gerenciamento de projetos Agile nasceu das inadequações da cascata e dos benefícios das abordagens iterativas para entrega de software. Eles podem traçar suas raízes até os anos 1950, liderança de pensamento nos anos 70, maturidade nos anos 90 e adoção até os anos 2000. Em 2001, um grupo de profissionais e especialistas criou o Manifesto Ágil , com o objetivo de definir 4 valores e 12 princípios norteadores que buscam corporificar o espírito do desenvolvimento ágil de software e estimular sua evolução. E definitivamente evoluiu.

Agora, simplesmente chamar algo Agile não é particularmente útil. A palavra, mesmo em um contexto de software, significa coisas diferentes para pessoas ou organizações diferentes. Existem muitas facetas, definições, implementações e interpretações. Cada corpo que adota o Agile tende a tentar dar a ele sua própria definição.

Simplesmente chamar algo de Agile não é particularmente útil. Tweet

Basta dizer que o desenvolvimento de software Agile e o gerenciamento de projetos são um grupo de comportamentos, estruturas, técnicas e conceitos relacionados que favorecem fundamentalmente a entrega do software de trabalho correto o mais cedo e com a maior frequência possível de forma realista.

Mencionei anteriormente que o Agile, conforme aplicado ao desenvolvimento de software ou gerenciamento de projetos, pode ser coisas diferentes. Resumindo, o desenvolvimento de software Agile cuida do desenvolvimento de um ótimo software em um business as usual (BAU) ou contexto de projeto. O gerenciamento ágil de projetos, por outro lado, cuida da governança e do controle necessários para entregar projetos complexos, incluindo, mas não se limitando a software.

Existem muitos métodos de desenvolvimento de software Agile disponíveis, como Scrum , Kanban , XP e Desenvolvimento Lean de Software . Mas assim como o jogo de rúgbi envolve mais do que um scrum, o Agile também o é. Isoladamente, esses paradigmas Agile não abordam o ciclo de vida completo do gerenciamento de projetos exigido em projetos complexos, como governança, recursos, financeiro, gerenciamento de risco explícito e muitos outros conceitos importantes de gerenciamento de projeto. Para estes, você pode querer considerar PMEs Agile ou PRINCE2 Agile —Pensar nisso como 'Agilidade Governada'.

Por que precisamos ser ágeis?

Há muito tempo, vagamos pela terra para coletar alimentos e abrigo para sobreviver. Eram necessidades simples, mas bastante ágeis. Algum tempo depois, países e economias cresceram e prosperaram na parte de trás do Revolução Industrial . Este foi o nascimento do gerenciamento e controle e a perda de agilidade. Agora estamos no Era ou revolução da informação , onde as empresas empregam trabalhadores do conhecimento. Trabalhadores do conhecimento são você, seus parceiros e seus colegas e pares, que se esforçam para criar grandes soluções para os problemas dos clientes, negócios, sociais, econômicos e mundiais. Os trabalhadores do conhecimento aplicam a análise, o conhecimento, o raciocínio, a compreensão, a experiência e as habilidades a necessidades frequentemente definidas de forma vaga. Essas empresas e trabalhadores precisam de métodos e técnicas que não podem ser atendidos pelos processos e procedimentos da velha Era Industrial. Agile oferece suporte a interações.

Praticamente nenhum projeto de software pode definir com segurança no início e saber tudo o que precisa para entregar software funcional valioso sem alterações. A mudança apresenta oportunidades e riscos para o sucesso de um projeto. Oportunidades não gerenciadas podem significar a diferença entre uma grande empresa e uma empresa incrível. Risco não gerenciado significa desastre e ruína. Agile gerencia mudanças.

A adoção do Agile permite que você responda às mudanças ou aos novos requisitos. Ele capacita as equipes de desenvolvimento a serem especialistas e tomarem decisões apoiadas por uma empresa engajada, confiável e informada. Ele permite que você entregue aos clientes o que eles realmente desejam. Em última análise, coloca você e sua organização no controle do fornecimento de software valioso e de alta qualidade que atende às necessidades e expectativas do cliente, ao mesmo tempo em que obtém um retorno sobre o investimento em dólares o mais cedo possível. Agile cria valor.

Há um custo para adotar o Agile. Não vem de graça. A transformação para uma abordagem ágil de entrega de software pode ser um caminho difícil de seguir. No entanto, se você internalizar a filosofia Agile, agir com cuidado, envolver a equipe certa com a atitude certa, dividir as coisas, torná-las realizáveis ​​e realistas e responder ao feedback, você colherá recompensas. Agile enfatiza a colaboração.

A seguir estão listados alguns benefícios que você pode esperar:

• Velocidade de mercado
• Geração de receita anterior
• Entrega regular de valor real
• Proteção para o seu investimento
• Data, data, data
• Melhor qualidade do produto
• Expectativas gerenciáveis
• Maior satisfação do cliente
• Equipes de alto desempenho
• Melhor visibilidade do progresso
• Previsibilidade, transparência e confiança
• Risco gerenciável

O sucesso não é definitivo, o fracasso não é fatal: é a coragem de continuar que conta.

Winston Churchill pode nunca ter realmente dito isso, mas acho que é um bom resumo do Agile. Sabemos que o Agile é o melhor passo em frente para a maioria dos projetos. Isso o incentiva a se empenhar pelo sucesso, mas sempre repetimos e continuamos a construir sobre isso. O Agile o incentivará a falhar, mas falhe cedo e siga em frente. Ter a coragem de continuar e construir a solução certa com base no insight informado por seu cliente é o que traz a recompensa.

O que devemos ter em mente é que você pode adaptar o Agile às suas necessidades. Use o método e a governança adequados para o seu negócio. Onde quer que você comece, seja fiel ao conteúdo, contexto e espírito do método que você usa - mantenha-o natural. Se você está apenas começando, aprender . Se você já faz isso há um tempo, Compreendo . Se você está se tornando incrível, Aplique . Finalmente, se sua empresa e seus projetos são complexos e interdependentes, governo . Com o tempo, você e suas equipes descobrirão o que funciona melhor para sua empresa.

Viabilidade

Então agora você está pensando: 'Ok, entendi. Como eu começo? Por onde eu começo? ” Bem, com todas as coisas boas, começamos do início. E com o Agile, é se perguntando 'Qual valor de negócio eu quero entregar?' Afinal, é por isso que realizamos projetos, para gerar valor de negócio. Para estabelecer se vale a pena empreender o projeto para derivar o valor do negócio, você precisa entender se é viável.

Visão

Seu projeto foi projetado para aumentar a receita, entrar em um novo mercado, adquirir mais clientes, melhorar a percepção do cliente ou tornar a vida mais fácil para um determinado problema que você identificou? Com isso em mente, você pode definir sua 'visão'.

• Sua visão pode vir de fontes diferentes - sua própria startup ousada para resolver um problema comum, estratégia de gestão de negócios, projeto favorito de seu CEO, uma equipe de produto específica ou mesmo as necessidades do seu cliente.
• Tente dar um passo para trás de seus próprios sapatos e 'ver' como será o futuro com seu novo produto ou serviço nas mãos de seus clientes.
• Envolva seus stakeholders - o CEO, o cara do produto e os clientes. Faça o workshop, não tente fazer isso isoladamente. Desafie as suposições e valide os argumentos.
• Escreva, seja breve. Foco no valor do negócio.
• Refine-o até que todos concordem que a visão ressoa com todos e encontra uma interpretação comum que determina para onde você está indo.
• Sua visão, se válida, raramente muda. Como você vai chegar lá, certamente.

As pessoas não compram o que você faz ou como você faz. Eles compram o “por que” você faz isso. É isso que cria a conexão emocional entre sua empresa e seus clientes. A visão ajudará a ilustrar isso.

É viável?

A viabilidade vem em pelo menos alguns tons. Normalmente, você desejará entender se sua visão de um futuro melhor para sua empresa e clientes é tecnicamente viável e se é viável para sua empresa fazer acontecer.

• Se sua visão é viajar para qualquer lugar do mundo em menos de uma hora, você pode ter um problema com a viabilidade técnica. Uma vez que a ciência, a física e a tecnologia ainda não alcançaram esse sonho, sua solução técnica pode não ser viável em outra coisa senão na teoria. Além disso, se sua solução fosse nova, isso iria muito além da ideia de um produto com minima viabilidade (MVP).

• Para testar a viabilidade técnica de seu produto, considere explorá-lo ainda mais em um projeto de protótipo do Discovery ou executando um Espinho nas fases iniciais do projeto. Você saberá qual método usar pensando na escala ou complexidade da solução que tem em mente.

  “Parte do melhor conhecimento que minhas equipes adquiriram no entendimento da viabilidade técnica veio da execução de um pico. E, muitas vezes, é a solução mais simples que vence! ”

• A segunda sombra de viabilidade a ser considerada é se você, sua equipe ou sua empresa têm as habilidades e a motivação para fazer isso funcionar. Usando um exemplo, se você é ótimo em fazer bolos em casa para o aniversário de seus filhos, isso é fofo. Mas se você quiser transformar isso em um negócio de venda dos melhores bolos para o mundo, precisa entender se pode torná-lo escalável, lidar com os negócios e também com a produção, gerenciar a distribuição e o atendimento e cuidar do atendimento ao cliente.
• Esse tipo de visão pode ser alcançável a longo prazo. Mas, por enquanto, possivelmente não. Portanto, reduza, pense pequeno, pegue um pedaço pequeno que pareça realista e concentre-se em fornecer a melhor aspiração menor possível. Se isso conseguir envolver e encantar seus clientes, faça com que eles voltem para mais e conte aos amigos e, a partir daí, aumente a escala usando o feedback do cliente como guia e bússola.
• Além disso, você precisa saber se o seu projeto é viável em termos de orçamento e prazo. Sua empresa pode se dar ao luxo de entregar este projeto? O prazo é alcançável? Tempo e dinheiro são duas das três restrições em um projeto Agile que são corrigidas. Nosso objetivo é entregar dentro de um determinado tempo e orçamento fixos.
• A qualidade de um produto se refere ao produto final que seus clientes usam e às práticas de engenharia que sua equipe usa para entregar um software excelente, robusto e confiável. Qualidade também é algo que não deixamos de lado. Os critérios de qualidade, por outro lado, podem mudar. Se você não pretende construir uma Ferrari, o produto pode não ter uma percepção de alta qualidade. Se você não está construindo foguetes espaciais, então as tolerâncias alcançadas em termos de produção podem ser muito maiores. Defina o tom apropriado e a expectativa desde o início.

Então, agora você confirmou que seu sonho é mais do que chocolates sofisticados, comece a testar suas suposições e a provar às pessoas que vale a pena investir neste esforço.

Justificação

Agora, dependendo de suas circunstâncias, a justificação virá em diferentes formas. Mas, essencialmente, você quer provar que este projeto irá satisfazer os critérios de sucesso do cliente, tem uma chance de sucesso, entregará valor e é acessível.

• Declare suas suposições com base nas necessidades do cliente e, em seguida, valide-as. o Lean Startup oferece grande orientação sobre como identificar e provar que seu produto é necessário para seus clientes e criará valor.

• Escreva, teste e valide seu plano de negócios. Agora, isso não se parece em nada com os que seu banco ou seu major de negócios e finanças lhe disseram para produzir. Não os use - eles estarão desatualizados antes de a tinta secar. Em vez disso, verifique o Business Model Canvas . Este é essencialmente um plano de negócios resumido que mantém seu foco em sua proposta de valor, seus clientes, receitas e custos. Use-o para validar se você tem um negócio que vai funcionar.

  “Eu ignorei esse conselho uma vez e passei muito tempo escrevendo um longo plano de negócios tradicional de 50 páginas. Não me levou a lugar nenhum. Todas as suposições que fiz eram infundadas e todas as projeções que fiz não puderam ser validadas. Foi uma experiência dolorosa e cara que me ensinou a nunca mais fazer isso. ”

• Se você está em um negócio maduro com portfólios de projetos sendo entregues em um ambiente complexo, a modelagem financeira pode ser necessária. Se for preciso, faça isso somente depois de provar o que foi dito acima.
• Depois de construir seu MVP, pode haver um caso para a criação de um plano de negócios mais tradicional - por exemplo, se você tiver que buscar financiamento ou seleção dentro do portfólio de projetos e recursos concorrentes de sua empresa. Mas este será um plano de negócios baseado e informado pelas ferramentas utilizadas acima. Vai ficar mais leve também.
• Em qualquer caso, use essas ferramentas como artefatos vivos que respiram. Use-os como seu guia e referência. Eles nunca são estáticos. Consulte-os e revise-os à medida que seu projeto ou negócio evolui.

Assim que tiver sua justificativa e todas as partes interessadas estiverem a bordo, você estará em chamas.

A fase de viabilidade normalmente é realizada uma vez na vida do projeto. Você pode descobrir que revisou a visão e a viabilidade do projeto, especialmente se seus dados, clientes, mercado ou negócio indicarem isso. No mínimo, eles serão suas luzes orientadoras durante todo o processo.

Iniciação

Impressionante. A decisão foi tomada, o projeto tem luz verde e você está pronto para construir. Bem, quase. Eu sei que você está pensando: 'Vamos já, sério? Se não fizermos isso agora, nunca faremos. Vamos colocar esse show na estrada! ” Mas considere isso - o Agile não é nada senão entregar valor no início e frequentemente, enquanto encanta seus clientes ao longo do caminho. Dedicar algum tempo para descobrir a melhor maneira de entregar seu projeto é a base mais bem construída para o sucesso.

O time

Nos esportes, ao pensar no seu jogo de equipe favorito, você será capaz de reconhecer os principais papéis que permitem que a equipe atue como o faz. Tradicionalmente, você encontrará um gerente, um capitão e o resto do time. Fora disso, você encontrará treinadores, fisioterapeutas, nutricionistas e uma variedade de funcionários de apoio. Mas se olharmos para o jogo de rúgbi, há uma equipe dentro da equipe: os jogadores que compõem o scrum . Este pacote é composto por jogadores designados cujo trabalho é recuperar a bola e continuar o jogo. Quando um scrum está em jogo, os jogadores de cada lado trabalham, sem líder, como uma única unidade da maneira mais colaborativa, comunicativa e eficiente possível para recuperar a posse de bola. É o jogo de rugby que inspirou Jeff Sutherland para nomear sua metodologia de desenvolvimento de software 'Scrum'.

• Scrum não é o único método de desenvolvimento de software no manual Agile. Mas é o que melhor descreve o conceito Ágil e os comportamentos de trabalho em equipe, motivando indivíduos, criando relacionamentos de confiança, auto-organização, liderança servil , comunicação, transparência e colaboração.
• Sua equipe será formada em grande parte pelas circunstâncias em que você se encontra. Você pode ter desenvolvedores disponível para você. Alguns, nenhum ou todos eles podem estar familiarizados com o Agile em vários graus. Você pode querer contratar uma nova equipe ou parceria com terceiros.
• Outras funções também serão necessárias, mas vamos discuti-las mais tarde.
• Já foi dito que se você forma sua equipe de desenvolvimento, então você escolheu sua tecnologia. Dependendo de onde você reúne sua equipe, eles virão com conjuntos de habilidades específicas. Portanto, pense cuidadosamente em como formar sua equipe de desenvolvimento e se você precisa realizar uma avaliação técnica antes de chegar a este ponto em sua jornada.
• Isso nos leva a equipes multifuncionais. As equipes trabalham melhor quando trabalham juntas, quando os indivíduos contribuem para fazer o trabalho independentemente de seu cargo. Tente formar uma equipe que seja autossuficiente e indivíduos que desempenhem mais de uma função.
• Construa um ambiente, uma cultura e um centro de relacionamento - um lugar onde a equipe pode entregar, livre de restrições ou restrições. Dê à equipe as ferramentas, pessoas, recursos e espaço para ser eficaz e ter um bom desempenho.
• Mantenha o tamanho das equipes em não mais que sete ou oito. Se você precisar de muito mais desenvolvedores, divida a equipe em várias novas equipes. Cada equipe pode ser responsável por uma determinada área funcional. Se você tem várias equipes em vários locais, considere a possibilidade de realizar um Scrum de Scrums. E onde eles são numerosos em ambientes complexos, use o gerenciamento de projetos Agile.
• Certifique-se de que a equipe, o negócio, as partes interessadas e até mesmo os clientes tenham acesso uns aos outros. Certifique-se de que eles se comunicam e colaboram e remova qualquer coisa que atrapalhe o progresso. A comunicação diária é a melhor cura para as doenças do projeto. Quando as pessoas falam, elas fazem as coisas.

Há muitas maneiras de formar uma equipe para fornecer software.

Resumo do projeto

Na etapa de viabilidade, você descobriu o “porquê” do seu projeto e criou sua confiança para seguir em frente com sua startup ou obteve apoio para prosseguir. O resumo do projeto é o documento vivo que reúne o 'por quê' com o 'o quê' e 'quando' e 'quem'. É 'viver' porque, conforme você progride, seu conhecimento, compreensão e caminho podem mudar. Deixar este documento uma vez escrito e nunca mais retornar a ele apenas remete seus pensamentos para um ponto no tempo. Em um mundo Agile, sua referência point-in-time pode mudar semanalmente ou mesmo diariamente no início, por isso é importante mantê-la atualizada.

• Uma ótima ferramenta para encapsular e manter o resumo do seu projeto é algo que Jonathan Rasmusson chama de 'plataforma inicial' em seu livro O Agile Samurai . Aqui, você encontrará ótimos conselhos sobre como garantir que todos os interessados, afetados ou envolvidos com seu projeto estejam na mesma página.
• O maior inimigo da entrega de projetos é ter um entendimento pouco claro, inconsistente ou simplesmente diferente do que é o projeto e quais “requisitos” devem ser satisfeitos. Mesmo que uma parte interessada importante tenha uma compreensão ou visão diferente do que você está fazendo, as consequências podem ser substanciais.
• Um bom resumo do projeto comunica:
  1. Uma expectativa comum e acordada entre as partes interessadas e os membros da equipe.
  2. Uma compreensão do projeto, com a mesma compreensão por todas as partes.
  3. A meta, visão, objetivo, escopo e contexto do projeto.
• Você terá muitas informações boas para o brief, reunidas a partir da viabilidade. O resumo do projeto o ajudará a definir e encontrar as respostas para as perguntas de pesquisa. Ele reunirá as partes interessadas, seu objetivo , escopo de alto nível, riscos, solução de destino, orçamento, cronograma, expectativas e prioridades.

Um colega uma vez me parou em um corredor e me perguntou onde poderia conseguir o briefing do projeto para o projeto. Eu brinquei 'Não precisamos de um briefing, somos ágeis'. Ele parecia confuso, como se questionasse minha sanidade ou autoridade. Ele estava certo em fazer isso.

Antes de continuar, certifique-se de que todos estão na mesma página, faça um workshop, faça as perguntas difíceis e acerte em algum lugar onde as pessoas possam parar, ler, comentar e ajudar a revisá-lo.

Cultura e formas de trabalhar

Você conhece a forma como sua empresa funciona e sua cultura, como ela gosta de fazer as coisas. O Agile, por sua própria natureza, pode desafiar algumas dessas formas de trabalho que sua empresa cultivou ao longo dos anos. Não espere que o Agile seja implementado e que todos o adotem com amor desde o início. Algumas pessoas podem achar isso confuso e vê-lo apenas com pavor e medo. Algumas pessoas podem se recusar abertamente a se envolver nisso. Esses são desafios e percepções que você deve superar. Mas em seus primeiros dias, não saia por aí agitando o bastão Agile batendo em alguém que não quer ouvir com ele. Isso não vai construir confiança, adoção ou envolvimento.

Eu já fui fã de balançar grandes bastões proverbiais uma vez, e isso me rendeu muitos comentários negativos na imprensa. Eu o virei, mas não antes de sofrer uma dor considerável primeiro.

Ao iniciar seu caminho de adoção, siga com cuidado, respeito e empatia. Se você está em um negócio tradicional antigo e decadente, talvez não seja a melhor abordagem para alinhar todo o negócio. Comece pequeno e gradualmente ganhe respeito e reconhecimento. Comece apenas com sua equipe. Assim que você começar a fornecer um software mais rápido e com melhor qualidade do que nunca, as pessoas começarão a notar e vão querer jogar seu jogo. Quando o fizerem, ofereça-lhes a bola, leve-os para um café e leve-os para o seu novo mundo. Ajude-os.

Com sua equipe, agora que eles sabem do que se trata o projeto e seus planos para a adoção do Agile foram acordados, deixe a equipe decidir como deseja se comportar e operar como uma equipe.

• Oriente sua equipe para identificar os conceitos, técnicas, comportamentos e estruturas Agile que você acha que se ajustam às suas necessidades coletivas.
• Aceite as solicitações dos membros da sua equipe sobre quais requisitos eles têm para ajudá-los a ter o melhor desempenho possível. Algumas dessas solicitações, você poderá resolver imediatamente. Outros, você pode precisar de um orçamento ou ajuda externa. Faça o que puder para que isso aconteça
• Estes são os primeiros passos para se tornar um verdadeiro líder-servo.
• Considere organizar algum treinamento apropriado nos conceitos e técnicas que sua equipe está optando por adotar. Essa é a melhor maneira de garantir que todos os membros da sua equipe, mesmo as partes interessadas, estejam na mesma página e recebam a mesma mensagem. Trabalhe com uma organização de fornecedores que possa adaptar suas ofertas às suas necessidades.
• Seja prudente. Ninguém será um ninja Agile depois de alguns dias em um workshop aprendendo como se tornar Agile. Seu caminho será longo. A palavra “tornar-se” é bastante definidora. Somente quando você realmente abraçar o Agile, verá seu valor. Isso deve excitar você. Se isso te excita, então excite os outros também.
• Agora que sua equipe concordou com os conceitos e técnicas, teve seus desejos atendidos e está em treinamento Agile, volte a atenção de sua equipe para si e para o que eles esperam de você, da empresa e uns dos outros.
• Definir algumas formas de trabalho (WoW) dentro e pela equipe ajuda a construir confiança, relacionamento e expectativas. O WoW é não Guerra e Paz . Deve ser curto e direto, entre sete e dez frases pontuais. Essas frases afirmam claramente como as pessoas se comportam, comunicam, colaboram, apóiam, atuam e atuam juntas. Também deve indicar o que a equipe espera do negócio.

• O Agile é tanto uma mentalidade quanto princípios e conceitos orientadores. Ajuda a desenvolver a maneira como você se comporta, pensa, negocia, interage, comunica, executa e melhora. Depende de indivíduos motivados que apoiam uns aos outros para alcançar um objetivo comum, juntos como um só. Existe um provérbio africano:

Se você quiser ir rápido, vá sozinho. Se você quer ir longe, vá junto. Tweet

A esta altura, sua equipe deve estar super animada, energizada e motivada. Agora, envolva-os ainda mais com seu acúmulo de histórias de usuários.

Backlog

Não tenha dúvidas de que há incerteza envolvida em seu projeto. Você não pode saber exatamente o que será necessário para construir o produto certo para seus clientes tão cedo em sua vida. Você não pode olhar melancolicamente para uma bola de cristal e prever o futuro.

O “backlog” ou “product backlog” é onde residem seus requisitos. O Agile favorece a escrita de declarações curtas e enérgicas que capturam a essência de um 'requisito'. O backlog é simplesmente uma longa lista de entradas, cada entrada definindo um único “requisito” discreto como uma história de usuário. E de agora em diante, usaremos a palavra história do usuário, e não 'requisito'. Você provavelmente está perguntando 'por quê?' Esta é uma boa pergunta. Pelo que parece uma eternidade, declarar os recursos ou facetas necessários em um projeto de software por um cliente sempre foi referido como um requisito. Essa palavra tem uma interpretação que não tem valor no Agile. O dicionário Oxford o define como:

Algo que é necessário ou desejado. Ou algo que é obrigatório ; um necessário doença .

E infelizmente, se nos propusermos a definir qual deve ser a nossa solução, afirmando que as coisas são “obrigatórias”, vamos acabar em apuros. É muito fácil dizer que todas essas histórias de usuários são obrigatórias. Se tivermos essa visão, corremos o risco de ultrapassar o cronograma e o orçamento na tentativa de entregar tudo de um determinado escopo. Não é problema dizer que, para este produto essas histórias são necessárias para que a solução seja viável, queremos apenas evitar a interpretação dessa palavra em particular.

• Sempre escreva histórias da perspectiva de um pessoa . Uma persona representa um usuário ou parte interessada da solução. É uma boa ideia desenvolver essa persona antes de começar um backlog.
• Nesse estágio, escreva apenas afirmações curtas e simples que basicamente sugiram um lembrete para ter uma conversa mais profunda sobre a história do usuário quando chegar a hora certa.
• Pessoas reais pensam em termos de tarefas que precisam ser realizadas para atingir um objetivo. Escreva suas histórias da perspectiva da pessoa e em termos do que elas precisam ser feitas.
• Você não precisa escrever o backlog completo - basta escrever o máximo que você imaginar que seus clientes precisarão para que seu produto seja viável.
• Você descobrirá mais tarde, ao longo da vida do produto, que as histórias de usuários mudarão, se tornarão mais ou menos importantes ou podem ser excluídas completamente. Liberar com frequência, obter feedback e avaliar o que é uma prioridade informará esse comportamento.
• Não escreva histórias isoladamente. Envolva sua equipe, stakeholders e até mesmo seus clientes. As histórias podem ser atualizadas a qualquer momento na vida de um projeto, mas devem evitar ser alteradas depois que o trabalho de desenvolvimento for iniciado.
• Algumas de suas histórias podem ser consideradas 'épicas'. Essas são histórias grandes que cobrem muito e serão divididas em histórias menores próximo ao momento da entrega.
• Considere usar o INVESTIR modelo, uma lista de verificação para validar a qualidade de uma boa história de usuário.
• Qualquer pessoa pode adicionar uma história ao backlog. Deve ser colocado na parte inferior ou em um 'estacionamento' especialmente criado. Essa história adicionada serve como um prompt para discutir com a equipe e a empresa. Se a empresa e a equipe o apoiarem, ele pode ser estimado e priorizado
• Você também pode considerar as partes do sistema que são mais arriscadas. Se você tiver uma história de usuário ou recurso que seja complexo, novo ou tecnicamente desconhecido, priorize-os no topo de sua lista de pendências. Dessa forma, você não tentará entregar as partes desafiadoras e críticas do seu produto apenas semanas antes do primeiro lançamento.

Depois de ter um backlog que atende às suas necessidades, você pode estimar as histórias nele, classificá-los em ordem de prioridade e construir um plano de liberação.

Estimativa e priorização de alto nível

A estimativa de alto nível é o processo de dimensionar sua carteira. Quão “grande” é o projeto e que valor ele oferece? Priorização é o processo de decidir quais histórias são mais importantes para você, a viabilidade do produto e os interesses de seus clientes. Queremos entregar os itens de maior valor o mais rápido possível para entregar o máximo valor ao negócio, obter feedback do cliente e não se preocupar com as pequenas coisas. A saída será uma lista de pendências ordenada classificada em prioridade e dimensionada apropriadamente.

• As histórias no topo são consideradas as mais valiosas. Queremos entregar os itens mais valiosos o mais cedo possível.
• Existem muitas técnicas para dimensionar e estimar, mas, neste ponto, você só quer ter uma boa ideia do tamanho de uma história.
  • Use tamanhos de camiseta, tamanho relativo, dias ideais ou pontos da história.
• Você não terá todas as informações disponíveis neste momento, e tudo bem. Apenas corra com isso.
• Envolva os stakeholders de negócios ou gerente de produto, se houver, e a equipe que fará o trabalho.
• Queremos aqueles que irão projetar, desenvolver e testando o trabalho para dimensioná-lo, porque as melhores pessoas para estimar são os especialistas.
• A equipe pode começar a dividir as histórias em partes menores. Se isso acontecer, escreva histórias que sejam mais granulares, mas discretas.
• A equipe também pode começar a classificar algumas histórias, já que, naturalmente, algumas coisas precisam ser entregues antes de outras para dar suporte à tecnologia ou a uma determinada jornada do usuário.
• Entre você e a equipe, você também pode começar a encontrar lacunas na lista de pendências que precisam ser preenchidas. Basta preencher essas lacunas com novas histórias e estimar e priorizar conforme apropriado.
• A priorização é mais facilmente realizada usando uma análise MoSCoW. MoSCoW é uma técnica simples que ajuda você a decidir quais histórias são 'obrigatórias' para que seu produto seja bem-sucedido.
• Você pode fazer uma passagem de priorização antes do início da estimativa. No entanto, o dimensionamento de certos elementos também pode determinar uma decisão sobre a prioridade e o valor real do negócio. Portanto, jogue a estimativa e a priorização um do outro, mas não brigue por isso!
• Duas histórias não podem ser tão importantes quanto a outra. A história na classificação 1 é mais importante ou valiosa do que a história na classificação 2.
• Uma ótima maneira de demonstrar a importância ou o valor de uma história é adicionar um valor monetário a ela. Se, por exemplo, se pensa que a história A traz $ 5.000 de receita extra e a história B pode atrair $ 100, então a história A é mais valiosa. Da mesma forma, se a história C salva mais os negócios do que a história D, a história C é mais valiosa.
• Depois de dimensionar seu backlog, você ficará com um número. Quando chegarmos ao planejamento da liberação, esse número nos ajudará a entender o quanto pode ser entregue por nossa equipe em um determinado prazo.

Lembre-se de que você não precisa saber todas as suas histórias de usuário antecipadamente. Além disso, lembre-se de que não é necessário entregar todas as suas histórias antes que um cliente veja seu produto. Você deseja permanecer ágil - e isso significa apenas criar o que você precisa, quando precisa, desperdiçando o mínimo possível e respondendo às mudanças nas necessidades do cliente e nas condições de mercado. Um roteiro o ajudará a traçar seu produto e planejar seus objetivos para os próximos 3, 6, 9 e 12 meses.

Roadmap e Storymaps

PARA roteiro é exatamente o que parece, oferece o mesmo que um roteiro de um país. Ele detalha a posição relativa das cidades (ou, no seu caso, recursos) entre si e as rotas que podem ser tomadas para ir da cidade A para a cidade B, ou o recurso X e o recurso Z. Não informa qual rota você deve tomar, ou como você deve chegar lá. Não informa qual meio de transporte usar, mas pode ilustrar opções para pegar a rodovia ou o trem.

Em uma cidade, existem muitas estradas, edifícios, parques, serviços e instalações. Todas as características de uma cidade. Isso também se aplica ao roteiro de seu produto. Nesse nível, seu roteiro mostra os principais objetivos ou marcos a serem alcançados. Uma meta é um agrupamento lógico de temas, recursos e histórias do usuário reunidos em uma visualização consumível que demonstra valor tangível. O roteiro de um produto de software compartilha essa visão e comunica sua intenção. Não necessariamente mostra como ou quando os recursos serão entregues; apenas o valor relativo das metas e recursos para você e sua empresa.

Uma ótima maneira de demonstrar um roteiro é gerar um mapa da história . Esta ferramenta indica a priorização valorizada pelo cliente. Ele estabelece a espinha dorsal, ou blocos de construção essenciais de seu produto. O esqueleto ambulante fica pendurado no backbone e ilustra os recursos que o tornam um MVP. Todos os outros recursos são o que agregam mais valor e importância ao sistema. O mapa da história apresenta recursos em posição relativa uns aos outros e é uma ferramenta visual incrível.

É importante notar que depois de realizar um exercício de mapeamento de histórias, seu backlog pode precisar ser refinado. Isso ficará claro onde as histórias foram divididas em várias histórias, identificadas como redundantes, recém-criadas ou como uma prioridade mais alta ou mais baixa do que se pensava anteriormente. O mapa da história é outro artefato que é continuamente revisitado e revisado.

A fase de iniciação normalmente é realizada uma vez na vida de seu projeto. No entanto, muitas das ferramentas e documentos que você criou serão revisitados e revisados ​​ao longo do projeto.

Planejamento de Liberação

“Finalmente”, ouço você chorar, “finalmente, algum planejamento”. Bem, você essencialmente planejou todos os estágios de viabilidade e iniciação; nós apenas não chamávamos assim. Isso é evidência de planejamento iterativo ou adaptativo - a arte de planejar apenas o suficiente para atingir seus objetivos imediatos e mais valiosos. Veremos mais tarde mais sobre planejamento adaptativo, mas, por enquanto, o planejamento de lançamento é o nosso foco.

Seu plano de liberação pode muito bem ser determinado por eventos externos. Talvez haja uma feira de negócios em que você queira demonstrar seu aplicativo ou seus clientes obterão o máximo de benefícios usando seu aplicativo nas vésperas do Natal. Estes são eventos da linha do tempo com os quais seus objetivos podem estar alinhados. Você provavelmente planejaria fornecer histórias de usuário ou recursos que façam mais sentido para facilitar esses eventos. Se não houver datas externas que você precise considerar, você pode simplesmente optar pela priorização de recursos e fornecer o quanto antes o que faz mais sentido e agrega mais valor aos seus clientes.

• Se você criou um mapa da história na iniciação, isso ajudará a orientar seu plano de liberação. Use-o para identificar seu MVP, o conjunto mínimo de recursos que colocará seu produto nas mãos de seus clientes, começará a gerar receita, obter feedback e conquistar mais clientes.
• O mapa da história também o ajudará a criar lançamentos futuros. Mas lembre-se de que conforme você aprende, obtém feedback, inspeciona e se adapta, as versões futuras podem mudar. Portanto, não planeje em detalhes.
• Você pode ter de dois a quatro lançamentos em um período de 12 meses. Não faça menos, porque seu primeiro lançamento é o seu MVP e coloca o pé na sua porta, depois do qual você vai querer iterar e lançar mais recursos e correções de bugs em um ciclo regular. Não faça mais, a menos que esteja tendo um bom desempenho e tenha muitas técnicas e ferramentas Agile para gerenciar a entrega contínua.
• Cada versão é uma caixa de tempo que é dividida em iterações menores. Uma iteração é uma caixa de tempo. O timebox é uma das medidas de controle mais importantes no Agile.
• Para dimensionar seu lançamento:
  • Divida sua caixa de tempo de lançamento por dois. Isso lhe dará quantas iterações você tem. Portanto, se você tiver um release de 12 semanas, terá seis iterações de duas semanas.
  • Em seguida, remova duas iterações - você reservará uma para uma iteração 'sprint 0' e outra para uma iteração 'release'. Isso deixa você com quatro iterações de desenvolvimento.
  • Trabalhe com sua equipe e o product owner para preencher cada iteração com histórias, começando do topo da lista de pendências e trabalhando para baixo. Quando a equipe achar que preencheu uma iteração com histórias suficientes que possam ser alcançadas de forma realista com base em sua capacidade no período de duas semanas, repita para as próximas iterações. Use o plano de liberação e o mapa da história para orientar o que acontece em cada iteração.
  • Não planeje o próximo lançamento ainda. Você fará isso quando estiver perto do final da versão atual.
  • Pegue as histórias de usuário de cada uma de suas iterações e some os tamanhos das histórias. Portanto, se sua iteração 1 tiver 25 pontos de história, mas as iterações 2, 3 e 4 tiverem 10, 45 e 65 pontos, respectivamente, você precisará refatorar. Almeje um número igual de pontos de história em cada iteração. Essa se torna sua velocidade prevista - a quantidade de 'coisas' valiosas concluídas para cada iteração.
• A equipe pode não ter trabalhado junta antes. É quase certo que estejam trabalhando em um novo problema ou produto. Eles não terão o melhor desempenho desde o primeiro dia. Por esse motivo, sua velocidade pode ser volátil nos primeiros sprints. Mas à medida que a equipe se acomoda, ela deve se estabilizar. Use esses dados para refatorar seu planejamento de lançamento que, por sua vez, ajuda a planejar seu produto com velocidade e confiança conhecidas.
• Se necessário, divida as histórias em partes menores e redimensione.
• Seu plano de liberação, especialmente no início da vida de um projeto e uma nova equipe, é sempre apenas um guia. Não trate isso como um compromisso ou garantia de que todas ou essas histórias exatas serão entregues conforme planejado. À medida que sua equipe amadurece, o trabalho é realizado e a confiança aumenta, assim como a precisão de seus planos.
• Nunca force sua equipe a 'se comprometer' com mais do que eles se sentem confortáveis. Confie em seu julgamento e experiência.
• Os exercícios de planejamento de versões futuras serão mais simples, porque você pegará o tamanho da versão, multiplicará o número de iterações pela velocidade de sua equipe e preencherá o plano de versão com as histórias que somam a velocidade multiplicada pelo número de iterações.

Considere isso como um exemplo. Se você vai a um restaurante para comer, não vai pedir todos os itens do menu e espera comer tudo de uma vez. Você nunca seria capaz de comer tudo, você pode não pagar o custo, você vai enjoar de comida e o restaurante pode fechar enquanto você está comendo o quinto de 19 pratos! Você pode não deixar um cliente satisfeito, o restaurante pode não considerá-lo um grande cliente e a experiência será ruim para todos. Mais provavelmente, se você adora o restaurante, será porque você desfrutou de uma bela refeição lá uma vez. Você vai decidir voltar e desfrutar de uma refeição diferente. Você vai dizer a seus amigos, você vai lá com frequência. A moral da história é:

• Planeje seus lançamentos em pequenos pedaços.
• Considere sua capacidade.
• Não faça mais do que você pode realmente realizar.
• Reveja o plano com frequência para ver o que você pode mudar e melhorar.
• Planejar, executar, inspecionar, aprender, adaptar, repetir .

O planejamento da liberação geralmente ocorre em um projeto de software. Cada novo lançamento requer um plano de lançamento. O plano de liberação também pode ser refatorado a qualquer momento durante um projeto. Apenas tome cuidado para não exagerar e cair na psicose de planejamento zumbificada. No final do planejamento de lançamento, você vai querer se preparar para a primeira iteração, que é para onde iremos a seguir!

Iterações de produto

Sua equipe está pronta, eles estão motivados, você tem um negócio engajado, seu planejamento inicial está feito - agora você está pronto para construir seus sonhos.

Falamos anteriormente sobre algumas das ferramentas, técnicas e conceitos que o Agile subscreve. Já existem muitos recursos disponíveis que fazem um ótimo trabalho no estabelecimento das bases para a entrega de um projeto de software Agile. Escolha um, mantenha-o simples e cresça em sua jornada Agile. Para ajudar a reduzir o trauma na decisão da metodologia de desenvolvimento de software Agile certa para começar, eu recomendo o Scrum. E apenas Scrum. Haverá a tentação de usar elementos de outras metodologias. Não faça isso ainda. Guarde esse tipo de mudança até que você tenha vivido e respirado Scrum por 6 ou 12 meses. Então, se você determinou que sozinho não funciona para você ou se deseja amadurecer como uma equipe, introduza constantemente novos métodos, técnicas ou estruturas.

eu escolho Scrum como a abordagem recomendada para a adoção do Agile por uma nova equipe, porque tem todos os princípios básicos integrados. É muito popular e tem muitas comunidades e recursos de boa qualidade online, em livros ou na sala de treinamento. Isso o atenderá bem, mesmo para as equipes menores. O restante deste post é dedicado a discutir alguns aspectos importantes da entrega de software que você, sua equipe e as partes interessadas devem sempre ter em mente.

Planejamento Adaptativo

O planejamento em um projeto Agile é um processo contínuo. Fazemos um planejamento inicial com antecedência, apenas o suficiente para entender o que sabemos em um determinado ponto. Nossos planos iniciais serão vagamente definidos e falhos. E então iteramos nosso planejamento, adaptando-nos às novas informações, planejando com mais detalhes antes de iniciarmos a entrega, respondendo às mudanças no escopo. Essa é uma forma de minimizar o desperdício - apenas nos esforçando para planejar quando necessário.

• A equipe e a empresa, ou seu representante informado e autorizado, como um gerente de produto, planejam ativamente em conjunto - a equipe porque são os especialistas que irão entregar e o gerente de produto porque são os especialistas que podem orientar as necessidades da empresa.
• As estimativas para histórias de usuários serão menos precisas quanto mais longe estiverem de serem desenvolvidas. Por exemplo, as epopeias atrairão estimativas de alto nível que serão baseadas em muitas incógnitas. Histórias de usuários bem definidas e granulares estimadas pouco antes do início de um sprint serão muito mais precisas.
• Existem muitas “escalas” de estimativa que você pode usar. Use a técnica que achar mais adequada para sua equipe e o estágio certo de planejamento - Wide Band Delphi, planejamento de pôquer , hora ideal, tamanho relativo, pontos da história ou tamanhos de camisetas.
• Ao dimensionar uma história, um tamanho realmente serve para todos. Todas as histórias devem ser dimensionadas usando a mesma técnica e abranger todos os elementos, como design, desenvolvimento, teste e refatoração. Quando você começa a fazer o planejamento de iteração para um sprint, certas tarefas podem ser criadas e todas contribuem para a conclusão da história.
• Sempre considere risco, incógnitas, influências externas, a capacidade de sua equipe e a velocidade cada vez maior de planejamento.
• Se as histórias de usuário que foram levadas para um sprint não foram concluídas, não estendemos o timebox. Esses itens inacabados ou não iniciados são colocados de volta no topo da lista de pendências e levados para o próximo sprint.
• Sempre planeje entregar a menor quantidade necessária para atingir uma determinada meta. Identifique técnicas para podar recursos. Reduza o desperdício e encontre o valor real que pode ser fornecido de forma realista com seus recursos limitados de tempo.

Criação de História

As histórias são elaboradas quando você precisa delas. Você não precisa de explicações completas da história para recursos que ainda faltam seis meses para serem entregues. Escrevê-los no início pode ser um esforço desperdiçado, quando essa necessidade desaparece do escopo. Escreva suas histórias no máximo duas iterações antes de serem necessárias. É preferível reduzir esse período para um sprint.

Vamos dar um tempo no sprint 0 para definir o cenário. Em duas semanas, você começará o desenvolvimento. Agora é hora de pegar o suficiente das histórias do topo da lista de pendências que poderiam potencialmente ser entregues no sprint 1. Você pode pegar de 10 a 15% a mais se não tiver certeza de sua velocidade. Esses one-liners agora podem ser expandidos em documentos verdadeiramente valiosos com cenários, critérios de aceitação e wireframes. Se os wireframes ainda não foram criados, agora é a hora de fazer isso. Você pode descobrir, ao revisar essas histórias de candidatos, que elas precisam ser divididas. Talvez fossem épicos que não poderiam ser concluídos em uma corrida. Se você dividir as histórias, reavalie-as com a equipe.

PARA boa história segue as seguintes regras: - Escrito em um formato comum, por exemplo, COMO A EU QUERO ASSIM. - Inclui os critérios de aceitação que a história deve atender para ser considerada aceitável pela empresa para aprovação. - Usa uma linguagem que a empresa e seus clientes entendem. - Segue o modelo INVEST. - Inclui todos os documentos de suporte para informar o desenvolvedor, designer e testador: wireframes, visão geral do design técnico, outros ativos. - Atende aos seus critérios padrão de “definição de pronto”.

Sprinting

Independentemente de você chamá-lo de sprint, iteração ou timebox, cada entrega incremental de seu projeto Agile tem um tempo limitado. O timebox não diminui e não aumenta. Concentre-se em iterações de duas semanas no início. Você pode descobrir que 1, 3 ou 4 semanas se adequa melhor ao seu modelo de negócios. Depois de escolher um comprimento, não o altere. Você deseja manter um regular cadência , ou um ritmo sustentável. Isso significa que a equipe e os negócios se concentram na entrega de software regular, sem o emprego de horas extras loucas para fazer o trabalho e liberar incrementos potencialmente entregáveis ​​a cada duas semanas.

• Trabalhar em pequenos incrementos traz um grande benefício. Isso significa que você está se concentrando apenas no futuro imediato da entrega e, com novas contribuições, feedback e aprendizado, pode responder às mudanças em um curto ciclo iterativo.
• No início de uma versão, execute um sprint 0. Isso permite que a equipe, a empresa e a versão do seu projeto se preparem e defina a mentalidade para uma entrega bem-sucedida. Desenhe a estrutura técnica e a arquitetura de base que darão suporte à base para o lançamento. Configure ambientes, contas e ferramentas. Execute picos para entender problemas difíceis ou desconhecidos. Elabore suas histórias de usuário em prontidão para o sprint 1. O Sprint 0 trata de se preparar.
• Durante um lançamento, continue refinando o backlog. Conforme você entende mais ou aprende algo novo, suas prioridades podem mudar, novos requisitos podem surgir e o que você pensava anteriormente ser um grande recurso pode ser totalmente removido.
• Não comece um trabalho que não tenha chance de ser concluído em um sprint. Se não puder, divida-o em pedaços menores. E não comece um novo trabalho quando o trabalho iniciado anteriormente não tiver sido concluído. Você não cria nenhum valor começando muitas coisas que não podem ser consideradas completas. Além disso, evite mudança de contexto . Esta é a atividade de iniciar uma tarefa, ficar perturbado, iniciar outra e, na sua forma mais problemática, não concluir nenhuma delas.
• Limite a quantidade de trabalho em andamento pela equipe a qualquer momento. Por exemplo, se você tem três desenvolvedores e um testador, pode colocar um limite de WIP para os desenvolvedores e para o testador.
• Nunca acrescente mais trabalho a um sprint depois que ele foi planejado. Nunca pare um sprint no meio. As exceções são:
  • Se você teve um desempenho mais rápido do que o esperado, considere pegar a próxima história do topo da lista de pendências, desde que esteja preparada adequadamente.
  • Se o sprint tiver um desempenho tão ruim que não será concluído. Normalmente, isso só acontece onde houve uma catástrofe de alguma descrição.
  • Se o objetivo do sprint não puder mais ser suportado devido às necessidades de mudança imediatas do negócio.
• Se você cancelar um sprint, faça-o com elegância, reserve um tempo para refocalizar e inicie um novo sprint como faria com qualquer outro.
• Perto do final de uma versão, considere um sprint de lançamento final. Nenhum novo recurso é escrito, alguns bugs podem ser corrigidos e os preparativos podem ser feitos para realmente lançar uma nova versão de seu produto para seus clientes. Isso não quer dizer que você não pode fazer lançamentos incrementais para o cliente nesse ínterim - é apenas que este é um mecanismo de lançamento controlado, medido e sustentável.
• No final de um release, você pode considerar um sprint de uma semana. Neste sprint, você pode trabalhar com a equipe para analisar algumas novas ideias ou descobrir alguma nova tecnologia. Essas são ótimas ferramentas que beneficiam o negócio e dão à equipe algum espaço de briefing para pensar e ser criativo. Não é para brincar e ainda criará valor. Da mesma forma, todos precisam de uma pausa. Tirar férias neste momento ajuda a manter sua cadência e velocidade em boa forma quando você está no meio da liberação.

Definindo Feito

Definir o que “pronto” realmente significa é muito importante. Existem muitas versões de “pronto” na vida do seu projeto - o que significa ser “feito” com uma história, lançamento ou projeto inteiro. Tudo se resume ao que você, sua equipe e a empresa consideram completo com o nível certo de qualidade para satisfazer a prontidão para envio.

Para a sua equipe, a definição de uma história “pronta” será algo como todo o código completo, revisado por pares, atende aos critérios de aceitação definidos, testado por unidade, UAT e enviado para seu repositório de código. Para permitir a passagem de uma história do designer para o desenvolvedor e para o testador, as definições de “pronto” terão que ser aceitas pela próxima pessoa na cadeia. O product owner terá expectativas quanto ao que isso significa para eles, a fim de liberar o incremento do produto para seus clientes. Em qualquer caso, todos devem estar cientes do que significa “feito” e ser uma parte responsável em garantir que seu significado seja cumprido. Defina sua definição de “pronto”, comunique-a, concorde com ela e desenvolva-a. Pronto pronto.

Medição Contínua

Se você não pode medir, você não pode gerenciá-lo. O mesmo vale para melhorias. A necessidade de coletar dados empíricos em um projeto Agile é quase tão vital quanto ter sangue fluindo nas veias! Como saber o que precisa ser gerenciado, corrigido ou aprimorado se não houver dados? Bem, simplesmente, você estará contando com a intuição e com suposições infundadas, que se desfazem rapidamente sob exame. E dependendo de quem está fazendo o escrutínio, este pode ser um lugar bastante desconfortável para se estar. Portanto, desde o início do seu projeto, certifique-se de saber como irá demonstrar o progresso e por quais medidas os outros verão o seu sucesso.

Felizmente, o Agile vem carregado com ferramentas e técnicas úteis. A primeira coisa a fazer é voltar ao Manifesto Ágil, digitar as seguintes palavras em seu processador de texto favorito, ampliá-las para 96pt, imprimir e aplicar na parede para que todos vejam:

O software funcional é a principal medida de progresso Tweet

Seu maior poder demonstrável no fornecimento de software é mostrá-lo às pessoas que trabalham, fazem o que deve fazer. Isso não apenas deixará seus clientes satisfeitos, mas também conquistará muito respeito para sua equipe e tornará mais fácil sua adoção por meio do negócio.

Aqui estão algumas outras ferramentas:

• o standup diário : Existem algumas variações desta cerimônia, mas a essência é fazer com que todos os membros da equipe conversem cara a cara: seja breve, focado e leve. Se alguma coisa precisar de uma discussão longa, pare para uma conversa mais longa entre as pessoas necessárias após a trocação. Se houver obstáculos, escreva-os como uma história, adicione-os ao seu backlog e faça com que sejam resolvidos o mais rápido possível. Qualquer coisa que esteja impedindo sua equipe retarda seu progresso e será demonstrável em velocidade reduzida e software que não atende às expectativas.
• Velocidade : É uma ferramenta histórica. É um pouco como aqueles avisos financeiros que você recebe que dizem que o desempenho passado não é garantia de desempenho futuro. Mas, no caso do Agile, esperamos alcançar uma velocidade de equipe que seja bastante suave. É a velocidade que nos permite projetar o desempenho futuro e a confiança em nossos planos. Pode haver influências fora do seu controle que podem diminuir o número de resultados de story points para um determinado sprint. Se isso acontecer, você provavelmente conseguirá se recuperar. Nunca use a velocidade como uma vara para vencer seu time; não vai ganhar nenhum favor para você. Uma coisa certa é que a velocidade será irregular nos primeiros 2–4 sprints. Em algum ponto desse período, porém, você deve começar a ver consistência e estabilidade. Se sua velocidade está oscilando de um extremo a outro, você tem um problema que precisa resolver com sua equipe.
• O gráfico de burndown: Essa medida de progresso é espinhosa. Por esse motivo, não forneci um link para descobrir mais - você terá que fazer sua própria pesquisa e concordar como equipe e empresa que trabalha para você. O motivo de ser espinhoso? Bem, nenhum recurso por aí conta a mesma história! Algo combinado é que ele mostrará, em um sprint ou lançamento, como você está se saindo em relação ao seu timebox. Se mantido diariamente, ele mostrará se você está no caminho certo ou se desviando. Algumas equipes o usam para representar quanto valor resta a ser criado, na maioria das vezes, outras o usam para mostrar quanto trabalho resta a ser concluído. O primeiro é uma celebração do sucesso e da geração de valor, o último é menos inspirador e motivador.
• O gráfico de burnup: se você deve mostrar as taxas de conclusão do trabalho, use o gráfico de burndown para isso. Mas usar o gráfico de burnup permite que você mostre quanto valor foi criado e quanto mais valor você está planejando criar até o final do sprint. Uma ferramenta muito mais motivadora para uma equipe demonstrar para a empresa o que foi feito (ou pouco se as coisas não estão indo tão bem ...) e o que eles ainda têm seus olhos postos. Em qualquer caso, use os gráficos para identificar onde o progresso não está acompanhando conforme o esperado e procure padrões ou desvios e comece a corrigir o problema subjacente o mais rápido possível. Atualize-os diariamente para sprints e uma vez no final de um sprint para gráficos de versão de lançamento.
• Quadros de tarefas : Estes são excelentes radiadores visuais para demonstrar o valor que está sendo criado. Quando atualizados diariamente ou a qualquer momento do dia, eles mostram imediatamente o progresso que está sendo feito. Se combinados com Kanban, eles também são ótimas ferramentas para visualizar o fluxo e bloqueios no sistema. Se você pode ver que muito desenvolvimento foi concluído, mas os testes não são tão produtivos, você pode ver o problema acontecendo e responder de forma adequada e rápida.

Outras ferramentas a serem consideradas são Valor agregado ágil , tempo de ciclo e diagramas de fluxo cumulativos (CFD's).

Mantenha essas medidas, gráficos e outras ferramentas visíveis, de preferência em alto e bom som, em uma parede para que todos possam ver. A equipe, as partes interessadas e outras partes interessadas podem ver imediatamente o status de um projeto. É transparente e serve como uma ferramenta de comunicação valiosa. Se você não pode colocar esses artefatos em uma parede, use ferramentas que sejam compartilháveis ​​e colaborativas e certifique-se de que aqueles que desejam acessar as tenham.

Melhoria continua

Ao longo de sua vida Agile, procure identificar e aprender onde melhorias podem ser feitas. As lições não são capturadas e aprendidas no final de um projeto. É como passar no teste de direção e, provisoriamente, fazer sua primeira viagem sem um instrutor. Você saberá o que funciona e o que deve fazer, mas com o tempo você ajustará suas habilidades e capacidades de direção, aprendendo novas técnicas. Você vai até adquirir maus hábitos. Procure-os, compreenda-os e encontre maneiras de melhorar.

Existem muitas oportunidades para identificar o que não funciona e aplicar soluções. A abordagem embutida para isso no Agile é a retrospectiva. Esta é a principal ferramenta para reflexão e ajuste. No final de cada sprint, reserve um tempo com a equipe para melhorar como o trabalho é feito, como a qualidade é entregue, como a eficiência pode ser maximizada, como o desperdício pode ser minimizado e como a capacidade é aumentada. Ao identificar medidas de melhoria, não fique tentado a resolver todos os seus problemas imediatamente. Identifique aqueles que terão mais impacto e podem ser implementados no próximo sprint. Meça e observe. Se teve o impacto desejado, bloqueie-o, escreva-o em suas formas de trabalho e definições de feito. Se não funcionar, pense novamente. Todas as lições aprendidas que não forem colocadas no próximo sprint podem ser estacionadas e priorizadas para receber atenção no próximo sprint.

Personalize o processo. Remova tudo o que não funciona. Remova os impedimentos. Sua maturidade como equipe ágil não conhecerá limites se você permitir.

Além do gerenciamento ágil de projetos

É importante saber o que acontece depois que o projeto é entregue. Suporte e manutenção são essenciais para garantir que, uma vez que o projeto esteja nas mãos dos clientes, ele permaneça com bom desempenho; o feedback do cliente pode ser fatorado em versões futuras; e os problemas dos clientes são tratados de forma adequada. Um projeto é um esforço único e limitado pelo tempo. O produto que ele entrega vive depois que a equipe do projeto é desfeita. Certifique-se de que você é capaz de suportar o produto quando ele estiver ativo.

Projetos ágeis coexistem com abordagens mais tradicionais. Equilibrar os requisitos de controle orçamentário e visibilidade das partes interessadas com os objetivos do Agile de flexibilidade e capacidade de resposta.

Uma estrutura de governança ou modelo de governança Agile é usado em conjunto com processos Agile padrão, como Scrum. Eles funcionam de duas maneiras específicas:

• Eles fornecem um invólucro para um projeto Agile, esclarecendo os processos que ocorrem fora das iterações de desenvolvimento (sprints). Isso inclui fornecer critérios claros para a conclusão bem-sucedida do início do projeto e validação adequada das decisões e do plano.
• Eles mudam a ênfase de partes específicas do processo Agile padrão e destacam princípios e técnicas particulares que precisam de governança ou de suporte à governança.

No mundo em constante mudança de hoje, organizações e negócios estão ansiosos para adotar uma abordagem mais flexível para entregar projetos e querem se tornar mais ágeis. No entanto, para organizações que entregam projetos e programas, e onde já existem processos formais de gerenciamento de projetos, a informalidade de muitas das abordagens Agile é assustadora e às vezes é percebida como muito arriscada. Essas organizações focadas em projetos precisam de uma abordagem ágil madura - agilidade dentro do conceito de entrega de projetos - Gestão ágil de projetos .

Aprenda e cresça com a adoção do Agile. Sempre faça aquilo com que sua equipe se sentir confortável, certifique-se de que sua voz seja ouvida e atenda às suas solicitações. Incentive sua equipe a adotar técnicas novas e mais valiosas no momento certo. Negocie com a empresa e incentive-os a entender o que significa ser uma organização ágil.

Aproveite a jornada.