Archive for December, 2008

Framework, método e música

2008-12-26

 Na produção musical, um artista busca fazer músicas que agradem ao seu público.

Alguns músicos gostam de se isolar, utilizam seu violão para testar acordes, vão anotando, revisando, enviam o material para um colega músico. Recebe sugestões de instrumentistas, altera o conteúdo, a forma, e por fim, dá se por satisfeito com sua produção. Eventualmente, esta música pode ser juntada a outras de sua produção e pode gravá-las em estúdio. Lançando assim mais um LP.

Outros músicos se reúnem com amigos, começam a improvisar, colaboram e vão anotando na mesa, em pedaços soltos de papel. Vão a bares e apresentam a públicos pequenos aqueles trabalhos inéditos. Veem a reação do público. Apresentam gravações a produtores, elaboram mais e assim fazem suas criações.

Em cada artista conhecido vemos manias, processos ou a falta deles, inspiração e produções diferentes.

Alguns artistas são aclamados pelo público, outros nem tanto. A qualidade da música que o artista apresenta ao público mostra dois componentes que se combinam em grandes sucessos.

O primeiro elemento é o talento dos músicos. Nos perguntamos: “Esta música é boa ?”. O público adora. A melodia é genial! Os versos, então…

O segundo é a produção da música. “Como foi gravada e como foi lançada ?”. Ela foi gravada com qualidade em estúdio de primeira linha. O som está de acordo com a proposta da música. A mídia de lançamento é de boa qualidade, com excelente arte gráfica. Os interpretes fizeram jus ao material.

Traduzindo esta alegoria para o mundo dos frameworks e metodologias, o músico com seu produtor seguindo certa rotina na criação estão de fato, utilizando uma metodologia. Esta metodologia pode atrapalhar o músico ou ajudá-lo na criação. Isto não determina se o músico vai conseguir fazer a música, e muito menos se a música vai ser boa.

Um framework como Scrum, determinaria apenas a necessidade de pontos de inspeção e adaptação. Isto poderia ser atingido testando músicas com platéias selecionadas, apresentando demos para determinados produtores que conhecem bem o mercado, etc. Com este feedback o artista poderia então alterar a música e evoluir o seu produto. Isto também não determina se o músico vai conseguir fazer a música, e também muito menos se a música vai ser boa.

Um framework como Scrum ajuda na medida em que o feedback ocorre mais cedo e continuamente, mas não faz a música ser boa. O que faz a música ser boa, em primeiro lugar, é o músico.

Em software, o trabalho de arquitetura é necessário. A metodologia te obrigará a trabalhar a arquitetura de uma determinada forma com determinados entregáveis. Scrum não te obriga a fazer arquitetura, arquitetura é parte do que é necessário ser feito, e portanto, fora do que um framework obriga. Em ambos os casos, alguém que seja bom arquiteto será necessário para fazer o software. Se não houver alguém bom em arquitetura para fazer o software, o software vai ficar ruim!

As metodologias nos lembram de tudo que é necessário para se fazer um software de qualidade. É preciso arquitetura, design, testes, etc. As metodologias obrigam um passo-a-passo que se propõem a garantir que tudo que é necessário para um software de qualidade vai ocorrer.

Scrum por outro lado, se traduz em práticas que vão ajudar os profissionais a fazer o que seus talentos os permitem, sem tentar amarrá-los. Ainda assim, a arquitetura precisa ser feita, o software tem que ser programado e o teste tem que ser feito.

Para fazer música são necessários bons músicos. Para fazer um bom software são necessários bons programadores. As metodologias nos lembram disso e para isso foram criadas. Nos obrigam a fazer tudo o que tem que ser feito e com isto nos amarram. E muitas vezes nos emperram, tirando o espaço para melhores músicas e criatividade.

Scrum não amarra a produção. É tarefa das pessoas lembrar que cada necessidade tem que ser endereçada com seu respectivo talento. A arquitetura pode ser simplesmente pensada, pode ser rabiscada no papel ou pode fazer parte de um documento formal. A necessidade de fazer arquitetura existe pela natureza do problema (fazer software).

Estudar metodologias é salutar e necessário aos mais jovens e inexperientes. Não para amarrá-los, mas para que eles tenham ciência do que é necessário. É o feijão com arroz de se fazer música.

E finalmente, para fazer boa música, o cara tem que ser bom! Quem se preza como músico precisa saber do seu riscado.

Não é uma pena… deve ser horrível quando isto acontece.

2008-12-16

 

Para inaugurar este blog, gostaria de fazer alguns comentários que são relacionados ao grande número de críticas a Scrum e também relacionados aos defensores que vêm Scrum como a nova bala-de-prata para fazer sistemas.

É provável que o fator mais importante relacionado ao surgimento de Scrum seja a epifania que tiveram alguns profissionais da área de TI de que eles tinham de fato um compromisso profissional ao realizar suas tarefas dia-a-dia.

Este compromisso profissional não pode ser entendido como as obrigações mundanas a que os profissionais de TI são submetidos. É um compromisso ético. É o entendimento de que está em suas mãos e possibilidades gerar mais valor do que é gerado.

Estes profissionais compreenderam, com muito trabalho e várias experiências falhas e sucedidas, que é necessário considerar conseqüências. É obrigação pensar no retorno que o seu trabalho traz. É obrigação informar claramente sobre riscos, ganhos, vantagens e desvantagens do fruto de seu trabalho. Acima de tudo, eles passaram a acreditar que independente das regras impostas pela sua indústria, ao se ter a opção de gerar mais valor e a de gerar menos valor, deve-se escolher os melhores frutos.

Um paralelo interessante pode ser traçado utilizando-se a profissão médica. O médico tem um compromisso ético com a saúde do paciente. Este compromisso tem que estar acima da imposição institucional ou da indústria. O médico deve receitar o melhor remédio, e não lhe pode ser imposto o que receitar ou como tratar o paciente.

O médico considera vários fatores ao tratar uma doença ou condição. Ele tem a obrigação de informar ao paciente dos riscos de linhas diferentes de atuação. Uma vez iniciado um tratamento, não consideramos que há como pressionar o médico a curar o paciente mais rápido.

Desta forma, o profissional da área de TI não pode seguir cegamente um processo de software, não será mero escravo das imposições do cliente ou de uma instituição sem pensar que deve agir honestamente. Daí vem a importância da transparência de Scrum. É obrigatório que as escolhas feitas sejam informadas. Os “riscos do tratamento” têm que estar claros. Se o diagnóstico é de difícil tratamento, isto tem que ser entendido pelos envolvidos no projeto. Os Stakeholders têm que saber o que se passa para ter sua influência representada de forma compatível.

Este é o pano de fundo de Scrum e dos métodos ágeis em geral. E independente das regras que surgiram após este ponto inicial, devem ser estes pontos que nos norteiam, e não as regras e práticas.

Uma analogia jurídica está na consideração do texto constitucional. A constituição fica acima das outras leis, é mais forte que estas. Em alguns casos, leis municipais ou estaduais complementam estas leis, ditam procedimentos, normatizam direitos e deveres. Em outros, estas leis são julgadas inconstitucionais, estão em conflito com algo mais básico e importante, e, portanto não podem valer.

Scrum não é uma metodologia. Scrum é a arte do possível, é um framework com regras simples de como trabalhar. Não vai te dizer como resolver problemas. O que Scrum tenta fazer é te ajudar a ter transparência, te ajudar a buscar a geração de valor.

De certa forma, é similar a grande frase da declaração de independência americana: “We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.”

É um direito inalienável “perseguir” a felicidade. Não é um direito inalienável tê-la.

Da mesma forma, devemos buscar gerar valor. Não necessariamente vamos conseguir.

A visão de que Scrum resolverá todos os seus problemas é um grande engano. Em primeiro lugar, Scrum é uma tentativa de evidenciar problemas. Resolvê-los caberá a cada um.

Outro dia li um artigo (http://alistair.cockburn.us/Why+can’t+people+deliver%3f) do Alistair Cockburn em que ele dizia que ter uma espada sem saber usá-la não o faria ganhar uma luta contra um exímio lutador de faca.

E é justamente nesta dimensão que está o centro da questão da maioria das críticas e defesas ferrenhas. Independente de suas práticas, você só vai curar doentes se souber e aplicar medicina. Só ganhará uma luta de espadas se for bom esgrimista (Samurais incluídos).

 Quando fiz o treinamento de ScrumMaster com o Ken Schwaber, tive a oportunidade de fazer várias perguntas capciosas a ele sobre situações específicas. Eram dilemas, problemas complicados que me pareciam não ser resolvidos de forma clara. Problemas que continuavam problemas.

A maior parte das respostas eram na forma de: “Pois é, que problemão que VOCÊ tem, hein ? Depois me conta como vocês fizeram.”;

E é isso aí. Sem mágica. Sem fórmulas, apenas mais obrigações e uma melhor consciência na nossa atuação.