É muito fácil defender RUP hoje em dia depois de toda evolução do mercado [que diga-se de passagem o RUP só ajudou sendo a antítese do caminho correto], duvido que esses 3 únicos caras que supostamente conhecem a pedra filosofal do RUP fizessem o que fazem [ou devem fazer] hoje antes desses últimos 15 anos de discussão e experimento ágil.

É difícil imaginar que Kent Beck, Martin Fowler e tantos outros que começaram a propagar o agilismo após o manifesto ágil não conhececem RUP a ponto de,  como os defensores atuais do RUP afirmam: “renomearam práticas antigas com nomes novos”.

Meus caros, práticas não são o coração do agilismo, são os valores e princípios. RUP sempre valorizou os itens à direita em detrimento aos itens à esquerda no manifesto ágil, então não me venham com essa de que seguir o plano nunca foi prioritário do RUP. RUP é uma metodologia que não deu certo porque foi uma tentativa de taylorizar o desenvolvimento de software.

ps. Notaram que não linkei nada? Preguiça de responder esse tipo de coisa.

O que diferencia esses processos não são as práticas, são os valores. O problema é que entender, compreender e adotar valores é algo subjetivo que varia de pessoa para pessoa por mais que se tenha princípios bem definidos que conectem as práticas a esses valores.

Diante disso, nenhum processo garante que seu projeto será um sucesso por estar o seguindo, mesmo que seja “By The Book”.

Há uma preocupação com o chamado Scrumbut, mas eu já vejo e vi projetos Scrum que não são Scrumbut e mesmo assim o software produzido, por mais ágil que seja, não tem qualidade e no primeiro refactoring você já entra no prejuízo similar a um software desenvolvido em Cascata.

Fato é que esses valores e princípios não garantem software com código coeso, desacoplado, limpo, claro e facilmente lido, ou seja, com qualidade interna.

Hoje minha preocupação em todos os projetos é a qualidade interna do software, não importa que metodologia seja adotada. Qualidade interna garante que o software tem boa saúde e é fácil de ser medida.

Saúde do software é o quão rápido e efetivo ele se recupera de mudanças e o quão limpo ele está de defeitos. Para se recuperar de mudanças o software precisa ser limpo e claro, ser facilmente entendível e lido.

Livre de defeitos é ter uma cobertura de testes que explorem e machuquem o código até descobrir falhas que passam despercebidas.

A grande maioria dos processos se preocupa mais com a qualidade externa do que a interna. Não importa se você faz reuniões em pé, tenha o cliente presente ou faça Scrumban ou até mesmo que você esteja entregando software rápido, nada disso vai garantir qualidade e que não vá ter prejuízo no futuro.

Vender qualidade externa tem um apelo comercial fácil porque você não precisa comprovar a qualidade do software e sim do processo, o discurso é sempre mais elegante do que falar em código, principalmente para alta gerência e burocratas, tanto é que todos os modelos de qualidade reconhecidos avaliam o processo e não o produto.

CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto.

Um exemplo de qualidade interna de um software são os testes automáticos em suas diversas nuances como unitários, aceitação, integração e funcional, mas não apenas isso, métricas de coesão, cobertura, LOC, complexidade e tantas outras.

No Maré de Agilidade eu fiz questão de enfatizar:

“Não importa que processo você siga, se é ágil ou não, se você não faz testes de Software vocês está errado em todos.”

Não existe um software sem bateria de testes automáticos com qualidade, isso é lenda. Em mais de 10 anos de profissão o que tenho notado é que a grande maioria, senão todos, são fortemente acoplados e de baixa coesão como consequência da falta de testes. Aplicar testes nesses softwares é uma tarefa quase impossível e proibitiva em relação a custos, sai mais barato fazer um software novo.

Outra coisa que falei no Maré de Agilidade foi:

“Não seja ágil, seja o melhor possível, porque ao procurar ser o melhor você invariavelmente vai se deparar com práticas que o tornam melhor e aí você se tornará ágil”.

Assim como o lema da Rossi: “Armas não matam pessoas, pessoas matam pessoas” podemos induzir que: Processos não desenvolvem software, pessoas desenvolvem software!

Ao trabalhar com pessoas, precisamos entender que modelos de negócios como software são de terceira onda [Alvin Toffler aqui] e não da segunda onda [industrialismo]. Qualquer analogia com modelos de segunda onda provocará insuficiência no trabalho dessas pessoas [por isso Lean faz tanto sucesso hoje] e elas precisam estarem motivadas para produzir qualidade interna, coisa que o trabalho sobre qualidade externa não produz.

Esse tema sobre pessoas e processos [como homem/hora] será escrito em outro artigo.

Resumo desse artigo é: Pessoas são responsáveis por produzirem qualidade interna ao produto e não processo, invista nelas.

Ontem começou o Maré de Agilidade com o curso RR11 de Ruby on Rails da Caelum com o Fábio Kung, que não precisa de apresentações [se você não sabe quem é Fábio Kung então mude de profissão].

Como o Kung está indo integrar o time da Locaweb, [apesar de continuar como instrutor na Caelum] essa é a última oportunidade de tê-lo conosco para ministrar esse curso, a turma foi agraciada com a sorte.

Na quinta e na sexta acontecerão os minicursos oficiais do Maré de Agilidade com o Manoel Pimentel da Visão Ágil e a turma da empresa SEA Tecnologia [ Renato Willi, Bruno Pedroso e Alexandre Gomes], ambos organizadores do evento.

No sábado acontecerão as palestras com todos que ministraram/rão cursos além de Clavius Tales, Fabiano Milani da Adaptworks e um tal de Christiano Milfont.

Todos os minicursos estão com vagas esgotadas, se você quiser ainda participar do Maré de Agilidade, corra para a inscrição das palestras enquanto há tempo.

Para finalizar o Maré, a Adaptworks promove o curso “Planejamento e estimativas em projetos ágeis”, através do telefone (11)5585-7738 ou pelo e-mail contato@adaptworks.com.br na sede do CGDT.

Um grande problema na compreensão sobre Scrum é justamente achar que ele serve para gerenciar projetos, dessa forma para ser confundido com um PMBOK ágil é um passo. Gerência de projetos é um campo distinto da direção do desenvolvimento de software e não vou tratar ou especificar nesse artigo porque já rascunhei em artigo passado.

Scrum é um modelo de desenvolvimento de software. A Scrum Alliance que é uma espécie de “organismo” que rege a maturação do Scrum, não o definiu como Project Management, mas como:

“Scrum is an agile software development framework.“

Scrum é similar ao XP ou FDD, guia a equipe com um modelo baseado em práticas para um melhor desenvolvimento de software. Como esse pessoal – que muitas vezes nunca foram técnicos – encontra em Scrum práticas fortemente ligadas ao controle das iterações, transmuta toda a cultura burocrática adquirida em metodologias de gerência de projetos e confunde atividades – como avaliação de riscos e aquisição e controle de recursos – com as necessidades do time jogando fora o que os incomoda – como práticas necessárias ao desenvolvimento – e ficando apenas com o que sentem confortáveis.

Quando James Shore escreveu seu famoso artigo “The Decline and Fall of Agile” ele definiu isso muito bem fazendo analogia que estavam correndo para a sobremesa mas jogando fora os vegetais. Martin Fowler em seu artigo Flaccid Scrum [Akita traduziu e comentou], escreveu ter notado que o problema técnico acontece mais com Scrum devido a não prescrição [omite] de práticas técnicas e ser centrado em técnicas de “gerenciamento de projetos”, ou seja, o problema é de qualidade técnica interna.

Hoje todo mundo se diz Scrum Master, todos entendem e usam Scrum e mesmo assim já estamos vendo projetos com Scrum caírem no mesmo erro e problema de modelos anteriores. Como disse o Martin Fowler em seu artigo: “Esses projetos de Scrum flácido em andamento prejudicarão a reputação não somente do Scrum mas de todo Agile”.

Scrum é uma metodologia maravilhosa que tem muito a engrandecer o XP e as outras metodologias, mas usando um Scrum transviado de PMBOK é um caminho natural ao fracasso retumbante.

Solução?

Eu poderia escrever dezenas de linhas aqui com conselhos e bla-bla-blas mas vou ser direto e lacônico: XP.

A lista tem menos de um mês e já conta com cerca de 120 membros e uma boa movimentação, por volta de 500 emails, se mantivermos essa média seremos uma das mais movimentadas do Brasil.

A idéia é fortalecer o XP, mas não em detrimento de outras metodologias ágeis, pelo contrário, teremos sempre o prazer em discutir e divulgar outras iniciativas.

Mas XP?

Sim, XP porque tenho um carinho especial e por considerar que é a metodologia mais madura no Ceará.

Segundo dados do artigo do João Barros [membro do grupo], XP aparece empatado com Scrum com 30% de adoção, mas as experiências públicas mais conhecidas e profissionais mais experientes são com XP. Destaque para a Fortes Informática e o Clavius Tales – confiram esse Podcast com ele.

Nada impede discussões sobre outra metodologias, lembrando somente que o foco é XP. Se criqrem outros grupos eu terei o prazer de participar também, só não tenho tempo para administrar e focar várias iniciativas e pessoalmente prefiro XP por motivos que ficarão para um post futuro.

É interessante observar no artigo do João que já há uma crescente adoção por parte das principais empresas do Ceará – ele listou 24 das mais conhecidas e importantes do estado. Todo trabalho de pesquisa é uma fotografia de um momento e nos fornecem estatísticas de avaliação, pode parecer alguns dados muito otimistas, mas precisamos ter uma base para trabalhar as ações e direcionar os esforços.

É impressionante como o XP sem divulgação e apelo de marketing conseguiu empatar com Scrum e com modelos mistos cada qual com 30%. Outro fato interessante é a baixa representação de outros modelos fora Scrum e XP.

Porque do Ceará?

O Anderson Fabiano fez uma pergunta pertinente no twitter:

@cmilfont me juntei ao grupo. perguntinha basica: qual o ponto de limitar o grupo geograficamente (ce) na era da internet?12:42 PM Feb 16th from web in reply to cmilfont

E ele mesmo deu uma boa definição:

@cmilfont saquei. +- o principio do craigslist (de 4 anos atras)… limitar para conquistar 12:48 PM Feb 16th from web in reply to cmilfont

Tenho notado que grupos menores e com pessoas que se conhecem tem melhores discussões porque inibe mais flamewars e ataques pessoais devido ao conhecimento do “humor” nos emails de caras conhecidas.

Criar uma lista exclusiva e focada no estado ajuda a direcionar esforços, não só discussões. Um dos grandes objetivos da lista – grupo- é fortalecer a adoção de XP e para tanto organizaremos eventos e pesquisas nesse intuito.

Já dei início ao censo ágil de 2009 com um questionário para colher informações macros sobre adoção de metodologias ágeis, após essa primeira pesquisa entrerei mais a fundo em questões específicas. A idéia é realizar um censo a cada semestre.

Enfim, vale a pena a participação mesmo de quem não é do estado, as discussões estão “quentes” e boas.

Riscando os cavalos!
Tinindo as esporas!
Través das coxilhas!
Sai de meus pagos em louca arrancada!
— Pra quê?
— Pra nada!

Poema Gaúcho do poeta pernambucano Ascenso Ferreira.

O SEI publicou uma nota sobre CMMi e Agile e causou um certo frisson em membros de “listas de discussões agiles”.

O que muda? nada, absolutamente nada. Pelo menos para o mundo agile continua a mesma coisa, não só temos de lutar contra o mundo de terno como o pessoal do Jeans já está lutando entre si.

O SEI está vendo que perdeu a batalha e agora quer liderar essa nova “era agile”.

Agile é possivel com CMMi?

Nunca, porque a cultura deles valoriza mais os itens a direita do manifesto ágil, é da essência.

Mas vão tentar especificar um “burro”, podem ter certeza.

A mistura de um jumento[jumenta] com cavalo[égua] nasce um burro[mula], ser híbrido mas ESTÉRIL. Muito bom para trabalhos pesados [já que o jumento tem resistencia] e com mais velocidade [que o cavalo possui] mas que não pode gerar filhos. A mesma analogia pode ser aplicada a mistura de duas culturas antagônicas.

Quem promove essas bobagens são charlatões que saíram do mundo do terno e caíram no mundo do Jeans por pressão e querem se sentir com capacidade de liderar novamente, para isso precisam controlar e guiar a cultura do Jeans já que é contra sua essência assumir que um “Recurso Humano” [que para nós se chama gente ou pessoa] tem mais valor do que um processo por exemplo.

Essa turma não consegue entender a cultura que propiciou o manifesto ágil e abraçou – desvirtuando – alguns métodos, entre eles o Scrum, que apelidei desde o ano passado de “RUP de Jeans”.

Observe que o software funcionando foi abandonado em prol do discurso de “gestão”, “venda da imagem”, “governabilidade” e todas as Buzzwords importadas – [trazidas?] – do mundo de terno.

XP é radical

Noto que o pessoal FuDiDo está em luta aberta contra o XP, tudo bem que FDD sempre esteve à sombra até do Scrum, mas esse tipo de abordagem é idiota e irracional, com argumentos do tipo: “XP é um nome agressivo”, “Práticas de engenharia do XP são restritivas e difíceis de adotar”, “XP não tem governança de projeto”, “XP não tem controle de riscos, prazos”, “Whatever”.

Idiotice tem limites e todos os limites já estão estourados. Esse tipo de argumentação é somada com os preconceitos clássicos de que: “agile não dá certo em projetos grandes”, “equipes remotas perdem toda a comunicação”, “não tem documentação”, “é anarquia”, … e se confundem.

Essa nota do SEI me lembrou da Questão Christie, o que eles querem? Um pedido de desculpas por terem enterrado sua cultura na lata do lixo da história? Vão impor sua força para controlar o mundico agile?

Ágil não dava errado em projetos grandes? As falácias estão perdendo força?

Vamos esperar qual o próximo capítulo.

Já escrevi muito sobre isso em posts passados. O Vinícius da ImproveIt escreveu sobre o assunto também.

Resumindo minhas considerações eu tenho a certeza de que certificações são apenas um apelo comercial de marketing pessoal ou de diferenciamento em licitações. Para as empresas é muito cômodo contratar com parâmetros estáveis de análise de currículo como certificações e nível superior, mas não é seguro.

Sou da opinião do Phillip Calçado que não devemos promover as certificações além do que elas representam criando um efeito artificial sobre a realidade. Como não é seguro contratar alguem por causa da certificação, é dever moral e ético de profissionais trabalharem para evitar essa promoção das certificações como algo sério.

Concordo com o Alexandre Magno de que é difícil entrar nas corporações sem um apelo “marketologico”, as certificações seria o cartão de visita para você passar da porta, mas o que tenho visto é depois que se senta de frente do CEO as certificações continuam como algo sério como se fosse realmente um diferencial, o que não é verdade.

Eu nunca dei muita bola para certificações, mas estou pensando seriamente em tirar algumas porque a IVIA (sócia do Tuangr onde trabalho) tem uma política de reembolsar os funcionários que se certificam. Isso é bom para a empresa que tem moeda para competir nas licitações e bom para os profissionais que entopem o currículo de graça com algo que o mercado erroneamente considera fundamental, fora isso não há motivo algum para alguém pagar caro por uma certificação.

[update 28/05/2008]

O Shoes blogou sobre essa thread.

[/update]