GP digivolve para ScrumMaster!

Apenas para alinharmos: o meu pensamento pessoal sobre o ScrumMaster, é muito simples:

1. Ele é quem mais manja de Scrum, garante que o Scrum será aplicado e ensina e ajuda a todos a aplica-lo; (inclusive ajudar o PO a montar o Product Backlog)
   
   
2. Ele é o paizão do time de desenvolvimento. Ele cobre todo mundo e deixa que o time faça o seu trabalho; Ele é um facilitador. Ou servidor.
   
   
3. Ele remove todos os obstáculos que aparecerem durante o desenvolvimento;
   
   
4. Ele é parte do time;
   
   
5. Ele é PIG; e
   
   
6. É ele quem cultiva o espírito de time da equipe (essa é por minha conta! rs..)
   

Como disse, isso é o que eu entendo como sendo as atribuições do ScrumMaster.

Note que em nenhum momento há nada parecido como: "gerencia", "coordena", "organiza", "comanda", "controla" ou "cobra".

Como o Time Scrum é auto-gerenciado, é do time responsabilidades como: definir o que irá compor o Sprint Backlog; garantir a qualidade do produto; e etc.

Ok, parece bem simples, né? Pois é.

Quando GP digivolve para ScrumMaster!


Sabemos que não é fácil quebrar paradigmas (ou "paradinha", como diz Luli Radfahrer, rs..).

Eu sei. Estudo POO há um bom tempo, e ainda não peguei o jeito, de verdade! Os vícios que adquirimos com o tempo, dificultam essa mudança do pensamento.

Agora imagine mudar uma "paradinha" muito maior, como o fato de vc estar acostumado a ter o controle, ser o centralizador de tudo, organizar cronogramas, mandar e desmandar.

Poxa, vc vai perder o seu poder que demorou tanto para vc conquistar!

É a barra que passa quem era GP e passa a ter a função de ScrumMaster.

Veja bem, eu não estou criticando GP's. Conheço alguns ótimos, onde sem eles alguns projetos simplesmente não rolariam. O que estou comentando é sobre o abismo que há entre as atribuições do GP e as do ScrumMaster.

Isso virou um post motivado por uma ocasião específica.

Estava conversando com um certificado ScrumMaster (ex GP), apresentando o esquema de Integração Continua (IC) que estamos adotando na equipe (aliás, ótimo assunto para outro post! rs..).

Quando comentei sobre a auditoria automática de código, ouvi o seguinte comentário (não exatamente nessas palavras):

"(..) Ótimo! No final do dia, quando o desenvolvedor estiver indo embora, se o ScrumMaster notar algum problema nos relatórios de auditoria de código ele vai barrar o desenvolvedor no momento e falar: 'você não vai embora enquanto não resolver isso aqui!'.(..)"

(no way!!!)

..pois é.

Veja bem: eu estava apresentando uma técnica que foi estudada pelo time, que estava sendo defendida e implementada pelo time e, principalmente, para benefício do time!

Realmente, talvez o desenvolvedor ir embora deixando algo a ser feito talvez não fosse a postura mais legal do mundo, porém não é esse o ponto que estou comentando aqui, mas sim sobre o controle do ScrumMaster sobre o time (que como comentei no inicio do post, na minha visão, é nenhum! rs..)

Entendo que a preocupação com a qualidade do produto é do time. Nosso time quer implementar IC, para melhorar a qualidade do nosso produto!

Ok, o ScrumMaster também faz parte do time, mas essa não é uma de suas atribuições. ScrumMaster não gerencia: ele facilita e ajuda!

Agora, se o seu time não está comprometido com a qualidade do produto, com a meta, com o conceito de pronto e tudo mais, bom, daí a ferramenta de auditoria é o menor dos seus problemas.

Como faz parte das atribuições do ScrumMaster garantir que o Scrum seja aplicado (e isso não tem nada haver com a Engenharia do Software!), se o Scrum Master se depara com um time que não PIG, que não é auto-gerenciável ou desmotivado, aí sim ele deve interferir!

Mas interferir no sentido de motivar o time. De enciná-lo a ser auto-gerênciável. De fazer o time ser PIG! Essa é uma das atribuições do ScrumMater, pois tem tudo haver com "garantir que o Scrum seja aplicado corretamente". E não se preocupar em fiscalizar o time!

Esse tipo de fiscalização é totalmente prejudicial para a saúde do Scrum, e é uma potêncial causa de fracasso!

Ao contrário do que possa parecer, isso não é anarquia!! Apenas com um time PIG é que os métodos ágeis podem funcionar. E com um time PIG, o ScrumMaster não precisa se preocupar em ficar fiscalizando relatórios: o próprio time faz isso! É interesse deles, mais do que qualquer um!

Acho que um dos problemas, é o esquema atual de certificação ScrumMaster. Eu acho tão furada, mas tão furada que apesar de ter feito o (excelente) curso da Caelum, não me considero ScrumMaster e nem divulgo que eu tenho o tal certificado.

Essa certificação como é, pode dar uma falsa impressão a quem a tira, para quem a vende (o comercial das consultorias) e para quem as compra (o cliente).

A transição não é fácil! A filosofia ágil traz uma série de mudanças desde pensamento até comportamento. É todo um conjunto de inteligências que devem ser estimuladas.

É como reaprender a andar. Mas dessa vez, com agilidade!

É isso!

;)

Missão Impossivel: adotar métodos ágeis

Como comentei, estou estudando sobre métodos ágeis.

Scrum e Xp mais especificamente.

Não faz muito tempo não.. acho que desde o ano passado, apenas...

Fiz um ótimo treinamento, tento ler bastante sobre o assunto, acompanho vários blogs fantásticos (pena que não cabem todos aki, rs..), listas de scrum, pergunto, comento, discuto e etc.

E sinto que aprendo algo novo todos os dias.

Confesso que ainda não consegui ler nenhum livro sobre o assunto (um de verdade quero dizer, dos mestres!). Ok, é uma falha minha.. acontece que os melhores livros estão em inglês e não tenho o melhor inglês do mundo (além da preguiça). Outro fator é que acho que "apenas" o inglês técnico não basta, justamente por ser uma assunto menos técnico. (mas os livros estão no meu backlog, rs..)

Uma coisa que deu para notar é que não se aprende a ser ágil da noite para o dia. Sou a prova viva disso. Tenho a impressão que não sei 10% do que podia ser considerado "B-" no meu antigo ginásio sobre a matéria de métodos ágeis. (rs..)

Mesmo assim, estou participando do processo de introduzir agilidade na empresa onde presto serviços.

Falta de opções da empresa, suponho.

Mas, mesmo assim, é uma enorme oportunidade para mim.

Estou aprendendo sobre agilidade, scrum, xp e muito mais. E vem como conseqüência, tdd, automatização, ddd, integração continua, maven e muito, muito mais!

Cara, como eu conseguia desenvolver antes disso? Sinceramente, não consigo entender! (hauhau)

Bom, o fato é que a agilidade ser introduzida por "não-especialistas" pode trazer uma série de dificuldades, confusões, embaraços e etc.

Além da minha evidente falta de preparo, cheguei a conclusão (e descobri o Brasil né? rs..), que são muitos os fatores que dificultam a adoção dos métodos ágeis.

Fica aki algumas observações iniciais:

É um universo totalmente novo.

Se vc está acostumado a estudar horrores com a sua linguagem de programação preferida, lamento mas vc vai ter que estudar outro tanto para entender a filosofia ágil e tudo o que a envolve.

Não, não é difícil não. É quase óbvio, eu acho.

Mas a mudança de paradigma! ahh, essa é complicada.

Todo o universo que conspira contra vc.

O mundo é contra vc. Ninguém entende como algo tão "anárquico" (na visão deles) assim pode dar certo!!

A empresa é contra vc. Eles não entendem como eles vão continuar faturando alto com um modelo que favorece tanto o cliente. Além de ter que mudar todo o seu modelo de negócio (prospecção, contrato e etc).

Os gerentes são contra vc. Eles não entendem como eles vão manter o poder de mandar nos vassalos, code monkeys e etc. E quando entendem, é dificil mudar sua cultura.

A equipe é contra vc. Eles não entendem como os metodos ágeis vão facilitar o desenvolvimento, diminuir o trabalho e stress como promete.

O cliente é contra vc. Ele não acredita, que vc vai entregar tudo o que ele acha que precisa nesse modelo. Ou ele simplesmente não acredita em agilidade, entregas pequenas e etc. Recebe o resultado do seu sprint, mas nem olha nada pois "vou olhar quando tiver tudo junto". Normalmente são traumatizados por experiências ruins de fracassos anteriores. Mas algumas vezes são mal intencionados, sim. Infelizmente.

O mercado é contra vc. Os grandes players ainda seguem o modelo de fábrica, que, conseqüentemente, contamina os seus clientes e dificulta a vida de quem quer introduzir a agilidade. A agilidade ainda é vista como "marginal", apesar de ser aplicada por "empresinhas" minúsculas como um tal de Google, Yahoo e etc..

Até os agilístas são contra vc. Vc começa a questionar, experimentar e, conseqüentemente, errar, e os mais experientes criticam veemente sua falta de experiência e técnica. Acertadamente sem dúvida! Concordo 100% com as críticas! Elas são ótimas e bem vindas! Porém, algumas vezes, elas são colocadas de certa forma que podem trazer mais malefícios do que benefícios e serem desestimuladoras, quando deveriam ser, penso eu, estimuladoras.

E diante de tudo isso vc se questiona, pois todos os argumentos que são colocados, são válidos. Quero dizer que todos os questionamentos devem ser discutidos (como em todos os assuntos). Acredito que não devam existir dogmas e tudo deve ser conversado, discutido e etc..

Mas contra tudo isso só há um remédio: estudar, estudar e ESTUDAR!!

Não foi de uma hora para outra, que os grandes caras chegaram onde estão. Eles também passaram por essa barra. Talvez menos. Talvez mais. Mas também passaram! (rs..)

Mesmo assim, com todas as dificuldades, com todos os preconceitos, com toda a falta de crédito, e com todos os erros, não desanime! Acredite na idéia! Vista a camisa! E continue estudando, falando, escutando, discutindo, reclamando e tentando.

E compartilhe tudo isso!!

Vamos aprender todos juntos! Mesmo que seja errando.

Seria ótimo se acertassemos em todas as primeiras tentatívas, né?

=)

PS: Esse post se auto destruirá em 30 segundos.

NerdAndGeek on Rails na Caelum

Eu já tinha uma pilha de livros de Ruby e de Rails para ler.

Mas sabe quando nunca dá tempo, ou pq vc tem que ficar correndo atrás do preju de Java e Scrum, ou pq vc viu programação o dia inteiro e só quer passar o fds na farra? Pois é.

O problema é que vc compra uma série de livros, coloca tudo no backlog, prioriza, mas conforme a carruagem anda, as prioridades vão mudando com o que é urgente para o momento, e RoR sempre ficava para depois.. =\

Mas dessa vez, surgiu uma oportunidade e fiz o treinamento de Ruby on Rails na Caelum ministrado pelo (excelente) Fábio Kung.

<-- Sou totalmente adepto ao auto-aprendizado, e acho que não é preciso nenhum curso para se aprofundar em nenhum assunto, porém, devo confessar que fazer um curso, assinar um contrato e, principalmente, pagar o curso, nos força a tomar uma atitude de, no mínimo, ir ao curso e aprender! Logo é uma maneira de nos forçar a estudar. Tendo tempo ou não! rs.. --!>

Sabe akelas aulas que vc fica com sono, e não sabe quando vai terminar e fica bocejando, navegando no Orkut, só ouvindo besteiras do instrutor e quando sai da aula vc pensa: "porque diabos estou perdendo meu tempo com isso?"?

Pois é, não é assim!

Vc fica vidrado, nem vê o tempo passar e quando sai vc pensa: "cara, foi do cacete!"! =)

É um treinamento de duas semanas, onde a primeira é focada no Ruby e a segunda no Rails.

Mas não pense que fica nisso não, viu! Pq todo dia é uma aula de POO, arquitetura, história da programação, dicas de excelentes livros, patterns, boas práticas e muito, muito mais!!!

Vou comentar brevemente sobre o treinamento (juro que não estou ganhando nada por isso! rs..)

O ruby?
puts "caraca!"
Nossa, como é gostoso aprender uma nova linguagem de programação, totalmente diferente das linguagens que agente está habituado como Java, C# e etc. XD

Ruby - se diz "rubi" e não "rãbi" - é muito diferente de Java e C#, absurdamente orientada a objetos e feita para ser estupidamente fácil de ser lida.

Para se ter uma idéia da legibilidade, segue um exemplo muuito legal: (baseado no exemplo do blog do Fábio Kung):

contaOrigem = Conta.first
contaDestino = Conta.last

transferir quantia: 10, de: contaOrigem, para: contaDestino

Agora me diz: quanto milissegundos vc demorou para entender o que esta acontecendo aí em cima?

Acredite ou não, essa é uma chamada de um método com argumentos e tudo!

Sem palavras, né? =D

Outra característica muito interessante é ter a tipagem dinâmica e fraca! Cara, que característica estranha (muito) num primeiro momento.

Suas raízes funcionais também causam espanto, para quem não está acostumado (como eu).

Mas o que eu achei mais da hora, é o fato de ela não ser baseada em classes, como Java, C# e etc.

Ah não! Outra coisa que é mto dahora é como ela é dinâmica! Vc acrescenta comportamentos e atributos aos objetos a todo momento. Durante a execução. D+

Poutz, são tantas coisas da hora que é difícil resumir em um único post. =/

O rails?
Abracadabra!

Essa história de "convenção sobre configuração" torna o desenvolvimento no rails extremamente rápido. A idéia é simples: o que era para ser pensado sobre ambiente, estrutura e etc já foi pensado e vc se concentra no desenvolvimento do que realmente importa: as funcionalidades!

Ele já é MVC por padrão, já pensa em três ambientes para vc (dev/homologação/produção), já fornece os artefatos necessários para - e incentiva inclusive - o TDD e isso tudo só é o começo.

Vc pode até apelar nele se quiser, mas no final é mais gostoso fazer "na mão"! E por "na mão" entende-se "fazer metade, ou menos, do que faria com Java/C# etc para fazer o mesmo"! =P

Há algumas IDE's interessante para ele, que 'facilita' algumas tarefas, mas eu gostei mesmo foi de fazer o curso no gedit customizado mesmo! =P

O ActiveRecord é animal, e aquele eskema do Rails de tratar o Method Missing das Entidades para montar uma consulta a partir da chamada do método é de outro mundo!! =D

Caraca! Mas RoR é só maravilha assim?

Bom, como o Fábio costuma dizer durante o curso: "não é o caso de melhor ou pior, é mais uma questão de vantagens e desvantagens".

Tanto na questão de que "se RoR é adequado para o meu projeto" quanto em questões mais de baixo nível como: "ah, quer dizer que eu tenho que 'criar a tabela' antes da classe?". Pois é. Demora um pouco para acostumar.

O Fábio costumava dizer que o Rails não esconde que vc está trabalhando com um banco de dados. E isso é meio estranho para quem está acostumado com Hibernate's da vida.

Outra coisa que demora um pouco para acostumar de alguem que vem do mundo dos Hibernate's, são as migrations. É que agente acaba acostumando a nem tocar no banco de dados (o hibernate cria/atualiza tudo automaticamente, mesmo..)

E a escola? E o instrutor?
A Caelum sempre tem um atendimento rápido e eficiente. A sala é boa, tem um quadro enorme, o coffe-break é ótimo (custo/benefício) e, o mais legal: as máquinas são todas boas e ubuntu! =D

O Fábio Kung é dakeles caras que começaram a programar com 12 anos de idade. Já viu né?

Quando vc acha que está manjando tudo da sua linguagem preferida, ou entendendo tudo sobre Patterns, ou mandando bem em POO, vc precisa ter uma aula com o Fábio! E vc vai ver o que é mandar bem de verdade!! =)

Quando o Fábio começa a despejar 3% do seu conhecimento como, por exemplo, sobre programação funcional, vc pensa "cara, e eu pensando que sabia programar!" hauhauha!

Ok, o mais importante, é que ele tem uma didática muito boa e tem o domínio (pratico e teórico) sobre o assunto e tudo o que o envolve!

E vale a pena?
IMHO, o curso vale cada centavo e tempo investido!

É uma linguagem que está em alta no momento, com grande procura e com cases de sucesso bem legais.

É totalmente Orientada a Objetos (alguns dizem que é mais que Java/C#, etc..) e o rails segue vários padrões de mercado, além de ser fácil e pragmático.

Claro que é sempre mais proveitoso se vc já tiver um conhecimento inicial sobre o RoR, POO e etc.

Porém, se vc está pensando em começar com programação e tem algum conhecimento de web, algum conhecimento (mínimo) de POO, já tem um mínimo de lógica de programação esse curso também serve para vc!!

Vc verá POO a fundo (passo a passo se for o caso), arquitetura, padrões e etc!

E vc estará aprendendo com alguem quem realmente entende do assunto, não com akele seu outro professor que acha que a herança é a característica mais importante da OO. =/

É isso!