Já falei em muitas conversas, cursos, publiquei no Twitter que eu amo o Alistair Cockburn. O cara tem experiência e uma visão de todo que faz com que tenha opiniões bem embasadas sobre o desenvolvimento de software.

Hoje me deparei com o "Juramento de Não-Lealdade", traduzido pelo pessoal da Qualidata no seu blog: http://blog.qualidata.com.br/?p=356. Quem divulgou foi o Uilton no scrum-brasil.

“Eu prometo não desconsiderar nenhuma ideia baseada em sua origem, mas considerar ideias vindas de todas as escolas e tradições com o objetivo de encontrar aquelas que melhor se encaixem em cada situação.”

Para mim, em outras palavras, o juramento quer dizer: "serei e agirei como adulto".

“Estou cansado de pessoas de uma escola de pensamento atacando idéias de uma outra escola de pensamento. Estou ansioso por pessoas que não se importam com a origem das ideias, e sim com o seu significado e o que elas são capazes de produzir. Então eu proponho um ‘Juramento de Não-Lealdade’ (The Oath of Non-Allegiance) :

Eu prometo não desconsiderar nenhuma ideia baseada em sua origem, mas considerar ideias vindas de todas as escolas e tradições com o objetivo de encontrar aquelas que melhor se encaixem em cada situação.

Isto significa o fim de afirmações como ‘Isto não é bom – isto não é ágil puramente orientado a objeto, etc…’, mas sim a discussão sobre se a ideia em questão (uma impura plan-driven ágil ou qual seja) funciona bem nas condições do momento.
E eu serei o primeiro a assinar.
Alistair”

http://alistair.cockburn.us/Oath+of+Non-Allegiance

 

 

 

 

Na sexta e no sábado participei de um seminário / workshop / curso de SCRUM junto a pessoas da Stefanini São Paulo e de pessoas de alguns clientes. No final fomos divididos em equipes para uma dinâmica. Para não estragar a experiência de quem ainda não participou, vamos dizer que as equipes devem produzir algo. Eram cinco equipes e a nossa ganhou de lavada.

Depois de passada a euforia da vitória (quem não gosta de ganhar, principalmente dos seus colegas que trabalham na mesma sala, dá assunto para alguns dias), fiquei pensando nas razões pelas quais conseguimos produzir mais e melhor. Pensei na equipe e notei que tínhamos nela entre os nove membros, pelo menos três pessoas da área de testes.

Eu era o líder da equipe e lembrei que no começo, sugeri que focássemos em produzir atendendo a todos os requisitos, mesmo que isso tornasse a nossa produção mais lenta. Foi incrível o quão fácil a equipe concordou com a idéia e se comportou de acordo. Agora eu penso, "claro, eles são da área de testes, provavelmente já estavam pensando nisso".

Bem, moral da história, levamos muito a sério a qualidade, produzimos muito bem e quando vimos estávamos também rápidos. No final eu disse para a equipe o que eu sentia, que daquela forma, com aquelas pessoas e aquele pensamento, poderíamos produzir qualquer coisa. De tijolos a aeronaves.

Conseguimos aplicar TDD? Olha, acho que sim, e olha que não era software, longe disso.

Valeu equipe Σ!
"Primeiro fazer certo, depois fazer muitos!"

Não sei se alguém já falou essa frase antes, mas acabei cunhando ela depois da primeira reunião que tive com o time de desenvolvimento. Como o primeiro sprint é de arquitetura, o assunto foi pura sopa de letrinhas. Eu até me virei um tempo (CSS, COOKIES, MVC, etc), mas infelizmente passei batido em quase todas as piadinhas que só tem graça para quem realmente entende do negócio, quero dizer, da arquitetura do sistema.

Fiquei bem no estilo do filha da puta em dia dos pais, do pum em bombacha, ou dos dedos no chinelo de franciscano, perdido.

Que venham os sprints funcionais!

 

Agile Software Development: The Cooperative Game Alistair Cockburn ISBN: 0321482751 Páginas: 504 Idioma: Inglês Editora: Addison-Wesley Professional Ano: 2006

Comentário Kerber

Sou fã do Cockburn desde o Writing Effective Use Cases, livro no qual ele derruba os mitos e mosta o que um caso de uso realmente é e para que serve. No Agile Software Development, Cockburn explica o desenvolvimento de software através da sua analogia preferida: um jogo cooperativo. O desenvolvimento de software é um jogo cooperativo que tem dois objetivos, o primário, entregar o software solicitado, o segundo, deixar a situação propícia para que o próximo jogo também seja ganho.

Cockburn explica o que é uma metodologia e orienta o leitor na criação da sua (sim, cada tipo de projeto merece a sua própria metodologia).

O livro vai do filosófico ao pragmático começando com o estudo de conceitos como "comumicação" e terminando com análises concretas das diferentes metologias. A parte que mais me agradou foi aquela na qual ele descreve os equívocos comuns na interpretação do manifesto ágil. Essa parte vai merecer um artigo aqui.

Read the rest of this post »

Assistindo às olimpíadas de inverno (que estou achando mais legal que a de verão) e principalmente os comentários sobre a patinação artística no gelo, e como as coisas funcionam, tive o clique de comparar esses dois esportes que em comum acho que só tem os patins e a vontade de vencer com os dois extremos das metodologias de desenvolvimento que em comum só tem os computadores e a vontade de vencer. Lembro que estou falando dos dois extremos. Se você encontrar alguma característica que deixei de lado comente!

Patinação artística no gelo		Hockey no gelo
Orientada ao planejamento		Orientado à mudança
Uma apresentação é cuidadosamente planejada, a dupla prepara a coreografia a ser executada, prepara a música, treina movimentos isolados, mas dá muita atenção aos movimentos compostos. Um movimento está ligado no outro, há seqüência e interdependência entre eles.		Você pode tentar planejar tudo o que vai acontecer em um jogo, mas depois acaba desistindo. Vale mais a pena investir em treinar as habilidades individuais da equipe e o entrosamento para adaptação rápida. Até existem jogadas ensaiadas, mas você nunca vai dizer "a jogada B depende da finalização da jogada A". As jogadas são escolhidas (e inventadas) conforme o jogo segue.
Pequenas mudanças podem ser feitas no plano (fazemos aquele salto dessa vez?), mas apenas antes de começar, depois que começou, segue o plano. Uns dizem que dá para cochichar no ouvido do parceiro e combinar algo, mas girando 4 vezes no ar é meio difícil conversar.		As vezes você dribla e bate, as vezes você dribla, passa, recebe de volta e bate, as vezes você bate na cabeça do adversário e vai para o chuveiro.Ao fim de cada jogada rola um papinho rápido com os companheiros mais próximos para fazer ajustes (John, John! Fica ligado pô, ó o cada aqui!).
A equipe conversa muito com o técnico antes da apresentação, durante a apresentação a comunicação é difícil, sobra para o técnico torcer. O feedback só é recebido ao final.		Você leva um tapa na orelha (no capacete) do técnico toda vez que o desagrada (e quando o agrada), logo depois da jogada. O feedback é imediato. Aliás, bobeou, está fora no meio do jogo.
Levou um tombo e deu de bunda no chão? Levanta e segue o plano de onde parou (deixa para coçar depois).		Levou um gol aos 30 segundos? Ajusta as jogadas para compensar. Levou um gol faltando 30 segundos? Ajusta as jogadas para compensar.
A apresentação tem um tempo determinado e espera-se que tudo o que foi planejado seja executado nesse tempo. Há movimentos obrigatórios. Não conseguiu fazer tudo o que estava planejado? Encrenca, perde nota.		O jogo tem um tempo determinado dividido em períodos menores. Acabou um período ou o jogo, a coisa fica como está, não importa quantos gols sairam.
Alguém grita da arquibancada pedindo um movimento que não foi planejado, mas que ficaria lindo agora. O sujeito vai preso.		Alguém grita da arquibancada pedindo que vocês façam "aquela" jogada especial, você acha uma boa, fala rapidinho com um companheiro e se ele topar, vocês fazem.
"Jogar" bonito faz diferença.		Jogar bonito é legal, anima a galera, mas eu quero é gol. O que interessa é disco na rede.
Você deixa a sua maior manobra para o final.		Você tenta fazer a sua melhor jogada desde o primeiro minuto.
É o esporte perfeito - para quem gosta.		É o esporte perfeito - para quem gosta.

Confessions of a Serial Product Owner (download aqui)
Anna Forss
Páginas: 66
Idioma: Inglês

Working as a product owner or inspiring to be? Thinking about using SCRUM but don’t know what that means to business people? Are you a business person and your development department uses SCRUM and you don’t understand how you fit in or how it works? Confessions of a serial product owner is a short description of how SCRUM can work, as described from a business person’s point of view.

Comentário Kerber

Ótimo livro, dá impressão que foi escrito para mim. Ainda existem algumas divergências a respeito do analista de negócios ser automaticamente alocado como product owner no SCRUM, contudo, se você está no "business side", vai se sentir confortável nessa posição que está longe de ser simples e fácil, mas permite que você cumpra a sua missão.