Bruno Pereira

O InfoQ publicou uma discussão interessante sobre a escolha de perfis em um time ágil. Nesta discussão, alguns defendem que um time formado somente por especialistas seria mais performático do que um time formado somente por generalistas. Outros defendem a escolha de especialistas somente em último caso. Existem também os que defendem o meio termo.

Eu tenho uma opinião semelhante à do Scott Ambler:

One approach is to build a team with some people who are generalists and some who are specialists, the generalists provide the glue within the team and focus on the bigger picture whereas the specialists focus on the detailed complexities of your project. This works well because the strengths of generalists balance the weaknesses of specialists and vice versa, and it is often quite useful for a generalist to pair with a specialist because of this balance. A better approach would be to build a team comprised of people who are generalists with one or two specialties — generalizing specialists.

Eu acho que é legal ter um time equilibrado, onde os especialistas aos poucos vão melhorando habilidades diferentes de sua área principal. Não acho que necessariamente começar um time com especialistas seja uma má decisão, contanto que se estimule a versatilidade. Depois de algum tempo, especialistas multi-disciplinares podem aprender bastante uns com os outros e formar um time de excelente nível, com todos melhorando seu nível geral.

Eu particularmente estou numa fase em que estou tentando aprender bastante sobre áreas nas quais eu ainda não sou tão forte como gostaria (a área de client side por exemplo). Acredito que o mais importante é o sentimento de humildade quanto aos nossos conhecimentos e o desejo de sempre estar melhorando. A decisão de qual caminho traçar vai depender das estratégias e escolhas pessoais de cada um, mas a humildade e a busca pela melhora constante devem estar sempre presentes.

Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

Toda semana eu e o Silvano discutimos vários aspectos das nossas aplicações. Como melhorar algumas delas, novos componentes que podem trazer ganhos interessantes, mudanças de arquitetura, etc. Os principais objetivos são: trazer mais qualidade para os projetos e produtividade para a equipe.

Alguns meses atrás estávamos falando com freqüência sobre frameworks web. A maioria das aplicações na Globo ainda usa Struts 1.x. O Struts 1 foi por muitos anos o framework web padrão Java. Ele trouxe muitos ganhos interessantes, comparando com o desenvolvimento usando apenas Servlets + JSP.

Um ponto “fraco” do Struts 1 é que ele não tem nenhum suporte a componentes visuais. Toda a parte visual das aplicações fica por conta dos desenvolvedores, assim como os recursos “Web 2.0″. O problema é que desenvolver esta parte visual de forma customizada em todos os projetos é muito trabalhosa, não é produtiva. Com isso surgiram inúmeros frameworks mais modernos, com suporte visual muito mais rico, trazendo boa produtividade neste aspecto.

O fato é que com esta enorme gama de opções, não temos mais um framework que se destaque de forma absoluta sobre os outros. Temos várias opções para cada projeto. Entretanto, não dá para querer abraçar o mundo, então é comum que busquemos 1 ou 2 opções que nos atendam em quase todos os casos.

Na nossa equipe nós já temos uma aplicação com JSF, que na verdade foi concebida ano passado, antes da minha mudança de equipe. Eu estou usando o Wicket em um projeto pessoal e ainda estou aprendendo o framework, ainda não o domino a ponto de usá-lo de forma produtiva. Com alguma freqüência nós discutimos sobre estes 2 frameworks, e eu ainda tenho a opinião que descrevi anteriormente.

Neste escopo das discussões sobre JSF vs Wicket, também falamos algumas vezes sobre Rails e Grails. Algumas semanas atrás eu e o Silvano começamos a estudar Grails, e fizemos pequenas aplicações de exemplo. Eu já li inteiro este livro de Grails disponível no InfoQ. Ele estava aqui na minha lista de “Livros que quero ler quando tiver tempo”, mas já o movi para a lista de livros que li

Eu estou gostando bastante do Grails, pois ele é extremamente produtivo para aplicações nas quais eu acho que ele faz sentido. Você consegue em 2 dias desenvolver aplicações que provavelmente você demoraria 1 semana ou mais com frameworks Java tradicionais. Eu ainda não o utilizei o suficiente para saber os limites de uso do mesmo. Provavelmente para projetos com requisitos mais críticos de carga e customização das interfaces, ele já não será uma opção tão boa assim. Entretanto, em aplicações internas, com carga limitada e sem grandes necessidades de customização visual, ele é perfeito.

O próximo passo para mim é tentar utilizá-lo em casos mais complexos. Estou pensando seriamente em utilizá-lo no @dvogado.com, um software para advogados que eu desenvolvo no meu tempo vago, mas que está congelado há alguns meses por falta de tempo. Quando eu conseguir um pouco mais de tempo vou tentar implementá-lo com o Grails, e acho que consigo fazer isso bem rapidamente. O Grails atenderia bem à minha proposta de distribuir um pacote completo com tudo que o usuário precisa, tornando o deployment o mais simples possível. Com o Grails eu utilizaria o Jetty + HSQL que ele traz por padrão, e precisaria adicionar apenas o JDK no pacote.

Uma discussão muito interessante também é a de Grails vs Ruby on Rails, mas isso fica para um outro post em breve

Alguns anos atrás o TheServerSide era o meu site de tecnologia (e Java) preferido em geral. Muitas discussões interessantes rolavam por lá, tinha os Tech Talks, os simpósios, artigos, etc. Era muito bom para acompanhar o que estava acontecendo de importante na nossa área.

De uns tempos para cá, a qualidade do site despencou, e agora praticamente só noticiam coisas do tipo “XYZ was released”. Onde XYZ podia ser qualquer coisa. Framework, servidor de aplicações, biblioteca, livro, qualquer coisa. Muito raramente eu vejo alguma coisa que me motive a ler mais do que o título.

Já o InfoQ traz diariamente várias coisas pelas quais me interesso. Tem tanto conteúdo de qualidade que eu não consigo acompanhar a velocidade de divulgação das coisas. E isso é ótimo, pois sempre sei que encontrarei coisas boas para ler por lá. Uma coisa que eu gosto no InfoQ é que nele eu vejo muita coisa boa além de Java. Conteúdo sobre metodologias de desenvolvimento, outras linguagens, outras plataformas. Novidades que podem me agregar bastante coisa. Quase todas as vezes que sai alguma notícia “XYZ was released” no TheServerSide eu não ligo a mínima pro que tá sendo lançado. E se é algo que me interessa, eu rapidamente viria a saber do lançamento em algum outro lugar.

Uma coisa que o InfoQ e o TheServerSide têm em comum é que ambos foram fundados pelo Floyd Marinescu. O TheServerSide foi fundado no final de 99, e o InfoQ no começo de 2006. Floyd Marinescu deixou o TSS em agosto de 2005, então muito provavelmente sua saída teve significativo impacto na qualidade do site. Atualmente o TSS é o 4o site da minha lista de preferências, atrás do InfoQ, Artima e DeveloperWorks. Mas do jeito que a coisa está indo não sei se ele vai conseguir sobreviver por muito tempo.

Especialmente depois que eu comecei a escrever artigos pra Java Magazine, eu passei a reparar bastante nas formas de exposição de conteúdo técnico. Conseguir cativar um público de alto nível é muito difícil. Desenvolvedores, arquitetos e gerentes de software não têm muito tempo para desperdiçar, pois a quantidade de coisas a estudar é enorme. Para conseguir que um público assim leia o que você se propõe a escrever, você precisa escrever de forma precisa, mas também estimulante. Se você simplesmente jogar informações nos leitores, não vai conquistar o apreço deles e eles não continuarão acompanhando as suas publicações.

Uma coisa que eu tento fazer nos meus artigos é sempre mostrar a motivação por trás do que estou falando. Especialmente se for um tema polêmico ou controverso, é fundamental estimular a discussão das pessoas. Ninguém gosta de ouvir a “Voz do Brasil”, mas conheço muitas pessoas que gostam de ouvir a Band News, com a apresentação do Ricardo Boechat (eu sou uma dessas pessoas). Talvez as notícias presentes nos 2 programas sejam as mesmas. Entretanto, eu sempre me interesso pelas opiniões do Boechat, e eu nunca ouvi coisa mais enfadonha que a Voz do Brasil.

Comecei falando do InfoQ e terminarei falando sobre o mesmo. Este site é um belo exemplo de conteúdo técnico de qualidade, com temas que realmente atraem os leitores mais exigentes. O Floyd Marinescu parece uma excelente referência de como oferecer conteúdo para a nossa área.

Aos poucos venho começando a escrever meus artigos e também aqui no blog, e meu objetivo será sempre a linha do InfoQ. Conteúdo de qualidade com inteligência por trás. Quero escrever coisas que eu gostaria de ler se fosse outra pessoa escrevendo. Escrever bem é muito mais do que escrever corretamente. Espero conseguir atingir estes objetivos, e se possível ajudar a Java Magazine a ganhar cada vez mais qualidade. E é claro que sempre vou receber muito bem as críticas e opiniões de quem quiser colaborar nesta empreitada