O tema mudou para o default. Como alguns perceberam (obrigado pelos avisos!) estou sendo alvo de um ataque que modifica o text adicionando milhõs de links para sites de spammers e fecha os comentários. Tentei fechar uns buracos de segurança óbvios, mudar senhas e etc. e por fim resolvi tirar o tema para ver se esse foi o buraco. Atualizei o WP pra última versão mas não funcionou.
Se alguém tiver uma dica eu agradeço.
Muita gente reclamando de problemas nos acentos no feed. A data do início dos problemas parece coincidir com quando eu comecei a usar o Mac, hoje chequei todos os feeds, do WordPress e feedburner e todos estão setando o conteúdo curretamente para UTF-8.
Não tenho idéia sobre o que pode ser :( Estou procurando respostas, se alguém possuir alguma dica avise.
Um pouco após eu pedir demissão a Globo.com anunciou o projeto mais complicado dos último anos. Não são poucos os interessados nem fácil migrar sete anos de infra-estrutura, mas foi feito. Em um mês. Usando Scrum.
Após a adoção de práticas ágeis por toda a empresa o impossível ficou mais próximo e com o talento da equipe de WebMedia ele se tornou real. Globo Videos em Flash, para que não acreditava aqui está.
Parabéns à todos os globais!
Como já é tradicional neste blog, meus pitacos para 2008:
Há alguns anos eu trabalhava para uma grande empresa que cria produtos em um nicho muito específico. Dá última vez que eu vi alguém fazer uma estatística 90% dos produtos eram em C, 5% em C++ (”muito lenta”) e o restante em PERL, Python e Java.
A coisa que eu mais gostava sobre essa empresa era como o modelo de negócios deles era movido por inovação. Quando alguém tinha uma boa idéia ele era convidado a montar um protótipo em laboratório que seria oferecido à clientes. Haviam muitos ganhos para os bem-sucedidos, meu chefe, diretor regional de tecnologia, subiu ao seu cargo após duas idéias convertidas em produto (além de ganhar uma boa grana).
No entanto, apesar da inovação presente nos novos produtos lançados simplesmente não havia inovação técnica. Não importa o software, tudo era feito em C. Eu fui contratado para um novo time que cuidava das alicações Java. Estas aplicações só foram criadas porque os clientes exigiam interfaces web e RMI para os produtos da empresa e porque contratar programadores C sempre foi um problema. Mesmo trabalhando basicamente com Java (e naquela época o sonho de todo mundo era arrumar um emprego “100% Java, nada de PHP ou VB”) boa parte do meu trabalho era escrever e testar interfaces em C que se comunicavam com o sistema “de verdade” (o feito em C).
Certa vez me mandaram por 10 dias, que viraram 20, numa viagem de trabalho. O lugar não era muito amigável com turistas então passei boa parte do tempo no quarto de hotel tentando entender a televisão. Como não tinha Internet liberada eu passava no dia baixando PDs e páginas completas para ler à noite e nos fins-de-semana. Com o tempo pensei: e se eu reconstruisse o sistema em Java? Obviamente que não consegui reproduzir o sistema todo dado o tempo mas se o sistema antigo tinha 5% em Java eu consegui que fosse unas bons 30%. Chegue no escritório doido para mostrar ao meu chefe.
Obviamente foi um banho de água fria. A pessoa ficou feliz por eu me interessar pelos projetos internos e disse que iria ver o sistema, um dia. Esse dia nunca chegou. Após alguns meses eu pedi demissão da empresa.
Dia desses estava falando com um amigo que ainda trabalha lá e soube que 50% dos clientes foram embora. Na época que eu trabalhava nessa empresa ela tinha quase que o monopólio de um dado tipo de sistema, com tempo concorrentes foram surgindo. O sistema da empresa era claramente superior aos outros mas era muito menos flexível. Ele era muito bom no que fazia mas quando precisávamos que ele fizesse a coisa um pouquinho diferente o projeto durava meses. Os concorrentes chegaram com linguagens como C++ e Java e apesar de não terem um produto com 10 anos de bons serviços prestados eles conseguiam mudar rapidamente.
Há dez anos a escolha por utilizar C e IPC de UNIX na mãozona era certa. Nenhuma plataforma da época oferecia o desempenho aceitável. Infelizmente as pessoas acabam construindo as piores coisas do mundo com desculpa de performance e o sistema era completamente monolítico e depende tanto do SO que mudar de uma versão minor para a outra leva um ano com um time de 3 pessoas completamente dedicados.
Se esta empresa acompanhasse os movimentos da indústria veria que existiam plataformas que já ofereceriam performance aceitável (eu já trabalhei em sistemas Java mais eficientes que aquele em ouros lugares) e que iriam oferecer a flexibilidade necessária. Infelizmente só repararam isso quando a concorrência invadiu o mercado.
A empresa continua com produtos ótimos em suas idéias mas ninguém consegue esperar 2 anos para colocar algo no ar. As coisas mudaram e escolher a tecnologia certa para cada caso é cada vez mais o qe define sucesso ou fracasso de um projeto. Ou de uma empresa.
O G1 acabou com seu blog no Second Life. Ninguém liga mais para Second Life. Uma das coisas mais engraçadas sobre estes “novos” conceitos de Internet é ver um bando de gente das mais variadas áreas falando sobre os temas sem entender quase nada do assunto.
O que move a Internet desde sempre são as possibilidades derivadas do aspecto técnico. O curioso é que o programador não está pronto para lidar com isso, ele passou anos, décadas aprendendo a somente pegar as regras de negócio de alguém e transformá-las em código, quando temos um ambiente como a Internet onde quem sabe mais sobre o negócio é o programador ele simplesmente trava.
Enquanto você não colocar um arquiteto de informação lado a lado com um desenvolvedor você não vai ter nada que preste. É óbvio para alguém que entenda minimamente do que é feita a Internet que o Second Life não ia dar em nada simplesmente porque é uma plataforma de software muito pobre. Não falo dos recursos 3D mas sim da forma de distribuição.
“Não tem ninguém lá”, as pessoas reclamam. É óbvio que não vai ter, quem vai querer fazer o download, criar uma continha, um avatar e ter que abrir aquele programa enorme e lento toda hora para conversar com as pessoas? Pergunte a qualquer programador experiente e ele vai ter dizer que esse problema já matou diversas outras boas iniciativas, se você está querendo introduzir algo novo não obrigue as pessoas a usar algo só para isso.
É só olhar a história dos Instant Messengers. O ICQ é muito melhor que qualquer alternativa (eu acho que já usei todos) exceto o Jabber (que é um protocolo aberto e padronizado, outro nível) mas ainda assim não deu em nada. Quando o conceito de instant messaging ficou popular não foi através dele, foi com MSN, Yahoo! Messenger e agora o Google Talk. Instalar o ICQ e utilizá-lo numa conexão de 33kpbs era uma droga e quando a conexão ficou aceitável a Mirabilis já era passado.
Fale sobre FTP, Gopher,Finger ou qualquer outra coisa que não seja HTML entregue via HTTP que a maioria dos “profissionais de internet” não vai sequer entender. Fazendo uma versão do famoso bordão da comunidade Lisp: Aqueles que não conhecem de verdade a Internet estão fadados a repetir os erros que já foram cometidos.
Os últimos tempos têm sido corridos. Projeto importante no trabalho, projeto pessoal muito importante e no meio do caminho eu vejo um grande “paradigm shift” em tecnologia.
Este blog fala basicamente sobre desenvolvimento de software em geral, com foco em boas práticas e tendências. Eu escrevo em Português mais porque existe uma grande falta de material neste idioma, além de ser o meu nativo. Quem lê este blog sabe que há um bom tempo eu me interesso por Domain-Specific Languages, DSLs, e cada vez mais tenho vontade de blogar sobre este tema e outros derivados. Para entender corretamente DSLs estou passando por um crash course de linguagens de programação, com foco na teoria de LISP e seu MOP e aplicando na medida do possível em Ruby. Acontece que mesmo eu estando anos-luz atrás de quem já trabalha com isso falta material sobre este assunto em qualquer idioma, desta forma resolvi criar mais uma vez um blog em inglês:
Basicamente lá eu vou tratar sobre assuntos “globais”, como DSLs, e aqui no fragmental.com.br eu fico com os assuntos locais. Aqui eu tenho postado muito pouco mas lá eu tenho compartilhado minhas experiências no desenvolvimento de linguagens de domínio, então existe uma grande chance de ter mais posts lá num período futuro.
Aqui eu continuo com os assuntos que eu acredito que sejam relevantes apenas para o mercado brasileiro, seja por falta de material em PT-BR ou porque é coisa da nossa cultura. Como não estou acostumado a escrever em inglês, tirando especificações técncias e textos informais por favor me corrijam quando eu me embananar.
Muito mais mudanças em breve.
Toda empresa em que eu já tenha trabalhado, atendido como fornecedor ou prestei consultoria até hoje tem o mesmo discurso: esse negócio de [qualquer novidade] é legal mas aqui dentro não funciona. Pode até funcionar nas empresas certinhas, mas aqui nosso negócio é muito específico, nossa tecnologia é muito específica, nossos banheiros são muitos específicos…. Tenho uma notícia para quem pensa assim: não existe empresa certinha. Todo mundo acha que é diferente dos demais.
Ainda bem que no meu trabalho as coisas não são assim. Todo mercado é dinâmico mas o de Internet chega ao ridículo, da noite para o dia todos os paradigmas mudam. Ao mesmo tempo nós somos o braço de Internet de um dos maiores grupos de mídia do mundo e temos que seguir os mesmos critérios de qualidade, agilidade e inovação dos nossos “irmãos” nos canais de TV, Jornais e Rádios.
Quando fui contratado um dos requisitos era exatamente trabalhar o processo de desenvolvimento da empresa. Não somos diferentes de ninguém, temos um processo que foi criado e adaptado por sete anos e está longe de ser perfeito, como em qualquer lugar padrão. Após algum tempo observando como as coisas funcionam começamos a introduzir mudanças.
Somos uma equipe grande (incluindo alguns colegas blogueiros) que tem como trabalho cuidar de diversos sistemas entre sites, ferramentas de edição e produção de conteúdos e utilitários diversos.
Antes da mudança que introduzimos nosso fluxo de trabalho era o mais caótico possível: alguém enviava um e-mail com algo que estava errado ou precisava ser feito. Este e-mail originava uma tarefa num Gantt Chart. Uma das minhas tarefas diárias era correr atrás da equipe com o cronograma na mão perguntando o que estavam fazendo, depois sentar na minha mesa e atualizar o cronograma. Cada desenvolvedor pegava uma tarefa, ocasionalmente dois dividiam uma mais complexa. Ao terminar o desenvolvedor enviava um pacote para a equipe de testes (nenhum teste além do eventual feito pelo desenvolvedor era feito por aqui) que testava e homologava. Eventualmente o pacote voltava e ia para produção.
A primeira providência foi acabar com o cronograma. Nós temos uma licença do Jira, que apesar dos seus problemas funcionais é um dos melhores issue trackers disponíveis. O fluxo mudou: agora o cliente enviava um e-mail, este entrava no Jira e era designado para a pessoa que dava um prazo para a solução.
Dentro os diversos problemas que ainda tínhamos era colocar coisas em produção. Para homologar, agendar para subir em uma janela, acompanhar a janela, etc etc perde-se muito tempo e a cada tarefa concluída o ciclo era repetido. Solução? Só subir software a cada 15 dias. Em vez de mandarmos 5 ou 7 pacotes por todo o processo mandávamos apenas um e desta forma economizamos muito tempo. Eventualmente conseguíamos fazer mais coisas por parar menos com distrações do processo.
O próximo problema era no mundo das prioridades. Antes alguém mandava um e-mail e olhávamos para ele. Se fosse algo muito grave no nosso ponto de vista (ou se o cliente ligasse reclamando) nós colocávamos a alteração no topo da lista, caso contrário ia para quando “tivéssemos tempo” (i.e. nunca). Obviamente o cliente não ficava satisfeito com essa priorização e nós perdíamos muito tempo trabalhando no que era importante para nós sem saber se era importante (ou mesmo útil!) para o cliente ou não.
Solução? Jogo do Planejamento. Temos diversos clientes internos (e alguns milhões de externos) então elegemos o grupo que realmente representa nossos clientes. Em reuniões semanais de uma hora nós passávamos todas as issues abertas (depois da primeira reunião isso foi rápido) e agendamos possíveis subidas para estas. O cliente pode alterar qualquer iteração, menos a que está em execução. Quando o sistema vai para o ar o cliente recebe uma lista com todas as modificações que subiram para testar e mandar o feedback.
Estava melhor mas ainda não era o ideal. Nossos projetos ainda eram planejados em extensos Microsoft Projects que em algumas semanas perdiam sua sincronia com… o mundo real. A visão era de que o esquema de Jira/Jogo do Planejamento/Release de 15 dias funcionava bem para a manutenção mas não para projetos.
Então mudamos algumas coisas. Após quatro membros da equipe participarmos do curso de Scrum da Teamware nós resolvemos colocar em prática alguns conceitos, melhorando o processo utilizado para manutenção de maneira que servisse para nossos projetos.
Colocar em prática? Como assim?!? O projeto já possui cronograma definido, equipe definida, o escopo vêm sendo discutido há meses! Por que não esperar uma boa oportunidade, com tudo calmo? Simples: porque ela não vai acontecer. Qualquer empresa que queira se manter competitiva vai estar sempre bolando algo novo e mantendo suas pessoas ocupadas com isso. Oportunidade não se espera, se cria.
Para minimizarmos o risco da adoção nós introduzimos as coisas aos poucos. O foco não era implantar o processo X ou o processo Y mas sim coisas que nos ajudassem. O Scrum é um bom molde, um bom guideline. Vamos tentar implantar o molde, se virmos algo melhor ou ruim no caminho adaptamos. Vamos seguir, devagar quando necessário, mas movendo para frente.
Primeiro precisamos diminuir a importância do Jira em favor de post-its. Issue trackes são ferramentas bem interessantes, com o passar dos releases fizemos os usuários aprenderem a abrir issues no jira e acompanhar o andamento por ele (muito menos telefonemas de ’status report’!). Um dos problemas da ferramenta era presença. Para termos o Jira numa reunião precisamos de um notebook e nem todos poderiam utilizar a ferramenta ao mesmo tempo. Outro problema era a granularidade das tarefas. Outro era que cada um tinha sua lista de issues para resolver então eu passava horas (eu diria quase que 8) todo santo dia priorizando todas as issues abertas para cada desenvolvedor.
Para os desenvolvedores deixar o Jira um pouco de lado está sendo simples. Eles já não atualizavam o status dele mesmo! Eu tinha que encher o saco diariamente. Para os outros interessados no andamento do projeto não, após termos ensinado a todos a utilizar a ferramenta falar para olharem para uma outra não seria muito bem recebido. Além disso, muitos dos nossos clientes estão em outros prédios da empresa e não conseguem olhar nosso quadro. A solução encontrada foi mantêr as user stories no Jira, mas não as tarefas.
As user stories passaram a ser blogs. Quando alguém enfrenta uma dificuldade e resolve o problema ele “bloga” um comentário, mas não chega nem a atualizar o status. O uso passou a ser muito mais documental e menos de visão de status. Quando alguma story atinge o status de ‘done’ eu atualizo o status no Jira. A documentação não é tão util, já temos um wiki com especificações técnicas (segundo princípio de Agile Modeling, geralmente fotos dos whiteboards e descrições de alto nível apenas) e estou louco para me ver livre da obrigação de sincronizar com o issue tracker todo dia.
Um dos problemas é que não tínhamos espaço disponível. O escritório oferece uma boa disposição de mesas em baias de 4 pessoas, mas não há paredes disponíveis para pregarmos cartazes.
(desconte a poluição visual da minha mesa)
A solução imediata foi pregar o cartaz com os post-its num rack de servidores para desenvolvimento que fica no corredor.
Hoje já pegamos um antigo laboratório para nossas reuniões mais importantes, mas ficamos um bom tempo apenas com o rack e ainda o utilizamos. Salas de reunião ou mesmo o laboratório são fechadas e os cartazes lá dentro não estão 100% do tempo visíveis. Seguimos com o planejamento do sprint atual no rack e os outros cartazes e artefatos no laboratório. Antes que alguém pergunte tudo é registrado em câmeras digitais e como já me reportou uma vez o Vinícius sobre suas experiências as fotos nunca foram usadas além de decorar Flickrs e 8Ps.
Então todos os dias nos reunimos em frente ao rack para nosso Daily Scrum, uma reunião rápida diária. Um dos problemas que as pessoas sempre levantam para fazer este pequeno “compartilhamento de status” é a hora. Fazer muito cedo as pessoas podem não chegar, muito tarde não vai ser produtivo… bem, aqui a coisa é bem pior. Nossa equipe não exige a priori nenhuma restrição de horário, trabalhamos com pessoas que criam software e soluções, não com recepcionistas que precisam atender o telefone. Como consenso decidimos que as 11 da manhã todos estaríamos aqui. Temos ainda problemas, alguns dias falta um ou outro mas no geral vamos bem.
A reunião dura quase que exatos quinze minutos, para evitar que as pessoas se dispersem precisamos conversar algumas vezes e explicar que o foco é nos objetivos, não no desenrolar das tarefas. Outro ponto foi esclarecer que a equipe se reporta a ela mesma, não a mim. Eu viajei bastante nas últimas semanas e eles precisaram tocar sozinhos, o que fizeram com maestria.
O projeto já estava com as entregas definidas e renegociar não era uma opção. Infelizmente não conseguimos fazer reuniões de priorização com o cliente mas o responsável pela definição de negócio senta aqui do lado e nossos Sprint Backlogs, a lista de coisas que implementaremos a cada Sprint, já estavam bem definidas, com pouca margem para reagendamento (que foi devidamente utilizada).
Para fazer o pouco de planejamento que restava nós nos trancamos numa sala e estimamos todas as tarefas. Nas primeiras iterações mesmo explicando que um Story Point é dado por relatividade (primeiro você acha o mais simples depois estima os outros usando da métrica do “o quanto mais difícil é fazer X do que fazer aquele mais fácil?”) o time surgiu com valores quase que aleatórios para as tarefas, basicamente marcaram um número muito alto para todos. Nas iterações seguintes as estimativas foram ficando mais reais e hoje todos fazemos piada dos valores originais. Descobri que incluir uma reavaliação das estimativas na reunião de retrospectiva pós-sprint é útil para termos um melhor critério.
Na reunião de planejamento de Sprint nós deveríamos fazer uma versão inicial das listas do que precisamos fazer (tarefas) para atingir o objetivo (user story) de cada item do Sprint Backlog. Com medo de introduzir muita coisa nova eu optei por fazer apenas a lista da primeira Story. No final isso se mostrou irrelevante.
A empresa possui seu fluxo de processo já estabelecido e precisamos fazer nosso processo ser compatível com o das outras equipes, que inclui um grande teste de homologação no final. Antes das mudanças o desenvolvedor não executava teste algum, a equipe de QA era a responsável. Com o tempo percebemos o quanto isso era trabalhoso e propenso à erros. Uma das soluções que buscamos é ter testadores na nossa equipe mas enquanto isso não acontece nós mudamos a forma de pensar.
Lá no início da jornada o Guilherme e eu introduzimos testes unitários com JUnit no build. Demorou um pouco mas fatalmente as pessoas começaram a fazer (e as palestras do Guilherme fizeram com que pessoas de outras equipes começassem a fazer testes unitários por si só!). Quando o Bruno entrou na equipe, antes do projeto, uma das primeiras tarefas que dei para ele foi configurar o CruiseControl para fazer build e executar testes unitários. Mais problemas: não havia um servidor disponível para instalar. Conversa aqui, conversa ali conseguimos espaço num servidor de testes que roda diversas máquinas virtuais de VMWare, instalamos Ubuntu e o dito cujo (hoje usaria o Buildx), pronto. Após o CruiseControl o Bruno tratou de integrar o Fit ao nosso processo para fazermos testes de integração, e rodando com o CruiseControl.
Como ninguém tinha experiência com o Fit, o Bruno trabalhou em par com quem pegava a tarefa de implementar os testes. Com uma semana as pessoas estavam escrevendo Fixtures razoáveis, mesmo os estagiários.
Outro ponto que precisávamos testar era a interface, quase sempre web. Avaliamos o Selenium e mesmo com limitações ele parecia razoável mas não ideal. O Tiago investiu um dia integrando o Selenium no nosso build e trabalhando com test-cases em XSTL e fez o mesmo esquema que o Bruno para passar conhecimento. Agora nosso desenvolvimento só está “pronto” quando o código foi criado, com JUnit, com testes no Fit e com Selenium. O último QA achou apenas um bug em um módulo que alguém esqueceu de testar com caracteres especiais.
No primeiro Sprint eu não fiz reunião de revisão. Foi um erro cometido pela pressa mas imperdoável. No segundo nós fizemos uma reunião extremamente útil, levantamos pontos bons e ruins e colocamos num quadro (cuidado, termos fortes abaixo. ambiente irreverente é assim mesmo):
A maior parte dos pontos ruins (no “nem F$#%endo”) eram interrupções externas que eu preciso trabalhar. Minha viagem (que era um dos pontos ruins) recente fez com que os desenvolvedores respondessem por compromissos meus (outro ponto: reuniões que duram dias inteiros) , além de deixá-los sem proteção de interrupções externas (outro ponto citado) como telefonemas e até suporte a outras equipes integrando com nossos sistemas. Tirei daí que se precisar me ausentar preciso deixar alguém como Scrum Master, ainda que o time perca um membro ativo. Diluir o papel de Scrum Master causa mais prejuízos do que tirar uma pessoa do time de desenvolvedores.
Os pontos positivos incluíram o trabalho em equipe, os mecanismos de teste que ajudaram no desenvolvimento, o QA não ter encontrados bugs, a janela para produção ter sido tranquila e outras coisas que basicamente derivam da nova maneira de trabalhar.
Dos pontos ruins o que me preocupou mais foram os referentes a plataforma tecnológica da aplicação. Fizemos uma mudanças grande na direção de uma arquitetura SOA e como qualquer empresa não temos tempo de treinar todo mundo rapidamente.
O desenvolvimento desta arquitetura foi feita basicamente antes do projeto iniciar. Eu incubi o Guilherme de levantar possíveis soluções para nossos problemas de integração e esboçamos o projeto dos WebServices com tudo que tínhamos de melhor, incluindo REST. O primeiro uso desta infra-estrutura foi num projetinho bem curto que realizamos no início do ano e ela se mostrou muito boa.
O problema foi que neste projeto apenas o arquiteto (o próprio Guilherme) e eu metíamos a mão neste sistema. Quando começamos o projeto maior os conceitos ali dentro precisavam ser espalhados. Na primeira iteração com algumas cabeçadas conseguimos um desempenho bom mas ainda não o suficiente. Também vimos alguns pontos onde a arquitetura estava diminuindo muito a produtividade das entregas e que a introdução dos conceitos de WebServices REST, Hibernate/JPA, caches distribuídos e outras coisas menores precisa ser feita com mais cuidado. Algumas pessoas aprendem rápido e sozinhas, outras não e isso não tem a ver com habilidade técnica e sim com perfil (coisa, aliás, que defendo aqui desde sempre).
A solução que pensamos foi adicionar como tarefa um workshop arquitetural. Eu não queria cometer o mesmo erro e trancar o projeto na mão de um membro do time apenas (ou alguns), então nos reunimos durante a tarde. Na primeira parte da reunião o Guilherme explicou a arquitetura do início, mesmo para quem teoricamente já sabia foi útil.
Para estruturar a coisa eu pedi ao Guilherme quatro visões: a estrutura lógica (componentes), a estrutura física (servidores, bancos de dados, etc.), a de pacotes (como os módulos são divididos) e a de caso de uso (descrição do que acontece numa user story relativamente complexa do início ao fim).
Depois nós realizamos um exercício que aprendi no curso da TeamWare: cada um recebeu um bloco de post-it e uma caneta. Por cinco minutos escrevemos tudo que atrapalha nossa produtividade rapidamente, se alguém não pensasse em nada escrevia “nada” no papel. Depois discutimos cada ponto destes sorteando um de forma aleatória. Da forma escolhida para sortear surgiu o nome interno da técnica: a Dança do Siri (derivado da maneira “curiosa” de obter os papéis pelo Tiago):
Houveram poucos pontos técnicos, a maioria de infra-estrutura. Neste meio surgiram também coisas de processo como o papel dos estagiários no time. Um dos pontos levantados é de que nosso time não é tão homogêneo (e qual é?) e nem todos conseguem trabalhar em todas as partes do sistema. Uma estratégia que definimos foi de fazer pares quando ocorrerem estes casos e se tudo mais falhar partir para outra tarefa. O importante é quebrarmos os feudos de sistemas.
Todas foram discutidas, os pontos cabíveis foram anotados e mantivemos o histórico:
Na reunião para a entrega do primeiro pacote tínhamos um problema: descobrimos um erro no cronograma inicial (criado antes do projeto iniciar e antes de adotarmos o processo novo) que iria atrasar o projeto em oito dias. Começamos a reunião com uma descrição do processo de desenvolvimento para os clientes (aqueles que não participam no dia a dia do produto), revisão dos fatos ocorridos que desencadearam no atraso, o que faríamos para voltar ao rumo e a demonstração das funcionalidades. Para nossa surpresa a resposta foi excelente. Os clientes elogiaram a transparência do desenvolvimento, elogiaram o fato de verem algo em produção tão rapidamente e terminamos tendo que responder a uma pergunta: mas por que não fizemos assim antes?
Nós não implementamos o Scrum por completo (me viu falar em burndown chart aqui?), ainda falta bastante. Também não conseguimos eliminar problemas de prazo, tivemos que trabalhar algumas horas extras no último Sprint e possivelmente neste também. Algumas pessoas não se adaptaram aos novos processos e deixaram a equipe. Mas o importante aqui é que elevamos a qualidade do nosso trabalho consideravelmente -a ponto do cliente perceber- e as pessoas estão felizes em trabalhar desta forma, tanto as de fora quanto as de dentro. Paramos de correr atrás do prórpio rabo resolvendo problemas aleatórios diários e estamos trazendo resultados.
Engraçado que outro dia alguém falou comigo no corredor “Poxa, tô sabendo que vocês estão indo muito bem no projeto, heim? Perguntei pra Fulana -uma cliente- e ela disse: ‘É, eles estão gerenciando na linha dura desta vez, estilo sargentão’”.
Será?
Ontem eu terminei o dia assistindo a palestra sobre Rails de Neal Ford, da ThoughWorks. O tema em si não era novidade mas eu queria ver a reação da platéia, que foi como esperado: exatamente como a platéia brasileira que é apresentada ao framework. A diferença é que os americanos (e indianos, e japoneses, e suecos, e demais presentes…) já passaram da fase do ‘ouvir falar’ que o Brasil está vivendo e estão na fase de ver os impactos.
Ford também abriu meu dia de hoje com sua palestra sobre DSLs em linguagens estáticas. Ótima apresentação focando nas diferenças entre APIs, Human interfaces, DSLs Internas e externas e mostrando exemplos em Java, Groovy e Ruby.
Depois desta eu não perderia por nada a apresentação do Uncle Bob. Infelizmente foi apenas a mesma apresentação que já assiti algumas vezes, que basicamente traduz o ótimo livro do martin. Claro que apesar do conteúdo já ser conhecido a presença de espírito do apresentador faz tudo valer a pena. no meio da apresentação as imagens sumiram dos slides e o tio Bob teve que desenhar todas novamente num flip chart, não sem emendar comentários hilários sobre a origem e utilidade de cada uma. O bashing também era um ponto de sentar de rir, começando pelo já batido bashing do Netbeans (”só existem duas IDEs para Java: Eclipse e Netbeans, e por um acaso o Eclipse é gratuito”) passando pelo bashing da massa de programadores C++ sobre usas ferramentas e plataformas (”se alguém disser que compila um sistema C++ de gente grande em menos de duas horas é mentira”). Afinal, você ia discutir sobre C++ com o cara?
Uncle Bob se juntou á Scott Ambler, figurinha conhecida dos brasileiros, e Elliotte Rusty para falar sobre TDD. O painel recebeu várias perguntas da platéia e, como o próprio Uncle Bob deixou claro, era engraçado como as perguntas são
Minha tarde terminou com Dean Wampler falando sobre AOP em Ruby. Eu acreditava que seria uma palestra bem básica mas me surpreendi, Wampler falou sobre como a metaprogramação de Ruby não substitui AOp com exemplos tirados de frameworks famosos como Rails e decorreu sobre as propostas da área, inclusive as novidade do Ruby 1.9. Infelizmente a platéia não estava preparada, apenas uns 5 eram programadores Ruby de fato.
Para aqueles que mostraram sua solidariedade pela minha perda do lollapalooza informo que pelo menos comprei o Live at the Gorge, que eu nem vi pelo Brasil. Imperdível.
Eu bato nesta tecla frequentemente, mas nunca deixo de ficar espantado em como as pessoas conseguem fazer a associação completamente errada ao tentar adequar a posição de desenvolvedor de software em algum lugar. Existe uma pressão social para que enquadremos esta profissão em algum critério, preferencialmente apenas estendendo uma já existente. Eu não tenho nada contra a princípio, na verdade deixo sempre bem claro que na minha visão desenvolvimento de software é uma engenharia, uma ciência destinada a resolver problemas.
Eis que aí mora o perigo. Ao associar a profissão com engenharia logo se vê gente que tenta adequar tudo a esta área, como se houvesse apenas uma maneira de fazer engenharia. O maior problema, entretanto, é que o desenvolvimento de uma solução em software é diferente do da maioria das engenharias (talvez não da química… preciso pesquisar sobre isso). Numa engenharia tradicional (civil,agrónoma, sanitária…) geralmente você precisa entregar um projeto que vai ser executado por outros profissionais, quase sempre profissionais que não possuem o grau de engenheiro, ou seja: não saberiam resolver os problemas por si só. A implementação do projeto tem que seguir o plano minuciosamente, primeiro porque a mão-de-obra teoricamente não possui conhecimento suficiente para tomar decisão em caso de dúvida e em segundo lugar porque um projeto deste geralmente é algo big bang. Você não consegue construir meia ponte, deixar uns carros passarem por uma semana e ajustar o projeto. precisa construir a ponte toda, do início ao fim, de uma só vez e seja lá o que Zahl quiser.
Bem, detesto ser estraga-prazeres de tantos mas não é assim que software funciona. Há muito tempo que descobriram que a melhor maneira de produzir software é de maneira iterativa e incremental. Este é o princípio básico de RUP, Scrum e XP, só para citar algumas metodologias/processos de desenvolvimento. Nestes processos sabe-se muito bem que o nível de acerto em um projeto BDUF, que segue o modelo dos engenheiros do parágrafo anterior, é passo certo para o fracasso. Ok, mentira minha, certo não é. Eu conheço algumas poucas empresas, de ramos muito específicos (geralmente gente que lida com regulamentação governamental pesada) que consegue levar este modelo. Aliás, sabe qual é esse modelo onde você produz uma especificação antes e escreve código depois? Waterfall, ou Cascata.
Eu me lembro em algum momento de 2002 tendo uma aula na faculdade sobre este modelo. O professor, uma pessoa com curriculum bem razoável e instrutor certificado IBM para RUP, ou algo assim, desenhou o velho diagrama espiralado no quadro e escreveu embaixo uma lista copiada da apostila sobre vantagens e desvantagens dos dois modelos. Em seguida ele começaria a descrever o modelo iterativo incremental desta maneira:
Primeiro, é feita a análise do problema. A análise é, certamente, a parte mais importante de todo o processo. Neste momento são identificados os problemas, os atores, os casos de uso e tudo mais que é necessário para chegarmos na próxima etapa, o projeto do sistemas.
Na fase de projeto os projetistas pegam o trabalho do analista -que deve ser completo o suficiente para que o projetista faça seu trabalho sem ter que esclarecer qualquer dúvida- e criam o modelo da solução para aquele problema, criando diagramas de interação entre as classes e seus estados.
Logo em seguida os codificadores pegam este projeto e escrevem software. O sistema assim está entregue. Notem que um sistema feito desta forma divide corretamente as responsabilidades e gera código de qualidade e bem documentado. Nenhum programador ninja sai escrevendo código por aí sem que antes tudo seja validado pelo analista, projetista e arquiteto do sistema.
Naquela época eu sentia que havia algo errado mas não sabia dizer o que era. Apesar dele não ter explicado direito o tal espiral se isso era diferente do waterfall esta descrição não fazia sentido. Ele descreveu o processo de waterfall, com uma única peculiaridade de atribuir papéis aos participantes. Ele estava errado, não tinha entendido nem mesmo o que era modelo iterativo incremental, muito menos o RUP no qual se certificara.
Quem olha o gráfico das baleias corcundas pode realmente ter uma impressão desta, mas eu realmente espero que alguém que seja um instrutor certificado, ou mesmo um instrutor não certificado, saiba que mais importante que a figura é o embasamento literário. Os livros sobre o tema vão te explicar o que aquelas curvas significam e, ao contrário do senso comum, elas não significam fases no seu projeto. Ok, nova mentira, elas significam sim, até são chamadas de phase, mas o meu ponto é que este conceito não é o mesmo que você vai ouvir por aí.
Uma fase no RUP indica apenas um período de tempo com uma dada característica mais marcante. Na fase de Inception, por exemplo, a atividade mais marcante é a de modelar o negócio e trabalhar requisitos. Isso não significa que você não vai coletar e analisar requisitos mais tarde pelo contrário. indica apenas que a maior parte do trabalho naquele tempo é destinada a esta atividade. E por quê? Porque precisamos de modelos de análise completos? Não! Simplesmente porque naquela altura do campeonato não sabemos direito o que vamosconstruir e estamos tentando entender mais ou menos para começarmos a trabalhar.
Em RUP geralmente as funcionalidades com maior risco ou impacto arquitetural serão implementadas primeiro, XP e Scrum possuem uma estratégia que eu considero muito mais inteligente neste aspecto que é trabalhar logo de cara pequenos pedaços que o cliente escolher. No fim das contas o efeito é bem semelhante: começamos a trabalhar no sistema pedaço por pedaço, descobrimos os pontos que precisam ser ajustados, os ajustamos e seguimos em frente: o desenvolvimento iterativo é completamente baseado feedback que uma iteração dá para a equipe. XP e Scrum possuem diversas características mais interessantes que as implementações comuns de RUP para boa parte das pessoas (iterações curtas, planning game, reuniões super-ultra-rápidas diárias…) mas eu diria que estão ganhando tanto terreno e tão rápido pelas falhas nas pseudo-implementações de RUP que os instrutores certificados, appraisers CMM/CMMi/MPS.BR/Sigla-de-3+x-letrinhas-que-estiver-na-moda-este-mês e demais membros da fauna de processos de desenvolvimento de software insistem em aplicar. Após alguns anos se enganando o mercado começa a acordar e procura um novo salvador da pátria, nesta armadilha está caindo um conceito que é, na minha opinião, uma evolução pura e simples dos processos existentes (mais foco nas pessoas -em vez de temer o ‘programador ninja’ fazer com que o conhecimento se espalhe por todos- e em resultados palpáveis e obtidos rapidamente, por exemplo), processos estes que nunca foram implantados de fato na maioria das empresas, destas que compraram uma caixinha de pseudo-RUP e ganharam um belo waterfall com zilhões de documentos para preencher todo dia.
E o meu maior medo agora é de estar vendo isso acontecer com processos ágeis. Durante o excelente curso de Certified Scrum Master (onde a certificação é algo simbólico, não quer dizer nada além de que você teve x horas de treinamento, por isso pode tirar da sua assinatura de e-mail, por favor?) ministrado pela Teamware lá no Rio conversamos muito sobre isso no cocktail. Já se pode ver empresas muito conhecidas da comunidade por prometer mundos e fundos, entregar (quando entrega) software de péssima qualidade e aos olhos da cara que de repente viu no Scrum, por exemplo, vantagem competitiva.
Como nós vamos conseguir saber se estas pessoas entenderam o mínimo necessário? Não vamos. Apenas podemos nos preparar para que quando estas figurinhas aparecerem com seus Certified Scrum Master, Certified Rational QualquerCoisa, PMP, CMMi, MPS.BR e tudo mais que couber no cartão de visitas nós possamos fazer uma avaliação real, sem nos basearmos nas baboseiras que sempre são citadas.
Fazer este tipo de avaliação não é difícil. Se você não entende a vantagem competitiva e está apenas curioso pergunte ao fornecedor o que ele te oferece de diferente. Ouça bem o que ele lhe diz, estude. Caso não saiba avaliar contrate um consultor e peça referências em um fórum como o do GUJ (onde temos o maior prazer em rechaçar fornecedores ruins em geral). Peça para fazer uma visita ao ambiente de trabalho, qualquer menção da palavra ‘fábrica’ já é sinal de eliminação do processo seletivo: fábricas são um modelo que não funciona para software (pense numa fábrica de notícias num jornal. Funcionaria? É o mesmo princípio: atividade criativa não se serializa ou controla desta forma) e são o extremo oposto de metodologias ágeis (não necessariamente do RUP, mas mesmo assim a empresa deve perder muitos pontos na avaliação). A empresa tem um portfólio no site, todas têm, então ligue para os clientes anteriores. De surpresa, claro, não avise ao fornecedor ou ele irá te indicar apenas referências que ele sabe o que dirão.
Dá trabalho, mas é melhor gastar um mês fazendo a seleção de um fornecedor decente do que ficar anos e anos se lamentando de um projeto furado.