Agile Brazil 2013 – 2º Dia – 1ª parte

O Samuel Crescêncio da OnCast fez a bertura e boas-vindas, alertando para a novidade de Open Spaces no final da tarde, uma palestra de encerramento do dia com um neurocientista de ponta e apresentando pessoalmente a Dra Rebecca.

Dra Rebecca Parsons – Diretora de Tecnologia
ThoughtWorks e Agile Alliance

rebecca

Ela iniciou apresentando um ciclo de Agile Business como fundamental:

  • Testable hipothesys
  • continuous design / experimental design
  • quick delivery
  • measure the outcomes

Também sobre quais são os fatores críticos de sucesso:

  • esteja preparado para fazer (mudanças rápidas e seguras)
  • ter visibilidade de progresso
  • experimentar frequentemente (*)
  • balancear previsibilidade e oportunidades
  • confiar em evidências mais que em palpites

(*) Ela falou algo que faço questão de grifar: “Se você não erra com alguma frequencia, provavelmente é porque não esta tentando de verdade!

Agile Software Development – “A importância da transparência do progresso REAL!”, não adianta saber se temos 80% “done”, se os próximos 20% são completamente imprevisíveis e vão ter uma curva muito maior que tudo o que fizemos até aqui … logo, é importante ter métricas e histórico, além de tomar MUITO cuidado com a interpretação de ambiguidades e percepções sem embasamento.

Internal Software Quality – A tarefa de qualidade é responsabilidade de todos, mas especialmente, o código tem que ser fácil, inteligível, com boas métricas, de mais fácil manutenção quanto possível, prevendo-se participação efetiva de SQA desde o início e do business até o final, sempre “devendo todos concentrar a atenção naquilo que faz diferença” de forma sustentável e ATENÇÃO: “Nem sempre é fácil ou possível, mas devemos estar de olho na tendência, abrir concessões eventualmente é plausível, mas se a tendência é só abrir concessões, ai com certeza temos um grande problema”.

Princípios de arquitetura evolucionária – Basicamente, qual é o nível de dificuldade para ter uma solução fácil sempre será um bom indicativo de boa arquitetura. Outro cheiro é como estamos compartilhando as informações entre diferentes partes do sistema e o quanto complicamos este tráfego com volume desnecessário por ser mais fácil ou rápido, mas no qual teremos dificuldades no futuro, tornando o processo de mudança mais penoso e complicando a reversibilidade se necessário.

Last Responsible Moment – Porque esperar? Pela oportunidade de ter o máximo de informação, pois decisões muito cedo impõem riscos porque o volume de pressupostos não validados ainda são muito altos e gerarão riscos e retrabalho evitáveis. Mas quando então? Cada caso é um caso a ser percebido, onde o racional pode estar baseado em segurança, carga, …

Continuous Delivery – Continuous Delivery não exige a ausência de intervenção humana, é possível que pelo modelo de negócio ou contexto, o último passo seja um OK formal do cliente, um negócio de call center talvez não seja afeito a publicações automáticas a cada deploy, ninguém exige que seja automático.

Cem por cento automatizado ou com interferência (aprovação) humana, o caminho igual passa por um modelo deguro de automação de deploys e rollbacks, quer isto aconteça após um OK final do cliente ou através de um pack de testes unitários e funcionais automatizados, para tanto é fundamental  um bom e racional pipeline de testes.

Continuous Design – Aqui ela apenas fez uma referência, pois o ciclo de discovery muitas vezes não é ágil, é criativo, mas ainda é muito inspiracional e individualista, é preciso haver um modelo e técnicas participativas e interativo-incremental.

“What about the organization” – Dilema: “Controle de custos exige estabilidade, TI não pode ser só centro de custos, exige responsabilidade e a lembrança de que muitas vezes diferenciais são voláteis e devem ser entendidos e separados daquilo que é commodity. É importante fazer o que é importante onde é importante, dando relevância a gerência de portfólio.

  • Negócios ágeis
  • Arquitetar para adaptabilidade
  • Equilibrar custos e experimentação
  • Maximixar visibilidade e feedback
  • Alinhamento c/ a organização
  • Inovação

Técnicas de Facilitação – Marcos Garrido e Manoel Sabbagh

DSC06024

Um workshop nota 10, não, 12, muuuuit bom, uma sequencia de games em que eles atribuíam aos integrantes de cada mesa uma atitude a ser assumida em cada dinâmica, por exemplo, um disperso, um chato, um agressivo, um convicto, gerando uma salada de frutas para ser resolvido pelo facilitador do grupo, que variava a cada exercício, lógico que eram situações absurdas, pois não temos vários extremistas rebeldes em cada equipe, mas gerava em 7 minutos um exercício rico em percepções para reflexão e debates no foco do papel do facilitador, que conceitualmente é:

  • deve ser neutro
  • deve ser aceito pelo grupo
  • não deve ter autoridade
  • deve guiar sem interferir
  • buscar consenso através da reflexão
  • buscar convergência
  • buscar foco
  • perceber disfunções
  • buscar um modelo democrático
  • não deve ser intermediário com outros interessados
  • não é representante do grupo

Na medida em que flexibilizamos as timeboxes vamos incorporando estas distorções ao inconsciente, de forma que após algum tempo ficará difícil resgatar atitudes dissonantes como atrasos, dispersão, interferências, acomodação, …, sem a necessidade de gerar uma nova curva de aprendizado e convencimento, correndo o risco de cada ciclo enfrentar novas resistências devido ao desgaste.

Mudar um hábito é mais difícil que criá-los, pois exige desconstruí-lo para então construir novos. Deixarmos fixar entre nós hábitos errados achando que com o tempo eles se resolverão não é exatamente ser auto-organizado, provavelmente é intransigência, falta de entendimento, falta de treinamento ou facilitação, são situações que devemos mapear o mais breve possível e investir na mitigação.

Báh, enfatizaram uma coisa que me venho 20% de profissionais que conheço e que eu sempre enfatizo como algo a ser mudado o quanto antes, interromper uma explanação de um colega para outro, dizendo: “O que ele esta querendo dizer …”, tchê, é o mesmo que dizer que o cara não tem capacidade de se explicar e precisa que alguém o faça por ele … conheço gente que trata suas equipes assim e conheço gente que fica fula, mas não fala nada .

2 comentários sobre “Agile Brazil 2013 – 2º Dia – 1ª parte

  1. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

  2. Pingback: Um ano e meio de blog – Obrigado galera! | Jorge Horácio "Kotick" Audy

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s