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.

No entanto, existem algumas abordagens que podemos utilizar a fim de chegar em um consenso. Vou falar um pouquinho a respeito e se alguém tiver algo a contribuir, será melhor ainda.

Atualmente vendemos software na ilusão de que alcançaremos prazo, custo e escopo sem surpresas. Mas… isso não é verdade. Nunca foi. Trabalhar dessa maneira, a não ser que seja em um ambiente conhecido e extremamente controlado quase sempre nos leva a fracassar em um desses pontos, quando não em todos.

O ideal nesse caso, é sentar com quem vende, com quem elabora contratos, com a área jurídica e com quem executa e procurar o modelo ideal para sua oferta de agilidade. Scrum, XP, MSF são apenas modelos de gerenciamento de projetos e engenharia, que não dizem como realizar essa venda. Isso não é o papel dessas ferramentas. Cada empresa deve encontrar sua forma de trabalhar essas ofertas.

Se utilizarmos métodos ágeis e iterativos em uma proposta de escopo fechado das duas uma: ou não vamos efetivamente trabalhar de maneia iterativa, pois precisamos controlar o escopo o tempo todo ou como fornecedores vamos tomar prejuízo, pois provavelmente o escopo será maior do que o contratado já que não conseguimos medir de maneira confiável o escopo de um projeto em tempo de proposta.

Fora do Brasil um modelo de venda que já é muito aceito e difundido é o “Tempo e Material” (Time and Material) que é basicamente trabalhar “hora aberta”, ou seja, o fornecedor recebe X por cada hora trabalhada. Posso afirmar com certeza que essa é a melhor maneira do fornecedor de trabalhar com metodologias ágeis já que não temos um cronomêtro financeiro em contagem regressiva. Mas será que essa é a melhor maneira pro cliente? Muitos deles dizem que sim, pois se a consultoria aplicar realmente um modelo ágil é fácil medir e verificar se o trabalho está sendo feito e se está sendo feito de maneira adequada atendendo as expectativas e objetivos do cliente. O problema é que nosso mercado, principalmente as repartições públicas, não estão preparadas para isso, ainda. Fornecedores e clientes ainda não se entenderam a ponto de confiarem uns nos outros e acreditar que esse modeo colaborativo funciona melhor do que o baseado em documentos que-me-protegem-de-qualquer-mudança ao qual estamos acostumados. Enquanto isso não acontece (e tenho fé que vai acontecer!) temos que continuar vendendo e comprando e trabalhando para alcançar os objetivos do cliente.

Para diminuir um pouco esse medo dos clientes de serem enganados e gastarem demais e diminuir o risco do fornecedor na presação de serviços existem algumas coisas que podemos fazer.

Uma delas é adicionar uma cláusula de fuga nestes contratos “hora aberta” que permite que, caso um cliente ou até mesmo o fornecedor não esteja satisfeito com o andamento do projeto, este possa cancelar o contrato sem onûs para ambos os lados. Dessa forma, é possível “obrigar” tanto ao fornecedor quanto ao cliente a trabalharem em conjunto, pois se qualquer um pisar na bola o outro pode sair fora num piscar de olhos.

Outra maneira é elaborar um contrato de preço fixo e com tempo estimado utilizando qualquer técnica com as quais já estamos acostumados, mas não fixar completamente o escopo do projeto ou então garantir que apenas uma parte do escopo seja entregue. Talvez algo entre 60% e 80%. Isso também diminui um pouco o risco do fornecedor em dar um preço fechado e ao mesmo tempo garante ao cliente que ele terá seu sistema desenvolvido com um método de qualidade mesmo sem ter 100% de escopo definido em proposta entregue. Na verdade, muitas vezes isso nem é necessário já que o principrio de pareto afirma que 80% dos benefícios gerados por um sistema são proporcionados por apenas 20% das funcionalidades.

Seja qual for a maneira que você trabalha, o mais importante é estar alinhado com seu cliente e trabalhar de maneira honesta e transparente porquê se você for sinero e honesto e realmente ajudar seu cliente a atingir seus objetivos, ele provavelmente não irá te deixar na mão. Isso também vale para clientes. Se você ajudar seu fornecedor e não procurar tirar vantagem de contratos que obriguem ele a ter prejuízo com certeza ele não irá faltar com você e te ajudará a crescer.

Referências adicionais

José Papo Website – Apresentações e informações a respeito de contratos ágeis

Improve IT – Modelo de contrato ágil

Isso acontece, pois durante este período o desenvolvedor ainda está aprendendo como a coisa funciona e não tem certeza se esta dando certo ou não. Além disso, esbarramos vez ou outra em código legado que inviabiliza dificulta os testes. Isso é normal, não só com TDD, mas com uma série de práticas/tecnologias que temos que aprender para melhorarmos nosso produto final.

O importante é esperar este período e continuar se esforçando para que os resultados comecem a aparecer.

Recentemente a InfoQ BR traduziu um excelente artigo de Mark Levision sobre este assunto que vale a pena conferir.

Estou terminando de ler, mas já da pra adiantar que é uma técnica de gerenciamento pessoal de atividades muito parecida com Scrum. Ela é baseada em uma lista de todo’s para o dia a dia e espaços de tempos definidos e fechados para execução dessas atividades. Tudo muito simples e funcional, assim como Scrum.

Vou começar usar a partir de amanhã e comento sobre os resultados posteriormente. Vale a leitura!

Para essas pessoas eu trago hoje um vídeo feito pelo Hamid Shojaee que apresenta Scrum em menos de 10 minutos. Não concordo com tudo que ele fala e com certeza algumas partes fundamentais ficaram fora, mas para dar um gostinho do que Scrum é vale a pena ver.

Segue o vídeo:

Outro material muito interessante de referência e complementar é um PDF famoso chamado “Scrum in Five minutes”. Também vale como introdução e é rapidinho de ler.

É importante ressaltar que estes materias são bastante básicos e não são totalmente completos. Sendo assim é fundamental procurar outras fontes de informação antes de sair fazendo de qualquer jeito e dizendo que usa Scrum. Ok?

Fui pesquisar, mas não encontrei nenhuma ferramenta gratuita web que pudessemos usar. Foi ai que surgiu o .NET Scrum. A idéia não é construir nada pra competir com o que existe por ai, mas utilizar da idéia pra ter um laboratório e construir um projeto onde possamos aplicar o que há de mais novo em tecnologia além de boas práticas de engenharia e condução de projetos.

Portanto, quem der uma olhada no projeto e quiser contribuir ou apenas acompanhar vai encontrar um ASP.NET MVC, jQuery, NHibernate usando interfaces fluentes, DDD, TDD, Spring.NET e outros frameworks e design patterns importantes para a construção de uma boa solução em .NET.

Se deixarmos de lado a parte tecnológica também é possível aprender um bocado trabalhando na organização de um projeto open source. Projetos de código aberto e mantidos pela comunidade são o maior caso de sucesso de times distribuidos trabalhando juntos a fim de atingir um objetivo. Se já é difícil obter sucesso em um projeto com o time no mesmo lugar, imagine trabalhar com pessoas que você nunca viu na vida e com comunicação relativamente limitada? Um grande desafio!

O Maurício Aniche que participa do DotNetArchitects já se juntou ao projeto pra me ajudar. Já existem alguns códigos publicados no codeplex e uma documentação miníma também. Quem quiser ajudar é mais do que bem vindo!

Revista Mundo NET - Edição 12

Recebi em casa e com certeza também já está nas bancas a edição número 12 (novembro-dezembro) da revista Mundo NET. Nesta edição meu artigo (escrito em conjunto com André) fala a respeito da utilização de Scrum junto com o Microsoft Team System como ferramenta e mais algumas dicas e cuidados que se deve ter na adoção de uma metodologia ágil como Scrum.

Além da minha contribuição a revista traz ainda artigos sobre Parallels Extensions pro .NET (que eu já comentei aqui), sindicalização ATOM e um super apanhado a respeito de coleções e estruturas de dados entre outros.

Não sei se foi só eu ou se outros leitores também vão ter a mesma reação, mas me espantei com a qualidade da impressão desta edição e da parte gráfica da revista que ficou muito legal, diferente do que estamos acostumados a ver.

Vale a pena conferir!

Eu acredito que existem diversas formas de se executar um projeto, mas na minha humilde opinião nesta apresentação o Jeff Sutherland da a entender que Scrum é a única forma de se trabalhar e que serve pra todos os cenários e empresas. No entanto todos sabem que cada caso é um caso e que não existe uma única maneira que vai dar certo pra todos.

Não sei se é meu inglês que está meio enferrujado, mas durante alguns momentos da apresentação ele me pareceu muito arrogante falando de coisas que já viu e que está acostumado a ver. Não acho que é a melhor maneira de melhorar as coisas agindo desta forma.

Apesar desses dois pontos que eu não gostei muito é um excelente vídeo que acrescenta bastante no aprendizado e uso do Scrum.

De qualquer forma, vou colocar aqui também pra fazer mais jabá!

Tá, tá, tá. Eu estava nervoso no começo, mas depois a coisa fluiu melhor.

Críticas como sempre, são bem vindas.

Espero que gostem!