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

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?

User Stories Applied - For Software Development

Ano novo! Energias parcialmente renovadas (ainda não tive as férias que quero) e tempo de terminar a leitura de alguns livros que eu não conseguia me concentrar para ler durante o mês de dezembro devido ao burnout adquirido do último projeto.

Vamos lá!

Desde que eu escrevo a respeito dos livros que leio eu nunca escrevi aqui no blog qual a idéia por trás dos posts de resenhas que faço e acho que esse é um ótimo post para falar a respeito.

A idéia não é nunca foi escrever longos e chatos resumos de livros iguais aqueles que usávamos para as provas de literatura do colégio. Por dois motivo: a) É um pé no saco fazer esse tipo de trabalho e ao invés de ter prazer ao escrever esses posts eu me sentiria entediado (sem falar no tempo que levaria) e b) porque ninguém procura esse tipo de resumo (acredito eu) de livros técnicos ou relacionados a área técnica, pois o conhecimento contido nessas obras não pode ser absorvido apenas com um resumo.

Acompanhando a cronologia dos meus resumos é possível conhecer também um pouquinho mais a respeito de mim e quais focos estou dando para meus estudos. Isso é legal pra eu poder ver a qualidade das leituras que fiz ao longo do tempo quando olhar pra traz e pros leitores enxergarem um ser humano por trás deste blog e não apenas mais alguém escrevendo sobre tecnologia (até coloquei uma foto minha no about! ).

Outro aspecto importante que eu procuro passar nesse tipo de post é o que eu buscava quando comecei a ler o livro e se efetivamente minhas ansiedades e expectativas a respeito do assunto foram atendidas. Além desses pontos também acabo indiretamente dando feedback de onde comprei os livros e fornecendo os preços para que quem quiser possa comparar e ver se está pagando mais caro ou barato.

E como não podia deixar de ser, falo um pouquinho a respeito dos pontos mais importantes do livro e que mais chamaram minha atenção.

Enfim, achei que como esses posts estão entre os mais visitados no blog valia a pena esclarecer as minhas motivações.

Agora é bom falar a respeito do assunto principal do post, né?

Este livro escrito por Mike Cohn é simplesmente f a n t á s t i c o!

Apesar de ter lido bastante a respeito deste assunto na internet e em outras referências ágeis menos específicas, desde que comecei a aplicar práticas e disciplinas ágeis, há algum tempinho atrás, eu vinha esbarrando em agluns aspectos desta técnica e não conseguia alcançar todos os benefícios oferecidos por ela.

Parece que a partir do momento que comecei a ler este livro uma luz se acendeu na minha cabeça. Luz essa que iluminou e sanou as dúvidas que eu tinha sobre o assunto e também a respeito de alguns outros tópicos que eu ainda não tinha uma informação muito concreta e corroborada.

Mike começa o livro falando do básico: o que são histórias, roles, personas, quando usá-las, testes de aceitaçao, como escrever histórias de qualidade seguindo o acrônimo INVEST (assunto pra outro post com certeza) e comparações com outras técnicas oferecendo inclusive uma excelente referência a respeito de casos de uso (use case). Terminar de ler essa primeira parte é mais do que suficiente pra aplicar a técnica já com um certo grau de exatidão e eficiência.

Mais adiante, ele aborda priorização (explicando o excelente acrônimo MoSCoW que com certeza será assunto pra mais um post futuro), estimativas e planejamento. Estes eram assuntos que não eram muito claros em minha mente e que com certeza estão muiiiiiito mais claros agora.

Mais pro final ele apresenta uma introdução rápida a respeito de Scrum e como utilizar as histórias em conjunto com Scrum e também uma introdução aos principais conceitos de XP.

Além da qualidade e quantidade de informações a respeito de user stories, Mike ainda apresenta alguns capítulos dedicados a um case real que começa da identificação das histórias, passando pela estimativa e priorização e indo até os testes de aceitação. Essa parte é importantíssima e agrega muito porque consolida através de exemplos reais (e não aqueles exemplos bobos que esbarramos constantemente) as informações apresentadas em todo o livro.

Se eu tivesse que recomendar um único livro para mudar a forma de pensar das pessoas e para que essas pessoas começassem a fazer software de uma maneira melhor, com certeza esse seria o livro. É “totalmente excelente”!

Me empolguei tanto escrevendo sobre o livro que já ia esquecendo das informações básicas de sempre: o livro possui 268 páginas e pode ser encontrado na Livraria Cultura por R$132,00 (paguei R$80,00 há dois meses atrás). Chegou no mesmo dia que comprei então pra quem não gosta de esperar é uma ótima pedida.

Recomendadissímo!

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.

Pergunto isso, pois aqui no Brasil ainda não temos nenhum grande case (que eu conheça pelo menos) de empresas prestadora de serviços (as famosas consultorias) que tenham investido nesse modelo durante tempo o suficiente (aka bastante tempo) e tenham conseguido se consolidar mantendo dentro de toda a cadeia de consultores e projetos as mesmas práticas e cultura envolvidas na utilização de métodos ágeis.

O motivo para isso não ter acontecido, na minha opinião, é que agilidade é um hype recente e por conta disso as consultorias ainda não chegaram no momento de replicar esse conhecimento para muita gente e muito rápido. Esse conhecimento ainda está na cabeça de poucos e os projetos que estão sendo executados utilizando agilidade são coordenados por estes poucos.

Mesmo em empresas “de verdade” (costumo chamar assim empresas “não consultorias” onde TI é importante, mas não é o core business) ainda não tenho certeza se isso é possível. Sei que o pessoal da Globo.com obteve muito sucesso em disseminar as práticas em mais de dez equipes, mas isso aconteceu com bastante trabalho, muito coaching e depois de algum tempo. Não do dia para a noite. Não tinha como ser diferente. Nesse cenário (vou me dar a liberdade de falar uma possível bobagem) onde a equipe tem um tamanho fixo ou perto disso e a demanda é mais ou menos conhecida acredito que escalar agilidade e disseminar as práticas seja mais fácil. Mas e em um cenário onde essas informações não são conhecidas, como fazer?

Como vocês sabem, trabalho em uma consultoria de software e estamos procurando aplicar práticas ágeis no maior número de projetos que pudermos (e onde agilidade for a melhor estratégia). No entanto, estamos indo com responsabilidade, pois senão de ágil só vamos levar o nome e nada da cultura. Por conta disso, esse movimento ainda não está em seu ápice de maturidade e poucos projetos (em relação ao todo que a empresa executa) estão utilizando dessas práticas. Contudo, a demanda por essas práticas está aumentando de uma maneira gigantesca e em algum momento a cultura e as práticas vão se perder se nada for feito a respeito.

Em resumo, temos um cenário onde a demanda não é conhecida nem de perto, as pessoas que farão parte dos novos projetos também não são conhecidas (pelo menos a maioria) e o tamanho das equipes e requisitos não são sabidos. Ai volto para pergunta inicial: como escalar e ainda assim obter consistência com agilidade em um curto espaço de tempo? Tenho certeza que não existe resposta mágica para essa pergunta.

É por isso que estou iniciando uma pesquisa não focada em agilidade e nem em aspectos técnicos, mas sim em um assunto que eu pouco vi comentado nas minhas leituras: capacitação de equipes ágeis. Ok, ok, ok…vocês vão me dizer que tá cheio de gente por ai que ministra cursos de capacitação de equipes em Scrum, XP, etc. Só que quando falo de capacitação, não estou falando em dar um treinamento de dezesseis horas para uma equipe e deixar a bola rolar. Isso, apesar de fundamental, está longe de ser suficiente.

Para inciar o estudo, estou me apoiando na experiência adquirida pela Toyota com a utilização do método de Instrução de trabalho e que está disponível em diversas literaturas onde cada um dos operários da linha de produção é um instrutor em potencial. É desse tipo de capacitação que estou falando. Executar um processo detalhado e peculiar (como são as metodologias ágeis) com a mesma precisão e qualidade em todas as pontas. Independente de gestão, equipe e localidade. Compartilhar os mesmos principíos desde o estagiário até o último nível da gestão. Para atingir esse objetivo é necessário aplicar um esforço brutal em treinamento e capacitação para que, na eventualidade, seja possível formar uma nova equipe treinada e preparada rapidamente.

Portanto, se alguém tiver experiência ou conhecimento de referências sobre esse assunto peço encarecidamente que compartilhe comigo (e com todos os leitores do blog), pois tenho certeza que esse é um assunto que em breve vai dar bastante dor de cabeça para muita gente. A idéia não é ficar esperando sentado até que as práticas e o nome se deteriorem pelo mau uso, mas fazer algo a respeito.

Conforme eu for avançando vou compartilhar minhas descobertas e experiências com vocês. Me desejem boa sorte.