Posts Marcados Ágil

White Fox: O Início

Após a definição do conceito do que buscava nesta minha nova empreitada, a White Fox está finalmente pronta e iniciou suas operações oficialmente este mês! É sempre algo muito especial participar da construção de uma empresa nova; mais especial ainda quando é uma empresa que representa um ideal buscado por muito tempo. Claro que iniciar uma empresa é sempre muito trabalho, muitos trâmites burocráticos, investimentos, implantação de toda a parte de infra-estrutura (ambiente, rede, telefonia etc.) e planejamento financeiro, tudo isto simultaneamente às atividades cotidianas e com uma equipe mínima! Muito cansativo, mas está valendo muito!

Estamos conseguindo começar com um time pequeno, mas totalmente alinhado ao conceito do que queremos para a empresa. Estamos também definindo os contratos de prestação de serviço com os clientes existentes para adaptá-los 100% a um formato ágil. Há uma grande necessidade de negociação, pois, por maior que seja a maturidade deles, sempre é complicado definir um contrato baseado neste tipo de desenvolvimento. Estamos tendo sucesso até agora e acredito que esta experiência vai tornar mais fácil a negociação com novos clientes.

Apesar de contarmos com uma grande vantagem inicial, que é a existência de clientes ativos, a White Fox vai agora encarar desafios bem importantes para se manter e crescer. Na minha visão, os problemas mais difíceis são a definição do processo de prospecção/venda mantendo o resultado, a gestão do crescimento e a definição de um processo interno de desenvolvimento. A questão da prospecção/venda é a mais difícil de ser equacionada. Prospectar significa ter tempo livre, fazer concessões a potenciais clientes (consultorias, análises, demonstrações) para que seja possível mostrar o nosso serviço e permitir que eventualmente seja fechado um contrato de desenvolvimento. Porém, este processo é caro já que o tempo investido é um tempo que deixa de ser aplicado no atendimento de clientes existentes e que, portanto, deixa de gerar receita. E um modelo agile prevê uma confiança enorme da contratante na contratada, o que faz com que muitas prospecções, para funcionar, exijam um grande investimento. Desta forma, prospectar pode significar comprometer grande parte, senão todo, o resultado obtido nos projetos em andamento para tentar trazer clientes novos. Assim, isto é algo que tem que ser pesado com muito cuidado e o que estamos fazendo é praticamente “escolhendo a dedo” os potenciais clientes que achamos que vale a pena prospectar. O lado negativo é que o crescimento é extremamente lento.

A gestão do crescimento é outro grande desafio. Encontrar profissionais prontos com o nível que necessitamos na White Fox é uma tarefa quase impossível. Encontrar pessoal com potencial é bem mais simples, porém treinar alguém com potencial até que esteja no ponto necessário é algo demorado e caro. E escolher o momento de incluir alguém também é algo que exige grande cuidado, já que para prospectar é necessário ter algum tempo livre de pessoas excelentes; no entanto a prospecção é lenta e o treinamento também, assim estes custos podem comprometer completamente o resultado de um período. Estamos tentando balancear isto com um programa de estágio para tentar identificar pessoas com grande potencial e ter um tempo de treinamento mais longo e com isto conseguir um tempo maior para prospecção.

O outro desafio que eu vejo é com relação à gestão interna do processo de desenvolvimento. Nós. por princípio temos uma equipe muito pequena, mas ainda assim é necessário um fluxo de trabalho que garanta o andamento das atividades básicas. Além disto, todos os clientes exigem algum tipo de contabilidade para a gestão de custos, o que significa que tudo o que fazemos deve ser de alguma maneira registrado e totalizado para efeito de faturamento. E como quase todos os nossos projetos são muito antigos, temos que funcionar bem com a manutenção e evolução de sistemas legados de qualidade variada. O que temos feito é dedicar um tempo na busca e definição de metodologia e ferramentas para nos apoiar nesta gestão. Gostamos muito do Scrum mas ele não é aplicável a projetos de manutenção. Da mesma forma, a maior parte das ferramentas de gestão de processos ágeis existentes deixa muito a desejar nesta parte de manutenção e contabilização. Estamos avaliando várias e considerando também a possibilidade de desenvolvimento de uma nossa, simples, mas quer iria atender por completo as nossas necessidades. Acredito que nas próximas semanas nós iremos chegar a uma definição.

No mais, muito trabalho, mas com uma equipe muito motivada. Estamos adotando uma postura minimalista com relação à parte administrativa e financeira; terceirizando quase tudo e adotando práticas que simplifiquem isto ao máximo. O mesmo vale para a parte de infra-estrutura, estamos utilizando quase tudo na Cloud; a única exceção é o source-control, que ainda assim fica em um espaço contratado de um datacenter. Conforme fomos evoluindo vou postando aqui as soluções e caminhos que adotamos. Até a próxima!

, , , , ,

3 Comentários

Refatorando Grandes Sistemas

Olá, feliz 2010! Eu estou muito animado, as perspectivas para 2010 são muito boas! Fiquei agradavelmente surpreso com a reação das pessoas à White Fox, ela foi muito bem recebida e recebi várias mensagens de apoio, obrigado! Estou muito convicto de estar no caminho certo e construindo uma empresa que será um local excepcional para se trabalhar e prosperar. E o ano começa animado, este mês estamos entregando 2 primeiras versões de novos sistemas além de continuarmos com a manutenção dos existentes.

Conversando com um amigo na semana passada, caímos no assunto de grandes sistemas e do processo necessário à manutenção (evolutiva ou corretiva) para sistemas de grande porte em geral. O que me levou a refletir sobre isto pois, apesar de achar que processos e especialização por segmentos (silos) no desenvolvimento de software seja algo nocivo, não consegui achar nada de errado ou que eu faria diferente naquele caso específico.

O ponto é que grandes sistemas necessariamente exigem uma grande infra-estrutura. Por menor que seja uma mudança, para se garantir que um sistema não seja afetado por ela, é necessário avaliar todo o impacto, preparar uma sequência de testes específicos para a mudança e executar todo o conjunto de testes de integração e funcionais – muitos dos quais, até pelo volume, podem não ser totalmente automatizados. Isto sem falar no processo de liberação de versão em si, que envolve muitas vezes compilações e execuções de testes unitários que podem demorar várias horas. Em um time agile, mesmo com o máximo de automatização, este processo todo iria significar que o time iria passar a menor parte do tempo implementando a mudança e a maior parte do tempo, planejando, testando, integrando e verificando se tudo ficou ok. Não é algo viável, na minha visão. Acho que é por isto que o pessoal de Scrum afirma que Scrum é para novos projetos somente, não sendo adequado para manutenções.

Então o que fazer? Será que para grandes sistemas não é possível usar métodos ágeis? Ou que temos que assumir que para grandes sistemas, irão existir silos (testes e/ou gestão de configuração, por exemplo) e que isto é algo que não tem solução? Os que me conhecem sabem que esta resposta não é satisfatória pra mim. Porém, uma vez que o sistema tenha um certo tamanho, não consigo ver como fazer as coisas diferentes. Talvez então a saída seja não deixar os sistemas passarem de um tamanho crítico.

Claro que certas áreas exigem software de grande porte. O caso de um sistema operacional como o Windows, um aplicativo como o SAP ou mesmo um aplicativo como o Word, são sistemas que irão exigir toda uma infra-estrutura pesada para permitir manutenção e evolução. Não é à toa que o processo de testes da Microsoft, por exemplo, é algo extenso e complicado. Porém, não acho que isto deva ser usado para software de menor porte. Aliás, acho justamente o contrário, usar este tipo de técnica/processo para software de menor porte significa aumentar em ordens de grandeza o custo para desenvolvimento/manutenção e dificultar significativamente o uso de metodologias ágeis.

Assim, quando possível, acho que devíamos buscar quebrar grandes sistemas em aplicações menores. Usando os mesmos princípios aplicados em refatoração de código (tais como responsabilidade única, baixo acoplamento etc.), poderíamos tentar quebrar os sistemas em módulos para que, apesar de funcionarem em conjunto, sejam entidades separadas. Isto seria possível com uma definição clara de fronteiras, com o apoio de interfaces de serviços (SOA) e com um isolamento de interfaces com o usuário. Áreas de negócio distintas poderiam ser separadas de maneira que o domínio de negócio fosse separado, fazendo com que mudanças em um determinado setor do domínio não afetasse os demais. E mudanças na interface de serviços poderiam ser feitas de maneira versionada e evolutiva, no formato tipicamente usado em SOA.

Claro que uma refatoração de sistema só é possível com a participação direta do cliente, já que isto significa por si só uma mudança em processos, modo de trabalho e até mesmo na relação comercial, já que diversos módulos podem também significar mais de um fornecedor. Mas acredito que se isto gerar uma economia significativa no custo de desenvolvimento, será algo que terá grandes chances de ser adotado pelo cliente. O que mais uma vez ressalta a importância da área de contato com o cliente deter também todo o conhecimento técnico para propor e justificar mudanças como esta. Uma área puramente comercial teria muitas dificuldades em entender e vender algo deste tipo. Felizmente este não é o caso da White Fox.

Na White Fox nós temos alguns sistemas que estão começando a entrar no estágio em que a manutenção está começando a ficar cara, talvez seja este o momento de se pensar em uma refatoração deste tipo. Irei tentar colocar algo assim em prática e vou postando os resultados aqui. Novamente, um feliz 2010 para todos!

, , ,

1 comentário

White Fox: O Conceito

Nestes mais de 15 anos de carreira, meu sonho sempre foi ter meu próprio negócio, uma empresa de desenvolvimento de software que fosse algo diferente e reconhecida pela qualidade do seu pessoal e de seus produtos. Nestes anos, eu tive algumas empresas, todas buscando atingir esta meta, porém, por várias razões, nenhuma delas chegou a atingir este ideal.

Sonhos não morrem, eles permanecem no inconsciente e em momentos propícios, voltam com toda a força. E mais uma vez, está chegando a hora de tentar de novo e atingir o meu ideal. Estou na fase de concepção de uma nova empresa, a White Fox Consultoria e Desenvolvimento de Software. Neste post quero falar um pouco sobre o que estou buscando, quais as motivações e que valores eu estou trazendo para esta nova empresa.

Desta vez acho que tenho grandes chances de atingir meu sonho. Em todos estes anos, eu tive a oportunidade de ver o que funciona e o que não funciona na gestão de uma empresa de desenvolvimento, tanto em aspectos de relação interpessoal quanto na parte de resultados e controle. Acredito que esta experiência, acumulada com muitos erros e acertos (quero crer que tenham sido mais acertos do que erros), é essencial para que a White Fox possa ter sucesso.

Uma das lições mais importantes que eu aprendi é que para que uma pequena empresa tenha sucesso, os seus sócios devem fazer mais do que gerir. Não tenho dúvida que administrar bem em todos os aspectos (especialmente o financeiro) é fundamental para o sucesso. Porém isto não é nem de longe o suficiente. Pois por melhor que seja, um bom gerente administrativo não é capaz de trazer aquilo que cada vez mais eu acho que seja o mais importante: a paixão pelo que se faz, a inspiração para si e para seu time de fazer o melhor e buscar o melhor sempre, o orgulho e o prazer de se estar fazendo algo excepcional. E tudo isto só é possível quando o líder consegue ser a representação disto para todo o time; desta forma ele tem que ser (ou pelo menos ter sido) antes de tudo, um excelente técnico.

Assim, a White Fox está sendo concebida com o melhor de todos estes mundos. A paixão por desenvolvimento e tecnologia é o que move cada integrante da nova empresa. A gestão transparente e minimalista garante que todo o esforço seja voltado para o negócio da empresa, que é fazer bom software para seus clientes. E um time ultra-selecionado, com os melhores profissionais da área produz a mistura que irá permitir que ela tenha muito sucesso.

A White Fox traz alguns conceitos pouco usuais na nossa área. Um deles é que o time seja realmente formado por somente arquitetos/seniores, do tipo que é capaz de fazer um sistema do zero em pouco tempo e que é capaz de atuar em todos os aspectos de um sistema, do banco de dados à interface, passando pela gestão de atividades e pela interação com o cliente. A excelência técnica e o pragmatismo são as características mais relevantes dos membros do time da White Fox. Outro conceito é que cada integrante é um sócio na empresa, sendo responsável pelas decisões da sua alçada e recebendo uma parcela do resultado geral do negócio. Finalmente, iremos buscar um ambiente de trabalho extremamente agradável, sem nenhum tipo de burocracia desnecessária. A idéia é fazer da White Fox o local ideal de trabalho para um desenvolvedor.

O formato de desenvolvimento é o agile. Fortemente baseado no Scrum, mas sem ser Scrum, a empresa irá ter como missão produzir com software com ROI extremamente vantajoso para os seus clientes. O formato implica também uma certa maturidade do cliente. Contratar no formato agile significar que o cliente é também parte do desenvolvimento e o sucesso de qualquer projeto é diretamente proporcional à qualidade e envolvimento do pessoal do cliente. Claro que este formato não é para todos, mas para os que se encaixarem neste perfil, a recompensa será software sendo desenvolvido de maneira rápida e com um ROI excepcional.

Outro diferencial é emprego de um framework de desenvolvimento em todos os produtos construídos. Este framework tem sido evoluído ao longo de vários anos e agora está maduro o suficiente para permitir o desenvolvimento incrivelmente rápido de sistemas sem nenhum sacrifício de usabilidade ou manutenabilidade. O uso e padronização do framework no desenvolvimento da White Fox facilita também o treinamento de pessoal e a manutenção de todos os sistemas produzidos. E, pela qualidade das pessoas do time, o framework vai sendo evoluído a todo tempo para permitir ainda mais velocidade e qualidade final.

A empresa será lançada oficialmente no início do ano que vem. Extra oficialmente ela já está a todo vapor, o time inicial está definido e ela já tem faturamento suficiente para garantir o início das operações. O web site está sendo construído para representar todos estes valores e os clientes estão sendo apresentados à esta nova forma de trabalho (com muito sucesso até agora!). Antes que perguntem sobre o nome, Fox é uma palavra de relevância especial para mim, ligada à agilidade que quero representar. A cor branca transmite simplicidade, clareza e transparência. O logo final está abaixo:

 

logowhitefox

 

Se você se identificou com este sonho e quiser fazer parte deste empreendimento, me mande um email. O time inicial está pronto, mas a perspectiva é de crescimento rápido. Aguardem então para mais notícias sobre o andamento desta nova empresa!

, , , , ,

3 Comentários

Profissão Codificador

Acho que a carreira de muitos de nós, programadores, começa de maneira similar: usualmente em algum momento da adolescência temos contato com computadores, ficamos fascinados por eles (na minha época foi um Gradiente Hotbit MSX, com programação BASIC) e a partir daí começamos a programar. E se você está lendo este blog, é grande chance de que nunca mais você tenha parado!

Mas me pergunto como será o nosso futuro nesta carreira. Tirando os que mudam de área (viram gestores, analistas de “negócio”, instrutores ou simplesmente vão fazer outra coisa) ou os que passaram em concurso público (este é um assunto que eu nem vou entrar!), eu fico imaginando como seria o futuro dos que continuam a programar. Alguns se tornam consultores independentes famosos, o que irá garantir uma aposentadoria tranquila escrevendo livros, artigos e ministrando palestras. Mas acho que  atualmente a maioria dos bons codificadores trabalha no esquema de pessoa jurídica, para um ou mais clientes e vive da capacidade de horas que consegue fazer. E até quando? Em algum momento isto vai ficar cansativo, ou ele vai se desatualizar e vai sair do mercado (interessante que, salvo raras exceções esta ainda é uma área quase 100% masculina… mas isto é assunto pra outro post!). E qual será o destino destes codificadores?

Apesar de se trabalhar no esquema de pessoa jurídica implicar que se tenha um negócio, infelizmente esta é uma profissão com muito pouca “escala”, já que o limite são as horas que cada um consegue fazer no mês. Mesmo para os que têm uma veia empresarial e que contratam um ou mais auxiliares, esbarra-se no limite de gestão de equipe (que pra mim varia de 4 a 7 pessoas). A partir daí, a qualidade cai ou se começa a ter dificuldade de garantir entregas ou prazo. E as tentativas de crescimento com equipes maiores são extremamente complicadas – falo por experiência! E não é fácil ter um negócio dependente da venda de projetos ao invés de horas; da maneira que eles como são vendidos hoje, em regime de preço fechado, eles tem um risco altíssimo, que quase sempre é negligenciado para se garantir o melhor custo, resultando em mais prejuízos do que sucessos.

Assim me pego muitas vezes pensando neste assunto. Nossa profissão é jovem, ou seja, não tem muita gente no final de carreira ainda. Mas estamos prestes a chegar lá. E acho que se não começarmos a pensar e atuar nisto, pode ser que para a maior parte de nós, este fim de carreira não seja uma experiência muito tranqüila.

Outro ponto interessante é que os que permanecem codificando são justamente os melhores desenvolvedores. E lembrando da regra de 10:1 de produtividade (como o Steve McConnell sumariza bem aqui), isto significa que as pessoas que tem mais probabilidade de ter problemas no final da carreira são justamente as que são as grandes responsáveis por construir o que está sendo feito hoje, como líderes de times, arquitetos ou simplesmente “virando” noites para fazer aquele projeto atrasado e over budget ser entregue. De uma certa maneira, este grupo é a espinha dorsal dos que hoje fazem acontecer e que são usados pelos que não são tanto (para quem gosta de reflexões mais aprofundadas, recomendo o livro “Atlas Shrugged” da Ayn Rand. Escrito na década de 50, fala de uma sociedade onde poucas pessoas com excelência técnica e artística sustentam todos os demais até que elas se cansam e entram em “greve”… Muito interessante).

De certa maneira, a disseminação cada vez maior de metodologias ágeis melhora um pouco o cenário das pequenas empresas. A troca do modelo de venda em preço fechado por uma baseada em venda de equipes para iterações curtas beneficia todos, permitindo que os riscos sejam melhor gerenciados e expondo-os muito mais cedo no processo. Exemplos como a ThoughtWorks, que se especializou neste tipo de venda com sucesso mundial acabam incentivando a mudança de cultura que está em curso atualmente. Claro que vai demorar pra isto subir até que licitações públicas sejam feitas de forma diferente, por exemplo, mas acho que isto vai acabar acontecendo.

Mas isto não é a resposta para a grande maioria, que não tem vocação (ou interesse) em se transformar em empresários. E apesar de pensar bastante nisto, não vejo saída fácil e fico preocupado com o futuro destes desenvolvedores. Mas não deixo de conjeturar como seria se todos estes melhores codificadores se juntassem em algum tipo de empresa comum, onde a excelência técnica fosse aplicada na construção de produtos que resultassem em ganhos diretos. Interessante, não? Se alguém tiver pensamentos a respeito deste assunto, entre em contato!

, ,

5 Comentários

Desenvolvimento Ágil e Processos

Esta semana tive a oportunidade de conversar com vários clientes sobre o desenvolvimento ágil e a quantidade de controles e processos que devemos utilizar para suportá-lo. No meu caso, a virada de 180 graus de um desenvolvimento waterfall clássico (com especificação, aprovação e execução) para um desenvolvimento ágil teve como conseqüência inicial a abolição completa de controles e processos – até porque os controles e processos waterfall não se aplicam a um desenvolvimento ágil.

Porém, esta abolição completa está começando a gerar efeito colateral negativo, em dois aspectos: rastreabilidade de decisões e controle de faturamento. A deficiência nestes dois aspectos me foi apontada por clientes e vem sido também sentida internamente pela equipe de desenvolvimento.

A questão da rastreabilidade significa entender, às vezes muito tempo depois da implantação, porque uma determinada funcionalidade foi implementada de uma certa maneira ou porque determinada decisão de negócio (ou de arquitetura) foi feita em detrimento de outras. E, em um desenvolvimento ágil, isto comumente se perde já que os itens de backlog vão sendo implantados e código produzido, ainda que bem comentado, não é suficiente para se manter a visão destas características. Embora as práticas ágeis não sejam contra a documentação (muito ao contrário), fica a questão do quanto e como se documentar. Uma documentação que não seja realmente útil significa gastar horas que poderiam estar melhorando o ROI gerando novas funcionalidades.

A questão do faturamento do trabalho produzido por uma equipe ágil também é um ponto problemático.Mesmo assumindo que o cliente já tenha comprado a idéia de usar uma metodologia ágil, ainda assim ele vai querer uma contabilização do que foi gasto e aonde. E embora o product manager e o cliente específico da funcionalidade tenham uma comunicação extensiva, muitas  vezes existem outras pessoas para as quais é importante prestar conta das atividades realizadas. Ainda que a produtividade seja alta, algumas vezes é difícil se ter uma visão do trabalho gerado em cada interação, especialmente em longos períodos de tempo.

Desta forma, nestes dois aspectos, é necessário se definir artefatos e processos mínimos que sejam capazes de gerar e armazenar estas informações. No nosso caso, o que temos feito é tentar automatizar estes processos através de sistema interno específico, para minimizar o tempo despendido na geração destes artefatos e para padronizar as informações produzidas. Assim, para a gestão do backlog, controle das atividades realizadas em cada iteração e armazenamento de notas referentes às tarefas realizadas, estamos desenvolvendo um produto web específico que denominamos Iterator. Nele, teremos a gestão do backlog, a definição das iterações com as específicas tarefas, um amplo suporte a notas, descrições e arquivos anexados a cada tarefa e uma visibilidade por perfil. Ele possui também um módulo windows que é utilizado pelos desenvolvedores para apontar, de maneira simples, rápida e minimamente intrusiva, as atividades em que atuou, permitindo a visibilidade pelos membros da equipe e stakeholders do projeto.

Alguns podem achar que desenvolver um sistema internamente para isto é um overkill, já que existem alguns produtos voltados à gestão e controle do desenvolvimento ágil. Porém, os melhores que analisamos ou são caros (outro conceito relativo, mas caros no nosso cenário) ou são voltados exclusivamente para a gestão de backlog (sem o lado de faturamento) ou simplesmente são muito complexos para se adotar, gerando custo excessivo de treinamento e adaptação. Desta forma, acredito que o custo de desenvolvimento do Iterator (que com o framework, não é tão alto assim), acaba sendo compensado por estes fatores. Finalmente, existe o objetivo de transformá-lo em um produto, o que traz outras compensações.

Se alguém possuir necessidades similares ou que use um produto que não atenda completamente e quiser influenciar no desenvolvimento, basta entrar em contato. Conforme formos evoluindo e quando tivermos algo disponível publicamente, eu notifico a todos por aqui. Até a próxima.

, , , , , , , ,

Deixe um comentário

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

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