testes « Fragmental
- "Otimizar..kanban…" peraí, vocês querem que eu ajude você a decidir onde colocar seu story wall?
- É, acho que você pode colocar deste jeito…
- Você tem alguma idéia do quanto vocês estão pagando por hora pra eu estar aqui?!?
Eventualmente o cliente percebeu que onde posicionar o story wall era o menor dos seus problemas. Um dos principais problemas deles é que estavam fazendo exatamente o que o Fabio Câmara sugeriu: tinham um Scrum Master que criava, gerenciava e ajustava o plano. Os desenvolvedores estavam sempre atrasados porque eles nem sabiam qual era o plano, apenas sabiam das atividades. Discussão típica:
- Você está atrasado, meu time está em dia.
- Eu falei que precisava de dois dias para colocar o back-end em produção, bom estamos terminando agora, com o mínimo de atraso.
- Mas o front-end não está pronto, qual a diferença?
- Isso é com o time do Beltrano. Nós aqui estamos certos. Sprint goal atingido, vamos para o bar.
Ou, na "obtenção de feedback":
- Ok, esta tarefa aqui está demorando muito então vamos acabar entregando aquela ali atrasada.
- Você está dizendo que o projeto vai atrasar?!
- Não, não. Você me entendeu mal. Meu time está OK, nós vamos entregar em dia, não se preocupa não.
- Aquela tarefa ali… está meio atrasada, não?
- Não, não. Veja bem, ela já vai estar pronta… já já.
[final do sprint]
- Bom. Aquela tarefa ali atrasou. Isso fez com que o Fulano ficasse preso ajudando o Beltrano e não fizesse o trabalho dele. Mas não tem tanto problema porque ele não ia conseguir fazer o trabalho dele mesmo já que esta tarefa depende da outra.
- Então… o que vocês estão entregando hoje?
- O Domain Model, todas as classes no lugar. Ta pronto. Só falta testar.
A solução neste caso específico teve que ser meio drástica. O que queríamos fazer era remover todos os Scrum Master e devolvê-los a sua posição original (geralmente gerente de projetos e desenvolvedores sênior) mas vimos que isso ia causar problemas políticos demais. A solução mais viável foi manter os Scrum Masters -pelo menos o título- e usarmos "Gerentes de Iteração". Iteration Manager é o termo que usamos para um papel equivalente ao Scrum Master –gerente de projetos é outra coisa- e estes caras atuavam como lideres dos times e gerentes de iteração.
Os gerentes de projeto -ainda chamados Scrum Masters por razões históricas- tinham ainda o "plano", algo em extremo alto nível que dizia que considerando a situação atual de escopo e velocidade a funcionalidade X vai ser entregue dia Y, a Z dia W e assim por diante. Arrastar barrinhas no Microsoft Project não mudava o plano, ele era apenas um retrato da situação real e para mudar a situação real você tem que resolver seus impedimentos. Sem truques.
Outro problema foi o tal do testes. Nós sabemos que desenvolvedores profissionais testam mas neste cliente eles compartilhavam da idéia do Fábio de que testar é coisa pra recurso barato. Resultado? Os recursos caros ficavam dias produzindo código caro que não funcionava. Apos um sprint inteiro de código caro produzido se tinha que reescrever boa parte. Como é aquela história de "o barato sai caro mesmo"?
Nada disso, qualidade é algo muito caro para ser produzido por "recursos baratos". Como o Jason Yip diz: controle qualidade é responsabilidade do time todo -ele sugere o termo "Inspetor de Qualidade" para o que normalmente chamamos de QA- e para isso os desenvolvedores precisam entrar na dança. Sendo extremamente sincero, eu não consigo entender como um desenvolvedor experiente assume que uma metodologia ágil consiga funcionar sem testes. Você não tem sequer uma especificação dizendo o que vai construir! A única maneira que eu vejo disso meio que funcionar é se ao invés de uma metodologia ágil você utilizar apenas mini-waterfalls a cada sprint. Fica um tempo especificando o que vai ser feito, um tempo fazendo, um tempo testando. Enxágüe e repita. Mas isto não é uma metodologia ágil, o ciclo de feedback é muito longo!
E este foi só um dos múltiplos exemplos que tivemos nos últimos dois anos. É preciso ter cuidado, muito cuidado. Scrum vêm crescendo muito como hype e é um framework, cheio de lacunas por definição. Quando alguém com bastante bagagem vê as lacunas no Scrum ele logo assume que basta enfiar o que já se usa em desenvolvimento "tradicional" e acaba criando um híbrido de modelos quase sempre extremante ineficiente. Scrum não diz como desenvolver software? Sem problemas, nós sabemos fazer isso: escreve uma especificação no wiki, codifica, testa. Scrum não diz como compartilhar conhecimento sobre o código? Sem problemas, nós sabemos como fazer isso: antes do código ser enviado para o SCM ele tem que ser aprovado por um membro mais sênior do time. Scrum não diz como integrar código? Sem problemas: cada um cria seu branch e nós integramos no final do Sprint.
É bom notar que mesmo com as lacunas citadas o framework tem princípios bem definidos. A opinião de que o Scrum Master é o dono do plano vai de encontro com o que o Scrum prega. Pode ser a opinião de alguém experiente, você pode achar que faz sentido… só não pode dizer que isso é Scrum.
E se você soma isso ao fato de que não é preciso muita coisa para ter um certificado em Scrum o problema toma proporções gigantescas. Scrum em si não diz que é errado, digamos, escrever um documento de caso de uso de vinte páginas para cada item de backlog. E se, ainda por cima, a pessoa que sugeriu isso ainda possui um selinho dizendo que ele sabe Scrum?
Se você não tem um time experiente em metodologias ágeis então comece seguindo todas as práticas de XP. Após ganhar experiência decida o que funciona e o que não funciona –mas teste todas antes, e por um tempo considerável. Não comece apenas por Scrum. Como falei antes você vai encontrar muitos buracos e sempre a solução mais fácil vai ser fazer o que já se fazia antes.
Repetindo um tema freqüente neste blog: eu posso programar FORTRAN em qualquer linguagem. Eu posso gerenciar waterfall e/ou comando-e-controle em qualquer metodologia. Posted in brasil, comunidade, eventos, gerencia, metodologias, palestras, perolas, testes | 14 Comments »
Uh-Éme-Éle
Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.
O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para "modelagem" não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).
Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo "analista" no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?
Há algum tempo que eu me pergunto porque que se usa UML para "modelar". Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.
Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.
O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus "implementadores" façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo? Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como "programador júnior" porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu "analista" uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o "analista" sozinho cuide do serviço?
Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu "analista" usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.
Mas como assim? O "modelo lógico" é muito diferente do "modelo físico" e o "analista" não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:
Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo "diagrama de domínio". POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus "analistas" sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.
Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.
Posted in arquitetura, comunidade, engenharia, metodologias, plataformas, programando, testes | 26 Comments »
Posted in domain.specific.languages, gerencia, metodologias, programando, ruby, testes, thoughtworks | 6 Comments »