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

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!

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.

Lendo a opinião das pessoas, é possível separar em dois grupos distintos os tipos de reclamação:

1. Os “early-adopters” de Agile que acreditam que, por causa da chegada de Agile ao main stream aqui no Brasil, as práticas ficaram(ão) deturpadas e distorcidas e que agora todo mundo diz que é ágil, mas na prática,de acordo com a opinião desses mesmos “early-adopters” não são;
2. As pessoas que não acreditam que seja possível a co-existência entre CMMI e Agile e recusam-se a acreditar que isso possa trazer benefício algum;

Eu discordo dessas duas linhas de pensamentos e acredito que, mais que nunca, agora é que a coisa principalmente aqui no Brasil tende a melhorar.

Neste post, James Shore conta que antigamente ele era chamado para introduzir agilidade nos ambientes corporativos (e da a entender que essa época era boa). No entanto, hoje ele é chamado para ajudar a corrigir equipes “so called agile” que na verdade de ágil não tem nada. Bom… os tempos mudaram! É pouco provável que essa época onde a iniciação em agilidade deveria ser feita por um dos agile-gurus durasse pra sempre.

Como eu disse acima, o movimento chegou ao mainstream, mas isso só aconteceu porque quem iniciou esse movimento assim o quis. Agile veio do povo para o povo e isso agora incomoda muita gente. Hoje, quem quiser manter o título de master-introduzidor-de-agilidade-e-coaching vai ter que ralar e se ajustar as novas demandas.

Ainda comentando a respeito do primeiro grupo de opiniões, assim como a bíblia (é, aquela sagrada a respeito de Deus) e de acordo com os próprios autores de alguns livros conhecidos como referência (Scott Ambler em Agile Modeling e Ken Schwaber em Project Management with Scrum, por exemplo), práticas ágeis são apenas o que o próprio nome diz: práticas!

Como não são um how-to detalhado que você deve aplicar em todas as ocasiões e muitas vezes bastante abstratas são passíveis de interpretação. Sendo assim, como alguém pode dizer se você é ou não ágil? Se as práticas que você aplica estão trazendo resultados satisfatórios qual o problema em se referir ao termo agilidade? Está acontecendo a mesma coisa que acontece com alguns usuários de Linux e alguns participantes de projetos open-source: as pessoas estão se apegando demais aos termos e títulos e deixando de lado realmente o que o movimento prega. Parece ciúmes.

Movendo agora o foco para o segundo grupo de reclamantes, acredito que afirmar que CMMI é incapaz de trazer benefícios para as práticas ágeis é no mínimo uma contradição visto que um dos princípios básicos de agile é adaptação. Sempre quando alguém fala a respeito de como iniciar com metodologias ágeis uma das primeiras recomendações que ouço é “Não tente mudar o processo antes de utilizar ele da forma padrão. Experimente e depois decida se é necessário fazer alterações”. Olha lá! Mais um motivo para não fazer essa afirmação de que nenhum benefício pode ser colhido dessa co-existência. Como alguém pode afirmar que não vai dar certo se esse report foi uma das primeiras menções (se não a primeira) a respeito dessa co-existência e nada concreto ainda foi gerado? É a mesma coisa que dizer que não gosta de brocólis sem nunca antes ter provado.

Não sou expert em CMMI, tão pouco em Agile. No entanto, se verificarmos a origem do CMM e como a transformação ocorreu para o CMMI é possível entender porque as práticas são tão distoantes. O CMM teve origem no departamento de defesa dos Estados Unidos. Eles precisavam de um modelo que pudesse garantir que o software funcionando em um avião militar não parasse de funcionar no meio de um vôo. Hmm… não precisamos pensar muito pra concluir que antes de testar um treco desses em produção (guerra?) ou em homologação (vôo de treinamento?) seriam necessários muitos testes para garantir que os milhares de dólares que essas belezinhas custam não fossem jogados no buraco; sem falar na vidas dos pilotos.

Dessa forma, acredito que essa abordagem extremamente pesada, com longa duração e diversas exigências de verificação e validação em diversos níveis hierarquicos, de fato, não parece a pior opção pra esse cenário.

São duas abordagens diferentes e que devem ser usadas em cenários diferentes. O perigo é conhecer uma ferramenta só (martelo) e sair martelando tudo que encontrar pela frente até quando o alvo não é um prego, mas sim um parafuso.

Em resumo e para conluir (já escrevi muita coisa…) acredito que é cedo pra afirmar qualquer coisa e que não devemos nos opor tão radicalmente as mudanças (como o próprio manifesto prega). Se essas mudanças tanto no aspecto da ascensão de Agile ao mainstream quanto das mudanças oriundas da co-existência com CMMI forem pra melhor, vão permanecer. Se forem para pior, com certeza o mercado logo, logo esquece… e se não esquecer cada um pode sempre criar seu próprio mundo onde tudo é bonito e belo!

Brincadeira! Mas de fato, em uma conversa ontem com a patroa descobri que as mulheres (pelo menos ela) tem mais facilidade pra entender alguns principios da agilidade do que muitos homens.

Estavamos conversando sobre nossos trabalhos (ela trabalha com logística/compras) e caimos no papo de projetos em geral e no porque especifíco da maioria dos projetos de software falharem. Expliquei pra ela que um dos motivos é a utilização de modelos em cascata onde em um projeto de 12 meses o fornecedor fica 4 meses junto com o cliente no início do projeto e só da as caras novamente 8 meses depois com um software (ou parte dele apenas) fresquinho funcionando.

Foi incrível que no momento que terminei de explicar o processo em cascata e ia começar a falar a respeito de agilidade ela me interrompeu (ela não sabe nada de software) e traçou um paralelo MUITO legítimo que serve como um ótimo exemplo da aplicabilidade de métodos agéis. Explico:

No tempo livre ela pratica dança do ventre e, esse ano junto com seu grupo de dança, ela participou de duas apresentações abertas ao público. Para isso, o grupo teve que encomendar roupas sob medida e combinando até certo ponto entre si. Foi ai que os problemas começaram. Apesar de seguirem um modelo básico -como quando construimos softwares diferentes para o mesmo seguimento de empresas- cada roupa tinha suas peculiaridades -assim como as regras de negócio especifícas de cada empresa-. Ela passou as necessidades de sua roupa pra professora do grupo -podemos chamá-la de analista de negócios- e essa por sua vez especificou para as costureiras da empresa fornecedora -os programadores!- como o cliente queria a roupa. Conversaram uma ou duas vezes na primeira semana e depois de aproximadamente 3 meses a roupa estava pronta e perfeita!

Será que estava mesmo?

É claro que NÃOOOOOOOOOOOOOOOOOOOOOOOOO!

(Até então eu imaginava que processos em cascata falhassem só em projetos de software, mas pelo jeito parece que não)

Já com a roupa nas mãos e p*** da vida por ter gasto uma grana preta com a roupa (acreditem, custa caro) que apesar de seguir um esqueleto básico e padronizado não estava nem perto de estar pronta (tamanho, cores e acessórios errados) ela entrou em contato com o fornecedor. Apesar dos problemas ela imaginou que seria possível consertar a roupa a tempo da apresentação que iria acontecer em 1 mês. No entanto, ao final desse mês e no dia da apresentação a roupa tinha sido consertada, mas ainda estava cheia de problemas -assim como as milhares de não conformidades de software feitos por esse processo-. O jeito foi se apresentar do jeito que estava (meia boca) -ida a produção!- e ainda hoje (6 meses depois) ela ainda esta brigando com as costureiras pra ter a roupa 100%.

O mais interessante é que depois de me contar essa história, ela mesmo conseguiu chegar a solução mais óbvia (que ainda não entra na cabeça da maioria das pessoas no nosso mercado de software) que havia pra evitar ou diminuir os problemas com a roupa: provar semanalmente a roupa junto com as costureiras ao invés de ver apenas o resultado final depois de um tempão. Ou seja, abstraindo um pouco mais temos: ITERATIVIDADE, PARTICIPAÇÂO DO CLIENTE, ACOMPANHAMENTO FREQUENTE e muitos outros príncipios da agilidade.

A idéia dessa analogia que nem saiu da minha cabeça não é mostrar que é possível fazer roupas com metodologias agéis, mas sim o quão prejudicial é desenvolver software sob medida de forma cascateira. Ser ágil, ou ao menos iterativo é muito fácil e os benefícios são claros.

Ultimamente tenho conversado bastante com pessoal da área comercial e todos confirmam o que nós consultores já sabemos: os clientes estão cansados de perder dinheiro com projeto de software! Acredito que agilidade ainda não é uma coisa mais bem aceita e padronizada no Brasil porque a maioria dos clientes compradores de software ainda não sabem que uma alternativa a processos cascata e escopo fechado existe.

Sendo assim, por meio desta analogia das roupas ou por esta outra do Alexandre Magno ou ainda com esta do Vinicius da Improve IT nosso papel é evangelizar os clientes e promover métodos agéis, pois somente desta forma essa bagunça que é nosso mercado hoje vai mudar!