tucaz.blog.now() Rotating Header Image

Eu não uso Scrum porque Scrum não funciona!

É Isso ai! Scrum não funciona!

Sabe porque Scrum não funciona? Porque se chama Scrum. Esse hoje é o maior problema do Scrum. Há dois anos atrás pouquíssimo se falava nisto que hoje virou hype. Nessa época as pessoas só falavam que usam Scrum depois de estudar bastante, trocar experiências e exercitar bastante. Ai sim alguém tinha coragem de dizer “Eu uso Scrum” e ainda assim com um pouco de receio, pois sabiam que tinha mais coisas além de apagar toda documentação do projeto e e quebrar as cadeiras pra fazer as reuniões em pé. As pessoas (a maioria) que diziam isso sabiam o que estavam dizendo. Scrum tinha credibilidade.

Nessa época, essas pessoas que conheciam agiram como evangelizadores do Scrum e finalmente ele atingiu as massas. No entanto, hoje o que mais se ouve são times/pessoas que não tem a menor idéia das noções e fundamentos por trás do Scrum ou qualquer outro processo/metodologia/framework ágil dizendo que são praticantes de Scrum. Até gente que nunca participou de um projeto usando Scrum hoje vende Scrum.

Isso é propaganda ruim. E propaganda ruim se multiplica muito mais rápido do que a boa. O pior da propaganda ruim é que cria-se ainda mais preconceito em cima de algo que já encontra resistência naturalmente. Isso tira todas as chances de sucesso de uma implementação de Scrum. Estou cansado de ver em todos os lugares pessoas frustradas dizendo que tentaram implantar Scrum em suas empresas e não conseguiram. Mas é claro que não! O filme do Scrum já está queimado. Você vai falhar antes mesmo de tentar.

Já faz um tempo que eu parei de vender a idéia de usar Scrum. Desde então eu digo que eu procuro executar práticas ágeis. Soa mais leve, mais simples. O pré-conceito diminui dessa forma e a resistência também. Do que importa se meu facilitador chama Gerente de Projetos ou Scrum Master? As pessoas se preocupam mais com nomes do que com resultados e esse é o problema. Agilidade é o que há, mas funciona melhor sem rótulos.

Verbos HTTP: GET e POST. Você sabe mesmo a diferença?

Até pouco tempo atrás quando eu fazia entrevistas a fim de contratar desenvolvedores, não importando o nível, eu fazia a mesma pergunta: “Você sabe a diferença entre GET e POST em uma request HTTP?”. Por incrível que pareça poucas pessoas sabiam responder. Na maioria das vezes alguém que se considerava um desenvolvedor web não tinha a menor idéia  sobre o que eu estava falando. Acho que era culpa do RH que fazia uma pré-seleção muito ruim, mas anyway…

Hoje essa informação já chegou a maioria dos desenvolvedores web (já era hora, não?) então a pergunta no contexto original perdeu um pouco a validade. Todo mundo sabe que enviar formulários via GET manda as informações pela querystring e que POST manda encapsulado dentro da request e bla bla bla. No entanto, com a nova “moda”, que acho bem bacana aliás, de REST(ful) a pergunta ganhou um contexto novo e tornou a ser válida: você sabe qual a diferença dos verbos em uma request HTTP? Não só de GET e POST, mas de todo o resto?

Decidi fazer esse post rápido enquanto retomava meus estudos a respeito de WCF e assistia a um vídeo do MIX do ano passado que está no final deste post.

POST não escala, GET sim. Porquê? Por causa da semântica! POST, PUT, DELETE e outros verbos são por definição non-safe e com efeitos colaterais, ou seja, é esperado que uma request usando esses verbos modifique algum recurso. Dessa forma é impossível fazer cache desse tipo de chamada. E como todos nós sabemos, sem cache = sem escalabilidade, isn’t that right?

Vamos tomar como exemplo uma chamada a URI imaginária: http://meusite.com.br/usuario/novo passando via POST todas as informações necessárias para se criar um usuário. Se tudo correr bem, vamos receber como resposta um HTTP Status Code 201 indicando que o recurso foi criado e a URL para acessa-lo. Provavelmente algo como http://meusite.com.br/usuário/765.

Agora a pergunta: é seguro para os intermediários dessa request tais como proxies, clientes, etc efetuarem o cache disso? Não! Imagine um usuário do sistema que utiliza esse recurso tentando cadastrar um novo usuário com os mesmos dados. Ao invés de receber uma resposta de conflito ele receberia um status 201 dizendo que o recurso foi criado. De fato o recurso foi criado, mas será que deveriamos mostrar isso pra ele quando na verdade a criação desse recurso já havia acontecido e a ação que ele executou neste momento não trouxe sucesso? Acho que não.

Já o GET, por definição é cacheavel, pois não possui efeitos colaterais. Ele apenas devolve o recurso desejado sem modificar nada. Claro que isso só acontece quando bem usado, pois tem muita gente que utiliza esse verbo de maneira errada e baseado em parâmetros executa ações que deveriam ser associadas a outros verbos HTTP. Como não modifica nenhuma informação é possível efetuar o cache desse recurso com segurança.

Pra quem quiser ver mais a respeito de REST, GET, POST e cache, basta acessar o vídeo no site do MIX 09.

De volta a terrinha

Acho que todo mundo já sabe, mas para aqueles que não sabem ainda voltei ao Brasil no mês passado. A idéia era ir para os EUA e ficar por lá, mas como nem tudo na vida são rosas tive uns problemas familiares por aqui que fizeram com que voltasse. A idéia de me mudar daqui ainda é muito forte e vai acontecer. Só teve de ser postergada um pouquinho :)

Apesar de voltar pro Brasil continuo trabalhando pra HNI, mas de maneira remota, o que não deixa de ser uma experiência bem interessante dada a diferença de timezone e dificuldade de comunicação.

Isso quer dizer que vou voltar a postar bastante no blog como eu fazia antes? Espero que sim, mas agora vou fazer um pouco diferente e gostaria de um feedback de quem lê pra ver se estou agradando ou não. A idéia do blog foi sempre postar coisas que eu acho interessante e conheço, mas com alguma experiência prática e opinião pessoal no assunto. Isso faz com que os posts saiam relativamente grandes e demorem muito para serem escritos (da trabalho, mesmo que o resultado final não seja o melhor do mundo! eheheh).

Por conta dos problemas do dia a dia e da natureza do meu atual trabalho posts assim vão ficar um pouco mais raros, mas quero aumentar sua frequência em breve. Enquanto isso, vou compartilhar informações mais curtas, comentários menores e links que acho que valham a pena divulgar.

Além disso, também estou fazendo uns tweaks no blog e um deles que já pode ser visto é o de idiomas. Quando acessarem o blog pela próxima vez via HTTP o plugin vai identificar sua origem e direcionar para os posts na lingua correspondente: inglês ou português. As duas línguas vão ficar disponíveis, mas será necessário clicar no post de outro idioma para le-lo.

O endereço direto para os posts em inglês é: http://blog.tucaz.net/en e para os posts em português é: http://blog.tucaz.net/br.

Dessa maneira contínuo escrevendo em inglês e praticando o idioma e posso escrever também em portugûes conteúdo que acho que valha a pena apenas para nós brasileiros (como é o caso do próximo post que está na fila).

Ainda não sei exatamente como os feeds vão se comportar, mas vamos descobrir em breve. :)

Por último, caso encontrem problemas com o feed ou com o blog ou tenham comentários ou perguntas de qualquer natureza, POR FAVOR me avisem pra eu melhorar/resolver o que for necessário. Okidoki?

Soçarba

(Inglês) [Book Review] Startup

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Basic stuff: handling exceptions in .NET

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Leading by omission

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Communicating and understanding are the keys to succeed

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Almost good!

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Blog Maintenance

Desculpe, mas este post só está disponível em Inglês.

(Inglês) We should fire more

Desculpe, mas este post só está disponível em Inglês.