O que não é Scrum

13.maio.2009

dilbert-agile-programming

Departamento de sistemas da matriz adotou Scrum como metodologia de desenvolvimento. Bacana, não?

Não.

Primeiro ponto: Scrum é um framework de gerenciamento de projetos, e não de engenharia. Obrigatoriamente você vai precisar de alguma técnica complementar se quiser que seu desenvolvimento de sistemas (no caso) esteja dentro do que se considera aceitável. Os responsáveis pela adoção acreditam realmente que apenas o Scrum vai salvá-los da danação eterna.

Segundo: usar Post-its, quadros brancos, burndown charts e mimimitings não significa que você esteja usando Scrum. Daily Meetings semanais e Stand-up Meetings sentados, com três horas de duração também não tem nada a ver com Scrum.

Terceiro: Aposto um dedo da mão direita como um “Scrum” aplicado dessa forma vai afundar o projeto, ou pelo menos vai gerar um produto de péssima qualidade, caro de se manter e muito, mas muito estressante de se trabalhar.

Aposto outro dedo da mesma mão como o Scrum vai levar a culpa e vai ser banido a pontapés da empresa. Com o risco de alguém olhar para trás e se transformar numa estátua de sal.

Pedir a benção do Papa para ‘implantar Scrum’ dentro da empresa não soa exatamente ágil. O que a empresa teoricamente espera é software que funciona, com qualidade, dentro de prazo e custo estimados. Se você tem que beijar a mão do bispo para conseguir trabalhar direito, a agilidade definitivamente não faz parte do DNA da empresa.

E finalmente, imprimir “Scrum & XP from the Trenches” e ler passo a passo antes de tomar uma decisão só mostra o quão despreparadas estão as pessoas envolvidas. Por maior que seja a boa vontade, não vai rolar.

Scrum é flexível, e muito. Mas mudar os alicerces do framework é como ser católico sem acreditar em Deus.

Como bem escreveu Rodrigo Panachi, “agilidade não é metodologia, é atitude”.

Update: Recomendo a leitura do artigo do Rodrigo Yoshima.

Anúncios

Comunicação é tudo e mais um pouco

26.janeiro.2009
Imagine que você receba a seguinte especificação:

Pegue uma folha de papel A4. Sob a mesa, dobre-a ao meio. Coloque a folha dobrada sobre a mesa.

A especificação parece clara e simples, mas aposto que dobramos as folhas de forma diferente, obtendo resultados diferentes. Eu dobrei a minha folha verticalmente, enquanto provavelmente você dobrou horizontalmente, obtendo uma forma próxima de um quadrado.

Qual foi o problema?

Eu criei uma especificação tendo em mente exatamente o que eu queria. E eu acreditei que aquilo era mais do que suficiente.

Você pegou uma especificação, aparentemente muito simples, e sem questionar seguiu os passos que julgou corretos.

Não houve comunicação, cada parte presumiu coisas e o resultado final não foi o esperado.

O grande diferencial das ditas metodologia ágeis é exatamente permitir a comunicação rápida, clara e sem ruídos entre todos os membros da equipe. Isso não tem nada a ver com post-its, gráficos ou ferramentas na Internet. É por isso que estamos vendo-as falhar, e é por isso que o seu projeto, e o meu, também estão falhando.

É por isso que relacionamentos chegam a níveis insuportáveis de convivência, casamentos terminam, empregos viram um inferno. É por isso que ocorrem desencontros, é por isso que clientes recebem algo que não pediram e que não os atendem.

É por isso também que não consegui comprar um mísero pão doce quando estive fora do país.

Comunicação é, na minha opinião, o fator mais importante, e o menos valorizado. É tudo isso que eu falei, e mais um pouco.


Agilidade de tartaruga

13.janeiro.2009

Palestra apresentada no evento “Falando em Agile 2008”.

Reserve 48 minutos do seu tempo e assista. Vale a pena.


Sem comentários

11.dezembro.2008
Antes de mais nada: o que vou escrever aqui não se aplica a linguagens de ‘baixo nível’, como Assembly, por exemplo. Se você utiliza Java, Delphi, C#, Ruby ou qualquer outra que possa ser chamada de ‘alto nível’, pode continuar lendo.

Comecemos com uma ordem: não comente seu código.

Plaft. O impacto da ordem e os trolls agitam os dedos para começar a criticar.

Para que servem os comentários no código? Ensinaram na escola que é para informar suas intenções aos outros programadores. Teoricamente, quando o próximo coitado abrir o seu código, ele vai entender perfeitamente todas aquelas amarrações e voltas lógicas que você deu no código, apenas se guiando pelos comentários. Genial, não?

Agora, me mostre um só código legado, daqueles sem testes e que passaram na mão de pelo menos vinte estagiários, que tem os comentários perfeitamente atualizados e consistentes com a abordagem utilizada no código. Pois é, esse é o segundo problema que encontramos ao usar comentários. O primeiro, se você ainda não percebeu, é o retrabalho de ter que escrever código e em seguida escrever comentários para explicar o que o código faz.

Claro que ainda não te convenci. Anos de vício não se perdem em uma leitura. “Tudo bem, é só apagar aquele comentário que não faz sentido”. Vou usar um exemplo que encontrei aqui mesmo, no projeto em que trabalho.

O que a linha abaixo quer dizer?

int t = 0;

Nem mais, nem menos. Para mim, está sendo declarada e inicializada uma variável t. Para que serve, eu não faço idéia.

Vamos então comentar o código. Claro, assim o próximo sujeito que der manutenção nesse código vai entender perfeitamente o que estou tentando fazer aqui.

// tentativas de login
int t = 0;

Opa, bem melhor agora, não concorda? É óbvio que t é exatamente a mesma coisa que tentativas de login. Claro. Como não pensei nisso antes? Assim, no meio do código, basta você encontrar a variável, voltar ao local onde ela foi declarada e ler o porquê dela existir. Ou então, você pode ser uma pessoa bem legal e comentar cada linha onde a variável é utilizada. Se você for mais legal ainda, logo você terá um código de 300 linhas, sendo que 160 delas são só comentários. Legal mesmo.

Só que eu não sou um cara legal. Eu tenho preguiça de escrever comentários. Eu acho que um código de 300 linhas com 160 linhas de comentário é uma nojeira difícil de ler. Eu acho uma perda de tempo ter que reescrever comentários para cada linha que eu altero do código. É demorado, pouco produtivo e sujeito a erros. “E então, espertão. Como você faria?”

int tentativasDeLogin = 0;

Que tal assim? Sem comentários, sem nenhuma explicação adicional. Apenas código, puro e simples. O código se torna uma forma clara e concisa de documentação.

Ferramentas como NetBeans, Eclipse e Visual Studio, automatizam o ato de renomear um membro da classe dentro do escopo correto, o que honestamente, me faz desacreditar em qualquer argumento a favor do uso de comentários em detrimento da legibilidade do código.

Por falar em legibilidade, vou começar a inserir linhas entre os parágrafos. Pelo menos para mim isso ajuda muito na hora de ler textos maiores. Espero que te ajude também.

😉


Declínio e queda das metodologias ágeis – Ecos do além

21.novembro.2008

O debate continua ecoando. Na última pesquisa, o Google acusou 9.800 páginas sobre o assunto [1].

Um dia esse site chega lá =)


Declínio e queda das metodologias ágeis

18.novembro.2008
James Shore escreveu um artigo [1] que causou uma série de discussões como há muito tempo eu não via. Antes de continuar aqui, leiam. Eu espero.
Muita coisa absurda é feita em nome do Scrum ou de Agile, assim como muitas atrocidades já foram cometidas em nome do RUP, do PMBok ou da metologia que vier à sua cabeça. O problema é que, enquanto as anteriores ficaram com a fama de burocráticas e lentas, as metodologias ágeis em geral carregam a idéia errônea de serem desorganizadas, bagunceiras e irresponsáveis. Ao mesmo tempo, já ouvi casos onde o nome ‘Scrum’ foi associado a projetos sem definição de pronto, processos amarrados e burocráticos ou mesmo anarquia (no sentido mais comum do termo).
Aí você pergunta: ‘Ué, processos amarrados e burocráticos? Mas não era pra ser ágil?‘. Sim, era. O Scrum, em sua definição formal, não é uma metodologia, mas um framework, um conjunto de práticas e idéias que levam, antes de mais nada, a mudanças culturais e comportamentais. Essas sim é que vão causar melhora na comunicação, aumento de produtividade e toda essa coisa que tentam vender como um produto na caixinha.
Há duas semanas ouvi um profissional de TI (ex-IBM e apaixonado por RUP, segundo o próprio), dizendo que Scrum não presta porque não tem um livrão de 800 páginas explicando passo a passo como fazer. ‘Vira zona’, nas palavras do colega.
Também há algumas semanas, um conhecido evangelizador da Microsoft publicou suas impressões sobre Scrum [2]). O cidadão tem a infelicidade de dizer que “Scrum é fácil de usar”. Claro, é sempre muito fácil mudar antigos hábitos, perder vícios e mudar a cultura da empresa inteira. É sempre muito fácil ter o comprometimento de todos os membros da equipe, ter facilidade de comunicação e mesmo criar o conceito de equipe dentro da empresa.
Assim como aconteceu nesse caso, pessoas tidas como especialistas começam a vender Scrum, ou qualquer metodologia ágil como se fosse algo fácil e rápido de aplicar. Projetos inteiros vão para o vinagre por completa falta de organização e, principalmente, por falta de um entendimento verdadeiro do que realmente é ser ágil.
Agile não é só Scrum, não é bagunça nem falta de organização. Scrum não é Kanban e Post-it com reuniões em pé. Ser ágil não é só entregar em prazos curtos, não é só usar TDD, BDD, XP ou a PQP de sigla que você achar por aí. Não é jogar fora a documentação, nem deixar de modelar, não é trabalhar sem contrato, não é criar piscinas de bugs, não é descer a lenha em PMP ou queimar o PMBok em praça pública. Agile, Scrum, Crystal, XP, etc são, antes de mais nada, bom senso.
Nem mais, nem menos.

Referência: