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

Tive uma dúvida nos últimos tempos.

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…

Leia o restante deste artigo »

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.

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.

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!!!!!

Na semana passada ministrei nosso Workshop Scrum para nossos amigos da empresa FórumAccess. A FórumAccess é um excelente exemplo de consultoria pequena que o Phillip Calçado tanto fala. É uma empresa com mais ou menos 100 desenvolvedores que já está trilhando o caminho da Agilidade de maneira intuitiva. Com o treinamento eles de fato adotarão o Scrum para gerenciar os projetos.

Mais um treinamento com uma bela paisagem!
(essa ponte é linda na foto, mas ao vivo ela estraga a paisagem)

Uma das coisas que mais me chamaram a atenção na FórumAccess é a adoção de contrato de escopo negociável, apesar das dificuldades em vender este tipo de contrato no mercado. Eles são um dos poucos exemplos de empresa que oferecem este tipo de contrato (aqui em São Paulo são pouquissimas empresas que aplicam isso).

Como o Vinícius Telles explicou muito bem na sua palestra do TDC 2008 e também no vídeo sobre desperdício de funcionalidade, seu objetivo como desenvolvedor de software não é entregar tudo, mas sim, entregar aquilo que mais agrega valor para o cliente. O contrato de escopo negociável favorece isso.

Equipe 1

Equipe 2

Escrevendo User Stories

A homepage mais feia do mundo

Todo mundo

Tudo começa no planning

Agradeço a todo pessoal da FórumAccess pela troca de informações rica, principalmente sobre como o mercado tem se comportado com os contratos de escopo negociável. Essa mudança de cultura é muito importante para melhorar nosso mercado. Eu realmente acredito que consultorias menores e mais concentradas em entregar valor são alternativas melhores que as fábricas de software gigantes e burocráticas.

Julho é um mês agitado aqui na Aspercom. Todo o pessoal está de férias e muitos querem se manter atualizados nas novidades do mercado e etc… Ministramos treinamentos para aproximadamente 100 pessoas neste mês.

Sala de Treinamento da Aspercom
Computadores DELL Core 2 Duo e monitores LCD de 21″

Uma das grandes “novidades” é que dessa vez mais pessoas levantaram a mão quando perguntei se elas estão aplicando desenvolvimento iterativo. De acordo com a pesquisa rápida, creio que 60% dos alunos disseram estar aplicando desenvolvimento iterativo. 40% ainda era cascateiro. Bem, creio que isso é uma grande vitória, pois é muito comum 100% da turma ser cascateira. Será que as empresas estão caindo na real?

Eu acho que a comunidade Agile está fazendo um bom trabalho. Estamos dando o recado de maneira muito clara. Tem várias outras boas novidades de empresas grandes e pequenas buscando melhorar seus processos. Logicamente também aparece um ou outro louco afundando a adoção de Agile em algum lugar.

Foi muito legal neste mês de julho conversar com muitas pessoas de muitas comunidades diferentes. Uma das motivações de ter escrito o “Rigidez Conceitual Burra em Java” é o dinamismo da comunidade PHP. Realmente vejo eles buscando sistemas mais organizados através de frameworks bastante influenciados pelo Rails. Por conta de um sitezinho que precisei fazer, estudei o CakePHP. Infelizmente o site era bem simples e não deu para aprofundar muito, mas é fato que o sistema fica mais claro, mais fácil de manter e com uma melhor separação de responsabilidades. Logicamente a sintaxe do PHP é o que não ajuda!

O fato de ter escolhido PHP é que o provedor do cliente não tinha Rails “inicialmente”. Problema de comunicação! Quando fui colocar a primeira iteração no ar para testes, ví a seguinte tela:

Por melhor que seja o PHP, me desculpem! Rails é Rails! O provedor do cliente atendia Rails sim! Como estava ainda na primeira iteração logicamente que valia a pena migrar para Rails. Deus abençoe a Phusion. Uma das razões que me faz apostar no Rails é o Passenger (mod_rails). Logo logo o mod_rails se tornará padrão em qualquer provedor. Pra falar a verdade, creio que a popularização do mod_rails marcará o início da queda do PHP.

No treinamento Scrum do dia 19 de julho, conhecí o André e o Antônio Carlos (pessoal da Stefanini) que estão num grande projeto Web para a Fnac. O que chamou a atenção é que este projeto é Scrum + DDD + .NET + Escopo Negociável. Sendo sincero com vocês, é raro pessoas que trabalham com .NET aplicar DDD corretamente como este pessoal. Infelizmente, é comum o DsPLPC (Data Set pra lá e pra cá). Vamos ver se isso muda com o Entity Framework (isso se a M$ não fizer nenhuma besteira). Mas fiquei contente que o Antônio Carlos relatou como nosso treinamento auxiliou na adoção do Scrum com o Team System. Realmente estamos torcendo por vocês.

Muitas outras histórias e relatos tive nessas turmas. Realmente foi muito enriquecedor! Gostaria agradecer a todos os alunos pelas conversas nos coffe-breaks e pela excelente avaliação feita dos treinamentos.