A certificação ágil realmente vale a pena?

Da Redação CIO, com IDG News Service

Publicada em 07 de julho de 2017

Profissionais TI

O framework Agile revolucionou o processo de desenvolvimento de software e o gerenciamento de projetos, aumentando a demanda por profissionais de TI versados ​​na metodologia e em seus muitos sabores. Para ajudar os profissionais de TI a  se destacarem neste cenário, surgiram várias certificações ágeis, cada uma oferecendo uma abordagem única para avaliar o conhecimento e a competência desses profissionais com o framework.

Mas as certificações, especialmente da metodologia Agile, realmente comprovam competência e proficiência? Quanto os gerentes de contratação devem confiar na "sopa de letrinhas" das credenciais ágeis para medir a experiência de um candidato? E que valor as empresas devem dar a elas?

"Argumentos contrários existem para quase todas as certificações, seja Java, Oracle, Microsoft - e agora Agile. Não é algo que meus clientes estejam solicitando especificamente; eles só querem saber se as equipes podem criar um bom software", diz John Doucette, vice-presidente de operações de consultoria da empresa de desenvolvimento de software personalizado Magenic Technologies.

A certificação não garante sucesso

Para Doucette, uma certificação ágil pode mostrar que um candidato investiu algum tempo estudando as melhores práticas em torno da metodologia. Mas ter pessoal certificado em Agile não é garantia de sucesso de um projeto ágil, acrescenta.

"O sucesso do projeto ágil tem menos a ver com desenvolvedores certificados e muito mais a ver com o fato de a organização, como todo, abraçar a mudança de cultura para uma mentalidade ágil, do nível mais baixo até o CEO," diz Doucette.

Agile é difícil de comparar

Não há nada de errado, teoricamente, com uma tentativa de construir uma referência para as habilidades em geral, mas, em particular, Agile é muito difícil de avaliar, porque há muitos pontos intangíveis dentro da metodologia, diz Scott Staples, presidente e chefe global de negócios da Mindtree.

"Coisas como trabalho em equipe, liderança, capacidade de adaptação, capacidade de tarefas múltiplas, necessidade de entender e transformar as necessidades do negócio em requisitos de software, planejamento, capacidade de refletir sobre falhas, críticas construtivas... são todas habilidades dentro da estrutura ágil difícieis de medir", diz Staples.

Dentro de pequenas empresas e startups, essas qualidades tendem a ser mais evidentes, porque com funcionários limitados e orçamentos apertados, todos têm que armar e trabalhar muito como equipe. Grandes corporações, por outro lado, têm dificuldade em expandir Agile em sua estrutura, por causa da escala.

Esteja a salvo

"As empresas maiores são onde vemos os grandes embates com a metodologia Agile, especialmente em estruturas bem estabelecidas e legadas, que estão tentando mudar para uma maneira mais ágil de fazer coisas. É difícil trabalhar em torno de hierarquias entrincheiradas e deixar para trás a mentalidade de comando e controle", diz Staples. Nestes casos, as certificações podem ser valiosas, porque muitas vezes as equipes e a liderança de TI vão ouvir "especialistas" mais de perto se acharem que precisam de conselhos, diz Staples.

Um desses exemplos é o SAFe, ou Scale Agile Framework . A SAFe fornece um roteiro e melhores práticas para adotar Agile em uma escala empresarial, e as certificações SAFe abrangem todos os aspectos de Agile em escala, desde arquitetura, integração, financiamento, governança e funções.

"Nós somos realmente otimistas em relação à SAFe. A certificação SAFe, para nós, é praticamente infalível na medida em que as pessoas não podem obter certificação a menos que comprovem proficiência com testes práticos e demonstrem a aplicação de seus conhecimentos em situações do mundo real. Um caminho fácil, capaz mostrar que o compromisso e o domínio são realmente impressionantes ", diz Staples.

Qualquer certificação ágil que não exige que os candidatos tenham algum tipo de treinamento prático é prejudicial, não apenas para os candidatos, mas para as organizações que os contratam e para o campo de desenvolvimento de software em geral, diz Dave West, product owner da Scrum.org, que fornece avaliações profissionais, treinamento em princípios ágeis e certificações dinâmicas.

"Você não quer praticantes de Agile que nunca praticaram Agile, podendo entrar e fazer um teste e depois sair com apenas uma credencial de papel. Isso não ajuda ninguém e degrada a profissão e a metodologia. Realmente tem que ser algum componente de treinamento prático e prova de que, quando você está no centro do desenvolvimento, que você pode aplicar a metodologia de forma eficaz, que você tenha um histórico com Lean, Kanban ou Agile puro", diz West.

E quando se trata de certificação ou não, o indicador mais importante da perspicácia ágil de um profissional de TI são os resultados comprovados e demonstráveis ​​do mundo real, diz Staples.

"Quando vemos uma certificação, como um mestre de Scrum certificado, nós dizemos, isso é ótimo, mas também queremos que os candidatos o provem. Pedimos muitas questões difíceis, que mostrem que é possível  "fazer ágil" na prática, não apenas na teoria. Pode ser um problema se as pessoas puderem apresentar uma credencial de papel e, em seguida, não conseguirem desempenhar seu papel em uma situação do mundo real. E isso, na minha mente, é um crime ", diz Staples.

Dito isto, é útil ter conhecimento prático de algumas certificações Ágeis comuns, se você ainda está considerando uma mudança para uma metodologia ágil ou já está trabalhando. Mas lembre-se, assim como a certificação não garante que um candidato seja proficiente em Agile, contratar profissionais com credenciais de certificação não torna sua organização Agile, diz Doucette.

DevOps é uma resposta inevitável para uma TI cada vez mais complexa

Por Patrick Hubbard * 

Publicada em 22 de junho de 2017 no site CIO.

Alguns consideram o DevOps uma panaceia todo-poderosa, um paraíso cantado em versos em que o mundo das operações funciona sem atrito no éter insondável. Entretanto, a maioria dos administradores de rede e de aplicativos costuma adotar uma destas duas posições: "Sim. O DevOps é muito útil. O que há de tão surpreendente nisso?" ou "Não tenho tempo, paciência nem uma equipe para ficar fazendo vudu. Aqui nós trabalhamos de verdade." Existem muitos fornecedores demonstrando como seus produtos aceleram o DevOps, o passando direto para Agile, entrega contínua de redes e muito mais, sem pegar fôlego para atrair o interesse de equipes de TI empresariais para as quais o DevOps ainda é uma novidade.

Quando olho para a nossa equipe de TI interna aqui na SolarWinds, uma das mais conservadoras que conheci, percebo que também é possível para qualquer departamento de TI usar o DevOps para tornar-se um ativo vital para a empresa, e não apenas uma área de suporte. Na verdade, não temos escolha, já que ele está chegando a empresas de todos os portes, queiramos ou não.

A lentidão da TI é fatal

No caso da TI tradicional, procedimental e compartimentalizada, não é a pressão para resolver problemas com urgência nem o medo que os recursos se esgotem que destrói o entusiasmo da equipe. O que o destrói é o andamento moroso dos projetos. O que o gerenciamento de TI quase nunca entende é que não passamos um mês colocando novos racks de rede online porque queremos – fazemos isso porque projetos monolíticos, insatisfatoriamente projetados ou baseados em dados históricos incorrem em riscos, e a ferramenta de mitigação de riscos de TI aceitável na maioria das empresas é o trabalho de um comitê. Todos nós já passamos por isso. Projetos que deveriam levar aproximadamente dois dias para serem concluídos são discutidos por semanas em reuniões com pelo menos uma dezena de participantes presenciais e outros tantos no viva-voz.

A esta altura, aqueles que já sabem como se reunir ou trabalhar com um painel de tarefas podem estar torcendo o nariz, lembrando-se dos tempos difíceis, antes da adoção do Agile. Vocês diriam aos engenheiros de rede do exemplo acima: "Criem pequenas equipes para seus principais esforços e segmentem esses esforços em blocos de curto prazo. Não é difícil!" Mas a maioria de vocês pode estar pensando: "OK, devo admitir que estou começando a ouvir meus colegar falar sobre o DevOps, mas nem sei por onde começar." É compreensível.

Um exemplo pessoal

Nossa TI é incrivelmente avessa a riscos e, como resultado, muito tradicional. É fato que eles precisam gerenciar uma operação global, conformidade regulatória e muito mais, mas, em geral, tendem a não mexer em time que está ganhando (e isso não traz nenhum benefício ao resultado final). Portanto, quando eles adotaram práticas de DevOps de livre e espontânea vontade, isso chamou minha atenção.  Seu primeiro sucesso foi migrar a arquitetura de servidor IIS^™ no CoLos para entrega contínua.

A equipe de operações estava gerenciando cerca de uma centena de instâncias de IIS em uma variedade de funções, a maioria manualmente, desde a porta de entrada do site .com até serviços de informações, proxies, balanceadores de carga e muito mais. Pode-se comprovar a adequação do IIS como um todo, mas o WindowsServer^® em que ele reside deixa alguns administradores nervosos. Existem permissões e patches, incerteza na detecção de intrusos e intranquilidade quanto ao que fazer caso um estado atípico seja detectado.

A equipe existente, e não jovens profissionais terceirizados cheios de si, aprendeu algumas fórmulas do Chef e do Ruby. Eles criaram redes de desenvolvimento/teste/preparação em que imagens de máquinas foram criadas, testadas e empacotadas por scripts.  Delegaram a configuração de scripts da equipe de rede para especialistas em aplicativos, virtualização e armazenamento.  Criaram pequenas equipes multifuncionais para supervisionar o projeto e acabaram se surpreendendo com algo incrível. Toda noite, em um horário programado e sem interação humana, batalhões inteiros de novas máquinas com IIS eram executados, testados na produção e adicionados aos pools dos balanceadores de cargas. Servidores existentes eram extraídos dos pools e limpos, e seus IPs liberados de forma programática pelo IPAM. A equipe de operações podia contar automaticamente com servidores IIS/Windows Servers totalmente novos todos os dias. 

Mais do que um feito épico e um projeto de sucesso para a equipe, o primeiro projeto conseguiu o impossível: encantou o gerenciamento. Ele demonstrou o benefício real do DevOps na produção, ou seja, rapidez sem afobação. O DevOps reduziu significativamente os ciclos de implantação sem exigir o aumento do número de funcionários e, ao mesmo tempo, reduziu os riscos por meio da automação. Esse é o ponto alto em rapidez segura e eficiente, que torna a adoção do DevOps aceitável até para os mais céticos. 

A parte do "senão..."

A principal meta do DevOps é a rapidez mas, infelizmente, as mudanças nas organizações de TI continuam sendo o aspecto mais lento em muitas empresas, ainda que a diretoria esteja em busca de agilidade. Atualmente, a habilidade de uma empresa de adaptar-se rapidamente em busca de novas oportunidades e novos fluxos de receita é o que a diferencia dos concorrentes. Cada vez mais, a liderança sênior está passando a ver a transição para o DevOps não mais como uma teoria, mas como uma ferramenta indispensável.

Se sua equipe de operações já começou a adotar os locatários centrais Agile do DevOps e seu gerente está relatando os benefícios reais para o CIO, você está no bom caminho.  Mas, para as equipes confinadas ao mundo tradicional da abordagem lenta e baseada em tíquetes o tempo está se esgotando. Mais cedo ou mais tarde, sua empresa perceberá as vantagens do DevOps e remodelará suas operações.

A mudança pode acontecer organicamente. Talvez sua liderança executiva aprenda algo com colegas de outras empresas, incentivando e capacitando sua equipe a aprender e explorar novas habilidades e técnicas. Ou talvez possa ser você a aproveitar uma oportunidade de ser independentemente estratégico, implementando novos processos e demonstrando um novo valor ou oportunidade. Ambos representam excelentes resultados. Mas a transição também pode vir abruptamente, com a chegada de um jovem CIO que já use o DevOps e que, em seis meses, substitua toda a equipe "herdada".

Assim, a meta é explorar como aproveitar as técnicas do DevOps, independentemente de você fazer parte do departamento de TI de uma empresa multinacional com 300 funcionários, liderar o departamento de rede de um grupo de administradores versáteis de uma empresa de médio porte ou trabalhar sozinho. Participe de um workshop de liberação do ceticismo e dê uma folheada em um livro sobre Agile. Pergunte-se se existe algum processo demorado e entediante de configuração manual de redes que seja um bom candidato à automação. Contate seus colegas em comunidades técnicas e pergunte o que funciona para eles. Aprenda um pouco de Perl, configure o Chef, experimente construir sistemas em seu laboratório a partir de scripts em vez de usar a linha de comando; é provável que você descubra por que as técnicas do DevOps são uma resposta inevitável para uma TI cada vez mais complexa, que é pressionada a fornecer redes e sistemas de forma rápida e confiável.

(*) Patrick Hubbard é gerente técnico da SolarWinds