Débito Técnico

Na minha coluna MundoOO da revista MundoJava, publiquei um artigo que dismistifica muito sobre User Stories e responde a algumas perguntas comuns sobre o assunto que observei no mercado em muitas equipes: Como escrever? Quem faz o que? Pra que usar cartões? Aonde está a especificação? e etc…

Essas dúvidas geralmente surgem no nosso Workshop Scrum, onde temos uma atividade prática muito legal sobre captura de User Stories dentro de uma concepção ágil (veja cases do blog).

Este artigo é parte de uma série sobre Agilidade que estou mantendo na coluna. Ultimamente escreví sobre modelagem ágil, TDD, requisitos/especificações executáveis e etc…

Segue o trechinho grátis:

É fato que a maior parte do mercado brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo, bancos, Telecom, indústrias e etc…). O contrato de escopo fechado promete “previsibilidade” no desenvolvimento de software, porém, esta forma de contratação parte de duas premissas muito duvidosas: 1 – o cliente sabe exatamente o que quer; e 2 – a equipe sabe estimar exatamente o esforço de construção.

Se você já trabalhou em dois ou três projetos de software você sabe perfeitamente que essas premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu gerente colocar 50%, 100% e até 150% de “gordura” ou “pulmão” no valor da proposta para o cliente. E esse é o resultado: tentar forçar a “previsibilidade” num contrato de escopo fechado gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como verdade absoluta e dizem: “- Eu quero tudo!!!”, não se importando se a solução vai resolver os problemas ou não.

Na verdade, um projeto de software tem uma peculiar característica de “constante investigação”. Ken Schwaber chama isso de “inspeção e adaptação”. Em termos mais práticos, o dia-a-dia de uma equipe de desenvolvimento de software é “checar se estamos no caminho certo e ajustar o rumo sempre que necessário”. Desenvolvimento de software é um processo criativo de pesquisa, então, especificações pactuais gordas que apodrecem no nosso controle de versão nos ajudam muito pouco para o sucesso do projeto. Em projetos de software bem sucedidos é comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que não podem ser ignorados e a outras possibilidades de solução ou “atalhos” que devemos aproveitar. Dentro do desenvolvimento iterativo esses problemas e atalhos se tornam muito claros.

Quer ler mais? Já nas bancas…

Nas últimas semanas tivemos vários relatos de empresas do Planalto Central adotando práticas ágeis em projetos para o Governo. Na semana passada ministrei o nosso Workshop Scrum para o pessoal da Infraero.

Mais uma vez os questionamentos são baseados nos famosos “projetos de escopo fechado”. E após muitas discussões (construtivas) é fato que a legislação de contratação de outsourcing para o governo ferem as práticas ágeis. Porém, na minha opinião, existem maneiras de ao menos cobrar desenvolvimento iterativo dos fornecedores para reduzir o risco com entregas parciais.

Para quem não conhece, a InfoQ estará abrindo as portas aqui no Brasil e temos um evento de lançamento no dia 01/11 (sábado) com a presença de muitas pessoas das comunidades Agile, C#, Rails e etc… Estarei presente participando de mais um painel sobre Métodos Ágeis (Mais uma vez… tá vendo? Quem mandou não estudar mais sobre arquitetura?)

Link para as incrições: http://www.fratech.net/infoq

Nos próximos meses temos eventos interessantes, e estarei participando de alguns. Minha agenda é bem agitada como colunista da MundoJava e proprietário-instrutor-consultor da Aspercom. Além disso, a Aspercom também tem projetos na mesma linha que a Improve It. Falar sobre esses projetos é assunto para outro post, até porque preciso de autorização de clientes e parceiros.

Rails Summit da Locaweb

O Fábio Akita (AkitaOnRails) está fazendo um barulho enorme no blog dele e com razão. Faz um bom tempo que não vejo um evento com uma seleção tão interessante. Muita gente de fora e também feras brazucas. O fato da Locaweb ter disponibilizado o Passenger nos seus planos pode sim agitar a adoção do Rails.

O que me interessa nesse evento: Chad Fowler e sua palestra sobre “A Evolução de um Framework”; Jay Fields que falará sobre “A Imaturidade dos Testes de Desenvolvedores”; Carlos Villela sobre “Uma Web de Documentos”; George Malamidis e a implementação RESTful do Ruby on Rails; David Chelimsky (do RSpec) sobre Behavior Driven Development (uma das minhas linhas de estudo atuais); Vinícius Manhães Teles sobre empreendedorismo com Ruby on Rails.

Link para o evento: http://www.locaweb.com.br/railssummit

Falando em Agile

Neste evento da Caelum também estarei marcando presença, o pessoal da ThoughtWorks vai estar por lá e a palestra do David Anderson promete muito.

Link para o Evento: http://www.caelum.com.br/falando-em-agile/

Com certeza tirarei algumas fotos para postar uma retrospective aqui.

Na edição 29 da revista MundoJava escreví sobre o dia a dia de um agilista. Continuando uma série sobre TDD na Revista MundoJava nesta edição escreví um artigo sobre a ferramenta FIT para automação de testes. O artigo teve participação de Ivan Sanchez e James Shore.

O Ivan Sanchez foi o cara que fez o treinamento CSM junto comigo no início de 2007, e teve o azar de cair no mesmo grupo comigo! O Ivan é um agilista e grande evangelista de Coding Dojos. Atualmente trabalha na Signature Technologies no Reino Unido.

James Shore (Jim) é lider do projeto FIT (criado por Ward Cunningham), atua em projetos ágeis desde 1999 (sim, existem projetos ágeis antes do Manifesto Ágil) e escreveu o livro “The Art of Agile Development“.

Uma das coisas legais de escrever na MundoJava é ter contato com esses caras lá de fora e poder trazer estes conteúdos para nossa comunidade. Escrever com o Scott Ambler e o Jon Kern foi muito legal. Este artigo com o James Shore também foi especial. Infelizmente eu recebo mais não do que sim, mas ainda vou continuar insistindo com os mestres! Ah… vocês querem o trecho grátis do artigo, certo? Então aí vai:

Uma das questões comuns é: Quem escreve os dados de teste? Pela estratégia do FIT, os dados de teste são escritos a “oito mãos”. É comum que tudo inicie com o usuário ou cliente e com o analista de negócios, capturando cenários de teste iniciais que formatam alguns critérios de aceitação. Depois disso, um desenvolvedor pode verificar a formatação das tabelas, referenciar as Fixtures e assim obter o RED do ciclo TDD. Ao mesmo tempo os testers podem participar colocando mais cenários. Logicamente, o FIT é uma ferramenta ágil. É importante uma rica colaboração face a face de todos os envolvidos para que exista sucesso na adoção dessa abordagem.

Uma atenção especial deve ser dada ao trabalho do analista de negócios. Atualmente é comum que esses profissionais capturem requisitos em documentos texto e alguns diagramas. Geralmente este tipo de abordagem é muito pobre para o desenvolvedor, principalmente se não existe uma comunicação rica entre eles. Comunicação com documentos é uma forma muito pobre de comunicação (veja artigo “Modelagem Ágil”, MJ 27). Um modelo de requisitos em texto é muito deficiente na maioria das vezes. Pare para pensar: Não existe teste sobre documentos em texto e nem compilador para diagramas!
Rodrigo Yoshima

O que é o FIT e porque se importar com ele? O FIT é parte do seu arsenal ágil de prevenção de bugs. Diferente da abordagem tradicional para a qualidade, onde focamos em encontrar e remover defeitos, as práticas ágeis focam-se primeiramente em previnir que bugs sejam criados. Isso nos leva a alguns resultados impressionantes. Times ágeis experientes produzem poucos bugs por mês.

As “práticas ágeis de engenharia” pregadas pelo Extreme Programming (XP) são parte da solução. Essas técnicas como Test-Driven Development (TDD), programação aos pares, propriedade coletiva do código, design simples e trabalho energizado previne a maioria dos erros de programação. Elas garantem que o código faz exatamente o que os programadores pretendiam que ele fizesse.
James Shore

FIT ou Framework for Integration Testing é uma ferramenta excepcional no auxílio ao desenvolvimento de um software. O cliente (ou analista de negócio) escreve tabelas mostrando o que o sistema deve fazer através de exemplos. O desenvolvedor escreve o código das fixtures, que são as classes que ligam as tabelas com o sistema que está sendo implementado. A partir daí as tabelas se tornam “executáveis” e as regras definidas podem ser validadas de maneira automatizada.

FitNesse é a implementação mais popular de FIT, que funciona na forma de um wiki. Cada página representa um teste executável e é possível executar múltiplas páginas para validar um sistema como um todo. Além disso, por se tratar de um wiki, favorece a colaboração entre cliente e desenvolvedores, podendo servir como uma ótima base de conhecimento sobre o sistema que está sendo construído.
Ivan Sanchez

O FIT é uma ferramenta muito interessante: Uma coisa que chama a atenção em projetos onde utilizamos o FIT é que produzir as tabelas com os dados de teste é uma atividade de modelagem intensa. Modelar não é fazer diagramas, é muito mais profundo do que isso!

Já nas bancas!

Aqui estão as fotos e fatos do final de semana ágil em Brasília.

Chopp Ágil DF

Na sexta-feira rolou o Chopp Ágil DF, conforme publicado no post anterior.

Presença do Pessoal

“Arte Agile”

Workshop Scrum

Mais uma turma finalizada e com ótimas avaliações dos nossos alunos! Nesta turma em especial, tentamos responder as questões de devem assolar o cerrado: “Como colocar um ambiente ágil em projetos e licitações do Governo?”. A conclusão que sempre chegamos é que de fato contratos de escopo fechado e BRUF são muito dispendiosos. Sim, é possível ter um ambiente iterativo com escopo fechado, porém, você sofrerá com a gestão de mudanças irracional e o cliente sofrerá com aqueles 60% a 100% de “gordura” que o fornecedor colocará no contrato.

Todo mundo

Equipe 1

Equipe 2 (por que eles riem tanto?)

Adoro esses “artefatos ágeis” que surgem do nada e ajudam muito os alunos.

Isso é um mapa de navegação de um site de rede social.

Scrum-Ban semi-digital.

Opinião no nosso amigo Narixx sobre o peso do rinoceronte (depois de saber que um avestruz pesa 135Kg).

Fatos interessantes:

- Perguntei para dois brasilienses sobre como funcionava o esquema dos endereços em Brasília, ambos falaram que é “muito simples” e depois entraram em discussão entre eles sobre como funcionava tal esquema.

- Em Brasília tem um Standcenter / Promocenter muito maior que o que havia em São Paulo. É a feirinha do Paraguai. Produtos excelentes com procedência duvidosa e 3 meses de garantia.

- Brasília é mais bonita ao vivo do que em fotos.

Não deixe de também de olhar o post do Rafael Benevides no seu blog. Aliás, o Rafael contribuiu muito para que essa turma se disponibilizasse no DF. Obrigado novamente Rafael!

No dia 18 de outubro teremos uma nova turma em Brasília. Ainda não está divulgada no nosso site, porém será em algum hotel a definir. Para se inscrever envie um mail para rodrigoy@aspercom.com.br. O programa, preços e condições também estão no nosso site.

Estarei neste sábado ministrando o nosso Workshop Scrum em Brasília e aproveitei para marcar um Happy Hour com os agilistas locais (presença confirmada do pessoal da AgilDF, Rafael Benevides, Narixx, Renato Willi só para citar alguns).

(fazendo um anúncio de maneira ágil)

PMPs, CMMistas, Cascateiros, Ganttistas, Cowboys Heróicos também podem participar, desde que não defendam Waterfall.

Acessem: http://www.barazeitedeoliva.com.br/

Estive presente no JustJava 2008 onde apresentei a palestra “Mitos do Desenvolvimento de Software e Soluções Ágeis” (que logo em seguida teve a muvuca sobre Agilidade e Testes, muito boa por sinal). Também estive presente no Painel sobre Metodologias Ágeis mediada pelo Jorge Diz. Minha apresentação no SlideShare:

Fiz um esforço descomunal para não constar coisas da moda sobre Agilidade nesta apresentação. Até me arrependí do título. Dei um foco maior no “básico” (o cliente, o time e a iteratividade). Acreditem, o básico é o que o mercado precisa digerir neste momento. No fim muitas pessoas gostaram e até riram das piadas. Ganhei nota 8.5 do Prof. Papo, então, acho que fui bem (não estou muito acostumado a palestrar).

Troquei idéia com muita gente e reencontrei velhos amigos como os “Thiagos” da época da Datasul, donos do projeto Floggy.

Timba, eu e o “Thiago Doido”

Prof. José Paulo Papo, eu e Prof. Eduardo Guerra (”O editor-chefe”)

Mesa do Debate

Eu…

Desde o início deste ano estou separando agenda para poder comparecer e palestrar em eventos. Parabéns a todos pela organização e com certeza estarei presente em 2009.

Na semana passada ministrei nosso Workshop Scrum para uma turma de 20 pessoas do Banco Indusval Multistock.

O Banco Indusval Multistock S.A. é um banco privado com 40 anos de experiência de atuação no mercado financeiro brasileiro. Desde 1993, suas atividades encontram-se focadas em um dos segmentos que o Banco considera dos mais atrativos do mercado de crédito: crédito a empresas médias.

A equipe deles desenvolve seus softwares em PHP e busca utilizar o Scrum como mecanismo de controle de projeto para iniciar uma melhoria de seus processos, buscando uma melhor interação entre o desenvolvimento e as áreas de negócio. Este tipo de necessidade beneficia muito a adoção do Scrum, pois toda instituição financeira é bem focada na busca por resultados rápidos.

Seria muito legal se esta moda pegasse em grandes instituições financeiras como Itaú, Bradesco, Unibanco e muitos outros! Infelizmente os projetos que desenvolví para grandes bancos sempre eram escopo fechado, foco em documentação e mais alguns toques cascateiros. Uma coisa para os CIOS dessas empresas pensarem a respeito.

É incrível como o mercado é dado a modismos. Atualmente quando falamos sobre Agilidade um monte de besteirinhas acompanham o termo. Várias vezes ví em fóruns de discussão: “estamos adotando o Scrum, mas ainda não temos o quadro de tarefas”, “ainda não conseguimos ter as histórias em cards”, “ainda não temos as cartas do Planning Poker”, “ainda não traçamos o gráfico de burndown”, “ainda não temos o quadro branco para fazer os modelos”, “ainda não estamos estimando em pontos”, ” e etc, etc, etc… às vezes ouvimos “não usamos mais casos de uso, só usamos histórias”, “não documentamos mais a arquitetura”, “banimos o RUP”, “não documentamos mais a visão”, “não usamos mais UML”, “não temos mais documentos Word, só usamos Wiki”, “não somos mais CMMI” e etc, etc, etc…

Infelizmente vejo que tem se criado um “Termômetro Agile” bem estúpido. É um AMM (Agile Maturity Model) que mede o quão Agile você é baseado na quantidade de práticas da moda que você aplica. É mais ou menos assim:

Práticas AMM	Pontos
	Sim	Não
Você tem o quadro de tarefas da iteração?	+10	-10
Você tem as histórias em Index Cards?	+10	-10
Você está usando mais de 135 post-its por mês?	+10	-10
Você tem o quadro branco com modelos?	+10	-10
O quadro branco tem modelos UML?	-5	+5
Você mantém modelos UML como artefatos?	-15	+15
Você tem as cartas do planning poker?	+5	-5
Sua reunião diária dura exatamente 15 minutos?	+5	-5
Você usa algumas práticas do RUP?	-10	+10
Sua documentação está num Wiki?	+5	-5
Você se preocupa com rastreabilidade?	-15	+15
Está usando uma ferramenta para gerenciar o projeto?	-10	+10
Sua iteração tem mais que 2 semanas?	-10	+10
Seu Gráfico Burndown está em pontos?	+5	-5
Você pode ir trabalhar de camiseta?	+15	-15
Você usa Gantt Chart?	-100	+100
Você é CMMI?	-100	+100
Você tem PMPs na equipe?	-50	+50
Você tem CSMs na equipe?	+50	-50
Você está fazendo em Rails?	+25	-25
Você já assistiu uma palestra com o Juan Bernabó?	+20	-20
Sua equipe assiste aos videos da ImproveIT?	+20	-20
Você lê o blog do Guilherme Chapiewski sobre a Globo.com?	+20	-20
Você fez o curso com o Alexandre Magno na Caelum?	+20	-20
Você lê os artigos do Rodrigo Yoshima?	+20	-20

(Juan, Vinicius, Guilherme e Magno… isso é só piadinha, OK? - espero que não tenha retaliação )

Nível	Pontos
1 - Cascateiro	até 50
2 - Discretamente ágil	51-100
3 - Ágil	100-300
4 - Bem Ágil	301-500
5 - ThoughtWorks / Google	acima de 500

Quadro referência

O objetivo aqui é exatamente falar contra isso, ou chamar a atenção para esses modismos. Usar Kanban, Index Cards, Cartas do Planning Poker, Pontos e Quadro Branco não é o que vai tornar você ágil. Dependendo do contexto é capaz que seja melhor você esquecer essas coisinhas da moda. Elas podem até te atrapalhar. Aplique desenvolvimento iterativo, trabalho em equipe, foco em resultados…

Vou dar um exemplo. Uma das coisas que me atrapalham é perder a ordem das histórias. Quando você está trabalhando iterativamente, seguindo uma ordem definida por um Product Owner, essa ordem deve ser mantida. Quem fez treinamento comigo ou trabalhou comigo em projetos sabe que sou chato para manter a ordem da fila de construção. Nesse novo projetinho Rails que estou desenvolvendo sozinho, resolví isso furando os cartões, colocando uma correntinha para manter a ordem e um durex verde para indicar a primeira história da fila:

Sim! Isso está ajudando no meu projeto. E poderíamos até evoluir a idéia: a correntinha poderia ter um cadeado que só o Product Owner tem a chave, pois só ele pode tirar, colocar ou mudar a ordem dos Index Cards. Seria mais uma prática da moda!!!!

Práticas AMM	Pontos
	Sim	Não
Você tem uma corrente amarrando os Index Cards do Backlog?	+10	-10

AMM v1.1

Francamente!!!!!