Um sistema ruim sempre derrota pessoas boas

Brasil e Alemenha em 2014 - 7 x1

O dia era 8 de Julho, do ano de 2014. Era uma terça-feira com um céu azul e tempo agradável, como todo fim de outono em Belo Horizonte. Brasil e Alemanha iriam se enfrentar pela semifinal da copa do mundo. Nunca um jogo dessa magnitude havia acontecido na região das alterosas. E por todo o  Brasil havia uma grande expectativa da sua seleção estar em uma final de copa do mundo.

Só que não! A história, contada e recontada, você conhece bem. Não preciso repeti-la aqui.

Avancemos para o dia seguinte. Um vexame esportivo como nunca visto na história Brasileira. Jornais de todo o mundo destacam a excepcional vitória da Alemanha, nunca antes vista em uma semifinal.  E para o brasileiro comum, eu inclusive, restava erguer os dedos e apontar culpados. Afinal, é mais fácil culpar pessoas quando alguma coisa vai mal.

O mito dos heróis e vilões

Tendemos a supervalorizar o talento individual. Acreditamos que as maiores e piores coisas que acontecem são obras de pessoas; iluminadas ou amaldiçoadas. Fazemos isso o tempo todo, culpando aquele jogador, aquele político ou aquele colega de trabalho pelo insucesso das iniciativas que estamos observando ou participando.

Esse pensamento é ingênuo. Muito. E para piorar, somos programados a insistir nessa ingenuidade. Psicólogos já catalogaram esse viés, chamado de Viés de Atribuição. Esse viés cognitivo se refere aos erros sistemáticos cometidos quando as pessoas avaliam ou tentam encontrar razões para seus próprios comportamentos e os dos outros.

Se você corta alguém abruptamente no trânsito, você cria uma justificativa no seu cérebro. Estou atrasado para pegar meu filho na escola. Foi mal.

Mas se alguém faz o mesmo com você duas semanas depois, aquele sujeito é um babaca ignorante sem nenhum escrúpulo e educação. Ele merece morrer empalado em praça pública, sem sombra de dúvida.

O mito dos heróis e vilões nas empresas

Em muitas organizações, é inútil preocupar-se indevidamente com variações entre indivíduos. Tipicamente, a  cultura organizacional, políticas e a liderança tornam irrelevantes as diferenças entre indivíduos.

Por quê? Empresas não “criam” coisas pois elas são seres sencientes. Ao invés, empresas executam, competem e coordenam esforços de muitas pessoas. As empresas mais bem-sucedidas nestas tarefas são aquelas em que o sistema de trabalho é a estrela.

W. Edwards Deming já nos mostrava empiricamente na metade do século XX que a performance das instituições  é dirigida muito mais pelos sistemas de trabalho do que pelo talento individual.  Empresas são sistemas adaptativos complexos. E, em sistemas adaptativos complexos, os resultados são multifatoriais e não são óbvios. Se o fossem, todo empreendedor chefiaria uma Apple, Google ou Amazon nesse exato momento.

O que são sistemas de trabalho?

Vou trazer um relato de um caso que experienciei. Um trabalhador em uma organização era vilanizado por ser alguém que cometia muitos defeitos em suas tarefas. A área de qualidade dessa empresa o satanizava e discussões pesadas aconteciam com a área de engenharia por causa dessa pessoa.

A área de engenharia dessas organização trabalhava com políticas de remuneração variáveis. E essa pessoa, em particular, era premiada por cumprir tarefas no prazo; mesmo que a qualidade não fosse endereçada. Afinal, havia uma área de qualidade para “pegar” os defeitos. Com tais incentivos, ele se adaptou. E realmente o foco dele era apenas a velocidade de entrega das tarefas.

O efeito prático das políticas de otimização local do trabalho e da atribuição de problema para as pessoas contribuiu para que essa empresa tivesse tempos de resposta enormes para as demandas do time do tal garoto enxaqueca. Era um cenário destrutivo e todos perdiam. Um verdadeiro 7×1.

Quando um novo gestor entrou e começou a mudar as engrenagens do sistema (não as pessoas), as políticas foram mudadas e também os sistemas de incentivos. A cultura agora foi mudada de competição local para ganhos globais ou nada feito. Os incentivos financeiros valorizam de forma balanceada a velocidade e fatores de qualidade. Depois de alguns meses, a pessoa que era culpada por tantos defeitos passou a entrega tarefas com índices de qualidade excelente, na visão das outras áreas.

O que houve aqui? O sistema foi ajustado, gradativamente. E ajustes no sistema com políticas corretas ajudam a incentivar bons comportamentos. E bons comportamentos, repetidos em base diária, cultivam culturas de sucesso. E culturas de sucesso criam espaço para que oportunidades aleatórias catapultem organizações para o sucesso.

Como posso criar sistemas de trabalho na minha organização?

  1. Primeiro, combata a sua programação mental ingênua.Quando um erro grave acontecer, você vai querer a cabeça do infeliz que a cometeu. Em uma bandeja de prata. Esse é o seu modo lagarto em ação, tomando o controle mental do seu neocortex cerebral. Ao invés, pare e respire. Faça uma análise das fragilidades do seu sistema de trabalho. Se erros graves então acontecendo, o sistema de trabalho está frágil.Nada é verdadeiramente bom ou ruim, mas o pensamento faz com que o seja, já dizia William Shakespeare.
  2. Combata as fragilidades. E não as pessoas.Examine as políticas em curso, explícitas ou implícitas.  Examine a cultura e o efeito das políticas em curso no comportamento das pessoas. Finalmente, analise os sistemas de incentivos. Realize análises de causa raiz com instrumentos como o processo A3. E descubra com profundidade os fatos geradores dos comportamentos ruins que provocam erros danosos na sua organização.
  3. Mude o sistema de trabalho, um grão de area por dia. 

    Envolva as pessoas nas mudanças e busque atos de liderança. Em base  periódica, introduza mudanças evolucionárias na sua organização. Essas mudanças devem introduzir estressores de melhoria na sua organização e tornar os seus sistemas menos frágeis, resilientes, robustos e eventualmente anti-frágeis.Por exemplo, o Método Kanban possui um amplo catálogo de ideias de melhorias ligada a gestão visual, limitação do trabalho em progresso, políticas explícitas, gestão do fluxo, sistemas de feeback, entre outros. Somado a um mecanismo de mudanças evolucionárias e atos de liderança, ela pode ajudar você na mudança da sua organização para criar agilidade de negócio e mais robustez.Um outro exemplo é a cultura DevOps. Através de práticas evolucionárias de colaboração, automação, medição e gestão de fluxo, ela promove que empresas de TI possam reduzir tempos de entrega, melhorar feedbacks técnicos e promover mais experimentos.

    Um terceiro exemplo é o modelo mental do Management 3.0, que busca operar na energização de pessoas, empoderamento de times, alinhamento de restrições e desenvolvimento de competências em ambientes de gestão complexos.

    Então, pessoas são irrelevantes?

    Lógico que não. O oposto é verdade. Você deve energizar pessoas todo o tempo e de todas as formas possíveis. Fornece-las propósito, autonomia e oportunidades contínuas de desenvolvimento é fundamental para desenvolver e aprimorar os seus sistemas de trabalho.

    Aqui entra o papel da liderança. Quando um líder é fraco e cultiva sistemas de trabalho ruins, a colheita será pífia. Mesmo com pessoas brilhantes.

    Ao invés, se você como líder desenha bons sistemas de trabalho, você abre espaço para o desenvolvimento das pessoas e você terá resultados positivos para a sua gestão e a sua organização.

Os gerentes não são confrontados com problemas independentes entre si, mas com situações dinâmicas que consistem em sistemas complexos de problemas de mudança que interagem entre si. Eu chamo essas situações de bagunça. Os problemas são extraídos das bagunças pela análise. Os gerentes não resolvem problemas, eles gerenciam bagunças, Russel Ackoff

 

 

 

 

 

 

 

 

 

Scrum Medíocre – 5 Disfunções ágeis e seus antídotos

O Scrum é o framework ágil mais usado na comunidade ágil. Desenhado ainda nos 90, ele trouxe um guia acionável para organizar e entregar projetos com ideias muito boas tais como:

  • Ciclos PDCA de curto prazo (Sprints) e ritos para sistematizar esses ciclos (planejamento de sprint, reunião diária, revisão e retrospectiva)
  • Papel de facilitador do método, combinando funções de processo e de gestão (Scrum Master)
  • Papel de interface com áreas de negócio e conceito mais claro de produto (Product Owner)
  • Times multidisciplinares (ao invés de pessoas que trabalham sozinhas e não colaboram).

Entretanto, a forma como o Scrum foi implementado em muitas organizações lá fora e no Brasil criou um monstrinho que apelido aqui de Scrum Medíocre. É fácil reconhece-lo através de disfunções comuns. Enumero 5 dessas disfunções ágeis aqui.

Reunião diária zombie

SM: – João, o que você fez ontem?
SM: – E você, Maria, o que fez ontem?
SM: – José, meu filho, me fala o que fez ontem?

João, Maria e José, como zombies, respondem de forma catatônica às perguntas do Scrum Master comando e controle. Eles estão com sono, não querem estar ali em pé, detestam aquele momento e estão contando os minutos para voltar às suas mesas e colocar o fone de ouvido.

Qual o problema aqui? Foco nas pessoas e não no trabalho.

Trabalho empurrado

Primeiro dia da Sprint 
PO: – Time, nos temos 7 histórias que devem ser completadas em 10 dias úteis. Ordens da chefia. João, você pega as histórias 1 e 2. Maria, você que é sênior irá trabalhar nas histórias 3, 4 e 5. José, conto com você para cuidar das histórias 6 e 7.

Ultima dia da Sprint
O time não entrega nem 50% do trabalho empurrado e é culpado pela sua performance ruim. Uma reunião de retrospectiva é chamada onde o time tem a sua atenção chamada pelos problemas de desempenho.

Primeiro dia da próxima sprint
A mesma história se repete.

Métricas míopes

Tudo o que o time conhece são sprints e suas métricas locais. O time estima com planning poker, tamanho de camisa e afins. E ele mede a sua produtividade local com gráficos de burndowns.

Mas se você pergunta a qualquer um, até mesmo o PO, quanto tempo demora em média uma demanda para fluir da chegada até a produção, a resposta é nula. Nenhuma métrica acionável de cliente é usada pelo time.

Servidão ao backlog

O backlog é cultuado como se os desejos ali colocados fossem ordens de Deus. O PO e o time não fazem nenhum engenharia de valor e o foco é puramente centrado na entrega de funcionalidades. O % de completude de backlog é usado como métrica de sucesso da iniciativa, centrada puramente em escopo.

Projetos centrados em escopo fixo e prazo aberto

O escopo, ao invés do tempo, é o principal guia para organizar quando um projeto deve terminar. Se um time trabalha 3 meses e o escopo não foi cumprido, novos sprints são abertos até que o escopo seja completado. O conceito de prazo fechado e MVPs são completamente ignorados. O dinheiro é drenado como em projetos tradicionais pelo modelo mental da fixação ao escopo.

Muitas dessas disfunções tem sido amplamente debatidas por agilistas que assinaram o Manifesto Ágil como Martin Fowler, Robert Martin (Uncle Bob) e Allistair Cockburn.

Juntas, essas disfunções criam um cenário terrível de agilidade burocrática que drenam o dinheiro do seu time como um tipo de chupa-cabra do mal.

chupacabra

Antídotos ao Scrum Medíocre

A boa notícia é que você pode incorporar ideias antifrágeis ao seu sistema de trabalho para sair da mediocridade Scrum.

Pergunte ao quadro (Antídoto para a Reunião Diária Zombie)

Ao invés de perguntas para as pessoas sobre o que elas fizeram ontem, pergunte ao quadro. Faça a reunião diária com o quadro Kanban aberto. Navegue da direita para a esquerda (e não da esquerda para a direita). Você quer terminar itens mais que começar novas coisas e aumentar de forma ingênua o trabalho em progresso.

Para cada cartão navegado, pergunte se existem gargalos. Exemplos de gargalos incluem itens bloqueados, tarefas que estão há muito tempo no quadro ou limites ao trabalho em progresso. Quando um gargalo é encontrado, você incentiva ações do time para desbloquear itens bloqueados ou atuar sobre itens parados. Mostre ao time que estamos interessados em fazer o trabalho fluir.

Em resumo. Não pergunte o que o João, Maria e José fizeram ontem. Queremos gerenciar o trabalho e não as pessoas. Essa pequena mudança de comportamento faz o time perceber que você está preocupado com a entrega. E não microgerenciamento do trabalho deles.

Trabalho puxado (Antídoto para o trabalho empurrado)

Ao invés de um trabalho empurrado de forma comando e controle para o time, o PO deve apenas alimentar uma coluna de pronto para começar.

E o time deve puxar o trabalho sob demanda, um item por vez. Ou seja, o time se compromete com poucas coisas. Isso cria foco para o time e reduz sua ansiedade. O compromisso estabelecido cria um trabalho que deve fluir pelo sistema e com a ajuda de reunião diária efetiva irá fluir.

O PO observa a vazão média de itens por  quinzena ou mês. E essa vazão permite que ele comece a compreender a dinâmica do time e a sua capacidade de entrega. E então ele fornece itens dentro da vazão possível pelo time. A realidade deve guiar o PO e não fantasias imaginárias de produtividade.  O trabalho puxado é o melhor aliado do PO para aumento da eficiência do seu time.

Métricas Acionáveis (Antídoto para métricas míopes)

O PO, SM e time devem observar duas métricas centrais na ótica dos clientes que são:

  • O tempo de ciclo das entregas (lead time)
  • A vazão das entregas (taxa de entrega de demandas em base semanal ou quinzenal)

Por quê?

Porque clientes querem saber quanto tempo um time vai demorar para fazer um trabalho e quantos itens são entregues por período (ou sprint).

Em última instância, essas métricas observam se o seu sistema de trabalho é solido, i.e, como o trabalho flui desde o momento do compromisso até o momento do aceite. Como o tempo médio, sua distribuição e a vazão estão se comportando dentro de cada etapa do seu fluxo de trabalho.

Ou seja, essas métricas permitem que você analise gargalos, critérios de aptidão para os seus clientes e lhe permitem estabelecer previsibilidade de trabalhos futuros. Se um time descobre, por exemplo, que o seu time demora 9 dias para entregar um trabalho comprometido, você consegue estabelecer compromissos baseados na realidade objetiva do histórico do seu time.

Gestão do Upstream (Antídoto para a Servidão ao Backlog)

A gestão do upstream é uma técnica onde o PO pode organizar um quadro Kanban específico para identificar, realizar processos de triagem, engenharia de valor e entregar itens prontos para a execução para o time de desenvolvimento de produtos.

Os processos de “triagem” de ideias podem eliminar demandas antes de irem para o time. Essa mortalidade é positiva. Isso gera economia de tempo e consequentemente de custo.

Além disso, o upstream também busca entender a melhor cadência para entregar os itens para o time de desenvolvimento de produtos e qual deve ser a taxa de entrega de itens em base periódica conforme a taxa de consumo viável do time de desenvolvimento. Um quadro de upstream que entrega trabalho além da capacidade de vazão do time de execução (chamado de downstream) gera um backlog  extenso. E essas demandas se tornam obsoletas enquanto aguardam serem atendidas

Fluxo Contínuo e MVPs (Antídoto para projetos centrados em escopo fixo e prazo aberto)

O conceito de fluxo contínuo é um antídoto que pode ser usado em times de maior maturidade. E é incrivelmente poderoso. Ao invés de fixação em projetos com escopo fixo que levam invariavelmente a conflitos terríveis entre times e clientes, buscamos entregas de fluxo contínuo.

Trabalhar em fluxo contínuo significa que um time pega um item quando tem capacidade disponível, se organiza para entregar o item de ponta a ponta dentro do menor tempo de ciclo possível e agrega valor de negócio incrementalmente.

Trabalho com fluxo contínuo em TI não é trivial e requer também que o custo de transação para implantar em produção seja baixo. Isso muitas vezes requer arquiteturas centradas em microsserviços e práticas DevOps CI/CD bem estabelecidas. Mas se você tem as premissas apropriadas, pode ser uma abordagem muito interessante.

O Catálogo de Antídotos do Método Kanban

Cada um desses antídotos faz parte do método Kanban. O método Kanban não é uma alternativa ao Scrum. Ao invés, ele é uma ferramenta para você introduzir mudanças no seu sistema de trabalho centrado em Scrum. Ele é uma lente de análise para você observar o trabalho do seu time, detectar fragilidades e melhorar continuamente o seu sistema de trabalho. Da fragilidade para a resiliências, robustez e então antifragilidade.

O método Kanban lhe fornece esteróides naturais para você introduzir estressores no seu Scrum e sair de um Scrum medíocre para um Scrum de alta maturidade.

Quer melhorar o seu Scrum? Adote práticas Kanban.

“The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much”, Taleb.

 

Kanban e Devops: Bons sozinhos e ainda melhor se juntos.

Dois movimentos que tem ganhado muita tração nos últimos anos na TI são a Cultura DevOps e o Método Kanban.

Já falei sobre a Cultura DevOps aqui nesse espaço em vários posts organizados nessa página. Mas é sempre bom reforçar o conceito de DevOps. Vamos lembrar dos seus três caminhos essenciais.

O Tao do DevOps

  1. O princípio do fluxo, que acelera a entrega do trabalho do Desenvolvimento para Operações e então para os nossos clientes
  2. O princípio do feedback, que nos permite criar um sistema de trabalho cada vez mais seguro;
  3. O princípio de aprendizado contínuo e experimentação, que promove uma cultura de alta confiança e uma abordagem científica para a melhoria organizacional como parte de nosso trabalho diário.

Já o Kanban é um método de gestão de mudanças que busca promover a melhoria de maturidade para o trabalho do conhecimento. No caso particular da TI, um tipo de trabalho de conhecimento, o método Kanban te ajuda a entregar e sustentar software com menor fragilidade.

Gene Kim, um dos autores do excelente livro e bíblia do DevOps chamado O Manual do DevOps  fez uso de várias práticas gerais do método Kanban para definir os princípios e guiar como devemos adotar DevOps na práticas nas nossas organizações.

O purgatório do DevOps

Em algumas empresas onde já rodei diagnósticos de maturidade DevOps vi desenvolvedores muito habilidosos insistindo em implementar ferramentas DevOps pelo culto à tecnologia.

Frases que já ouvi se parecem com o seguinte:

“Temos pipelines de CI implementados para todo o nosso código .NET”

“Temos aqui o JUnit, Jenkins, Terraform e Ansible nos ajudaram em nossos fluxos CI/CD. Nosso DevOps está acelerado”

“Estamos criando automação de testes de unidade em nossos branches. E olhe só, eles são disparados automaticamente quando um commit é feito no branch principal”. 

Quando pergunto sobre como isso ajudou a reduzir o tempo de entrega (Lead Time) ou a taxa de defeitos, ouço um silêncio abissal. Os times não tem medições e não tem a mínima preocupação com isso em suas implementações.

DevOps … de verdade

A mensagem é clara. Se alguém ainda acredita estar fazendo DevOps porque apenas criou um pipeline de uma ferramenta CI/CD  ou um conjunto de testes automatizados, essa pessoa está equivocada.

Qualquer ação que façamos e que não esteja conectada ao Tao do DevOps é ilusão (ou sendo bem rude; pura masturbação técnica).

Um teste Litmus para você avaliar a saúde da sua implantação DevOps é o seguinte:

  1. Se você não evidencia como o seu tempo médio de entrega das demandas está sendo reduzido, o seu movimento DevOps está meia boca.
  2. Se você não evidencia como você está criando sistemas mais seguros (menos frágeis), como por exemplo a redução de problemas graves em produção, o seu movimento DevOps continua meia boca.
  3. Se você não evidencia como a sua TI está cada vez mais preparada para suportar hipóteses de negócio do conceito à produção, o seu movimento ainda estará meia boca.

O Método Kanban para acelerar Implantações DevOps

O método Kanban tem no seu núcleo as ferramentas conceituais para você acelerar a sua iniciativa DevOps.

Ele se baseia no mecanismo de mudanças evolucionárias, i.e, pequenas mudanças que são aplicadas continuamente sobre um sistema de trabalho para aumentar a robustez desse sistema.

O método Kanban possui seis práticas genéricas. Todas elas são úteis para implantação DevOps, mas destaco três aqui nessa postagem.

1. Gestão do fluxo

O fluxo é o movimento do seu  trabalho de TI (demandas, projetos, incidentes, erros). O método Kanban diz que devemos gerenciar o trabalho através de entregas previsíveis e suaves. E sempre usar dados para medir a sua maturidade.

Essa prática Kanban está profundamente conectada com o primeiro caminho do DevOps. E uma métrica central do sistema Kanban, o Lead Time, pode te ajudar claramente a mostrar a eficiência de sua implementação DevOps.

Quando medimos continuamente o Lead Time e a variabilidade dessa medida em nossas implantações DevOps, você passa a ter uma ferramenta poderosa para mostrar valor e agilidade de negócio de forma concreta. No wishful thinking!

Como exemplo, pude acompanhar uma empresa que reduziu o seu lead time das demandas de 30 para 20 dias ao longo de alguns meses com a introdução consistente de estressores DevOps no seu sistema de trabalho. Até o mais céticos dos gerentes envolvidos deu o braço a torcer.

2. Laços de Feedback

O método Kanban estimula que tenhamos cadências específicas para avaliar a nossa maturidade, sempre dirigidas por dados. Essas cadências promovem a colaboração entre as pessoas, aprendizado e melhorias.

Por exemplo, em reuniões como a retrospectiva de time discutimos como está a nossa previsibilidade das nossas demandas, variabilidade do tempo de entrega e taxa de defeitos. Com isso, podemos avaliar, periodicamente, se as nossas ações tecnológicas e ferramentas estão ajudando o nosso sistema a fluir. A colaboração aumenta e isso é pilar central para a criação de uma cultura DevOps.

3. Políticas explícitas

Quando encontramos um sistema de trabalho ruim, podemos descobrir e introduzir políticas que nos ajudam a reduzir as fragilidades nesse sistema.

Por exemplo, pense em algumas dessas ideias DevOps:

  • Revisões por pares;
  • Git Merge Requests;
  • Automação de testes de unidade
  • Critérios de aceite para promoção de builds;
  • Testes de estresse na infraestrutura.

Essas ideias podem ser representadas no sistema Kanban a partir de políticas de trabalho. Essas e outras políticas podem ser introduzidas sob demanda para eliminar as fraquezas no seu ambiente e criar um organismo cada dia mais forte.

Como um outro exemplo, pude acompanhar um time com baixa maturidade de arquitetura e qualidade que avaliou as fragilidades o seu sistema de fluxo e introduziu uma política de revisão obrigatória do código por pares. Essa política, tornada obrigatória pelo próprio time, conseguiu trazer estabilidade para as decisões arquiteturais e iniciar o pagamento da dívida técnica que esse time introduziu ao longo de seis meses de trabalho indisciplinado. O sistema Kanban ajudou o time a implementar a política e medir o efeito prático dessa política no lead time e taxa de defeitos em produção.

Resumo – Esteróides Naturais

Assim como o hormônio do crescimento ou a testosterona, anabolizantes naturais que ajudam humanos a se tornarem mais fortes e resilientes, podemos pensar que o sistema Kanban introduz formas legítimas de você melhorar a sua implementação DevOps.

Times DevOps que introduzem práticas Kanban no seu sistema de trabalho tem muito mais chance de sucesso. Eles reduzem a resistência à mudança, trabalham em práticas que fazem sentido no seu contexto, criam hipóteses de melhoria dirigidas pelo pensamento científico e operam sob o manto da antifragilidade.

 

 

Trilhando a sua jornada DevOps

Tivemos o privilégio de acompanhar nessa semana o primeiro DevOps Days Belo Horizonte. Lotação esgotada, excelentes palestras e muitas trocas de experiência. Definitivamente, o tema DevOps está nos corações e mentes de muitos profissionais de TI pelo Brasil afora.

E como boa coincidência, tivemos nesse mês a publicação do relatório State of DevOps Report 2018 do instituto de pesquisa e avaliação DevOps – o DORA. Ele trouxe nessa edição um modelo evolucionário para o aumento da sua maturidade DevOps. E esse modelo foi compilado através da análise do que milhares de empresas tem feito por todo o planeta. Faço um resumo do relatório abaixo para ajudá-lo a desenhar a sua jornada DevOps.

vladislav-babienko-703701-unsplash.jpg
A sua jornada para o mundo DevOps

Estágio 0 – Construir a Base

A análise dos dados da pesquisa do estado de DevOps de 2018 revelou as práticas fundamentais empregadas pelas equipes bem-sucedidas. Essas práticas se correlacionam tão fortemente com o sucesso do DevOps que o instituo DORA recomenda que elas são essenciais em todos os estágios do desenvolvimento do DevOps. Em outras palavras, as práticas que devem ser adotadas em qualquer estágio para progredir para o próximo estágio permanecem importantes até mesmo para aquelas organizações que evoluíram mais longe em sua jornada DevOps e que já mostraram o maior sucesso.

As práticas fundamentais estão listadas abaixo:

  • O monitoramento e alertas são configuráveis ​​pelas equipes que operam o serviços em produção. 
  • Os padrões de implantação para a criação de aplicativos ou serviços são reutilizados.
  • Os padrões de teste para a criação de aplicativos ou serviços são reutilizados.
  • As equipes contribuem com melhorias nas ferramentas fornecidas por outras equipes.
  • As configurações são gerenciadas por uma ferramenta de gerenciamento de configuração.

Estágio 1: Normalize a pilha de tecnologia

A maioria das organizações que usam grandes quantidades de tecnologia está lidando com muita complexidade, diminuindo seus esforços para avançar nos negócios. Portanto, não é surpreendente que os primeiros esforços em uma transformação DevOps
(ou qualquer tipo de transformação de negócios) se concentraria na redução da complexidade.

As duas práticas que definem o estágio 1 funcionam para reduzir a complexidade:
• As equipes de desenvolvimento de aplicativos usam controle de versão.
• Equipes fazem a implantação de aplicações em um conjunto padrão de sistemas operacionais.

Estágio 2: Padronize e reduza a variabilidade

No estágio 1, vemos organizações normalizando suas tecnologias
e processos. Quando chegam ao estágio 2, as organizações já começaram o processo de padronização de um conjunto de tecnologias; configurações de aplicativos separados dos dados, uso consistente de controle de versão e também um processo consistente para testes de infraestrutura e um padrão de compartilhamento de código-fonte.

No estágio 2, as organizações estão trabalhando para padronizar e reduzir a variabilidade, um tema que prevalece em todos os estágios da evolução do DevOps.

Toda organização tem variação, que pode derivar de várias causas diferentes, incluindo:
• Adoção de novas tecnologias para substituir muitas funções de tecnologias antigas. E ao mesmo tempo, as tecnologias mais antigas nunca são removidas.
• Produtos caseiros que não seguem padrões comuns do setor e não possuem interfaces comuns.
• Uma proliferação de ferramentas que se sobrepõem e não foram racionalizadas.
• Fusões e aquisições, que trazem ainda mais tecnologias legadas para casa.

No estágio 2, a reutilização de tecnologias e padrões se torna importante. Isso leva os times de Dev e  Ops a colaborar e tomar decisões de arquitetura que afetam a capacidade de implementação e testabilidade dos aplicativos. Por causa do direcionamento para esses padrões comuns, as equipes começam a inventar maneiras de aumentar a velocidade na adoção de padrões e reduzir ainda mais a variação. Isso impulsiona a inovação no nível de equipe para otimizar processos e fluxos de trabalho em torno das pilhas de tecnologia abençoadas.

Um antipadrão primário a ser observado neste estágio é que cada equipe se normalize em seus próprios padrões. Isso levará a um maior grau de variação global e é exatamente a direção errada.

Em essência, as práticas de definição para o estágio 2 são:
• Construa em um conjunto padrão de tecnologias.
• Implante em um sistema operacional padrão único. (ou em um conjunto mínimo, se um apenas não for possível)

Os principais benefícios da organização dos padrões e tecnologias de uma equipe de TI são:
• Velocidade de entrega mais rápida.
• Mais flexibilidade para a equipe de desenvolvimento trabalhar em novos aplicativos, serviços ou componentes.
• Área de superfície reduzida para vulnerabilidades de segurança.
• Menos partes móveis para manter, atualizar e aprender. E isso reduz a complexidade essencial e acidental.

Etapa 3: Expandir as práticas do DevOps por toda a TI e além

Os estágios 1 e 2 reduzem a complexidade geral da pilha de tecnologia para que as equipes possam obter resultados mais repetitivos com variação limitada. O estágio 3 é sobre a expansão das práticas de DevOps para o grupo mais amplo de equipes de TI e prestação de serviços.

No estágio 3, as práticas de DevOps se espalham para além das equipes de desenvolvimento e operações, onde primeiro criaram suas raízes. À medida que a colaboração aumenta e a organização se concentra em melhorias em torno do gerenciamento de serviços, implantação, redução de tempos de espera e minimização de aprovações, esses esforços afetam as áreas além dos departamentos de tecnologia. O compartilhamento de ferramentas, aplicativos e serviços aprimorados – assim como o conhecimento – com outras áreas funcionais da empresa agora se torna fundamental para expandir o sucesso anterior do DevOps e dimensionar o DevOps em toda a organização.

As pesquisa do instituto DORA mostraram que o estágio 3 é onde as iniciativas de DevOps mudam de pequenos grupos de sucesso em algumas equipes para uma onda que se espalha e eventualmente transforma toda a organização.

Foi também observado em achados do grupo que o Estágio 2 (reduzindo a variação
na pilha de tecnologia) e a Etapa 3 pode ocorrer em ordem direta, em ordem inversa ou ao mesmo tempo. Mas ambos precisam acontecer antes de progredir para o estágio 4 (automatizar a entrega da infraestrutura).

Ou seja, faz mais sentido concentrar-se na redução da variabilidade nos estágios iniciais, de modo que haja menos ocorrências para gerenciar, economizando tempo e distração de sua equipe. Mas se isso não for possível porque algumas dessas coisas estão fora do seu controle, trabalhe primeiro nas coisas que você pode controlar. O mais importante é que a equipe de gerenciamento de serviços de TI e quaisquer outras equipes que dependem de serviços trabalhem juntas durante esse estágio.

As práticas definidoras no estágio 3 são:
• Os indivíduos tem autonomia para poder trabalhar sem aprovação manual de fora da equipe (ex. gerentes e áreas de negócio). E isso foi alcançado através da confiabilidade obtida na busca das práticas do estágio 2.
• Padrões de implantação para criar aplicativos e serviços são reutilizados.

Outras práticas importantes para estágio são:

• Os indivíduos conseguem fazer alterações com tempos de espera reduzidos (lead times).
• Mudanças de serviço podem ser feitas durante o horário comercial.
• Revisões pós-incidente ocorrem e os resultados são compartilhados.
• Equipes constroem código em um conjunto padrão de tecnologias.
• Equipes usam integração contínua.
• As equipes de infraestrutura usam também controle de versão.

Etapa 4: Automatizar a entrega da infraestrutura

O estágio 4 é onde as equipes de infraestrutura estão no centro da atenção. As práticas definidoras neste estágio são sobre automatizar a entrega de infraestrutura – o que muitos pensam como o início de uma iniciativa de DevOps.

Essas práticas de automação de infra-estrutura aparecem mais tarde na jornada evolucionária do que podemos esperar. Isso porque são ativadas por coisas que caracterizam estágios anteriores: normalização, redução de variáveis ​​e expansão da evolução do DevOps para além das equipes de tecnologia nos negócios. Sucesso em estabelecer esses fatores em estágios iniciais torna muito mais fácil alcançar o sucesso no Estágio 4.

E  isso não quer dizer que a automação de infraestrutura não está acontecendo em estágios anteriores. Já no Estágio 0: Construir a base, a prática de gerenciar configurações de infraestrutura com uma ferramenta de gerenciamento de configuração rapidamente se instala desde o início, quando as equipes de operações estão buscando padronizar para resolver suas próprias necessidades.

A principal diferença no estágio 4 é que o objetivo de conduzir a automação de infraestrutura nesse estágio é proporcionar maior agilidade a todo o negócio, não apenas para uma única equipe.

Embora esse estágio seja gratificante – parece que você está realmente fazendo o DevOps agora – é importante reconhecer que os estágios anteriores possibilitam a automação da infraestrutura. O instituto DORA viu organizações tentando saltar imediatamente para este
estágio sem passar pelos estágios anteriores. E o resultado é a frustração. É preciso que essas organizações demorem mais do que o esperado para fazer qualquer progresso real com a automação da infraestrutura.

As equipes de infra-estrutura nesse estágio da jornada de DevOps começam a adotar práticas de desenvolvimento ágil, como o uso de controle de versão para configuração do sistema e configurações de aplicativos, e adotam ferramentas usadas pelas equipes de desenvolvimento de aplicativos. As equipes, nesse estágio, também automatizam as configurações de políticas de segurança dentro de sua esfera de influência.

As práticas centrais para o estágio 4 são:
• As configurações do sistema são automatizadas.
• O provisionamento é automatizado. 

E algumas práticas associadas são:
• Configurações de aplicativo estão no controle de versão.
• As equipes de infraestrutura usam o controle de versão.

Estágio 5: Fornecer recursos de autoatendimento

Para passar para o Estágio 5, uma organização deve ter os seus vários departamentos comprometidos em fornecer recursos de TI como um serviço para a empresa, em vez de tratar a TI como um centro de custo que executa ordens de serviço. Esses departamentos incluem desenvolvimento, qualidade, operações, segurança, ITSM e outras áreas funcionais.

Neste último estágio da evolução do DevOps, os benefícios para a organização multiplicarem-se enormemente à medida que a colaboração bem-sucedida entre os limites funcionais se acelera.

Esses ganhos são vistos em várias áreas distintas:
• A arquitetura de aplicativos vai além da padronização de tecnologias e começa a evoluir no sentido de trabalhar e suportar a migração na nuvem, a adoção de contêineres e a proliferação de microsserviços.
• A automação da política de segurança passa de atender as necessidades de uma equipe para se tornar a linha de base de como a segurança e a conformidade são medidas em todo o departamento, ou mesmo em toda a organização. Além disso, o provisionamento automatizado avança para o provisionamento de ambientes completos para desenvolvedores, testadores e outras equipes técnicas.

Uma vez que você comece a ter sucesso em múltiplos limites funcionais, os pilares do DevOps – (CAMS) Cultura, Automação, Mensuração e Compartilhamento – tornam-se mais difundidos em toda a organização.

As duas práticas de definição para o estágio 5 são:
• Respostas a incidentes são automatizadas.
• Recursos de TI (ex. máquinas ou conteineres) estão disponíveis via autoatendimento.

As duas práticas associadas neste estágio são:
• Aplicativos de arquitetura com base nas necessidades de negócios.
• As equipes de segurança estão envolvidas no design e na implantação de tecnologia.

Resumo do relatório

Em resumo, os dados coletados pelo instituto DORA mostraram que embora existam muitos caminhos individuais por meio de uma transformação DevOps, há maneiras de atingir e dimensionar o sucesso mais rapidamente. As organizações têm uma escolha: elas podem escolher ser sistemáticas sobre como elas evoluem ou podem adotar uma abordagem mais dispersa. É claro que é possível que até mesmo uma abordagem ad-hoc funcione, mas o que foi observado nas organizações que atingiram os níveis mais altos da evolução do DevOps é que elas não chegaram lá por acaso.

O Todo Poderoso Gráfico do Fluxo Cumulativo de Valor

Figuras brilhantes da administração moderna, como Peter Drucker, já diziam que é inútil tentar gerenciar um sistema de trabalho sem um sistema consistente de medições e métricas. Se você já trabalha com métodos ágeis isso é ainda mais importante pois métodos ágeis são baseados nos princípios de transparência radical, feedbacks e replanejamentos contínuos. Sem números apropriados, não conseguimos avançar na maturidade do uso de métodos ágeis.

Felizmente, existe um gráfico simples e superpoderoso que pode ser facilmente usado por times ágeis. Esse gráfico lhe dará muitas informações valiosas, tais como:

  1. A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.
  2. O tempo médio que o seu sistema de trabalho demora para processar um novo pedido ou requisito. (lead time ou tempo de atravessamento).
  3. O tempo médio que cada papel ou área do seu sistema de trabalho demanda para processar novos itens. (cycle time ou tempo de ciclo).
  4. A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).
  5. Observar mudanças de escopo ao longo do tempo
  6. Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)
  7. Observar gargalos
  8. Estimar quando o seu projeto irá terminar

Ferramentas normalmente usadas por times ágeis, como por exemplo o Microsoft VSTS/TFS, JIRA Agile, Redmine ou o Trello com plugins, já constroem automaticamente esse gráfico e liberam o nosso tempo para a análise intelectual das informações. Ao mesmo tempo, você pode criá-los em ferramentas de planilhas simples como o Google Sheets ou o Excel. Irei fazer isso ao longo desse post para que você possa entender como construir e interpretar esse gráfico.

Construindo o Gráfico do Fluxo Cumulativo de Valor

O nome do nosso super-gráfico é fluxo cumulativo de valor e é também chamado de CFD ou Burn-Up.

Os passos essenciais para a construção desse gráfico são:

  1. Decidir que tipo de informação será medida.
  2. Decidir a frequência da análise.
  3. Decidir que etapas do fluxo de valor serão medidas.

Vamos trabalhar com um primeiro exemplo onde queremos analisar os incidentes que são atendidos por uma área de suporte de um produto. A nossa análise nesse exemplo será semanal e iremos analisar as seguintes etapas:  novos incidentes, incidentes em tratamento e incidentes fechados.

Primeiro monte uma tabela com as informações dos incidentes em cada estado ao longo de cada semana.

Captura de Tela 2018-09-09 às 11.02.39.png

Depois você deve somar os dados em cada semana, i.e, em cada semana iremos ver todos os incidentes naquele estado. Na semana 2, portanto, teremos 17 incidentes no estado aberto, 10 em execução e 7 fechados. Isso irá gerar uma planilha simples conforme mostrado abaixo.

Captura de Tela 2018-09-09 às 11.02.46

Agora iremos representar isso visualmente em um gráfico de área 2D (Area Chart Non Stackable no Google Sheets ou Área 2D no Excel). O resultado abaixo será mostrado.

chart

 

Extraindo Informações do Gráfico Cumulativo de Valor

Vamos agora interpretar as informações trazidas por esse gráfico.

A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.

O primeiro fato a ser extraído do gráfico é como o seu sistema de trabalho está se comportando conforme o seu fluxo de valor, que é a coleção de etapas ou estados através dos quais podemos observar o sistema de trabalho.

Podemos observar que nas 4 primeiras semanas tivemos 52 incidentes abertos, 33 itens em execução e 19 fechados. Já na semana 6 observamos 78 itens abertos, 51 em execução e 40 itens fechados. E isso indica que o sistema na semana 6 está menos saudável que na semana 4 pois existe um acúmulo maior de itens nos estados aberto ou em execução. Colocado de outra forma, podemos ver que na semana 4 existe um acúmulo de 33 itens (52 itens abertos – 19 itens fechados). Já na semana 6 temos 38 itens acumulados (78 itens abertos – 40 itens fechados).

Se observamos a figura, podemos observar como a barriga da área azul. Visualmente podemos ver que a barriga na semana 6 se tornou maior que a barriga da semana 4. E isso indica que a saúde do sistema piorou.

Sistemas de trabalho saudáveis devem manter conseguir processar itens em taxas similares às suas chegadas. Isso evita filas, troca de contexto e defeitos no processamento de pedidos, requisitos, demandas ou encomendas.

O tempo médio de processamento de pedidos (lead time ou tempo de atravessamento)

Um dos motivos que leva a que métodos ágeis tenham esse nome é que eles buscam garantir que um pedido aberto não fique muito tempo dentro do seu sistema de trabalho, i.e., um novo pedido ou requisito deveria ser rapidamente construído, verificado e liberado para os seus clientes. Chamamos essa métrica global de tempo de atravessamento ou lead time.

Vamos examinar como o lead time pode ser examinado pelo gráfico do fluxo cumulativo de valor. Ele pode ser lido através da diferença horizontal entre os itens fechados e os itens abertos.

Captura de Tela 2018-09-09 às 11.38.25.png

Por exemplo, na semana 5 estamos vendo que os itens fechados correspondem aos itens que foram abertos na semana 2. O lead time da semana 5 está perto de 4 semanas, que indica que um incidente fica perto de um mês no seu sistema antes de ser finalizado.

Se observarmos a semana 10, vemos um o sistema ficou ainda menos saudável.  Os itens fechados na semana 10 foram abertos entre a semana 5 e a semana 6, que indica que o lead time médio agora está em cerca de 4 semanas e meia.

Nos métodos ágeis, buscamos minimizar o lead time. Quanto menor o lead time, mais rápida é a capacidade do seu time de processar pedidos. E portanto a medição do lead time é em minha opinião a mais importante métrica a ser observada em sistemas baseados em métodos Scrum, Kanban e afins.

O tempo médio de processamento de pedidos por papel ou área (cycle time)

Se o lead time mostra o tempo total de atravessamento no nosso sistema de trabalho, podemos usar o mesmo racional para examinar como uma etapa do trabalho (papel ou área) está se comportando. Considere o gráfico abaixo como exemplo.

Captura de Tela 2018-09-09 às 11.54.21.png

Aqui estamos observar o tempo de ciclo da etapa de execução, i.e, o tempo médio que um incidente demorou para ser efetivamente resolvido uma vez que ele começou a ser tratado pela equipe. Podemos ver que o tempo de ciclo na semana 5 era de um pouco mais de 1 semana. Já na semana 10 o tempo de ciclo já era de 3 semanas, indicando que o time de execução claramente não está conseguindo liberar incidentes na mesma taxa que eles estão chegando.

Veja ainda que o tempo de ciclo pode ser analisado em outras etapas. Por exemplo, no gráfico abaixo podemos observar o tempo de ciclo da etapa de Novos Incidentes.

Captura de Tela 2018-09-09 às 12.02.14.png

Aqui podemos ver que na semana 3 um incidente demorava, em média, uma semana e meia até começar a ser tratado pelo time. Já na semana 10 um item ficava aberto quase 4 semanas até começar a ser tratado pelo time.

Longos tempos de ciclo para uma etapa indicam que a área associada aquele trabalho está com dificuldades. E isso indica que a gestão deve buscar formas de apoiar aquele time para reduzir nos gargalos. Ao invés de permitir a chegada de novos itens de foram desenfreada (ilusão de controle) ou fazer ameaças (management 1.0) a gestão ágil deve promover enxames de ajudantes de outras áreas e funções para desafogar o time com dificuldades e com isso reestabilizar o sistema.

A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).

Esse gráfico é tão legal que podemos observar também como os itens estão se acumulando no sistema de trabalho. A isso chamamos de trabalho em progresso ou WIP (Work In Progress). Valores altos do WIP indicam que o seu sistema não está saudável pois indica que as pessoas estão tentando fazendo muita coisa ao longo de uma semana. Isso leva a interrupções no trabalho, trocas de contexto e esgotamento mental pelo seu time.

No gráfico abaixo, podemos observar que o WIP da semana 10 é claramente pior que o WIP da semana 02, mostrando como o sistema está se degradando ao longo do tempo.

Captura de Tela 2018-09-09 às 12.09.16.png

De fato, se você observar os dados da planilha fornecida no exemplo você irá observar que o WIP da semana 02 era de 19 itens (26 – 7). Já o WIP na semana era de 37 itens (119 – 72).

Observar mudanças de escopo ao longo do tempo

Vamos considerar o contexto de um time que precise construir um produto e fez um levantamento inicial dos requisitos do produto. Esse time trabalha em um fluxo de valor com os estados: Backlog, Em Análise, Em desenvolvimento, Em testes, Em homologação e Fechado.

O gráfico mostrado abaixo mostra que houve um intenso esforço na descoberta de requisitos nas semanas 2 e 3. E o gráfico também mostra que houve mudanças de escopo ao longo da semana 8 (12 novos itens surgiram). E se o projeto foi baseado em premissa de escopo fechado, isso indica um sinal gerencial amarelo que sinaliza que novos sprints talvez sejam necessários para completar o escopo recem-descoberto.

Captura de Tela 2018-09-09 às 13.34.42.pngObservar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)

Podemos observar ainda um aspecto bem importante na saúde de um sistema que é a sua vazão, ou taxa de produção de itens no tempo. Por exemplo, considere o seguinte gráfico.

Captura de Tela 2018-09-09 às 13.41.45.png

Explicitei nesse gráfico a vazão dos responsáveis pelo desenvolvimento nas semanas 4, 5, 6 e 7. Observe que quanto maior a inclinação da seta, maior é a vazão. E então podemos observar que o time de desenvolvimento teve um problema mais sério entre a semana 5 e 6. A inclinação da seta aqui está muito baixa nesse região do gráfico. Talvez algum dos desenvolvedores tenha sido alocado em outro projeto ou algum aspecto técnico da arquitetura ainda não explorado do produto tenha surgido e atrasado o trabalho de todos eles.

A análise da vazão ao longo de cada etapa é um instrumento importante para o Scrum Master, Agile Coach e time analisar a saúde e estabilidade do sistema de trabalho.

Observar gargalos

Um outro superpoder desse gráfico é permitir que você analise gargalos. E para isso vamos habilitar as linhas de tendência das etapas inicial e final desse sistema de trabalho (novos requisitos no backlog e requisitos fechados). As linhas de tendência são criadas pela opção Trend Lines no Google Sheets e Excel e são observadas pelas linhas vermelha e preta nesse exemplo.

Captura de Tela 2018-09-09 às 13.56.38.pngSe a inclinação das linhas é igual isso indicaria que o sistema está saudável. No caso aqui, estamos vendo que a inclinação da linha vermelha é maior que a inclinação da linha preta. E isso indica que mais itens estão chegando do que itens saem do sistema de trabalho.

Podemos fazer essa análise comparando quaisquer duas etapas (ex. desenvolvimento versus testes ou análise versus testes), para todo o intervalo de tempo ou para um período de análise. As inclinações das retas nos permitem analisar se gargalos estão sendo formados.

E se você observar um gargalo, é o momento de ligar um sinal amarelo e analisar como podemos pensar coletivamente e apoiar área que está apresentando dificuldades.

Estimar quando o seu projeto irá terminar

Por último, mas não menos importante, esse gráfico lhe dá também uma oportunidade de estimar quando o projeto provavelmente irá terminar.  Vamos considerar o gráfico mostrado abaixo, onde explicito a quantidade de itens fechados ao longo do tempo e também a quantidade de itens que devem ser realizados ao longo do projeto.

Captura de Tela 2018-09-09 às 14.07.07.png

Uma heurística simples que podemos usar aqui é a regra de três sobre os itens fechados até o momento. No nosso exemplo temos 28 itens que foram fechados em 10 semanas. E como temos 117 itens a serem realizados, o tempo total para finalizarmos todos os itens no escopo seria calculado como: 117/28 *10 = 41 semanas.

Essa abordagem, pois mais simplista que pareça, trabalha com o princípio básico que a velocidade passada é um excelente preditor da velocidade futura em um sistema. E isso se torna cada vez mais verdade quando você tem um bom número de observações ao longo do tempo.

Erros Comuns no uso do Fluxo Cumulativo de Valor

Embora esse gráfico seja extremamente poderoso, devemos ter atenção a alguns pontos para não usarmos a ferramenta de forma errada. Alguns erros incluem:

  1. Começar com um fluxo de valor complexo. Recomendo começar com um fluxo simples (A Fazer, Em execução, Finalizado) e incluir mais estados a medida que você e o seu time se acostumarem com o instrumento.
  2. Possui uma definição fraca de Finalizado. Finalizado é algo que está pronto para os seus usuários finais. Se você trabalha com entrega de livros, Finalizado significa que o seu livro está na casa do seu cliente. Se você trabalha com uma cozinha, Finalizado significa que o seu cliente está almoçando o prato que ele pediu há 30 minutos atrás. E se você trabalha com desenvolvimento de software, Finalizado implica que o aquela funcionalidade está nas mãos dos seus usuários no ambiente de produção.
  3. Não possuir Critérios de Aceite para mover um item ao longo do fluxo de valor.  É fundamental que o time defina critérios objetivos que permitam avaliar se um item pode transitar de um estado para outro no fluxo de valor. Isso evita falsos positivos e a maquiagem de dados.
  4. Não comunicar o gráfico. Esse gráfico deve ser afixado em base periódica nas paredes do local de trabalho do seu time ou exibido na TV da sua sala. Esconder esse gráfico em alguma planilha obscura na rede não irá ajudar ao seu time, nem você.
  5. Ter uma frequência baixa de atualização. O poder do gráfico cumulativo de valor vem das interpretações que conseguimos obter das medidas ao longo do tempo. (WIP, Lead Time, Taxas e Gargalos). E isso depende de um ciclo de amostragem regular. Recomendo um ciclo mínimo de uma semana. mas se você coletar os números em base ainda menor você terá insumos ainda melhores.
  6. Adotar esse gráfico apenas para  um único tipo de informação. Todo sistema complexo deve ser examinado em diferentes níveis. E cada nível  lhe dar perspectivas diferentes de análise. Por exemplo, na construção de produtos podemos analisar Épicos, Features ou Histórias. E podemos ter gráficos CFD para cada um desse itens, que permite que você observe a saúde do sistema em níveis distintos e possa extrair interpretações mais robustas.

“Don’t look with your eyes, look with your feet. Don’t think with you head, think with your hands.“ – Taiichi Ohno


A planilha mostrada nesse exemplo está compartilhada aqui para seus estudos sobre o CFD.

Organizando o Trabalho em Squads – Morrem os projetos e nasce o fluxo contínuo de produtos

Na maioria das empresas que possuem áreas de TI, existe uma dicotomia muito bem estabelecida entre pessoas que entregam produtos de software através de projetos e pessoas que sustentam esses softwares, cuidando das manutenções corretivas, adaptativas e pequenas demandas evolutivas.

Muitas pessoas que trabalham na TI nunca viram um outro modelo e acreditam que isso é a forma natural de organizar o trabalho.  Se você é uma dessas pessoas, pare e pense na consequência desse desenho organizacional. Provavelmente você deve lidar com alguns problemas tais como:

  • Os seus times de projetos nunca se tornam especialistas em anda pois eles estão continuamente mudando de assunto devido a orçamentação centrada em projetos e a consequente alocação e deslocação das pessoas dos projetos tão logo eles terminem.
  • Os times de projetos são incentivados a entregar seus projetos no prazo, custo e com o escopo acordado. E ao tentar fazer isso, eles são naturalmente incentivados a “flexibilizar” a qualidade do produto. “Testes de unidade automatizados? Não tenho tempo para isso. Código limpo? Então. Também não tenho tempo. BDD. Nem pensar.. estou atrasado!”.
  • A área de projetos não se responsabiliza pela qualidade do produto. Como o seu papel é entregar software o mais rápido possível nos ambientes de produção. a qualidade é “problema” da sustentação e da infraestrutura.
  • Existe um gasto enorme de dinheiro com incidentes em sustentação. Acompanho empresas com TIs enormes e ainda fico impressionado com o montante financeiro gasto em incidentes e defeitos.
  • Começam a surgir conflitos entre times de desenvolvimento, times de sustentação e times de infraestrutura. Dedos são apontados de lado a lado e as atribuições de culpa pelos software de baixa qualidade pipocam. O desenho da organização, e não as pessoas, cria esse conflito.
  • Existem times distintos que alteram o código fonte do produto e isso provoca a criação de complexidade acidental na forma de branches desnecessários, sistemas de lotes e filas, que reduzem o tempo total de entrega e baixa a percepção de valor para os usuários finais.

 

As Squads como alternativas para a cultura projetizada

photo-1523266433356-91a22e6f18ed.jpeg

Uma Squad deve ser estruturado como um time coeso que esteja alocado no desenvolvimento e sustentação de um produto ou fluxo de valor de uma organização. Ao fazer isso você redesenha o sistema tático da sua TI e provoca o seguinte:

  • Todos são agora responsáveis pela qualidade. Se você codificou mal e não testou, é sua responsabilidade. E você vai pagar por isso daqui a algumas semanas em produção. Quando você, enquanto líder, desenha a sua cozinha para fazer com que os cozinheiros comam a comida que eles estão cozinhando, você muda a percepção deles sobre o impacto dos atalhos.
  • Não existem mais dedos apontados para fora. A Squad, inclusive com o seu líder, é responsável pelos eventos que ocorrem. Incidentes vão ocorre, obviamente, mas é papel da Squad rodar suas retrospectivas para lidar com o aprendizado e melhorar continuamente.
  • O aprendizado e a produtividade aumentam. Se você mantém pessoas juntas durante um longo tempo com ritos kaizen periódicos, isso habilita o aprendizado organizacional e com isso a produtividade desses times na implementação de novas funcionalidade.
  • Você incentiva o estabelecimento da cultura de times. Times são estruturas poderosas para lidar em ambientes complexos. Atribuir metas a times e reforçar a cultura de times promove um senso de equipe e permite também atenuar as nossas fraquezas individuais.

Squads sim, mas do jeito correto

photo-1508591360875-10163ed98c8e

O conceito de fluxo contínuo de valor é fundamental para implementarmos Squads da forma correta. E isso significa que:

  • Você tem um PO e pessoas da área de negócio que estão permanentemente priorizando o que é valor de negócio. Fixar o escopo por 6 meses porque o gerente mandou não é mais a forma apropriada de trabalhar. Ao invés, você tem um backlog que é permanentemente repriorizado e o item de maior valor é puxado pelo time quando o item que estava em trabalho foi entregue em produção. No Lean, chamamos isso de sistemas puxados (Pull Systems).
  • Você deve medir continuamente o retorno de valor de negócio trazido pela sua Squad. E isso é fundamental para avaliar se o investimento que está sendo realizado na sua Squad faz sentido. E, na prática, se o seu produto de negócio ou fluxo de valor não tem tração no mercado, a Squad é reduzida ou desmobilizada.
  • Você deve entregar em produção em ciclos curtos. Entregas semestrais ou anuais em produção, portanto, não fazem mais sentido. E portanto os “itens” de trabalho, na forma de histórias ou features, devem ser pequenos. Idealmente, cada história deveria caber em uma semana (ou duas). E as tarefas do time devem ser estruturadas em não mais que 6 horas diária. No mundo Toyota/Lean, chamamos isso de “One Piece Flow” e foco implacável no “Lead Time”.
  • A qualidade contínua se torna parte do processo. Para isso, você usa técnicas diversas hoje estruturadas em corpos de conhecimento DevOps tais como: Automação de Testes de Unidade, Automação da Verificação do Código, Smoke Tests, Automação de Builds, Integração Contínua e Entrega Contínua. Esses conceitos DevOps são a forma moderna da TI implementar o conceito Lean/Toyota chamado de Jidoka.
  • Qualquer decisão de otimização deve avaliar o efeito sobre todo o fluxo de valor de negócio. Metas locais para o time de testes como remoção de defeitos perdem sentido. E esse também um dos princípios Lean.

Ao fazer isso, você ganha um desenho da sua TI que irá lidar melhor em um mundo complexo, não determinístico e imprevisível.

O Manifesto Ágil das Squads

Se houvesse uma manifesto ágil das Squads, ele seria parecido com isso.

Fluxo de valor e produtos de negócio mais que projetos de software.
Entregas contínuas  mais que longos ciclos de desenvolvimento e homologação.
Qualidade contínua nos produtos de negócio mais que foco míope em prazos.
Otimização do fluxo de valor mais que sub-otimização do trabalho de desenvolvimento, testes ou infraestrutura.

Mas… e o meu escritório de projetos?

Você pode estar pensando. Isso parece legal, mas o meu escritório não me deixa fazer isso.

Confesso que isso realmente é tenso. Em várias implementações que participei, temos que destacar tempo de qualidade para evangelizar o escritório de projetos. E em várias vezes, não funciona mesmo.

O que tenho observado são abordagens diversas para lidar com isso, tais como:

  1. Operar abaixo do radar do PMO (mais conservadora e provavelmente mais inteligente). 

    Quando você tem um PMO arcaico ou resistente, pode ser impossível buscar uma mudança de abordagem. Operar abaixo do radar implica que você possui Squads internamente dentro da sua TI com o propósito de evoluir produtos de negócio, mas a linguagem de comunicação com a empresa e interessados de negócio ainda será a linguagem de projetos. Isso exige que você faça uma prospecção ativa de projetos para conseguir garantir a orçamentação do seu Squad ou de pelo menos uma parte das pessoas do seu Squads.  E isso pode implicar em que sua Squad precise cuidar de mais de um produto para que seja possível financiá-la.

  2. Negociar a orçamentação anual por produtos de negócio, mas estabelecer uma lógica de desembolso centrada em projetos.Nessa abordagem o PMO tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer mudar a lógica de funcionamento de um PMO, que poderia gerar muita resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será investido através de projetos do PMO que irão financiar uma Squad durante esse ano fiscal.Observe que nessa abordagem não basta medir o sucesso financeiro baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e medir o retorno financeiro trazido para a organização no investimento em um produto de negócio. Squads devem ser medidas, primordialmente, pelos resultados de negócio que seus produtos trazem.
  3. Transcender o conceito de projetos, introduzir o conceito de fluxo de valor e orçamentação relativizada e convencer o seu escritório dissoAlgumas empresas  sublimaram o conceito de projetos e trabalham com o conceito de fluxo continuado de valor de negócio. Nessa abordagem você estabelece em base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza os itens mais importantes do bacilo que cabem naquele período de tempo. E você mede periodicamente como foi a agregação de valor de negócio por essa Squad. Se a agregação de valor foi frutífera, você coloca mais investimento naquela Squad. Se os resultados na perspectiva de negócio são ruins, você reduz ou desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido.

    O método ágil em escala organizacional chamado SAFE trabalha com essa   abordagem e tem sido muito usado em algumas grandes empresas para facilitar a transição para esse modelo.

 

Referências Adicionais:

 

“We have minds that are equipped for certainty, linearity and short-term decisions, that must instead make long-term decisions in a non-linear, probabilistic world.”
Paul Gibbons, The Science of Successful Organizational Change: How Leaders Set Strategy, Change Behavior, and Create an Agile Culture

 

 

Os três princípios fundamentais dos métodos ágeis e do DevOps

Muitos times já aprenderam que fazer Scrum não é (apenas) colocar um conjunto de pessoas em uma sala e executar ritos como um planejamento de sprint ou uma retrospectiva. Se observamos por exemplo que o gerente determina as tarefas do time e interrompe as falas de um colaborador que traz uma sugestão, sabemos que não estamos vivendo um ambiente ágil.  É como se estivéssemos observado um animal que possui penas e bota ovos, mas você percebe que não se trata de um pássaro verdadeiro ao olhar a boca dele.

feathered-dinosaur-beipiaosaurus-exhibition-museum-natural-history-vienna-foto-taken-february-th-39609374
Archaeopteryx lithographica

Acompanhei um caso em uma empresa em 2016 onde um determinado analista, muito bem intencionado, me disse que eles possuíam o DevOps muito bem implementado. E então ele me mostrou todo um conjunto de pipelines de gestão de builds e releases implementados no Visual Studio Team System. Ele também me mostrou painéis técnicos dos vários projetos no Sonar Source e muitas estatísticas geradas.

E então eu perguntei como os times estavam usando isso para melhorar suas práticas. E a resposta foi que ele não tinha autorização do seu gerente para buscar intervenções de melhoria nos times. (!?) E mais um bicho estranho me veio à cabeça – um animal com bico de pato, que bota ovos, nada muito bem, mas que não é um pássaro.

1024px-Ornithorhynchus
Ornitorrinco – Platypus Ornithorhynchus anatinus

 

Um dos maiores riscos à adoção do ágil e do DevOps é que as pessoas não compreendam os princípios que levaram à criação dessas práticas. Isso porque os times e os resultados não irão melhorar realmente sem que os princípios fundamentais da agilidade sejam internalizados. E então podemos ter conclusões precipitadas na esfera gerencial que podem levar ao descrédito nos métodos e o retorno ao modo anterior de trabalho.

A Origem dos Princípios Ágeis e DevOps – Sistemas de Produção Lean

Um dos conceitos fundamentais no Lean é o fluxo de valor (Value Streams). Vamos defini-lo primeiro no contexto da manufatura e depois extrapolar como ele se aplica ao DevOps e ao fluxo de valor de TI. Podemos definir o fluxo de valor como “a sequência de atividades que uma organização empreende para atender a uma solicitação do cliente” ou “a sequência de atividades necessárias para projetar, produzir e entregar um bem ou serviço a um cliente, incluindo os fluxos de informação e material.

Nas operações de manufatura, o fluxo de valor é geralmente fácil de ver e observar. Ele começa quando um pedido do cliente é recebido e as matérias-primas são liberadas no chão-de-fábrica. Para permitir tempos de execução rápidos e previsíveis em qualquer fluxo de valor, normalmente há um foco implacável na criação de um fluxo leve e uniforme de trabalho, usando técnicas como pequenos tamanhos de lote e redução do trabalho em progresso (WIP). Buscamos também evitar o retrabalho para garantir que não transmitamos defeitos para as próximas etapas do processo. Finalmente, buscamos otimizar continuamente nosso sistema em direção aos nossos objetivos globais.

Os mesmos princípios e padrões que permitem o fluxo rápido de trabalho em processos físicos são igualmente aplicáveis ​​ao trabalho de tecnologia de informação ou qualquer outro trabalho de natureza de conhecimento. No mundo Agile e DevOps, normalmente definimos nosso fluxo de valor de tecnologia como o processo necessário para converter uma hipótese de negócios em um serviço habilitado por tecnologia que agregue valor ao cliente.

A entrada para o nosso processo é a formulação de um objetivo de negócio, conceito, ideia ou hipótese. El começa quando aceitamos o trabalho em Desenvolvimento, adicionando-o ao nosso backlogde trabalho. A partir daí as equipes de desenvolvimento que seguem um processo ágil ou iterativo típico provavelmente transformarão essa ideia em histórias de usuários e em algum tipo de especificação de recurso, que é implementada em código no aplicativo ou serviço que está sendo construído. O código é então guardado no repositório de controle de versão, onde cada alteração é integrada e testada com o restante do sistema de software.

Como o valor é criado somente quando nossos serviços estão sendo executados na produção, devemos garantir que não apenas fornecemos fluxo rápido, mas que nossas implantações também podem ser realizadas sem causar caos e interrupções, como interrupções de serviço ou deficiências de atendimento a requisitos de performance, segurança e usabilidade, entre outros.

O Foco Implacável no Tempo de Entrega

usain-bolt-atleta-0816-1400x800-3

Em implantações Ágeis DevOps, nossa atenção deve estar no tempo total de entrega dos itens do backlog a até a produção (Lead Time). Esse fluxo de valor começa quando qualquer analista em nosso fluxo de valor verifica uma alteração no controle de versão e termina quando essa alteração é executada com êxito na produção, fornecendo valor ao cliente e gerando feedback útil e telemetria.

Em empresas tradicionais muitas vezes nos encontramos em situações em que os prazos de implantação exigem meses. Isso é especialmente comum em organizações grandes e complexas que trabalham com aplicativos monolíticos muito acoplados, geralmente com ambientes de teste de integração escassos, longos períodos de teste nos departamentos de qualidade, alta dependência de testes manuais e muitos processos manuais de aprovação.

Quando temos longos tempos de implantação, precisamos de super-heróis em quase todos os estágios do fluxo de valor. Podemos descobrir que nada funciona no final do projeto quando integramos todas as alterações da equipe de desenvolvimento, resultando em códigos que não são mais compilados corretamente ou que não passam em nossos testes. A correção de cada problema requer dias ou semanas de investigação para determinar quem quebrou o código e como ele pode ser corrigido e ainda resulta em resultados insatisfatórios para os clientes.

Ao falar de ágil e DevOps, os desenvolvedores recebem feedback rápido e constante sobre seu trabalho, o que permite que implementem, integrem e validem seu código de maneira rápida e independente e com isso implantem o código no ambiente de produção sem efeitos colaterais.

Conseguimos isso verificando continuamente pequenas alterações de código em nosso repositório de controle de versão, realizando testes automatizados e exploratórios e implementando-o na produção. Isso nos permite ter um alto grau de confiança de que nossas alterações funcionarão conforme projetado na produção e que quaisquer problemas podem ser rapidamente detectados e corrigidos. Isso é mais facilmente alcançado quando temos uma arquitetura modular, bem encapsulada e fracamente acoplada, para que as pequenas equipes possam trabalhar com alto grau de autonomia, com falhas pequenas e contidas, sem causar interrupções globais.

De fato, times DevOps desenvolvem um sistema de trabalho que os permitem entregar software em produção em base diária. Exemplos de empresas que publicados relatos impressionantes dessa agilidade de negócio incluem a Amazon, Netflix, WalMart, Target, Nordstorm, Facebook, Adobe e Sony, entre outras.

Mas, afinal, que princípios são esses que permeiam o ágil e o DevOps e o que eles dizem de tão importante?

Yoda_7
“Os três princípios deve você usar para habilitar a força dos métodos ágeis e DevOps”

Princípio #1 – Fluxo Contínuo

No fluxo de valor de TI, o trabalho normalmente flui de Desenvolvimento para Operações. O primeiro princípio demanda o fluxo rápido e suave do trabalho desde o Desenvolvimento até as Operações para entregar valor aos clientes rapidamente. Nós otimizamos esse objetivo global mais que metas locais, como taxas de conclusão de tarefas de desenvolvimento, taxa de correção de testes ou medidas de disponibilidade de operações.

Aumentamos o fluxo tornando o trabalho visível, reduzindo o tamanho dos lotes e os intervalos de trabalho e criando qualidade, evitando que os defeitos sejam transmitidos aos estágios anteriores de trabalho. Ao acelerar o fluxo através do fluxo de valor da tecnologia, reduzimos o tempo de espera necessário para atender às solicitações dos clientes internos e externos, aumentando ainda mais a qualidade do nosso trabalho, tornando-nos mais ágeis e capazes de superar a concorrência.

Nosso objetivo aqui é diminuir o tempo necessário para que as mudanças sejam implantadas na produção e aumentar a confiabilidade e a qualidade desses serviços. Dicas sobre como fazemos isso no fluxo de valor da tecnologia podem ser obtidas a partir de como os princípios do Lean foram aplicados ao fluxo de valor na indústria e incluem:

  • Tornar o trabalho visível;
  • Limitar o trabalho em progresso;
  • Reduzir o trabalho em lotes;
  • Reduzir os repasses;
  • Identificar e limpar impedimentos e
  • Reduzir a dificuldade do trabalho diário.

Princípio #2 – Feedbacks Frequentes

O segundo princípio descreve os mecanismos que permitem feedbacks rápidos da direita para a esquerda em todos os estágios do fluxo de valor. Como exemplo, feedback dos times de operações para implantadores e feedbacks dos analisas de testes para implementadores. O nosso objetivo é criar um sistema de trabalho cada vez mais seguro e resiliente.

Na TI, o trabalho acontece quase inteiramente dentro de sistemas complexos com risco alto de defeitos e paradas em produção. Como na manufatura, geralmente descobrimos problemas apenas quando ocorrem grandes falhas, como uma interrupção de produção em massa ou uma violação de segurança que resulta no roubo de dados do cliente.

Iremos tornar o nosso sistema de trabalho mais seguro através da criação de fluxo de informações rápido, frequente e de alta qualidade em todo o fluxo de valor e em nossa organização, o que inclui feedback frequente entre toas as pessoas e funções. Isso permite detectar e corrigir problemas enquanto eles são menores, mais baratos e mais fáceis de consertar; evitar problemas antes que causem catástrofe; e criar aprendizado organizacional que integramos no trabalho futuro. Quando fracassos e acidentes ocorrem, devemos trata-los como oportunidades de aprendizado, em oposição a uma causa de punição e culpa.

Uma das características que define um sistema complexo é que ele desafia a capacidade de qualquer pessoa de ver o sistema como um todo e entender como todas as partes se encaixam. Os sistemas complexos normalmente possuem um alto grau de interconectividade de componentes fortemente acoplados, e o comportamento no nível do sistema não pode ser explicado meramente em termos do comportamento de cada componente individual do sistema.

Falhas são inerentes e inevitáveis em sistemas complexos. E então devemos projetar um sistema de trabalho seguro onde possamos executar o trabalho sem medo, confiantes de que quaisquer erros serão detectados rapidamente, muito antes de causarem resultados catastróficos como danos aos trabalhadores, defeitos no produto ou impacto negativo no cliente.

Projetar sistemas perfeitamente seguros está além da capacidade de qualquer time, mas podemos tornar mais seguro trabalhar em sistemas complexos quando as quatro condições a seguir são atendidas:

  • O trabalho complexo é gerenciado para que os problemas no design e nas operações sejam revelados;
  • Os problemas são tratados coletivamente e resolvidos, resultando na rápida construção de novos conhecimentos;
  • Novo conhecimento local é explorado globalmente em toda a organização;
  • Os líderes criam outros líderes que continuamente aumentam as capacidades da organização.

Em um sistema de trabalho seguro, devemos testar constantemente nossas premissas de projeto e operação. Nosso objetivo é aumentar o fluxo de informações em nosso sistema de tantas áreas quanto possível, mais cedo, mais rápido, mais barato e com tanta clareza entre causa e efeito quanto possível. Quanto mais suposições possamos invalidar, mais rápido podemos encontrar e corrigir problemas, aumentando nossa resiliência, agilidade e capacidade de aprender e inovar.

No fluxo de valor de TI, muitas vezes obtemos resultados ruins devido à ausência de feedback rápido. Por exemplo, em um projeto de software em cascata, podemos desenvolver código por semanas ou meses e não obter feedback algum sobre qualidade até começarmos a fase de testes – ou, pior ainda, quando lançamos nosso software para os clientes. Quando o feedback é atrasado e pouco frequente, é pouco eficaz para permitir evitar resultados indesejáveis.

No mundo DevOps, o nosso objetivo é criar feedback rápido em todos os estágios do fluxo de valor de tecnologia, abrangendo Gerenciamento, Desenvolvimento, Controle de Qualidade, Segurança da Informação e Operações do Produto. Isso inclui a criação de processos automatizados de criação, integração e teste, para que possamos detectar imediatamente quando uma alteração foi introduzida que nos tire de um estado de funcionamento e implementação corretos.

Também criamos telemetria abrangente para que possamos ver como todos os nossos componentes de sistema estão operando no ambiente de produção, para que possamos detectar rapidamente quando eles não estão operando conforme o esperado. A telemetria também nos permite medir se estamos atingindo nossas metas pretendidas e, idealmente, é irradiada para todo o fluxo de valor, para que possamos ver como nossas ações afetam outras partes do sistema como um todo.

Os loops de feedback não apenas permitem a rápida detecção e recuperação de problemas, mas também nos informam sobre como evitar que esses problemas ocorram novamente no futuro. Isso aumenta a qualidade e a segurança de nosso sistema de trabalho e cria aprendizado organizacional.

O Terceiro Princípio – Aprendizado Organizacional

Enquanto o Primeiro Caminho aborda o fluxo de trabalho da esquerda para a direita e o Segundo Caminho aborda o feedback rápido e constante recíproco da direita para a esquerda, o Terceiro Caminho foca na criação de uma cultura de aprendizagem e experimentação contínua. Esses são os princípios que permitem a criação constante de conhecimento individual, que é então transformado em conhecimento de equipe e organizacional.

Diversas empresas tem aprendido que a formação de times de alta performance depende da promoção da segurança psicológica e do estabelecimento de clareza de propósitos. A segurança psicológica é a crença compartilhada pelos membros de uma equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 

Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em equipes com maior segurança psicológica são menos propensos a sair do Google, são mais propensos a aproveitar o poder de ideias diversas de seus companheiros de equipe, trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes.

Empresas de TI de alto desempenho exigem e promovem ativamente o aprendizado. Em vez de o trabalho ser rigidamente definido, o sistema de trabalho é dinâmico, com os times realizando experimentos em seu trabalho diário para gerar novas melhorias, possibilitadas pela rigorosa padronização dos procedimentos de trabalho e documentação dos resultados.

No fluxo de valor de TI, nosso objetivo é criar uma cultura de alta confiança, reforçando que somos todos aprendizes ao longo da vida que devem assumir riscos em nosso trabalho diário. Ao aplicar uma abordagem científica para a melhoria de processos e o desenvolvimento de produtos, aprendemos com nossos sucessos e fracassos, identificando quais ideias não funcionam e reforçando aquelas que funcionam. Além disso, qualquer aprendizado local é rapidamente transformado em melhorias globais, de modo que novas técnicas e práticas possam ser usadas por toda a organização.

Reservamos tempo para a melhoria do trabalho diário e para acelerar ainda mais e garantir a aprendizagem. Nós constantemente introduzimos estresse em nossos sistemas para forçar a melhoria contínua. Podemos até simularmos e injetamos falhas em nossos serviços de produção sob condições controladas para aumentar nossa resiliência. E ao criar esse sistema contínuo e dinâmico de aprendizado, possibilitamos que as equipes se adaptem rápida e automaticamente a um ambiente em constante mudança, o que, em última análise, nos ajuda a vencer no mercado.

Quando trabalhamos dentro de um sistema complexo, por definição, é impossível prevermos perfeitamente todos os resultados de qualquer ação que tomemos. É isso que contribui para resultados e acidentes inesperados, ou mesmo catastróficos, em nosso trabalho diário, mesmo quando tomamos precauções e trabalhamos com cuidado.

Quando esses acidentes afetam nossos clientes, procuramos entender por que isso aconteceu. A causa raiz é muitas vezes considerada como erro humano, e a resposta gerencial muito comum é “nomear, culpar e envergonhar” a pessoa que causou o problema. E, de forma sutil ou explícita, a gerência sugere que a pessoa culpada cometer o erro será punido. Em seguida, eles criam mais processos e aprovações para evitar que o erro ocorra novamente. No fluxo de valor da TI, estabelecemos as bases de uma cultura generativa, esforçando-nos para criar um sistema de trabalho seguro.

Quando acidentes e falhas ocorrem, em vez de procurar por erro humano, procuramos como podemos redesenhar o sistema para evitar que o acidente aconteça novamente.

Por exemplo, podemos realizar uma análise post-mortem após cada incidente para obter o melhor entendimento de como ocorreu o acidente e definir quais são as melhores contramedidas para melhorar o sistema, evitando de maneira ideal que o problema volte a ocorrer e permitindo uma detecção e recuperação mais rápidas.

O resultado de eliminar a culpa e colocar o aprendizado organizacional em seu lugar é que as organizações se tornam cada vez mais autodiagnosticas e auto aperfeiçoadas, hábeis em detectar problemas e resolvê-las”.

Muitos desses atributos também foram descritos pelo autor Peter Senge como atributos das organizações que promovem aprendizado continuado. No excelente livro chamado A Quinta Disciplina, ele escreveu que essas características ajudam os clientes, garantem a qualidade, criam vantagem competitiva e uma força de trabalho comprometida e motivada.

Resumo dos Três Princípios

Os métodos ágeis e o DevOps não são processos fechados ou um conjunto de ferramentas. Ao invés, eles são uma cultura baseada nos sistemas Lean e que busca reduzir o tempo da entrega de valor em produção, aumentar o feedback entre o time e fornecer um ambiente seguro para experimentações e inovações de negócio.

Ao realizar o seu próximo planejamento de sprint, ao pensar em automações de testes, ao criar pipelines DevOps ou contêineres Docker, pare e pense:

  • Como estou ajudando o meu time a entregar software mais rapidamente em ambiente de produção?
  • Como estou melhorando os feedbacks entre os membros do time e também o time e os nossos clientes?
  • Como o nosso ambiente está ficando mais seguro para habilitar que as pessoas aprendam e melhorem continuamente?

Se você identificou as relações, muito bom! Ajude o seu time a internalizar os princípios ágeis e DevOps e prospere continuamente no aumento da maturidade do Scrum, XP, Kanban e DevOps na sua empresa.

“Are you too busy for improvement? Frequently, I am rebuffed by people who say they are too busy and have no time for such activities. I make it a point to respond by telling people, look, you’ll stop being busy either when you die or when the company goes bankrupt.”
— Shigeo Shingo, Pai do Sistema Toyota de Produção

 

 

O trem ágil chegou! Em qual estação você vai embarcar?

Gosto muito do conceito da difusão de inovações de Rogers, que mostra como inovações são adotadas ao longo do tempo por uma audiência potencial. A figura, reproduzida abaixo a partir do trabalho original de Everett Rogers de 1962, traz a hipótese que existem cinco perfis no ciclo de adoção de uma nova tecnologia, processo ou produto.

curva-de-adoção-de-novos-produtos-receita-x-tempo
Fonte: blog.cicloagenciadigital.com.br

Os dois primeiros públicos, ou mercado inicial, são os perfis desbravadores que experimentam um novo processo, produto ou tecnologia. Se os seus relatos e resultados obtidos forem bons, a inovação vence o abismo e avança para a maioria inicial e com nova confirmação de sucesso ela avança posteriormente para a maioria tardia.

Por curiosidade, comparei a tendência de pesquisa de termos comuns na esfera gerencial como PMBOK, Scrum e Lean. Os resultados estão abaixo mostraram ao longo dos últimos anos uma inversão da procura ao longo dos últimos anos. Os números mostram um que o Scrum ou o Lean trazem mais curiosidade que o PMBOK no Brasil.

Captura de Tela 2018-05-07 às 16.30.03

Fonte: Google Trends

Baseado também no que tenho observado na minha rede de gestores, arrisco dizer que o método ágil já venceu o abismo da incredulidade no Brasil no público gerencial. A aceitação dos métodos ágeis está cada vez maior e mesmo aqueles que ainda não estão usando estão querendo se informar.

Ao mesmo tempo, não devemos confundir métodos ágeis com Scrum. Existem muitos tipos de métodos ágeis e cada empresa pode se beneficiar de um tipo distinto de método para a sua realidade. Não é porque o método ágil venceu o abismo que ele vai ser aceito pela maioria tardia, que é um público muito mais cético.

Para lançar alguma luz nos diversos métodos ágeis, compilei um mapa ferroviário com as linhas onde correm alguns três ágeis populares no mercado.

O mapa está abaixo  e disponível aqui em alta resolução, que você pode baixar e abrir em uma janela própria do seu computador. Eles contém mais de 70 conceitos usados dentro do mundo ágil em escolas diversas de pensamento.

Trem Ágil

Cada linha é representada por uma cor distinta e contém conceitos, papéis ou termos fundamentais para o entendimento daquele trilho. O objetivo é lhe dar um mapa para você navegar no mundo ágil, reconhecer e correlacionar conceitos comuns falados nos corredores e times ágeis de todo o Brasil.

Destaco aqui pontos importantes do mapa:

  • Linha Vermelha – Representa o trem do Scrum, o método mais popular do mercado ágil no Brasil, Aqui você vai encontrar termos como Backlog do Sprint, Planejamento de Sprint, Revisão ou Retrospectiva
  • Linha Amarela – Representa o trem do dono do produto e do desenvolvimento de produtos. Contem termos importantes como Backlog do Produto, VPD, Design Sprint e Design Thinking.
  • Linha Laranja – Representa a metodologia Kanban, que vai além do quadro Kanban. A linha laranja evolui para a linha do Lean, a linha Roxa.
  • Linha Roxa – Representa a linha dos métodos lean e traz conceitos fundamentais como a redução de lotes, redução do tempo de ciclo, teoria de fila e controle empírico de processo.
  • Linha Azul – Representa a linha dos times ágeis e traz ideias poderosas como Squads e o Management 3.0.
  • Linha Preta – Aqui temos a agilidade para dezenas ou centenas de pessoas, chamada de agilidade em escala. Escolhi representar aqui os principais conceitos de um dos métodos mais poderosos para a agilidade em escala no mercado, que é o SAFE.
  • Linhas Verde Escura, Verde Clara e Azul. Se você é de TI, vai gostar dessas linhas. Elas trazem os conceitos de DevOps, Automação de Testes e Arquiteturas Ágeis.

O mapa é uma abstração apenas e deve ser enriquecido ao longo do tempo com novos termos, conceitos e relações. Se você já trabalha com métodos ágeis, sugestões são muito bem vindas.

E como me aprofundo em cada trilha?

Se você quer navegar com mais profundidade por uma dessas trilha, tomo a liberdade de lhe recomendar alguns livros essenciais para iniciar ou reforçar o seu aprendizado em um dos trens do mundo ágil.

Linha Vermelha – Scrum

514ZCPRQ-bL._SX337_BO1,204,203,200_71nHi9Q2t6L._AC_US436_QL65_

Linha Amarela – PO – Dono do Produto

51oQRBYUxeL._SX381_BO1,204,203,200_61K0l8DfyCL._AC_US436_QL65_

Linha Laranja – Kanban

616tkWkRWjL._AC_US436_QL65_51hocASZ3bL._AC_US436_QL65_

Linha Roxa – Lean

41FItt2UB8L._AC_US436_QL65_51O-pgPIYAL._AC_US436_QL65_

51pgq089gIL._AC_US436_QL65_-2

Linha Azul

516O25pIrgL._AC_US436_QL65_71tMlME3L6L._AC_US436_QL65_

Linha Preta

511nXu28UIL._AC_US436_QL65_51zOpwQvJNL._AC_US436_QL65_

Linhas Verde e Azul – Para você que é de TI e estava se sentido esquecido

A fábula dos porcos assados (e os sistemas de informação)

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir dai, toda vez que queriam comer porco assado, incendiavam um bosque.  O tempo passou, e o sistema de assar porcos continuou basicamente o mesmo.

Mas as coisas nem sempre funcionavam bem: às vezes os animais ficavam queimados demais ou parcialmente crus. As causas do fracasso do sistema, segundo os especialistas, a dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou, ainda, às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar – na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: havia maquinário diversificado, indivíduos dedicados a acender o fogo e especialistas em ventos – os anemotécnicos. Havia um diretor-geral de Assamento e Alimentação Assada, um diretor de Técnicas Ígneas, um administrador-geral de Reflorestamento, uma Comissão de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias e o Bureau Orientador de Reforma Igneooperativas.

Eram milhares de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Um dia, um incendiador chamado João Bom-Senso resolveu dizer que o problema era fácil de ser resolvido – bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então sobre uma armação metálica sobre brasas, até que o efeito do calor – e não as chamas – assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor-geral de Assamento mandou chamá-lo ao seu gabinete e disse-lhe: “Tudo o que o senhor propõe está correto, mas não funciona. Isso pode funcionar na teoria, mas na prática não faz sentido. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? E com os acendedores de diversas especialidades? E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadoras de ar? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Hein?.”

“Não sei”, disse João, encabulado.

“O senhor percebe agora que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que, se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo?.”

“O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas? O que o senhor espera que eu faça com os quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? E o que fazer com nossos engenheiros em porcopirotecnia? Vamos, diga-me!”.

“Não sei, senhor.”

“Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia – isso poderia trazer problemas para o senhor no seu cargo.”

João Bom-Senso, coitado, não falou mais um “a”. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.”

Desconheço o autor desta fábula, mas ainda vejo florestas sendo queimadas com muito mais frequência do que imaginaria na área de Tecnologia de Informação.

Ouvi um relato de um projeto que foi fragmentado para quatro empresas fornecedoras operando remotamente, cada um com a sua especialidade tecnológica (Mobilidade, barramento, back-end e Web). Uma desculpa para este arranjo foi que cada empresa fornecedora era “dona” de uma tecnologia e os acordos contratuais exigiam esta distribuição. Dois anos depois e com com milhões de reais gastos nenhum produto foi entregue. O diretor de assamento então resolveu assar no espeto os gerentes e algumas fábricas que participaram deste processo.

Também tive a oportunidade de ver um time de produto que herdou uma arquitetura Web absurdamente complexa de um  “arquiteto super inteligente” de uma fábrica de software. O efeito desta arquitetura é o que time demora 3 semanas para implementar um cadastro de complexidade média.

Estas histórias reais me lembram do conceito de complexidade acidental e complexidade essencial, popularizado na TI por Neal Ford.

A complexidade essencial representa a dificuldade inerente a qualquer problema. Na nossa fábula acima, acender fogo era necessário para assar os porcos.  A complexidade decorrente dos compromissos que assumimos que incorrem em dívidas técnicas é diferente. Consiste em todas as formas imposta externamente de que o software se torne complexo e não deve existir em um mundo perfeito. A isso chamamos de complexidade acidental. Tecnologias como o Java EJB, Microsoft BizTalk e ERPs cujos nomes não podem ser pronunciados são exemplos de complexidade acidental na TI.

Tomo a liberdade aqui de expandir a definição original do autor, pensada para arquiteturas de software, para arranjos essenciais e arranjos acidentais.

Por exemplo, a existência de analistas desenvolvedores, analistas de testes e líderes de projetos são arranjos essenciais para entregar software de qualidade. Já times de testes e times de desenvolvedores que trabalham em salas separadas e com processos cascatas são exemplos de arranjos acidentais. E os  “gerentes de projetos” que ficam atrás das suas mesas 8 horas por dia atualizando cronogramas Gantt de 1000 linhas e perguntando aos seus coordenados “Eh aí, tá pronto?” são exemplos também ruins de arranjos acidentais.

Se você está cansado de queimar florestas inteiras para assar porcos, recomendo a aplicação de práticas do Lean Software Development, um corpo de práticas muito legais para você descomplicar a sua TI e a forma como entrega e mantém software.

“Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.”
Edsger W. Dijkstra

Maturidade DevOps – Gestão de Releases, Implantação e Entrega Contínua

Este é o nosso quarto post da série sobre maturidade em práticas DevOps. E aqui vamos discutir como podemos melhorar a maturidade no processo de gestão de releases, implantação contínua e entrega contínua.

Quando estamos discutindo Releases, estamos falando em como mover com velocidade e segurança um build nos diversos ambientes da sua empresa (exemplo – testes, homologação e produção).

Os princípios orientadores da gestão de releases

  1. Construa qualidade contínua
  2. Trabalhe em pequenos lotes
  3. Os computadores executam tarefas repetitivas, as pessoas resolvem problemas
  4. Procure melhoria contínua, obsessivamente
  5. Todos devem ser responsáveis

Construa qualidade contínua

Edwards Deming, figura-chave na história do movimento Lean e influenciador do movimento DevOps, ofereceu 14 princípios fundamentais para a gestão.  O terceiro princípio diz – “Eliminar a dependência da inspeção para alcançar a qualidade. Elimine a necessidade de inspeção em massa, construindo qualidade no produto em primeiro lugar “.

É muito mais barato solucionar problemas e defeitos se os encontrarmos imediatamente – idealmente antes de serem verificados no controle de versão, executando testes automatizados localmente. Encontrar defeitos através da inspeção (como o teste manual) é demorado e caro.

Criar e evoluir loops de feedback para detectar problemas o mais cedo possível é essencial na entrega contínua. Se encontrarmos um problema em nossos testes exploratórios, não devemos apenas corrigi-lo, mas depois perguntar: como poderíamos ter captado o problema com um teste automatizado de aceitação? Quando um teste de aceitação falha, devemos perguntar: Poderíamos ter escrito um teste de unidade para capturar esse problema?

Trabalhe em pequenos lotes

Em abordagens tradicionais para o desenvolvimento de software as transferências de desenvolvimento para teste ou teste para produção de TI consistem em lançamentos completos: semanas ou meses de trabalho por equipes e fábricas com muitas pessoas. E a razão pela qual muitos times trabalham em grandes lotes é devido ao grande custo fixo de entregar as mudanças.

Na entrega contínua tomamos a abordagem oposta e buscamos obter todas as mudanças no controle de versão até o final da liberação, obtendo feedback o mais rápido possível. Um dos principais objetivos da entrega contínua é mudar a economia do processo de entrega de software para tornar economicamente viável trabalhar em pequenos lotes para que possamos obter os muitos benefícios dessa abordagem.

Trabalhar em pequenos lotes tem muitos benefícios. Isso reduz o tempo necessário para obter feedback sobre o nosso trabalho, facilita a triagem e a reação a problemas e aumenta a eficiência e a motivação.

Computadores executam tarefas repetitivas, as pessoas resolvem problemas

Uma das primeiras idéias filosóficas da tradição de Toyota é o jidoka, às vezes traduzido como “automação com um toque humano”. O objetivo é que os computadores executem tarefas simples e repetitivas, como testes de regressão para que os humanos possam se concentrar na resolução de problemas . Assim, computadores e pessoas se complementam.

Muitas pessoas se preocupam que a automação os afastará de um emprego. Este não é o objetivo. Nunca haverá escassez de trabalho em uma empresa de sucesso. Em vez disso, as pessoas são liberadas do trabalho de trabalho despreocupado para se concentrar em atividades de maior valor. Isso também tem o benefício de melhorar a qualidade, uma vez que os seres humanos estão mais propensos a erros ao executar tarefas insensatas.

Procure melhoria contínua, obsessivamente

A melhoria contínua, ou kaizen em japonês, é outra idéia-chave do movimento Lean. Taiichi Ohno, uma figura-chave da história da empresa Toyota, disse uma vez,

“As oportunidades de Kaizen são infinitas. Não pense que você tenha feito as coisas melhores do que antes e esteja à vontade … Isso seria como o aluno que se torna orgulhoso porque superou seu mestre duas vezes em três na esgrima. Uma vez que você escolhe as idéias kaizen, é importante ter a atitude correta em nosso trabalho diário porque depois de uma ideia Kaizen existe uma outra ideia Kaizen a ser descoberta.”

Não trate a transformação como um projeto que será iniciado e depois concluído para que possamos retornar ao negócio como de costume. As melhores organizações são aquelas em que todos tratam o trabalho de melhoria como parte essencial do seu trabalho diário e onde ninguém está satisfeito com o status quo.

Todos devem ser responsáveis

Em organizações de alto desempenho, nada é “problema de outra pessoa”. Os desenvolvedores são responsáveis ​​pela qualidade e estabilidade do software que eles criam. As equipes de operações são responsáveis ​​por ajudar os desenvolvedores a desenvolver qualidade. Todos trabalham juntos para atingir os objetivos de nível organizacional, em vez de otimizar o que é melhor para sua equipe ou departamento.

Quando as pessoas fazem otimizações locais que reduzem o desempenho geral da organização, muitas vezes são devido a problemas sistêmicos como sistemas de gerenciamento pobres, ciclos orçamentários anuais ou incentivos que recompensam os comportamentos errados. Um exemplo clássico é recompensar os desenvolvedores por aumentar sua velocidade ou escrever mais código ou recompensar testadores com base no número de erros que eles encontram.

A maioria das pessoas quer fazer o que é certo, mas eles vão adaptar seu comportamento com base em como eles são recompensados. Portanto, é muito importante criar loops de feedback rápido das coisas que realmente importam: como os clientes reagem ao que construímos e o impacto em nossa organização.

Estabelecido esta base conceitual, vamos apresentar aqui uma escala de maturidade para a gestão de releases.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de gestão de releases. A entrega de um release nos ambientes de testes, homologação e produção é sempre feita de forma manual e sem o auxílio de ferramentas. Neste nível observamos que os desenvolvedores precisam trocar manualmente os apontamentos de banco de dados e editar arquivos de configuração (exemplos – WebConfig em .NET ou web.xml e Java).  Muitas vezes observamos rebotes e atritos com o time de infraestrutura e erros em produção devido a falhas humanas.
  2. Maturidade 2 – Consciente –  Aqui a cultura de releases começa a ser instalada. Ferramentas como Ansible ou Microsoft PowerShell  começam a ser utilizadas para automatizar os passos de publicação. Embora o processo ainda exija intervenção humana, os passos estão documentados em scripts que podem ser disparados sob demanda.
  3. Maturidade 3 – Gerenciado – Aqui os releases começam a ser publicados em intervalos regulares em ambientes controlados. Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Microsoft TFS ou Microsoft VSTS entram em cena para pegar um build que já tenha sido produzido e mover este build para os ambientes de testes, homologação e produção. Neste nível informações sobre senhas de produção não são mais conhecidas pelo time de desenvolvidos. Os arquivos com estas informações são usados pelos ambientes de gestão de release de forma transparente. E aqui também existem smoke tests automatizados que verificam se o ambiente de testes, homologação ou produção não foram quebrados.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de implantação de builds e também na capacidade de desfazer publicações automaticamente. Os builds começam a ser implantados com frequência diária em ambientes de testes e homologação e as publicações em produção ocorrem conforme os calendários acordados com áreas de negócio. E um aspecto crítico observado neste nível também é a capacidade de desfazermos publicações caso alguma instalabilidade tenha sido observada em ambiente de produção. Esta capacidade de desfazer publicações, obviamente, é controlada por ferramentas para evitar erros humanos.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que começa a experimentar a prática da implantação contínua (continuous deployment) e entrega contínua (continuous delivery). A primeira prática lida com a capacidade de publicar automaticamente builds nos ambientes de testes e homologação toda vez que um novo build tiver sido gerado pelo time.  E a segunda prática lida com a capacidade de entregar builds em produção de forma automatizada e com governança toda vez que um build tiver sido aprovado no ambiente de homologação. Aqui vemos também os times experimentando com testes e ambientes canários (também chamados de testes A/B).

 

Observe que esta escala de qualidade trabalha com dois fatores: o esforço humano necessário para a publicação de builds e a frequência de publicação. Times pouco maduros tem muita dificuldade para fazer publicações e normalmente dependem de intervenções humanas para publicar uma aplicação. Já times com maturidade alta tem o seu processo totalmente controlado por robôs, que não ficam cansados, e conseguem gerar publicações com grande frequência.

 

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os primeiros é específico sobre o processo de implantaçao e entrega contínua e conta também um excelente sítio Web com várias práticas documentadas.

Temos ainda dois outros livros sobre DevOps que mostram em contexto os processos de implantação e entrega contínua

41db4qikfil-_sx348_bo1204203200_     41x0usghmnl-_sy346_

51mcvngdt6l