: :
os agilistas

Não existe solução livre de problemas

Não existe solução livre de problemas

os agilistas
: :

SZUSTER: Então, na verdade, esse autor faz uma provocação que é assim, gente, o que causou aquela falha de segurança foi uma coisa sistêmica muito maior que é qual? É aquela empresa não entender que pensar em um negócio significa, em certos momentos, priorizar ações totalmente técnicas, e que essas ações não são fruto de incompetência, elas são frutos de escolhas que vão sendo feitas e que o negócio está junto ali tomando essas decisões. Uma empresa dessas que faz isso, obviamente que ela está muito mais digital e percorrendo esse mundo novo do que uma empresa onde a área de negócios insiste em se manter ignorante desse tipo de assunto, e fica falando: “Eu tenho é que pedir as coisas, as features aqui, esses caras têm que me der essas features”; vocês têm algum exemplo aí bacana que possa ilustrar isso? 

FELIPE: É legal essa questão que você colocou, do que um squad realmente, que tipo de entrega um squad pode fornecer, e como a gente gosta muito de citar o agilismo na prática, eu vou dar um exemplo bem recente de um processo de coaching que eu fui fazer com um dos nossos times. O time estava claramente tenso, estava nervoso, e eu fui analisar a causa-raiz era justamente essa relação dificultada com o negócio, de que o negócio só tinha expectativa de que as entregas deveriam ser novas features. Quando eu fui analisar um pouco mais profundamente o que tinha no backlog para o time construir, tinha alguns débitos técnicos, e fazendo um parênteses pontuando o que é um débito técnico, um débito técnico são decisões possíveis, plausíveis e que o time toma para tentar fazer alguma entrega, às vezes porque tem alguma restrição de data ou porque às vezes a gente quer colocar alguma coisa à prova mais cedo, ou porque naquele momento a complexidade para se construir toda a solução técnica completa não é compatível com a realidade de número de usuário, de escala que o sistema tem que tomar, então, toma-se algumas decisões arquiteturais e armazena-se alguns débitos técnicos, isso metodologicamente é possível e aceitável. Mas, então, o time tinha alguns débitos técnicos no backlog e alguns bugs de fato, eu até brinco em algumas palestras que eu dou, eu também não vou lembrar qual o livro, mas algum livro do Kent Beck. 

SZUSTER: Você é mais novo que eu. 

SZUSTER: É, realmente não deveria estar com esse problema de memória. Mas em algum livro do Kent Beck sobre Test Driven Development que eu li, onde ele falava assim: “A gente tem que aceitar que não existe sistema livre de bug, eles só não foram encontrados ainda”; então, se um dos pais do agilismo e do desenvolvimento orientado a teste coloca algo dessa forma, a gente tem que aceitar que bug é inerente à aplicação e à construção. 

SZUSTER: Só um comentário rapidinho, só. Acho, assim, que a pessoa tem que entender o modelo econômico por trás disso, né? 

VINICIUS PAIVA: É isso que eu ia falar. Por exemplo, é meio absurdo pensar que a questão de risco, que é muitas vezes até, não falar que é fácil, mas é plausível de você transformar aquele risco, economicamente, em grana. O cost of the lay que alguns autores de Lean falam. Então, assim, é claro que a decisão deveria ser orientada a isso, mas isso eu acho que tem muita a ver, até o Szuster fala, em alguns parênteses dele ele fala de um padrão sistêmico do seeking the wrong goal, de buscar um objetivo errado. Se o objetivo for só feature, porque o negócio é ignorante em falar outra coisa que não seja feature, então você vai, realmente, nunca você vai priorizar uma questão de débito técnico, por exemplo, que vai levar a um risco muito grande, entendeu? 

FELIPE: Exatamente. Não, e aí nós temos duas possibilidades, dando sequência no exemplo, ou você vai realmente deixar de priorizar a solução de um risco ou de um débito técnico ou de um bug, que pode recair nesse exemplo que o Szuster deu, no futuro você ser engolido por esse débito, ou acontece o que aconteceu nesse exemplo que eu estava dando aqui, o time acabava absorvendo todo o ônus de solução. Porque se você tem um time que realmente é comprometido, eles não vão aceitar que o sistema continue com alguns bugs. 

SZUSTER: Eles vão ficar igual uns doidos tentando. 

FELIPE: Eles vão ficar uns malucos tentando absorver todo o ônus. 

SZUSTER: E ao mesmo tempo. 

FELIPE: E ao mesmo tempo tentando criar as novas features que foram priorizadas pelo negócio. 

VINICIUS PAIVA: Mas tem limites, né? 

FELIPE: Isso é fato. Isso tem um limite, porque, o que acontece? Aquele time realmente comprometido vai começar a trabalhar depois do horário, vai começar a trabalhar final de semana para tentar carregar tanto o peso das novas features quanto os débitos técnicos que eles não concordam em deixar desenrolar. E isso tem um impacto muito grande no médio prazo, o time estafa e inclusive a qualidade das novas features começa a descer. Então você cria um problema sistêmico muito grande. 

SZUSTER: Então, na verdade, esse autor faz uma provocação que é assim, gente, o que causou aquela falha de segurança foi uma coisa sistêmica muito maior que é qual? É aquela empresa não entender que pensar em um negócio significa, em certos momentos, priorizar ações totalmente técnicas, e que essas ações não são fruto de incompetência, elas são frutos de escolhas que vão sendo feitas e que o negócio está junto ali tomando essas decisões. Uma empresa dessas que faz isso, obviamente que ela está muito mais digital e percorrendo esse mundo novo do que uma empresa onde a área de negócios insiste em se manter ignorante desse tipo de assunto, e fica falando: “Eu tenho é que pedir as coisas, as features aqui, esses caras têm que me der essas features”; vocês têm algum exemplo aí bacana que possa ilustrar isso?  FELIPE: É legal essa questão que você colocou, do que um squad realmente, que tipo de entrega um squad pode fornecer, e como a gente gosta muito de citar o agilismo na prática, eu vou dar um exemplo bem recente de um processo de coaching que eu fui fazer com um dos nossos times. O time estava claramente tenso, estava nervoso, e eu fui analisar a causa-raiz era justamente essa relação dificultada com o negócio, de que o negócio só tinha expectativa de que as entregas deveriam ser novas features. Quando eu fui analisar um pouco mais profundamente o que tinha no backlog para o time construir, tinha alguns débitos técnicos, e fazendo um parênteses pontuando o que é um débito técnico, um débito técnico são decisões possíveis, plausíveis e que o time toma para tentar fazer alguma entrega, às vezes porque tem alguma restrição de data ou porque às vezes a gente quer colocar alguma coisa à prova mais cedo, ou porque naquele momento a complexidade para se construir toda a solução técnica completa não é compatível com a realidade de número de usuário, de escala que o sistema tem que tomar, então, toma-se algumas decisões arquiteturais e armazena-se alguns débitos técnicos, isso metodologicamente é possível e aceitável. Mas, então, o time tinha alguns débitos técnicos no backlog e alguns bugs de fato, eu até brinco em algumas palestras que eu dou, eu também não vou lembrar qual o livro, mas algum livro do Kent Beck.  SZUSTER: Você é mais novo que eu.  SZUSTER: É, realmente não deveria estar com esse problema de memória. Mas em algum livro do Kent Beck sobre Test Driven Development que eu li, onde ele falava assim: “A gente tem que aceitar que não existe sistema livre de bug, eles só não foram encontrados ainda”; então, se um dos pais do agilismo e do desenvolvimento orientado a teste coloca algo dessa forma, a gente tem que aceitar que bug é inerente à aplicação e à construção.  SZUSTER: Só um comentário rapidinho, só. Acho, assim, que a pessoa tem que entender o modelo econômico por trás disso, né?  VINICIUS PAIVA: É isso que eu ia falar. Por exemplo, é meio absurdo pensar que a questão de risco, que é muitas vezes até, não falar que é fácil, mas é plausível de você transformar aquele risco, economicamente, em grana. O cost of the lay que alguns autores de Lean falam. Então, assim, é claro que a decisão deveria ser orientada a isso, mas isso eu acho que tem muita a ver, até o Szuster fala, em alguns parênteses dele ele fala de um padrão sistêmico do seeking the wrong goal, de buscar um objetivo errado. Se o objetivo for só feature, porque o negócio é ignorante em falar outra coisa que não seja feature, então você vai, realmente, nunca você vai priorizar uma questão de débito técnico, por exemplo, que vai levar a um risco muito grande, entendeu?  FELIPE: Exatamente. Não, e aí nós temos duas possibilidades, dando sequência no exemplo, ou você vai realmente deixar de priorizar a solução de um risco ou de um débito técnico ou de um bug, que pode recair nesse exemplo que o Szuster deu, no futuro você ser engolido por esse débito, ou acontece o que aconteceu nesse exemplo que eu estava dando aqui, o time acabava absorvendo todo o ônus de solução. Porque se você tem um time que realmente é comprometido, eles não vão aceitar que o sistema continue com alguns bugs.  SZUSTER: Eles vão ficar igual uns doidos tentando.  FELIPE: Eles vão ficar uns malucos tentando absorver todo o ônus.  SZUSTER: E ao mesmo tempo.  FELIPE: E ao mesmo tempo tentando criar as novas features que foram priorizadas pelo negócio.  VINICIUS PAIVA: Mas tem limites, né?  FELIPE: Isso é fato. Isso tem um limite, porque, o que acontece? Aquele time realmente comprometido vai começar a trabalhar depois do horário, vai começar a trabalhar final de semana para tentar carregar tanto o peso das novas features quanto os débitos técnicos que eles não concordam em deixar desenrolar. E isso tem um impacto muito grande no médio prazo, o time estafa e inclusive a qualidade das novas features começa a descer. Então você cria um problema sistêmico muito grande. 

Descrição

Este conteúdo é um corte do nosso episódio: “#13 - Ignorância Intencional”.

Nele, refletimos sobre como é importante que o time e o cliente entendam que o objetivo do negócio está além da entrega de features. Aprender a lidar com os débitos técnicos que vão surgir e assumir algumas escolhas inteligentes durante o processo, garantem que a geração de valor não seja comprometida. Ficou curioso? Então, dá o play!

Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão na nossa página do Linkedin ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!

Nos acompanhe pelas redes sociais e assine a nossa newsletter que chega todo mês com os assuntos quentes do agilismo através do site.

See omnystudio.com/listener for privacy information.