Eu vou falar um pouco mais sobre o Wordpress porque acho que é um bom exemplo de um software de qualidade.
Vou começar pela instalação. Para instalar o Wordpress, só é necessário verificar o “Famous 5-Minute Install“. Pronto. Funciona de verdade. Na verdade não é você que instala o Wordpress, ele se instala sozinho, você apenas manda ele se instalar. Não dá pra engolir softwares que só para instalar é preciso ler um livro cheio de procedimentos e depois acaba dando tudo errado e você ainda tem que ficar pesquisando na internet para ver ser descobre o que aconteceu.
Um dos procedimentos que ele faz na instalação é criar a estrutura do banco de dados. Hoje em dia não é difícil encontrar um framework que facilite isso (vide Hibernate), por então não fazemos isso sempre?
Outro exemplo que vi de como o Wordpress é robusto foi quando eu resolvi mudar a configuração dos permalinks. Após alterar a configuração veja o que apareceu na tela:
Devido a minha escolha o wordpress precisava criar um arquivo .htaccess para atender minha necessidade, como ele sozinho descobriu que não tinha permissão de escrita no diretório, mostrou na tela as instruções detalhadas do procedimento que eu precisava fazer na mão para que os permalinks pudessem funcionar. Quantas vezes você já se deparou com algum erro desconhecido e teve que fuçar logs para descobrir qual o problema?
É verdade, Software Robusto demanda mais esforço mas devemos abrir mão da preguiça. Não podemos é abrir mão da qualidade dos softwares que escrevemos. Software frágeis acabam por consumir a falsa economia no desenvolvimento porque geram um imenso custo de suporte e manutenção. Siga o exemplo do Worpress.
Resolvi abandonar o blogger.com e manter o blog por mim mesmo.
Fiz a opção de instalar o Wordpress (que não conhecia) sem muita informação. Apenas achei que era o mais popular. E valeu mesmo a pena.
Estou realmente IMPRESSIONADO. O Wordpress É MUITO BOM! A instalação foi muito fácil e a quantidade de opções que você pode customizar me chamaram a atenção. A quantidade de plugins disponíveis é quase ilimitada. Se você quiser montar um blog algum dia eu recomendo fortemente o Wordpress.
Sobre o blog, por enquanto ainda não fiz muitas modificações, apenas escolhi um tema e algumas opções bastantes simples, mas penso que ao longo do tempo vou estudar um pouco mais e dar uma incrementada. Espero que gostem.
Trabalhei esses últimos dias fazendo uma otimização de uma rotina escrita em C# e que usava NHibernate. Uma das mudanças que fiz foi fazer um bulk delete de uma certa entidade. Quis o destino que eu encontrasse um método delete com uma assinatura que recebia uma query. Perfeito!
Fiz a minha parte:
sessao.Delete("FROM Ocorrencia WHERE ...");
Não é que o maldito NHibernate ao invés de simplesmente criar a query de remoção, executa uma query de consulta, monta todos as entidades (no caso, Ocorrencia) e depois dá delete de um por um?
Por que diabos alguém em seu juízo perfeito escreveria um método tão estúpido quanto esse? Se eu já quero apagar esses objetos porque carrega-los na memória, consumindo o meu já escasso tempo de processamento?
Fica a lição: NÃO PROGRAME POR COINCIDÊNCIA. Não é apenas porque um método tem a assinatura perfeita que ele vai ser a solução do seu problema. LEIA A DOCUMENTAÇÃO. Certifique-se que está fazendo a coisa certa, ou caso contrário você estará “Entering in a world of pain”.
Muito legal o post “Chocoholic Agile Adoption Strategy“. Nesse post o autor fala sobre a experiência de criar uma nova escala para realizar estimativas das user stories. Para enfatizar o caráter abstrato da estimativa de tamanho, eles criaram uma escala de chocolates. Quanto maior a barra de chocolate escolhida (Furry Friends, Chunky, Half Block, Family Block, Half Slab ou Slab), maior o tamanho da estória.
Por aqui estamos utilizando story points mesmo, porém uma de nossas equipes inovou ao criar uma premiação para algumas das tarefas, veja só:
Estimar em chocolates é legal, comê-los é ainda melhor… Imagine juntar as duas práticas ))
Estou participando aqui no trabalho do ajuste do data mart de projetos. Esse trabalho me fez lembrar de uma apresentação que fiz no Developer’s World 2004: “Métricas em Fábricas de Software” ou “Tudo o que você sempre quis saber sobre o seu projeto mas tinha medo de perguntar”.
Tudo evolui tão rápido na nossa área, que normalmente essas apresentações antigas ficam facilmente obsoletas, mas dando uma olhada nessa, achei que as perguntas ainda são bem relevantes e interessantes. Cá pra nós eu odeio mesmo o título oficial, não suporto o termo “Fábrica de Software”. Fábrica dá uma conotação próxima a manufatura, que não representa de forma alguma o conceito de desenvolvimento de software.
De qualquer forma, estou querendo chamar a atenção para as ferramentas que estamos usando para implementar nosso data mart de projetos. Estamos usando uma suite open source chamada Pentaho. Plataformas de BI normalmente são complexas e muito caras, mas a ferramenta de ETL do pentaho (Kettle ou Pentaho Data Integration) é muito boa. Tem seus pequenos problemas de interface mas em termos de funcionalidades é bastante poderosa. Me irrita bastante quando as pessoas precisam fazer um trabalho específico e não usam a ferramenta adequada, por isso quando precisar criar um data warehouse ou mesmo quando for fazer uma migração de um banco para outro, utilize uma ferramenta de ETL, e em especial considere utilizar o Kettle. Você vai ganhar muito tempo…
Para curtir um pouco a nostalgia, aqui está a apresentação de 2004.
Cuidado quando precisar aprender uma tecnologia nova. É muito tentador ver um tutorial e achar que já sabe usar a coisa. Já cansei de ver o pessoal cair do cavalo por conta disso (eu mesmo caí várias vezes). Estudar apenas o tutorial não lhe dá a base necessária para entender como aquele treco funciona e muitas vezes você vai fazer besteira por não compreender o que acontece por debaixo dos panos.
Aqui o caso em questão é o wicket. Um de nossos clientes resolveu adotar esse framework em sua arquitetura. Eles mesmo escreveram parte da aplicação utilizando o wicket e nós continuamos o desenvolvimento. A base que eles desenvolveram não era suficiente para atender todas as necessidades do projeto (nunca é), então tivemos que nos aprofundar na solução. Muitos envolvidos cairam na armadilha. Aprendem um pouco e começam a chutar e adivinhar como o negócio funciona através de tentativa e erro. NÃO FAÇA ISSO!
Agora eu mesmo estou aprendendo a trabalhar com wicket. Peguei um livro (Wicket in Action) e estou estudando TUDO. Em geral esse tipo de livro começa com um overview, passando para uma explicação sobre a arquitetura, depois vem o tutorial e depois vem seções que mostram de forma mais detalhadas suas funcionalidades. Normalmente durante o tutorial você já é capaz de implementar coisas mais simples, mas não pare por aí. ESTUDE O LIVRO TODO! Monte uma base SÓLIDA de conhecimentos. Depois de ter essa base, tudo fica mais fácil.
Um de nossos maiores clientes solicitou que houvesse um repasse de conhecimento sobre scrum. E lá fui eu para Brasília com meu treinamento scrum de 8 horas. Estive em Brasília poucas vezes, mas desta vez pude presenciar um fato histórico: na terça (28/10/08) foi dia mais quente da história. Que sorte Aqui em Recife faz calor, mas pelo menos temos um ventinho… lá foi diferente… nem uma brisa… foi duro de aguentar…. Foi difícil também ter que ministrar este treinamento para 4 turmas (foram 72 pessoas ao todo) em 4 dias consecutivos com esse calor e gripado. Foi um teste de resistência… Mas deixando isso de lado, vamos as lições que aprendi dessa aventura:
Cada turma é diferente. Eu estava acostumado a treinar o pessoal aqui da empresa, onde é tudo mais homogeneo. O ambiente e as conversas do dia a dia fazem com que não tenha muita novidade e voce já possa antecipar as polemicas. Lá foi muito diferente. Cada turma era composta de pessoas com perfis diferentes, ocupando cargos diferentes, trabalhando em departamentos diferentes… Tive que me virar. Cada dia o pessoal debatia e criavam polemicas diferentes, e eu tinha que ajustar o treinamento a todo momento. Acho que quando alguém de uma turma for conversar com outro de outra turma, vão achar que assistiram treinamentos diferentes… hahaha… No final, deu tudo muito certo e acho que a mensagem foi bem passada e assimilada. Foi uma experiencia fascinante.
Não existe exame anti-doping para instrutores. Ainda bem… estava lá a base de vitaminas, analgésicos, antitérmicos, antinflamatórios, anti-isso, anti-aquilo… se houvesse anti-doping eu ia ser suspenso.
Conversei com algumas pessas em cargo de chefia, que não são necessariamente da área que me diziam que tinha alguma coisa muito errada em passar mais de 1 ano levantando e detalhando requisitos e na hora de implementar ainda surgem dúvidas e modificações toda hora. Preciso acrescentar alguma coisa?
Muitas pessoas que não conhecem, acham que scrum é uma coisa muito exótica, algo que pode ser usado para brincadeiras mas não para projetos sérios… temos que estar preparados para dar a informação correta e completa, para que a ficha caia.
Nada supera exemplos reais, especialmente exemplos conhecidos pela audiencia. Como trabalhamos para esse cliente há algum tempo, e temos alguns projetos onde só fazemos a implementação do sistema (CASCATA PURA), pude citar exemplos reais, que eles viveram e conhecem muito bem. Claro que neste processo voce vai criticar a forma que eles conduzem seus projetos, mas não devemos ter medo de ferir seus sentimentos. Estamos tentando fazer o bem.
Para todo problema existe solução. Muitas pessoas passam a vida toda criando obstáculos para evitar a mudança. Nossa missão é remove-los.
Com certeza aprendi outras coisas, mas agora já escrevi demais… Até a próxima!
Compareci ao kickoff da criação do grupo Scrum User Group Recife na quarta-feira passada. Acho muito interessante esse tipo de iniciativa, pois já é comum haver colaboração virtual através da internet, mas nada substitui uma oportunidade para discussões e troca de experiências cara a cara. O próximo encontro já está marcado para o dia 5 de novembro, e eu estarei lá colaborando.
Durante o evento, houve uma apresentação de Boris Gloger sobre as dificuldades de se adotar Scrum, e enquanto eu escutava, acabei por reviver os primeiros momentos da implantação aqui na empresa. Como já falei em post anterior, eu fui o responsável em implantar o scrum, e tudo começou com um projeto piloto e 1 equipe. Tudo tava indo muito bem, os conceitos estavam sendo bem assimilados e o trabalho ia de vento em popa, porém os bons resultados criaram uma imensa pressão nos outros projetos. De repente, todas as equipes queriam usar scrum. A pressão foi tão grande que não deu para conter a ansiedade do povo. Em um piscar de olhos tive que treinar quase 100 pessoas (não tínhamos orçamento para contratar Boris…) e todo mundo passou a usar scrum. Como eu só era um (ainda sou apenas um), não deu para acompanhar o dia a dia de todas as equipes e nem todas as equipes conseguiram experimentar o sucesso da equipe piloto.
Com esta situação, decidi adotar uma nova estratégia de acompanhamento utilizando um dos princípios do TPS (Toyota Production System) chamado “Genchi Genbutsu” que em tradução livre significa vá até lá e veja você mesmo. A minha idéia é entrar em cada uma das equipes, fazer parte dela por 1 ou 2 sprints e ajudar a fazer os ajustes necessários para transformar os insucessos em sucessos. Este processo vai ser bem demorado, mas acredito que vai deixar resultados mais sólidos. Já passei pela primeira equipe que estava com a moral nas canelas e juntos conseguimos virar o jogo. Estou agora na segunda equipe e estamos evoluindo bastante. O que eu aprendi com essa experiência é que cada equipe em cada projeto é um mundo novo. Não dá para ficar fazendo suposições ou criando boas práticas universais….
Sempre fui fã das metodologias ágeis, sempre acreditei nos seus princípios. Passei um bom tempo tentando convencer as pessoas da minha empresa a adotar SCRUM, e só depois de muito esforço consegui sinal verde fazer o piloto. Depois dos bons resultados deste piloto, acabei sendo responsável pela implantação do SCRUM em toda a empresa. Com a experiência adquirida, passei a prestar consultoria para outras empresas. Hoje tive uma experiência interessante em uma dessas consultorias.
O cenário é o início do desenvolvimento de um novo produto. Como é o início, existe a necessidade de criar arquitetura e escrever um monte de código de infraestrutura. Todo esse trabalho ia levar pelo menos 2 sprints, mas sem entregar nada de palpável para o Product Owner. Mostrei a equipe a importância de entregar algo com valor de negócio desde o primeiro sprint, até porque não tem como provar que a infraestrutura está correta se não for construido nada em cima dela. Planejamos o primeiro sprint com uma parte de infra e algumas funcionalidades que utilizariam essa infra.
O início do sprint foi bem típico, a equipe bastante motivada pelas novidades e um Product Owner esperançoso, porém sem acreditar que receberia um pedaço do produto pronto em apenas 4 semanas. Hoje foi o dia do Sprint Review e ao ver que a equipe conseguiu fazer e entregou um pedaço do seu querido produto, o Product Owner falou todas as frases que a gente espera escutar no fim do sprint: “Era isso o que eu queria!”, “Agora eu tenho algo para pegar, apertar e ver como vai ficar!”, “Com isso eu posso dizer se vocês estão no caminho certo”, “Agora eu posso trabalhar mais junto de vocês”, “Quero ver o que vocês estão fazendo mesmo antes de acabar o sprint”, …
Missão cumprida. Product Owner engajado. Claro que não podemos deixar a bola cair, depois do primeiro sprint, temos que continuar a fazer entregas de forma contínua. Mas o Product Owner está engajado, tudo vai ser mais fácil.
Entregue valor de forma contínua e desde o primeiro sprint! Tenha fé!
Meu primeiro computador foi um TK85. Nele eu aprendi o BASIC e comecei a programar. Logo eu percebi que o BASIC não era suficiente para fazer tudo o que queria e comecei a estudar AssemblyZ80. Nessa época não tinha internet, a gente aprendia muitas coisas nos livros e revistas, mas na maioria do tempo era por tentativa e erro. Todas essas dificuldades e limitações ajudaram a formar uma geração que conhece muito bem como um computador funciona e sabe muito bem como programar. Hoje em dia, o cara que quer começar na área já começa aprendendo uma linguagem como Java, PHP, C#, Ruby, ou sei lá o que e se tornam engenheiros medíocres… Falta uma base sólida! A maioria dos engenheiros hoje em dia não têem a mínima idéia de como as linguagens e os computadores funcionam. Se você está começando, aprenda C (não precisa ser assembly). Aprendendo e usando C, você vai construir a base de conhecimentos necessária para ser tornar um bom engenheiro. Depois de ter essa base, você vai aprender qualquer linguagem com muita facilidade, se tornando um excelente programador.
Eu vou falar um pouco mais sobre o Wordpress porque acho que é um bom exemplo de um software de qualidade.
Resolvi abandonar o blogger.com e manter o blog por mim mesmo.
))
Estou participando aqui no trabalho do ajuste do data mart de projetos. Esse trabalho me fez lembrar de uma apresentação que fiz no Developer’s World 2004: “Métricas em Fábricas de Software” ou “Tudo o que você sempre quis saber sobre o seu projeto mas tinha medo de perguntar”.
Cuidado quando precisar aprender uma tecnologia nova. É muito tentador ver um tutorial e achar que já sabe usar a coisa. Já cansei de ver o pessoal cair do cavalo por conta disso (eu mesmo caí várias vezes). Estudar apenas o tutorial não lhe dá a base necessária para entender como aquele treco funciona e muitas vezes você vai fazer besteira por não compreender o que acontece por debaixo dos panos.
Um de nossos maiores clientes solicitou que houvesse um repasse de conhecimento sobre scrum. E lá fui eu para Brasília com meu treinamento scrum de 8 horas. Estive em Brasília poucas vezes, mas desta vez pude presenciar um fato histórico: na terça (28/10/08) foi dia mais quente da história. Que sorte 
Sempre fui fã das metodologias ágeis, sempre acreditei nos seus princípios. Passei um bom tempo tentando convencer as pessoas da minha empresa a adotar SCRUM, e só depois de muito esforço consegui sinal verde fazer o piloto. Depois dos bons resultados deste piloto, acabei sendo responsável pela implantação do SCRUM em toda a empresa. Com a experiência adquirida, passei a prestar consultoria para outras empresas. Hoje tive uma experiência interessante em uma dessas consultorias.