Como é a vida de Agile Coaches que atuam em times de Plataforma ou SRE

Para os profissionais que iniciam o trabalho com metodologias ágeis, é muito comum andar com o guia Scrum “debaixo do braço”, como se diz. Mas, para além do que dita a norma, como adaptá-la a cada cenário? Como assegurar um bom entrosamento para que surjam bons feedbacks nos times de Plataforma ou SRE? Para Rodolpho Neto, que é Agile Master no Pagseguro, a primeira coisa é saber ouvir as “dores” do time. “Por mais que seja interessante ir pelo “by the book” a gente pode acabar perdendo algumas pessoas que não se adaptaram com um processo muito regrado, que às vezes não reflete a dinâmica do time. Não é porque está no livro que precisa fazer tudo o que diz ali”, comenta ele. Rodolpho acredita que o contexto ideal é justamente uma mistura dos dois: o que pregam as regras do método e principalmente muito feedback do time.

 

Crédito: tuleap.org

Mauricio Nakabayashi, Senior Solution Architect na Elvenworks, precisou “levar muita porrada” até perceber que, realmente, tudo bem se não fizer exatamente como está escrito no livro. Ele poderia simplesmente “ser mais paciente, saber o que a equipe está passando e escutar”, nas palavras dele. Em resumo, ouvir mais e estar mais aberto para as novas opiniões. Algo que, convenhamos, não chega a ser tão fácil ou natural para quem tem uma cabeça mais voltada para a programação do que para a gestão de pessoas. No entanto, gerir pessoas, e sobretudo aprender com elas, ao longo do processo de desenvolvimento de um Produto, é o desafio principal para quem trabalha com metodologias ágeis.

Luiz Resende, Cloud Services Manager na Claranet Brasil, conta de uma metodologia herdada das artes marciais japonesas, chamada Shuhari, que explica como a imitação leva à excelência. Em resumo, quando aprendemos ou treinamos algo, passamos pelos estágios do “shu”, “ha”, e “ri”. No “shu”, repetimos as formas e nos disciplinamos para que nosso corpo absorva as formas que nossos antepassados criaram, sem desvios; no “ha”, agora que nos disciplinamos, podemos fazer inovações, e as formas podem ser quebradas ou descartadas. No “ri”, nos afastamos completamente das formas, abrimos a porta para a técnica criativa e chegamos a um lugar onde agimos de acordo com o que nosso coração e mente desejam. Luiz acredita que as metodologias ágeis carregam muito da essência Shuhari. “Esse é um processo natural em tudo na vida que a gente vai começar. A princípio copiando alguém que tem mais experiência, até que você se desenvolva e deixe de ser “junior” para virar um “pleno”, e depois você se transforma em um sênior, que é quando ajuda mais ainda as pessoas a se desenvolverem na carreira”.

Como não poderia deixar de ser, o clima de colaboração precisa prevalecer para que as coisas caminhem bem na integração entre times de Produto e de Plataforma. Neste post, trazemos algumas reflexões desses três profissionais, em um bate-papo com nosso host Bruno Pereira, onde comentam o dia a dia deles como “agile coach” em suas equipes SRE. Você certamente irá se identificar com muitas partes, e também vai aprender na prática porque se preocupar com checklist de lançamento, Observabilidade e Gestão de incidentes é tão ou mais importante do que simplesmente “ser ágil”. 

Em times de SRE, quem é que cuida do backlog de Produto? Afinal, tem coisas ali que são plataforma, tem monitoramento, observabilidade, incidentes, FinOps, segurança e muitas outras coisas, que não é necessariamente responsabilidade de um time só, é um modelo muito compartilhado. Se não houver alguém responsável pelo roadmap, organizando o que que vai ser feito, muitos problemas vão surgir, principalmente na integração entre os times.

Rodolpho: Aqui no PagSeguro a gente tem alguns exemplos. É difícil achar um dono, principalmente quando estamos em um time que não necessariamente faz o Produto – o dono mesmo do produto é o time de Engenharia de Software – mas o backlog aqui é muito criado e construído em conjunto. A gente tem uma estrutura de time que chamamos de Engenharia de Confiabilidade, com profissionais de três frentes: SRE, AppSec, e de Database, que chamamos de DBRM, e não mais DBA. Então a gente já tem todos os profissionais para a condução do Produto no mesmo time, e isso meio que acaba forçando indiretamente o time de Produto a nos procurar mais cedo. Os cenários positivos são justamente quando isso acontece

Nesta semana tivemos reunião de apresentação de novos produtos. Quando a gente é inserido desde o início assim, é o melhor cenário possível, porque vamos construindo junto o backlog. A gente vai passando as nossas visões de quando observamos a arquitetura que foi apresentada, e eles também vão trazendo feedback. Alguns cenários que já aconteceram aqui e acontecem com certeza em outros lugares é justamente quando não somos incluídos no começo. Aí acabam surgindo aqueles pedidos de última hora, os famosos “pastéis”: uma criação às vezes de banco, de servidor, que já vem com a tecnologia definida. Isso pode acarretar até um atraso no projeto do time que acabou não conseguindo incluir a gente no começo para fazermos a construção em conjunto. O exemplo que eu tenho aqui é que o “dono” na verdade somos todos em conjunto, se a gente conseguir ser incluído no começo.

Mauricio: Atualmente passo por um desafio parecido. A gente conseguiu fazer a integração do time de SRE com o time de Produtos e Desenvolvimento, então hoje dentro de um determinado cliente funciona bem porque a gente já entra ali desde o início do ciclo daquele produto ou daquela feature nova que ele tem que lançar. Fica um processo mais maduro e mais fácil de lidar no dia a dia.

Luiz: No nosso cenário, normalmente a gente faz SRE em ambiente de cliente, então o responsável pelo workload é o cliente, e isso em geral é negociado. Ou seja, o cliente sabe da necessidade dele, porém dentro do nosso time de DevOps temos uma liderança técnica, uma pessoa que conhece um pouco mais de arquitetura e tem bastante propriedade para junto do cliente discutir quais são as melhores estratégias para a gente poder avançar e fazer o nosso SRE com a melhoria contínua dentro do ambiente. Às vezes tem Product Owner (P.O.) do lado do cliente, mas a gente acaba trabalhando muito em parceria. Justamente para não ter esse apontamento de dedo de quem é o responsável, todo mundo meio que abraça a causa, a gente compartilha essa responsabilidade; dentro da empresa também a gente até mudou a sigla de SCRUM Master para Agile Master, porque o especialista agilista também consegue apoiar com o papel de P.O., consegue apoiar o Tech Leader, o Stakeholder do lado cliente para poder ajudar a definir quais são de fato as tarefas e priorizar isso junto do cliente para que a gente execute e de fato entregue algum valor para o ambiente. Se a gente entra nessa de fazer o que o pessoal quer, a gente não consegue construir nada… a gente acaba sendo muito reativo, e às vezes é como o Maurício comentou: entre uma demanda e outra, “ah, isso é rápido”, esse “rápido” consome um tempo considerável porque não foi bem detalhado, não foi bem definido, atrapalha todo o planejamento. Então como não existe uma pessoa específica com chapéu de P.O., é importante todos assumirem a responsabilidade em conjunto junto. Sentar e traçar quais são as prioridades, quais são as demandas, o que é o pronto dessas demandas, o DoD (Definition of Done) para que a gente entregue valor no final do processo.

 

Crédito: heflo.com

Vocês que já são experientes com Kanban, como tipicamente lidam com o backlog do time sabendo que podem chegar coisas de última hora que precisarão ser atendidas com urgência? Como fazer para que isso não impacte tanto na cadência do backlog planejado do time?

Luiz: É importante termos um planejamento para conseguir avançar, aplicar melhoria contínua no ambiente, não ser só reativo. Mas precisa entender que incidentes e necessidades emergenciais acontecem. Então quando a gente faz um planejamento, obviamente é importante já termos vivido isso há algum tempo para que possamos ter alguma métrica ali e separar que, por exemplo, 70% do nosso nosso tempo vamos pensar no Sprint e reservar o espaço dos outros 30% para executar essas demandas pontuais que que surgem pelo caminho.

Se for um incidente a gente prioriza – prioridade zero – e outras solicitações vão existir ao longo do tempo. Então normalmente a gente elenca alguém no time para ser uma espécie de “bombeiro” e atuar nessas demandas que não são planejadas, para que o restante do time se concentre na evolução da construção do ambiente, e nas automações, e esse profissional é a pessoa que fica com o chapéu de bombeiro naquela semana e vai atuar mais em demandas não planejadas. A gente costuma fazer uma rotatividade até para não desmotivar esse profissional, mas é fato que ele também ganha um pouco mais de experiência porque atua em um ambiente ainda descontrolado, um ambiente de incidente, que ele não conhece, e acaba desenvolvendo um pouco mais das habilidades de fazer um troubleshoot, de identificar onde está a falha e poder consertar aquele problema e futuramente fazer uma correção definitiva.

Dentro desse universo é importante que a gente tenha essa rotatividade, e que essa experiência seja bem aplicada. É claro que depende muito do ambiente também, às vezes tem muito mais incêndio do que é possível a gente prever, mas isso também é importante para depois em uma reunião de review entender de fato porque está ocorrendo tanto incidente, e se for o caso envolver outras equipes; uma equipe de monitoramento, por exemplo, de repente não está monitorando muito bem as coisas, ou precisa refinar mais o monitoramento. De todos os experimentos, esse foi o que melhor se encaixou para lidar com esse tipo de situação. Claro que a gente não vai saber de cara se é 70-30 se é 50-50, isso precisa ser experimentado e depois com mais informações a gente consegue ajustar, sempre com foco na diminuição de incidentes.

Rodolpho: Eu já implementei Scrum e Sprints em outros times. Analisando o cenário do time na empresa onde trabalho atualmente, eu particularmente prefiro o usar modelo de cadência, ou seja, uso um quadro Kanban que só é reabastecido a cada 15 dias, sem uma Sprint propriamente definida, com escopo muito bem fechado, e algo que não posso interferir, justamente por conta desses pedidos ou atividades que possam entrar no meio. O que ajuda bastante aqui é primeiro a quantidade de pessoas que temos no time. Temos 30 pessoas para uma squad de infraestrutura. 

Então a gente tem essa rotação também que o Luiz comentou, de pessoas olhando essas atividades que chegam de última hora; e um acordo que a gente tem na nossa equipe é que todo o pedido que a gente recebe do time de Produto para entrar depois que a gente já fez o nosso planejamento é que o time direcione a pessoa, seja desenvolvedor, P.O., Agile Master, ou coordenador do outro time para mim ou para o coordenador do nosso time para que a gente faça primeiro aquele entendimento se a demanda é urgente. Porque, às vezes, a pessoa quer pedir uma atividade porque considera importante, ok, mas ela não é urgente, ela só é importante para aquela pessoa.

Mas a gente tem que fazer o entendimento porque quando não é realmente urgente e a gente demonstra para pessoa que a gente pode atuar nela, mas que se a gente atuar nela agora depois que já fizemos o planejamento, a gente vai acabar passando a atividade na frente de outros times que já foram planejados, atividades de incidente ou até de postmortem que a gente esteja tratando. Então quando a gente expõe isso, a prioridade até abaixa. A pessoa já consegue colocar para o próximo planejamento ou já fica para a próxima quinzena. Agora, se for algo realmente urgente e que não dá para esperar, a gente usa o Jira, e habilita o campo de classe de serviço do Kanban para fazer uma alteração para expedite e assim que entra como expedite ela fura a fila das outras.

Mauricio: Precisa tomar cuidado, porque onde tudo é prioridade, no final das contas nada é prioridade. A gente também toma cuidado em fazer esse alinhamento, por isso é muito bom ter as peças do SCRUM alinhadas. O P.O. e o Scrum Master, que tem a visão do produto, da entrega final, precisam estar alinhados com os stakeholders para que quando vier alguma prioridade poderem argumentar: “pessoal, tudo bem… isso aqui é prioridade, mas o impacto é esse se a gente parar a atividade x”. Então, é esse cuidado que a gente toma aqui na empresa também, de medir a prioridade mesmo. E o fato do Kanban dar essa visão do Sprint é essencial. Tem que ter a visão da sua Sprint, para entender bem o funcionamento e com isso fazer a tomada de decisões e ações.

Os times de produto gostam e precisam ter autonomia, auto-serviço e a capacidade de experimentar e colocar novas versões em produção com liberdade para tentar entender como é que funciona o cliente final da empresa; dessa forma, eles aprendem sobre o cliente e sobre o produto da forma mais rápida possível. Existem técnicas que a gente consegue operar para reduzir o risco de uma nova versão do Produto quebrar alguma coisa na aplicação. Como funcionam essas técnicas de processo de release para vocês, tendo todo o cuidado para não quebrar a experiência do cliente final? 

Maurício: Hoje estamos aplicando isso dentro de um cliente. Mas lá em 2018, na squad que eu trabalhava na Rivendel, experimentamos dar liberdade para o desenvolvedor testar sua aplicação antes de subir em produção – a gente até conseguiu o prêmio Agile Trends, na categoria DevOps – e de fato só quem coloca em produção é o SRE. Ou seja, damos liberdade para o desenvolvedor, mas não damos todo o caminho das pedras ali, por assim dizer. Por trás disso a gente também faz toda a parte de automação liga/desliga ambiente para não deixar só gerando custos. Então essa é uma das técnicas que a gente adotou, de dar essa automação dentro do ambiente para o dev subir e “destruir”; e a parte de começar a gerar artefatos ali dentro dos deployments – em vez de subir um deploy completo e gerar um artefato somente de uma fatia da aplicação.

Em situações onde a aplicação simplesmente para e não se sabe o que que acontece, em vez de fazer o rollback dela inteira, a gente adota os artefatos para quebrar e mitigar riscos; ao invés de voltar o rollback e gerar uma nova dor de cabeça de onde parou, qual foi o problema, onde encontrar o problema para fazer a correção… são gerados pequenos artefatos para fazer a aplicação no ambiente de homologação. Depois de aprovado por todos os times, SRE, desenvolvedores, P.O., aí fazíamos essa virada por produção. Foi bom por termos conseguido reduzir muito os riscos, e por de fato deixar ali um ambiente mais ágil. Tanto, que se houver algum problema, a gente consegue voltar em questão de minutos; ao invés de ter que parar tudo, refazer e perder mais uns 3 Sprints para a frente para corrigir um problema. A técnica dos artefatos acabou se provando mais rápida.

Passado o incidente, quando tudo já foi devidamente resolvido, como vocês lidam com o postmortem e a apuração do porquê aquilo aconteceu, e o que fazer para não acontecer de novo?

Rodolpho: Aqui nós temos muito enraizado na empresa essa cultura de blameless (de não “apontar dedos”) e postmortem. A gente tem um time inclusive só para cuidar dos postmortems que são criados. Temos uma estrutura que funciona assim: a gente acabou sendo acionado no incidente, aquele incidente é classificado como uma crise que tem classificações de prioridade; se é uma crise realmente, gera um postmortem automaticamente – temos um projeto no Jira específico para todos os postmortems da empresa – e sempre que o postmortem é criado a gente sai da crise com a ação de todo mundo voltar e preencher esse relatório o quanto antes. O ideal é no dia seguinte, se a crise acontecer de madrugada. Muita gente atua de madrugada, e é complicado parar para pensar ali; mas o projeto do Jira já vem com algumas atividades criadas por padrão.

Se existe entrega com alguma relação com entrega em produção, por exemplo, tem algumas atividades padrão no Jira que já contempla alguma ação se couber dentro delas. Além disso, a gente faz o preenchimento do próprio postmortem. Para isso, usamos a técnica dos “5 Porquês”, que consiste em perguntar o porquê cinco vezes ou talvez até mais se precisar, até encontrar a causa raiz; nesse postmortem, na cerimônia, estão incluídos todos os que participaram, sejam de times de Engenharia de Confiabilidade, no nosso caso, ou de Produto ou até de Plataforma, que são os times que cuidam da infraestrutura mais em nível organizacional. E a gente sai dali com as atividades definidas para cada equipe – com as atividades para cada Jira de cada time conectadas com esse postmortem.

Luiz: É importante não ficar apontando o dedo de quem é a culpa (cultura blameless), é importante achar a falha e junto pensar em solução. Então com toda essa cultura das pessoas trabalharem em conjunto, de ter aquele sentimento de “dono” facilita para discutirmos junto, usando técnicas como o Rodolpho citou, dos “5 Porquês” e já pensar em soluções ali mesmo. Por exemplo, quem vai ser o responsável, o que vai fazer, qual o impacto que isso vai gerar, mas para que a gente continue evoluindo. Sempre pensando em melhoria contínua, mantendo o ambiente estável, e sempre avançando e evoluindo a cada momento que identificamos incidentes.

Estamos o tempo todo vulnerável, apesar de ter toda uma equipe com toda a parte de monitoramento, com pessoas multidisciplinares cuidando do ambiente, alguém que conhece um pouco mais da parte de rede, ou alguém conhecendo mais da parte de segurança ou outra um pouco mais da parte da arquitetura do ambiente que o cliente possui. Mas é um risco, os incidentes sempre acontecem, então é importante nesse encontro de postmortem todo mundo estar com o pé no chão para buscar o melhor e não “apontar dedos”. Eu acho que nesse ponto o agilista sempre precisa ajudar a conduzir, quando tem um agilista em uma equipe ele sempre ajuda a conduzir que o final daquele encontro não é para culpar alguém, e sim trazer soluções para a gente investir e evoluir o ambiente. 

Como vocês fazem o onboarding das pessoas que entram para o time? Quais dicas para quem deseja atuar como Agile Coach em um time, principalmente SRE e Plataforma?

Rodolpho: Quando a gente fala de Agilidade ou de Agile Masters e Agile Coachs em times de SRE e time de Plataforma que não estão de fato desenvolvendo Produtos a gente não vê muitos cases, por ser um cenário um pouco atípico se comparado com desenvolvimento de software e de Produtos. O que poderia dizer de dica é que muitos agilistas iniciantes vão seguir o livro debaixo do braço, conforme está ali, e isso vai gerar um ensinamento para eles. Mas acho que o principal, ainda mais em time de infraestrutura, é primeiro ouvir qual é a dor do time. Por mais que seja interessante ir pelo “by the book”, a gente pode acabar perdendo algumas pessoas do time por que não se adaptaram com aquele processo muito certinho, muito bem definido e às vezes nem é o cenário do time. O time não precisa seguir à risca todas as cerimônias que o Scrum prega. Por exemplo, se o time achou que tem muita reunião acontecendo, a gente deixa de fazer uma vez por semana ou mais, se todos entendermos que não está gerando tanto valor assim. Então é uma mistura dos dois: é um pouco do livro e muito feedback do time.

Mauricio: É muito “abra a sua mente” e “escute mais as pessoas que estão com você no dia a dia”. Uma coisa que eu aprendi bastante é que não tem que ser tudo certinho como está escrito no Scrum guide, e eu vou ter que seguir assim. Mas eu precisei levar muita “porrada” para entender que tinha que ser mais ouvinte da minha equipe,  mais paciente, saber o que eles estão passando e escutar o que é melhor para equipe e não pensar somente no que eu vou implantar dentro da squad. Então é ser mais ouvinte, ser mais paciente e estar mais aberto para as novas opiniões. Outra coisa que aprendi é tomar cuidado com as críticas porque isso acaba gerando certo estresse também dentro da equipe, e o turn-over das pessoas. 

Luiz: Esse parte de seguir o Scrum guide é muito comum. Tem até uma metodologia chamada Shuhari, que é utilizada nas artes marciais, onde você imita alguém que já tem uma experiência; a princípio sem saber porquê, vai só treinando “socos” e “chutes” mesmo. Só com o tempo a pessoa vai entendendo e vai colocando o jeitinho dela. Acho que acontece algo semelhante com agilidade: no primeiro momento, quando tudo é novo, quando se está em um ambiente ou em uma equipe que ainda não utiliza o agile, a gente segue o guia. Então a gente vai fazer daily meeting todos os dias, vai fazer uma Sprint de 2 a 4 Semanas citando Scrum como exemplo, vai fazer uma review, uma retrospectiva no final de cada Sprint, porque é isso que alguém que definiu isso e registrou isso em um guia escreveu.

Mas a partir do momento que você vai avançando, vai ganhando experiência e o time vai entendendo, começa a utilizar mais ferramentas e práticas. Daí começa a segunda fase do Shuhari, é quando você quebra a regra e começa a colocar o seu jeito ali. Porque agora as coisas estão dando certo, e lá na frente, quando você dominar mais ainda a cultura se transforma, e tudo fica muito mais intrínseco e menos visível, porque é mais natural. Então esse processo é natural em tudo na vida que a gente vai começar. Primeiro copiando alguém que tenha mais experiência até que você se desenvolva, e aí deixa de ser um “júnior”, para virar um “pleno”; depois você se transforma em um “sênior”, que é quando você ainda ajuda as pessoas a se desenvolverem também. 

Rodolpho: Tem um outro ponto que lembrei agora que talvez seja interessante para quem começa. Se for um time novo ou às vezes um time já existente, eu acho que tem que começar do mais básico possível. Nem que seja só mostrar o fluxo de trabalho do time, um quadro mostrando o fluxo e como identificar gargalos; nem que seja só isso e, com o tempo, vai implementando outras coisas ali que o Scrum guide e a metodologia kanban direcionam a pensar, pensamento enxuto ou coisa do tipo.

Então começar com o básico, ter ali um fluxo atual do time onde você demonstra onde está o gargalo, acho que com o tempo o time vai criando a necessidade de se conversar mais. Se isso acontecer, então a gente pode acabar deduzindo uma daily meeting. Se o time tem a necessidade de se planejar mais porque está vendo ali no fluxo que tem muito gargalo, tem muito problema parado, então você começa a planejar mais. Ou seja, o ideal é começar aos poucos mesmo. Querer abraçar tudo de uma vez só é complicado.

Assista ao vídeo com a íntegra do bate-papo:

https://www.youtube.com/watch?v=s5Ct6gYSuFg&t=45s

 

Como é a vida de Agile Coaches que atuam em times de Plataforma ou SRE

Para os profissionais que iniciam o trabalho com metodologias ágeis, é muito comum andar com o guia Scrum “debaixo do braço”, como se diz. Mas, para além do que dita a norma, como adaptá-la a cada cenário? Como assegurar um bom entrosamento para que surjam bons feedbacks nos times de Plataforma ou SRE? Para Rodolpho Neto, que é Agile Master no Pagseguro, a primeira coisa é saber ouvir as “dores” do time. “Por mais que seja interessante ir pelo “by the book” a gente pode acabar perdendo algumas pessoas que não se adaptaram com um processo muito regrado, que às vezes não reflete a dinâmica do time. Não é porque está no livro que precisa fazer tudo o que diz ali”, comenta ele. Rodolpho acredita que o contexto ideal é justamente uma mistura dos dois: o que pregam as regras do método e principalmente muito feedback do time.

 

Crédito: tuleap.org

Mauricio Nakabayashi, Senior Solution Architect na Elvenworks, precisou “levar muita porrada” até perceber que, realmente, tudo bem se não fizer exatamente como está escrito no livro. Ele poderia simplesmente “ser mais paciente, saber o que a equipe está passando e escutar”, nas palavras dele. Em resumo, ouvir mais e estar mais aberto para as novas opiniões. Algo que, convenhamos, não chega a ser tão fácil ou natural para quem tem uma cabeça mais voltada para a programação do que para a gestão de pessoas. No entanto, gerir pessoas, e sobretudo aprender com elas, ao longo do processo de desenvolvimento de um Produto, é o desafio principal para quem trabalha com metodologias ágeis.

Luiz Resende, Cloud Services Manager na Claranet Brasil, conta de uma metodologia herdada das artes marciais japonesas, chamada Shuhari, que explica como a imitação leva à excelência. Em resumo, quando aprendemos ou treinamos algo, passamos pelos estágios do “shu”, “ha”, e “ri”. No “shu”, repetimos as formas e nos disciplinamos para que nosso corpo absorva as formas que nossos antepassados criaram, sem desvios; no “ha”, agora que nos disciplinamos, podemos fazer inovações, e as formas podem ser quebradas ou descartadas. No “ri”, nos afastamos completamente das formas, abrimos a porta para a técnica criativa e chegamos a um lugar onde agimos de acordo com o que nosso coração e mente desejam. Luiz acredita que as metodologias ágeis carregam muito da essência Shuhari. “Esse é um processo natural em tudo na vida que a gente vai começar. A princípio copiando alguém que tem mais experiência, até que você se desenvolva e deixe de ser “junior” para virar um “pleno”, e depois você se transforma em um sênior, que é quando ajuda mais ainda as pessoas a se desenvolverem na carreira”.

Como não poderia deixar de ser, o clima de colaboração precisa prevalecer para que as coisas caminhem bem na integração entre times de Produto e de Plataforma. Neste post, trazemos algumas reflexões desses três profissionais, em um bate-papo com nosso host Bruno Pereira, onde comentam o dia a dia deles como “agile coach” em suas equipes SRE. Você certamente irá se identificar com muitas partes, e também vai aprender na prática porque se preocupar com checklist de lançamento, Observabilidade e Gestão de incidentes é tão ou mais importante do que simplesmente “ser ágil”. 

Em times de SRE, quem é que cuida do backlog de Produto? Afinal, tem coisas ali que são plataforma, tem monitoramento, observabilidade, incidentes, FinOps, segurança e muitas outras coisas, que não é necessariamente responsabilidade de um time só, é um modelo muito compartilhado. Se não houver alguém responsável pelo roadmap, organizando o que que vai ser feito, muitos problemas vão surgir, principalmente na integração entre os times.

Rodolpho: Aqui no PagSeguro a gente tem alguns exemplos. É difícil achar um dono, principalmente quando estamos em um time que não necessariamente faz o Produto – o dono mesmo do produto é o time de Engenharia de Software – mas o backlog aqui é muito criado e construído em conjunto. A gente tem uma estrutura de time que chamamos de Engenharia de Confiabilidade, com profissionais de três frentes: SRE, AppSec, e de Database, que chamamos de DBRM, e não mais DBA. Então a gente já tem todos os profissionais para a condução do Produto no mesmo time, e isso meio que acaba forçando indiretamente o time de Produto a nos procurar mais cedo. Os cenários positivos são justamente quando isso acontece

Nesta semana tivemos reunião de apresentação de novos produtos. Quando a gente é inserido desde o início assim, é o melhor cenário possível, porque vamos construindo junto o backlog. A gente vai passando as nossas visões de quando observamos a arquitetura que foi apresentada, e eles também vão trazendo feedback. Alguns cenários que já aconteceram aqui e acontecem com certeza em outros lugares é justamente quando não somos incluídos no começo. Aí acabam surgindo aqueles pedidos de última hora, os famosos “pastéis”: uma criação às vezes de banco, de servidor, que já vem com a tecnologia definida. Isso pode acarretar até um atraso no projeto do time que acabou não conseguindo incluir a gente no começo para fazermos a construção em conjunto. O exemplo que eu tenho aqui é que o “dono” na verdade somos todos em conjunto, se a gente conseguir ser incluído no começo.

Mauricio: Atualmente passo por um desafio parecido. A gente conseguiu fazer a integração do time de SRE com o time de Produtos e Desenvolvimento, então hoje dentro de um determinado cliente funciona bem porque a gente já entra ali desde o início do ciclo daquele produto ou daquela feature nova que ele tem que lançar. Fica um processo mais maduro e mais fácil de lidar no dia a dia.

Luiz: No nosso cenário, normalmente a gente faz SRE em ambiente de cliente, então o responsável pelo workload é o cliente, e isso em geral é negociado. Ou seja, o cliente sabe da necessidade dele, porém dentro do nosso time de DevOps temos uma liderança técnica, uma pessoa que conhece um pouco mais de arquitetura e tem bastante propriedade para junto do cliente discutir quais são as melhores estratégias para a gente poder avançar e fazer o nosso SRE com a melhoria contínua dentro do ambiente. Às vezes tem Product Owner (P.O.) do lado do cliente, mas a gente acaba trabalhando muito em parceria. Justamente para não ter esse apontamento de dedo de quem é o responsável, todo mundo meio que abraça a causa, a gente compartilha essa responsabilidade; dentro da empresa também a gente até mudou a sigla de SCRUM Master para Agile Master, porque o especialista agilista também consegue apoiar com o papel de P.O., consegue apoiar o Tech Leader, o Stakeholder do lado cliente para poder ajudar a definir quais são de fato as tarefas e priorizar isso junto do cliente para que a gente execute e de fato entregue algum valor para o ambiente. Se a gente entra nessa de fazer o que o pessoal quer, a gente não consegue construir nada… a gente acaba sendo muito reativo, e às vezes é como o Maurício comentou: entre uma demanda e outra, “ah, isso é rápido”, esse “rápido” consome um tempo considerável porque não foi bem detalhado, não foi bem definido, atrapalha todo o planejamento. Então como não existe uma pessoa específica com chapéu de P.O., é importante todos assumirem a responsabilidade em conjunto junto. Sentar e traçar quais são as prioridades, quais são as demandas, o que é o pronto dessas demandas, o DoD (Definition of Done) para que a gente entregue valor no final do processo.

 

Crédito: heflo.com

Vocês que já são experientes com Kanban, como tipicamente lidam com o backlog do time sabendo que podem chegar coisas de última hora que precisarão ser atendidas com urgência? Como fazer para que isso não impacte tanto na cadência do backlog planejado do time?

Luiz: É importante termos um planejamento para conseguir avançar, aplicar melhoria contínua no ambiente, não ser só reativo. Mas precisa entender que incidentes e necessidades emergenciais acontecem. Então quando a gente faz um planejamento, obviamente é importante já termos vivido isso há algum tempo para que possamos ter alguma métrica ali e separar que, por exemplo, 70% do nosso nosso tempo vamos pensar no Sprint e reservar o espaço dos outros 30% para executar essas demandas pontuais que que surgem pelo caminho.

Se for um incidente a gente prioriza – prioridade zero – e outras solicitações vão existir ao longo do tempo. Então normalmente a gente elenca alguém no time para ser uma espécie de “bombeiro” e atuar nessas demandas que não são planejadas, para que o restante do time se concentre na evolução da construção do ambiente, e nas automações, e esse profissional é a pessoa que fica com o chapéu de bombeiro naquela semana e vai atuar mais em demandas não planejadas. A gente costuma fazer uma rotatividade até para não desmotivar esse profissional, mas é fato que ele também ganha um pouco mais de experiência porque atua em um ambiente ainda descontrolado, um ambiente de incidente, que ele não conhece, e acaba desenvolvendo um pouco mais das habilidades de fazer um troubleshoot, de identificar onde está a falha e poder consertar aquele problema e futuramente fazer uma correção definitiva.

Dentro desse universo é importante que a gente tenha essa rotatividade, e que essa experiência seja bem aplicada. É claro que depende muito do ambiente também, às vezes tem muito mais incêndio do que é possível a gente prever, mas isso também é importante para depois em uma reunião de review entender de fato porque está ocorrendo tanto incidente, e se for o caso envolver outras equipes; uma equipe de monitoramento, por exemplo, de repente não está monitorando muito bem as coisas, ou precisa refinar mais o monitoramento. De todos os experimentos, esse foi o que melhor se encaixou para lidar com esse tipo de situação. Claro que a gente não vai saber de cara se é 70-30 se é 50-50, isso precisa ser experimentado e depois com mais informações a gente consegue ajustar, sempre com foco na diminuição de incidentes.

Rodolpho: Eu já implementei Scrum e Sprints em outros times. Analisando o cenário do time na empresa onde trabalho atualmente, eu particularmente prefiro o usar modelo de cadência, ou seja, uso um quadro Kanban que só é reabastecido a cada 15 dias, sem uma Sprint propriamente definida, com escopo muito bem fechado, e algo que não posso interferir, justamente por conta desses pedidos ou atividades que possam entrar no meio. O que ajuda bastante aqui é primeiro a quantidade de pessoas que temos no time. Temos 30 pessoas para uma squad de infraestrutura. 

Então a gente tem essa rotação também que o Luiz comentou, de pessoas olhando essas atividades que chegam de última hora; e um acordo que a gente tem na nossa equipe é que todo o pedido que a gente recebe do time de Produto para entrar depois que a gente já fez o nosso planejamento é que o time direcione a pessoa, seja desenvolvedor, P.O., Agile Master, ou coordenador do outro time para mim ou para o coordenador do nosso time para que a gente faça primeiro aquele entendimento se a demanda é urgente. Porque, às vezes, a pessoa quer pedir uma atividade porque considera importante, ok, mas ela não é urgente, ela só é importante para aquela pessoa.

Mas a gente tem que fazer o entendimento porque quando não é realmente urgente e a gente demonstra para pessoa que a gente pode atuar nela, mas que se a gente atuar nela agora depois que já fizemos o planejamento, a gente vai acabar passando a atividade na frente de outros times que já foram planejados, atividades de incidente ou até de postmortem que a gente esteja tratando. Então quando a gente expõe isso, a prioridade até abaixa. A pessoa já consegue colocar para o próximo planejamento ou já fica para a próxima quinzena. Agora, se for algo realmente urgente e que não dá para esperar, a gente usa o Jira, e habilita o campo de classe de serviço do Kanban para fazer uma alteração para expedite e assim que entra como expedite ela fura a fila das outras.

Mauricio: Precisa tomar cuidado, porque onde tudo é prioridade, no final das contas nada é prioridade. A gente também toma cuidado em fazer esse alinhamento, por isso é muito bom ter as peças do SCRUM alinhadas. O P.O. e o Scrum Master, que tem a visão do produto, da entrega final, precisam estar alinhados com os stakeholders para que quando vier alguma prioridade poderem argumentar: “pessoal, tudo bem… isso aqui é prioridade, mas o impacto é esse se a gente parar a atividade x”. Então, é esse cuidado que a gente toma aqui na empresa também, de medir a prioridade mesmo. E o fato do Kanban dar essa visão do Sprint é essencial. Tem que ter a visão da sua Sprint, para entender bem o funcionamento e com isso fazer a tomada de decisões e ações.

Os times de produto gostam e precisam ter autonomia, auto-serviço e a capacidade de experimentar e colocar novas versões em produção com liberdade para tentar entender como é que funciona o cliente final da empresa; dessa forma, eles aprendem sobre o cliente e sobre o produto da forma mais rápida possível. Existem técnicas que a gente consegue operar para reduzir o risco de uma nova versão do Produto quebrar alguma coisa na aplicação. Como funcionam essas técnicas de processo de release para vocês, tendo todo o cuidado para não quebrar a experiência do cliente final? 

Maurício: Hoje estamos aplicando isso dentro de um cliente. Mas lá em 2018, na squad que eu trabalhava na Rivendel, experimentamos dar liberdade para o desenvolvedor testar sua aplicação antes de subir em produção – a gente até conseguiu o prêmio Agile Trends, na categoria DevOps – e de fato só quem coloca em produção é o SRE. Ou seja, damos liberdade para o desenvolvedor, mas não damos todo o caminho das pedras ali, por assim dizer. Por trás disso a gente também faz toda a parte de automação liga/desliga ambiente para não deixar só gerando custos. Então essa é uma das técnicas que a gente adotou, de dar essa automação dentro do ambiente para o dev subir e “destruir”; e a parte de começar a gerar artefatos ali dentro dos deployments – em vez de subir um deploy completo e gerar um artefato somente de uma fatia da aplicação.

Em situações onde a aplicação simplesmente para e não se sabe o que que acontece, em vez de fazer o rollback dela inteira, a gente adota os artefatos para quebrar e mitigar riscos; ao invés de voltar o rollback e gerar uma nova dor de cabeça de onde parou, qual foi o problema, onde encontrar o problema para fazer a correção… são gerados pequenos artefatos para fazer a aplicação no ambiente de homologação. Depois de aprovado por todos os times, SRE, desenvolvedores, P.O., aí fazíamos essa virada por produção. Foi bom por termos conseguido reduzir muito os riscos, e por de fato deixar ali um ambiente mais ágil. Tanto, que se houver algum problema, a gente consegue voltar em questão de minutos; ao invés de ter que parar tudo, refazer e perder mais uns 3 Sprints para a frente para corrigir um problema. A técnica dos artefatos acabou se provando mais rápida.

Passado o incidente, quando tudo já foi devidamente resolvido, como vocês lidam com o postmortem e a apuração do porquê aquilo aconteceu, e o que fazer para não acontecer de novo?

Rodolpho: Aqui nós temos muito enraizado na empresa essa cultura de blameless (de não “apontar dedos”) e postmortem. A gente tem um time inclusive só para cuidar dos postmortems que são criados. Temos uma estrutura que funciona assim: a gente acabou sendo acionado no incidente, aquele incidente é classificado como uma crise que tem classificações de prioridade; se é uma crise realmente, gera um postmortem automaticamente – temos um projeto no Jira específico para todos os postmortems da empresa – e sempre que o postmortem é criado a gente sai da crise com a ação de todo mundo voltar e preencher esse relatório o quanto antes. O ideal é no dia seguinte, se a crise acontecer de madrugada. Muita gente atua de madrugada, e é complicado parar para pensar ali; mas o projeto do Jira já vem com algumas atividades criadas por padrão.

Se existe entrega com alguma relação com entrega em produção, por exemplo, tem algumas atividades padrão no Jira que já contempla alguma ação se couber dentro delas. Além disso, a gente faz o preenchimento do próprio postmortem. Para isso, usamos a técnica dos “5 Porquês”, que consiste em perguntar o porquê cinco vezes ou talvez até mais se precisar, até encontrar a causa raiz; nesse postmortem, na cerimônia, estão incluídos todos os que participaram, sejam de times de Engenharia de Confiabilidade, no nosso caso, ou de Produto ou até de Plataforma, que são os times que cuidam da infraestrutura mais em nível organizacional. E a gente sai dali com as atividades definidas para cada equipe – com as atividades para cada Jira de cada time conectadas com esse postmortem.

Luiz: É importante não ficar apontando o dedo de quem é a culpa (cultura blameless), é importante achar a falha e junto pensar em solução. Então com toda essa cultura das pessoas trabalharem em conjunto, de ter aquele sentimento de “dono” facilita para discutirmos junto, usando técnicas como o Rodolpho citou, dos “5 Porquês” e já pensar em soluções ali mesmo. Por exemplo, quem vai ser o responsável, o que vai fazer, qual o impacto que isso vai gerar, mas para que a gente continue evoluindo. Sempre pensando em melhoria contínua, mantendo o ambiente estável, e sempre avançando e evoluindo a cada momento que identificamos incidentes.

Estamos o tempo todo vulnerável, apesar de ter toda uma equipe com toda a parte de monitoramento, com pessoas multidisciplinares cuidando do ambiente, alguém que conhece um pouco mais da parte de rede, ou alguém conhecendo mais da parte de segurança ou outra um pouco mais da parte da arquitetura do ambiente que o cliente possui. Mas é um risco, os incidentes sempre acontecem, então é importante nesse encontro de postmortem todo mundo estar com o pé no chão para buscar o melhor e não “apontar dedos”. Eu acho que nesse ponto o agilista sempre precisa ajudar a conduzir, quando tem um agilista em uma equipe ele sempre ajuda a conduzir que o final daquele encontro não é para culpar alguém, e sim trazer soluções para a gente investir e evoluir o ambiente. 

Como vocês fazem o onboarding das pessoas que entram para o time? Quais dicas para quem deseja atuar como Agile Coach em um time, principalmente SRE e Plataforma?

Rodolpho: Quando a gente fala de Agilidade ou de Agile Masters e Agile Coachs em times de SRE e time de Plataforma que não estão de fato desenvolvendo Produtos a gente não vê muitos cases, por ser um cenário um pouco atípico se comparado com desenvolvimento de software e de Produtos. O que poderia dizer de dica é que muitos agilistas iniciantes vão seguir o livro debaixo do braço, conforme está ali, e isso vai gerar um ensinamento para eles. Mas acho que o principal, ainda mais em time de infraestrutura, é primeiro ouvir qual é a dor do time. Por mais que seja interessante ir pelo “by the book”, a gente pode acabar perdendo algumas pessoas do time por que não se adaptaram com aquele processo muito certinho, muito bem definido e às vezes nem é o cenário do time. O time não precisa seguir à risca todas as cerimônias que o Scrum prega. Por exemplo, se o time achou que tem muita reunião acontecendo, a gente deixa de fazer uma vez por semana ou mais, se todos entendermos que não está gerando tanto valor assim. Então é uma mistura dos dois: é um pouco do livro e muito feedback do time.

Mauricio: É muito “abra a sua mente” e “escute mais as pessoas que estão com você no dia a dia”. Uma coisa que eu aprendi bastante é que não tem que ser tudo certinho como está escrito no Scrum guide, e eu vou ter que seguir assim. Mas eu precisei levar muita “porrada” para entender que tinha que ser mais ouvinte da minha equipe,  mais paciente, saber o que eles estão passando e escutar o que é melhor para equipe e não pensar somente no que eu vou implantar dentro da squad. Então é ser mais ouvinte, ser mais paciente e estar mais aberto para as novas opiniões. Outra coisa que aprendi é tomar cuidado com as críticas porque isso acaba gerando certo estresse também dentro da equipe, e o turn-over das pessoas. 

Luiz: Esse parte de seguir o Scrum guide é muito comum. Tem até uma metodologia chamada Shuhari, que é utilizada nas artes marciais, onde você imita alguém que já tem uma experiência; a princípio sem saber porquê, vai só treinando “socos” e “chutes” mesmo. Só com o tempo a pessoa vai entendendo e vai colocando o jeitinho dela. Acho que acontece algo semelhante com agilidade: no primeiro momento, quando tudo é novo, quando se está em um ambiente ou em uma equipe que ainda não utiliza o agile, a gente segue o guia. Então a gente vai fazer daily meeting todos os dias, vai fazer uma Sprint de 2 a 4 Semanas citando Scrum como exemplo, vai fazer uma review, uma retrospectiva no final de cada Sprint, porque é isso que alguém que definiu isso e registrou isso em um guia escreveu.

Mas a partir do momento que você vai avançando, vai ganhando experiência e o time vai entendendo, começa a utilizar mais ferramentas e práticas. Daí começa a segunda fase do Shuhari, é quando você quebra a regra e começa a colocar o seu jeito ali. Porque agora as coisas estão dando certo, e lá na frente, quando você dominar mais ainda a cultura se transforma, e tudo fica muito mais intrínseco e menos visível, porque é mais natural. Então esse processo é natural em tudo na vida que a gente vai começar. Primeiro copiando alguém que tenha mais experiência até que você se desenvolva, e aí deixa de ser um “júnior”, para virar um “pleno”; depois você se transforma em um “sênior”, que é quando você ainda ajuda as pessoas a se desenvolverem também. 

Rodolpho: Tem um outro ponto que lembrei agora que talvez seja interessante para quem começa. Se for um time novo ou às vezes um time já existente, eu acho que tem que começar do mais básico possível. Nem que seja só mostrar o fluxo de trabalho do time, um quadro mostrando o fluxo e como identificar gargalos; nem que seja só isso e, com o tempo, vai implementando outras coisas ali que o Scrum guide e a metodologia kanban direcionam a pensar, pensamento enxuto ou coisa do tipo.

Então começar com o básico, ter ali um fluxo atual do time onde você demonstra onde está o gargalo, acho que com o tempo o time vai criando a necessidade de se conversar mais. Se isso acontecer, então a gente pode acabar deduzindo uma daily meeting. Se o time tem a necessidade de se planejar mais porque está vendo ali no fluxo que tem muito gargalo, tem muito problema parado, então você começa a planejar mais. Ou seja, o ideal é começar aos poucos mesmo. Querer abraçar tudo de uma vez só é complicado.

Assista ao vídeo com a íntegra do bate-papo:

https://www.youtube.com/watch?v=s5Ct6gYSuFg&t=45s

 

Experimente agora, grátis!