Mestres, Overdose e Efeito Pendular na Produção de Software

Na onda do ágil, dos mestres (Agile Master, Kanban Master, Scrum Master), como fica a realidade na produção de software?

Compartilhe!

No início tudo era produzir software no prazo, no custo e dentro do escopo…

galaxia-objetivo-desenvolvimento-software

… e hoje continua sendo. Todo produto uma hora tem que ser entregue, tem orçamento limitado, e escopo macro definido.

Desculpe se lhe chateei. ;(

O efeito manada

Na área de produção de software (que “antigamente” chamávamos Engenharia de Software) atualmente estamos tendo overdose de conceitos, frameworks, métodos etc.

Agile, Lean, Kanban, Scrum etc. Muitos “etc”.

Melhoria Contínua (Kaizen do Lean, ou PDCA da administração clássica) é fundamental. Se não há a perfeição, há a oportunidade de buscá-la. E devemos insistir.

Mas como na natureza, a transformação só deve ocorrer após o fim de um ciclo natural, e não no meio dele.

Precisamos pensar sobre a ordem natural das coisas, pois se não há fluidez na ordem natural, fatalmente ocorrerá a desordem natural.

Talvez você pode dizer que “do caos emerge a ordem”. Mas até o caos tem ordem, a matemática pode nos ajudar a provar isso.

Mas não é da Teoria do Caos que estou falando. Estou falando de equilíbrio.

Mestres e Discípulos

mestre japones

Nessa onda de “mudança daquilo que ainda nem mostrou a que veio”, junto com novos modelos de trabalho temos novos papéis dos profissionais envolvidos.

E quantos novos papéis. Oportunidade para mestres temos aos montes.

Acabo de ver um debate no Linkedin sobre “existe Kanban Master?”.

Temos até “Agile Master”.

E tudo começou com o “Scrum Master”.

Numa cultura de aprendizado constante, de mudanças diárias, não sei se dá para termos “Mestres” num contexto onde nada se estabelece, e tudo é um tanto efêmero.

Não dá nem tempo de alguém se masterizar. 🙂

 

/* ser mestre demanda ser absoluto (ou quase) em alguma área de conhecimento. No conceito humano, no mínimo 10.000 horas de prática, segundo alguns autores */

Porque pais e mães de primeira viagem (primeiro filho) sofrem muito na adaptação, mas quando os filhos tem 15 anos, 20 anos, as coisas suavizam?

Porque Warren Buffett fala que devemos investir (investir demanda anos de paciência) e não especular? Que devemos aplicar apenas em nichos que conhecemos (é o Gemba do Lean Thinking)?

Porque os melhores técnicos de futebol dizem que “em time que está ganhando não se mexe”? Porque clubes de futebol que mantém o elenco durante várias temporadas, estatisticamente mantém os melhores resultados?

Porque a masterização demanda tempo, muito tempo.

“Overdose” de melhores práticas tirando o foco

Estamos ficando dopados (e não que isso seja de todo ruim) de Agile, Scrum, Kanban, noestimates, Value Stream, Scrum of Scrum, Business Agility etc.

Ontem ficamos dopados de RUP, CMM/CMMI, (levemente de) de XP, MSF etc.

E muitos mestres e entusiastas estão polarizando as coisas em velocidade descomunal, onde “A é ruim, B é ótimo”, mas no dia seguinte, “B não presta mais”.

O maior barato (sem duplo sentido aqui ok?) é que quando a onda era CMMI, produzíamos software em “fábricas de software”.

Aí começaram a dizer que software não é “linha de produção”, que fábrica de software é algo contrário ao trabalho criativo e artesanal, que é endurecer demais algo que precisa ser flexível.

Então hoje falamos de esteiras de produção de software, de ágil em escala.

E estamos caminhando para, num futuro de médio prazo, termos a predominância do pensamento lean (Lean Thinking) na produção de software.

E de onde vem o Lean (que eu adoro e acredito demais)?

De uma industria, ou fábrica de carros, chamada Toyota.

fabrica toyota lean kanban

Não sei se dá para evitar todas as “drogas” da agilidade, do pensamento enxuto, da horizontalidade que passa perto da anarquia, mas a mente humana reage a tudo isso com uma natural “perda de foco”.

Num mundo VUCA  perder o foco é quase uma certeza para 99% dos profissionais.

Efeito Pendular – ou 8 ou 80

some-ou-suma-radicalismo-producao-software

“Se algo está péssimo, tem que ficar ótimo”. Eis o lema de muitos.

Não temos paciência para sair do péssimo , ir para o ruim, para o regular, para o bom, para o muito bom, e então chegar no ótimo.

A ansiedade é o mal do século, origem de quase todos os desequilíbrios físicos atualmente (leia-se doenças, se quiser entender mais, procure por somatização).

E a ansiedade é força propulsora da ambição de “hoje péssimo, hoje ainda ótimo”.

/* pivotar é diferente de mudar tudo toda hora */

Mas a natureza não dá saltos. Ela é Kaizen (novamente o Lean que tanto admiro), “de poquin a poquin”, com diz o bom mineiro. 🙂

Isso tudo é o efeito pendular que Aristóteles citou ha alguns anos (uns 2300 atrás ~), ou algo tipo teoria dos ciclos econômicos (que se mantém quase em status de lei ha quase 100 anos) no mundo da produção de software.

teoria-dos-ciclos-economicos-mercado-software

Significa que no fim tudo ficará bem, equilibrado. Mas significa também que até que as coisas melhorem, vamos bater na superfície do vale.

/* leia-se ir do 8 ao 80, e depois ficar perto do 36 */

Voltando na “Engenharia de Software”, avaliemos:

  • Ontem muita documentação, hoje “zero documentação”;
  • Ontem executivos davam a direção, agora a direção “emerge do time”;
  • Ontem foco na qualidade, hoje “errar é parte do jogo e ai de quem achar ruim com o time”;
  • Ontem projetos, hoje produtos;
  • Ontem a empresa tinha que dar lucro, hoje “escopo aberto, orçamento ‘dinâmico’ e fim dos prazos”;
  • Ontem Analista de Sistemas, hoje “partial stack developer”.

/* arrisco-me a dizer que poucos são os desenvolvedores “mestres” (lembre-se das 10.000 horas) em Orientação a Objetos, Baixo Acoplamento e Alta Coesão e coisas elementares que são o 80/20 no valor do software executável produzido */

Concluindo

Penso que é necessário sair um pouco da enxurrada de teoria e focarmos naquilo que importa de fato: a entrega de valor e a diminuição do desperdício (leia-se eficácia e eficiência).

Penso que precisamos conhecer o diferente, para saber se ele nos serve.

Mas se ficarmos apenas no “diferente”, ou entendemos em modo “advanced” que a diferença constante é o status quo e harmonizamos (teoria do caos que citei anteriormente, algo para nosso futuro enquanto humanidade) e assim damos cadência aos empreendimentos da vida, ou então vamos viver de hipóteses que por serem muitas vira bagunça e ficam todas implausíveis, onde os resultados desaparecerão.

Viver de hipóteses é como o que fazemos quando procrastinamos: “puxa, legal, é isso! Amanhã eu começo“.

Ou mais na geração Y (da qual que faço parte): “uau, vou arrebentar, já comecei a implementar! Mas amanhã eu continuo“.

E algumas coisas no mundo moderno não vão mudar tão cedo:

  • Lucro é o fim de qualquer empresa, empresas que não dão lucro quebram;
  • Executivos tem um elefante nas costas e respondem por isso;
  • O que não tem um mínimo de prazo ou metas claras não fica pronto nunca;
  • Projetos tem início meio e fim, mas produtos tem seu início e declínio (vide curva S);
  • Testar idéias é necessário. Errar sem critério alegando “cultura do erro” é falta de ética.
  • Pessoas são orientadas a restrições e premissas, sem isso vira bagunça.
  • Menos é mais, simplicidade é um luxo para qualquer empresa ou pessoa.

E para produzir entrega de valor, a depender do contexto, até waterfall pode ser a melhor opção! 🙂

Nem lá nem cá

Eu enquanto Desenvolvedor quero falar sobre entregas sem pressão inquisitória, quero refatorar código para melhorar o sistema, quero fazer provas de conceito sem olhar para o cronômetro toda hora, quero experimentar novas tecnologias e novas arquiteturas sem achar que estou atrasando a meta do sprint e gastando todo o orçamento do projeto.

E também…

… eu enquanto Gerente de Projetos quero falar sobre entregas sem ficar receoso de magoar quando cobro resultado, quero conduzir o time na direção estratégica dada pelo executivo, quero poder dizer não quando o desenvolvedor quer que eu diga sim, quero ajudar a produzir o resultado sendo parte dele, e não mero espectador.

E eu sou as duas coisas (Gerente de Projetos na CLT, Desenvolvedor no MEI), hoje mesmo (sabadão) fritei para entregar uma funcionalidade “muito retrabalhada” onde o meu cliente disse duas vezes “que eu não entendi bem o que ele quis dizer”… só quem viveu isso sabe o que é, hahahaha…

Vamos refatorando o post, afinal, mudar é necessário, mas de “poquin a poquin”…

Engenharia de Software

  • Antonio Marcos

    Que post Plínio, muito show! Além disso, comentou sobre os testes ( levemente o TDD ) que é uma ótima forma de concretizar uma tarefa dentro de uma responsablidade. Explico… É uma visão pessoal. Então fica aberta a discussão saudável… Se você encarar uma classe como uma entidade de responsabilidade única e seus métodos como tarefas a serem produzidas, o TDD ajuda você no primeiro momento a concretizar as tarefas. Ele te dá um “Norte” de que se você precisa de mais detalhes ou não ( entendimento ) para realizar aquele conjunto de tarefas e garantir que aquela responsabilidade foi atendida. Mas, aí vem a questão que muitos estão negligenciando mais uma vez… Padrões de Projetos, para garantir um maior desacoplamento e maior coesão de nossa arquitetura da solução. Eu gosto da nossa carreira, apesar de ser um desafio constante. Mas não consigo gostar só de um lado da minha carreira. Vejo a importância da análise de sistemas e suas ferramentas, a importância dos padrões de projetos, da UML como uma ferramenta ampla, tanto para negócio como desenvolvimento. Vejo a importância de escrever de forma a respeitar as boas práticas de programação, etc. Para desenvolvedores que usam os dois chapéus, fica muito difícil dissociar esses papéis. Principalmente se passamos algumas noites sobre o teclado, tentando sobreviver com o que mais gostamos de fazer: expressar o que somos e pensamos.

    • Plínio Ventura

      Olá Antonio!

      Realmente, nossa área não é moleza. Não dá para ficarmos sem estudar, refletir, praticar. Devemos ser como filósofos digitais! 🙂

      Sobre o TDD, é um paradigma muito saudável. Pensar primeiro em como testar, para então programar orientado a isso (e garantindo a cobertura dos testes unitários está aderente ao escopo construído) é essencial para práticas como DevOps, por exemplo.

      E sobre os padrões de projeto, o uso racional da UML etc., sem dúvida dão “robustez” a qualquer profissional. Penso que o grande lance é termos uma caixa de ferramentas “sortida”, e usarmos cirurgicamente cada uma, conforme a necessidade demandar.

      Grande abraço!

  • Fabrício Laguna

    Ótimo texto, Plínio.
    As certezas sobre os métodos que servem ou não servem têm ajudado mais aos interesses econômicos dos auto declarados mestres foi que de seus aprendizes.

    • Plínio Ventura

      Olá Fabrício!

      Obrigado pela visita, que bom o conteúdo lhe foi útil. Realmente, e infelizmente, nem sempre a intenção é o resultado com valor, mas o homem/hora que se contrata de consultoria.

      Abraço!