Categoria: Agile

Os 7 princípios do Lean para desenvolvimento de software e os mitos que você deve evitar com todas as forças

O Lean tem se tornado cada vez mais popular no desenvolvimento de software entre as empresas que buscam entregar produtos com alta qualidade e valor aos clientes.

No entanto, ainda existem muitos mitos e equívocos que podem prejudicar o sucesso dos times ágeis. Nesse post, vamos desmistificar os mitos relacionados aos 7 princípios do Lean para desenvolvimento de software, que você deve evitar com todas as forças.

Vou citar cada um dos princípios do Lean e um mito relacionado a ele. Ao seguir os princípios do Lean, as equipes de desenvolvimento podem alcançar resultados significativos em termos de eficiência e satisfação do cliente.

Então, vamos lá!

Princípio 1: Eliminate Waste (Eliminar Desperdício)

Mito: Mais especificações no início do projeto reduzem o desperdício.

Alguns times acreditam que ter muitas especificações no início do projeto pode ajudar a eliminar o desperdício, pois todas as necessidades e requisitos já estarão documentados. No entanto, isso pode levar a uma abordagem de “big design upfront”, que pode levar a muitas especificações desnecessárias ou imprecisas, desperdiçando tempo e recursos.

Princípio 2: Build Quality In (Construir a Qualidade):

Mito: Testadores são responsáveis por encontrar defeitos.

Muitos times acreditam que é responsabilidade dos testadores encontrar e corrigir defeitos. No entanto, o objetivo do Lean é construir a qualidade desde o início, o que significa que todos os membros da equipe devem se esforçar para prevenir defeitos e encontrar soluções antes que eles aconteçam. Ressalto que bug, ou seja defeito, o que foi reportado depois de estar em produção. Os chamados “bugs internos” são acertos e parte do desenvolvimento.

Princípio 3: Create Knowledge (Criar Conhecimento):

Mito: Conhecimento é criado somente através de documentação.

Alguns times acreditam que criar documentação é a única forma de criar conhecimento, mas o Lean enfatiza a importância de aprendizado contínuo e comunicação efetiva. O conhecimento é criado através de experimentação, feedback e conversas entre membros da equipe.

Princípio 4: Defer Commitment (Adiar Compromisso):

Mito: Planejar é comprometer-se.

Alguns times acreditam que fazer um plano detalhado é se comprometer a seguir esse plano. No entanto, o Lean enfatiza a flexibilidade e a adaptação às mudanças. Em vez de se comprometer com um plano detalhado, a equipe deve se comprometer com os objetivos do cliente e trabalhar para entregá-los da melhor maneira possível.

Princípio 5: Deliver Fast (Entregar Rápido):

Mito: Pressa gera desperdício.

Alguns times acreditam que ter pressa para entregar o software pode gerar desperdício, pois não há tempo suficiente para fazer as coisas corretamente. No entanto, o objetivo do Lean é entregar valor ao cliente o mais rápido possível, sem sacrificar a qualidade. Isso significa que a equipe deve trabalhar de forma eficiente para entregar valor em ciclos curtos e frequentes.

Princípio 6: Respect People (Respeitar as Pessoas):

Mito: Trabalhar mais horas é a melhor forma de aumentar a produtividade.

Alguns times acreditam que trabalhar mais horas é a melhor forma de aumentar a produtividade. No entanto, o Lean enfatiza a importância de respeitar as pessoas e seus limites. Trabalhar excessivamente pode levar a problemas de saúde e estresse, o que pode diminuir a produtividade e a qualidade do trabalho.

Princípio 7: Optimize the Whole (Otimizar o Todo):

Mito: Otimizar partes individuais leva à otimização do todo.

Otimizar partes individuais do sistema não é suficiente para tornar todo o sistema eficiente, pelo fato das partes individuais estarem interligadas e afetarem umas às outras. Se apenas uma parte do sistema for otimizada, outras partes podem ser até prejudicadas, o que pode levar a problemas no sistema como um todo.

Bom, pra finalizar, é fundamental estar ciente desses mitos e trabalhar para superá-los, a fim de obter o máximo benefício do Lean no desenvolvimento de software.

Para saber mais…

Os mitos e princípios Lean foram extraídos do livro Implementing Lean Software Development, Mary and Tom Poppendieck, o meu livro preferido sobre Lean aplicado ao desenvolvimento de software em times ágeis.

Esses princípios fazem parte do treinamento DASM – Disciplined Agile Scrum Master da jornada ágil do PMI. Eu sou o instrutor desse treinamento pela JUMP TREINAMENTO PROFISSIONAL.

Mais informações sobre o Preparatório DASM da JUMP: https://www.jump.bhz.br/dasm

Agile na Capital One: a polêmica sobre as demissões

Capital One

Primeiro vamos aos fatos.

Conforme anunciado pela Bloomberg em 19 de janeiro de 2023, e no The Register em 20 de janeiro de 2023 a Capital One cortou, entre outros cargos de tecnologia, alguns papéis de agilidade como Agile Coaches, Scrum Masters.

Vejamos alguns trechos de declarações da empresa:

“Em 19 de janeiro, a Capital One cortou 1.100 cargos de tecnologia, disse uma fonte familiarizada com o assunto à Bloomberg – a Capital One não confirmou o número de cargos que seriam cortados, embora um porta-voz tenha dito à Forbes que os funcionários afetados foram informados de que poderiam se candidatar a outras funções na empresa.”

A empresa disse ao The Reg que sua organização de tecnologia “não estava se afastando do Agile e continuará a usar metodologias Agile para entregar software”, acrescentando: “essa mudança reflete como os processos ágeis se tornaram parte de nossas principais práticas de engenharia.“

“O papel Agile em nossa organização de tecnologia foi fundamental para nossas fases de transformação anteriores, mas conforme nossa organização amadureceu, o próximo passo natural é integrar os processos de entrega ágil diretamente em nossas principais práticas de engenharia.”

“Com a mudança desta semana, a empresa está eliminando cargos focados na chamada Agile Delivery de tecnologia. Em vez disso, espera-se que engenheiros e gerentes de produto usem rotinas ágeis naturalmente.”

“A Capital One continua comprometida em recrutar os melhores talentos, incluindo investimentos contínuos no recrutamento de novos profissionais e contratações de campus. Nossa organização de tecnologia está recrutando ativamente para uma variedade de posições, incluindo funções de engenharia focadas em nuvem, dados, aprendizado de máquina e segurança cibernética, bem como como Gerentes de Produto.”

Acredito que no caso da Capital One especificamente, nao se trata de estarem demitindo o Agile da empresa. Como foi dito, eles estão reestruturando após uma primeira transformação ágil, talvez “by the book”, para que nessa próxima fase a agilidade esteja mais integrada a todos os processos e ao Gerenciamento de Produtos.

Confesso que fiquei curioso em conhecer mais a fundo essa nova fase e não me parece um enfraquecimento da agilidade. pelo contrario. Vejo que é um ganho de consciência, um entendimento do contexto da empresa com o objetivo de criar um sistema de trabalho que funcione melhor, mais alinhado ao negócio dela.

Essa consciência corporativa é um dos princípios importantes para o sucesso das iniciativas de transformação ágil nas organizações.

Big Techs estão demitindo

É fato. A Forbes publicou uma lista dos layoffs das BIG TECHs em 2023. Isso inclui IBM, Microsoft, Google, Spotify, Amazon, Facebook (Meta) entre outras outras.

Nesse cenário mais amplo de demissões, minha opinião é que estamos em um momento de recessão pós-COVID, que desencadeou reduções de quadros em diversas Big Techs e não me parece que termina por aqui. A maior motivação é à diminuição da demanda por serviços digitais após a pandemia, devido ao término dos períodos de lock-down pelo mundo.

Portanto, como é fato que não é apenas a Capital One que está demitindo e essas demissões não me parecem focadas em um ponto específico passando longe de ser culpa do Agile, sejamos mais coerentes e vamos olhar para o futuro. Essa polêmica não tem fundamento.

Acredito que as empresas que fizeram o para-casa, se transformando rumo a agilidade de negócios, tem um modelo operacional ágil com mais capacidade de responder às oscilações do mercado nesse momento de recessão.

E você, o que vc acha?

Workshop e palestra no CBGPL 2019

No mês de maio tive a honra de participar do XIV Congresso Brasileiro de Gestão, Projetos e Liderança 2019 em Campinas a convite do capítulo PMI de São Paulo, rodando um workshop e uma palestra.

No Workshop de Kanban  aplicamos os princípios e práticas do Kanban para um grupo de 32 pessoas. O workshop foi bem divertido com participação ativa do pessoal.

A palestra foi sobre Transformação ágil. O assunto foi apresentado para um grupo grande de líderes que escolheram a minha apresentação dentre tantas outras que aconteciam no mesmo horário.

Agradeço ao time do PMI São Paulo pelo convite e parabenizo pelo evento de alto nível e pela organização impecável.

Segue o link da apresentação:

 

Arquitetura Ágil = Design Emergente + Arquitetura Intencional

Metodologias de desenvolvimento tradicionais costumam usar Big-Design-Up-Front (BUFD) para criar uma infra-estrutura de roadmap arquitetônico destinado a atender plenamente as necessidades do futuro sistema. A crença é que um esforço único no início poderia capturar requisitos e planos arquitetônicos suficientes para suportar o sistema para os próximos anos.

No entanto, esta abordagem vem com muitos desafios. Um deles é o delay no início da execução. Um outro desafio surge quando a arquitetura planejada, que possui um conjunto grande de especulações, se encontra com o mundo real. Pouco tempo é suficiente, para que os desenhos se tornem frágeis e difíceis de mudar e eventualmente surge um Big-branch-and-merge para que um novo conjunto de suposições especulativas seja colocado em ação. Para endereçar esses desafios combinamos o design emergente e a arquitetura intencional, impulsionados pela colaboração.

Design Emergente

O princípio 11 do Agile Manifesto é o principal motor por trás do conceito de design emergente: “As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas.” As implicações disso são:

  • O design é cultivado de forma incremental por aqueles que estão mais próximos a ele.
  • O projeto evolui de mãos dadas com a feature de negócios. Ele é constantemente testado e ativado por refatoração, TDD e integração contínua.
  • Equipes evoluem rapidamente o projeto de acordo com os requisitos atualmente conhecidos; o projeto é estendido somente conforme necessário para implementar e validar o próximo incremento de feature.

Esta nova prática de design emergente é eficaz no nível de equipe. No entanto, o design emergente por si só é insuficiente para o desenvolvimento de grandes sistemas.

  • Ele pode causar redesenho excessivo para coisas que poderiam ter sido antecipadas.
  • Equipes nem sempre são capazes de sincronizar com as outras, criando assim uma entropia de suposições e divergência de arquitetura.
  • As equipes podem mesmo não estar cientes de algumas das necessidades futuras de negócios maiores; fatores fora de seu alcance que direcionam a necessidade da arquitetura futura.
  • Bases comuns de arquitetura melhoram a usabilidade, extensibilidade, desempenho e manutenção de um sistema de sistemas maior.
  • Novos, padrões do usuário transversais afetam o propósito futuro da arquitetura.
  • Fusões e aquisições direcionam integrações e a necessidade de padronização da infra-estrutura.

Arquitetura Intencional

Portanto, chega um ponto em que o design emergente é uma resposta insuficiente à complexidade do desenvolvimento de sistemas em larga escala. Simplesmente, não é possível para as equipes se antecipar às mudanças que podem muito bem ocorrer fora do seu ambiente. Também não é possível para as equipes individuais entenderem completamente todo o sistema e, assim, evitar a produção de código e design redundante e ou conflitantes. Para isso alguma arquitetura intencional é necessária – um conjunto de iniciativas de arquitectura intencional, planejado para aumentar o design da solução, desempenho e usabilidade e fornecer orientação para o projeto entre as equipes e sincronização da implementação.

Arquitetura é uma colaboração

Claramente, é melhor ter ambos: rápido, controle local do design emergente e uma visão global da arquitetura intencional. A combinação, proporciona a orientação necessária para assegurar que o sistema como um todo tenha integridade conceitual e eficácia. Alcançar o equilíbrio certo de design emergente e arquitetura intencional impulsiona a evolução eficaz do sistema, como mostrado no diagrama desse post. 

O diagrama mostra que eles não são construções independentes. Arquitetura intencional restringe o design emergente, mas a um nível suficientemente elevado de abstração para permitir que as equipes possam se adaptar eficazmente a parte “intencional” para seu contexto específico. Ao mesmo tempo, influências e design emergente corrigem a arquitetura intencional e também alimentam novas ideias para o futuro, centralizando o esforço intencional.

Tal reciprocidade profunda entre design emergente e arquitetura intencional só pode ocorrer como resultado da colaboração entre as equipes ágeis, arquitetos de sistemas e gestores de produto.

Fonte: SAFe

 

Architecture Owner

Outro dia eu estava conversando com um desenvolvedor super bom de serviço. Ele me disse que acha “waste” essa diversidade de práticas e processos de desenvolvimento ágil. Ele tem muita dificuldade em reunir e visualizar todas as práticas e métodos funcionando juntos porque veio de um contexto muito técnico onde o que tinha de ser feito era apenas escrever código e entregar o software. Ele me disse que gostaria de saber, por exemplo, o que o arquiteto de software faz. 🙂 Eu achei sensacional a duvida dele e expliquei rapidamente o papel do arquiteto, mas isso ficou na minha cabeça e resolvi fazer esse post.

O papel de arquiteto de software ágil hoje está bem mais consolidado. O Disciplined Agile Delivery define o papel do Architecture Owner e as principais responsabilidades desse papel são:

  • Guiar a criação e evolução da arquitetura da solução.
  • Mentor e o Coach dos membros do time nas práticas e questões de arquitetura.
  • Entender a direção arquitetural, os padrões da organização e garantir que o time esteja aderente à eles.
  • Garantir que o sistema será suportado de maneira fácil encorajando um design adequado e tocando as refatorações necessárias para garantir um bom design.
  • Garantir que o sistema seja testado e integrado frequentemente.
  • Tem a palavra final sobre as decisões técnicas, mas deve engajar o time nas decisões e não dita-las.
  • Lidera o esforço de visualização inicial da arquitetura.
  • Trabalhar junto ao time de arquitetura corporativa (se ele existir).

No ciclo de vida básico do DAD existe um marco específico para provar a arquitetura o mais cedo possível na fase de construção. É uma forma do arquiteto mitigar os riscos técnicos e um checkpoint de governança para sinalizar a gerência sênior e outros stakeholders as decisões e questões técnicas.

Enterprise Agile

Como ponto de partida o Scrum é um excelente método ágil. No Brasil ele abre as portas das empresas para a agilidade. Isso se dá pela sua grande difusão entre os profissionais de gerenciamento de projetos nas áreas de TI. Agora, quando as empresas começam a levar o agile para um patamar corporativo o Scrum sozinho se mostra insuficiente.

Na prática, para uma abordagem corporativa é necessário recorrer a outros métodos para preencher os gaps de processo que o Scrum não trata. É aí que surgem as dificuldades. Quando as empresas começam a olhar para outros métodos surge o conflito de terminologias e a sobreposição de conceitos. Isso gera uma certa confusão na hora de definir e instalar esse novo processo. Faltam elementos para integrar o agile com as estratégias de governança das empresas.

Nesse contexto surgiu o Disciplined Agile Delivery (DAD). O DAD é uma abordagem híbrida que faz a “costura” de diversos métodos no formato de um framework de decisão. Esse framework te ajuda a definir o processo mais adequado de acordo com o contexto e a cultura organizacional da sua empresa. Diferente do Scrum, o DAD considera que existe um ecossistema corporativo e ele não pode ser ignorado.

O DAD estende o Scrum com estratégias do Extreme Programming (XP), Agile Modeling (AM), Unified Process (UP), Kanban, Lean Software Development, SAFe entre outros. Ele aborda práticas técnicas como Continuous Delivery, TDD, arquitetura, modelagem e também documentação e governança, fornecendo alternativas que aumentam a chance de você adotar estratégias que funcionem no seu contexto. Se você tem interesse em DAD entre em contato comigo. Vamos bater um papo.

Para mais informações acompanhe o blog Disciplined Agile Delivery. Para saber mais sobre treinamentos e certificações acesse o site do Disciplined Agile Consortium. 

2 Pizzas = 1 Team

2 pizzas

Regra de ouro para dimensionar times ágeis.

Regra das duas pizzas: O Time deve ter o número de pessoas que possa ser alimentado com duas pizzas.

Assim, o time deve ter 7 mais ou menos duas pessoas, ou seja, de 5 a 9 pessoas. A razão para essa regra é que times pequenos facilitam a comunicação entre os seus membros. Agora, se o time for incluir o João Vitor, então pode pedir uma pizza só pra ele. 🙂

Essa regra é atribuída a Jeff Bezos, fundador da Amazon.

Novo livro sobre DAD: Introduction to Disciplined Agile Delivery

Você está procurando um livro enxuto, de poucas páginas, de fácil leitura, que mostra como aplicar o DAD em situações típicas do dia-a-dia?  Achou! 🙂

Acaba de ser lançado o livro Introduction to Disciplined Agile Delivery

Esse livro de 102 páginas é para aqueles que querem conhecer a essência do DAD, o que ele é e o que não é  e quais os seus benefícios.

Sobre o DAD, ele é gratuito para uso e apesar de ter sido desenvolvido originalmente na IBM agora é mantido pelo Disciplined Agile Consortion.  No DAC você encontra todas as informações sobre o programa de certificação em DAD.

Boa leitura!

IntroDADCoverMedium

A Small Agile Team´s Journey from Scrum to Continous Delivery.
by Mark Lines and Scott Ambler