Transcrevo abaixo a entrevista que realizamos para a revista TI Digital, onde tive a oportunidade de tecer comentários sobre métodos ágeis, engenharia de software, SOA e arquitetura de software.
1) Quando você começou a se interessar por metodologias ágeis? E por que?
Meu primeiro contato profissional com métodos ágeis foi em 1997, quando tive a oportunidade de experimentar algumas práticas técnicas do processo XP tais como Metáfora Sistêmica, Desenvolvimento Dirigido por Testes, Propriedade Coletiva de Código e Planejamento iterativo. Foi uma experiência rica e ao mesmo tempo desafiante, devido a um novo modelo cultural e radicalmente diferente dos métodos que trabalhava até o momento.
2) Em que momento pôde perceber que a aplicação de métodos ágeis ao desenvolvimento de projetos realmente ajuda e otimiza os processos de uma empresa?
Surpreendentemente, já percebi algumas melhorias concretas na primeira experiência profissional. Ao longo de outras oportunidades profissionais, também percebi pontos concretos de melhorias. Também devo reconhecer que sem apoio executivo e um ambiente de transparência entre adquirentes e contratados, métodos ágeis podem não funcionar. As situações que vivi de fracasso do uso de métodos ágeis estavam relacionados a estes sintomas, que ocorrem em empresas com baixo nível de confiança.
3) Quais as funções de um gerente ágil de projetos? Ele precisa ser especialista em alguma metodologia ágil (como ser Scrum Master, por exemplo)?
A primeira e mais importante função é potencializar o seu time de trabalho. Potencializar o seu time significa fornecer uma liderança tão clara sobre os objetivos do projeto que o time verá estes objetivos como seus próprios objetivos. Times potencializados são auto-gerenciáveis, responsáveis e organizados. Eles trabalham de forma pragmática para atingir as metas do projeto em um ambiente muitas vezes adverso. Uma outra função importante do gerente ágil de projetos é ser confiável. Defino confiança aqui como intenções claras e saudáveis, postura ética, competência profissional e demonstração contínua de bons resultados. Um gerente ágil também deve ser um líder servidor e não um chefe autocrático. Sobre o conhecimento de métodos ágeis, eles são sem dúvidas valiosos, mas devem ser usados como ferramentas responsáveis de trabalho e não como instrumentos de auto-promoção ou de vaidade profissional para estampar uma assinatura de email.
4) Dentre as metodologias ágeis mais famosas e utilizadas para gerenciamento de projetos web, como a XP e a Scrum, quais você considera mais eficientes para projetos de pequeno, médio e grande portes?
Nenhum método de mercado é suficiente às necessidades de uma empresa, que é um organismo único e complexo. Devemos entender que métodos como o OpenUP, XP e Scrum tem objetivos diferentes e limitados ao contexto onde foram pensados. O OpenUP traz para os métodos ágeis uma disciplina de mitigação formal de riscos e outras boas práticas de métodos como o UP. O SCRUM tem como foco de preocupação aspectos de gerenciamento, enquanto o XP tem maior enfoque em práticas técnicas. A cultura antropofágica, tão bem colocado no manifesto antropofágico de Oswald de Andrade ainda nos anos 20, sintetiza a minha opinião sobre o melhor método ágil. Oswald de Andrade dizia que devemos devorar culturalmente as técnicas importadas para reelaborá-las com autonomia, convertendo-as em um produto de classe mundial. Em minha opinião, portanto, o melhor método é aquele que foi realmente personalizado à cultura local da sua organização. Se eduque formalmente em métodos como o FDD, Crystal Clear, Scrum, XP, Open UP, entre outros, e compile o melhor que existem neles à sua realidade local e cultural.
5) Até que ponto é complicado aplicar uma metodologia ágil em uma empresa em que toda a equipe está acostumada a trabalhar de forma informal, organizada através de seus próprios métodos?
Da minha experiência com implantação de processos, vejo que a mudança cultural de times é o elemento mais complexo ao uso de métodos ágeis. A nossa cultura escolar na universidade é de ênfase ao desenvolvimento do quociente intelectual, com pouca ênfase do quociente emocional. Método ágeis requerem que as pessoas tenham um bom quociente emocional, pois elas devem se comunicar permanentemente, trabalhar em equipe, saber ouvir, estabelecer e cumprir metas e subverter interesses puramente particulares (como ler emails particulares, abrir o Orkut ou bater papo no MSN) aos interesses da empresa durante o horário de trabalho. Desta forma, promover treinamentos de liderança para os gerentes e desenvolver práticas de aumento do quociente emocional dos funcionários podem nos ajudar a implementar métodos ágeis em organizações acostumadas à informalidade e à desorganização.
6) Para a empresa que deseja implantar uma metodologia ágil para gerenciar seus projetos, onde ela deve buscar ajuda?O ideal é investir em um profissional já contratado ou contratar um especialista temporário para aplicar as práticas na empresa?
Como citei anteriormente, vejo que o primeira passo é no desenvolvimento emocional dos funcionários. Possuir funcionários éticos, comprometidos e que realmente saibam trabalhar em equipe é fundamental. O segundo passo é olhar as experiências do mercado. Buscar casos de sucesso (e de fracasso) e conversar diretamente com gerentes de empresas que estejam querendo usar métodos ágeis para a melhoria organizacional. Finalmente, a busca por bons consultores ou de profissionais com experiência é um grande acelerador e pode sem dúvida evitar armadilhas comuns na implementação de métodos ágeis.
7) Você treina equipes para que sejam conduzidas por alguma metodologia ágil? Poderia contar algum caso de sucesso em empresa que aplicou alguma metodologia?
Trabalhamos sim com a capacitação de times em métodos ágeis, dentro de um processo participativo composto por oficinas, personalização de método e acompanhamento de times. Uma experiência interessante que gostaria de compartilhar aqui ocorreu ainda em 2001, quando fomos chamados para apoiar a implementação de melhores práticas de desenvolvimento para um centro de computação de uma grande universidade Brasileira. O trabalho foi bem desafiante e envolveu uma grande mudança cultural dentro de um ambiente ainda habituada a métodos clássicos de desenvolvimento. Ao longo de alguns meses de trabalho, conseguimos resultados bem interessantes que permitiram uma implantação de uma cultural de planejamento e entrega iterativa de software, geração contínua de valor (manifestada através de executáveis J2EE semanais) e práticas técnicas diversas que ainda hoje permanecem nesta organização. Ao longo dos anos, pudemos desenvolver outros casos interessantes, aprender com os erros e mais recentemente temos nos especializado em métodos ágeis dentro das disciplinas de governança de TI e arquiteturas corporativas. Os resultados recentes de uso dos métodos ágeis dentro do contexto de arquitetura corporativa tem sido muito estimulantes e o retorno de nossos clientes tem sido muito positivo.
8 ) Qual a diferença de Processo de Software para Metodologia Ágil?
Um método ágil é qualquer método de trabalho fundamentado no manifesto ágil e seus princípios. O manifesto nos diz: ” – Indivíduos e interações são mais importantes que processos e ferramentas. – Software funcional é mais importante que uma documentação completa. – Relacionamentos com clientes são mais importantes que negociação de contratos. – Responder a mudanças é mais importante que seguir um plano rígido. ” É importante notar que os métodos ágeis não são contra processos, ferramentas, documentação, contratos e planos. É apenas que os itens à esquerda do manifesto são mais importantes que os itens à direita. Também devemos também entender que um processo, seja ele de qualquer natureza, define uma ordenação temporal de atividades sendo executada por pessoas e que gerem produtos de trabalho. Dito isso, podemos diferenciar um método ágil de um processo na dimensão em que operam. Um método ágil opera na dimensão de valores e princípios ágeis, enquanto um processo opera na dimensão temporal, o que os torna complementares. Um processo pode estar baseado em um método ágil ou baseado em outros métodos.
9) A Arquitetura de Sistemas é tão importante quanto o desenvolvimento do sistema. Quais as práticas da Arquitetura de Software você considera mais importantes para o desenvolvimento web?
Absolutamente. Desenvolver um software sem o uso de práticas de arquitetura é como construir um prédio sem alicerces, projeto hidráulico ou projeto elétrico. Os resultados podem ser desastrosos. No âmbito de sistemas Web, onde muitas tecnologias complexas estão envolvidas, devemos buscar práticas de arquitetura em nossos projetos. Algumas práticas incluem: – Desenvolvimento da visão arquitetural – Definição de requisitos arquiteturais – Desenvolvimento dirigido por riscos – Desenvolvimento de prótotipos e provas de conceito para riscos altos no começo do projeto – Modelagem arquitetura – Acompanhamento de times para uma edificação arquitetural – Análise e avaliação de arquiteturas.
10) Você acha imprescindível que uma empresa de desenvolvimento web tenha um profissional arquiteto de software/sistemas contratado? Caso não tenha, qual a importância de os próprios desenvolvedores web terem noções de arquitetura de software/sistemas?
Seria sim desejável que toda empresa tivesse um arquiteto de software em seus projetos. Motivos de natureza econômica e de uma crônica falta de mão de obra qualificada em nosso mercado, entretanto, impedem que isso ocorra. Neste contexto, a educação dos times de desenvolvedores em práticas arquiteturais é extremamente bem-vinda e opera como um paleativo na ausência de um bom arquiteto de software no time. 11) Como se pode diferenciar Arquitetura de Software de Engenharia de Software? A arquitetura de software surge formalmente como uma especialização da disciplinas de análise e desenho ainda nos 90, baseado em experiências e observações de grandes projetos de software desde os anos 70. Neste contexto, a arquitetura de software pode ser vista como uma especialização da engenharia de software. Por outro lado, se observarmos o contexto da arquitetura corporativa, prática que opera como direcionadora de esforços de governança de TI, vemos que a arquitetura de software também é uma disciplina da arquitetura corporativa. Por exemplo, ao observarmos o TOGAF, corpo de conhecimento de arquitetura corporativa, vemos as seguintes disciplinas arquiteturais: arquitetura de negócio, arquitetura de dados, arquitetura de software e arquitetura tecnológica. Podemos definir e diferenciar a arquitetura de software, então, categorizando a arquitetura de software como uma disciplina da engenharia de software preocupada em definir e implementar a estratégia técnica de um projeto, garantindo o alinhamento às estratégias técnicas, econômicas, culturais e ambientais definidas na arquitetura corporativa de uma empresa.
12) Baseada na Engenharia de Software, surgiu a Engenharia Web. Como você poderia avaliar a importância de um engenheiro web em meio aos membros de uma equipe? Quais as principais funções de um engenheiro web?
Este engenheiro é também um papel importante em projetos de natureza Web, que possuem muitas particularidades. Suas principais funções estariam associadas a estas particularidades, que resumo aqui: – captura e definição de requisitos arquiteturais de acessibilidade, usabilidade, navegabilidade, controle de estado, desempenho, escalabilidade e segurança entre outras. – a aplicação de práticas de usabilidade e acessibilidade para a Web; – a aplicação de práticas de testes de desempenho e escalabilidade; – a aplicação de práticas de segurança e análise de vulnerabilidades de sites Web; – o conhecimento e aplicação de tecnologias Web tais como AJAX, Mash-Ups, RIA, WS-*, RS-*, entre outras
13) O SOA (Arquitetura Orientada a Serviços), é um estilo de Arquitetura de Software. Quando deve ser utilizado? O que é exatamente SOA?
Em verdade, SOA não é, conceitualmente, um estilo de arquitetura de software. SOA é definido como uma arquitetura de negócio e transcende a esfera da arquitetura de software, o que a torna muito mal compreendida. Primeiramente, deve ficar claro que SOA não é sobre Web Services. Vemos empresas que ao longo dos últimos anos criaram dezenas ou centenas de WebServices na ilusão de estarem implementado SOA, mas ao final apenas criaram uma malfadada arquitetura chamada JABOWS (ou Just a bunch of web services). Mas o que é SOA? SOA é um paradigma que busca alinhar e orientar os esforços de TI a partir da identificação, especificação e realização de serviços de negócio. Estes serviços devem ser governados e devem estar alinhados a processos de negócio e a capacidades de negócio. Desta forma, SOA deve estar alinhado a iniciativas de governança, iniciativas BPM (gerenciamento de processos de negócio) e também a iniciativas de arquitetura corporativa. Iniciativas SOA podem ser realizadas em empresas de porte médio ou grande e devem obrigatoriamente envolver as áreas de negócio e o corpo decisor de uma empresa (diretorias relevantes). Uma abordagem adequada para a implementação SOA é promovê-la em pequenos incrementos (iterações), onde cada incremento busque a organização de pequenos serviços de negócio governados e monitorados para que o benefício concreto trazido para as áreas de negócio possa ser aferido e possa sustentar novos ciclos de investimentos. Finalmente, deve ficar claro que SOA não é uma bala de prata que irá matar definitivamente os lobisomens alimentados ao longo de dezenas de anos pela ineficácia e pelo desalinhamento corporativo.
14) Em que as práticas do SOA se diferem da Arquitetura de Software e da Engenharia de Software?
Como SOA transcende a engenharia de software e a arquitetura de software, ele requer que outras práticas sejam aplicadas para o seu sucesso. Destaco três grandes diferenças: – a necessidade do uso de práticas de governança de TI; – a necessidade do uso de práticas de arquitetura corporativa; – a necessidade do uso de práticas de BPM. As práticas de governança, que podem ser ágeis, garantem um alinhamento real com os executivos das áreas de negócio alvo dos dos benefícios. As práticas de arquitetura corporativa, que também podem ser ágeis, garantem uma visão holística da arquitetura em termos das capacidades de negócio, dados e informações, sistemas de software e infra-estrutura tecnológica. Finalmente, as práticas de BPM garantem que uma vez que os processos corretos tenham sido identificados, eles possam ser modelados, medidos, governados e então melhorados.
15) Para o profissional que deseja se especializar em uma arquitetura, qual você recomendaria? Onde ele pode buscar auxílio para se especializar?
Primeiramente devemos saber que existem diversos tipos de arquitetura, tais como a arquitetura de software, arquitetura de aplicações Java, arquitetura de aplicações .NET, arquitetura tecnológica (ou de infra-estrutura), arquitetura de negócio, arquitetura de dados, arquitetura de soluções, arquitetura SOA, arquitetura de processos ou a arquitetura corporativa. Existe necessidade e demanda para todos estes papéis no nosso mercado e a busca depende do seu interesse e vocação. Como exemplo particular, comecei como arquiteto de aplicações Java, após uma carreira que começou com desenvolvimento e ao longo dos anos expandi a minha atuação para arquitetura de software e depois arquitetura corporativa. Todos estes trabalhos foram e são muito gratificantes e me trazem forte satisfação técnica e profissional. Profissionais com interesse em arquitetura devem buscar auxílios em bons centros de treinamento, em boas universidades e também nas oportunidades corporativas das empresas onde trabalham. Sobre a educação formal, uma dica é buscar centros de treinamento e universidades que tenham professores que realmente atuem como arquitetos. A experiência destes profissionais é muito rica. Sobre as oportunidades corporativas, o importante é olhar sempre os projetos através da lente da arquitetura. Um projeto de software sempre irá requerer uma estratégia técnica e esta é a oportunidade para o uso de práticas ágeis de arquitetura e um aprendizado concreto sobre práticas de arquitetura. Finalmente, é importante lembrar Umberto Eco sobre a necessidade de buscar sempre as fontes primárias para que possamos conhecer realmente um assunto. Ler textos clássicos sobre a arquitetura como engenharia, que existem já mais de 2000 anos, e também os clássicos da arquitetura de software que existem há 20 anos deve ser uma rotina para o arquiteto. No nosso meio, recomendo aos arquitetos que leiam textos arquiteturais de Mary Shaw, Phillipe Kruchten, Peter Eeles, Dana Bredemeyer, Grady Booch, Ivar Jacobson, Martin Fowler, Scott Ambler, Gerrit Muller, Len Bass, Paul Clements, Frederik Brooks, John Zachman e Barry Boehm, entre outros notáveis. Como diria Sir Isaac Newton: “Eu pude ver mais longe por que estava apoiado nos ombros de gigantes”.
