Archive for the ‘Publicado em Português’ Category

Faço parte de um time, o que não posso deixar de saber sobre Scrum ?

2009-06-06

Faço parte de um time, o que não posso deixar de saber sobre Scrum ?

Se você faz parte de um time e sabe pouco sobre Scrum, não se desespere. Aqui está um pequeno conjunto de dicas para você:

1. Seu time precisa de um ScrumMaster. O ScrumMaster deve saber sobre Scrum e vai te ajudar nas suas dúvidas. Não pense que você precisa saber tudo sobre Scrum, este é o trabalho dele. Não se preocupe se você não se tornar um perito em Scrum. Não é esse o seu trabalho.

2. Aprender quais são os papéis básicos, artefatos e atividades de Scrum é muito fácil, e você deve ser capaz de entendê-los com apenas alguns minutos de leitura. Você deve saber o mínimo, o básico sobre Scrum. Esta é a parte fácil e todos do time deveriam saber de cor. Se dê um tempo para aprender na prática.

3. Compreenda que o uso adequado de Scrum requer boa comunicação. Enquanto conhecer as regras básicas de Scrum é fácil, aprender a usar Scrum de forma eficaz é difícil. Confie no seu ScrumMaster, converse com ele, converse com os outros integrantes do time. Mantenha os canais de comunicação abertos. O seu ScrumMaster será capaz de te ajudar.

4. Você tem um conjunto de talentos e um trabalho a fazer. Se alguém ou alguma coisa não estão te permitindo fazer o seu trabalho, há algo de muito errado. Converse com os outros a este respeito. Informe o ScrumMaster sobre o que está havendo. Peça ajuda. Um dos conceitos básicos de Scrum é o de deixar as pessoas que sabem como fazer um trabalho, fazê-lo.

Se você sabe sobre Scrum ou não, eis uma regra para todos:

5. Nenhum projeto pode ser bem sucedido se você não conhece sua arte, não importa o quanto você saiba sobre Scrum. Se aprofunde nos estudos sobre arquitetura, leia sobre design patterns, leia sobre UML, mergulhe no aprendizado de testes ou gestão de configuração. Aprenda sobre TDD e integração contínua. Todas estas coisas são essenciais para se fazer software. Se você está trabalhando em uma área de negócios sobre a qual você nada sabe, procure saber e aprender um pouco sobre ela.

Se você puder aprender sobre ferramentas que potencializam seu conhecimento, o faça.

Conheça o SEU negócio antes de mais nada.

Um bom programador com um processo terá uma desempenho melhor que um bom programador sem, mas tudo que um programador ruim pode fazer com um processo é relatar muito bem como as coisas vão mal.

Advertisements

O Tao do Scrum

2009-01-02

Este post trata de mais uma analogia buscando o entendimento da relação entre o desenvolvimento de sistemas, metodologias em geral e Scrum.

Começo este texto com citações de Bruce Lee:  http://en.wikiquote.org/wiki/Bruce_Lee

Don’t get set into one form, adapt it and build your own, and let it grow, be like water. Empty your mind, be formless, shapeless — like water. Now you put water in a cup, it becomes the cup; You put water into a bottle it becomes the bottle; You put it in a teapot it becomes the teapot. Water can flow or it can crash. Be water, my friend.”

“Do not deny the classical approach, simply as a reaction, or you will have created another pattern and trapped yourself there.” — Tao of Jeet Kune Do

Bruce Lee ficou muito famoso através de suas aparições no cinema americano em que retrata artes marciais de forma realística pela primeira vez no Ocidente. Na época as artes marcias orientais eram muito restritas no ocidente e a participação de Bruce Lee nas telonas gerou um grande furor e consequente interesse nunca antes visto pelas culturas orientais.

Além de conhecer profundamente artes marciais, Bruce estudou filosofia na Universidade de Washington. Era um perfeccionista, e parecia buscar para sua própria vida um desenvolvimento mental e um desenvolvimento físico compatível.

Através de sua filosofia fica fácil entender porque ele é considerado o “artista marcial” mais influente do século 20.

Antes da criação das artes marciais, o homem em conflito tinha que agir de forma livre nos combates corpo-a-corpo. Os instintos eram dominantes quando o treinamento não existia. As artes marciais surgiram através de estudos dos movimentos de animais e do corpo humano. Buscava-se eficiência, conhecimento do corpo e controle.

A “era” das artes marciais trazia consigo uma forma de combate e uma forma de ensino. Junto com o conhecimento obtido do corpo e de seus movimentos e capacidades veio o formalismo e as doutrinas.

Com o tempo, as diferentes artes marciais (conhecidas hoje e já extintas) passaram a se basear em formas sólidas, se tornaram sequências pré-estabelecidas de movimentos. Se tornaram quase coreografadas e viraram dogmas. Os diferentes estilos eram comparados e cada clã defendia a sua forma de agir e mover.

Quando Bruce Lee cria o Jeet Kune Do, ele propõe uma quebra nas formas fixas, ele propõe no Ocidente que se utilize nas artes marciais aquilo que funcione, que seja eficiente, e não o que seja dogmático. Ao criar o Jeet Kune Do, Bruce mistura as artes marciais que estudou tentando criar a arte marcial definitiva.

Quando caras geniais como  Ivar Jacobson Grady Booch  James Rumbaugh criaram UML e RUP de certa forma eles buscavam o mesmo que Bruce. RUP deveria ser a forma definitiva de se desenvolver sistemas.

Acontece que com Bruce a história acabou sendo diferente. Em pouco tempo Bruce levou a filosofia para os seus próprios movimentos. Bruce concluiu que qualquer arte marcial, incluindo o Jeet Kune Do, solidificava o homem e que, portanto o limitava na hora do combate. Não havia fórmulas que fossem suficientes. Era necessário conhecer o próprio corpo e mente profundamente. Era necessário adaptar os movimentos às necessidades sempre, e não o contrário.

Bruce desejava ser como a água! Adaptável a qualquer situação. De certa forma, Scrum busca isso. Scrum prega a adaptação, e auto-inspeção. Ao mesmo tempo em que não solidifica como devemos nos mover nos pede que façamos o melhor que podemos. Por isso, Scrum não é uma metodologia, e sim um framework. O que é buscado é justamente o espaço para que possamos adaptar os nossos movimentos ao combate que se apresenta na nossa frente.

Em contrapartida, a rejeição pura e simples das artes marciais não vão te levar a conhecer mais as capacidades de movimento e ação que o corpo humano proporciona. Da mesma forma, a fuga deste conhecimento pré-existente nos solidifica e impede o crescimento.

Ninguém começa a lutar de forma eficiente sem forma ou método. Para se desenvolver um alto nível de excelência as formas e métodos são necessários. Deve-se estudá-los e conhecê-los, ao mesmo tempo procurando ficar livres deles.

Assim, Scrum é o fundo libertário de quem conhece as suas práticas e métodos. Sabe usar diferentes métodos conforme as necessidades. Afinal, conhecendo a capacidade do corpo, o braço tem suas formas de movimento. As pernas não chutam em qualquer forma. A liberdade é limitada pelo que temos ao nosso dispor, pela nossa realidade.

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.