Débito Técnico

Uma discussão surgiu na lista Scrum-Brasil… Muitas pessoas postaram coisas boas, mas em linha geral, achei que alguns conceitos estavam errados (e me preocuparam bastante). A discussão está aqui:

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.

É bastante comum as pessoas reclamarem que a empresa que trabalha não é ágil. Da mesma forma é bastante comum culparem os gerentes, coordenadores, diretores, o cara que cuida dos processos e etc… Algumas pessoas lutam com muito afinco por mudanças e as vezes conseguem adotar uma ou outra prática do Scrum ou até contratam um treinamento. A questão é que na maioria das vezes o que vai impedir o sucesso da adoção Agile na empresa não é o seu gerente, nem seus gerentes de projeto e nem o cara que cuida dos processos: o que impede a adoção Agile na maioria das equipes que tenho contato é a falta de conhecimento de boas práticas de engenharia.

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.

Quem ler esse título vai achar que eu enlouquecí depois do “O que matou o RUP pode matar o Agile“, mas o objetivo desse post é mais uma vez falar sobre mindset. Eu vejo que a grande dificuldade em entender práticas e metodologias vem de conflitos de mindset. Vou escrever mais sobre isso aqui no blog, pois vejo que combater prática contra prática ou metodologia contra metodologia é muito pouco produtivo. Os mindsets explicam tudo, apesar de ser bastante empírico escrever sobre isso. É dificil escrever sobre mind-set de maneira prática e útil sem descambar para um blá-blá-blá poético e filosófico.

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…
Leia o restante deste artigo »

Desde algumas polêmicas que ocorreram no Scrum Gathering neste ano, tenho discutido em diversos fóruns de discussões e eventos sobre o que tem ocorrido com a nossa comunidade de desenvolvimento ágil. Eu temo pelo o que pode ocorrer com o Agile aqui no Brasil. O que matou o RUP pode também matar o Agile.

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:

A Aspercom e a ThoughtWorks convidam você para o Encontro Agile/Mingle User Group Meeting. Este será um evento gratuito em São Paulo com mini-palestras, discussões e muito bate-papo.

Data: 30 de junho de 2009 às 19:00hs

Facilitadores:
Paulo Caroli (Agile Coach, ThoughtWorks)
Adam Monago (Gerente de Produto - Mingle, ThoughtWorks)
Rodrigo Yoshima (Instrutor Agile, Aspercom)
José Paulo Papo (Especialista Agile)

Agenda:
19:00 Auto-organização e Gestão por Metas Flexíveis (Yoshima, Papo)
19:45 Painel: Quais são seus problemas de gerenciamento de projetos?
20:15 Coffe & Bate-papos
20:50 Mingle User Group Metting (Adam Monago)
(happy hour após o evento!)

Mingle User Group Meeting - São Paulo

O encontro do Mingle User Group (MUG) do Brasil é uma oportunidade para conhecer, discutir e compartilhar experiências com o Mingle. Adam Monago, um especialista no produto juntamente com outros Agilistas experientes, demonstrarão o Mingle provendo dicas e truques em como usar o produto para gerenciamento de projetos e colaboração.

ATENÇÃO NOVO LOCAL:
Mercure Hotel São Paulo Paulista
Rua São Carlos do Pinhal, 87 - Bela Vista - MAPA
(Metrô Brigadeiro)

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

Num desses meus vôos, passei numa livraria no aeroporto de Guarulhos e comprei o livro “Uma Breve História do Mundo” de Geoffrey Blainey. O livro é excelente e praticamente li tudo no vôo de algumas horas. Este livro conta a história da humanidade de uma maneira muito agradável, pois o autor tem uma excelente capacidade de resumir e contar somente os fatos mais interessantes.

Nesses momentos aonde nós da comunidade de desenvolvimento de software estamos discutindo sobre auto-organização, Scrum, Agile e outras coisas, a leitura de Blainey vem bem a calhar. Por incrível que pareça, não faz sentido as pessoas acharem que auto-organização é algo extraordinário! Para já adiantar o assunto, auto-organização é algo que a humanidade pratica a milhares de anos e de alguma forma isso se perdeu nos últimos 100 anos.

No período Paleolítico, tempo da história que durou aproximadamente 2 milhões de anos, o homem se desenvolveu vivendo em grupos pequenos de até 20 pessoas. Eram tribos nômades que saíram da Africa e se deslocavam atrás daquilo que a natureza lhes oferecia (frutas, raízes, pesca, caça e etc…). É fácil imaginar como esses grupos se auto-organizava, apesar de ter uma liderança dos mais experientes (provavelmente nas atividades de caça). Nesse período frio da história a maior responsabilidade de um ser humano era sobreviver, e era uma questão de sobrevivência desenvolver a fala. O fato do ser humano necessitar de formas de comunicação explica um pouco sobre esse modo de vida.

Nesse período havia um grande isolamento. Não houve por exemplo um agrupamento de 50 humanos num mesmo lugar, pois um grupo grande não conseguiriria subsistir dos recursos locais por um tempo maior que algumas semanas. Os grupos moravam em cavernas e temiam a noite, assim como grandes animais.

Pinturas ruprestes: uma forma de “modelagem” comunicativa

Ainda na pré-história, lentamente, num período de 10 mil anos conhecido como a “Passagem”, a Terra se aqueceu, muitas geleiras derreteram aumentando o nível dos oceanos e o mapa-mundi ficou da maneira como o conhecemos hoje. A Terra começou a ter mais lugares habitáveis, teve um significativo aumento da população mundial, gradativamente o homem começou a desenvolver a agricultura e passou de nômade à sedentário. Esse período foi chamado Mesolítico caracterizado principalmente pelo domínio do fogo.

Continuando a história, com um homem sedentário e menos dependente dos humores da natureza, surgiram tribos e clãs maiores. O homem construiu casas que formavam as primeiras aldeias, mas mesmo assim havia um profundo senso cooperativo. Havia quem plantava, havia quem caçava e até a criação/domesticação de pequenos animais se desenvolveu. Como o estabelecimento do homem em locais fixos, temos o Período Neolítico. Ainda nesse período, não há qualquer razão para acreditarmos em qualquer estrutura rígida de controle: não havia relações de emprego e a formação social era simples e auto-organizada.

Com o domínio da fundição e outros avanços tecnológicos como a irrigação e o uso de ferramentas, já na Idade dos Metais (final da Pré-História), o homem organizou as primeiras cidades-estado e reinos onde havia comércio à base de trocas. Surgiram a navegação e as guerras. Mesmo assim, o dia-a-dia das pessoas era plantar e fazer alguns artesanatos (ferramentas, roupas, cerâmicas) em constante auto-organização geralmente em pequenas estruturas familiares. Nesse período com guerras e conquistas, surgiram talvez dois grupos não “auto-organizados”: os exércitos e os escravos. Exércitos logicamente não são auto-organizados na sua essência, pois não há sentido em ter uma reunião diária para decidir em grupo “quem vai morrer hoje”. Geralmente um general ou capitão toma essa decisão por você.

Só até este ponto, cobrimos grande parte da história humana, e vemos que a dinâmica interna do trabalho produtivo (fora os militares e escravos), em linhas gerais, era o homem obedecendo a natureza sobre os momentos certos de plantar, regar e colher. Não havia “chefes” mandando aquilo que os trabalhadores deveriam fazer no seu “dia-a-dia” (não estou entrando no mérito dos abusos dos Modos de Produção). Esse período que compreende desde o Neolítico (aprox. 10.000 a.C) até a Revolução Industrial (entre os séculos XVII e XIX) o trabalho consistia basicamente em plantar, criar animais e obter meios de se proteger do frio sempre em estruturas artesanais familiares. O trabalho de lavrar ainda era responsabilidade dos lavradores e eles dominavam essa arte. Não tinha gerentes de projeto ou algo similar. Não tinha ninguém dizendo como e qual ordem as coisas deveriam acontecer. Se você vier em qualquer sítio familiar aqui em Vinhedo, de onde escrevo (bebendo um excelente vinho de garagem da produção local), você ainda vai encontrar uma estrutura descentralizada e cooperativa que ainda perdura mesmo no século XXI.

Nos primórdios da Revolução Industrial muito mudou na maneira como olhamos para o capital e para o trabalho, e sem comentar as mudanças econômicas e políticas. Resumidamente a Revolução Industrial é sinônimo de automação. Com a crescente automação da agricultura e outros avanços tecnológicos, os rigores do campo se tornaram mais amenos. As pessoas sairam das fazendas e se instalaram nas cidades. Passaram a trabalhar não só plantando, mas viveram também da manufatura nas oficinas artesanais de roupas, utensílios e máquinas - um renascimento urbano - tendência que já vinha se desenvolvendo desde a Idade Média. Mesmo com essas mudanças, guerras e variações no clima que abalam a agricultura ainda podiam fazer centenas de milhares morrerem de fome.

Trabalho infantil ainda era muito presente no séc. XX

As mudanças deste século foram muito aceleradas. Tivemos o impulso de duas Grandes Guerras. Pessoas como Taylor, Fayol e Ford acrescentaram muito ao pensamento industrial e econômico. Chegamos ao Mundo Global e à era da Informação.

Apesar de ter feito isso, o objetivo deste artigo não era só contar história, mas lendo o livro do Blainey, escrever me pareceu irresistível. O objetivo aqui é dizer que realmente não há desculpa plausível para não ter auto-organização entre os profissionais do conhecimento e de alta tecnologia que são os desenvolvedores de software. A auto-organização é algo que faz parte da existência humana nesses milhares de anos de existência. É algo natural para um ser inteligente e racional. A falta de conhecimento, o medo, as limitações na comunicação e as barreiras culturais nunca foram motivos para não existir auto-organização na história. Um homem do Período Paleolítico, vestindo capas de peles, fugindo do frio, temendo grandes animais e sem sequer dominar o fogo sabia se auto-organizar. É simplesmente inconcebível que um programador, lendo este blog num MacBook, esperando um vôo num aeroporto internacional e falando ao seu iPhone, precise de alguém para organizar o seu trabalho juntamente com a sua equipe de desenvolvimento.

Pense nisso, Homo sapiens…

Terminou hoje aqui em São Paulo o maior evento sobre Scrum do mundo. Muitas histórias para contar e muitas fotos para postar. Estavam presentes aproximadamente 240 pessoas entre programadores, gerentes de TI, ScrumMasters e PMPs. As instalações do Hyatt são as melhores da cidade e a organização do evento foi muito boa. Vamos às palestras:

Project Management as a Strategic Competency - Ricardo Vargas, PMI

O Ricardo fez uma palestra bem política, e mostrou algumas coisas que gostaria que muitos PMP’s que tive contato vissem. De qualquer forma, a apresentação foi um pouco comercial do PMI, que defende a visão “Planejamento é crucial e conduz ao resultado. Esse resultado não foi por sorte e sim por ter processos”.

Uma coisa interessante é que todo mundo está fugindo do termo metodologia e processo, preferindo as palavras framework e ferramenta. Engraçado! Nada é metodologia! Nem o PMBOK! Nem o Scrum! Ele disse que PMBOK é um guarda chuva, e que odiava as pessoas “by the book”.

Ricardo Vargas, manda soltar e manda prender no PMI.

Ele afirmou: “Uso o PMBOK como uma referência. E não existe gerenciar segundo o PMBOK.”

Apesar da palestra ser criticada por alguns, eu gostei, mas pelo fato dele não conhecer profundamente o Scrum, cometeu alguns pequenos deslizes, como responder ao Juan que achava auto-gestão ótimo, mas não acreditava muito, pois não tinha tido sucesso ainda com isso.

Eu gostei porque tem muito PMPzinho que gerencia projetinhos de R$ 250 mil e se acham o super-hiper-gerente-de-projeto, porém, quando você gerencia projetos de R$ 250 milhões ou R$ 2,5 bilhões a coisa muda de figura. Você precisa de alguém bom para gerenciar.

A palestra foi boa, mas a discussão é: será que era para ela estar num evento de Scrum? Eu não ví problema nisso, e até achei acertada a estratégia, pois muitos PMPs se sentiram em casa.

Eu e o Juan Bernabo. Foto: Manoel Pimentel

Leia o restante deste artigo »

Quando publiquei o artigo Product Owner: um desgraçado ganancioso a minha intenção foi quebrar uma visão errada que o mercado tem a respeito de Scrum e Agile em geral. Muitas pessoas que converso em clientes, eventos e listas de discussão tem uma visão muito romântica a respeito do Scrum. Muitas delas entraram em choque ao ler esse artigo que diz que o Product Owner é um cara que só pensa em dinheiro.

As pessoas tendem a achar que tudo no Scrum é romântico, não tem nada te pressionando, a colaboração é linda, o Product Owner é paciente, as coisas fluem naturalmente, o ScrumMaster é um líder terno e querido, é só colar post-its no quadro, entregar iterações, entrar em débito técnico, comer pipoca nos plannings e viver feliz para sempre.

Infelizmente o Scrum não é assim. Nós precisamos entregar o projeto! Eu sei que muitos CSMs, CSPs e CSTs podem não concordar com o que vou dizer agora, e vou deixar bem claro aqui: a Reunião Diária do Scrum é o melhor mecanismo de cobrança que existe.

Quando tive os primeiros contatos com Scrum em 2005 (e antes disso eu aplicava as práticas iterativas de gerenciamento de projetos do RUP), eu estava trabalhando num projeto internacional que seria implantado em mais de mil hospitais no Japão*. O primeiro projeto de nove dígitos a gente nunca esquece. O projeto estava indo bem com as práticas do RUP, porém, sabe como é uma criança com um brinquedo novo? Eu estava doido para aplicar o Scrum e a transição foi bem tranquila (a equipe era sênior). Nessa virada, tomei uma das decisões mais sábias da minha carreira: eu deleguei o papel de ScrumMaster para outra pessoa. Eu atuei como um membro da equipe.

Tomei essa decisão de não ser ScrumMaster porque vejo que muitas práticas que descem da gestão na maioria das vezes não fazem sentido para as equipes. Eu quis provar o Scrum sob todos os aspectos. Atuar como membro da equipe antes de atuar como ScrumMaster foi uma experiência valiosa. Um ScrumMaster jamais será um bom ScrumMaster se ele nunca atuou como membro da equipe num projeto Scrum.

Nos primeiros dias eu ví que as reuniões diárias mostravam uma coisa claramente: me faltava FOCO na execução das tarefas. Eu era arquiteto, e muitas vezes não cumpria as tarefas do projeto simplesmente porque estava correndo atrás de algum capricho arquitetural ou perdia o dia lendo mails e fazendo coisas na Internet. Quando eu via que estava “viajando” demais, eu lembrava que às 15:00hs teria a reunião diária, e eu não havia cumprido a tarefa sob minha responsabilidade. Eu me sentia cobrado porque a reunião diária estava se aproximando e eu não tinha trabalho nenhum para mostrar para os outros membros da equipe.

Vocês se lembram das perguntas da reunião diária:

1. O que você fez desde a última reunião diária?

2. O que você pretende fazer até a próxima reunião diária?

3. Tem alguma coisa impedindo o seu trabalho?

Nas perguntas 1 e 2 a equipe não está se reportando ao ScrumMaster! Nessas perguntas a equipe está se reportando para ela mesma de forma auto-gerenciável. E sabe o que é interessante? O comprometimento da equipe é maior com a própria equipe do que com os níveis hierárquicos superiores. Quando você está falando o que você fez para a própria equipe você sabe que eles estão no mesmo barco que você. Não há razões para constrangimentos, dissimulações e conflitos.

É muito fácil enganar um gerente de projeto que passa com um Gantt Chart perguntando “- Já terminou a tarefa? Quantos porcento ainda falta?”. Agora, não é tão fácil assim enganar os membros da própria equipe… Eles passaram o dia todo com você. Não adianta você falar que não cumpriu a tarefa porque teve problemas com o RichFaces, pois os outros membros viram que você ficou a manhã inteira procurando seu carro novo na Webmotors. Não adianta você falar que não conseguiu falar com o usuário - a equipe viu que você ficou discutindo sobre repositorios no GUJ. Não adianta reclamar que o build demora - a equipe sabe que você ficou rodando os testes só para conversar com aquela loirinha do projeto ao lado.

A reunião diária está chegando, então, mostre serviço! Por mais romântico que você queira ser com o Scrum e com a auto-organização/gestão, por debaixo dos panos o Scrum tem mecanismos de cobrança, e são mecanismos muito melhores que um gerente de projeto perguntando “percentuais de conclusão”.

* Sei que você arquiteto de plantão deve estar doido para saber como era esse projeto do Japão por dentro. Vamos lá: Usamos Domain-Driven Design, cliente Swing, JBoss e EJB3/JPA/Hibernate no servidor, integração via XML-RPC - o troço tinha que escalar. Conseguimos suportar 80 transações simultâneas numa máquina com 2 processadores (o objetivo do projeto era suportar 1.000 prescrições médicas por minuto). O maior desafio era a usabilidade: japonês gosta muito de telas TouchScreen (por isso que os botões são grandes). Outras características: segurança biométrica, assinatura eletrônica de documentos, integração com máquinas de diagnóstico por imagem e quando você ligava o japonês não dava nem pra navegar na aplicação, só decorando os labels. Foi um dos projetos mais interessantes que participei.

Perguntinha na lista scrum-brasil@yahoogrupos.com.br:

Para se saber quantos pontos cabem na sprint atual, tomamos como base a sprint anterior certo? Dessa forma, vamos que seja colocada na sprint atual a mesma quantidade de pontos que foi atingida na sprint anterior.

Porém pelo que entendi, não temos a velocidade individual de cada um na sprint, não sabemos quantos pontos CADA DESENVOLVEDOR cumpre, pois cada um tem uma velocidade (baseada na capacidade, experiência, enfim, uma pessoa nunca é igual a outra). Só que como vamos saber qual será a velocidade da equipe na próxima sprint, ou seja, como vamos saber quantos pontos caberão na sprint, se a cada sprint eu tiver uma quantidade de pessoas diferentes trabalhando na sprint?

Porque eu pergunto isso? Imaginem que na sprint anterior tivemos 4 desenvolvedores trabalhando full time. Na próxima, um deles não poderá trabalhar 1 dia (irá fazer uma viagem a trabalho, por algum motivo) e outro faltou por uma questão de saúde, por exemplo. Dessa forma, minha velocidade já não é a mesma, pois não tive 4 pessoas full time.

Como tratar essas situações? Inclusive isso é muito comum na minha opinião.

Bem, estimativa não é uma ciência exata…

Uma das coisas que mais gosto nas práticas ágeis de planejamento e estimativa é exatamente o fato de não existir métricas individuais. Sim, nas equipes existem pessoas mais produtivas do que outras, porém, a variabilidade é tão grande entre pessoas e entre iterações que isso não vale a pena ser controlado, pois não somos robôs. Fred Brooks diz que há variação de até 80% na produtividade entre programadores. Algo que não ocorre com pedreiros como exemplo.

As práticas do Scrum e das estimativas ágeis (Planning Poker, literatura do Mike Cohn) são muito humanistas. Não são fatores deterministas que darão a produtividade da equipe. Se alguém na equipe teve que se ausentar, está com problemas na família, está doente ou está grávida, tudo isso é levado em conta na sua velocidade e ninguém é melhor que a própria equipe para fornecer parâmetros sob essa ótica tão empírica. Não é um gerente ditador que faz a equipe engolir a métrica. A EQUIPE É RESPONSÁVEL PELA ESTIMATIVA, sob todos os aspectos. É isso que faz a métrica funcionar.

No treinamento Scrum da Aspercom nós temos atividades práticas com estimativas ágeis, e é muito interessante como a aceitação de tal métrica é geral. Vejo o mercado cansado de métricas pesadas e pouco assertivas.

Respondendo a pergunta do nosso amigo do fórum, nas minhas equipes, no “planning” rolaria uma conversa mais ou menos assim:

“Se na Sprint 3 fizemos 39 pontos com todo mundo e nessa Sprint 4 o Claudervanderson vai viajar 1 dia, vamos estimar nossa velocidade em 37 pontos, fazendo as stories X, Y, Z, W, H, U, V, O…. concordam?”

A resposta para a velocidade sempre é dada pela Equipe… pense na velocidade como uma tendência e não como uma certeza. Pense na velocidade como uma aplicação financeira com riscos: “rentabilidade passada não garante rentabilidade futura”.

No cenário acima, se na Sprint 4 o Valdercleudiney ficar doente uns dois dias e vocês matarem 32 pontos ao invés de 37, não precisamos cortar os pulsos. Isso era esperado, certo? Então, no Planning da Sprint 5 pode rolar uma conversa assim:

“Bem, nessa Sprint 5 ninguém estará ausente e o Valdercleudiney melhorou. Vamos estimar nossa velocidade em 39 novamente? Concordam em planejar as Stories U, V, O, M, N, L, Q?”

A decisão é em grupo. Repetindo: É empírico.

Ou então você pode usar a tabela de fatores de correção da AMM:

Dor de Dente	-4%
Enxaqueca	-22%
Diarréia	-46%
TPM	-84%
Corinthians perdeu no Sprint anterior	-26%
Gravidez	-36%
Briga na família	-26%
Problemas com alcolismo	-21%
Diretor está de férias	-49%
O cara que cuida dos processos está de férias	+75%

Francamente!!!!!

Um dos fenomenos interessantes que tenho visto atualmente no mercado é a adoção de práticas ágeis, principalmente o Scrum, por empresas ISV de pequeno e médio porte. Já relatei alguns cases aqui como a Crivo, a YMF e a Summus. A algum tempo atrás a gente chamava os ISVs de “pacoteiros”, ou melhor, vendedores de pacotes.

Antes de mais nada digo a todos vocês que é muito bom trabalhar em ISVs. É um dos melhores ambientes para aprender sobre desenvolvimento de software, pois quando você está fazendo um produto para o mercado você utiliza quase 100% das práticas de desenvolvimento de software. Geralmente quando você trabalha para uma empresa, fazendo software sob medida, muitas coisas sobre análise de negócios, alinhamento com o mercado, concorrentes, design customizável, manuais de usuário, estrutura de distribuição e pós-venda não são problemas para você, mas para um ISV isso é o dia-a-dia do negócio. Fazer um produto para o mercado e ganhar dinheiro com isso é um desafio interessante.

A Synchro é um ISV 100% nacional que vende software para a área fiscal há 17 anos. Seus produtos atendem apuração fiscal, SPED, NF-e, CIAP e muitos outros. Eles estão presentes em São Paulo, Campinas, Curitiba e Rio de Janeiro.

No mês de janeiro a equipe da Synchro participou de uma das nossas turmas do curso Scrum da Aspercom, onde muita, mas muita conversa e discussões rolaram! No mesmo mês eles começaram sua adoção do Scrum no gerenciamento do projeto e também estão adotando outras práticas ágeis no seu processo de engenharia. Eles estão correndo bem a maratona da adoção Agile.

A adoção de práticas ágeis (como o Scrum) são decisivas para o sucesso dos ISVs. Nestes ambientes de alta competitividade qualquer ganho de market-share é importante, principalmente nesses momentos de crise. Os principais diferenciais que podem aumentar as vendas, reduzir custos e ajudar a esmagar a concorrência são alcançados com a colaboração, o foco, a transparência e a simplicidade das metodologias ágeis.

Ainda falando sobre as discussões correntes sobre o Papel do Product Owner, é interessante ver que em nesses cases citados, o Product Owner é uma pessoa de negócio, financiador (e geralmente está saindo dinheiro do bolso dele) e muito envolvido. Alguns deles tem conhecimento técnico. São orientados ao ROI da forma que o Scrum prega.