Agile Project Management: Nuances & Skills

Metodologias Ageis

Agile Project Management requires some additional skills to be possessed by an Agile Project Manager. It does not only involve managerial skills but also requires more team-oriented and leadership skills. Agile Development is a value-driven model with focus on outcomes unlike traditional approaches which are plan-driven in nature and based on output. At the same time, the centripetal force for success of the agile-based project is the agile team which executes it. It also requires additional skills in terms of adaptability, self-organization and motivation to continuously improve. Agile Transformation is a journey and not a process. It is a cultural, behavioral and mindset shift from bureaucratic to pragmatic empiricism. Agile teams improve through learning, inspection and adaption which help in bringing a consistent delivery cadence in shorter and visible iterative development cycles. Support from the leadership team is a must, and the focus of agile project management should be more on the degree of adaptability instead of predictability. Over a period of time when the team starts delivering with consistent velocity, it helps in increasing the confidence in the achievement of customer goals and defined outcomes.

Airton Senna do Brasil!

Quem me conhece sabe que não acredito em idolatria ao ser humano! Por ser humano, os seres falham… idolatria para mim é para o divino, NUNCA para humanos. Porém algumas pessoas cativaram o meu respeito enquanto pessoa, valores e enquanto profissional. O Airton foi um deles! Eu tenho ele como exemplo de vida: pela dedicação, pela força de vontade, pela retidão de caráter e generosidade! Ele fazia o q amava e se dedicava para aquilo q ele amava! Esse é o segredo da sua essência e o que o tornou incrível: amar o que faz e fazer com excelência! Ele conseguiu juntar o útil ao agradável! Fazendo o q ama e dedicou-se de corpo e alma para isso! A competição era consigo mesmo e nunca com outros. Exemplo de comprometimento, exemplo de sucesso! Toda vez q estou com uma dificuldade que parece impossível de resolver, SEMPRE lembro de vc Airton! Descanse em Paz! Obrigada por tudo! Brasil sil sil! Airton Senna do Brasil !!!

ABORDAGEM DE BPM ÁGIL: COMO INSERIR PRÁTICAS ÁGEIS NO CICLO DE BPM?

No post anterior sobre BPM Ágil, apresentamos os valores, princípios e práticas ágeis. Agora, vamos explorar através de exemplos as diferenças geradas pela introdução da agilidade no ciclo de BPM (Business Process Management).

Em um projeto de gestão de processos de negócio, normalmente são realizadas entrevistas (detalhadas em atas) de levantamento de processos que servem de insumo para a modelagem da cadeia de valor, fluxo de processos e (quando necessário) detalhamento das atividades. Depois que esses modelos são gerados, eles passam pela revisão interna de um membro da equipe de modelagem que pode sugerir ajustes. Após finalizado, o modelo é submetido à validação dos clientes e usuários. Caso sejam necessárias, são realizadas modificações. Dependendo do tamanho do processo e do número de atividades, esse ciclo de revisões, validações e ajustes se torna mais longo. A figura abaixo resume simplificadamente a sobrecarga de documentação e loops de revisões em um projeto de BPM tradicional.

Loops de revisões em um projeto de BPM

Para tornar esse processo mais dinâmico e rápido, algumas práticas ágeis podem ser aproveitadas. Para facilitar esta tarefa, a dheka criou um passo-a-passo sobre como desenvolver um projeto de BPM Ágil ou Lean BPM. Apesar de existirem diversos trabalhos sobre o uso de métodos ágeis no desenvolvimento de software, o uso de métodos ágeis na gestão de processos ainda é algo novo. Existem alguns trabalhos que abordam a inclusão de práticas ágeis nos projetos de BPM (KOLAR e PITNER, 2013; THIEMICH e PUHLMANN, 2013), porém eles não sugerem uma metodologia ou descrevem como realizar essa inclusão.

A abordagem de BPM Ágil ou Lean BPM pode ser resumida primeiramente, pela modelagem do processo que é dividida em pequenas entregas. Nas reuniões são levantados os processos que serão descritos como estórias. As estórias descrevem através de post-its o funcionamento dos processos e atividades e são usadas para o planejamento, priorização e divisão do trabalho.

BPM Ágil

Ao invés de um registro formal através da ata da reunião de levantamento, é proposto que durante a reunião sejam criadas que ajudem à modelagem do processo.

Ficha de Processos

Durante a modelagem de processos, ao invés de lidar com todos os modelos existentes, o cliente pode adaptar/configurar/personalizar a modelagem, de acordo com as suas necessidades e visando a simplicidade. Através do cardápio de processos, é possível selecionar quais modelos/diagramas (diagrama de objetivos, estrutura organizacional, modelo de localização, glossário, cadeia de valor, fluxo de processo e diagrama de detalhamento de atividade) e elementos/objetos (riscos, indicadores, regras de negócio, requisitos de negócio e etc.) serão adotados.

Após esta seleção, um backlog com as tarefas do projeto de BPM é criado. O trabalho de modelagem é planejado e dividido em pequenas entregas (sprints) com duração aproximada de 15 ou 30 dias. De acordo com esta duração, será necessário dividir essas entregas em um ou mais sprints. As tarefas a serem executas são alocadas em seus respectivos sprints. O backlog e os sprints são cadastrados em uma ferramenta, aonde a equipe de modelagem fará o acompanhamento do projeto de BPM.

Além disso, a modelagem de processos seguirá uma padronização através de regras e boas práticas definidas em um documento de diretrizes de modelagem e será realizada em uma ferramenta de modelagem de processos colaborativa, facilitando assim a revisão que poderá ser realizada durante a própria modelagem.

Por fim, podem ser alocados mais de um analista por processo e adotado um rodízio de analistas nos processos. Isto torna a modelagem mais dinâmica, pois os analistas podem discutir as dúvidas que surgem durante a modelagem e apresentar ideias ou soluções de modelagem para alguns problemas de representação não triviais. O rodízio de analistas também ajuda a padronização da modelagem entre os diferentes processos tratados no projeto e a elaboração de modelos com mais qualidade, já que visões diferentes contribuem com sugestões de ajustes e melhorias.

A diferença do BPM Ágil ou Lean BPM para o uso do BPM tradicional

A diferença do BPM Ágil ou Lean BPM para o uso do BPM tradicional é que neste caso são utilizadas técnicas não tradicionais vindas das metodologias ágeis ou lean (Scrum, XP, Kanban) na gestão de processos. Os princípios, valores e práticas ágeis presentes nestas metodologias ágeis foram adaptados e inseridos no ciclo de BPM.BPM Ágil ou Lean BPMpode ser resumida pela figura abaixo. Na figura, a modelagem do processo é dividida em pequenas entregas. Nas reuniões são levantados os processos que serão descritos como estórias. As estórias descrevem através de post-its o funcionamento dos processos e atividades e são usadas para o planejamento, priorização e divisão do trabalho.

Atualmente, os projetos estão cada vez mais dinâmicos e os gestores desejam resultados cada vez mais rápidos. Com isso, a Gestão de Processos de Negócio (BPM) começa a ser revista para entregar prontamente resultados e produtos. Como solução para este problema, veio a ideia de adaptar as praticais ágeis do desenvolvimento de software para a gestão de processos, tornando-a mais dinâmica e iterativa, propiciando entregas mais rápidas e com isso uma maior satisfação dos clientes.

Colocar o fluxo de volta ao fluxo de trabalho com limites de WIP

Os limites do trabalho em andamento não devem limitar seu progresso. Muito pelo contrário.

O que são limites de WIP?

Em desenvolvimento ágil, os limites de trabalho em andamento (WIP) definem a quantidade máxima de trabalho que pode existir em cada status de um fluxo de trabalho. Limitar a quantidade de trabalho em andamento facilita a identificação da ineficiência no fluxo de trabalho de uma equipe. Obstáculos no pipeline de entrega de uma equipe são claramente visíveis antes de uma situação se tornar extrema.

Por que os limites de WIP são importantes?

Então agora você está pensando: “Fale mais!” (bem, espero que esteja.)

Os limites de WIP melhoram a produtividade e reduzem a quantidade de trabalho “quase feito”, forçando a equipe a se concentrar em um conjunto menor de tarefas. Em um nível fundamental, os limites de WIP incentivam uma cultura de “concluído”. E, o mais importante, os limites de WIP tornam os bloqueadores e os obstáculos visíveis. As equipes podem analisar problemas de bloqueio para que eles sejam entendidos, implementados e resolvidos quando há um claro indicador de qual trabalho existente está causando um obstáculo. Uma vez que os bloqueios são removidos, o trabalho da equipe começa a fluir novamente. Estes benefícios garantem que incrementos de valor sejam entregues aos clientes mais rapidamente, tornando os limites de WIP uma ferramenta importante no desenvolvimento ágil.

Além disso, executar múltiplas tarefas é muito demorado.

Durante o desenvolvimento, é comum pensar: “Farei uma pausa em relação a esse problema enquanto começo a trabalhar em outro”. Ter dois problemas em aberto significa alternar de contexto entre duas coisas diferentes ou transferir trabalho entre colegas de equipe. Ir de um problema para o outro não é fácil – leva tempo e diminui o foco. Quase sempre é melhor trabalhar no problema original do que começar – e não concluir – um novo trabalho. Ou seja, os limites de WIP nos desencorajam a obstruir nosso próprio fluxo.

Finalmente, os limites de WIP mostram as áreas com ociosidade crônica ou sobrecarga. Eles ajudam a equipe a ver as ineficiências no processo todo em vez de apenas em uma área específica de trabalho.

PRO TIP:

Pode parecer estranho para equipes novas no uso dos limites de WIP. Reserve um tempo para discussão nas primeiras iterações. Entenda como e o motivo pelo qual a equipe atinge os limites de WIP. Resista à tentação de fazer ajustes arbitrários. Se uma violação se tornar consistente, é um sinal de que o limite de WIP é muito restritivo ou que o processo da equipe é ineficiente.

Uso dos limites de WIP em equipes ágeis

Agora que você sabe sobre o valor desses limites, vamos ao que interessa.

Ao lançar um novo fluxo de trabalho, tome uma decisão em equipe para determinar os limites de WIP para cada status. Recomendamos definir os limites de WIP após monitorar o número médio de itens de trabalho em cada status para alguns sprints. Abaixo é possível ver um quadro ágil de exemplo com os limites de WIP usados por uma equipe de desenvolvimento de software comum.

Acima, um limite de WIP foi definido na revisão de código. Como a coluna está excedendo seu limite, o histórico ficou vermelho.

Como não resta nada a fazer quando um problema é concluído, não há necessidade de um limite de WIP. No quadro acima, “Pronto para desenv.” significa que a história foi totalmente analisada pelo proprietário do produto e pela equipe. A equipe de desenvolvimento passa o trabalho de “pronto para desenv.” para “em andamento” à medida que começam a trabalhar nos itens. Como melhor prática, é importante manter trabalho suficiente no status “pronto para desenv.” para que cada membro da equipe de desenvolvimento permaneça trabalhando. Ao manter apenas histórias suficientes no estado “pronto para desenv.”, o proprietário do produto não fica muito à frente quando se trata de detalhar os requisitos e o programa se torna mais responsivo para alteração.

O status “em andamento” lista o trabalho que está sob desenvolvimento ativo. A meta dos limites de WIP nesse caso é garantir que todos tenham trabalho para fazer, mas ninguém esteja fazendo múltiplas tarefas. No quadro cima, o limite para os itens “em andamento” é quatro e há, no momento, três itens nesse estado. Isso mostra à equipe que eles conseguem assumir mais um trabalho. Como melhor prática, algumas equipes definem o limite de WIP máximo abaixo do número de membros da equipe. A ideia é preparar o espaço para as boas práticas ágeis. Se um desenvolvedor finalizar um item, mas a equipe já estiver no limite de WIP, eles saberão que é a hora de resolver algumas revisões de código ou chamar outro desenvolvedor para ajudar na programação.

O status “revisão de código” indica as histórias que foram totalmente escritas, mas precisam de revisão antes de serem mescladas na base de código. As revisões oportunas de código são uma melhor prática que estabelece qualidade, levam as inovações mais rapidamente ao mercado, tornam as mesclagens mais rápidas ao reduzir ramificações abertas e proporcionam conhecimento para toda a equipe de engenharia. É necessário atuar em itens nesse estado urgentemente pelos seguintes motivos:

  • O código não se torna inutilizável à medida que os membros da equipe verificam um novo código
  • O desenvolvedor não perde o contexto ganho ao escrever o código original
  • O recurso pode ser mesclado na ramificação principal para liberação

Os limites de WIP garantem que o código não revisado não se acumule.

Observe que, no quadro ágil acima, a equipe tem muitas revisões de código, então a coluna ficou em vermelho para indicar isso.

ANTIPADRÕES QUE DEVEM SER OBSERVADOS:

  • Os limites de WIP são usados conforme a necessidade para que a equipe não encontre mais problemas. (“Teto de dívida”, alguém?)
  • Todos têm muitas “tarefas secundárias” nas quais trabalhar quando estão ociosos.
  • Os membros da equipe ficam à espera de mais trabalho em vez de se prenderem aos obstáculos.
  • Adicionar mais horas pessoais em obstáculos persistentes é melhor do que melhorias nas práticas de engenharia ou nos processos da equipe.

Quatro metas paras as equipes ágeis que usam limites de WIP

Como em qualquer outra atividade, os limites de WIP podem parecer estranhos no começo. O objetivo aqui é otimizar a equipe a médio prazo, e a estranheza a curto prazo é realmente algo bom. Faz com que a equipe perceba alguns pontos problemáticos no processo. Após a equipe usar os limites de WIP por algumas semanas, será necessário fazer ajustes. Resista à tentação de criar um limite de WIP apenas porque a equipe está sempre passando por ele. Aproveite essa oportunidade para aumentar a capacidade – idealmente, ao treinar a equipe e fornecer a cada membro novos conjuntos de habilidades ou tornando alguns aspectos do processo de desenvolvimento mais eficientes.

Meta 1: dimensionar as tarefas individuais consistentemente. Ao dividir requisitos e histórias de usuário, é importante manter as tarefas individuais com não mais do que 16 horas de trabalho. Fazer isso aumenta a capacidade da equipe de estimar com confiança e ajuda a evitar obstáculos. Nada reduz uma equipe e agrava os limites de WIP como um grande item de trabalho obstruindo o pipeline.

PRO TIP:

Quando o trabalho nos limites em andamento está funcionando para a equipe, o tempo de ciclo de um problema cairá. O tempo de ciclo é a quantidade de tempo que leva para concluir um problema.

Meta 2: mapear os limites de WIP de acordo com as habilidades da equipe. O exemplo acima assume que os membros da equipe têm conjuntos de habilidades similares. Se sua equipe tem especialistas , o trabalho em limites em andamento pode ser diferente. Crie um status específico para o trabalho do especialista. Se houver obstáculos nesse status, use a oportunidade para mostrar aos outros membros da equipe como adicionar capacidade extra ao conjuntos de habilidades do especialista e aumentar o fluxo em toda a equipe.

Meta 3: reduzir a ociosidade. Quando alguém da equipe tiver tempo livre, encoraje-o a ajudar nas atividades da equipe. Essa pessoa contribuirá para a produtividade geral da equipe e aprenderá algo.

Meta 4: proteger uma cultura de engenharia sustentável. Trabalhar em limites em andamento não significa que os desenvolvedores precisam apressar o trabalho para evitar sobrecarga em um status específico. Eles devem dar suporte a práticas sólidas de engenharia ágil que protejam a qualidade do produto e a integridade da base de código.

Epics ágeis: definição, exemplos e modelos

Epics, histórias, temas e iniciativas

Essas estruturas simples ajudam as equipes ágeis a gerenciar, facilmente, o escopo e a estruturar o trabalho.

Digamos que você e sua equipe querem fazer algo ambicioso, como lançar um foguete no espaço. Para fazer isso, será necessário estruturar seu trabalho: dos maiores objetivos até os mais detalhados. Você desejará responder à mudança, reportar seu progresso e seguir um plano. Epics, histórias, temas e iniciativas são, precisamente, as ferramentas que você precisará para fazer isso.

Ao entender como essas metodologias ágeis populares ajudam a organizar o trabalho, sua equipe pode obter um equilíbrio entre estrutura, flexibilidade e lançamento de foguetes no espaço.

O que são histórias, epics, iniciativas e temas?

  • Histórias, também chamadas de “histórias de usuários”, são requisitos pequenos ou solicitações escritas da perspectiva de um usuário final.
  • Epics são grandes partes de trabalho que podem ser divididas em várias tarefas menores (chamadas histórias).
  • Iniciativas são coleções de epics que têm um objetivo comum.
  • Temas são grandes áreas de foco que abrangem a organização.

Epic ágil versus história

De certo modo, histórias e epics, no método ágil, são semelhantes a histórias e epics em filmes e livros. Uma história é uma narrativa simples, uma série de histórias interdependentes e relacionadas que compõem um epic (épico). O mesmo é verdadeiro para seu gerenciamento de trabalho, no qual a conclusão de histórias relacionadas leva à conclusão de um epic. As histórias contam o arco de trabalho completo, enquanto os epics compartilham uma visão de alto nível do objetivo unificador.

Em uma equipe ágil, as histórias são algo que a equipe pode se comprometer a finalizar em um sprint de uma ou duas semanas. Muitas vezes, os desenvolvedores trabalham em várias histórias por mês. Os epics, em contrapartida, são poucos e demoram mais para serem concluídos. Normalmente, as equipes trabalham em dois ou três epics por trimestre.

Se sua empresa está lançando foguetes no espaço e deseja aprimorar o serviço de streaming para seus lançamentos, é necessário estruturar suas histórias como as histórias abaixo.

Exemplos de uma história ágil:

  • Os usuários de iPhone precisam acessar uma visão vertical do feed ativo ao usar o aplicativo móvel.
  • Os usuários de desktop precisam de um botão de “visualizar em tela cheia” na extremidade direita inferior do player de vídeo.
  • Os usuários do Android devem ser vinculados à Apple Store.

Saiba como configurar histórias (chamadas de “problemas”) no Jira Software

As histórias acima estão relacionadas. Todas podem ser consideradas tarefas individuais que levam à conclusão de uma parte maior do trabalho (um epic). Nesse caso, o epic pode ser “Melhorar o serviço de streaming para lançamento no primeiro trimestre”.

Organizar o trabalho em histórias e epics também ajuda você e sua equipe a se comunicarem efetivamente na organização. Se estava reportando o progresso de sua equipe ao chefe de engenharia, estava falando em epics. Se estava falando com um colega na sua equipe de desenvolvimento, estava falando no nível da história.

Epic ágil versus iniciativa

Do mesmo modo que os epics são compostos de histórias, as iniciativas são compostas de epics. As iniciativas oferecem outro nível de organização, acima dos epics. Em muitos casos, uma iniciativa compila epics de várias equipes para obter um objetivo maior e mais amplo do que qualquer um dos epics. Enquanto um epic é algo que você deve concluir em um mês ou trimestre, as iniciativas, normalmente, são concluídas em vários trimestres ou um ano.

Exemplo de epics em uma iniciativa:

Digamos que sua empresa de foguetes queira diminuir o custo por lançamento em 5% nesse ano. É uma ótima adequação para uma iniciativa, pois um epic sozinho provavelmente não alcançaria essa meta. Nessa iniciativa, haveria epics como “Diminuir o consumo de combustível na fase de lançamento em 1%”, “Aumentar os lançamentos por trimestre de 3 para 4” e “Diminuir os termostatos de 71 a 69 graus #Dadmode”.

Na Atlassian:

Internamente, chamamos nossas iniciativas de “tíquetes de PC”. Os tíquetes centrais do projeto são configurados no Jira Software assim como nossos epics. Cada equipe pega seu foco ou cinco metas mais importantes por ano e faz tíquetes de PC para cada uma. Esses tíquetes de PC são usados pelos fundadores e pelo gerenciamento para entender todo o trabalho que está sendo feito na empresa.

Iniciativas versus temas

Em muitas organizações, os fundadores e a equipe de gerenciamento encorajarão a busca por um destino de aspiração. Essas são as metas (às vezes muito antiquadas) anunciadas a cada ano ou trimestre, e os temas são como isso é monitorado.

  • Iniciativas são coleções de epics
  • Os temas são rótulos que monitoram as metas organizacionais de alto nível

As iniciativas têm um design estrutural. Elas abrigam os epics, e a conclusão desses epics ocasionará a conclusão da iniciativa. Os temas são uma ferramenta organizacional que permite que você rotule os itens da lista de pendências, os epics e as iniciativas para entender quais trabalhos contribuem com quais metas organizacionais. Os temas devem inspirar a criação de epics e iniciativas, mas não tenha um relacionamento rígido de “um para um” com eles. Um tema para uma empresa de lançamento de foguetes deve ser algo como “Segurança em primeiro lugar”.

É assim que os temas podem ser vistos no Portfolio for Jira:

Na Atlassian:

Um de nossos temas essa ano é “Trabalho aberto”. Ele incentiva mais transparência, dentro e fora da empresa. Minha equipe está trabalhando nesse ema ao fazer uma retrospectiva pública no método ágil. Estamos solicitando que os desenvolvedores de software reflitam sobre sua experiência de desenvolvimento ágil e tweetem seus feedbacks com #RetroOnAgile. Como uma campanha de três meses, criamos um epic para isso e rotulamos esse epic com o tema “Trabalho aberto”.

Estruturar seu trabalho:

Usar o método ágil e a estrutura não é algo mutuamente exclusivo, e a estrutura disposta aqui não é adequada para todos os usos. Êxito é quando você e sua equipe entendem esses conceitos e os adaptam a suas necessidades. Para nós, são histórias, epics, iniciativas e temas. Você pode começar aprendendo como configurar os epics no Jira Software.

Uso de fluxos de trabalho para diversão e lucro

Todos odeiam processos, mas, sem um fluxo de trabalho estabelecido, você vai rapidamente para lugar nenhum.

Toda equipe de software tem um processo que é usado para concluir o trabalho. Normalizar esse processo–por exemplo, estabelecê-lo como um fluxo de trabalho–torna-o mais claramente estruturado e repetível, o que, em troca, faz dele escalável. Na Atlassian, usamos uma abordagem iterativa com o gerenciamento de fluxo de trabalho, pois isso nos ajuda a atender nossas metas mais rapidamente e exemplifica a cultura da nossa equipe. Somos especialistas no gerenciamento de fluxo de trabalho ágil (se podemos dizer isso de nós mesmos) e queremos ajudar você a se tornar especialista também.

Comece simples, comece agora

Ao implementar um fluxo de trabalho para a equipe, sempre comece simples. Lute contra a tentação de passar semanas pensando demais na engenharia. Fluxos de trabalho excessivamente complexos são difíceis de entender e adotar – sem mencionar a adaptação. Para equipes de software, recomendamos esses estados básicos do fluxo de trabalho:

PARA FAZER

Work that has not been started

EM ANDAMENTO

Trabalho que está sendo ativamente feito pela equipe.

REVISÃO DE CÓDIGO

Trabalho que está concluído, mas está esperando revisão.

DONE

Trabalho que está completamente concluído e atende a definição de pronto de equipe.

Em um rastreador de problemas, esses status passam de um para o outro usando transições que estruturam o fluxo de trabalho.

Algumas equipes de software incluem estados adicionais no fluxo de trabalho que ajudam a monitorar o status do trabalho de modo mais preciso.

AGUARDANDO GQ

Work that has been implemented, but is still waiting for a tester review (see our article on agile testing for more details).

PRONTO PARA MESCLAR

O código que foi revisado e está pronto para ser mesclado no código principal ou na ramificação de liberação.

Os diversos estados do fluxo de trabalho não precisam ser tratados cada um por uma pessoa diferente. À medida que uma equipe ágil amadurece, os desenvolvedores lidam com mais e mais trabalho – desde o design até a entrega. Afinal, uma equipe autônoma que pode lidar com trabalhos heterogêneos é uma das características da agilidade.

Bons fluxos de trabalho se adaptam às necessidades da equipe. Problemas ocasionais é normal. Mas problemas crônicos não são.

Fale sobre cada dificuldade durante a retrospectiva da equipe. Lembre-se que cada equipe terá valores um pouco diferentes com base no projeto, pilha de tecnologia e método de trabalho. É por isso que é importante escolher um rastreador de problema que tenha uma configuração flexível de fluxo de trabalho. Equipes em excesso comprometem o estilo de trabalho para adequação a um determinado conjunto de ferramentas, o que é frustrante para todos. Então, os membros da equipe começam a evitar o uso da ferramenta, ocasionando frustração na equipe e, geralmente, causando problemas. E, se a motivação diminui, a produtividade reduz. É um golpe duplo que queremos evitar!

As equipes novas no método ágil ou que não têm habilidades multifuncionais normalmente acabam com “pequenas cascatas” em seu fluxo de trabalho. Por exemplo, o departamento de design começa um item de trabalho com um modelo. A equipe de desenvolvimento faz a implementação. O teste confirma a qualidade. Cada estado fica bloqueado até o estado anterior ser concluído. Soa familiar? Isso é cascata. Mas podemos fazer melhor com fluxos de trabalho ágeis para liberar a equipe e facilitar o desenvolvimento.

Otimizar o fluxo de trabalho

Quando estiver confortável com o fluxo de trabalho básico e estiver pronto para personalizá-lo, crie status para cada tipo de trabalho em um processo da equipe. Criação de ideias, design, desenvolvimento, revisão de código e teste são funcionalmente diferentes e podem ter status individuais. Use um conjunto enxuto de status que comunique claramente em qual fase uma parte do trabalho está.

Os status do projeto também podem ser compartilhados com o restante da organização. Ao criar um fluxo de trabalho, pense sobre quais métricas são importantes para relatórios e o que os membros fora da equipe podem estar interessados em aprender. Por exemplo, um fluxo de trabalho bem projetado responde as seguintes perguntas:

  • Que tipo de trabalho a equipe concluiu?
  • A lista de pendências de trabalho está aumentando ou está no mesmo ritmo que a equipe?
  • Quantos itens estão em cada status?
  • Há obstáculos que estão diminuindo a velocidade da equipe?
  • Quanto tempo leva para conclusão de uma tarefa média?
  • Quantos itens de trabalho não foram aprovados em nossos padrões de qualidade na primeira vez?

A próxima etapa na otimização do fluxo de trabalho é garantir um fluxo de trabalho constante em todo o fluxo de trabalho. Os limites de trabalho em andamento (WIP) estabelecem os números mínimo e máximo de problemas em um estado específico do fluxo de trabalho, garantindo que cada estado no fluxo de trabalho tenha trabalho suficiente para manter a equipe totalmente utilizada, mas não tanto que possa fazer com que todos percam o foco ao fazer malabarismos com as prioridades. Impor limites em andamento mostrará rapidamente quais processos na equipe estão diminuindo o trabalho geral pelo pipeline. À medida que a equipe aprende a otimizar os limites do trabalho em andamento, o rendimento aumenta. (Consulte o artigo em Limites de WIP para mais detalhes.)

Os desafios do dimensionamento de um fluxo de trabalho

As organizações com várias equipes ágeis enfrentam desafios especiais com os fluxos de trabalho. Normalmente, as equipes querem otimizar o fluxo de trabalho para refletir sua cultura ou processo exclusivo. Perfeitamente compreensível. Mas podem surgir problemas quando várias equipes, que trabalham no mesmo projeto, usam processos diferentes.

Agile teams that work together can benefit from sharing the same workflow. Using the same workflow can make transitioning work between agile teams easier, because they use the same conventions for defining and delivering work. Creating a common process usually involves some give and take from both teams. That’s good! They’ll learn from one another and come out with a better workflow in the end.

DICA PROFISSIONAL

Com o Jira Software, o rastreador de problemas da Atlassian, as equipes podem compartilhar fluxos de trabalho, mas têm diferentes representações do processo no quadro ágil. Essa capacidade proporciona opções de visualização flexíveis sem sacrificar o ativo compartilhado do fluxo de trabalho.

Não importa como o seu fluxo de trabalho é, o processo de desenvolvimento dele também deve ser ágil. Converse sobre isso durante as retrospectivas e faça uma adaptação de acordo com a cultura da equipe e as alterações na composição.

kanban

Como a metodologia Kanban é aplicada ao desenvolvimento de software

O que é o Kanban?

O Kanban é uma estrutura popular usada para implementar o desenvolvimento ágil de software. Ele precisa de uma comunicação de capacidade em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro do kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento.

Kanban is enormously prominent among today’s agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or “kanban”, between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same “just in time” (or JIT) manufacturing process is still at the heart of it.

Kanban para equipes de software

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team’s capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Embora os princípios centrais da estrutura sejam atemporais e aplicáveis a quase todas as indústrias, as equipes de desenvolvimento de software encontraram um sucesso especial com a prática ágil. Isso ocorre, em parte, porque as equipes de software podem começar a praticar com pouca ou nenhuma sobrecarga, uma vez que entendem os princípios básicos. Ao contrário da implementação do Kanban no chão de fábrica, que envolveria mudanças nos processos físicos e a adição de materiais substanciais, as únicas coisas físicas que as equipes de software precisam são um quadro e cartões, que podem até mesmo ser virtuais.

Quadros do Kanban

O trabalho de todas as equipes Kanban gira em torno de um quadro do Kanban, uma ferramenta usada para visualizar o trabalho e otimizar o fluxo do trabalho entre a equipe. Embora os quadros físicos sejam populares entre algumas equipes, os quadros virtuais são um recurso crucial em qualquer ferramenta de desenvolvimento ágil de software para sua rastreabilidade, colaboração mais fácil e acessibilidade de vários locais.

Independentemente de o quadro de uma equipe ser físico ou digital, sua função é assegurar que o trabalho da equipe seja visualizado, que seu fluxo de trabalho seja padronizado e que todos os bloqueadores e dependências sejam imediatamente identificados e resolvidos. Um quadro básico do Kanban tem um fluxo de trabalho de três etapas: “To Do”, “In Progress” e “Done” (a fazer, em andamento e feito). No entanto, dependendo do tamanho, da estrutura e dos objetivos da equipe, o fluxo de trabalho pode ser mapeado para atender ao processo exclusivo de qualquer equipe específica.

A metodologia Kanban se baseia na plena transparência do trabalho e na comunicação em tempo real da capacidade, portanto, o quadro do Kanban deve ser visto como a única fonte de verdade para o trabalho da equipe.

Cartões Kanban

Em japonês, kanban é traduzido literalmente como “sinal visual.” Para as equipes Kanban, cada item de trabalho é representado como um cartão separado no quadro.

A principal finalidade de representar o trabalho como um cartão no quadro do Kanban é permitir que os membros da equipe acompanhem seu andamento por meio do fluxo de trabalho e de uma maneira altamente visual. Os cartões Kanban apresentam informações cruciais sobre determinado item de trabalho, dando visibilidade total à equipe sobre quem é o responsável por ele, uma breve descrição da tarefa sendo feita, qual a estimativa de tempo para essa parte do trabalho e assim por diante. Muitas vezes, os cartões nos quadros virtuais do Kanban também apresentarão capturas de tela e outros detalhes técnicos valiosos para o destinatário. Ao permitir que os membros da equipe visualizem não só a situação de cada item de trabalho a qualquer momento, mas também todos os detalhes associados, garante-se maior foco, total rastreabilidade e identificação rápida de bloqueadores e dependências.

The benefits of Kanban

O Kanban é uma das metodologias de desenvolvimento de software mais populares adotadas por equipes ágeis atualmente. Ele oferece várias vantagens adicionais para o planejamento e a transferência de tarefas para equipes de todos os tamanhos.

Flexibilidade de planejamento

A kanban team is only focused on the work that’s actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don’t impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there’s no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6’s estimate may be based on the completion of user stories 1-5. It’s always a good practice to confirm changes with the engineering team to ensure there are no surprises.

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

A sobreposição de conjuntos de habilidades leva a tempos de ciclo menores. Quando apenas uma pessoa detém um conjunto de habilidades, ela se torna um gargalo no fluxo de trabalho. Dessa forma, as equipes empregam as melhores práticas básicas, como revisão de código e ajuda em mentoria, para disseminar o conhecimento. Habilidades compartilhadas significam que os membros da equipe podem assumir um trabalho heterogêneo, o que otimiza ainda mais o tempo de ciclo. Isso também significa que, se houver um backup do trabalho, toda a equipe pode se mover para que o processo flua perfeitamente outra vez. Por exemplo, o teste não é feito apenas por engenheiros de controle de qualidade. Os desenvolvedores também o fazem.

Em uma estrutura Kanban, é responsabilidade de toda a equipe assegurar que o trabalho esteja avançando perfeitamente pelo processo.

Menos gargalos

Multitarefa mata eficiência. Quanto mais itens de trabalho em movimento, em um determinado momento, mais troca de contexto, o que dificulta o caminho para a conclusão. É por isso que um usuário-chave do Kanban serve para limitar a quantidade de trabalho em andamento (WIP, work in progress). O trabalho em andamento limita gargalos e backups em destaques no processo da equipe devido à falta de foco, pessoas ou conjunto de habilidades.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there’s good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else’s work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

Métricas visuais

Um dos valores centrais é um foco robusto na melhoria continua da eficiência e eficácia da equipe com cada iteração do trabalho. Os gráficos fornecem um mecanismo visual para as equipes garantirem a continuidade da melhoria. Quando a equipe pode ver os dados, é mais fácil detectar os gargalos no processo e removê-los. Dois relatórios comuns usados pelas equipes Kanban são os de gráficos de controle e os de diagramas de fluxo cumulativos.

Um gráfico de controle mostra o tempo de ciclo para cada problema, bem como uma média contínua para a equipe.

PRO TIP:

The team’s goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success.

Um diagrama de fluxo cumulativo mostra o número de problemas em cada estado. A equipe pode facilmente detectar bloqueios, visualizando o número de aumento de problemas em um determinado estado. Problemas em estados intermediários como “In Progress” (em progresso) ou “In Review” (em revisão) ainda não foram enviados aos clientes, e um bloqueio nesses estados pode aumentar a probabilidade de conflitos de integração em massa quando o trabalho é incorporado a montante.

Serviço constante

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it’s time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum vs. Kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another.

 SCRUMKANBAN
RitmoSprints regulares com extensão fixa (2 semanas)Fluxo contínuo
Metodologia da versãoNo final de cada sprint, se aprovado pelo proprietário do produtoEntrega contínua ou a critério da equipe
FunçõesProprietário do produto, mestre scrum, equipe de desenvolvimentoSem funções existentes. Algumas equipes recorrerem à ajuda de um agile coach.
Principais métricasVelocidadeTempo de ciclo
Filosofia de mudançaAs equipes devem se esforçar para não fazer alterações na previsão de sprint durante o sprint. Ao fazer isso, o aprendizado em torno da estimativa fica comprometido.Mudanças podem ocorrer a qualquer momento

Algumas equipes misturaram os ideais do Kanban e scrum para o “scrumban.” Eles tomam os sprints de extensão fixa e as funções a partir do scrum, e o foco nos limites de trabalho em progresso e tempo de ciclo a partir do Kanban. Porém, para as equipes que acabaram de começar com o agile, é altamente recomendável escolher uma metodologia ou outra e usá-la por um tempo. Você sempre pode iniciar aquela que for ideal mais tarde.

Cinco métricas ágeis que você não odiará

Estatísticas e gráficos são ferramentas importantes. Use-os para executar um bom trabalho.

Métricas são um assunto delicado.

De um lado, todos já tivemos um projeto no qual não havia nenhum tipo de dado monitorado, e era difícil dizer se estávamos no caminho certo para a liberação ou ficando mais eficientes à medida que avançávamos. Por outro lado, muitos já tiveram a infelicidade de trabalhar em um projeto cujas estatísticas foram usadas como uma estratégia, colocando uma equipe contra a outra ou justificando a necessidade de trabalhar durante o fim de semana. Então não é surpresa que a maioria das equipes tem uma relação de amor e ódio com as métricas.

Mas não precisa ser assim. Acompanhar e compartilhar métricas ágeis pode reduzir a confusão e mostrar o progresso da equipe (e retrocessos) durante todo o ciclo de desenvolvimento. Veja como.

Conhecer o seu negócio

“Concluído” conta apenas metade da história. É sobre criar o produto certo, no momento correto, para o mercado certo. Permanecer no controle durante todo o programa significa coletar e analisar dados ao longo do caminho. Em qualquer programa ágil, é importante monitorar as métricas de negócios e as métricas ágeis. As métricas de negócios têm como foco se a solução está atendendo as necessidades do mercado, e as métricas ágeis mensuram os aspectos do processo de desenvolvimento.

As métricas de negócio de um programa devem estar enraizadas no seu roteiro.

Para cada iniciativa no roteiro, inclua vários indicadores-chave de desempenho (KPIs) que fazem o mapeamento até as metas do programa. Além disso, inclua critérios de êxito para cada requisito do produto, como taxa de adoção dos usuários finais ou porcentagem do código coberta pelos testes automatizados. Esses critérios de êxito alimentam as métricas ágeis do programa. E quanto mais as equipes aprendem, melhor elas conseguem se adaptar e evoluir.

Como usar métricas ágeis para otimizar sua entrega

The agile metrics discussed below focus on the delivery of software. Whether you are a scrum or kanban team, each of these agile metrics will help the team better understand their development process, making releasing software easier.

Sprint burndown

Equipes scrum organizam o desenvolvimento em sprints com intervalos de tempo. Desde o início do sprint, a equipe prevê quanto trabalho pode fazer durante um sprint. O relatório de burndown então monitora a conclusão do trabalho durante todo o sprint. O eixo x representa o tempo e o eixo y refere-se à quantidade de trabalho ainda não concluída, medida em pontos de história ou horas. O objetivo é ter todo o trabalho previsto concluído até o final do sprint.

Uma equipe que atende consistentemente sua previsão é uma propaganda convincente para agilidade em sua organização. Mas não deixe isso tentá-lo a contornar os números declarando um item como completo antes que esteja. Pode parecer bom no curto prazo, mas, a longo prazo, isso só dificulta a aprendizagem e a melhoria.

ANTIPADRÕES QUE DEVEM SER OBSERVADOS

  • A equipe finaliza, antecipadamente, sprint após sprint porque ela está se comprometendo a fazer muito trabalho.
  • A equipe perde sua previsão de sprint após sprint porque está se comprometendo a fazer muito trabalho.
  • A linha de burndown mostra quedas bruscas em vez de um burndown mais gradual porque o trabalho não foi dividido em partes menores.
  • O proprietário do produto adiciona ou altera o sprint intermediário do escopo.

Burndown de liberação e epic

Os gráficos de burndown de epic e liberação (ou versão) monitoram o progresso de desenvolvimento de uma grande parte do trabalho do que em relação ao burndown de sprint, e orientam o desenvolvimento de equipes scrum e kanban. Como um sprint (para equipes scrum) pode conter trabalho de vários epics e versões, é importante monitorar o progresso de sprints individuais, bem como epics e versões.

“Deslizamento de escopo” é a inserção de mais requisitos em um projeto definido anteriormente. Por exemplo, se a equipe está entregando um novo site para a empresa, o deslizamento de escopo seria solicitar novos recursos após os requisitos iniciais serem esboçados. Embora não seja uma boa prática tolerar o deslizamento de escopo durante um sprint, a alteração do escopo em epics e versões é uma consequência natural do desenvolvimento ágil. À medida que a equipe passa pelo projeto, o proprietário do produto pode decidir assumir ou remover o trabalho com base no que estão planejando. Os gráficos de burndown de epic e liberação mantêm todos conscientes sobre o que está acontecendo e o fluxo de trabalho dentro do epic e da versão.

ANTIPADRÕES QUE DEVEM SER OBSERVADOS

  • Previsões de liberação ou epic não são atualizadas à medida que a equipe trabalha.
  • Nenhum progresso é feito ao longo de várias iterações.
  • O deslizamento de escopo crônico, que pode ser um sinal de que o proprietário do produto não entende completamente o problema que a parte do trabalho está tentando resolver.
  • O escopo cresce mais rapidamente do que a equipe pode absorvê-lo.
  • A equipe não está enviando liberações adicionais durante o desenvolvimento de um epic.

Velocidade

Velocidade é a quantidade média de trabalho que uma equipe de scrum conclui durante um sprint, medida em horas ou pontos de história, e é muito útil para previsão. O proprietário do produto pode usar velocidade para prever o quão rapidamente uma equipe pode trabalhar em uma lista de pendências, porque o relatório rastreia o trabalho previsto e o concluído ao longo de várias iterações – quanto mais iterações, mais precisa a previsão.

Digamos que o proprietário do produto quer concluir 500 pontos de história na lista de pendências. Sabemos que a equipe de desenvolvimento geralmente conclui 50 pontos de história por iteração. O proprietário do produto pode assumir, razoavelmente, que a equipe precisará de dez iterações (mais ou menos) para concluir o trabalho necessário.

É importante monitorar como a velocidade evolui ao longo do tempo. Novas equipes podem esperar ver um aumento na velocidade à medida que as relações e o processo de trabalho são otimizados. Equipes existentes podem monitorar sua velocidade para garantir um desempenho consistente ao longo do tempo e podem confirmar se uma mudança de processo específica fez melhorias ou não. Uma diminuição na velocidade média é geralmente um sinal de que alguma parte do processo de desenvolvimento da equipe tornou-se ineficiente e deve ser avaliada na próxima retrospectiva.

ANTIPADRÕES QUE DEVEM SER OBSERVADOS

Quando a velocidade for errática durante um longo período, sempre reveja as práticas de estimativa da equipe. Durante a retrospectiva da equipe, faça as perguntas seguintes:

  • Há desafios imprevistos de desenvolvimento com os quais não contávamos ao estimar este trabalho? Como podemos dividir melhor o trabalho para descobrir alguns desses desafios?
  • Há alguma pressão de negócios levando a equipe para além de seus limites? Há uma piora na adesão às melhores práticas de desenvolvimento em decorrência disso?
  • Como equipe, estamos tendo muito cuidado na previsão para o sprint?

Each team’s velocity is unique. If team A has a velocity of 50 and team B has a velocity of 75, it doesn’t mean that team B has higher throughput. Since each team’s estimation culture is unique, their velocity will be as well. Resist the temptation to compare velocity across teams. Measure the level of effort and output of work based on each team’s unique interpretation of story points.

Gráfico de controle

Control charts focus on the cycle time of individual issues–the total time from “in progress” to “done”. Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

Medir o tempo de ciclo é um modo eficiente e flexível de melhorar os processos de uma equipe, pois os resultados das mudanças são perceptíveis quase imediatamente, permitindo que a equipe faça quaisquer ajustes necessários. A meta final é ter um tempo de ciclo curto e consistente, independentemente do tipo de trabalho (novo recurso, débito técnico, etc.).

ANTIPADRÕES QUE DEVEM SER OBSERVADOS

Os gráficos de controle podem parecer instáveis no início. Não fique tão preocupado com todos os valores atípicos. Procure por tendências. Aqui estão duas áreas para observar:

  • Aumentar o tempo de ciclo -aumentar o tempo de ciclo diminui a agilidade que a equipe trabalhou muito para obter. Na retrospectiva da equipe, reserve um tempo para entender um aumento. Uma exceção: se a definição da equipe de “concluído” tiver sido expandida, o tempo de ciclo provavelmente também será expandido.
  • Tempo de ciclo irregular – a meta é ter um tempo de ciclo consistente para os itens de trabalho que têm valores similares de ponto de história. Filtre o gráfico de controle para cada valor do ponto de história para verificar a consistência. Se o tempo de ciclo for irregular em valores de ponto de história pequenos e grandes, passe um tempo na retrospectiva examinando as falhas e melhorando a estimativa futura.

Diagrama de fluxo cumulativo

O diagrama de fluxo cumulativo é um recurso importante para as equipes kanban , ajudando a garantir que o fluxo de trabalho na equipe seja consistente. Com vários problemas no eixo Y, tempo no eixo X e cores para indicar os vários estados do fluxo de trabalho , ele aponta, visualmente, os défices e os obstáculos e trabalha em conjunto com os limites de WIP.

O diagrama de fluxo cumulativo deve parecer mais suave da esquerda para a direita. Bolhas ou lacunas de uma cor indicam carências e obstáculos, então, quando vir uma, procure por modos de suavizar a faixa de cor no gráfico.

ANTIPADRÕES QUE DEVEM SER OBSERVADOS

  • Problemas de bloqueio criam backups grandes em algumas partes do processo e ausências em outros.
  • Crescimento da lista de pendências não verificada ao longo do tempo. Isto acontece quando os proprietários do produto não encerram os problemas que estão obsoletos ou simplesmente com prioridade muito baixa para serem abordados.

Ainda mais métricas

Boas métricas não são limitadas aos relatórios discutidos acima. Por exemplo, a qualidade é uma métrica importante para as equipes ágeis e há um número de métricas tradicionais que podem ser aplicadas ao desenvolvimento ágil:

  • Quantos defeitos são encontrados…
    • durante o desenvolvimento?
    • após a liberação para os clientes?
    • por pessoas fora da equipe?
  • Quantos defeitos são adiados para uma liberação futura?
  • Quantos pedidos de suporte ao cliente estão chegando?
  • Qual é a porcentagem de cobertura de teste automatizado?

As equipes ágeis também devem analisar a velocidade de de entrega e a frequência da liberação. No final de cada sprint, a equipe deve liberar o software para produção. Com que frequência isso realmente acontece? A maioria das liberações está sendo enviada? Na mesma linha, quanto tempo leva para a equipe liberar uma correção de emergência para produção? A liberação é fácil para a equipe ou exige muito trabalho?

As métricas são apenas uma parte da criação da cultura da equipe. Elas fornecem insight quantitativo no desempenho da equipe e fornecem metas mensuráveis para a equipe. Embora sejam importantes, não se preocupe apenas com isso. Ouvir o feedback da equipe durante as retrospectivas é igualmente importante no fortalecimento da confiança na equipe, qualidade do produto e velocidade de desenvolvimento durante o processo de liberação. Use os feedbacks quantitativos e qualitativos para impulsionar a mudança.

Execução de programas ágeis (sem perder a cabeça)

Algumas pessoas podem pensar que a transição para ágil significa perder de vista uma visão geral maior. Não há como não discordar.

Os usuários iniciais do desenvolvimento ágil eram equipes pequenas e independentes que trabalhavam em projetos pequenos e independentes. Eles provaram que o modelo ágil pode funcionar para a alegria e a melhoria de fabricantes de software ao redor do mundo. Mais recentemente, organizações maiores estão usando dimensionamento ágil além do uso em projetos ou equipes pequenas, buscando maneiras de aplicá-lo aos programas como um todo.

Nada vem sem desafios. Mas isso não significa que não possa ser feito. Em primeiro lugar, vamos ouvir sobre como a Gilt, uma loja de roupas on-line, usa o método ágil para transformar seu negócio.

Cascata versus ágil

Vamos começar com o básico – como o que torna ágil diferente.

Estilos de gerenciamento de projeto tradicional, como cascata, criação em fases. Abaixo está uma ilustração de um projeto cascata padrão. Esse estilo de desenvolvimento de produto coloca tudo em uma única versão “big bang” de alto risco. Uma vez que um projeto passa por uma fase, é difícil para revisá-lo, pois as equipes estão sempre avançando para a próxima fase.

Estilos de gerenciamento de projeto tradicional muitas vezes criam “caminhos críticos”, nos quais o projeto não pode avançar até um problema seja resolvido. Para adicionar insulto à injúria, o cliente final não pode interagir com o produto até que ele esteja totalmente completo. Assim, questões importantes no design do produto, bem como o código, ficam desconhecidas até o lançamento.

Vamos comparar isso com um estilo de gerenciamento de projetos ágil, que usa uma abordagem iterativa para desenvolvimento com intervalos de feedbacks regulares. Essas iterações permitem que a equipe possa se focar (e ser produtiva) em outra área do projeto enquanto um obstáculo é resolvido.

Além de remover caminhos críticos, as iterações permitem interagir com o produto durante o desenvolvimento.

Isso, por sua vez, fornece à equipe oportunidades constantes de criar, entregar, aprender e ajustar. Mudanças do mercado não pegarão você desprevenido, e as equipes estão preparadas para se adaptarem rapidamente aos novos requisitos.

Um benefício ainda maior é o compartilhamento de conjuntos de habilidades na equipe de software. Os conjuntos de habilidades sobrepostos da equipe adicionam flexibilidade ao trabalho em todas as partes da base de código da equipe. Desse modo, trabalho e tempo não são desperdiçados se a direção do projeto mudar. (Para mais sobre isso, consulte nosso artigo sobre criação de ótimas equipes ágeis).

Como criar um ótimo programa ágil

Quando um programa migra do gerenciamento de projeto tradicional para o ágil, a equipe e as partes interessadas devem usar dois conceitos importantes:

  • O foco do proprietário do produto é otimizar o valor da produtividade da equipe de desenvolvimento. A equipe de desenvolvimento depende de o proprietário do produto priorizar o trabalho mais importante.
  • A equipe de desenvolvimento só pode aceitar o trabalho que tem capacidade para realizar. O proprietário do produto não envia trabalho para a equipe ou compromete a equipe com prazos arbitrários. A equipe de desenvolvimento puxa o trabalho da lista de pendências do programa à medida que consegue aceitar novos trabalhos.

Vamos explorar os mecanismos que os programas ágeis usam para organizar, executar e estruturar o trabalho de uma forma iterativa.

Roadmaps

Um roteiro mostra como um produto ou solução se desenvolve ao longo do tempo. Os roteiros são compostos por iniciativas, que são grandes áreas de funcionalidade, e incluem cronogramas que comunicam quando um recurso será disponibilizado. À medida que o programa se desenvolve, o roteiro pode mudar–às vezes sutilmente, às vezes totalmente. A meta é manter o roteiro focado nas condições atuais do mercado e nas metas a longo prazo.

Requisitos

Cada iniciativa no roteiro é dividida em um conjunto de requisitos. Os requisitos ágeis são descrições breves da funcionalidade exigida, em vez de documentos com 100 páginas associados a projetos tradicionais. Eles são desenvolvidos ao longo do tempo e usam o entendimento compartilhado sobre o cliente pela equipe e o produto desejado. Os requisitos ágeis permanecem enxutos enquanto todos na equipe desenvolvem um entendimento compartilhado por meio de colaboração e conversas contínuas. Apenas quando a implementação está para começar que eles são mais detalhados.

Lista de pendências

A lista de pendências define as prioridades para o programa ágil. A equipe inclui todos os itens de trabalho na lista de pendências: novos recursos, erros, melhorias, tarefas técnicas e de arquitetura, etc. O proprietário do produto prioriza o trabalho na lista de pendências para a equipe de engenharia. Então, a equipe de desenvolvimento usa a lista de pendências priorizada como fonte única da verdade para o que o trabalho precisa ser feito.

Veículos de entrega ágil

O método ágil pode ser implementado usando várias estruturas (como scrum e kanban) para fornecer software. As equipes scrum usam sprints para guiar desenvolvimento, e as equipes kanban normalmente trabalham sem intervalos de trabalho fixos. No entanto, ambas as estruturas usam veículos de entrega grandes , como epics e versões, para estruturar o desenvolvimento para uma frequência de liberação sincronizada para produção.

Métricas ágeis

Equipes ágeis prosperam com as métricas. Os limites dotrabalho em andamento (WIP) mantêm a equipe e o negócio focados na entrega de um trabalho de alta prioridade. Os gráficos, como burndown e gráficos de controle, ajudam a equipe a prever a frequência de entrega, e os diagramas de fluxo contínuo ajudam a identificar os obstáculos. Essas métricas e artefatos mantêm todos focados em grandes metas e aumentam a confiança na capacidade da equipe de entregar trabalho futuro.

Execuções ágeis com confiança

Um programa ágil não pode funcionar sem um nível elevado de confiança entre os membros da equipe. Isso requer sinceridade ao ter conversas difíceis sobre o que é certo para o programa e o produto. Como as conversas acontecem em intervalos regulares, ideias e preocupações são expressas regularmente. Isso significa que os membros da equipe também devem confiar na capacidade do outro (e vontade) para executar as decisões tomadas durante as conversas.

Em resumo, o desenvolvimento ágil é uma abordagem iterativa e estruturada para fazer software. Ele fornece a capacidade de responder às mudanças sem sair dos trilhos. E isso é uma boa notícia para qualquer programa.