Desenvolvedores que sabem dizer NÃO. Você é um deles?

Qualquer semelhança com o mundo real.. Não é mera concidência.

Marco (o gerente ansioso, na segunda-feira) – Eu preciso desta funcionalidade entregue até Sexta-Feira. É ordem do cliente!

Bernardo (o desenvolvedor) – Hmm. Marco, sei não. Esta funcionalidade lida com três itens regulatórios, uma nova aba com 30 campos e um relatório complexo. E eu ainda preciso testar tudo isso e cuidar da implantação no nosso ambiente de nuvem.

Marco (o gerente mais ansioso ainda) – Olha. Eu REALMENTE preciso desta funcionalidade realmente para Sexta-Feira. O prazo já está dado. Faça o que for necessário e não me venha com esta bobagem de precisar fazer testes e código limpo.

Bernardo (o desenvolvedor passivo, resmungando..) – Ok, chefe. Eu vou tentar!

Marco (aliviado) – Ótimo, então. Estou já no aguardo. 

….

Na sexta-feira…

Marco  – Bernardo, o código já está pronto? Cliente me ligou aqui já.

Bernardo – Ainda não, chefe. Mal consegui terminar o cadastro. E tenho apenas o protótipo do relatório. E o Cauã ainda está testando o cadastro.

Marco – P#@*$ Bernardo. Você não consegue cumprir prazos. Que m*#&$! O que vou dizer para o cliente?

Bernardo – Olha. Eu disse apenas que ia tentar. E não meu culpe por isso porque o requisito veio incompleto, o analista financeiro do cliente não tinha disponibilidade para tirar minhas dúvidas. Não é minha culpa!!!

E mais uma pequena tragédia da vida real da TI ocorre.

O que aconteceu aqui?

  • Se você é um desenvolvedor, você vai pensar que a culpa é do chefe malvado e opressor. E isso não é um problema do pobre desenvolvedor, que fez o seu melhor.
  • Se você é um gerente, você vai pensar que o problema é do desenvolvedor desmazelado e sem compromisso.

Mas vamos sair para a TI por um momento.

Você entra em um Uber e precisa cruzar o centro da sua cidade. Você precisa estar no seu compromisso em 10 minutos. Mas o motorista sabe que isso não é possível, pois isso leva 30 minutos no horário da tarde. E você como cliente pode protestar e dar um soco no capô do carro e dizer. P*##&#…. eu preciso estar lá em 10 minutos. E ainda assim qualquer motorista responsável irá dizer que isso não é aceitável. E tentar ir mais rápido não irá mudar a situação.


Do; or Do Not. There is no Try!

Diga Sim ou… Diga Não.

O que o desenvolvedor deveria ter feito?

  • Dizer sim, se ele possui uma experiência com este tipo de demanda e se sente bastante confortável com os prazos.
  • Ou dizer que ele não consegue entregar este escopo no prazo estabelecidor.

“Mas isso não é meu problema” …. pode pensar um desenvolvedor. “A culpa é do meu chefe”.

Sinto informar, mas é você que está sendo demandado. E então é sua obrigação ética dizer se a tarefa é viável ou não.

Se fazer de vítima (passivo) e depois ficar putinho na Sexta-feira (agressivo) é atitude imatura do esterótipo profissional passivo-agressivo. Isso demonstra, no mínimo, um quociente emocional ainda que precisa ser desenvolvido. Para não dizer um quarto palavrão no meu texto, que seria muito deselegante.

Entendi…  Então preciso apenas dizer Não!?

A resposta é… Não.

É fácil dizer Não e não fornecer opções. Qualquer criança de 6 anos faz isso. Mas enquanto profissional pleno você deve apresentar opções. E isso envolve negociações e encarar sem medo o conflito momentâneo com o seu chefe.

Bernardo (desenvolvedor responsável): Olha, Marco. Sexta-Feira não é aceitável. Eu preciso fazer a modelagem de dados, o protótipo de telas, a implementação do código. Preciso limpar dúvidas de regras de negócio com o cliente e isso vai demandar 4 horas apenas de reuniões. E preciso fazer os testes de unidade, refatorar o código, preparar a implantação na EC2 e coordenar os testes com o Cauã (Analista de testes) e com o time da infraestrutura.

Marco (gerente ansioso): Testes de unidade. Refatoração. Isso é frescura de desenvolvedor Nutella! ha ha…  E ..hmmm… podemos envolver o Cauã apenas na Sexta-Feira e pular pode parte dos testes do relatório, não? E você pode fazer horas extras novamente! Tenho certeza que sua esposa irá entender a gravidade da situação

Bernardo (o desenvolvedor responsável):  Não fazer testes é gerar débito técnico. Você sabe, Marco, pela experiência do ano passado o que acontece quando envolvemos o time de testes apenas no final da demanda. E não criar a automação de testes de unidade vai gerar efeito muito ruim em médio prazo. E tudo isso vai afetar a imagem do produto e da nossa empresa.

Bernardo (o desenvolvedor responsável): E veja. Insistir em fazer horas extras em base continuada não irá melhorar a sirtuação. Você e eu sabemos que pessoas cansadas inserem mais defeitos no código. Já estou com 15 horas no banco de horas neste mês e não posso comprometer mais o tempo com meus filho e minha esposa.

Bernardo (o desenvolvedor responsável): Ao mesmo tempo … podemos buscar negociar com o cliente o escopo. Também fiz uma estimativa detalhada aqui com o João e a Marina e vi que podemos trabalhar primeiro na parte regulatória e negociar a nova aba com os dados adicionais que ele está pedindo. E podemos fazer uma consulta momentânea para exibir os dados centrais do relatório que ele está pedindo. E com isso podemos buscar negociar a outra aba do cadastro e o relatório para a próxima semana.

Marco (o gerente ainda ansioso): E então você me entrega isso na Sexta-Feira!

Bernardo: Sem problemas, chefe! 

O que aconteceu aqui?

O nosso desenvolvedor trouxe a realidade para a sala. Ele não removeu da sua lista as atividades essenciais, como testes de unidade ou refatoração. Ele sabe que isso seria irresponsável pois somente traria passivo técnico para ele e para o time. Ele fez um trabalho de estimativas com o time. E ele negociou o escopo e apresentou alternativas para a sua chefia.

Mas… eu tenho medinho de contestar com o meu chefe!!

Sim. Quanto tinha seis anos, eu também tinha medo de contestar meu pai. Mas quando você é adulto, você precisa ser responsável pelos seus atos.

E se você é um desenvolvedor responsável você precisa sim negociar e tomar atitudade responsáveis na hora de fornecer compromissos. Por experiência ao longo dos meus últimos 25 anos em TI, observo que a solução simples “Dizer sim” pode gerar um conforto momentâneo, mas o problema irá voltar. Muito pior e ainda sim teremos uma situação muito desagradável.

Negociar pode também ser desagradável. Você pode ter medo de ser repreendido. Você pode ter medo de ser despedido. Você pode ter medo do seu chefe ficar com raiva de você. Mas por experiência vejo que bons gerentes não despendem profissionais que contestem seus pedidos. Eles despedem profissionais que falham continuamente na entrega dos seus acordos.

E conheço vários bons gerentes que conheço esperam que os desenvolvedores saibam contestar. Eles passam a respeitar aqueles profissionais, muito mais que os passivos-agressivos que somente sabem resmungar e criticar o chefe na hora do almoço com seus coleguinhas de 6 anos de idade.

E saber contestar envolve:

  • Estudar com o profundidade o problema sendo dado;
  • Realizar diagnósticos precisos;
  • Apresentar alternativas;
  • Buscar soluções ganha ganha.

Mas… você não conhece o meu chefe! E aqui na minha empresa é diferente…

Talvez sim. E apesar disso você não irá cruzar o centro da capital do seu estado em 10 minutos no horário de rush. Não de carro. E dizer sim de forma ingênua não irá resolver o seu problema.

Ser transparente, que por acaso é um dos pilares dos métodos ágeis, é o caminho a ser seguido.

E onde aprendo a negociar com o meu gerente? No SEBRAE?

Para fazer negociações de desenvolvimento de software, não, infelizmente.

Recomendo duas leituras obrigatórias para o desenvolvimento emocional de todo bom desenvolvedor. O primeiro discute como a importância da atitude ética, técnicas de negóciação e como lidar com a natural pressão gerencial em toda empresa.

Já o livro abaixo é um dos cinco melhores que já tive a oportunidade de ler em minha vida e teve profunda influência no meu modo de pensar em TI. Ele irá lhe trazer uma visão sóciotécnica muita rica sobre o que é trabalhar em TI e 50 ferramentas para você usar no seu dia a dia de trabalho para bater as pressões de tempo que a realidade corporativa nos traz.

Quando a circunstância é boa, devemos desfrutá-la; quando não é favorável devemos transformá-la e quando não pode ser transformada, devemos transformar a nós mesmos, Victor Frankl

 

Maturidade 5 em Métodos Ágeis – Em busca da Anti-Fragilidade

Neste último artigo sobre um modelo de maturidade em métodos ágeis, iremos descrever como reduzir a fragilidade organizacional.

A figura abaixo mostra um esquema com níveis de maturidade organizacional em métodos ágeis, ao longo das perspectivas de times, ritos, entregas e qualidade. O nível 1 mostra uma organização mais frágil. Os níveis intermediários e avançados mostram organizações que não são mais frágeis.

 

ModeloMaturidadeMetodosAgeisv2
Melhoria contínua em métodos ágeis [Imagem maior]

A fragilidade organizacional é aqui definida aqui como aquele tipo de organização onde os eventos negativos provocam efeitos devastadores.

Um exemplo – A Anti-Fragilidade para Times

Um exemplo de fragilidade é uma organização que tenha um time baseado no modelo comando e controle. Neste modelo, existe a figura de um gerente forte e subordinados que cumprem comandos, com baixa interação entre si. Este modelo é frágil, pois pode ser abalado por várias questões tais como:

  • Uma provável baixa capacidade do gerente de lidar com todos os problemas do dia a dia;
  • Uma baixa capacidade de aprendizado dos comandados devido a sua baixa comunicação (não é tão comum encontrar pessoas que aprendam sozinhas);
  • Uma baixíssima resiliência a qualquer evento que afete o gerente (ausências no dia a dia ou faltas ao trabalho);
  • Um provável colapso do time quando esse gerente deixa a organização.

Ao reconhecer a fragilidade em um time, uma organização pode introduzir mecanismos de resiliência. Ao fazer isso, por exemplo, com mais autonomia para as pessoas, delegação administrativa  e maior comunicação interna, estaremos avançado para um time robusto.

Definimos robustez organizacional aqui como a capacidade de resistir a eventos negativos, que ocorrem em todas organização. No exemplo acima teríamos então a figura forte de um gerente, ao mesmo tempo com mais autonomia e comunicação entre os liderados. Nesse modelo robusto, o time consegue trabalhar sem o gerente e até suportar a sua perda, pois possuem autonomia e se comunicam com frequência.

A robustez parece o objetivo desejável, mas ela não é o contrário da fragilidade. Se a fragilidade fosse um número negativo, a robustez seria o número zero. Isto é, na robustez apenas lidamos com os eventos negativos, mas não geramos oportunidades de ganhos positivos nas incertezas. Times robustos, ao invés, apenas restauram o estado inicial após um incidente negativo.

E aqui entra o conceito da anti-fragilidade. Quando uma organização avança além da robustez, ela se torna anti-frágil. A anti-fragilidade é definida aqui como a resiliência para lidar com eventos negativos e ao mesmo tempo explorar oportunisticamente os eventos negativos e positivos. A anti-fragilidade é o contrário da fragilidade, i.e., é o tipo de organismo que se torna mais forte após as adversidades.

No exemplo de times, definimos então um time anti-frágil como um time auto-organizado.

  • Em times auto-organizados, não existem “gerentes” no sentido clássico. Existem líderes facilitadores que preparam o terreno para o time atuar e fazer o seu melhor coletivamente.
  • Aqui eles organizam as suas tarefas, resolvem os seus conflitos e periodicamente discutem o que funcionou e o que precisa ser aperfeiçoado. Aquilo que não funcionou irá gerar uma agenda de melhoria, que irá fortalecer esse time.
  • Em times auto-organizados, análises de causa raiz são realizadas para lidar com a fonte dos problemas, evitando erros similares futuros e portanto os tornando mais anti-frágeis.
  • Times auto-organizados são generalistas-especialistas e portanto redundantes a absenteísmos e rotatitivades (até um certo ponto). A redundância é uma das propridades desejadas em sistemas anti-frágeis.
  • Finalmente, time auto-organizados promovem e resolvem conflitos através de uma cultura permanente de feedbacks estruturados. Isso limpa arestas, problemas de relacionamento e cria extrema confiança entre os participantes.

Frameworks gerencias modernos como o Management 3.0  ou a Holocracia tem promovido a formação de times auto-organizados (e mais anti-frágeis que os tradicionais times de mercado). O  caso Zappos, que citamos em um post anterior dessa série, é um exemplo emblemático do uso da holocracia em uma empresa que fatura mais de 1 bilhão de dólares por ano.

Um outro exemplo – A Anti-Fragilidade para a Qualidade de Produtos

Um exemplo de qualidade frágil é um time de desenvolvimento de software que entrega produtos em produção com muitos defeitos e por isso tem boa parte da sua agenda ocupada com incidentes críticos no ambiente de produção.

Ao mesmo tempo, se esse time reconhecer a fragilidade, criar uma consciência de testes e começar a trabalhar em pequenos instrumentos como refatoração, testes de unidade e TDD, essa mesma organização pode avançar do mundo da fragilidade para a robustez.

Uma organização robusta para testes e qualidade parece apropriada, mas ela simplesmente tolera até certo nível os riscos negativos que ocorrem no desenvolvimento e manutenção dos seus produtos. No exemplo de qualidade acima, ela é aquela que escreve testes e os automatiza para lidar com a imprevisibilidade ambiental, que sempre irá acontecer. (exemplo: hardwares ou banco de dados sempre falharão em algum momento). Ao mesmo tempo, a robustez não cria inovação e não usa as oportunidades positivas que também se apresentam (assim como as negativas).

Nesse mesmo exemplo de qualidade, um time pode perceber que as práticas de testes podem ser tão poderosas que podem ser usadas para:

  • provocar falhas rapidamente no ambiente com automação de testes (CI/CD) – gerar erros pequenos no começo do produto é benigno e anti-frágil;
  • trabalhar a especificação de requisitos em uma abordagem BDD (Behavior Driven Development). Com o BDD, analistas exploram narrativas de negócio na forma de teste desde o começo do desenvolvimento do produto, reduzindo assim o custo total do desenvolvimento de software e ao mesmo capturando problemas que somente seriam descobertos mais tarde no projeto;
  • realizar testes de situações anômalas, como provocar deliberamente a falha de componentes e observar o comportamento do sistema (um exemplo ótimo nesse sentido é o aplicativo CodeMonkey do NetFlix, que derruba aleatoriamente servidores em produção para descobrir e antecipar problemas. Sim, ambiente de produção!);
  • introduzir tolerância a falhas e elasticidade computacional nos seus ambientes de produção, para aproveitar as oportunidades de picos de usuários em eventos futuros incertos.

 

Da fragilidade para a robustez. E da robustez para a anti-fragilidade

A melhoria contínua é o processo contínuo que levou organizações sem maturidade a estágios mais avançados. Mesmo nas organizações mais avançadas quanto ao uso de métodos ágeis, a melhoria contínua é o instrumento que as levam a manter as suas conquistas e buscar ainda mais aprimoramentos.

A melhoria contínua é a mola mestra para sair da fragilidade e avançar para a robustez e anti-fragilidade. Ela envolve sistematizar:

  • a observação ambientel dos eventos (positivos e negativos);
  • o debate regular sobre os acontecimentos positivos e como eles podem ser mantidos no sistema;
  • o debate regular sobre os acontecimentos negativos e como eles podem ser eliminados ou mitigados através de ações de melhoria no sistema.

Se um time realiza este “ritual” periodicamente, ele avança de forma contínua e em breve começa a eliminar as suas fragilidades, uma a uma.

Se pudesse recomendar uma prática inicial para qualquer time que queira se tornar ágil, esta prática seria a retrospectiva Scrum ou o ritual Kaizen em métodos Lean.

A Toyota é um excelente exemplo de como a aplicação sistemática de pequenas melhorias, de forma contínua, pode trazer grandes resultados em longo prazo. De forma geral, a Toyota é reconhecida por produzir carros com maior qualidade, menos defeitos embutidos,  menos horas de pessoas, estoques e plantas menores no processo produtivo do que os seus concorrentes. O livro Toyota Way mostra como essa cultura gerencial fantástica foi trabalhada passo a passo.

Sobre Anti-Fragilidade

É um conceito cunhado por Nicholas Taleb e inicialmente sistematizado na história humana na filosofia estóica (Sêneca, Marcus Aurelius e Epícuro). Um artigo introdutório e interessante sobre o tema pode ser encontrado no artigo Beyond Sissy Resilience: On Becoming Antifragile, que apresenta uma bela figura metafórica sobre o conceito.

antifragile-3

 

Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better ― Nassim Nicholas TalebAntifragile: Things That Gain from Disorder

Maturidade 4 em Métodos Ágeis – Agilidade em Escala Organizacional

Em continuidade ao nosso modelo de maturidade em métodos ágeis, iremos falar da escalabilidade das práticas ágeis em organizações. Vimos que no nível 3 de maturidade as práticas ágeis se tornam consistentes dentro de um projeto. O caminho natural  é o espalhamento dessas práticas por diversos projetos, áreas ou até mesmo toda uma organização.

Desde a nascimento dos métodos ágeis há 20 anos atrás, diversos praticantes enfretaram o problema da escalabilidade de métodos ágeis. Os resultados foram diversos e levaram a um conjunto robusto de frameworks de processo. Compilamos alguns abaixo.

LESS (Large Scale SCRUM)

Large Scale Scrum

Origem: O LESS foi compilado a partir das  experiências  de Craig Larman e Bas Voodle em consultoria e desenvolvimento de produtos em larga escala, com centenas de analistas trabalhando simultaneamente com um objetivo unificado.

Bases conceituais: O LESS tem como pilares o SCRUM, o pensamento Lean e Teoria de Sistemas. O SCRUM fornece ao LESS a estrutura, papéis, ritos e produtos de trabalho. O pensamento Lean fornece a esse framework a sólida base de conhecimento do Sistema Toyota de Produção, incorporado com robustez nesse trabalho. A Teoria de Sistemas traz os elementos poderosos de pensamento tais como efeitos defasados no tempo, ciclos de reforço positivos e negativos, análise de causas raízes e arquétipos organizacionais. O sítio mantido pelos autores é uma rica fonte de informações, congregando ao mesmo tempo conceitos sofisticados e práticas aplicáveis em virtualmente qualquer tipo de projeto.

Livro essencial:  Scaling Agile and Lean Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman e Bas Voodle.

Certificação de entrada: Certified LESS Practicioner


 

SAFe (Scaled Agile Framework)

SAFE 4.0
SAFE 4.0

Origem: O SAFE, que teve a versão 4.0 lançada em Janeiro de 2016, é fruto do trabalho de Dean Leffingwell, direcionado para operar uma área de Tecnologia de Informação em alinhamento ao portifólio organizacional, com o uso de princípios e práticas ágeis e lean.

Bases Conceituais: O SAFE também é fortemente baseado no SCRUM e no pensamento Lean. Entretanto, observamos nesse método também conceitos gerenciais clássicos como o uso de cadeias de valor, portifólio e programas de projetos. O SAFE é um método com uma estrutura mais rígida que outros métodos ágeis, o que traz críticas de agilistas mais extremos e elogios de gerentes que estão acostumados com escolas gerenciais mais tradicionais.

Livro Essencial: Scaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series)

Certificação de Entrada: SAFe Agilist


NEXUS

Nexos Framework
Nexus Framework

 

Origem: O Nexus teve origem a partir da experiência de Ken Schwabber, um dos pais do SCRUM, no desenvolvimento de produtos com vários times Scrum operando em paralelo. O Nexus é mantido pela comunidade Scrum.Org.

Bases Conceituais: O framework Nexus é a sistematização da técnica de escala o Scrum chamada Scrum of Scrums, para projetos que demandem entre 3 e 9 times operando em paralelo. Ele introduz novos papéis e um time especial (Time de Integração) e tem como foco central a integração e coordenação dos esforços de cada time na construção dos incrementos de produtos.

Livro Essencial: Guia do Nexus, já traduzido para o português.

Certificação de Entrada: Scaled Professional Scrum (SPS)


 

Holocracia (Holacracy)

Holocracia
Holocracia

Origem: A Holocracia é um sistema descentralizado de tomada de decisões para que empresas possam criar mecanismos de auto-organização para operar em ambientes dinâmicos e complexos.  

Base Conceitual: A Holocracia tem em seus pilares conceitos sociológicos de organizações de centro vazio, conceitos de auto-organização, teoria da complexidade e teoria da emergência (emergence). A Holocracia não é um framework de TI e tampouco centrada em projetos apenas. Ele lida com o problema de criar organizações anti-frágeis (como definido por Nassib Taleb no seu potente livro Anti-Fragilidade: coisas que se beneficiam da desordem). A Zappos, bilionária empresa americana recentemente comprada pela Amazon, implementa a holocracia como o seu sistema gerencial descentralizado. O portal Holacracy.org é uma vasta fonte de recursos para interessados e praticantes.

Livro Essencial: Holacracy: The New Management System for a Rapidly Changing World 

Certificação de Entrada: Holocracy Practicioner


 

Cada uma desses frameworks possui dezenas de casos documentados e milhares de empresas em todo o mundo que os usam para seu benefício econômico e social. E de volta ao nosso modelo de maturidade, definimos o uso de métodos ágeis em escala organizacional com esses ou outros frameworks similares como sendo o nível 4 de maturidade.

Organizações que atingem esse nível transcedem os projetos de desenvolvimento de software ou infraestrutura. Essas organizações mudam a sua estrutura interna de funcionamento e transcendem as mazelas gerenciais e ineficiências tão fortemente instaladas em muitas organizações ainda presas ao modelo da administração do século XX.

Se você já opera algum método ágil (SCRUM, OpenUP, XP, Entrega Ágil Disciplinada) de forma consistente em seu projeto há mais de 6 meses, talvez exista espaço para você avançar para o nível 4 de maturidade. Algumas dicas rápidas a respeito incluem:

  • estudar o pensamento e práticas lean;
  • estudar práticas de agilidade organizacional citadas nesses frameworks;
  • avaliar os casos de sucesso citados nesses frameworks e se informar como se deu a implementação;
  • promover debates entre times na sua organização que já praticam o SCRUM;
  • começar a incorporar o pensamento lean dentro das suas práticas ágeis;
  • começar a incorporar práticas lean dentro das suas práticas ágeis. Em particular, percebo da minha experiência que práticas lean ligadas à redução de desperdício tem apelo imediato nos gerentes e possuem baixa resistência para adoção.
  • escolher um framework em escala organizacional e começar a incorporar algumas de suas práticas em uma área ou produto de larga escala;
  • buscar apoio de pessoas que já possuam conhecimento mais sólido nesses frameworks.

Os resultados podem ser muito interessantes.

No próximo post, o último dessa série, iremos descrever como organizações podem atingir a excelência através desses métodos através da  mola mestra da melhoria contínua (Maturidade 5).

Pensamento do dia: “If everyone has to think outside the box, maybe it is the box that needs fixing.”, Malcolm Gladwell

Maturidade 1 em Métodos Ágeis – Reconhecimento

Muitos times e organizações desconhecem que eles não desempenham bem. Isso é muito natural e faz parte da limitação humana em compreender o efeito das suas ações no desempenho dos sistemas onde estão inseridos.

Mas o que é um sistema? Convido você a investir alguns minutos do seu tempo para assistir o vídeo abaixo, que apresenta o conceito de forma brilhante: Em Um Mundo de Sistemas (YouTube).

O desenvolvimento de software é também um sistema. E um sistema complexo, infelizmente. Os efeitos das ações tomadas nem sempre geram os efeitos desejados.

Algumas ações comuns na indústria parecem muito naturais e eficazes, tais como:

. especificar todos os requisitos antes que a primeira linha de código seja construída;

. especializar funções e otimizar a comunicação através de emails e documentos;

. testar apenas quando o código estiver pronto;

. reduzir o custo do desenvolvimento de produtos através da contratação de pessoas mais baratas;

. comandar e controlar o trabalho das pessoas;

. adicionar pessoas a um projeto atrasado para colocá-lo no trilho novamente.

Curiosamente, todas estas ações acima geram efeitos contra-intuitivos, i.e, eles tendem a gerar efeitos destrutivos no sistema. Um exemplo (levemente mais elaborado que o vídeo anterior) é mostrado por Craig Larman no diagrama abaixo.

xsystemsp20thinking-15-pagespeed-ic-wns033qpdz

Fonte: Craig Larman – Pensamento Sistêmico

Embora o desenho pareça complicado, ele mostra que existe um efeito defasado no tempo e no espaço na qualidade de um produto a partir da contratação de desenvolvedores baratos, que por sua vez gera um efeito negativo na produtividade do produto. É um exemplo de uma dinâmica negativa, tomada por uma ação que parece correta (contratar mais pessoas, mais baratas, para aumentar a produtividade do produto).

Reconhecer, pois, as armadilhas dos métodos tradicionais é o primeiro ponto para aumentar a maturidade do seu trabalho e do seu time em direção à melhoria de produtividade trazida pelos métodos ágeis. Trabalhar este reconhecimento requer que você comece a desenvolver uma habilidade de “atenção correta”, i.e., perceber conscientemente o que acontece ao seu redor.

Uma dica simples para começar a ter ciência do seu ambiente é o uso de reuniões de lições aprendidas, que deve ser executada em base semanal ou base quinzenal. Nesta reunião você convida todo o seu time e executa a seguinte dinâmica:

  1. Primeiro, o time avalia o que funcionou. Os fatos positivos devem ser capturados e escritos em um quadro branco ou cartolina. Enquanto facilitador, você deve incentivar o seu time a relatar tudo o que foi bom durante o período da avaliação.
  2.  Depois, você avalia o que não foi tão bom. Os fatos negativos também devem ser capturados, mas sem julgamentos ou acusações. Assim como os fatos positivos, os fatos negativos também devem ser escritos em um quadro branco.
  3. Finalmente, cada ação marcada na lista dos fatos negativos deve gerar uma ou mais ações de melhoria. Esta lista é fundamental e será perseguida pelo time no próximo ciclo de trabalho.

Métodos ágeis são desenhados a partir das premissas que o sistema onde um software é desenvolvido não é linear, i.e, a sua dinâmica complexa emerge a partir das interações entre seus atores. Para lidar com este tipo de ambiente, métodos ágeis estão baseados em um processo contínuo de experimentação e adaptação. Instrumentos como as reuniões diárias, reuniões periódicas de demonstraçao (revisão) e a coleta de lições aprendidas (retrospectiva) são exemplos neste sentido.

Iremos abordar os  princípios e práticas fundamentais dos métodos ágeis no nosso próximo post, onde discutiremos o segundo nível de maturidade de métodos ágeis dentro de uma escala de maturidade de adoção de métodos ágeis.

 

 

 

 

 

Aumento de Maturidade em Métodos Ágeis

Muitos times no Brasil tem experimentado o uso de princípios e práticas ágeis no seu trabalho de desenvolvimento de projetos e operação continuada. Entretanto, nem sempre os efeitos originalmente buscados em termos de eficiência de tempo e qualidade são alcançados. Para os mais céticos, isso cria uma “prova” que não funcionam na realidade única e particular de suas empresas. Se o ceticismo alcança a camada gerencial, isso pode significar a morte de iniciativas ágeis, que se tornam para sempre amaldiçoadas como apenas mais um modismo de consultores.

Pessoas que se debruçaram seriamente sobre a dinâmicas de times e projetos em empresas já perceberam que a dinâmica tradicional baseada em hierarquias rígidas, comando e controle, comunicação através de papel e aceitação de defeitos e desperdícios é ineficiente. Taiichi Ohno foi uma dessas pessoas e o resultado do seu sistema alternativo de pensamento pode ser observado no desempenho superior da Toyota através do sua filosofia Toyota Way, conhecido no ocidente como pensamento Lean há quase 50 anos. Kent Beck, Jeff Sutherland, Allistair Cockburn, Craig Larman, Mary Poppendick, entre outros, tem evidenciado há mais de 20 anos que métodos ágeis funcionam em organizações dos mais diversos tamanhos, setores e propósitos.

Para evitar que a desilução se instale e acabe com os movimentos ágeis nascentes na sua organização, é fundamental reconhecer que adotar métodos ágeis não é apenas tomar uma decisão ou comprar um livro. Adotar métodos ágeis é um processo, que demanda tempo e disciplina. Ao mesmo tempo, podemos observar a nossa maturidade ao longo do caminho, comparar com um modelo de referência, reconhecer as fragilidades e então decidir como avançar.

Modelo de Maturidade para Implantações Ágeis

Boa parte da comunidade ágil não usa modelos de maturidade, que tendem a ser prescritivos e ordernar artificialmente as ações futuras de uma TI. O CMMI é um exemplo deste tipo de modelo prescritivo. Ao mesmo tempo, nem todo modelo de maturidade precisa ser prescritivo. Ele pode ser um modelo de reconhecimento crescente da dinâmica da sua organização e uma capacidade crescente de sentir e responder aos fenômenos e incidentes que lá acontecem.

Neste contexto, apresentamos aqui um modelo de maturidade para aumentar a agilidade no seu trabalho, do seu time e até mesmo da sua empresa. O modelo apresenta os seguintes níveis.

0. Desconhecimento (Ignorância)
1. Reconhecimento da Realidade (Princípios)
2. Práticas Ágeis Nascentes em Indivíduos e Projetos
3. Práticas Ágeis Consistentes em Projetos
4. Agilidade em Escala Organizacional
5. Melhoria Contínua em Escala Organizacional

O nível 0 (Desconhecimento) é ainda dominante na maior parte das empresas. Muitas pessoas trabalham mal, geram resultados ruins, não reconhecem o seu desempenho ruim e reclamam que o problema está sempre lá fora. Frases comuns incluem:

  •  “A realidade aqui na minha empresa é diferente. Esta teoria não irá funcionar aqui.”
  •  “Eu trabalho com isso há quase 30 anos. Eu já sei muito bem o que preciso fazer”.
  •  ” Se você conhecesse o meu chefe, saberia que não posso fazer nada.”
  • ”O nosso contrato com o fornecedor nos impede de fazer isso.”
  • ”Eu já sou muito eficiente.”
  • ”O meu time somente funciona na base da pressão.”

O nível 1 (Reconhecimento) acontece quando pessoas começam a reconhecer que existe algo errado. É como alguém com sobrepeso extremo começar a ter ciência que o seu estilo de vida irá matá-lo em poucos anos. Em métodos ágeis, o reconhecimento se dá através da descontrução das crenças limitantes e percepção que:

  • pessoas e interações entre pessoas é o fator crítico de sucesso em projetos;
  • responder a mudanças é vital para lidar com o ambiente dinâmico de projetos e organizações;
  • buscar colaboração com os clientes e resultados ganha-ganha é mais eficiente que regulações e contratos rígidos;
  • entregar produtos em funcionamento em ciclos curtos é um aspecto vital no estabelecimento de confiança com seus clientes internos e externos;

O nível 2 (Práticas Nascentes) acontece quando alguém começa a realizar um experiento em base pessoal ou no seu time. Por exemplo, um desenvolvedor de software começa a fazer “Código Limpo”, que é uma abordagem estruturada para codificar com manutenibilidade, estensibilidade, segurança e reduzidos defeitos. Um outro exemplo é um arquiteto que implanta a prática de “Arquiteturas Evolutivas” no seu trabalho de infraestrutura. Um terceiro exemplo são times que introduzem o conceito de sprints, que são intervalos de tempo fixos usados para construir e demonstrar incrementos de produtos para os seus clientes internos e donos de produto. No nosso exemplo da pessoa com sobrepeso extremo, ela começa a agir e deixa de comer o seu terceiro ou quarto pedaço de pizza antes de dormir. Para avançar para o nível 2, é importante investir em leituras contínuas e um processo enxuto de experimentação (hipótese plausível, experimento curto, análise de resultados e relato das lições aprendidas).

Quando uma organização avança para o nível 3 (Práticas Consistentes), a cultura instalada na organização já reconheceu e aceitou que as novas práticas são melhores e que devem ser mantidas em novos projetos. É como um indivíduo que fumou durante 30 anos, reaprendeu a viver sem nicotina no seu organismo e que agora consegue subir 3 lances de escada sem ficar ofegante. Ele não aceita retornar para o nível de mediocridade que vivia e almeja agora subir 4 ou 5 lances de escada para alcançar o seu escritório e tornar irrelevante o elevador. Em organizações, observamos que este fenômenos em times com alta produtividade, que estabeleceram o seu conjunto de práticas vencedoras e são muito mais produtivos que times similares na mesma organização.

O nível 4 (Agilidade em Escala Organizacional) acontece quando a alta direção incorpora os modelos ágeis como cultura dominante na organização. Este novo organimo agora opera de forma com modelos gerenciais descentralizados com o uso de práticas como por exemplo a Holocracia. A Zappos, que faturou 2 bilhões de dólares em 2014, é um exemplo deste tipo de organização e foi citada em um Revista Forbes – Caso Zappos de 2015 pela revista Forbes. Frederic Laloux, no seu livro – Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness – descreve este tipo de maturidade organizacional como Green Companies, em oposição a empresas Red Companies, que representam o clássico modelo “Comando e Controle”.

O nível 5 (Melhoria Contínua) acontece quando uma organização opera em melhoria contínua, com uma cultura contínua de aprendizado. A prática de cada trabalhador se torna o lema Kaizen do Toyota Way“O meu trabalho é fazer o meu trabalho e melhorar continuamente o meu trabalho”. Aqui as pessoas operam com excelência, que foi trazida por anos da prática da observação, orientação, decisão e análises consistentes.

Observe que este modelo de maturidade não diz quais são as práticas que devem ser adotadas, nem a sua ordem implantação. Mas ele indica que o nível de consciência organizacional e o grau de espalhamento das práticas é que determina maturidade. Iremos abordar estes níveis em detalhes nos próximos artigos e lhe explicar como iniciar essa jornada em nível pessoal e promover esta melhoria para o seu trabalho, os seus times e a sua empresa.

Nível 1 – Reconhecimento (publicado em 08/12/15).

Nível 2 – Práticas Nascentes (publicado em 18/12/15).

Nível 3 – Práticas Consistentes (publicado em 04/01/16).

Nível 4 – Agilidade em Escala Organizacional. (publicado em 14/01/16)

Nível 5 – Em busca da Anti-Fragilidade (publicado em 07/03/16)

Além do SCRUM – Kit Ágil para Agilistas

O Scrum, método ainda pensando em 1986 no seminal artigo The New New Product Development Game, ganhou muito popularidade no Brasil nos últimos anos e disseminou alguns valores e princípios ágeis entre times de projetos em tecnologia da informação. O universo de métodos ágeis, entretanto, é muito mais vasto que as práticas apresentadas pelo Scrum. Compilo neste artigo algumas referências importantes para agilistas que queiram avançar nas práticas e valores de métodos ágeis.

  1. Livro Peopleware, de Tom de Marco. Um clássico escrito nos anos 70 e reeditado em 2013 que apresenta princípios e práticas da liderança efetiva de pessoas em TI e organização de times.
  2. O blog de Allistair Cockburn, que nos apresenta um grande número de informações de primeira linha sobre métodos ágeis e a sua excelente (mas pouco conhecida) metodologia Crystal. Recomendo, sobre este método, o excelente livro Crystal Clear: A Human-Powered Methodology for Small Teams: A Human-Powered Methodology for Small Teams.
  3. A página do método Entrega Ágil Disciplinada, do famoso agilista Scott Ambler, que apresenta um conjunto de práticas que estendem o Scrum para situações complexas de projetos de TI e realidades culturais diversas.
  4. Manufatura enxuta para desenvolvimento de software, que fornece poderosos princípios para redução do tempo de ciclo na entrega de software e redução de desperdícios. Um artigo introdutório ao tema é apresentado aqui e alguns excelentes livros sobre o tema foram escritos pelo casal Poppendick – Agile Toolkit,  Implementing the Lean Software Development e Leading Lean Software Development.
  5. Os artigos do Uncle Bob (Robert Martin), muito sensatos, e os seus clássicos livros Clean Code e Clean Coder.
  6. O trabalho de extensão de métodos ágeis para o nível organizacional descrito no excelente trabalho do método ágil corporativo Scale Agile Framework.

 

O radar técnico da ThoughtWorks, em português

A ThoughtWorks possui uma excelente publicação técnica, com tendências tecnológicas em técnicas, linguagens, plataformas e ferramentas de desenvolvimento de software. Originalmente publicado em inglês, esteve inacessível àqueles não versados na língua do Tio Sam. Felizmente, eles lançaram o novo Radar Técnico também em português.

Neste radar, de Janeiro de 2014, os temas centrais por eles pontuados são:

Alerta e recuperação antecipados em produção – Estamos observando uma infinidade de novas ferramentas e técnicas para capturar logs, monitorar, armazenar e consultar dados operacionais. Quando combinadas com uma rápida recuperação oferecida pela virtualização e automação de infraestrutura, as empresas podem reduzir a quantidade de testes necessários antes da implantação, talvez até mesmo executando os testes no próprio ambiente de produção.

Privacidade versus Big Data – Ao mesmo tempo em que estamos animados com as novas perspectivas de negócio possibilitadas pela coleta exaustiva de dados, também estamos preocupados com o fato de muitas empresas armazenarem grande quantidade de dados pessoais desnecessariamente. Defendemos que as empresas adotem uma atitude de “datensparsamkeit” e armazenem apenas o mínimo de informações pessoais necessárias sobre seus clientes.

O rolo compressor do JavaScript continua – O ecossistema em torno do JavaScript continua evoluindo como uma importante plataforma de aplicação. Muitas ferramentas interessantes têm surgido para testes, gerenciamento de dependências e construção de aplicações JavaScript, tanto do lado servidor, como do cliente.

A fusão do mundo físico e digital – dispositivos de baixo custo, plataformas de hardware aberto e novos protocolos de comunicação estão levando a experiência de usar um computador para mais perto do mundo ao nosso redor, longe das telas. Um grande exemplo é a proliferação de dispositivos vestíveis para rastrear dados biométricos e o suporte de hardware em outros dispositivos móveis, como telefones e tablets, para interagir com os mesmos.

Embora muitas das tecnologias do radar ainda sejam muito exóticas para a maior parte do público de TI do Brasil, é notável a tendência de crescimento do JavaScript, que também tenho observado em relatório do Gartner e até da nossa base pessoal de projetos e da observação de clientes. É o JavaScript, criado na quinta divisão do futebol inglês e que caminha a passos largos para a Champions League da tecnologia.

Para os curiosos, o relatório pode ser baixado neste sítio.
Boa leitura nerd, agora em português!