Fragmental

Em 2003 eu liguei para o escritório da ImproveIT e falei com o Vinicius Telles. Ele certamente não se lembra disso. Perguntei sobre os cursos da empresa em XP, datas e preços. O que o Vinicius me falou na ocasião foi que não havia muita demanda para este tipo de curso e que por isso eles eram oferecidos muito esporadicamente ou apenas para empresas em turmas fechadas. Como eu falei que possuía um pequeno time e um orçamento de tamanho semelhante ele sugeriu que eu comprasse alguns livros e usasse listas de discussão.

Se eu precisasse de algo semelhante no Brasil hoje, não teria este problema. Não este, ao menos. O meu maior problema seria encontrar, no meio do mar de ofertas, quem contratar.

Apesar de estar relativamente afastado da comunidade brasileira –o que pode ser percebido pela falta de atualizações freqüentes aqui- eu acompanho listas e fóruns e pude ver como as coisas mudaram nos últimos meses. Listas de discussão sobre métodos ágeis foram invadidas por ofertas de treinamentos, cursos, coaching e mentoring. Algumas listas que eram bem interessantes viraram apenas um veículo para a divulgação de serviços.

E como aferir as credenciais dos prestadores de serviço? Boa pergunta. Algumas desta pessoas, segundo meu histórico do Gmail, estavam oferecendo cursos de levantamento de requisitos no melhor estilo waterfall há alguns meses. Outros possuem treinamentos cujo programa é apenas uma xerox do Certified Scrum Máster –se o treinamento de SCM original já possui valor real muito baixo imagina quando o mesmo conteúdo é ministrado por alguém que não possui a experiÊncia habitual dos CST.

Outros dizem que já trabalharam para 50,60…100 empresas com metodologias ágeis. Estes são meus favoritos. Supondo que o sujeito tenho começado a trabalhar com metodologias ágeis em 2001 -quando o Agile Manifesto foi assinado- e já passou em 50 empresas, ele teria passado apenas um mês em cada empresa, na média. Além do fato de que eu duvido que estes pratiquem técnicas ágeis desde 2001, em minha vida eu vi poucos projetos de apenas um mês que tenham sido relevância para o currículo de alguém. Como previsto, os agilistas retardatários estão em todo lugar, cuidado.

Existe um trecho do Phillip Krutchen no seu livro de RUP que eu acho que se aplica com perfeição para algumas coisas que eu tenho visto por aí:

A Major Misconception

Although the four phases of a RUP project (Inception, Elaboration, Construction, and Transition) are run sequentially, remember at all times that the RUP lifecycle is fundamentally iterative and risk-driven. There is a big misconception that we would like to push aside very early in our discussion: The various phases are not simply a renaming (to sound fancy or different) of the classical phases of a waterfall process. From practitioners making their first acquaintance with the RUP, we have frequently heard, “Oh, I get it! In Inception you do all the requirements, in Elaboration you do the high-level design, in Construction you write the code, and you finish the testing in Transition.”

In trying to match the RUP to their current practice, they completely miss the point of iterative development. Yes, in the early weeks or months of a project the emphasis is very likely to be more on requirements and during the final weeks or months to be more on testing and polishing. This change in focus across the lifecycle is precisely what is hinted at by the “humps” on the lifecycle iteration graph (see Figure 1.3); the height of the humps varies across the cycle. But inside each phase, you plan iterations (see how in Chapter 12), and each of these iterations includes many of the software development activities to produce tested code as an internal—and later external—release.

Muitas das pessoas que hoje oferecem serviços em métodos ágeis foram exatamente as mesmas pessoas que criaram toda a confusão sobre fases no RUP. Substituindo iterative por agile (que egloba desenvolvimento iterativo) em “In trying to match the RUP to their current practice, they completely miss the point of iterative development” vai ter exatamente o cenário atual.

Um exemplo disto é a forma como alumas pessoas tentam transformar XP em algo mítico e irreal. Em discussões recentes eu vi gente taxando o XP como inferior à coisas como Scrum porque ele “visão de negócios” ou “focada em engenharia”. Mas heim?

A parte da “engenharia” é engraçada. XP é uma metodologia para desenvolvimento de software e como de se esperar ela possui praticas que estão ligadas com… er… desenvolvimento de software!

E a paixão pelo Scrum é algo fantástico. Uma busca por “Scrum framework” no meu Gmail traz milhares de emails de listas de discussão. As pessoas adoram Scrum porque é um “framework para processo”. Muito flexível, muito pratico e te deixa adotar suas praticas de engenharia favoritas. O Scrum pode ser extremamente formal ou informal.

Uhm… onde é que eu vi isso antes?

The RUP is also a process product that provides you with a customizable process framework for software engineering. You can configure the RUP product to support small or large teams and disciplined or less-formal approaches to development. It also allows you to add your own best practices and to share experiences and artifacts with peers and experts.

O que talvez muita gente não perceba é que há sempre um jogo de compensação em metodologias ágeis. Os valores definidos no Manifesto Ágil não são facilmente atingíveis e as praticas do XP são uma forma (não necessariamente melhor ou pior) de atingi-los. Obviamente você consegue atingir os valores através de praticas diferentes mas o que eu vejo é a maioria das pessoas usando as mesmas praticas que já usavam antes, talvez com cartões ao invés de documentos Word, e esperando que seja diferente do passado.

Misturar praticas é algo sadio quando feito por alguém que entende como estas se relacionam, mas a maioria das pessoas apenas está jogando as que não entendem ou são difíceis de vender. Eu já estive em diversas empresas brasileiras onde “ágil” significava colocar cartões na parede e ficar em pé meia hora todo dia de manhã.

Mas o que eu quero dizer, que você não deve contratar pessoas para ajudar sua empresa a adotar método ágeis? De jeito nenhum. Apesar de não prestar serviços no mercado brasileiro meu trabalho consiste exatamente nisso, seria bem estranho eu advogar contra. Este texto é apenas um desabafo e um alerta.

Um alerta porque através de amigos e colegas eu já estou vendo muitas empresas jogando dinheiro fora com treinamento, consultoria e mentoring sendo prestados por pessoas que possuem pouca ou nenhuma experiência a mais que os próprios alunos.

Desabafo porque acho que finalmente entendi porque a ImproveIT saiu do mercado de consultoria e coaching.