Pratique AgileMMA e faça uma adoção pragmática e sistêmica de Agile

Quando um conceito é implementado de diferentes formas, torna-se natural que diferentes percepções sobre o mesmo sejam criadas pelas pessoas. Nesse aspecto, o paradigma ágil é imbatível, pois como trata-se de uma abordagem filosófica, muitas e diferentes percepções são geradas em torno do grande guarda-chuva conceitual que ele representa. Mas sem dúvida, essa pluralidade de percepções, faz do paradigma ágil, uma fascinante e complexa filosofia administrativa, econômica e até mesmo social dentro do universo do desenvolvimento de software.

Baseado nessa compreensão acerca de Agile, venho trabalhando há muito tempo em ajudar as pessoas a terem uma visão mais ampla sobre o paradigma Ágil. Esse trabalho tem sido pautado principalmente em propor uma abordagem não xiita sobre nenhuma das “sub-ideias” inerentes na agilidade.

Para disseminar essa pensamento, ao longo dos anos, escrevi diversos artigos, fiz diversas palestras e até mesmo lancei o “Manifesto for Meta-Agile”, que de maneira concisa, reúne algumas diretrizes básicas para ajudar as pessoas a meta-cognizarem sobre seus comportamentos, processos e ideias quando estiverem elaborando alguma solução ágil.

Contudo, talvez o conceito Meta-Agile seja complexo ou abstrato demais para muitas pessoas, por isso, para ajudar na materialização desse conceito, nos últimos meses tenho usado uma abordagem que chamei de AgileMMA – Agile Mixed Methodologies Adoption (estou usando o termo methodologies para resumir as ideias, processos, técnicas e frameworks existentes sobre a alcunha de Agile).

Apesar do nome de forte impacto, a AgileMMA não se trata apenas de uma forma de usar as metodologias ágeis de um jeito “misturado”, mas sim, uma implementação do Manifesto for Meta-Agile, que oferece uma visão sistêmica dos momentos e cenários apropriados para cada metodologia, de acordo com o contexto corporativo em questão.

AgileMMA também parte da idéia de que uma mente san, gera um processo san, por isso, a AgileMMA é fortemente baseada num processo de Coaching. Esse processo de Coaching ajuda os indivíduos a trabalharem de forma efetiva em uma espécie de octógono de pontos chaves dentro uma adoção de Agile, são eles:

* Propósito – Quais os motivadores para adotar Agile.

* Percepção de valor – Quais os valores que empresa acredita.

* Efeito sistêmico – Qual o efeito que será gerado em toda a organização.

* Ganhos – Quais os benefícios envolvidos.

* Perdas – O que a organização precisa “abrir mão” para poder adotar Agile.

* Competências – Quais as novas competências (conhecimentos, habilidades e atitudes) as pessoas precisam desenvolver.

* Opções – Quais a opções de metodologias, frameworks, processos, técnicas (existentes ou não) a organização poderia usar para ter resultados ágeis.

* Propriedade – Qual (ou quais) opção (ões) com os quais a empresa irá construir o seu jeito ágil de ser e, como ela pretende trilhar o seu caminho rumo a Agilidade.

Como é claramente percebido, o nome AgileMMA trás uma analogia muito forte ao MMA (Mixed Martial Arts) que todos conhecem, pois no MMA um lutador que for proficiente apenas num estilo de luta (ex: boxe, karatê, jiu-jitsu etc), vai ter sérios problemas para fazer uma boa luta, quando o adversário o conduzir para um contexto diferente de sua proficiência (ex: trocação, chão, submissão etc).

Assim também é o praticante de AgileMMA, pois hoje, a dinâmica dos mercados, faz com que as empresas mudem seu contexto de trabalho numa velocidade muito rápida, então se o profissional for xiita ou só souber trabalhar num formato específico de Agile (ex: Scrum, XP, FDD, Kanban etc), terá grandes problemas de usar a ferramenta mais adequada para uma determinada situação. Além disso, o agilista também terá uma enorme dificuldade em gerar bons resultados, se ele ater-se apenas à metodologias já conhecidas, ou trabalhar apenas com o jeito by-the-book de cada uma delas. Nesse caso, o agilista precisa ter uma razoável capacidade de desprendimento de suas próprias ideias e conhecimentos, pois muitas vezes ele precisará criar soluções contra-intuitivas até mesmo pelo ponto de vista do paradigma ágil.

O praticante de AgileMMA é um exímio conhecedor de como que as opções ágeis se integram quando necessário e, também é um perito em criar modelos de transição de uma opção para outra.

O praticante de AgileMMA conhece em detalhes os jogos políticos e as principais complexidades organizacionais que possam facilitar ou dificultar uma determinada opção ágil. Sobre essa questão, compete ao praticante de AgileMMA, entender e descobrir novas formas de fazer o paradigma ágil conviver saudavelmente com essas questões organizacionais e também com os demais paradigmas existentes na empresa (ex: modelos de governança, modelos de maturidade, PMBok etc).

Logo, ser praticante de AgileMMA não significa que o profissional irá trabalhar com todas as metodologias ágeis ao mesmo tempo, mais sim terá a visão sistêmica suficientemente adequada para saber em que momento mudar sua estratégia de trabalho, de forma a assegurar um bom resultado para a organização inteira.

É importante observar que a abordagem AgileMMA não impede o praticante ter a sua preferência, ou a opção de metodologia em que ele mais sente proficiência ao trabalhar. Inclusive essa preferência pode servir como uma importante base de aprendizado e de experimentação das demais metodologias.

Hoje tenho visto algumas boas iniciativas em direção da AgileMMA, pois freqüentemente tenho contato com organizações que já experimentaram diferentes metodologias e com os resultados dessas experiências, acabam por criar um jeito todo próprio de fazer a sua agilidade. É importante destacar que cada experiência AgileMMA é única e por muitas vezes, aquele jeito de fazer Agile apenas faz sentido para aquela organização que criou o mesmo.

Por isso, ser um praticante de AgileMMA é um meio bem eficaz para elevar o estado Meta-Agile de qualquer organização, para isso, é muito importante que os profissionais interessados em praticar a AgileMMA comecem a treinar sua quebra de dogmas, abrir mão das posturas xiitas e principalmente, comecem a pensar recursivamente fora da caixa.

Portanto caro amigo agilista, Hajimê!!!




Sobre o autor:

Manoel Pimentel Medeiros (www.ica-ti.com.br) – Coach com mais de 15 anos de experiência na área de TI, onde atuou com Coaching e Trainning para executivos e times em ambientes organizacionais de Consultorias, Bancos e Telecom. É Diretor Executivo do ICA-TI (Instituto de Coaching Aplicado a TI) e fundador da Revista Visão Ágil, já escreveu sobre Agile e Coaching para portais e revistas do Brasil e exterior. Também palestrou em eventos nacionais e internacionais sobre agilidade. Possui as certificações PPC, CAC, CEC da SBC/BCI, Worth Ethic Corporation, CSM e CSP da Scrum Alliance e foi um dos pioneiros na utilização e divulgação de métodos ágeis no Brasil.

Convencer é melhor do que impor

Em tempos de agile, tem algumas coisas que são um pouco difíceis de algumas pessoas/times adorarem como prática. Por exemplo: como fazer com que desenvolvedores façam testes automatizados, de preferência usando a abordagem TDD? Pode parecer fácil, mas só quem já tentou sabe como é difícil e como existe resistência na quebra do paradigma.

Pra resolver o problema temos basicamente 2 opções: (1) Alguém obriga todos do time a fazer os testes automatizados e ponto final, ou (2) utilizar-se de algum método que os convença que essa prática trás ganhos significativos.

Continue reading

Projeto Ágil, de Nível Nacional e no Governo! O Case Encceja.

É verdade! E não é que os tempos estão mudando mesmo? No último dia 06 de outubro, entrou no ar o Encceja: Exame Nacional para Certificação de Competências de Jovens e Adultos. Ou, da forma mais fácil como nos descreveram, tipo um supletivão do governo.

Nossa história com o projeto começou quando eu e o Bruno fomos chamados pelo Fábio Petrillo, Coordenador Geral de Sistemas de Informação do INEP para ajudarmos o pessoal a trabalhar com Metodologias Ágeis. Não houve esforço nenhum para o Petrillo comprar a idéia, pois ele já acreditava em Agile e já tinha trabalhado com isso antes. Já leu os livros que eu li, os que você já leu e mais um monte que a gente nem ouviu falar ainda. É um cara que sabe das coisas.

O desafio pra gente era com a equipe, pois não seria legal chegar com “pose” de consultor pedindo pra eles fazerem as coisas de uma forma completamente diferente e depois ir embora deixando eles com o pepino na mão. Eles tinham que ver muito rápido benefícios nas práticas adotadas, e ver que estávamos do lado deles, senão a consultoria e o projeto iam afundar. Não sabíamos por qual prática começar, nem como abordar o pessoal.

Restavam 11 semanas de projeto e o prazo não era negociável por força de lei. A equipe começou com Danielzim, Cláudio Alberto e Sandro. Depois entraram Robert (JBoi Seam), Vitor e Kelly.
O desafio inicial era enorme. O projeto já tinha um módulo administrativo funcionando, com algumas fraquezas, e tínhamos que migrar o banco, desenvolver a inscrição web e refazer o módulo administrativo. Ao longo do projeto, a idéia da migração do banco e do redesenvolvimento do módulo administrativo foram abandonados. Ainda bem! A inscrição web já tinha por si suficientes desafios. Tinha que resolver diversos problemas legados de outras inscrições.

Cláudio Alberto pilotando o sistema apresentado pela equipe, para dar feedback ao cliente. Atrás: Bruno, Vitor, Petrillo, Robert e Daniel

Começamos levantando tudo em estórias e planejando iterativamente. A equipe tem muito mérito pois absorveu as práticas de forma surpreendentemente rápida. Também são muito habilidosos e desenvolveram as coisas bem rápido. No começo eu e o Bruno achamos as estimativas otimistas demais, que acabariam se frustrando, mas eles conseguiam cumpri-las muito bem. Havia receios por parte deles em relação à não utilização de casos de uso com toda descrição do sistema. Acredito que há até hoje! :o )

O Kanban começou numa porta de armário. Falta de espaço não pode servir de desculpa pra não começarmos a utilizá-lo. Depois foi pra um quadro chique, com product burndown e tudo mais.

Ao longo do projeto, o Cláudio foi fazendo a interface com o cliente a cada versão gerada e também levantava casos de teste, pois o cliente tinha restrições em estar presente. O feedback gerou diversas alterações que melhoraram bastante o sistema e também permitiram que escopo fosse cortado dessa release. Foi bom pra todos. O pessoal desenvolveu testes automatizados e também se ajudou em pares. Inclusive, pra eles isso foi um ponto forte destacado: a integração da equipe de desenvolvimento.

Par que nada, esta foi uma triple do pessoal, pra resolver problemas na automação de testes.

Uma das últimas stand-up meetings do projeto, falando dos testes e ajustes finais.

Após o sistema entrar em produção, a equipe já estava gerando versões com naturalidade e confiança pra ir corrigindo detalhes e disponibilizando versões a cada dia – graças às builds semanais. Na última visita que fizemos a eles, dia 8, já havia cerca de 20 mil inscritos (Rodando no JBoss – cha chim!!$$$), e consideramos o projeto um grande case de sucesso com agile.

Claro que ainda há muito o que aprender, aliás, essa é a moral da história: sempre há! Agora o desafio é espalhar a cultura no resto do departamento. Já sabemos que outro projeto vai começar a adotar metodologias ágeis, o Enem. Em breve, de um jeito ou de outro, todos acompanharemos os resultados – acredito que seja com muita alegria, como no case do Encceja.

Abraço a todos, parabéns ao INEP pela coragem e parabéns à equipe pelo ótimo trabalho!!!
Willi

Descobrindo as Metodologias Ágeis

Para iniciar os artigos no Blog Visão Ágil, eu gostaria de relatar um pouco da minha experiência com desenvolvimento de software e sua relação com as Metodologias Ágeis. Descobri o desenvolvimento de software por acaso, através de um curso profissionalizante Técnico em Processamento de Dados (TPD) que iniciei em 1993, seguindo alguns amigos. No início, eu não estava muito interessado, até conhecer o universo da Programação. Descobri que aquilo me fascinava e, de certa forma, me desafiava também. Comecei a fazer fluxogramas, algoritmos até o meu primeiro programa em BASIC. Aquela experiência foi decisiva para a definição da minha carreira profissional.

Dali em diante, depois do uso de quase duas dezenas de linguagens de programação, alguns cursos e muito aprendizado e softwares desenvolvidos, estou aqui para compartilhar com vocês um pouco destas experiências.

A primeira e mais inusitada foi a descoberta das metodologias ágeis. Em 1996, eu era bolsista em uma Universidade, tinha entrado no Curso Superior, cheio de expectativas e anseios. No setor onde trabalhava (Assessoria Especial de Planejamento/Apoio Técnico Pedagógico), basicamente digitava textos. Em horários de folga, estudava novas tecnologias e procurava novos desafios. Em outubro deste mesmo ano, vi que os chefes do setor criaram uma espécie de questionário de avaliação, denominado Avaliação Institucional, que seria aplicado a professores e alunos. Esta era também uma exigência do MEC.

Quando olhei aqueles formulários, pensei diretamente no desenvolvimento do software. Muita empolgação, pouca experiência…

Inicialmente, este projeto seria desenvolvido pelo CPD da Instituição, onde trabalhavam grande parte dos professores. Quando disse que tinha condições de desenvolver o projeto, os chefes ficaram apreensivos, mas compraram a idéia. Para iniciar o projeto, precisei chamar um colega meu de TPD e de faculdade, que poderia trabalhar meio turno comigo. Fizemos uma reunião inicial com o coordenador do projeto (chefe do CPD) e conversas diárias com os chefes do setor de Planejamento.

A minha sala era muito pequena, razão pela qual tinha apenas uma máquina (486 DX2 66 Mhz) e uma impressora matricial IBM 132 colunas. Combinei com este meu colega de trabalharmos juntos pela manhã no projeto e a tarde eu desenvolvia mais algumas funções do software além do trabalho do setor, que não podia parar.

A tecnologia que utilizamos na época era Clipper, versão 5.2.

Pegamos aqueles formulários e após algumas análises preliminares, conseguimos esboçar um modelo conceitual. Como havia apenas um computador, trabalhamos juntos, ora eu pilotando, ora ele. Tivemos que realizar alguns trabalhos de importação, parte da base COBOL da Instituição e outra parte de uma base ZIM, do Recursos Humanos.

Foi muito interessante o nosso aprendizado, pois conseguimos produzir um código muito enxuto, cada vez mais otimizado e sem gerar desperdício, pois o cliente estava ali na sala ao lado para acompanhar e direcionar as funcionalidades do projeto. Cada vez que percebíamos uma oportunidade de melhoria, realizávamos. Procurávamos ter versões diárias, sempre verificando e validando informações com os usuários/clientes. Concluímos esta versão em dois meses. A primeira versão compreendia funcionalidades básicas de operação e módulo de digitação para professores e alunos. Ficou para depois o desenvolvimento de relatórios gerenciais, até porque o pessoal do setor não os tinha definido. Este software funcionou em 8 Campi Universitários, fazendo o registro de questionários de mais de 9 mil alunos. Nos anos seguintes, exigiu pouquíssima manutenção.

Até onde sei, este sistema funcionou até 2002, pois saí da Instituição em 2000.

Algumas práticas importantes:

·         Comunicação efetiva

·         Padrões nas práticas de trabalho e de codificação

·         Pair Programming

·         Inspeções/Revisões de Código

·         Cliente presente

·         Projeto simplificado ao extremo

Em 1997, comecei a trabalhar com OO e Smalltalk. Programei por dois anos nesta linguagem, onde tomei conhecimento de alguns trabalhos e pessoas envolvidas com a tecnologia, entre eles o de Kent Beck.

Passaram-se alguns anos e, em 2001, através de conversas com o Klaus Wuestefeld, fiquei sabendo um pouco mais sobre eXtreme Programming. Quando vi o nome de Kent Beck e qual era o objetivo deste processo, tive certeza que funcionava. Foi paixão a primeira leitura. Quanto mais eu estudava, mais eu lembrava do projeto de Avaliação Institucional que, através do sucesso obtido e da satisfação do cliente, foi um degrau muito importante na minha vida. Embora já tivesse estas convicções, decidi que iria desenvolver software focado na comunicação efetiva, simplicidade, feedback e respeito do cliente, tendo como base os princípios ágeis.

Entrevista com Cicero Torteli, fundador da Paggo

Acabo de chegar de São Paulo, onde participei da TDC 2008. O evento foi muito legal. Tive a oportunidade de rever vários amigos, entre eles o Cicero Torteli, fundador da Paggo, que falou sobre a adoção do Extreme Programming por lá:

Ainda sobre a Paggo, escute também o podcast que gravamos há algum tempo com Maurício Hermógenes, Diretor de Tecnologia da Paggo.

Há várias outras entrevistas que foram gravadas na TDC 2008, com vários colegas aqui do blog Visão Ágil, tais como o Manoel, o Papo, Ricardo, Felipe, Rodrigo e meu amigão, Juan Bernabó. Em breve, estarão disponíveis aqui também.