: :
os agilistas

Como usar os conceitos ágeis para sustentar sistemas?

Como usar os conceitos ágeis para sustentar sistemas?

os agilistas
: :
Szuster: Essa questão de sustentação é engraçada porque no fundo esses assuntos convergem quando a gente fala de squads e de frentes digitais. Fale um sobre isso, Felipão.

Felipão: A experiência que eu já tive no assunto, eu dividi em dois aspectos, a pergunta fala sobre como fazer a passagem do bastão de uma feature que acaba de ser entregue pelo time que faz a sustentação. Eu já acho que não deve haver essa passagem de bastão, porque se a gente está falando de um produto, nessa primeira visão, se a gente está falando de um produto, o squad tem que ser o responsável por novos features e por sustentar a aplicação, é uma coisa que a gente já falou até em um episódio anterior, que um backlog de um produto tem que ser composto por feature sim, mas também por bugs, devs técnicos, então a sustentação é feita pelo próprio time. Um bug passa a ser uma história comum do time daquele produto, porque ninguém melhor de estar contextualizado no assunto, ter o conhecimento de causa para sustentar o produto do que o próprio time do produto. Agora quando a gente está falando de aplicações que são legados, já estão em operação e não existe um squad atuando de forma contínua…
Szuster: Só um comentário, então eventuais aplicações talvez aposente…
Felipão: Ter um squad cuidando. Aí sim a gente vai para um ambiente de sustentação centralizado. A experiência que eu já tive em um ambiente de sustentação centralizado fazendo aí um paralelo com o agilismo, o que melhor funcionou foi a gente colocar o time em operação de Lean Kanban, o método mais próximo do Lean Kanban, em que se consiga limitar alguns work in progress, que a gente sabe que na sustentação é às vezes inevitável, mas tentar levar ali o bug, o chamado até o fim. Por que estou falando isso? Porque no início dessa experiência que eu tive na sustentação centralizada a gente elevou muito o número do nosso work in progress, e aí você acaba se perdendo no contexto de um problema que você começou a analisar há uma semana, e a gente convergiu bastante quando entramos em modo Lean Kanban, em que a gente tinha um máximo de work in progress de três por desenvolvedor, três chamados e a gente entrava em um ciclo de às vezes estar parado em uma validação de um usuário, então a gente ficava enchendo o saco do usuário até conseguir realmente colocar aquele…
Szuster: Ir até o fim.
Felipão: Ir até o fim.
Szuster: Não ficar cada um passando o bastão e com uma meta local, vamos
dizer assim.
Felipão: Exatamente.
Szuster: Fechar o chamado na perspectiva dele.
Felipão: Porque no fim acaba acontecendo…
Szuster: Fechar, para resolver o problema.
Felipão: Exato. Se a gente não tiver essa orientação forte em resolver o problema, a gente começa a aumentar muito o work in progress, aumentar muito a fila e começa a fazer fechamento de chamado…
Szuster: à força.
Felipão: À força. O problema não foi resolvido. Então eu vejo mais por esse lado.
Szuster : Só um comentário. Esse primeiro cenário que o Felipão disse, para um squad poder de fato poder assumir a sustentação da frente, pela qual ele é responsável, você tem que estar com o conceito do agilismo ali na veia mesmo, porque primeiro esse squad vai ter que ter espaço para isso no backlog, então alguém que cobra constantemente, alguém que quer uma previsibilidade total e que não aceita que aquele…
Vinição: Não pode ter nenhuma variação em função de um novo problema.
Szuster: É, não pode ter variação, e se aquele time entregou menos… Pensa bem, um time tem que fazer o mais importante, e se num dado momento o mais importante é fazer uma pequena melhoria ou corrigir um bug crítico, aquilo é o mais importante, e o time vai fazer aquilo. Isso exige uma maturidade, vamos dizer assim, de gestão, para entender as variações, e na minha visão também, para isso acontecer de verdade, você tem que estar com uma série de ferramentas de devOps em ação para o time realmente… porque assim, se é um fardo muito grande para aquele time cuidar, vamos supor que se para acessar um ambiente é difícil, para fazer aquilo é difícil, para botar um deploy é difícil. Aí aquilo atrapalha tanto o time que você fala assim “deixa isso para alguém fazer” mesmo sendo mais eficiente, concordam?
Felipão: Se o time está com esse tipo de problema de autonomia, de DevOp de implantação, ele tem um problema até anterior à sustentação, porque provavelmente eles vão estar com esse mesmo problema para poder evoluir.
Szuster: Eu comento isso porque às vezes a causa raiz é essa, se o cara separa é porque assim “é muito ineficiente isso ficar dentro do time”, mas a solução às vezes não é separar, é ir à causa raiz dessas ineficiências.
Felipão: Eu não sei qual é o formato da sustentação aí no caso do Rodrigo, mas um conselho que eu daria para ele é tentar identificar, se for uma sustentação centralizada ele identificar o que é produto ali e começar a transferir a responsabilidade desses chamados de produto para os times de produto de fato.
Szuster: Engraçado, um conselho para o modo tradicional é ficar o mais limpo
possível.
Felipão: Exatamente.
Szuster: E para a frente de produto é trazer para dentro do contexto da frente
de produto.
Felipão: É claro que assim, em equipes descentralizadas existem métodos, como o ITIL, que ajudam também a fazer a gestão. Mas acho que o principal ponto é tentar identificar se tem produto ali no meio e tentar se tornar o mais Lean possível quando a gente está falando de centralizada e quando a gente está falando de produto, é colocar para o produto cuidar.
Vinição: Deixa eu só fazer alguns comentários. Na minha visão, a melhor estrutura é a sustentação estar dentro do squad por um fator crucial que aumenta a responsabilidade intrínseca do time, o time passa a ficar muito mais responsável pelo que ele gera. E essas questões de evolução de DevOps que a gente comentou aqui nascem até porque se a pessoa que faz é a pessoa responsável por no final de semana atender ao chamado, ele vai querer muito automatizar as coisas, melhorar a qualidade do que está entregando, mas há divergências. Se você tem uma variabilidade muito grande de algum produto, o que eu quero dizer com isso, vamos supor que um produto de vez em quando não tem chamado nenhum, vários dias sem chamado, mas de vez em quando tem uma rajada de chamados, ou pequenas demandas. Como lidar com isso? Você vai montar um squad só para isso? É um pouco complicado. Outro aspecto é o seguinte, quando está dentro do squad normalmente há um rodízio, não tem uma pessoa só que é a pessoa da sustentação, porque isso é muito frágil, então as pessoas vão girando. Mas, por exemplo, o Google tem um papel que eles chamam de SRE, que é Site Reliability Engineering, e às vezes têm times que são só desse papel, e o que eles fazem é selecionar as pessoas que têm um perfil adequado para isso, porque normalmente é um papel muito estressante, é o cara que gosta muito da emoção, então eles fazem uma seleção, já li em alguns artigos, própria para isso, a pessoa tem aquele perfil, não liga de ser acionada fora de hora, o cara até gosta. E o que eu estava falando voltando sobre a questão da viabilidade, o que você pode fazer nesse modelo do Google é um modelo mais centralizado, igual o Felipão estava falando. Então talvez você possa acumular produtos que tenham grande variabilidade e normalmente quando você junta muita variabilidade, a variabilidade total diminui, então é uma saída.
Szuster: Essa questão de sustentação é engraçada porque no fundo esses assuntos convergem quando a gente fala de squads e de frentes digitais. Fale um sobre isso, Felipão.
Felipão: A experiência que eu já tive no assunto, eu dividi em dois aspectos, a pergunta fala sobre como fazer a passagem do bastão de uma feature que acaba de ser entregue pelo time que faz a sustentação. Eu já acho que não deve haver essa passagem de bastão, porque se a gente está falando de um produto, nessa primeira visão, se a gente está falando de um produto, o squad tem que ser o responsável por novos features e por sustentar a aplicação, é uma coisa que a gente já falou até em um episódio anterior, que um backlog de um produto tem que ser composto por feature sim, mas também por bugs, devs técnicos, então a sustentação é feita pelo próprio time. Um bug passa a ser uma história comum do time daquele produto, porque ninguém melhor de estar contextualizado no assunto, ter o conhecimento de causa para sustentar o produto do que o próprio time do produto. Agora quando a gente está falando de aplicações que são legados, já estão em operação e não existe um squad atuando de forma contínua…
Szuster: Só um comentário, então eventuais aplicações talvez aposente…
Felipão: Ter um squad cuidando. Aí sim a gente vai para um ambiente de sustentação centralizado. A experiência que eu já tive em um ambiente de sustentação centralizado fazendo aí um paralelo com o agilismo, o que melhor funcionou foi a gente colocar o time em operação de Lean Kanban, o método mais próximo do Lean Kanban, em que se consiga limitar alguns work in progress, que a gente sabe que na sustentação é às vezes inevitável, mas tentar levar ali o bug, o chamado até o fim. Por que estou falando isso? Porque no início dessa experiência que eu tive na sustentação centralizada a gente elevou muito o número do nosso work in progress, e aí você acaba se perdendo no contexto de um problema que você começou a analisar há uma semana, e a gente convergiu bastante quando entramos em modo Lean Kanban, em que a gente tinha um máximo de work in progress de três por desenvolvedor, três chamados e a gente entrava em um ciclo de às vezes estar parado em uma validação de um usuário, então a gente ficava enchendo o saco do usuário até conseguir realmente colocar aquele…
Szuster: Ir até o fim.
Felipão: Ir até o fim.
Szuster: Não ficar cada um passando o bastão e com uma meta local, vamos
dizer assim.
Felipão: Exatamente.
Szuster: Fechar o chamado na perspectiva dele.
Felipão: Porque no fim acaba acontecendo…
Szuster: Fechar, para resolver o problema.
Felipão: Exato. Se a gente não tiver essa orientação forte em resolver o problema, a gente começa a aumentar muito o work in progress, aumentar muito a fila e começa a fazer fechamento de chamado…
Szuster: à força.
Felipão: À força. O problema não foi resolvido. Então eu vejo mais por esse lado.
Szuster : Só um comentário. Esse primeiro cenário que o Felipão disse, para um squad poder de fato poder assumir a sustentação da frente, pela qual ele é responsável, você tem que estar com o conceito do agilismo ali na veia mesmo, porque primeiro esse squad vai ter que ter espaço para isso no backlog, então alguém que cobra constantemente, alguém que quer uma previsibilidade total e que não aceita que aquele…
Vinição: Não pode ter nenhuma variação em função de um novo problema.
Szuster: É, não pode ter variação, e se aquele time entregou menos… Pensa bem, um time tem que fazer o mais importante, e se num dado momento o mais importante é fazer uma pequena melhoria ou corrigir um bug crítico, aquilo é o mais importante, e o time vai fazer aquilo. Isso exige uma maturidade, vamos dizer assim, de gestão, para entender as variações, e na minha visão também, para isso acontecer de verdade, você tem que estar com uma série de ferramentas de devOps em ação para o time realmente… porque assim, se é um fardo muito grande para aquele time cuidar, vamos supor que se para acessar um ambiente é difícil, para fazer aquilo é difícil, para botar um deploy é difícil. Aí aquilo atrapalha tanto o time que você fala assim “deixa isso para alguém fazer” mesmo sendo mais eficiente, concordam?
Felipão: Se o time está com esse tipo de problema de autonomia, de DevOp de implantação, ele tem um problema até anterior à sustentação, porque provavelmente eles vão estar com esse mesmo problema para poder evoluir.
Szuster: Eu comento isso porque às vezes a causa raiz é essa, se o cara separa é porque assim “é muito ineficiente isso ficar dentro do time”, mas a solução às vezes não é separar, é ir à causa raiz dessas ineficiências.
Felipão: Eu não sei qual é o formato da sustentação aí no caso do Rodrigo, mas um conselho que eu daria para ele é tentar identificar, se for uma sustentação centralizada ele identificar o que é produto ali e começar a transferir a responsabilidade desses chamados de produto para os times de produto de fato.
Szuster: Engraçado, um conselho para o modo tradicional é ficar o mais limpo
possível.
Felipão: Exatamente.
Szuster: E para a frente de produto é trazer para dentro do contexto da frente
de produto.
Felipão: É claro que assim, em equipes descentralizadas existem métodos, como o ITIL, que ajudam também a fazer a gestão. Mas acho que o principal ponto é tentar identificar se tem produto ali no meio e tentar se tornar o mais Lean possível quando a gente está falando de centralizada e quando a gente está falando de produto, é colocar para o produto cuidar.
Vinição: Deixa eu só fazer alguns comentários. Na minha visão, a melhor estrutura é a sustentação estar dentro do squad por um fator crucial que aumenta a responsabilidade intrínseca do time, o time passa a ficar muito mais responsável pelo que ele gera. E essas questões de evolução de DevOps que a gente comentou aqui nascem até porque se a pessoa que faz é a pessoa responsável por no final de semana atender ao chamado, ele vai querer muito automatizar as coisas, melhorar a qualidade do que está entregando, mas há divergências. Se você tem uma variabilidade muito grande de algum produto, o que eu quero dizer com isso, vamos supor que um produto de vez em quando não tem chamado nenhum, vários dias sem chamado, mas de vez em quando tem uma rajada de chamados, ou pequenas demandas. Como lidar com isso? Você vai montar um squad só para isso? É um pouco complicado. Outro aspecto é o seguinte, quando está dentro do squad normalmente há um rodízio, não tem uma pessoa só que é a pessoa da sustentação, porque isso é muito frágil, então as pessoas vão girando. Mas, por exemplo, o Google tem um papel que eles chamam de SRE, que é Site Reliability Engineering, e às vezes têm times que são só desse papel, e o que eles fazem é selecionar as pessoas que têm um perfil adequado para isso, porque normalmente é um papel muito estressante, é o cara que gosta muito da emoção, então eles fazem uma seleção, já li em alguns artigos, própria para isso, a pessoa tem aquele perfil, não liga de ser acionada fora de hora, o cara até gosta. E o que eu estava falando voltando sobre a questão da viabilidade, o que você pode fazer nesse modelo do Google é um modelo mais centralizado, igual o Felipão estava falando. Então talvez você possa acumular produtos que tenham grande variabilidade e normalmente quando você junta muita variabilidade, a variabilidade total diminui, então é uma saída.

Descrição

Este conteúdo especial é um corte de um dos episódios mais populares entre nossos ouvintes: o #59, "Perguntas e Respostas". Passa mês, passa ano, e ele segue como um sucesso de audiência, se mostrando continuamente relevante para a nossa comunidade agilista. Neste corte, selecionamos a resposta de Szuster, Vinição e Felipão para a seguinte pergunta: "Como usar os conceitos ágeis para sustentar sistemas?". Você tem a mesma dúvida? Então, dá o play! Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no Instagram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos! See omnystudio.com/listener for privacy information.