Adoção de metodologias ágeis

Este artigo aborda cenários pouco explorados pelas organizações durante a tomada de decisão a respeito da adoção de metodologias ágeis.

Adoção de metodologias ágeis
Na busca por processos de desenvolvimento de software mais flexíveis e capazes de suportar ambientes de negócio altamente voláteis e imprevisíveis, várias organizações optam pela adoção de metodologias ágeis. Além de propor algumas recomendações em geral desprezadas, este artigo identifica e explora aspectos que, ora surgem como obstáculos, ora servem de estímulo ao sucesso dessas iniciativas de adoção. Os aspectos propostos e questionamentos levantados sugerem uma abordagem que pode minimizar os impactos negativos comuns aos processos de mudança organizacional.Em que situação o tema útil
Se a sua organização tem planos para a adoção de metodologias ágeis, a utilidade da discussão proposta neste artigo vai se consolidar quando, ao invés de apenas almejar uma mera adaptação de uma ou outra teoria ao nosso ambiente de negócio, a verdadeira meta for a solução dos desafios e problemas atuais da organização.

 

Um processo de desenvolvimento de software é um conjunto de atividades e resultados associados que levam à produção de software. Ao longo da história da Engenharia de Software foram concebidos vários modelos de processos de desenvolvimento de software e nenhum deveria ser considerado como ideal ou solução para todos os contextos possíveis. Todos os modelos compartilham de fases essenciais como: especificação, projeto e implementação, validação e evolução; em geral definidas com o propósito de organizar e facilitar o gerenciamento das atividades que compõem o processo de desenvolvimento. Com o passar do tempo, os desafios atrelados ao desenvolvimento de software, tarefa cada vez mais complexa, impuseram novas demandas aos modelos até então utilizados.

Uma das principais demandas surgiu e vem somando força em contextos de negócio cada vez mais marcados pelas constantes mudanças. O cenário de imprevisibilidade não encontrou respaldo nos processos de desenvolvimento, os quais, orientados por uma estrutura rígida e altamente preditiva, não priorizavam a flexibilidade e a adaptação. Diante do desafio de responder com mais rapidez às mudanças, engenheiros de software, percebendo fraquezas na engenharia de software convencional, buscaram soluções para inovar os processos de desenvolvimento, originando o que foi denominado de “movimento ágil”.

A essência desse movimento, definido como agilidade, pode ser traduzida como a disponibilidade contínua de um método para rapidamente ou inerentemente criar a mudança, pró-ativamente ou reativamente adotar a mudança, e aprender com a mudança, enquanto contribui para o valor percebido pelo cliente (economia, qualidade e simplicidade), por meio de seus componentes coletivos e relação com seu ambiente.

Por mais promissora que seja uma teoria, o tempo e as tentativas para colocar em prática as ideias propostas seguramente culminarão numa nova realidade marcada pelo confronto entre as promessas e os resultados obtidos. Abordando o “universo” das metodologias ágeis, essa nova realidade dificilmente se estabiliza num mar de unanimidades e é muito fácilencontrar evidências que suportem diferentes perspectivas (sejaa dos entusiastas, a dos detratores, a dos indecisos, a dosevangelistas, a dos diferentes mercados, a dos vendedores de certificação, etc.).

Tomando como base diversos fatores por trás do sucesso e do fracasso das iniciativas de adoção das metodologias ágeis, a proposta deste artigo é explorar aspectos que, servindo de recomendações para nos anteciparmos aos desafios e riscos de tais iniciativas, também possam garantir ao máximo a produtividade das organizações, das equipes e do indivíduo rumo à melhoria contínua mesmo diante do ritmo crescente de mudanças.

História e Contexto

A “pedra fundamental” dos Métodos Ágeis é o IIDD (desenho e desenvolvimento iterativo e incremental), um método adotado há cerca de 70 anos. Como o termo “Metodologias Ágeis”só foi formalizado em 2001 por um grupo de especialistas em processos de desenvolvimento de software, muita gente ainda se anima com o “tema” assumindo que encontraram a solução mais “moderna” para substituir os velhos culpados pela situação de caos dos nossos projetos. Objetivando algo muito além da mera formalização de novos termos, o grupo de especialistas, depois de alguns encontros, apresentou uma série ou níveis de acordos que estabeleciam, na verdade, um novo paradigma para o desenvolvimento de software.

Estes acordos, essencialmente representados pelo que ficou conhecido como “Manifesto Ágil”, serviram e ainda servem como fundamento para a definição de processos de desenvolvimento caracterizados pela adaptabilidade, transparência (ou visibilidade), simplicidade e unidade. A abordagem proposta por estes novos processos, em resposta aos modelos tradicionais (rígidos e altamente preditivos), pode ser resumida da seguinte forma:

Primeiro nível: Precisamos de métodos particularmente desenhados para suportar e responder à volatilidade de projetos onde a única constante é a mudança. Ágil (ou Agile) foi o termo escolhido, visto que também permitia englobar projetos críticos com equipes enormes que, mesmo exigindo metodologias longe de parecerem “leves”, ainda requerem agilidade;

Segundo nível: Nosso propósito é descobrir maneiras melhores de se desenvolver software,e ao desenvolver, queremos que as pessoas também se desenvolvam. Queremos valorizar:

· Indivíduos e interações ao invés de processos e ferramentas;

· Software operante ao invés de documentações completas;

· Colaboração do cliente ao invés de negociações contratuais;

· Responder a mudanças ao invés de seguir um planejamento.

Atenção especial deve ser dada ao formato em que os valores acima foram apresentados: o primeiro segmento (em negrito) indica a preferência, enquanto o último descreve um item que, embora importante, é de prioridade menor. Muita gente confunde a proposta e elimina processos, ferramentas, documentação, contratos e planejamento.

Terceiro nível: Para sustentar os valores citados, precisamos criar princípios que devem ser seguidos:

· Priorizamos a satisfação do cliente através da entrega contínua e, desde cedo, de software com valor;

· Mudanças de requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Utilizamos a mudança em favor da vantagem competitiva do cliente;

· Entregar frequentemente software em funcionamento, desde a cada duas semanas até a cada dois meses, com uma preferência por prazos mais curtos;

· Pessoas do negócio e desenvolvedores devem trabalhar em conjunto diariamente por todo o projeto;

· Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o suporte de que precisam e confie neles para fazerem o trabalho;

· O método mais eficiente e eficaz de se transmitir informação para e entre uma equipe de desenvolvimento é a conversação face a face;

· Software em funcionamento é a medida primária de progresso;

· Os processos Ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente;

· A atenção contínua à excelência técnica e a um bom projeto aumentam a agilidade;

· Simplicidade – a arte de se maximizar a quantidade de trabalho não feito – é essencial;

· As melhores arquiteturas, requisitos e projetos emergem de equipes que se auto-organizam;

· Em intervalos de tempo regulares, a equipe reflete sobre como se tornar mais eficaz, para então aprimorar e ajustar seu comportamento de acordo.

Quarto Nível: O último nível representa as práticas ágeis, ou seja, atividades empregadas para executar ou implementar os princípios e valores ágeis. Não faz sentido dizer que há um conjunto definido de práticas e que nenhuma nova prática possa ser criada. É comum encontrar organizações que criam ou customizam as práticas existentes a fim de lidar com as necessidades específicas ao seu contexto.

A partir do fundamento segundo o qual os processos de desenvolvimento devem capacitar as organizações na resposta às constantes mudanças, a Figura 1 resume o relacionamento entre os valores, princípios e práticas ágeis.

Figura 1. Relacionamento entre Valores, Princípios e Práticas Ágeis.

A essência das Metodologias Ágeis

A essência da agilidade, representada pela necessidade de responder às constantes mudanças, pode ser mais bem visualizada através da comparação entre os novos paradigmas ágeis e os paradigmas dos modelos tradicionais (waterfall).

Figura 2 apresenta os principais tópicos através dos quais é possível realizar essa comparação e, ao mesmo tempo, capturar os fundamentos da abordagem ágil.

Figura 2. A mudança de paradigmas na abordagem ágil.

No intuito de esclarecer um pouco mais a mudança de paradigmas na abordagem ágil, destacamos os seguintes pontos:

· Medida de Sucesso: A forma de mensurar o sucesso é diferente. As equipes e a própria organização medem seu sucesso avaliando a habilidade de responder às mudanças ao invés da “imutável” conformidade aos planos;

· Cultura de Gestão: Tradicionalmente, a gestão define escopo, datas e recursos, além de definir e se responsabilizar pelo direcionamento técnico e pelo desempenho da equipe. No novo paradigma ágil, a gestão determina a direção, as equipes exploram o escopo e descobrem como realizar o máximo de funcionalidades num prazo determinado. A equipe se auto-organiza para cumprir os objetivos, tomando as decisões necessárias. A equipe toma decisões autônomas e corrige o rumo, adaptando-se às mudanças em tempo real. O foco da gestão é eliminar os impedimentos dentro da organização e confiar na capacidade da equipe de cumprir os objetivos (esta confiança é reforçada diariamente com a visibilidade do progresso e da evidência de que o código funciona e está integrado). Por sua vez, a equipe deve prestar contas sobre o cumprimento dos prazos e sobre os requisitos de qualidade. Autonomia e prestação de contas andam em total sincronia;

· Requisitos e Design: Ao invés de “gastar” meses na elaboração prévia de requisitos, de especificações detalhadas, de modelos de arquitetura, de protótipos, as equipes se concentram em ciclos rápidos de entrega de valor. A entrega antecipada de software funcionando serve para testar requisitos e pressupostos da arquitetura, além de diminuir riscos sobre a integração de componentes. No caso de surgirem inconsistências, a equipe trabalha no código, permitindo o feedback constante ao usuário e transparência ao longo do processo. Assim, é possível evitar que a gestão e outros envolvidos sejam obrigados a esperar durante meses na esperança de que a equipe esteja realmente construindo a coisa certa;

· Codificação e Implementação: Ao invés de trabalhar em todas as funcionalidades ao mesmo tempo e “torcer” para que a integração feita de uma única vez funcione, os desenvolvedores “atacam” em conjunto, e iterativamente, as funcionalidades de mais alta prioridade. A integração é contínua, os testes não são deixados para depois, a programação em pares é o padrão, a comunicação é intensa e contínua, e deve haver apenas um tipo de resultado: código funcionando, testado e integrado;

· Teste e Garantia de Qualidade: A equipe de teste não fica alocada numa sala secreta, responsável unicamente pela “fase” de testes. Testar é uma atividade conjunta e contínua. Todos devem prestar contas. Desenvolver testes automatizados passa a ser uma regra e não apenas a exceção. As competências de teste se desenvolvem enquanto os testadores participam das decisões de design e da automação dos testes. Os desenvolvedores, por sua vez, se capacitam à medida que entendem como escrever código que seja mais simples para ser testado. A equipe de QA faz o trabalho “real” de QA, ao invés de gerir uma legião de “testadores manuais”;

· Planejamento e Cronogramas: Como muitos imaginam (erroneamente), a agilidade não despreza o planejamento. Na verdade, este é bastante intenso e reaparece em dois níveis: planejamento geral para os releases (entregas planejadas) e planejamento mais refinado para as iterações (ciclos de desenvolvimento). O planejamento não é realizado todo de uma vez. Pelo contrário, limita-se a criar estimativas no ritmo dos ciclos dos próximos releases e iterações. O planejamento é simplificado, visto que as datas são sempre conhecidas com antecedência e as equipes, em conjunto com os “donos” do produto, determinam as prioridades de entrega. O monitoramento é mais simples também, em virtude das frequentes reuniões (diárias) de demonstração de status e do progresso.

Uma análise inicial

Um dos princípios fundamentais da adoção de tecnologia, conhecido como “adaptação mútua”, afirma que o sucesso na adoção de uma tecnologia numa organização requer adaptação tanto da tecnologia quanto da organização. A tecnologia, por exemplo, se adapta à organização ao permitir novas configurações de seus atributos (software e/ou hardware). A organização se adapta à tecnologia enquanto altera alguns dos seus fluxos de trabalho (processos de negócio) para que sejam mais compatíveis com a tecnologia ou se adapta enquanto altera os papéis das pessoas envolvidas em diferentes processos que sejam afetados pela nova tecnologia.

Seguindo essa mesma linha de raciocínio, ao adotar uma nova metodologia, uma organização deverá enfrentar os mesmos desafios associados à adoção de novas tecnologias. Em outras palavras, ao adotar uma metodologia ágil, a organização deve se adaptar aos novos princípios e práticas ao mesmo tempo em que a metodologia também é customizada para se adaptar à organização. Dentre as principais observações nesse sentido, quanto “menor a distância” entre a cultura organizacional e os pressupostos culturais implícitos no conjunto de práticas de uma metodologia, mais fácil será o processo de adoção.

É muito mais provável encontrarmos exemplos de iniciativas por meio das quais, ao invés de testemunharmos um planejamento cuidadoso para se antecipar aos riscos (diminuir a distância entre a metodologia e a organização), se prioriza a contratação de consultores com o único objetivo de desenvolver treinamentos rápidos, superficiais e que, de preferência, destaquem apenas as promessas a respeito de como todos os problemas serão resolvidos. Se envolve soluções tradicionais ou ágeis, é fato que pouca gente investe esforço suficiente para avaliar fatores que, mais cedo ou mais tarde, impactarão nas decisões e iniciativas de adoção.

Alguns mercados sobrevivem de modismos. Se não é o seu caso (mercado ao qual pertence a sua organização), sugerimos a seguir alguns aspectos que merecem dedicada atenção e consideração antes de e durante a implementação do seu “futuro” processo de adoção:

1. Considerando a Cultura Organizacional: A cultura da sua organização é um fator primário para o sucesso de qualquer iniciativa de mudança, inclusive a adoção de uma nova abordagem para desenvolver software. Embora a cultura incorpore muitas facetas, queremos destacar apenas duas partes específicas, visto que apresentam elementos relevantes aos métodos ágeis. Estas partes são:

a. Estrutura Hierárquica ou Cooperativa: Essa divisão lida com as formas como as pessoas são organizadas e como se comunicam dentro da organização.

i. Hierárquica: Numa organização hierárquica, existem divisões claras de responsabilidade e autoridade, com papéis específicos responsáveis por atividades distintas. Os canais de comunicação tendem a ser claramente definidos e bem restritivos. Qualquer comunicação que ocorra fora dos caminhos definidos é considerada como quebra de padrão e pode ser considerado como ato de insubordinação passível de respectiva punição;

ii. Cooperativa: Em organizações cooperativas, a comunicação e o fluxo de trabalho são mais flexíveis. Quando algo precisa ser feito, a equipe não se limita a descrições de cargo ou ao departamento que pertence. Impulsionada pelas necessidades do negócio, a equipe trabalha num modelo de auto-organização buscando aproveitar da melhor maneira possível as habilidades disponíveis no grupo.

b. Controle ou Reação às Mudanças: Esta divisão lida com a forma como a organização lida com mudanças e desvios de plano:

i. Controle total: Uma organização que controla as mudanças tende a valorizar a continuidade e conformidade aos planos e requisitos. Como mudanças são inevitáveis, e o controle total é a regra de sucesso, a organização tenta micro gerenciar qualquer mudança para minimizar o efeito nos projetos;

ii. Reativo: Organizações que reagem à mudança tendem a valorizar a satisfação do cliente. Esse tipo de organização não prioriza a abordagem “evitar mudança a qualquer custo”. Ao invés disso, desenvolve mecanismos para continuamente detectar o feedback do cliente e adaptar-se o mais rápido possível a qualquer problema ou opinião divergente comunicados pelo mesmo.

c. Considerações sobre a cultura organizacional: Alguns métodos ágeis possuem elementos que “só funcionam” em ambientes colaborativos e outros elementos claramente hierárquicos. Visto que a adoção vai impor desafios para sua organização, seja ela hierárquica ou cooperativa, é primordial avaliar e decidir pela abordagem que garanta o melhor resultado (menor risco, mais benefício financeiro, maior motivação, etc.). Uma organização do tipo “controle total” vai enfrentar mais dificuldades com a adoção de métodos ágeis, pois alguns deles caminham justamente na direção da abordagem reativa, ou seja, cliente e equipe elaboram, inicialmente, versões aproximadas dos planos e dos documentos de requisitos, e, à medida que o projeto avança, cada fato novo ou mudança é encarada como oportunidade para aprendizado através da adaptação e evolução (inclusive da documentação).

2. Considerando seus Clientes: O manifesto ágil declara que valoriza mais a colaboração do cliente do que a negociação por contratos. Apesar de existirem diversos elementos que comprovem essa valorização, queremos focar, a seguir, no estabelecimento de contratos:

a. Contratos: Contratos são exigidos para preencher a falta de confiança e as incertezas entre organizações diferentes, assim possibilitando que elas trabalhem juntas. O contrato de projeto de prazo fixo tradicional não lida com as incertezas do ambiente de negócio e do ciclo de vida de desenvolvimento de software, colocando cliente e fornecedores uns contras os outros, onde, ao invés de colaboração, tempo e energia são gastos decidindo quem deve pagar por uma mudança. A Figura 3 permite uma rápida e nítida comparação entre a abordagem tradicional e a abordagem ágil em relação aos contratos.

Figura 3. Contratos: “obstáculos” versus “apoio”.

b. Considerações sobre o estabelecimento de contratos: A adoção de métodos ágeis terá um impacto notável no relacionamento com os clientes, alterando a natureza dos acordos contratuais, a forma como os requisitos são definidos e gerenciados, e o grau de envolvimento do cliente nos projetos. Ou seja, o sucesso com qualquer metodologia ágil dependerá sobremaneira do envolvimento intencional do cliente rumo a uma nova maneira de fazer negócio.

3. Considerando seus Projetos: Apesar de não existirem dados estatísticos sobre os tipos de projetos cujas “características” possam garantir o sucesso na adoção de metodologias ágeis, queremos destacar alguns aspectos pertinentes ao contexto ágil que devem ser considerados em relação ao contexto atual dos seus projetos:

a. Tamanho das equipes: Parece ser muito mais adequado montar equipes menores (não excedendo 10-15 pessoas) para as abordagens ágeis. Embora não se imponha uma limitação explícita a respeito do tamanho das equipes, se priorizarmos a comunicação “cara-a-cara” em detrimento da comunicação via documentação, é fácil enxergar um limite prático para a composição destas equipes. Por outro lado, não devemos interpretar que se o escopo de um projeto exige a formação de equipes maiores, então é impossível usar uma abordagem ágil;

b. Localização geográfica das equipes: Uma equipe geograficamente distribuída pode utilizar as abordagens ágeis, mas tal configuração suscitará diversos desafios para uma comunicação contínua e livre de ruídos entre os membros da equipe. Mesmo diante dos recentes avanços em teleconferência e outras ferramentas de comunicação “instantânea”, ainda esperamos por um substituto à altura que traga os benefícios da comunicação de equipes localizadas no mesmo ambiente;

c. Criticidade dos projetos: O nível de criticidade dos projetos, variando entre “sem muita importância” e “falha não é uma opção”, é um fator importante na equação que nos é apresentada quando decidimos sobre a adoção de abordagens ágeis. Ao invés de afirmar que deveríamos ou não utilizar métodos ágeis em projetos críticos (um critério não muito objetivo, pois o que é crítico para uma empresa pode não ser para outra), preferimos recomendar que o risco envolvido na adoção seja analisado e balanceado em conjunto a outros riscos já identificados para, só então, tomar a decisão mais adequada ao contexto.

4. Considerando suas Ferramentas e Processos: Ao adotar uma nova metodologia, o impacto sobre a forma atual como utiliza ferramentas e processos será inevitável, eliminando algumas práticas consolidadas, adquirindo novas soluções ou aprendendo a utilizar melhor as funcionalidades existentes. Nesse sentido, sugerimos que considere os aspectos a seguir:

a. Gerenciamento de requisitos: Se a sua organização já adota uma metodologia ou ferramenta que exige certo nível de documentação e gestão de requisitos, será necessário examinar cuidadosamente as restrições impostas pela abordagem atual para determinar se um método ágil se encaixará nos moldes existentes. Se, por outro lado, sua organização não possui métodos definidos à gestão de requisitos, é importante avaliar o impacto das mudanças necessárias para padronizar uma metodologia utilizando uma abordagem ágil (Por exemplo, seremos obrigados a utilizar ferramentas de requisitos? Será necessário um maior rigor ou mais burocracia? Nossa equipe está preparada para as novas competências?);

b. Gerenciamento de projeto: O mesmo tipo de questionamento feito sobre a forma como sua organização gerencia os requisitos pode ser utilizado para confrontar seu “estilo” atual de gerir projetos. Representando de forma genérica a abordagem ágil para lidar com alguns aspectos chave da gestão de projetos, a Figura 4 mostra que:

i. Estimativas de atributos do produto de trabalho (tamanho, complexidade, etc.) não são, em geral, produzidas;

ii. Estimativas de esforço e cronograma (específicas a uma determinada iteração) são produzidas num nível intermediário de detalhes;

iii. Os planos, em geral, não são documentados de forma detalhada;

iv. Enquanto o progresso do projeto é monitorado, com razoável rigor, de acordo com o plano, ações corretivas quase nunca são tomadas. Ao invés disso, os desvios em relação ao que foi planejado são tratados como “fatos” e os planos são alterados para se “conformarem” a essa nova compreensão da realidade;

v. Os planos alterados são documentados no mesmo nível de detalhe do plano original.

Figura 4. Gestão Ágil de Projetos.

5. Considerando sua Equipe: Ao adotar qualquer método ágil, a experiência atual de sua equipe e a forma como reagem às mudanças exigirão importantes considerações em relação aos seguintes tópicos:

a. Mudanças no fluxo de trabalho: Visto que o trabalho de todos será impactado, é vital que as diversas reações sejam monitoradas. A Figura 5 mostra os estágios através dos quais as pessoas tendem a passar quando lidam com mudanças no ambiente de trabalho. Ainda que nem todos reajam da mesma forma, os estágios representam um padrão a ser observado dentro de sua organização quando qualquer mudança significativa for introduzida. Vale a pena prever algumas estratégias a fim de minimizar os riscos e/ou estimular as oportunidades geradas durante cada estágio.

Figura 5. Estágios em Processos de Mudança.

b. Fazendo a mudança “pegar”: Se você decidir por adotar métodos ágeis baseado em “nada” (pouca informação e análise), o esforço certamente será em vão. Para a mudança “pegar”, é necessário mergulhar nos detalhes e “segredos” da metodologia até obter conhecimento suficiente sobre os pontos críticos ao seu contexto. Se possível, contrate um consultor ou profissional com experiência relevante no assunto e no seu modelo de negócio. Se você espera que as pessoas “comprem a ideia” a respeito da adoção, é importante considerar o planejamento que inclua, na medida do possível, as seguintes reflexões:

i. Envolvo as pessoas durante o processo de decisão?

ii. Reforço constantemente as razões para a mudança?

iii. Discuto sobre os planos de implementação da mudança?

iv. Comunico regularmente o status da iniciativa de mudança?

v. Compartilho as informações sobre os problemas encontrados e como os mesmos foram “atacados”?

vi. Celebro cada conquista?

c. Alterando o sistema de recompensas: Toda organização possui um sistema de recompensas. Seja formal ou não, todo funcionário entende muito bem quais comportamentos são recompensados. Sem sombra de dúvida, a adoção de um novo método vai acrescentar novas variáveis ao “sistema” e um novo padrão de comportamento vai emergir exigindo cuidados adicionais.

Basta definir a Condição-Alvo?

De acordo com especialistas do SEI (Software Engineering Institute), “…todas as metodologias de gestão e de engenharia de software estão baseadas em suposições culturais e sociais. Ao adotar novas práticas, os líderes na maior parte das vezes vão enfrentar dificuldades para alinhar esses pressupostos e a realidade dentro de suas organizações.”.

Tomando emprestado alguns aspectos do “modelo” de gestão Toyota Kata, queremos destacar observações que sirvam de alerta ao processo de adoção. Em primeiro lugar, vale frisar que adotar uma metodologia, por mais promissora que se apresente, não deveria ser a meta de uma organização. Pelo contrário, as pessoas responsáveis pelo planejamento, direcionamento e execução estratégica deveriam ter em mente, como condição-alvo, a melhoria contínua dos diversos processos de negócio que constituem a empresa.

O estabelecimento de uma condição-alvo, entretanto, é apenas parte do processo de melhoria (ver Figura 6). A outra parte é caminhar através dos obstáculos que surgirão enquanto se avança em direção à condição-alvo. Supondo que sua organização estabeleça como condição-alvo a adoção das metodologias ágeis, o modelo da Toyota nos sugere os seguintes alertas:

· Assuma que o caminho é obscuro

o Frequentemente definimos um plano e confiamos que nosso único desafio será alocar recursos e conduzir a execução do plano. A realidade, infelizmente, não é linear e nem previsível o bastante para que essa seja uma maneira eficaz de alcançar nossas condições-alvo;

o Independente da qualidade do seu planejamento ou de quão organizada e detalhada é a estrutura do seu plano de adoção, é altamente recomendável assumir que o caminho rumo à condição-alvo não se revelará tão previsível e sem mudanças; o caminho é uma zona cinza, imprevisível.

· Como trabalhar na zona cinza

o Uma vez que a condição-alvo tenha sido estabelecida e que um plano tenha sido elaborado, o foco deveria ser o próximo passo. Não adianta “gastar” muito tempo com planos muito detalhados porque sempre que um passo é dado, o cenário de adoção, como consequência, pode ter mudado consideravelmente;

o O caminho em direção à condição-alvo é trilhado em passos curtos e rápidos, com a aprendizagem e os ajustes ocorrendo ao longo do caminho. Ao fazer ajustes com base no que foi aprendido ao longo do caminho, podemos progredir como um cientista faz, ou seja, a cada percepção empírica, um cientista ajusta o seu curso para tirar vantagem do que foi aprendido;

o Outra analogia útil: você já definiu para onde quer ir (a condição-alvo), mas o caminho à frente entre aqui e  é obscuro. Você está segurando uma lanterna, mas ela só ilumina até certa distância na escuridão. Para ver adiante e iluminar os obstáculos escondidos na escuridão, você tem que dar um passo à frente;

o Esse procedimento de experimentação (cientista trabalhando na zona cinza) é resumido pelo conhecido ciclo Planeje-Faça-Verifique-Aja (PDCA). Vamos considerar os quatro pontos a seguir:

§ Os sistemas adaptáveis e evolutivos, por sua natureza, envolvem a experimentação;

§ As hipóteses só podem ser testadas através do experimento, não pela discussão intelectual, opinião ou julgamento humano;

§ Para que um experimento seja científico, deve ser possível que a hipótese venha a ser refutada;

§ Quando uma hipótese é refutada, particularmente podemos adquirir uma nova percepção e desenvolver mais a nossa capacidade.

Figura 6. Processo de Melhoria.

O que está “por trás” das “falhas”?

Se levarmos em consideração as incontáveis iniciativas de adoção das metodologias ágeis, um aspecto que sempre volta à pauta das discussões e desperta interesse de toda comunidade envolvida, é a tendência de dar uma ênfase desproporcional em favor “daquilo que deu errado”, das histórias de “insucesso” e dos “prováveis culpados”. Pior, parece que estão mais interessados em defender o status do que realmente avaliar o que está por trás das tentativas frustradas de adoção.

Por outro lado, nossa proposta é estimular a reflexão sobre os aspectos que tiveram influência no “insucesso”, mas a partir de um olhar renovado em busca de aprendizado. Apenas apontar obstáculos e não investigar novas possibilidades pode resultar num eterno padrão de resistência a tudo que parece “novo” e que exija mudanças. Se olharmos atentamente para os obstáculos que dificultam o processo de adoção das metodologias ágeis, o que podemos encontrar? Qual a parcela da metodologia, da cultura organizacional e dos indivíduos envolvidos?

A partir dos resultados coletados na recente pesquisa “State of Agile Development Survey 2011”, além de muitas outras descobertas, a Figura 7 apresenta números, senão curiosos, bastante reveladores sobre os principais obstáculos para o processo de adoção das metodologias ágeis. Limitando-se apenas aos três principais (e mais votados) obstáculos, encontramos fatores como: (i) Inabilidade para efetuar mudanças na cultura organizacional [52%], (ii) Indisponibilidade de pessoal com as competências necessárias [40%] e (iii) Resistência a mudanças em geral [39%]. Se recuperarmos os números da pesquisa de 2008, vamos encontrar os mesmos obstáculos e porcentagens não muito diferentes [(i) 45%, (ii) 42%, (iii) 44%].

 

abrir imagem em nova janela

Figura 7. Obstáculos à Adoção de Metodologias Ágeis.

Visto que a maioria das pesquisas se referiam a dados de questionários em nível global, a ausência de informações específicas à comunidade brasileira incomodou um grupo de pesquisa em métodos ágeis da Universidade de São Paulo o qual, por ocasião do aniversário de 10 anos do Manifesto Ágil, conduziu em 2011 uma pesquisa para levantar o estágio atual de adoção e adaptação de métodos ágeis em todo o Brasil. O “Questionário Nacional sobre Métodos Ágeis” apresentou resultados (ver Figura 8) com incrível semelhança quando comparado às pesquisas realizadas em nível global.

 

abrir imagem em nova janela

Figura 8. Barreiras para Adoção de Metodologias Ágeis (Brasil).

As evidências reunidas e apresentadas até aqui reforçam as previsões de especialistas como Martin Fowler que já em 2006 ressaltava que “uma das partes mais difíceis da introdução de metodologias ágeis em uma organização é a mudança cultural que esta representa. Na verdade, descobrimos que essa é a principal preocupação de organizações ao adotá-las”. Hoje é possível deduzir que a principal preocupação se configurou como principal obstáculo.

Limitando o foco nesse principal obstáculo – Mudança da Cultura Organizacional – fica cada vez mais perceptível a existência de um relacionamento muitas vezes conflitante entre cultura e práticas na organização, impedindo que algumas iniciativas de mudança em organizações de TI possam ser bem sucedidas, independente da vontade expressa pelas lideranças da empresa, mesmo com a ajuda de consultorias especializadas.

Com a participação ativa de uma empresa de consultoria de TI – a ThoughtWorks – referência mundial na utilização de práticas ágeis em seus projetos, um grupo de pesquisadores da Universidade Federal do Rio Grande do Sul tentou explorar quais seriam os pressupostos básicos de cultura organizacional que estão relacionados com a adoção de determinadas práticas ágeis. Como resultado, a pesquisa revelou alguns pressupostos que são mais adequados à implantação de práticas ágeis. São eles:

· Processo de decisão coletivo e participativo (ao invés de um baseado em autoritarismo e paternalismo);

· Valorização do pragmatismo (em oposição a uma autoridade moralista);

· Crença de que os seres humanos são basicamente bons (em oposição a basicamente maus);

· Uma atitude proativa (em oposição a reativa e fatalista);

· “Grupocentrismo” (em oposição ao individualismo).

Voltando à questão “O que está por trás das falhas?”, acreditamos que a conclusão mais coerente, não tomando posição parcial ao responsabilizar individualmente a metodologia ou a organização pelos insucessos, se sustenta nas premissas da “adaptação mútua”, ou seja, a metodologia deve se adaptar à organização enquanto a organização se adapta à metodologia.

O que está “por trás” dos casos de sucesso?

Acreditamos que a análise sobre o que está por trás do sucesso de um processo de adoção é diferente de quando avaliamos as falhas por trás de tais iniciativas. Por exemplo, quando nos propusemos a investigar brevemente o que estava por trás das iniciativas de adoção que falharam, não nos detivemos na verificação dos critérios de sucesso definidos para as iniciativas. Em outras palavras, se os critérios para adotar uma metodologia foram objetivos ou subjetivos, coerentes ou não, nosso foco se dirigiu apenas para os fatores que impediram o alcance da meta estipulada. A análise se limitou a dizer que não foi possível adotar as práticas e princípios ágeis por esse ou por aquele motivo.

Por outro lado, a análise sobre o que está por trás dos casos de sucesso parece exigir um pouco mais do que simplesmente verificar se as práticas e os princípios ágeis foram adotados. Na grande maioria dos casos, os pesquisadores estão mais interessados em levantar evidências sobre quais foram as razões que motivaram a consideração e respectiva adoção das metodologias ágeis. É fácil notar que, ao se definir uma razão, os responsáveis pelo processo de adoção já estão automaticamente indicando um critério para avaliar o sucesso da “empreitada”. Nesse sentido, não adiantaria emitir alguns relatórios indicando que adotamos práticas x e y e, ao mesmo tempo, não apresentarmos indícios de que as razões pelas quais iniciamos “isso aqui” não foram satisfeitas ou não se mostraram coerentes à realidade da organização. Ou seja, ter sucesso depende não apenas de adotar, mas atender aos critérios definidos.

Se desprezarmos o número de empresas que definem como critério de sucesso a adoção “pura e simples” ainda que não consigam evidência alguma sobre qualquer tipo de indicador de melhoria, nos resta debruçar sobre as motivações ou razões que levaram outra parcela de empresas interessadas em possíveis benefícios ou promessas de melhores resultados. A mesma fonte de onde retiramos os dados sobre as falhas nas iniciativas de adoção traçou conclusões a respeito da seguinte questão: Qual a razão/motivação para adotar metodologias ágeis?

As empresas participantes da pesquisa podiam escolher mais de uma opção e atribuir “pesos” a cada opção utilizando as categorias “Nada Importante”, “Pouco Importante”, “Muito Importante” e “Mais Alta Importância”. Anotando apenas as opções marcadas como “Muito Importante” e “Mais Alta Importância”, a pesquisa nos diz que:

· 77% buscavam acelerar o “time-to-market” (tempo de resposta a uma demanda do mercado);

· 83% buscavam melhorar a capacidade de gerenciar a mudança de prioridades;

· 80% buscavam melhorar a produtividade;

· 65% buscavam melhorar o alinhamento entre TI e Negócio;

· 71% buscavam aumentar a qualidade do software.

Continuando, sem especificar números, o sucesso para essas empresas também pode ser interpretado como “Reduzir custos”, “Melhorar/aumentar a disciplina da engenharia”, “Melhorar a visibilidade do projeto”, “Melhorar a moral da equipe”, “Reduzir riscos”, “Melhorar a manutenibilidade/extensibilidade de software” e “Simplificar o processo de desenvolvimento”.

Se antes da adoção a maior prioridade era obter ganhos relacionados à produtividade e “time-to-market”, os resultados da pesquisa apontaram que os reais benefícios se concretizaram em (i) melhorar a capacidade de gerenciar a mudança de prioridades [84%], (ii) melhorar a visibilidade do projeto [77%] e (iii) aumentar a produtividade [75%].

Retomando o questionamento sobre o que poderia estar “por trás” do sucesso de iniciativas de adoção, acreditamos que se trata fundamentalmente de ter condições de atestar onde e como a agilidade pôde transformar uma organização nas mais variadas frentes (inovação, aprendizado e melhoria contínuos, resiliência, adaptação, etc.). Qual o sentido de medir o sucesso pelo número de práticas ágeis adotadas se nenhuma melhoria efetiva nos resultados da empresa pode ser evidenciada? Parafraseando alguns evangelistas ágeis, “Fazemos algo ágil quando seguimos algumas práticas ágeis. Ser ágil é diferente de fazer. Quando somos essencialmente ágeis, agimos movidos por um mindset ágil, sabemos que as práticas são os meios para uma outra finalidade. Ser ágil é mais do que adotar apenas uma outra metodologia. A chave está em abraçar/enfrentar/aceitar a mudança” – Bob Hartman.

No momento que alteramos nosso campo de visão, deixando de pensar apenas na adoção e alocando nossos esforços para uma transformação, podemos fazer uso de algumas recomendações chave para uma transição de sucesso:

1. Obtenha o suporte do “alto escalão executivo” e da liderança;

2. Use os princípios ágeis para tratar de questões relevantes ao negócio;

3. Defina o que significa “ser ágil” na sua organização;

4. O engajamento de toda a organização deve fazer parte da missão;

5. Invista na capacitação da equipe de transição;

6. Apresente resultados em termos de negócio (evite jargões desconectados do contexto);

7. Não argumente só com princípios. Use métricas objetivas;

8. Reconheça o esforço para mudar paradigmas, modelos mentais e comportamentos;

9. Prepare-se para superar os obstáculos durante a transição;

10. Tenha um plano. Tenha bom senso e seja ágil no planejamento.

Conclusão

Como identificar e superar os desafios enfrentados atualmente e se preparar diante da imprevisibilidade dos desafios que estão por vir? Respostas que sejam relevantes a todos os contextos possíveis não ultrapassarão os limites da superficialidade. Enquanto revisamos a estrutura geral através da qual o artigo foi composto, o nosso maior desafio e principal recomendação virá por meio de questionamentos e sugestões que gerem uma espécie de “tensão criativa” que, incomodada pelo indesejado estado atual das organizações (seja por acomodação, inércia, baixa produtividade, desmotivação, poucos resultados), crie uma visão compartilhada entre todos os indivíduos rumo à transformação.

Se mantivermos uma mentalidade que negligencia a história e contexto que desencadearam o “movimento” ágil, como assegurar que as soluções adotadas não estão justamente nos levando a repetir os mesmos erros e a cair nas mesmas “armadilhas”?

Explore a essência das metodologias ágeis a fim de buscar discernimento diante de questões como:

· Estamos prontos para adotar alguma metodologia ágil?

· Dentre os princípios, valores e práticas conhecidos, existe um conjunto mais coerente com o nosso contexto?

· Será necessário customizar a metodologia para atender as restrições e necessidades da nossa organização?

· Devemos definir nossa própria metodologia a partir da escolha de algumas práticas que já testamos?

· Na atual conjuntura, faz sentido utilizar qualquer metodologia ágil?

Você está preparado para assumir os custos de um processo de adoção que é executado sem planejamento prévio a respeito dos passos necessários para uma análise inicial com o objetivo de responder sobre a viabilidade do projeto?

Se os critérios de viabilidade não lhe parecem evidentes (estrutura da organização, ciclo de vida dos projetos, gestão do capital humano, modelo de negócio, relacionamento com clientes, etc.), qual será sua estratégia para escapar da tentação de definir como condição-alvo a “mera” adoção de uma metodologia enquanto fecha os olhos para o que realmente importa e precisa ser mudado?

Até que ponto o fato de conhecermos o que está por trás das falhas de diversas iniciativas de adoção pode representar algum benefício real? Defendemos a tese segundo a qual “não aprendemos com os erros, de fato, o aprendizado é confirmado pela correção dos erros”. Qual sua opinião a respeito disso? O que você e sua organização podem ganhar a partir dos erros (próprios e dos outros)?

Quando analisamos os casos de sucesso em processos de adoção, quantos de nós inadvertidamente não nos apegamos ao mantra “em tecnologia nada se cria, tudo se copia”? Nada contra a “reciclagem” ou reaproveitamento de ideias, mas almejar o sucesso numa iniciativa de adoção dependendo única e exclusivamente das receitas dos outros faria todo sentido se a meta fosse, sem julgamento de valor, copiar a receita dos outros.

Independente do mercado em que atua, quando olhamos para uma organização que valoriza a inovação, é comum encontrarmos um comportamento compartilhado entre todos no sentido de encarar todo e qualquer desafio como verdadeiras oportunidades para mudança e respectivo aprendizado.

Além de tudo o que foi exposto até o momento, fica um último desafio: tente estabelecer qualquer tipo de conexão entre o tema do artigo e domínios que, à primeira vista, não representem nenhuma associação “natural” e/ou lógica. Outra abordagem semelhante pode ser implementada através de conversas formais ou informais com o objetivo de compartilhar com profissionais de outras áreas as descobertas antes, durante e depois de suas iniciativas de adoção de metodologias ágeis. Seja curioso e invista mais tempo fazendo questionamentos a respeito de tudo ao invés de se acomodar com as respostas prontas.

About these ads

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s