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…

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.

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

Fiquei bem surpreso como nos dois últimos eventos de Java falamos muito sobre Ruby e Rails (TDC e JustJava). Digo isso não nas palestras, mas sim nos bate-papos. Eu confesso! Nos últimos eventos gostei mais das conversas nos intervalos do que das palestras.

A minha dúvida era: “Se num evento de Java se fala muito sobre Ruby, o que se fala num evento de Ruby?”. Para minha surpresa, o que se fala muito num evento de Ruby é BUSINESS. Isso mesmo! O Rails Summit da Locaweb teve muito bate papo sobre negócios e como ganhar dinheiro com software. O que mais me chamou a atenção foi uma “certa aversão” ao termo Agile nas conversas dentro e fora das palestras. O Guilherme Chapiewski ficou meio revoltado quando eu disse que logo vão exigir “Scrum Masters Certificados” nas licitações (sim… eu ouví esse papo nas minhas andanças no Planalto Central). O Shoes foi categórico: “Não falo sobre Agile”. Já com o Vinicius Teles, batemos muito papo sobre negócios, produtos, não trocamos uma palavra sequer sobre Agile. Também estavam presentes muitos outros agilistas, railers, gujeiros, alunos da Aspercom e etc…

Vamos falar das palestras (vou comentar apenas as que me chamaram a atenção OK? Devido a minha agenda não deu para participar de todas também):

Keynote do Chad Fowler

Carl Youngblood (Surgeworks) & Chad Fowler. Foto: Flickr do Helder Ribeiro (cara, não te conheço mas valeu pela foto)

O cara é palestrante profissional. Foi agradável. Fiquei surpreso que ele cortou o cabelão e o barbão. Alguns pontos que achei muito legais:

1. Ele fala muito sobre música. Ele é músico. Toca vários instrumentos e até estudou música. Check this out:

2. Ele nunca estudou academicamente sobre programação. Aprendeu tudo sozinho (como muitas outras pessoas). Para falar a verdade, neste ano ele assumiu que está tomando algumas aulinhas de Erlang.

3. Algumas pessoas para ele são “remarkable”. Para ele, não para mim. Um japa gritando que nem uma gralha e outra japa dançando que nem uma lingüiça na frigideira, não são parâmetros de destaque na minha opinião.

4. “Always use Sharp n’ Dangerous Tools like Dynamic Typing / Monkey Patching”, creio que esse foi o ponto alto da palestra. Nesse mesmo momento ele disse que tipagem dinâmica é coisa para bons programadores, assim como XP. O tom da palestra dele foi “Java é coisa do passado”, e colocou os Javeiros atrás dos PHPeiros (uma coisa que quase reacendeu a inquisição aqui no Débito Técnico quando escreví).

5. Eu e o Chad compartilhamos uma prática: nós usamos geradores de código para nós mesmos. Infelizmente não tive oportunidade de conversar mais com o Chad a respeito disso.

6. Seja o pior programador da sua equipe. Isto é, se você é o melhor você não aprende muita coisa. Se você é o melhor, talvez seria bom você pensar em mudar para uma equipe que tenha pessoas melhores que você para você crescer.

Imaturidade dos Testes com Jay Fields

O Jay Fields foi meio polêmico. Falou algumas coisas meio “revolucionárias” (coisas do tipo: não se apegue a padrões para teste). Teve certo burburinho depois da palestra, mas outros comentários foram legais da parte dele:

1. Trate seu código de teste com o mesmo carinho que você trata o seu código de implementação/produção.

2. Testes são procedurais! Usar objetos como código de teste podem dificultar seus objetivos com o teste. Isso é verdade principalmente para código Java e xUnit.

3. Seu objetivo não deve ser buscar 100% de cobertura de teste, e na opinião do Jay, todas as vezes que ele viu equipes buscando isso tinha alguns testes idiotas no meio disso tudo. O foco deve ser direcionar seus testes para que eles sejam inteligentes. Os testes devem cobrir muito bem as partes essenciais.

4. Todas as ferramentas tem seus prós e seus contras, isso achei muito legal ele citar, pois testes com Selenium, RSpec, xUnit e etc devem ser mesclados nos seus testes, assim como a estratégia (Smoke, Integração, Unidade, Funcional, Aceitação e etc…). Cada um tem as suas particularidades sobre a velocidade ao rodar, legibilidade e facilidade de manter. Ele criticou todas as ferramentas, inclusive o RSpec, mesmo com o David Chelimsky presente!

5. Ele citou outras duas ferramentas que não conhecia: O Synthesis e o Expectations.

Almoço Besteirol Interneteiro

Juntamos numa mesa: Eu, Fabio Kung (Caelum), Bruno Carvalho (Globo), Mauricio Linhares, Guilherme Chapiewski (Globo) e Phillip Calçado Shoes (ThoughtWorks). Falamos muito sobre Testes, Ruby e até Java. Um papo de arquitetos. Eu não tava entendendo muito da conversa.

Mas a parte legal foram os besteirols da Internet. Só dava a gente rindo alto no salão inteiro. Fomos os últimos a sair. Fica a dica deste site: http://www.tolicesdoorkut.com/.

(não abra isso no seu emprego / sim, a inclusão digital tem seus efeitos colaterais… muito colaterais por sinal)

David Chelimsky – RSpec e BDD

Talvez eu tenha achado um sobrenome mais difícil de escrever que “Chapiewski”. Err… não … Chapiewski ainda é mais difícil. David Chelimsky colocou alguns pingos-nos-is sobre TDD vs BDD. Sim, BDD é mais uma palavra na moda, porém, tem algumas coisas que realmente não são o cerne da TDD e estão incluídas na BDD. De qualquer forma, os princípios são parecidos. A apresentação do David reforçou bastante esses pontos.

Auditório cheio e prestando atenção em David.

Pedi para ele postar os slides no blog dele. Vamos aguardar!

Vinicius Manhaes Teles – Empreendorismo em Rails

Foi muito legal a apresentação do Vinicius. Não citou nada sobre Agile, o que pode ter frustrado alguns, porém, para mim foi muito bom. Ele palestrou sobre como crescer prestando serviços ou como crescer elaborando produtos. Um toque legal para quem quer um dia ser seu próprio chefe (eu recomendo). Conversamos bastante sobre as estratégias da Improve IT para seus produtos, uma linha que também tento seguir, mas ainda sem tirar o pé de serviços. O problema é que segundo o Vinicius, serviços não escalam, assim como Ruby. (he he he, piadinha).

Vinicius, eu e o Marcos Tapajós (Improve IT / Surgeworks)

O evento foi excelente! O Fabio Akita está de parabéns, assim como todo o pessoal da Locaweb. Que venha o Rails Summit ‘09.

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.

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!

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.

(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/

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.

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.