Medos e argumentações sobre o uso de Agile

Em todas as pesquisas sobre projetos é possível observar o crescimento no uso de Métodos Ágeis por empresas de diferentes segmentos e portes, nacionais e globais. Mas, reaparecem em todas elas alguns mitos e angústias que merecem ser debatidos, em especial aqueles relacionados às maiores dúvidas e restrições percebidas por executivos e profissionais.

No estudo feito pela galera do grupo de estudos em Métodos Ágeis da USP, replicando aqui no Brasil em 2012 a mesma pesquisa realizada anualmente pela Version One a oito anos. É possível extrair e debater um pacote de preocupações comumente externadas por executivos e profissionais:

motivos para não adotar agile - brasil

Antes de mais nada, vamos balizar que tipo de projeto estamos debatendo, são os 85% de projetos de software mais comuns, não é a implementação tipo IN ou serviço de integração, que baseia-se exclusivamente em questões técnicas 100% mapeáveis e previsíveis com antecedência. Vamos focar em projetos médios, aqueles mais comuns, deixemos os nanicos e gigantes para outro fórum, Ok.

A seguir faço uma reflexão a partir de minha experiência, quer em projetos tradicionais como GP ou como Scrum Master em Equipes Ágeis, mas trata-se apenas de minhas experiências, crenças e valores, não são dogmas e podem ser ou não rebatidas por quem possui outras experiências e valores … No stress!

50,6% – Falta de documentação?

No caso do Scrum, levantamos e entendemos o todo em dinâmicas colaborativas como User Story Mappings. Identificamos a relevância e cronologia de todos os requisitos, sonhos, pretensões, primeiro temos um mapa visual de tudo o que se quer e precisa fazer. Não existe uma receita simples para a partir dai estabelecer a ordem e necessidade daquilo que deve ser detalhado para cada Sprint, a única forma de saber é fazendo, aprendendo e melhorando no seguinte.

A partir deste mapa, parte-se para detalhar de forma iterativo-incremental, seguindo a cadência do projeto, em camadas, como em um repolho, mas a estratégia e documentação são vivas, atualizadas a cada novo ciclo. A ordem é um misto de relevância, pré-requisitos e oportunidade. O resultado é documentação mais assertiva e de maior qualidade (User Stories). Não tentamos detalhar itens secundários ou menos relevantes, que serão feitos dali a meses e muito provavelmente devem mudar até entregarmos o mais importante.

Quanto a documentação mais técnica, ela é complementada com boas práticas de engenharia ágil como as de XP, com auto-documentação, investimento em paterns, em padrões permanentemente coletivizados e garantidos através de boas práticas em qualidade de código via componentização, serviços, OOP, testes unitários, pair reviews, pair programming, dojos, linguagem ubiqua, seguindo os mesmos preceitos do tático, com MVP e eliminação de desperdício.

Tenho 30 anos de mercado, documentação gera diferentes percepções no time, um diretor vê 300 folhas de detalhamento e fica feliz, insanamente seguro, o gerente de projetos vê ali trabalho, centenas de horas para manter minimamente atualizados, a equipe de desenvolvimento pode usar os diagramas e artefatos que mais lhe agreguem, especialmente com as regras de negócio, mas sempre recorrerão mesmo ao software, que se bem escrito será o seu melhor amigo.

43,8% – Falta de previsibilidade?

O que é previsibilidade? Se é achar que sabe o que será feito daqui a 4 meses, saber com 4 meses de antecedência quais os detalhes de certo relatório, saber 4 meses antes todos os detalhes das N telas do sistema … você está se enganando!

O senso de conforto e tranquilidade neste caso é habitualmente inútil e muito oneroso, o fato é que você está investindo centenas de horas tentando detalhar coisas menos importantes, o usuário mudará sua percepção e certezas na medida em que o projeto avançar e validar seus pressupostos e percepções.

Em Agile há uma dinâmicas inicial de mapeamento do todo, dimensionamos a complexidade e tamanho de forma a negociar tempo, custos, tamanho da equipe e investimentos. O pressuposto essencial é a confiança (*) no conhecimento e experiência naquele tipo de produto e tecnologia, assim eles dimensionarão com razoável sucesso o tempo total, dimensionam a equipe e metodologia desejada.

(*) Se você tem uma equipe inexperiente ou sem um mínimo de confiança e comprometimento, errarão feio em qualquer metodologia e no máximo servirá de experiência para o próximo projeto, independente de ser Waterfall ou Agile.

41,0% – Falta de planejamento prévio?

Devem ser os mesmos que reclamam da “falta de previsibilidade” e “falta de documentação” … acho curioso como as pessoas preferem a falsa ilusão de que está tudo previsto e dará certo, mesmo com a provável experiência de que a única certeza é que software são projetos complexos e se ajustam no caminho. PMI, Chaos Report, Ambisoft, todos os estudo das últimas décadas mostram que não são os seus projetos, a maioria dos projetos do mundo estouram os planos.

O planejamento deve ter balizas de tempo, custo, escopo inicial e qualidade desejada, mas tudo isso apoiado no objetivo de garantir o máximo de valor. Se o projeto se basear no fato que a estratégia definida e o mapa de requisitos trabalhado apontaram para uma equipe de X integrantes que trabalhará Y meses a um custo de Z reais. O próprio cliente participará nas decisões e vendo o produto surgir iterativamente irá referendar ou não aquele escopo inicial.

Mas precisa sim ter confiança na contratação das pessoas e nomear keyusers com tempo para acompanhamento, compatíveis com a importância do projeto … Desenvolvimento de software não é uma competição, os melhores resultados vem de equipes mistas e comprometidas com o produto, se você não acredita nisso e acha que NÃO está rasgando dinheiro, continue assim e boa sorte!

37,3% – Perda de controle gerencial?

Por quê? Você pode ao redor das equipes ágeis, manter um olhar gerencial, mas não com foco em preditividade, mas pode ter um gerente dedicado a extrair relatórios formais do andamento junto a equipe, cliente e usuários. Não precisa demitir ninguém, ele não terá hierarquia sobre a equipe, mas pode dar um apoio valioso ao cliente nas suas decisões diárias em cada Sprint. Se não está claro em como implementar, leia o livro sobre SCRUM e PMBOK do GP e Agilista Fábio Cruz de Florianópolis, Santa Catarina.

34,5% – Falta de capacitação do time?

Não tenho a menor idéia do que esse tópico está fazendo aqui, mas mostra um grande desconhecimento das responsabilidades organizacionais. Gestão por competências, Gestão do conhecimento, treinamentos técnicos formais, tudo isso independe da metodologia praticada.

Mas, posso dizer sem medo de errar que equipes ágeis tem muito mais foco em disseminação de conhecimento, boas práticas, multi-disciplinaridade, usando técnicas como peer review,  pair programming, dojos técnicos e de business, hackatonas, capacitando as equipes a conhecer e colaborar mais, de forma mais racional, orgânica e sustentável.

Os pais da gestão do conhecimento são Nonaka e Takeuchi, os mesmos pais do Scrum, Zarifian em 1999 contextualizou o que chamou de Objetivo por Competências com bases idênticas aos métodos ágeis, a teoria da empresa baseada em conhecimento também teve contribuições de Nonaka e Choo. O método XP é integralmente baseado na capacitação, multi-disciplinaridade, estabelecimento de padrões e qualidade em design de software e produto.

32,2% – Falta de planejamento antecipado?

Lá vamos nós novamente, as pessoas querem garantias, planos detalhados, anos e anos de sobre-custos e perda de controle no modelo vigente, onde projetos dão errado porque os requisitos mudam e as pessoas não aprendem que gastam fortunas tentando prever tudo e depois mais tempo ainda discutindo o plano rasgado. Quer saber, a maioria nem sabe calcular o ROI de seus projetos.

A culpa sempre é da equipe, é do cliente, é do papa, e como sei que a culpa poderá ser minha eu coloco uma margem gigante, o projeto custa o dobro, pois sei que é uma competição e que pode sobrar para mim, acabo mais preocupado com a forma que com o conteúdo.

Planos tentam ser usados como garantia, rapidamente esquecemos o business e focamos no contrato, cada lado tentando safar o seu quinhão. Quebra-se os pratos com um fornecedor e passa-se para outro, até não sobrar nenhum e retornamos ao primeiro. Se for equipe interna é muito pior, pois culpa-se alguém, cria-se um ambiente de terror e tudo recomeça no próximo projeto.

32,0% – Time resistir a mudança?

Sim, 100% de acordo, trabalhar com a colaboração de cliente, usuário, equipe, terceiros, sempre com foco em algo que gere orgulho em ter sido o melhor possível exige uma reprogramação mental intensa, demanda tempo para estabelecer um novo padrão, menos predatório e mais baseado em confiança.

O modelo preditivo atual é muito conveniente, sempre dá errado, sempre acaba em bate-boca, sempre alguém foi o culpado, mas como no fundo sabemos que este teatro todo é porque de fato software são complexos e não temos total domínio do que planejamos, acaba sempre ficando o dito pelo não dito … todo mundo magoadinhos, mas dali a pouco começam outro embate do zero, tudo de novo, com a maior cara de pau. Ou é isso ou dei muito azar nos últimos 30 anos.

Em maior ou menor escala, contratos com planos detalhando meses de trabalho geram grandes ilusões e expectativas, depois é uma corrida desenfreada para entregar o mais rápido possível, nos livrarmos do abacaxi, porque as mudanças são inevitáveis, assim como as responsabilizações e a quebra de pratos

25,8% – Falta de disciplina de engenharia?

Quac! O que quer dizer isso? Métodos ágeis não impedem absolutamente nada de acontecer, bom ou ruim, a diferença é que a equipe vai apontar o desperdício eventualmente feito só para satisfazer as aparências e que gerarão dívida técnica ou ônus no futuro. Isso só gera maior consciência e menos alienação.

Disciplina técnica diz respeito a padrões, a OOA, OOP, TDD, está relacionada a muitas coisas que a galera não pratica ou apenas um ou dois praticam e que gera uma colcha de retalhos nos sistemas, com módulos nos trinques e outros candidatos a lixeira. Muitas das técnicas do XP expõem estas idiossincrasias e forçam as equipes a definirem boas práticas e nivelam a qualidade e padrões.

Mas pode ser querer tentar modelar todo o banco antecipadamente, querer usar UML e modelar todo o sistema antecipadamente, OK, faça, mas prepare-se para ter a maturidade de gastar tempo para arrumar ao invés de só ir incluindo as mudanças e onerando com tabelas, índices, campos, componentes, atributos, etc, que caducaram e que só oneram, isso sempre aconteceu mas todo mundo varre para baixo do tapete, no Agile isso dói e agora este custo vem a tona.

25,1% – Conformidade com regulamentos?

Essa é muito difícil de entender, temos reuniões de discovery, planning, daily, review, retrospectiva. Todos eles revisam e realinham nosso Norte, todos geram pactos, definições de pronto, prioridades e critérios de aceitação. A equipe ainda tem que seguir os valores, regras e normas em todas as suas naturezas, agora ainda mais, pois cada um é o alter-ego um do outro. A empresa tem objetivos, regras e uma cultura que deve sempre ser levada em conta.

A impressão de várias destas angústias é que surgem a partir de adoções equivocadas de Agile, o que não é raro, na falta de um bom facilitador, de alguém que treine e esclareça o significado real, a natureza e real objetivo de cada princípio e regra … fica difícil. Tem muita gente que confunde agilidade com liberdade total, com falta de controles, só lembram de 2 ou 3 dos princípios e esquecem da maioria dos 4 artigos do manifesto.

20,8% – Qualidade de SW reduzida?

Agile possui várias camadas, a pirâmide Lean do grande Samuel Crescêncio mostra isso de forma exaustiva. Tem métodos para a camada estratégica, para gerenciamento de projetos na camada tática, e essencialmente técnicos para a qualidade e design no desenvolvimento. Para os que se preocupam com qualidade de software reduzida, sugiro lerem mais sobre XP, DDD, TDD, além da necessidade de ler sobre coisas que não nasceram com o Agile, como a esquecida lenda da Programação Orientada a Objetos.

Qualidade de software não se simboliza por documentação, se simboliza por qualidade … do software, simplicidade, componentização, manutenabilidade, serviços, etc, conheço gerentes que questionam Agile por deficiências que antes não apareciam, mas que a transparência do Agile mostrou.

Como diz o grande Giovanni Bassi, Agile tira o tapete da sala … não tem mais para onde varrer a sujeira, mas a sujeira já estava lá antes do tapete sumir. O fato é que tem gente que sente falta do velho tapetão, mas a equipe trabalhará a cada Sprint para convencer o negócio que qualidade é investimento e lucro certo.

12,4% – Sem preocupações?

Pode colocar esses 12,4% em uma camisa de força, pois adotar Agile não é de maneira alguma algo trivial. Adotar Agile exige uma gradual quebra de paradigmas, uma mudança profunda no modelo mental que praticamos a décadas, desde o ENIAC. É muito mais fácil um dizer que cumpriu ordens e o outro dizer que a equipe foi incompetente, dizer que o cliente mudou tudo ou que o analista não entendeu o que ele quis dizer …

Hoje em dia é um jogo de conveniência, software é complexo, assumir isso e trabalhar de forma auto-organizada e colaborativa, todos participando com a meta de fazer o melhor possível, adequado a importância e Momentum … isso não é para os fracos nem comodistas, demanda tempo, conversa e perseverança.

12,0% – Incapacidade de escalar?

Escalar é difícil sempre, mas de fato, tanto waterfall quanto métodos ágeis são difíceis de escalar, ainda mais nos dias de hoje com equipes geograficamente dispersas, multi-culturais, com fuso horário envolvido. Em 30 anos de carreira, desconheço projetos fáceis com várias equipes em um só produto …

Minha convicção é que em projeto pequenos e médios as equipes ágeis tem mais facilidade em agregar, na medida em que se escala é necessário papeis dedicados a garantir a comunicação, tráfego e convergência de padrões, qualidade e foco, usualmente nestes papéis usamos arquitetos de soluções, lideranças técnicas, SQA, Agile Coach, … Já usamos um PO com vários analistas de negócios lhe apoiando, Faz parte do modelo e funciona muito bem.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s