http://br.groups.yahoo.com/group/scrum-brasil/message/5618

Um dos maiores benefícios do Scrum é organizar o backlog nos seus itens e suas prioridades. O objetivo do Scrum é matar o backlog, ou ter o maior retorno possível com os itens do backlog que são implementados Sprint por Sprint, de maneira iterativa. Como falei no post anterior, o objetivo do Sprint é ter funcionalidades potencialmente implantáveis. Mais uma vez, esse é um conceito fundamental do Scrum que muitas vezes é esquecido, essencialmente porque isso é garantido por boas práticas de engenharia.

Definição de pronto é uma premissa que visa garantir que o que está sendo entregue REALMENTE atende as necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnlogia. A Definição de Pronto tem relação com a qualidade, a manutenção futura do sistema e os objetivos do produto. Logicamente isso pode variar de projeto para projeto, mas não tem relação alguma com a maturidade da equipe. Se a equipe não consegue atender ao critério definido afrouxar o critério pode ter consequências desastrosas…

Vou dar um exemplo aqui de como ter uma má definição ou ter essa definição baseada nos skills da equipe pode ser ruim. Imagine que estou fazendo um produto de software para o mercado. Esse geralmente é o ambiente ISV que tenho trabalhado. Um software desses atende centenas de usuários, deve ter uma manutenção constante e barata, ter um deployment fácil, excelente usabilidade e farta documentação do usuário e sistema.

Se você quiser fazer um exercício, prezado ScrumMaster, peço que você escreva o que você acha que deve ser a definição de pronto deste produto antes de prosseguir a leitura do artigo.

Estamos iniciando o primeiro Sprint depois de uma concepção ágil e visamos nesse primeiro Sprint entregar as funcionalidades mais importantes para nossos usuários (e espero que vocês também estejam fazendo isso nos Scrums de vocês). Bem, vamos escrever uma definição de pronto baseada na maturidade comum das equipes que vemos por aí:

Definição de Pronto 1.0:
Testado no ambiente de homologação

Na primeira iteração a equipe está super contente com o resultado. Eles conseguiram “entregar” umas 5 ou 6 histórias. O Product Owner até esboçou um sorriso no Review e a moral da equipe está no alto (primeira entrega no Green Field sempre é assim).

Inicialmente essa definição de pronto parece ser boa. Há um sentimento de valor sendo entregue. Até a quinta iteração essa definição pareceu boa, porém, a equipe percebe que ela está cada vez mais devagar. Com as funcionalidades se acumulando está cada vez mais difícil executar os testes e refatorar o sistema para entrar os itens do backlog. A qualidade está decaindo rapidamente. Este cenário é bastante conhecido e bastante citado aqui no blog: A FALTA DE PRÁTICAS ÁGEIS DE ENGENHARIA como testes automatizados, integração contínua e etc…

Esse problema foi causado porque nossa definição de pronto era baseada na maturidade da equipe, e não nas necessidades do projeto. Nesse momento é necessário contratar treinamento, chamar uma consultoria para parear com os desenvolvedores, mudar o mind-set da equipe para orientá-la a testes, aprender novas tecnologias, trocar membros da equipe e etc… No entanto, o problema MAIOR é que temos 5 iterações já implementadas sem testes que se tornaram um péssimo legado. Tudo terá que ser revisado e muitas coisas reescritas na sexta iteração (e isso vai fazer mal para a moral da equipe, acredite). Bem, com tudo isso ajustado, mudamos a definição de pronto para a sexta iteração (que na verdade será uma refatoração gigante):

Definição de Pronto 1.1:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de homologação

Creio que o Product Owner e o bolso dele não ficaram muito feliz com esse fato. Houve uma ruptura na Value Chain (corrente de valor) e com isso, um sentimento de falha do próprio Scrum. Porém, com a definição ajustada as entregas das próximas iterações possuem uma qualidade e confiança muito maior. Não estamos mais perdendo tempo com testes que podem ser automatizados. Os processos de integração contínua estão mostrando falhas o mais rápido possível e o design está simplificado. Durante as iterações 6, 7 e 8 a definição de pronto 1.1 mostrou ser a ideal.

Até que no início da 9a. iteração (de umas 20 previstas) o Product Owner diz que quer colocar o produto no mercado em produção. Ele quer faturar com a solução, antecipando o ROI, afinal, é isso que o Scrum promete. Isso significa que após a décima iteração a equipe terá que lidar com mais práticas SCM, e não só isso, manuais de sistema devem ser elaborados para o pessoal de suporte, assim como manuais de usuário, help on-line, materiais de treinamento e etc…

Mais uma vez, vimos que a definição de pronto não foi suficiente para atender ao conceito de funcionalidade potencialmente implantável. Mais uma vez a equipe deverá parar totalmente para melhorar seu deployment, escrever manuais, fazer transições e etc… Mais uma vez a iteração 9 será um grande refactoring para atender a nova definição de pronto:

Definição de Pronto 1.2:
- Implementado com boas práticas de engenharia (ex. testes automatizados)
- Implantado no ambiente de produção
- “One-click deployable”
- Com documentação técnica e do usuário

Há uma grande correlação entre o conceito do Value Stream do Lean e a Definição de Pronto do Scrum, e esse exemplo que coloquei aqui demonstrou claramente que o processo de desenvolvimento dessa equipe não é fluído: foram necessárias “fases” de estabilização para se ter valor, se aproximando de um estilo Waterfall. É interessante notar que um sistema Kanban pode deixar a corrente de valor mais visível que uma definição de pronto. Ter uma telinha do sistema que entra e funciona sem dar pau é uma parte bem pequena de um produto de software: não só isso irá gerar ROI. Aquilo que sai da equipe deve ser um incremento completo e não só aquilo que é importante, ou visível.

Muito se fala em equipe multi-disciplinar. É comum achar que um arquiteto, um desenvolvedor e um tester fazem um Carnaval, porém, a característica multi-disciplinar da equipe deve corrobar com aquilo que essa equipe pretende entregar. O backlog nos fala o que deve ser entregue e a definição de pronto, ortogonalmente, nos fala exatamente os critérios dessa entrega. Nesse aspecto, os itens do backlog não tem só relacão com funcionalidades, mas sim, com VALOR.

Como já havia citado aqui, design incremental é uma das práticas de engenharia que poucas equipes dominam. Poucas equipes sabem exatamente o que é um incremento. Um dos conceitos do Scrum que é bem pouco comentado e que costumo dar bastante enfoque no meu treinamento é exatamente a definição do pedaço de funcionalidade potencialmente implantável. O próprio Ken Schwaber disse no Gathering que somente 20% das equipes conseguem entregar algo potencialmente implantável ao final da iteração. Inclusive, essa é a motivação dele ter fundado a Scrum.org após sua saída da controversa Scrum Alliance.

Quando dizemos que estamos entregando algo potencialmente implantável isso nos leva a uma visão que poucas equipes Scrum tem: no andar das iterações é o cliente que decide a hora que ele quer ir para a produção, e seu software deve permitir isso. Tudo aquilo que você “incrementou” deve ser capaz de resolver algum problema de negócio sem depender de grandes investimentos em preparação de ambientes ou “Sprints de estabilização”. O que você incrementa além de atender a sua definição de PRONTO deve ser sólido, refatorável, bem arquitetado e durar para sempre. O software criado deve ser um ativo, que coloca dinheiro no bolso de alguém.

Quanto eu estou pareando com alguém ou trabalhando num incremento eu vejo algumas características na realização desse trabalho. Basicamente um incremento é:

- Documentado e especificado (usando BDD, TDD ou outros documentos)
- Analisado (parte do ciclo TDD, refactorings)
- Sólido (incremente com boas práticas OO)
- Coberto por testes (incrementos futuros não quebram o atual)
- Integrado Continuamente (há outros na equipe incrementando)
- Potencialmente Implantável (o cliente decide quando vai pro ar)

A prática dos Baby Steps

Um fato que é bastante interessante é a velocidade dos times ágeis: é um mito achar que times ágeis programam numa correria desatada e que agilistas trabalham num ritmo barulhento, frenético e alucinado. Muitas pessoas que tem contato com uma equipe ágil pela primeira vez pode até estranhar a calma, seriedade e tranquilidade que cerca esses times ágeis. Por incrível que isso possa aparecer, times realmente ágeis “aparentam” ser lentos. É comum ver eles mais pensando do que digitando. Porém, cada passo de bebê que eles dão são passos firmes, determinados, bem pensados e principalmente na direção correta. Numa equipe ágil a cada 2 ou 3 horas vários passos pequenos foram dados e cada incremento agrega valor para o projeto.

Chega ser ridículo quando vou conversar com certos empresários e eles dizem: “- Aqui já somos ágeis… é uma correria do cacete aqui!”

Mentalidade Cascateira do Programador

O maior motivador deste artigo é a minha experiência depois de ter ministrado algumas vezes o nosso novo treinamento Domain-Driven Design. Neste treinamento as atividades práticas são orientadas a testes, e tenho visto que alguns alunos penam para completar os exercícios mesmo quando nós já fornecemos os testes automatizados escritos.

Exemplo: Temos um caso de uso com 4 testes falhando para os alunos implementarem em uma hora. São 4 testes de integração, então, basta fazer cada teste passar em 15 minutos que a solucão está completa. Muitos não conseguem fazer isso, e a maior razão é não conhecer sobre Design Incremental. Eles olham aqueles testes falhando e entram em pânico. Saem cuspindo código sem rodar os testes querendo fazer todos eles passarem ao mesmo tempo. Nos últimos 5 minutos da atividade prática ainda está tudo RED e falham miseravelmente. Simplesmente não lhes parece natural fazer o primeiro teste passar, depois o segundo, depois o terceiro e assim sucessivamente. Eles não pensam em passos de bebê e nem em incrementos. Essa minha experiência é bastante relevante para a questão, e define a mentalidade cascateira:

O cascateiro é aquele desenvolvedor que espera que algo milagroso acontecerá nos últimos instantes do prazo, e tudo aquilo que não funciona passará a funcionar, seja por sorte ou intervenção divina.

Essa definição é essencialmente válida mesmo para quem diz que usa ciclos iterativos. Ciclos iterativos não necessariamente são Ágeis, pois se sua equipe ainda sofre para que tudo que foi implementado funcione ao final da iteração você ainda tem mentalidade cascateira, e precisa melhorar suas práticas de teste e integração contínua.

Você que é desenvolvedor pode fazer uma auto-avaliação prática. Acesse meu Github e baixe o projeto exemplo do treinamento Domain-Driven. Em seguida, acesse a classe CadastrarHospedeTest e tente fazer com que estes testes passem num prazo de uma hora. Pegue como exemplo a classe CadastrarQuartoTest. Depois, responda as perguntas:

1. Você conseguiu implementar em uma hora?
2. Quantas vezes aproximadamente você rodou os testes?
3. Você conseguiu fazer os testes passarem um por um?
4. De 0 a 10, como você avalia a confiabilidade do seu código?

Como eu sempre digo: Colar post-its na parede todo mundo quer, mas escrever testes automatizados ninguém quer.

O produto principal da SGIweb são produtos e soluções para Procurement e B2B integradas com ERP e vendidas como serviços entre mais de 65.000 empresas participantes. Para maiores informações, visite o site do WebSupply em www.websupply.com.br. Foi muito legal ministrar este treinamento, principalmente porque a SGIweb é uma empresa com mais de 20 anos de mercado e que está inovando seus processos nas práticas Agile com vigor.

Mais um ISV para o portfólio da Aspercom, que em 2009 consolidou sua posição como a principal empresa em treinamentos corporativos e consultoria em Scrum, Extreme Programming e práticas Agile no setor. Que venha 2010!

A Leosoft é uma empresa que já utiliza Extreme Programming há algum tempo, tendo sido treinada pelo renomado Vinicius Teles. Ambos os treinamentos foram customizados para focar em práticas que fortaleceram a visão de negócios dos produtos da empresa junto ao mercado, já que cliente presente é um grande desafio para os ISVs. De norte a sul do Brasil é muito interessante ver como empresas com times pequenos e auto-organizados conseguem excelentes resultados em seus produtos e empresas.

Atividades práticas em grupo, muito comuns em treinamentos da Aspercom

Um ambiente informativo compartilhado na vida real

Gostaria de parabenizar a todos da Leosoft pelos excelentes bate-papos e trocas de experiências. Muito sucesso em 2010!

Nessas férias aproveite o tempo para aprender mais sobre desenvolvimento de software com a Aspercom. Faça sua inscrição no treinamento Requisitos ou UML e ganhe grátis um mini-curso sobre Agile (17/dez).

Levantamento e Especificação de Requisitos
Estabeleça a Visão do sistema e Controle os Requisitos com sucesso
Noturno: Dias 1, 3, 8, 10 de dezembro (terças e quintas - calendário)
R$ 520,00 à vista com desconto ou 3x R$ 185,00 - Grátis: Mini-curso Agile

Orientação a Objetos com UML 2.0
Aprenda na prática sobre Casos de Uso, Design e Arquitetura de Software
Noturnos: Dias 7, 8, 9, 10, 14, 15, 16 de dezembro - (calendário)
R$ 890,00 à vista com desconto ou 4x R$ 230,00 - Grátis: Mini-curso Agile

Gerenciamento de Projetos com Scrum
Aprenda as práticas Agile que mais crescem aqui no Brasil
Sábado Integral: Dia 12 de dezembro - (calendário)
R$ 430,00 à vista com desconto ou 3x R$ 150,00

Descontos para 2 ou mais alunos.

Inscrições: contato@aspercom.com.br

LOCAL DOS TREINAMENTOS:
Domore - Av. Paulista, 807 - 18 andar
São Paulo - SP

Nesse artigo vou comentar sobre a polêmica que o José Papo criou primeiramente no seu Twitter. Não satisfeito postou também na Scrum-Brasil. Segue o link para a animada discussão “Scrum e PMBOK - determinadas incompatibilidades filosóficas”:

http://br.groups.yahoo.com/group/scrum-brasil/message/4810

A discussão estava indo como sempre vai: uns defendendo, outros criticando, até que passou pela questão “certificação”. Hoje existem muitos PMPs que também são CSM, e vejo que isso é bem natural - quem tem um mindset que busca certificações é esperado que colecione-as. O Luiz Aguiar postou algo interessante, falando que agilistas de verdade não ligam para certificações. Isso é interessante para esse artigo, pois, vou falar aqui que muitos que gerenciam projetos de verdade a lá PMBOK também não ligam…

No ano de 2008 eu decidí investir através da Aspercom numa parceria para fazer um produto: um software para gestão de projetos de engenharia focado em DPC (design-procurement-construction). O projeto envolvia a área de engenharia, compras, financeiro, gestão de projetos e canteiro de obras. Para os desenvolvedores de plantão nós usamos Java, Seam, JBpm, Domain-Driven Design, Scrum e XP.

A Aspercom tenta ao máximo seguir o Manifesto Ágil que diz: “We are uncovering better ways of developing software by doing it and helping others do it.” Me é estranho uma empresa que treina em Agile não se envolver em projetos. Por isso tivemos aqui a experiência do projeto DDWorks e do RailsRumble. Esse projeto de 2008 foi um outro exemplo com muito aprendizado.

Nosso cliente inicial neste projeto era uma grande empresa de engenharia especializada em fornos de siderurgia (aqueles fornos que custam milhões de dólares). O pouco de contato que tive com esses engenheiros stakeholders me mostrou uma visão completamente diferente do PMBOK que é tão mal aplicado na nossa área de TI. Só para começar, meu primeiro choque é que um projeto de um forno de siderúrgia é um investimento que pode chegar fácil a 100 milhões de dólares, então, não se trata desses nossos projetinhos de software que raramente ultrapassam 6 dígitos.

Só para passar a magnitude das coisas, um projeto de engenharia de um forno tem fases e muitas vezes ocorre um overlap. Não é um projeto em cascata. Basicamente o design é fazer desenhos, plantas e mapas, mas não só isso: o engenheiro deve fazer uma lista de material contendo tudo que é necessário para montar o forno. Esse trabalho pode envolver até uns 30 engenheiros num único projeto. Há desenhos topográficos, esquemáticos, detalhes e etc… O cliente também tem uma equipe de engenheiros própria que verificará a conformidade do projeto as suas instalações. Talvez essa parte do projeto seja algo parecido com desenvolvimento de software - é algo criativo e requer profundos conhecimentos técnicos. Quando expliquei o Scrum para o cliente ele até cogitou usá-lo para essa fase de engenharia. Mas as semelhanças param por aí…

Com as listas de materiais elaboradas e aprovadas o próximo passo é comprar (procurement). Para isso, é necessário negociar, importar, ter certificados de capacidade de fornecedores, pensar em logística, prazos e muito mais. Você vai precisar de algumas dezenas de compradores para gerenciar equipes de fornecedores, pensar em lead-times, lidar com importadoras, engolir as maracutaias no porto de Santos e mais uma dezena de coisas que pode dar errado: desde uma espessura de tubo inconforme de uma empresa de Jundiaí até motores falsificados que estão vindo da China. Associado a todo processo de compra existem métodos de inspeção para garantir que contratos sejam cumpridos nos rigores da qualidade exigida pelo projeto, que se mal feito pessoas podem até morrer.

Com o material chegando no canteiro de obras é necessário gerenciar almoxarifados e organizar equipes de montagem e de ensaios (testes). Nesse ponto crucial do projeto, além de lidar com possíveis problemas entre pessoas, falhas de planejamento e falta de materiais críticos (uma abracadeira de 15 dólares pode gerar um atraso de muitos dias e milhares de dólares) um gerente de projetos ainda tem lidar com problemas como a chuva e orgãos ambientais e governamentais.

Nesses últimos 3 parágrafos acho que escreví menos de 10% dos problemas que um projeto DPC (design-procurement-construction) tem. Ainda faltaria falar mais centenas de outros problemas como a taxa do dólar, o preço do aço no mercado internacional, a burocracia brasileira, o roubo de peças do almoxarifado, as falhas de comunicação e muitos outros. Estamos falando de um projeto de milhões de dólares que pode envolver 7 regiões do globo, mais de 80 empresas e seguramente mais de 1.000 pessoas (consegue imaginar uma daily metting?).

Eu sempre critiquei muito o PMBOK em muitas ocasiões, mas o problema era o mind-set. Eu digo aqui em alto e bom som que para um projeto de engenharia como esses a melhor ferramenta é o PMBOK sem sombra de dúvidas. Nesse tipo de projeto controle de terceiros, WBS, plano de comunicação, gerencia de riscos e muito do que não faz sentido para software faz todo sentido. O cara que gerencia tudo isso tem que ser bom e faz sentido ter uma pessoa como foco central no projeto. Nesse ambiente o mindset PMBOK faz sentido. O tempo que estive inserido nesse mundo um gerente de projetos muito bom em DPC chegava a ganhar mais de 20 mil reais fácil-fácil. Esses são os caras que estão gerenciando construção de oleodutos, plataformas de petróleo, linhas de produção contínuas de aço e muitos outros desafios emocionantes. Eu vejo a aplicabilidade do Scrum como nula neste tipo de projeto e quero cases que me provem o contrário.

Voltando ao assunto do Luiz Aguiar, o que achei bastante interessante é que gerentes de projeto muito bons em DPC não eram PMPs, não davam palestras por aí, não tinham certificações nas assinaturas de email, mas sabiam MUITO BEM o PMBOK, pois viviam suas práticas todos os dias. Eles gerenciavam milhões a bilhões de reais e tinham uma grande responsabilidade. Esse é um ambiente onde só se consegue gerenciar com muito conhecimento e acúmulo de experiência. Isso certificação nenhuma dá.

Eu concordo que o mindset da gestão em projetos de software é bem diferente dessa realidade e não dá para misturar as duas coisas.A gestão de projetos de software é simples. Muito mais simples. Simples ao ponto de se questionar a necessidade de um GP para equipes sêniores. O PMBOK, como conjunto de conhecimentos para gestão de projetos é um “super-set” grande demais para projetos de software, o que pode confundir muito, mas pode ser dimuído (ele sofre o mesmo que o RUP). Apesar de se tratar de mindsets diferentes é impossível negar que as práticas são semelhantes. No nosso treinamento Scrum eu simplesmente não consigo deixar de citar que há semelhanças e diferenças marcantes, mas as semelhanças estão lá. O Scrum roda dentro de um ciclo PDCA, é a equipe que estima, existe controle de escopo e prazo. Tudo está lá, mas um pouco diferente do PMBOK.

PMBOK serve para software? Digo para vocês que se eu estiver num projeto onde equipes apartadas ou fornecedores estão desenvolvendo partes completamente diferentes do projeto - como acontece num projeto de equipamentos que envolve construção de hardware e software específicos (um projeto incomum) - é bem provável que eu irá usar muitas práticas do PMBOK.

Eu concordo com o Uncle Bob quando ele fala que se você deixar programadores sozinhos lidando com os problemas do desenvolvimento e manutenção de software naturalmente eles vão começar a buscar práticas do Extreme Programming. Eu arrisco dizer aqui que bons (e espertos) gerentes de projeto PMBOK lidando com problemas de gestão no desenvolvimento de software também naturalmente se apegariam as práticas do Scrum.

O que não é admissível na minha opinião é poluir a gestão de um projeto usando inadvertidamente práticas PMBOK by the Book, o que infelizmente é comum no mind-set de gerentes de projeto megalomaníacos. Por isso muitas vezes a comunidade ágil tem asco do PMI. Como sempre, a culpa não é do PMBOK, mas do mindset poluído.

Você já gerenciou projetos multi-sites, multi-equipes, multi-fornecedores e multi-milionários? Não? Então pode voltar para o seu Scrum.

Existem muitas maneiras de você avaliar se um evento foi bom ou não. Você pode avaliar o programa, a organização, a presença de palestrantes internacionais e etc… Com essa maratona de 3 eventos em menos de 10 dias o que aprendí é que um bom evento é feito por pessoas. Não só pessoas importantes, mas simplesmente pessoas. Pessoas sedentas em aprender também fazem um bom evento.

O relato que farei aqui dos eventos é uma visão bem pessoal. Não vou avaliar muito as palestras e nem ser tão crítico, pois sei que muitas outras pessoas vão escrever excelentes restrospectivas, falando sobre cada palestra.

Ágiles 2009 em Florianópolis

O Ágiles foi de longe o melhor evento de Agile que já fui. O programa estava excelente, tinha muita gente interessante e a atmosfera estava muito legal. O que achei legal no Ágiles é que tinha muita gente nova que simplesmente foi ao evento para aprender Agile, e fiquei muito satisfeito de ter ajudado muitas pessoas com alguns coachings gratuitos em muitos assuntos, desde coisas mais técnicas como especificações executáveis até outros assuntos como liderança e etc…

O Brian Marick, um dos autores do Manifesto, abriu o evento com uma palestra bastante informativa. Fez algumas metáforas sobre desenvolvimento de software com o trabalho de veterinária de sua esposa, mostrando que a experiência e a prática faz a diferença. O ponto alto foi o momento em que falou que é a equipe que gerencia o ScrumMaster e não o contrário. O Brian fala bastante sobre o “líder servidor”. O Brian é bastante simpático e ficou à disposição o evento todo para parear com todo mundo. Os pairings que rolaram foram uma das coisas que tornaram o Ágiles especial. Tinha até o que chamei de “pairing lobby”.

O pairing lobby foi a idéia de alguém com muita visão. Na entrada do evento tinha mesas, cadeiras, story cards e flipcharts que qualquer pessoa poderia usar. Ao menos umas 6 pessoas vieram me perguntar alguma coisa e a resposta era um pairing de 20-30 minutos. Muito legal! Nunca tinha visto isso num evento Agile e fica a dica para quem for organizar os próximos…

Fui muito feliz na minha escolha da palestra. O evento tinha uma trilha básica sobre Agile para quem estava aprendendo e apresentei parte do curso Scrum da Aspecom com o título “Entendendo User Stories”. Tinha mais de 60 pessoas presentes, mas mesmo assim, consegui formar uns 10 grupos e botei os aprendizes para trabalhar. O resultado final foi muito legal e as pessoas adoraram o hands-on prático.

Grupos formados, palestra bombando!

Stories não são especificações!

O Alisson Vale deu uma excelente introdução ao Lean e Kanban na sua apresentação. Já conhecia o Alisson, mas nesse evento tive a oportunidade de trocar mais figurinhas com ele nos almoços e breaks. O Clavius Tales da Fortes também nos acompanhou de perto. O Alisson já começou sua apresentação falando das limitações que existem nas implementações Scrum e apresentou as importantes ferramentas e conceitos de um sistema Kanban para implementar um fluxo contínuo de entrega de software, limitando o Work in Progress e diminuindo a variabilidade do processo. Eu confesso que não fui um estudioso muito aplicado em Lean, mas já cheguei a conclusão que desenvolvimento iterativo é uma limitação do meu processo e não algo 100% desejável. O Alisson abriu muitos horizontes inexplorados nos nossos bate-papos sobre a Phidelis, a empresa do Alisson que já está com maturidade em fluxos contínuos de entregas usando um sistema Kanban muito inteligente. Acompanhe o blog do Alisson e saiba mais sobre Lean em Software: http://www.alissonvale.com/englishblog/

No início da noite teve o polêmico keynote do Roy Singham, CEO da ThoughtWorks. Na sua palestra houve uma mistura de política, sociologia e críticas ao nosso mercado de TI. Roy reafirmou a missão da TW que é “revolucionar a TI” e para isso, defende o uso de Agile e também de iniciativas Open Source. Foi um discurso direcionado ao nosso mercado brasileiro. Criticou quem só está buscando as práticas de gerenciamento do Scrum sem buscar as práticas de engenharia do XP. Disse não concordar muito com certificações, algo que gerou um burburinho no evento e uma avalanche no Twitter. Entre outras coisas, Roy anunciou a abertura do escritório da ThoughtWorks aqui no Brasil. Iniciamente será em Porto Alegre e mais direcionado para desenvolvimento offshore. O keynote do Roy foi empolgante, ele tem o dom da oratória e demonstrou as caracteristicas de um líder que são muito raras.

Eu tive a oportunidade de conversar bastante com o pessoal da TW (Carlos Vilella, Frank Trindade, Sidney Pinney e outros), inclusive fiz muita amizade com o Roy. Conversamos bastante sobre TI, política, liderança e outras coisas. Aprendí muita coisa com ele.

Jantar com o pessoal da TW com Roy Singham, Brian Marick e outros agilistas locais.

Infelizmente no segundo dia perdi algumas palestras importantes, como a da Diana Larsen e do Joshua Kerievsky. Infelizmente como empresário tive que pegar uma mesa no pairing lobby só para enviar emails e propostas (#fail). A palestra do David Hussman foi muito interessante sobre Coaching e pude conversar com David e Joshua numa troca de idéias muito legal sobre ensino e treinamento presencial e online.

Antes de mais nada eu quero parabenizar a todos pela excelente organização do evento e principalmente pela grade diferenciada. Fiquei muito contente que o Ágiles teve um foco muito maior nas práticas de engenharia do que nas práticas de gestão. O Extreme Programming foi a grande estrela e o Scrum foi deixado meio de lado (pelo menos foi o sentimento que eu tive). Não tenho a confirmação, mas é bem provável que o Ágiles 2010 será em outro país, creio que no Peru. Definitivamente é um evento que você não pode perder.

A cobertura fotográfica do evento mais uma vez ficou por conta do Manoel Pimentel. Acesse o seu Beonthe.net no link abaixo:

http://www.manoelpimentel.com/fotos_eventos/72157622450201053/1

As retrospectivas do Encontro Ágil e Rails Summit vou postar aqui em alguns dias. Stay tunned.

Workshop Gerenciamento de Projetos com Scrum
Aprenda sobre a metodologia que mais cresce aqui no Brasil
Dia 23/10 - sexta - das 8:30 às 18:30
à vista com desconto R$ 390,00 ou 2x R$ 205,00

Treinamento Domain-Driven Design em Java
A arquitetura OO focada em solucionar os problemas dos usuários
Dia 24/10 - sábado - das 8:30 às 18:30
à vista com desconto R$ 320,00 ou 2x R$ 170,00

PROMOÇÃO Scrum + DDD: R$ 620,00 ou 4x R$ 160,00

INSCRIÇÕES / INFORMAÇÕES: contato@aspercom.com.br

1. The Scrum user Worms:

Roy’s speech was (correctly) criticizing a lot people that look for Agile project management practices from Scrum and don’t use the engineering practices from XP. No big deal on this, lots of influent people say the same. I twitted this:

Roy Singham from ThoughtWorks “Worms are those who do Scrum and don’t do XP. #outstanding http://bit.ly/curso_xp - inscreva-se.

http://twitter.com/rodrigoy/status/4717474432 (note that I’m marketing my XP course on this)

The fact is that Roy was joking on that slide, just like me. Unfortunately non-portuguese speakers don’t get it. That was just a joke, no offense to plain Scrum users (but you should really study and apply XP).

2. The Scrum Certification polemic

@rodrigoy: Roy Singham said this loud: “ThoughtWorks SAY NO TO Scrum Master Certification” (I know you CSM won’t RT this) #Ágiles2009

http://twitter.com/rodrigoy/status/4717561417

On this post 2 significant things happened: 1st - Roy was talking about CSD; In fact I misunderstood and also typed it wrong, just take that “Master” out of the twitt and it will be more accurate to what Roy was saying. Joshua corrected my mistake anyway.

The other significant thing is that Ola Bini (ThoughtWorker and very influent/famous programmer) RT my post. That was a surprise for me (he doesn’t follow me). How would I know that? Ola just boosted my twitt all over and other influent people here in Brazil and worldwide also retwiited. That typing mistake spread like a plague over Twitter. My fault. Sorry.

I just blog this to put things straight. It really wasn’t my intention all this noise worldwide. Roy and I became friends on this event, so I don’t want to put inaccurate words on his mouth that hurts your feelings. Roy’s positions on many subjects are tough just like me.

You feel free to twitt this blog post. This is the short link: http://bit.ly/rodrigoy_singham_csm

Quando eu estava no começo da minha carreira, no início dos anos 90, por incrível que possa parecer os métodos eram ágeis. O cliente e os reais usuários eram muito próximos e participavam ativamente do projeto. O ciclo, apesar de não ter formalidades iterativas, era focado em entregas frequentes. Apesar das arquiteturas fracas, a qualidade era boa e a satisfação dos usuários era maior. Trabalhei com Clipper, Visual Basic 3-6, Mumps e outras coisas da época - além de administrar redes Novell 3.12 e Lantastic. Os projetos eram divertidos, focados em resultados e na maioria das vezes o financiador ficava no seu pé. Eu me lembro do Tonhão, o gerente financeiro da Rede America Burger & Pasta, meu primeiro (e único) emprego como programador CLT. O Tonhão todas as sextas batia na minha mesa no CPD e perguntava: “-E aí Japa, tá pronto?”. Todas as sextas, religiosamente às 15:00 o Tonhão cobrava sobre aquele sistema de controle de caixa das lojas que acabou com os disquetes e com muita burocracia, pois usava comunicação via modem.

Nos meados de 1996 recebí uma ligação de um amigo meu do colégio técnico dizendo que as consultorias estavam pagando R$ 22,00 a hora para projetos do Bug do Milênio em COBOL. Bem, para a época esse valor era bastante significativo, topei na hora e lá fui eu ter a experiência de uma empresa grande. Se existe uma coisa que você pode responsabilizar sobre a bagunça que existe no mercado de TI hoje essa coisa é O BUG DO MILÊNIO. Eu estranhei muito trabalhar em consultorias nessa época. Os projetos chegavam e nem tinha uma única reunião com o cliente. Na maioria das vezes tinha um gerente-proxy entre a equipe e os clientes. Os projetos Y2K eram ainda mais peculiares. Teve projetos que o trabalho era passar uma ferramenta de detecção de problemas Y2K, ir até o código indicado pela ferramenta e fazer as alterações, mas sem recompilar e sem qualquer teste. Eu me sentia um digitador. Levei até uma bronca de um coordenador por tentar compilar o projeto para ver se nossas alterações ao menos geravam os binários. Meu coordenador gritou que aquilo não era escopo do projeto. Nesse momento eu ví que qualidade não era uma preocupação central das consultorias.

Passada a fase Y2K, começaram os projetos Internet e de sistemas periféricos de grandes implementações ERP. O problema é que o desenvolvimento de software empírico (que eu apliquei nos meus estágios e lá na Rede America) não atendia às necessidades de projetos outsourcing. Gerentes queriam controles, relatórios e Gantt Charts. A preocupação maior era a mesma dos projetos Y2K - O ESCOPO. Se você estivesse numa consultoria no final dos anos 90, você compreenderia perfeitamente o mindset do SEI com o seu CMM. Os gerentes de consultorias buscavam algo que amarrasse a equipe ao contrato com o cliente. Meio por fora de tudo isso comecei a estudar Orientação a Objetos, OMT, Booch, e mais pra frente, a UML e o RUP. Minha primeira experiência prática com o RUP foi num projeto internacional para a Phillips Medical Systems em 1999.

Esse projeto da Phillips era um sistema orçamentário empresarial que integrava vários departamentos, inclusive a matriz em Rotterdam. Foi desenvolvido em Visual Basic, Orientado a Objetos e banco de dados Oracle. Quando olhei o RUP pela primeira vez gostei de Casos de Uso, Iteratividade e o foco Arquitetural. Neste projeto a equipe variou entre 3 a 5 pessoas. No início estabelecemos uma Visão para definir o problema junto aos usuários, o ciclo iterativo era de 30 dias e tinha perto de 15 casos de uso (que escrevemos de maneira correta). Usamos o famigerado Visual SourceSafe (o supra-sumo da época) e somente uns 6 ou 7 diagramas UML foram mantidos como artefatos (além do MER). O foco sempre era entregar o produto e não preencher artefatos. A gente até tinha alguns testes automatizados, mas a maioria dos testes era manual. Entregamos o projeto após 3 ou 4 iterações e foi um sucesso! A satisfação dos usuários foi além das expectativas. A partir desse projeto, o modo que eu instancio o RUP é assim: Iterativo, Orientado ao Usuário (Casos de Uso) e centrado em Arquitetura.

Quando voltei desse projeto para a consultoria um dos meus gerentes queria saber como foi o processo. Eu comecei a falar que o cliente participou bastante e que as entregas a cada 30 dias foram determinantes para diminuir os riscos. E a pergunta que se seguiu traduz bastante o mindset de um gerente (da época ou de hoje): “- Legal, legal, Rodrigo, mas quais eram os documentos que vocês preenchiam?”. Aí eu falei que usamos a Visão, os Casos de Uso, a UML, o MER… logo em seguida veio a pergunta número 2: “- Você poderia me dar um exemplo de cada um para usar no projeto XPTO?”. Hoje eu vejo que ele estava buscando respostas fáceis. Na época eu poderia ter dado minha cópia do livro sobre Unified Process dos Três Amigos, porém, o que eu fiz foi copiar um disquete com os artefatos. Ainda hoje ainda me culpo por ter feito aquilo, mas eu era ainda um profissional inexperiente, com pouco mais de 5 anos de estrada. Colaborei para a ilusão daquele gerente por respostas fáceis. Me desculpe se você era um dos desenvolvedores do projeto XPTO na virada do ano 2000. Me desculpe se um dia, um gerente chegou para você entregando um disquete dizendo: “- Olha, o preenchimento desses artefatos garantirão o sucesso do projeto.”

Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário - implementar - entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.

No ano de 2003 eu ví a primeira palestra de um “especialista” falando absurdos sobre o RUP, no melhor estilo Waterfall. Ele disse coisas do tipo “Levantar todos os requisitos na concepção”, “Modelar tudo na fase de elaboração”, e principalmente, o cara pregava descaradamente a errônea sequência Casos de Uso - UML - Codificação - Testes, e uma irracional separação de papéis que está em uso até hoje. Ele teve até tempo de mostrar como preenchia alguns artefatos. Nesse tempo eu não era tão crítico como hoje, e nem mesmo para os meus amigos que assistiram a palestra eu alertei contra as falácias daquele fanfarrão.

A cada dia que se passou desde então, ví mais e mais pessoas falando absurdos do RUP. Quando se diz RUP atualmente no mercado muitos torcem o nariz, associam com cascata, associam com artefatos, associam com ferramentas Rational, e principalmente, associam com esse pensamento burocrático da virada do milênio. Muitos dos que criticam são agilistas famosos, mas que não tem mais de 10 anos de experiência. Eu queria que a maioria desses consultores e especialistas Agile estivessem lá nos anos 90, reclamando da implementação OO nos produtos base da Microsoft, tentando entender Objective-C e vendo uma esperança OO mais simples no Delphi como alternativa. A gente acreditava que a Orientação a Objetos resolveria todos os nossos problemas, mas 15 anos depois ainda temos modelos anêmicos e pessoas sem a mínima noção do que são dependências ou mensagens querendo discutir OO em fóruns colocando sua pilha de certificações na sua assinatura de e-mail.

Em 2003-2004 eu tive o primeiro contato com o Extreme Programming num projeto J2EE para um grande Call Center Vendas, um projeto único no mundo, clusterizado, distribuído, Swing e mensageria. Sobre o XP, quer saber? Não ví quase nada de novo. Agora Casos de Uso são User Stories menores, o ciclo iterativo é mais curto, o desenvolvimento é orientado a testes (isso sim achei uma boa idéia, apesar de não compreender bem nos primeiros projetos) e a programação é em par (isso também geralmente não é uma azeitona fácil de engolir logo de primeira). Eu particularmente tenho dificuldade em parear com algumas pessoas devido ao meu déficit de atenção. Eu olhei para o XP e no primeiro momento ví que muito do que diziam do XP era algo parecido com o que a gente fazia nos anos 90, principalmente a parte do cliente presente. Todos os meus clientes no início dos anos 90 eram presentes. Comparado com a visão do desenvolvimento de software das consultorias o XP era o cúmulo da controvérsia. Já na mentalidade de um desenvolvedor de software dos anos 90, o XP faz todo sentido do mundo. Meu primeiro contato com o Scrum foi em 2005. E mais uma vez tive aquele sentimento: Sim, é bem diferente das práticas erradas do mercado, porém, não é muito diferente do RUP. Ele diz mais sobre ROI e sobre um importante Product Owner, mas também me lembro do Tonhão como um Product Owner nato nos anos 90. Em 2005 o Scrum era o cúmulo do descontrole de custos do projeto, por conta do seu escopo aberto e por conta do mindset PMBOK, mas para um desenvolvedor dos anos 90, simplesmente é o retorno aquilo que a gente já fazia: nos anos 90 não tinha pressão para se entregar tudo, mas havia pressão para resolver os problemas de negócio do cliente. E eu me lembro do Tonhão todas as sextas me cobrando aquilo que estava pronto, doido para colocar a aplicacão no ar só para ter certeza que ninguém na rede estava roubando ele.

A grande questão sobre o Agile Movement é sua mudança cultural. Infelizmente são poucas as pessoas que se divertiram fazendo software nos anos 90 - se você costuma tratar os desenvolvedores como crianças, lentamente eles se convencem que são crianças. O manifesto é um grito contra as coisas erradas do mercado. É uma emancipação dos desenvolvedores que não querem ser crianças. É uma injeção pragmática contra o pensamento pseudo-tradicionalista, controlador e traumatizado que existe hoje no mundo empresarial, especialmente na indústria do desenvolvimento de software.

O que vocês devem estar se perguntando é: O que matou o RUP e pode matar o Agile? Como eu falei, eu temo pelo movimento Agile. Assim como foi em 2003, em 2009 eu ví o primeiro pseudo-especialista Agile falando absurdos - violando valores. A partir do momento que eu vejo a comunidade Agile discutindo e dando importância demais a post-its, quadro de tarefas e cartinhas de planning poker, eu temo pelo movimento Agile. Quando eu vejo a comunidade Agile buscando certificações, preocupados em como casar Agile com CMMI ou como adaptar Agile à contratos de escopo fechado, eu temo pelo movimento Agile. Sempre que eu vejo isso no mundo Agile, me transporto a 10 anos atrás e me lembro das discussões sobre templates de casos de uso, definições de padrões de modelagem UML, pensamento linear, check-lists de artefatos, uso incorreto de ferramentas, falta de compreensão sobre fases e o pior de todos: o departamento que cuida dos processos de desenvolvimento. Resumindo, quando vejo esse mindset de besteirols e libertinagens Agile, eu me lembro do mindset burro e burocrático que contaminou o RUP.

O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha.

Mais sobre o assunto “queda do Agile”:

Agile está morto! D-us salve o Agile! - José Papo
The Decline and Fall of Agile - James Shore
Por que dizemos não à certificação de Scrum Master - Vinicius Teles
A Completa Irrelevância do Certified Scrum Master - Philip Calçado
Flaccid Scrum - Martin Fowler

Esse artigo e a palestra que ministro com mesmo título é inspirado em “What Killed Smalltalk Could Kill Ruby, Too”, Keynote do Robert Martin (ou Uncle Bob) na RailsConf ‘09. Uma das melhores palestras que já ví. Veja abaixo: