É 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:
[photopress:IMG_1407.JPG,full,pp_image]
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!!!!!
Fala Rodrigo,
Fiz 400 pontos! hahaha… Muito bom post e bem legal essa idéia de manter a ordem de prioridade das histórias.
Abraço
Vou mudar a escala!!!!
“Aplique desenvolvimento iterativo, trabalho em equipe, foco em resultados…”
Tá ai uma opinião diferente… longe dos modismos (gostei) (Y) :
Quando leio/ouço/discuto agilidade parece pra conhecer esse assunto, tem que obrigatoriamente: Criticar UML, falar de cartões, falar de iteratividade (mesmo se às vezes, não compreende ao certo ou mesmo a aplicabilidade correta)…
Parábens (+ uma vez) !!!
Esse negócio de correntinha é meio GLS hein rsrs
perdi 10 pontos rsrs
=)
A idéia da correntinha é legal! mas será que isso não seria uma forma comando-controle de se trabalhar?
Hahahaha…quanto será que o Dxalma vai tirar??
Rodrigo, quer ver o caos do que você escreveu? Olha isso aqui: http://www.dragile.com/
Eu vou fazer uma pergunta de iniciante.
Precisa mesmo seguir a ordem certinha? Imagino assim: a iteração dura duas semanas (chute), e o owner definiu umas quatro histórias, que são as mais importantes pra ele, pra fazer na primeira iteração. Aí fiquei na dúvida, faz diferença se os desenvolvedores trocarem a ordem dessas quatro histórias, contanto que realmente sejam essas as que vão ser entregues daqui a duas semanas?
Leonardo, se você tiver certeza que vai entregar todas as histórias acaba não fazendo diferença, mas na possibilidade de não conseguir entregar tudo é importante seguir a ordem definida pelo PO, pois afinal o objetivo é entregar maior valor de negócio em menos tempo.
A mesma coisa vale pra quantas histórias podem estar rodando ao mesmo tempo. O ideal é que seja o menor número possível e com a maior quantidade de gente trabalhando em uma história, pois dessa maneira o conhecimento é distribuido de maneira mais homogenea entre a equipe.
É claro que existem situações onde esses dois pontos não podem ser seguidos, mas de uma forma geral esse é o caminho.
Valder, de maneira alguma! O Scrum tem determinadas regras importantes que fazem a metodologia funcionar. Uma delas é que o Product Backlog é um artefato do Product Owner. Ele é o responsável e deve tirar o máximo de dinheiro possível disso.
Não é qualquer regra que significa comando-controle diretamente. Agilidade tem regras claras. Como exemplo, quem dá os prazos é a equipe.
Boa, mestre Yosha.
Sugestão para a tabela: usar a palávra “ágil” em tudo (+50/-50)
“Aqui usamos técnica ágeis para tomar café.” – leia-se engolimos
“Fazemos arrumação ágil de mesa.” – leia-se não arrumamos
“Processo ágil de desenvolvimento cascata.” – leia-se fazemos tudo do mesmo jeito
“Aqui nós inovamos de maneira ágil, agregando valor e entregando soluções de alto valor para o cliente” – leia-se fazemos de qualquer jeito, afinal no final o que importa mesmo é o preço
:-)))))
Rodolpho… essa foi muito boa… são 2:20, tive um ataque de riso incontrolável, minha filha mais nova até acordou assustada… levei uma bronca titânica da minha esposa… ha ha ha ha…
Sensacional o post! Dr Agil (dito por Alexandre Magno) é demais, não consigo parar de rir! ahuhauhauhauhau
Sensacional !!
Ae mestre Yosha (hahahaha), por que Rails ganha pontinhos e Java, Python, Shell Script, HTML, JavaScript, BASIC do meu MSX não ganha nada? =)
Rails está na moda!!! Java não ganha nada por razões óbvias:
http://blog.aspercom.com.br/2008/07/31/rigidez-conceitual-burra/
Basic do MSX é muito bom… aliás, um dos primeiros programas que fiz na minha vida foi nele:
10 PRINT “RODRIGO YOSHIMA”
20 GOTO 10
O único problema é que toda a vez que você precisava fazer um RENUM você entrava em débito técnico.
Rodrigo,
Concordo com a essência deste seu post. Na minha experiência Agile, os verdadeiros resultados estão no
“desenvolvimento iterativo, trabalho em equipe, foco em resultados…”
dos “artefatos” listados aí na sua AMM não utilizo nem 10% AINDA. Digo “ainda”, pois acho tudo isso idéias interessantes e que vou aplicar num futuro caso surga a necessidade.
Não vou encher um processo com “penduricalhos” (nada contra a correntinha) só por causa de modismo. Senão acabamos indo contra um dos pricipios do manifesto ágil “Software em funcionamento mais que documentação abrangente”.
Muito bom essa post!!! 🙂
165! puxa e nem agile a gente é 😀
Muito bem bolado!
Voce utiliza blocos de Lego? Sim +10 / Nao -10
http://www.infoq.com/news/2008/09/lego-information-radiators
=o)
Parabéns pelo post Rodrigo, é uma idéia interessante, se bem que eu não acho muito prático utilizar. Não sei porque mas não consigo, e atualmente busca estar com menos papéis, porque mais na frente estarei com um lixão, e depois quero guardar para ter um histórico e tal, mas nunca dá certo.(isto é para um caso de projeto pessoal, assim como você mencionou).
Você lê os artigos do Rodrigo Yoshima? (hehehehe) já garantir 20 pontos! Gostei das brincadeiras e é desta forma que você acaba vendo o quanto estamos sendo práticos no que fazemos, de forma a refletirmos, buscando agregar valor ao produto de forma coerente, e o melhor evitando desperdícios! :^)
Pingback:Débito Técnico » Blog Archive » JustJava 2008
Pingback:XP no “underground” – Scrum no “mainstream” « Clavius Tales