Posts Marcados Agile

Produtividade – Princípios

Continuando a série sobre produtividade, e antes de entrar em detalhes da nossa plataforma atual, vou relacionar alguns princípios que utilizo quando o assunto é produtividade.

  1. Uso de tecnologia de ponta – como citado no post anterior, eu acredito que a incorporação de uma nova tecnologia ou framework só deve ser feita quando há um ganho claro mensurável. Nossa indústria muda muito rapidamente e muitas frentes às vezes aclamadas como excelentes práticas podem cair em desuso daqui a alguns meses. Isto posto, é fundamental estar atualizado, pois a todo tempo surgem soluções ou práticas que definitivamente podem gerar ganhos de produtividade. Eu me considero um dos últimos dos “early-adopters”, ou seja, nossa plataforma usualmente tem quase tudo que é de ponta, porém normalmente não sou um dos primeiros a adotar uma determinada novidade.
  2. Dogmatismos e guerras religiosas – Na nossa indústria é muito comum encontrar pessoas que defendem práticas ou teorias simplesmente por elas terem sido definidas, não importando que finalidade ou benefício possa advir do uso delas. Minha visão sobre isto não poderia ser mais pragmática, acredito que temos que conhecer muito bem a teoria e os conceitos envolvidos, porém o uso é condicionado ao ganho que possa ser obtido. Mesmo que isto signifique “deturpar” uma teoria ou usar somente uma parte dela. Nosso negócio não é o purismo e sim a produtividade, portanto, pra mim, não há espaço para dogmatismos. Tenho vários exemplos sobre este tema. Um muito comum é sobre “modelos anêmicos”, que tentam fazer um purismo OO quando, na minha experiência, isto causa mais problemas do que ajuda (mais sobre isto no post da camada de domínio). Não tenho nenhum problema em ter uma visão procedural de serviços, se desta forma estamos sendo mais produtivos. Outra é sobre uso de “patterns” conhecidos. Muitas pessoas ficam olhando um problema e tentando identificar e classificar aquilo em um pattern quando algumas poucas linhas de código já poderiam ter resolvido o problema há muito tempo. Quanto mais patterns conhecermos melhor, mas se usar não é intuitivo, algo provavelmente não está certo.
  3. Complexidade – Desenvolver sistemas significa fazer tarefas complexas. Mas para mim, a complexidade deve estar sempre que possível escondida das tarefas do dia a dia. Por exemplo, um framework de domínio vai ter áreas muito complicadas para se projetar e construir. No entanto, usar um framework de domínio deve ser algo simples. A todo o tempo eu avalio o esforço para se esconder as complexidades de tarefas comuns e quando há um potencial, isto é feito. Claro que a tarefa tem que ser comum o suficiente para compensar o esforço de encapsulamento; não faz sentido fazer um framework para uma tela que será desenvolvida uma única vez. CRUDs são usualmente candidatos a usar frameworks, pois todos os sistemas possuem várias telas deste tipo. Um corolário disto é que se for possível automatizar algo com o uso de DSLs, eu vou considerar esta opção de maneira muito favorável. DSLs tornam as tarefas do dia a dia mais simples, então pra mim isto significa produtividade direta. Infelizmente fazer uma DSL ainda é algo muito complexo, e utilizar uma pronta que não tenha nenhuma área de conflito é raro – se ela não se encaixar bem, não vai ser produtivo usar. Um exemplo muito bem sucedido na nossa equipe é o ActiveWriter, que é uma DSL para se gerar entidades de domínio. Atualmente nossa plataforma de domínio está tão boa que nossos desenvolvedores quase que esquecem que ela está lá, trabalhando com uma interface gráfica para desenhar entidades e gerando a maior parte do código com geradores automáticos. Outros exemplos nesta linha são o uso de interfaces fluentes, operadores customizados e assim por diante.
  4. Manutenabilidade – Este é um conceito sujeito a muitas guerras religiosas. Para muitos desenvolvedores, a busca da uma manutenabilidade máxima é o objetivo final, mesmo que isto não seja necessário. Na minha visão, a manutenabilidade de um sistema moderno está ligada a duas áreas: facilidade de alterar interfaces e facilidade de entender e identificar as regras de negócio. As demais áreas complexas (frameworks, camadas de domínio etc.) serão complexas, não importa quão bem feitas sejam. Então não adianta tentar deixá-las super simples de dar manutenção; se a equipe que as projetou não estiver disponível, vai ser difícil alterar. Claro que boas práticas de programação devem ser usadas nestas áreas, mas daí a tentar fazer algo universalmente simples pode ser um esforço inviável. No meu caso, eu me preocupo com telas e regras de negócio. Em termos de regras, temos tido bastante sucesso, hoje temos sistemas legados de quase 10 anos que ainda são simples de ter regras de negócio alteradas. Telas são um pouco mais complexas, pois a tecnologia mudou muito nos últimos anos, mas mesmo assim temos tido um razoável sucesso. Mais sobre isto no post referente a interfaces.
  5. Linguagens Declarativas – Outro tema polêmico, linguagens declarativas são linguagens que se propões a dizer o que deve ser feito ao invés de como deve ser feito. Exemplos são linguagens como SQL ou XSLT e qualquer outra DSL. Na minha visão, este é um dos maiores fatores de produtividade, pra mim linguagens declarativas SEMPRE são ordens de grandeza mais produtivas do que linguagens imperativas (C# etc.). Assim, no nosso caso, muitas extrações são feitas em SQL direto. Ultimamente HQL também tem sido uma excelente opção. (Obs.: não acho que regras de negócio devam estar em stored procedures, já que regras de negócio são procedurais e portanto, imperativas por natureza). E no nosso caso, o uso de XSLT é prevalente nas interfaces. Apesar de ter uma curva de aprendizado significativa, a minha opinião é que o esforço para aprender XSLT é sempre é retornado muitas vezes em produtividade – mais sobre isto no post sobre interfaces.
  6. Perfil da Equipe – Por último, um tópico que foi abordado no post anterior. Minha opinião é de que ter pessoas inexperientes vai afetar negativamente a produtividade, em qualquer cenário. Como visto nos itens acima, trabalhamos com todas as tecnologias de ponta, o que significa uma grande formação básica necessária. Na nossa equipe é muito raro um novo membro, por mais experiente que seja, não ter um tempo de adaptação de um ou dois meses. Para desenvolvedores inexperientes, este tempo seria muito maior, afetando de maneira drástica a produtividade geral da equipe. Este é um grande problema pois profissionais bons são raros, e uma troca de pessoal freqüente também afeta de maneira significativa a produtividade. Não vejo solução para isto, o que faço atualmente é ter pessoas chaves liderando as equipes que possam absorver eventuais necessidades por troca de pessoal, mas esta troca inevitavelmente vai diminuir a produtividade.

O próximo post é sobre a camada de dados de de domínio. Até breve.

, , , , , , , , ,

Deixe um comentário

Produtividade – Introdução

Durante toda minha carreira a busca da produtividade no desenvolvimento de software tem sido uma constante. Afinal, desenvolver software de qualidade em pouco tempo é o objetivo de todo desenvolvedor.

A busca pela produtividade começa lá na faculdade, quando aprendemos Orientação à Objeto. A promessa de reuso de classes cria a idéia de que a programação OO já é naturalmente mais produtiva. E conforme vamos evoluindo, passamos a conhecer frameworks, plataformas e até geradores de sistemas, todos com a promessa de ser o holly grail de produtividade. Some-se a isto a idéia de que processos podem ajudar no sentido de que tarefas simples possam ser executadas por pessoas inexperientes, todas contribuindo para fazer software bom e rápido, e temos o cenário atual da indústria de desenvolvimento de software.

Depois de alguns anos a gente começa a separar o joio do trigo e ver que esta questão é extremamente complexa, muito mais do que conseguimos perceber no início da nossa carreira. Tecnologia ajuda, mas de maneira nenhuma garante produtividade (muitas vezes, é o contrário). Processos idem, muitas vezes geram mais tempo perdido do que economizam. Esta série é sobre minha visão atual a respeito de produtividade, minha e da minha equipe. De maneira nenhuma acho que esta é uma receita universal que possa ser aplicada a qualquer time. Muito ao contrário, acho que cada time tem características e pontos fortes que serão mais expressivos com determinado conjunto de ferramentas e processos.

É importante notar que em todos os itens a minha visão é muito pragmática. Conhecer teoria é importante, mas ela evolui e conceitos de hoje podem não ser os de amanhã. Assim para eu usar algo, eu tenho que perceber um ganho imediato, nos desenvolvimentos sendo realizados. Usar tecnologias ou processos porque alguém diz que é legal ou pela promessa de um dia gerar algum ganho não é algo que eu faço. Mas, é claro que é muito importante estar atualizado. Por exemplo, esta semana estou adaptando a nossa infra-estrutura para usar um tipo de validação baseado em jQuery que me foi recomendada por um membro da equipe e que faz todo o sentido e vai gerar produtividade hoje.

Assim, em uma série de posts, vou descrever o que eu adoto como infra-estrutura para as aplicações desenvolvidas pela nossa equipe e minha opinião sobre a razão para usar e como estão sendo utilizadas. Ao final, um post sobre o nosso estágio atual e o que ainda estamos sentido falta.

Uma conclusão, no entanto, é clara para mim. O desenvolvimento de aplicações de médio ou grande porte é muito complexo – e não sei se um dia vai se tornar simples. Ser produtivo implica em utilizar uma série de tecnologias e conceitos que não são fáceis de aprender. Assim, não é possível ter gente inexperiente e ser produtivo ao mesmo tempo. Isto é assunto para um post específico também, mas adiantando, não acredito que haja, no desenvolvimento de sistemas, tarefas simples o suficiente para ocupar pessoas inexperientes por completo. No mínimo, uma grande supervisão é necessária, o que por si só já diminui a produtividade. Claro que treinar é necessário, mas hoje eu separo muito bem o trabalho de produção do de treinamento. Se há treinamento envolvido, a produtividade vai cair, sempre. Isto parece óbvio, mas foram muitos anos até que esta conclusão fosse assimilada.

O próximo post é sobre princípios gerais de produtividade que eu aplico.

, , , , ,

Deixe um comentário

O fim do arquiteto?

Nas últimas semanas tenho participado de várias discussões internas e em listas de discussão sobre composição de times de desenvolvimento. Este é um assunto especialmente interessante, pois a qualidade ou o custo do software que construímos é ultimamente o resultado da qualidade e do custo do time que o construiu.

A característica de rapidez da evolução da plataforma tecnológica de desenvolvimento faz com que se manter atualizado exija uma super especialização. Isto é muito difícil de ser feito e as pessoas com mais experiência e que conseguem se manter atualizadas acabam sendo conhecidas como “arquitetos” (categoria na qual eu me incluo). Elas dominam as múltiplas áreas de conhecimento de desenvolvimento e conseguem definir e ensinar como aplicar padrões e tecnologias de maneira adequada. No entanto, na minha visão, um dos maiores riscos deste grupo é que adotemos a busca da atualização tecnológica como o nosso principal e único objetivo e esqueçamos que na verdade o nosso objetivo é fazer software bom a um custo viável. Afinal, usualmente, o cliente não está interessado se o sistema dele é .NET, Java, usa DDD ou não, é feito via TDD ou não; o que ele quer é algo que ele perceba valor (ou seja, bom!) e que ele pague um custo que ele ache justo pra construir e manter o sistema.

Acho que no fundo, todos nós sabemos disto, já que provavelmente iniciamos nossa carreira fazendo algum sistema para alguém. Ocorre que quando as empresas vão crescendo, surge uma dificuldade de escala, já que temos que fazer um volume cada vez maior de horas de desenvolvimento. E, ao contratar mais pessoas, começam a existir os problemas usuais do desenvolvimento em equipe: aumento de custo e queda de qualidade. Várias alternativas têm sido propostas para lidar com isto, ligadas à própria origem da “Engenharia de Software” como disciplina, há décadas atrás. É muito interessante reler o livro “The Mythical Man-Month”, do Brooks. Os problemas que ele descreve na década de 60 sobre desenvolvimento baseado em Mainframe (!!) são praticamente os mesmos de hoje!

A abordagem mais em voga atualmente para lidar com o problema de escala é montar uma equipe hierárquica, normalmente sob coordenação de um gerente de projeto (nas maiores empresas, um PMP) e composta por pelo menos um arquiteto e um conjunto de desenvolvedores com mais e menos experiência (seniores e juniores). E usar um processo definido para garantir que os mínimos padrões de qualidade sejam atingidos e o custo controlado. Neste modelo, tenta-se diminuir o custo usando-se mais juniores e tentando evoluí-los com treinamento durante o desenvolvimento. Eu mesmo fui adepto deste modelo por muito tempo, mas confesso que, após muitos anos de tentativas, estou muito desapontado com os resultados. A cada vez os custos de produção aumentam, a qualidade continua ligada a somente a quem está construindo (e não ao processo) e manter um grau de satisfação na equipe é complicado. A tal ponto de que passei a não mais acreditar neste modelo e partir para a adoção de uma metodologia ágil.

Em desenvolvimento ágil as equipes são sempre pequenas e não há uma hierarquia rígida (há um líder técnico somente). O ciclo de entregas é curto e a preocupação com valor sendo entregue é o mais importante. Embora isto resolva vários problemas do desenvolvimento em equipe, ele tem um problema crítico de escala também, já que para grandes projetos seriam necessárias várias equipes e a orquestração disto não é trivial.

Neste cenário, estamos tentando ver como compor estas equipes ágeis. Tivemos várias experiências mal sucedidas com desenvolvedores menos experientes. O desenvolvimento ágil pressupõe muita autonomia e é difícil garantir qualidade e custo com juniores, já que o processo é bem leve e não há a preocupação com o treinamento em si. Alguns propõem o pair-programming como solução, porém algumas tentativas que fizemos nesta linha não foram também bem sucedidas. Isto tem nos feito buscar equipes somente com desenvolvedores super experientes. Ainda que sejam mais caros, os resultados têm sido melhores com um custo geral mais baixo. O desafio tem sido encontrar pessoas experientes que estejam dispostas a trabalhar em todos os aspectos da aplicação – que incluem CRUDs, relatórios etc. – e não somente na parte “legal” de infra ou interfaces avançadas.

Desta forma, perde-se um pouco o sentido de se ter pessoas só com o papel de arquiteto na equipe. Na verdade, cada um deve estar preocupado todo o tempo com as soluções dadas e participar de novas decisões, contribuindo com o resultado final do projeto. Acredito que este seja um modelo mais interessante, pois a ausência de um arquiteto formal faz com que os desenvolvedores se sintam mais livres para contribuir e assumam melhor esta responsabilidade. Claro que isto só é possível se cada desenvolver for capaz de contribuir desta forma e para isto, cada um deve de fato ser também um arquiteto!

Com isto, voltamos mais à maneira de como começamos, quando desenvolvíamos sozinhos. Se o sucesso que tínhamos lá puder ser refletido também nesta forma de trabalho em equipe, vamos estar no caminho certo!

, , , , ,

1 comentário