• Transparência: garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados;
• Inspenção: diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas;
• Adaptação: se um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, o inspetor deverá ajustar o mais rápido possível o processo ou o material sendo processado.

A metodologia Scrum consiste em um conjunto formado por Times e seus papéis, Time-Boxes, Artefatos e Regras.

Os Times de Scrum são projetados para otimizar flexibilidade e produtividade, são auto-organizáveis, multidisciplinares e trabalham com iterações. Um Time de Scrum conta com três papéis definidos:

• o ScrumMaster: responsável por garantir que o processo seja seguido e compreendido por todos, trabalhando na remoção de impedimentos, incentivando e levando a equipe a ser mais produtiva e garantindo a qualidade do código gerado;
• o Product Owner: é a única pessoa responsável pelo gerenciamento do Product Backlog e por garantir o valor do trabalho realizado pelo Time. Deve manter a lista de prioridades sempre atualizada com as tarefas de maior valor de negócio.
• o Time: são os desenvolvedores que transformam o Product Backlog  em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Frequêntemente possuem conhecimentos especializados, como programação, controle de qualidade, análise de negócios, arquitetura, etc. Cada membro do time aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora a eficiência e eficácia do time como um todo.

Reuniões de Planejamento da Release, a Sprint, Reuniões de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da Sprint e a Daily Scrum estão incluídos nos Time-Boxes da Scrum.

• Reunião de Planejamento da Release: estabelece a meta da release, estimativas e as maiores prioridades do Product Backlog, os principais riscos e as carasterísticas gerais e funcionalidades que estarão contidas na release. Estabelece também uma data de entrega e os custos prováveis se nada mudar. A organização pode inspecionar o progresso e fazer mudanças nesse plano a cada Sprint. Esse planejamento é inteiramente opcional, onde iniciando os trabalhos sem essa reunião, a ausência de seus artefatos aparecerá como um impedimento que deverá ser resolvido. Na maior parte dos caso o processo de planejamento é feito no início do trabalho da release e não é modificado com o passar do tempo. São definidos uma meta geral e resultados prováveis.
• Sprint: é uma iteração de duração fixa. Durante um Sprint, o ScrumMaster garente que não será feita nenhuma alteração de escopo que possa afetar a Meta da Sprint. Uma Sprint consiste do Planejamento da Sprint, o trabalho de desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem intervalos entre elas. Uma Sprint pode ser cancelada antes do prazo fixo, mas somente o Product Owner tem autoridade para isto. Uma Sprint pode ser cancelada se a Meta da Sprint se tornar oblsoleta, pela empresa mudar de direção ou se as condições do mercado ou tecnologia mudarem.
• Reunião de Planejamento da Sprint: é o momento no qual a iteração é planejada. É fixada oito horas de duração para uma Sprint de um mês. Para Sprints mais curtas, deve-se alocar proporcionalmente ao tamanho total da Sprint para essa reunião. Ela consiste em duas partes, a primeira parte – o quê? – é o momento no qual é decidido o que será feito na Sprint e a segunda parte – como? – é o momento no qual o Time entende como desenvolverá as funcionalidades em um incremento do produto. Para a primeira parte o Product Owner apresenta ao Time o que é mais prioritário no Product Backlog. Cabe ao Time a decisão de avaliar quanto do Backlog deverá ser selecionado para a Sprint. Uma vez selecionada as atividades do Backlog, a Meta da Sprint é delineada, sendo ela o objetivo que será atingido no Sprint. Na segunda parte da reunião o Time geralmente começa projetando o trabalho, identificando tarefas. As tarefas devem ser decompostas para que possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint Backlog. O Product Owner estará presente nesta segunda parte da reunião para esclarecer e ajudar a efetuar trocas de tarefas caso as estimativas excedam ao tempo da Sprint ou o haja algum impedimento ainda não resolvido para a execução daquela tarefa. Caso o Time finalize a Sprint antes do prazo, será negociado com o Product Owner uma nova tarefa que será adicionada ao atual Sprint Backlog.
• Revisão da Sprint: ao final da Sprint, é feita uma reunião de Revisão, com duração proporcional à duração da Sprint – quatro horas para Sprints de um mês. Nesta reunião o time colabora sobre o que acabou de ser feito e baseado nisso eles colaboram sobre quais são as próximas tarefas que podem ser feitas. Trata-se de uma reunião informal, com a apresentação das funcionalidades. O Product Owner identifica o que foi feito e o que não foi feito. O Time discute sobre o que ocorreu bem e quais foram os problemas enfrentados, além de como esses problemas foram resolvidos. O Time demonstra o trabalho que está pronto e responde a questionamentos. O Product Owner faz projeções de datas prováveis apartir de várias hipóteses de velocidade. A Revisão de Sprint fornece entradas valiosas para as reuniões de Planejamento de Sprints seguintes.
• Retrospectiva da Sprint: logo após a revisão da Sprint e antes da próxima reunião de Planejamento da Sprint o ScrumMaster encoraja o Time a revisar seu processo de desenvolvimento, de forma a torná-lo mais eficaz e  gratificante para a próxima Sprint. A finalidade é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e ferramentas. Deve identificar e priorizar os principais itens que ocorreram bem e aqueles que, feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. No final desta reunião o time deve ter identificado medidas de factíveis melhoria que implementarão na próxima Sprint.
• Daily Scrum: o Time se encontra diariamenta para uma reunião de no máximo 15 minutos, sempre no mesmo horário e no mesmo local durante as Sprints. Durante a reunião cada membro explica:
  • O que ele realizou desde a última reunião;
  • O que ele vai fazer antes da próxima reunião;
  • Quais obstáculos estão em seu caminho.

As Daily Scrums melhoram a comunicação, eliminam outras reuniões, identificam e removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de decisões e melhoram o nível de conhecimento de todos acerca do projeto. É uma inspeção e adaptação do progresso na direção da Meta da Sprint.

Os Artefatos do Scrum incluem o Product BackLog, o Burndown da Release, o Sprint Backlog e o Burndown da Sprint.

• Product Backlog e Burndown da Release: os requisitos para o produto estão listados no Product Backlog, por seu conteúdo, por sua disponibilidade e por sua priorização. O Product Backlog evolui à medida que o produto e o ambiente em que ele será usa evoluem, ele é dinâmico, no sentido de que ele está constantemente mudando para identificar o que o produto necessita para ser apropriado, competitivo e útil. O gráfico de Burndown da Release registra a soma das estimativas dos esforços restantes do Product Backlog ao longo do tempo. O Product Owner mantém o Product Backlog e o Burndown do Backlog da Release atualizados e publicados todo o tempo.
• Sprint Backlog e Burndown da Sprint: o Sprint Backlog consite nas tarefas que o time executa para transformar itens do Product Backlog em incremento pronto. É todo trabalho que o Time identifica como necessário para alcançar a Meta da Sprint. Os itens do Sprint Backlog devem ser decompostos suficientemente para que mudanças no progresso possam ser entendidas na Daily Scrum. Um dia ou menos é um tamanho comum para um item do Sprint Backlog. O Sprint Backlog é um retrato em tempo real altamente visível do trabalho que o Time planeja efetuar durante a Sprint. O Burndown do Sprint Backlog é um gráfico da quantidade restante de trabalho do Sprint Backlog em uma determinada Sprint ao longo do tempo da Sprint.

O Scrum exige que os Times desenvolvam um incremento de funcionalidade do produto a cada Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado, garantindo que todos os incrementos funcionem juntos.

* Referência: The Scrum Guide – The official rulebook.

Qual é a idéia? Simples… Descrever o meu ambiente de trabalho em apenas 7 itens… 7 itens parecem ser muita pouca coisa para um ambiente de trabalho, mas vamos focar nos quais eu mais utilizo e nos quais agregam mais produtividade no meu dia-a-dia…

1) GNU/Linux

É inegável a minha produtividade no Linux… Profissionalmente trabalho com este sistema operacional desde meados de 2003, quando então trabalhava no TRE onde cultura OpenSource é grande por lá, graças ao meu amigo Augusto Campos. Nestes anos já passei por várias distros como Suse, Slackware, Mandrake, mas nos últimos anos venho utilizando o Ubuntu. Leve, prático e simples… E não tem nada que um atp-get não resolva… Mas minha história com o Linux começou a muito tempo atrás… com o Conectiva 4.0, em meados de 1998 quando ainda precisava compilar os drivers do modem e placa de som do meu Pentium 233MMX :P

Quanto a produtividade? Bem… me encontro muito mais fácilmente na organização funcional do Linux do que a do Windows… O Linux me oferece um nível de personalização muito maior do que o Windows. Sem contar na estabilidade da plataforma, a não preocupação com “registros e licenças” para aplicativos do cotidiano e a facilidade de configuração do ambiente de trabalho conforme meu gosto :)

2) Eclipse IDE + Gnome Text Editor

A IDE Eclipse é a principal ferramenta de trabalho no meu dia-a-dia. Já fica no meu “Startup Applications“. Trabalho com a plataforma Java EE, e o eclipse – além de ser gratuíto – é altamente customizável! Tenho um perfeito ambiente de desenvolvimento montado com o eclipse + plugins. Alguns dos principais plugins que utilizo para ele, e que me poupam muito tempo, é o Java EE IDE, Tigris Subversion para acesso e controle do SVN, Web Tools Plataform, Sonatype M2Eclipse para uso/gerenciamento do Maven,  FindBugs e PMD para a qualidade do código. O Gnome Text Editor (no windows costumava utilizar o TextPad) é meu editor secundário… Leve e simples… Aquivos XML, SQL, HTML… são com ele!

3)  SoapUI + HermesJMS

Nada que se cria é perfeito. FATO! E é por isso que além dos costumeiros testes unitários utilizo o SoapUI para efetuar os testes integrados dos serviços. O SoapUI é uma ferramenta fácil de utilizar.  Não tem um serviço disponível? O SoapUI cria automaticamente um mock Service para você em menos de 2 segundos! É ele que me dá a segurança final de que o serviço está realmente funcionado de acordo com o esperado.

4) Bash

Usuários de Windows devem achar essa parte a mais engraçada… Ao contrário do Windows onde “tudo” se resolve com o mouse, em um servidor *nix não é bem assim… No entando isso não é uma desvantagem, pelo contrário! Uma janela Shell permite que eu faça tudo e mais um pouco. Consigo parar um serviço travado, um dead-lock, ficar analizando logs em tempo real, procurar por aquele arquivo que não lembro onde fica, mas sei parcialmente o conteúdo dele… O Shell é uma ferramenta extremamente versátil e útil no dia-a-dia. Tenho vários scripts shells que criei para facilitar meu trabalho, e volta e meia crio novos scripts. O que preciso fazer? Chamar o script no console e passar o parâmetro necessário que desejo :) Mas confesso, um dos comandos mais utilizados por mim é o “kill -9” :P

5) Skype

O principal meio de comunicação hoje para mim! Com ele converso com os clientes da Europa sem maiores dificuldades! Faço meetings com vídeo, discuto problemas com a documentação, tenho total log do que já foi discutido – ótimo para tirar dúvidas posteriores e/ou evitar aquele disse/não disse ;) O Skype hoje é tão essencial para meu trabalho quando o meu celular na vida particular! Minha fonte de comunicação e documentação, por que não…

6) Google

Alguém hoje em dia consegue trabalhar – pergunto trabalhar, porque viver sem eu sei que não dá – sem o Google?!

O Google é minha fonte de informações! É para ele que recorro quando estou com alguma dúvida ou quando quero me atualizar em determinado assunto. Se o Google não souber, ninguém sabe!! Além do sistema de buscas, trabalho diariamente também com outros produtos Google, como GMail, com dezenas de filtros já estabelecidos e que poupam muito tempo de trabalho manual de filtragem, e o Google Calendar para organizar minha agenda de reuniões, convites e lembretes. O Google Documents também aparece todos os dias por aqui. É nele que armazeno a grande maioria da documentação gerada nos projetos. Fácil de compartilhar e nunca serão perdidos por uma falha de disco.

7)  TeamViewer

Algumas vezes no trabalho optamos por fazer um pair programming e com certeza os resultados alcançados são grandes… Afinal, duas mentes pensam melhor do que uma única sozinha – ou não…

Mas como fazer isso com uma equipe remota? Do outro lado do oceano? TeamViewer! O TeamViewer não nada mais do que um gerenciador de conexão remota, um VNC mais “avançadinho”. Com ele, aliado ao Skype, fazer um pair programming remoto é quase, eu disse quase, a mesma coisa do que pessoalmente! Além disso, o TeamViewer já me salvou diversas vezes. Deu problema? Não resolveu as dicas? Conecte no desktop do seu amigo e resolva você mesmo! ;)

Os animais, ansiosos, queriam agradar aquele que os cuidava e lhes alimentava todos os dias.

Semanas antes da data já haviam começado as reuniões, discuções e idéias do possível presente que gostariam de dar ao fazendeiro. Dias passaram-se e não chegavam a nenhum consenso. Eles queriam supreender com algo que o fazendeiro realmente apreciasse.

O porco sempre à frente das reuniões anotava todas as sugestões, tentando de alguma forma juntar idéias e então criar o presente perfeito para o seu dono. Sugestões aqui, sugestões ali… Sempre haviam coisas novas para serem discutidas e feitas.

A galinha, no entanto, achava aquilo uma perca de tempo. Dizia ela que o fazendeiro nem era tão bom assim que merecesse tudo aquilo que se estava tramando. Afinal,  ele me alimenta mas toma meus ovos…

Alguns outros animais concordaram, outros nem tanto… Mas o porco continuava firme e forte em prestigiar o aniversário de seu dono.

Certo dia, na véspera da aguardada data, a galinha desce de seu puleiro e sugere então que se faça o melhor café da manhã que o fazendeiro já teve na vida, como forma de demonstrar o apreço de todos animais ali na fazenda. Faremos, disse a galinha, ovos com bacon!

Todos os animais pareceram gostar da idéia, e concordaram que seria um magnífico presente para o fazendeiro.

O porco então dá um passo à frente, e fala a todos: – Os ovos, nossa amiga galinha nos dará. Os bacons, somente eu poderei dar, e isso me custará a vida…

Os animais perplexos, não haviam pensado nisso.. Já estavam convencidos que seria impossível dar este que seria o melhor presente para o fazendeiro, quando o porco, novamente chama a atenção para si mesmo e completa: – Se este for o melhor presente que podemos oferecer ao nosso dono, eu irei prover o bacon do café da manhã…

Comprometimeto x Envolvimento, onde você está?

“A maioria das pessoas se refugiam na ignorância. Neste contexto depressivo, algumas pessoas criaram uma ilusão de liberdade, uma liberdade paleativa chamada ‘Software Livre’.

Portanto, usuários ou não de Software Livre, não eram mais do que indivíduos em conformidade com leis arbitrárias ditadas por um grupo de ‘autoridades’ da Internet.

As pessoas cançaram-se deste negócio.

Decidiram então que deveriam ser livres para compartilhar informações e recursos com seus amigos por pura satisfação.

Esta liberdade ficou conhecida como computação soberana.”

Isto será possível quando alcançada as sete seguintes liberdades: (Breves descrições)

Liberdade 1 – Nome Próprio

É a liberdade para escolher qualquer nome para si mesmo. O formato do nome escolhido não é limitado de forma alguma, mesmo em casos de homônimos, e há a possibilidade de mudar o nome escolhido à vontade.

Liberdade 2 – Apelidos

É a liberdade de escolher qualquer nome para se referir a outros. Não é limitada às pessoas, mas aplicadas a tudo que for acessível no mundo virtual. Baseia se na noção de que esquemas de endereços completos implicam na abdicação da própria liberdade em favor a uma autoridade central. Deste modo, alternativas viáveis seriam esquemas de endereços relativos centralizados por cada pessoa.

Liberdade 3 – Confiança

É a liberdade de confiar em alguem que desejar. É a possibilidade de atribuir um grau de confiabilidade para qualquer pessoa, possivelmente dependendo do assunto (por exemplo, uma opinão em uma música pode ser altamente confiável, mas opinões sobre carro ou economia não). Além disso, o grau de confiabilidade irá depender do envolvimento em relação as pessoas (por exemplo, pode-se confiar mais em um amigo do que um amigo do amigo).

Liberdade 4 – Privacidade

Esta liberdade possui dois aspectos: A liberdade de ver somente o que se deseja, e a liberdade de manter informações inacessíveis à pessoas não confiáveis. Uma aplicação do primeiro aspecto seria evitar spams aceitanto somente mensagens de pessoas com um certo grau de confiança.

Liberdade 5 – Expressão

É a liberdade de se expressar. Não é apenas a liberdade de expor seus pensamentos, mas também a liberdade de pensar sobre informações dadas por outras pessoas.

Liberdade 6 – Hardware

É a liberdade de compartilhamento de recursos. Baseado na suposição de que a maioria dos recursos de hardware estão subutilizados, principalmente entre usuários domésticos. Compartilhando os recursos de um grande número de pessoas, seria possível diminuir a dependência dos provedores de Internet e hosts.

Liberdade 7 – Software

É a liberdade de compartilhar todo software utilizado. Baseado no software livre, que deve ter uma instalação trivial e ser fácil de usar.

Mesmo desenvolvendo e testando localmente em JBoss, muitas vezes o comportamento entre o WAS e o Jboss não são os esperados… Algo funciona muito bem no JBoss mas no WAS insiste em não funcionar.

Deste modo me vejo obrigado algumas vezes a debugar o código remotamente no WAS, mas para poder fazer isso antes preciso configura-lo para que inicie em modo Debug. Os passos são simples e rápidos, e descrevo os aqui para quem utiliza um ambiente de desenvolvimento parecido com o meu, descrito acima…

Ao contrário do JBoss, para iniciar o Debug Mode do WebSphere é necessário configurá-lo através do seu “console manager”. Abaixo estão os passos a seguir:

1. Inicie o servidor normalmente.
2. Acesse o “Administrative Console” – Console administrativo. A url do serviço é algo como: https://192.168.1.15:9050/ibm/console/ (a porta pode variar bastante).
3. No menu ao lado esquerdo, expanda “Servers” e selecione então o link “Application Servers”.
4. Clique no nome do servidor que você deseja iniciar em modo debug.
5. Na aba “Configuration”, desça até “Additional Properties” e clique no link “Debugging Service”.
6. Em “General Properties”, marque o Startup check box. Isso irá iniciar o serviço de Debug do WAS toda vez que ele for (re)iniciado. Preste atenção na porta de acesso, você também poderá muda-lo caso necessário.
7. Clique em OK e então salve a configuração.
8. Reinicie o Server para que as alterações e o Debug Mode seja iniciado.

Pronto… Simples e rápido… Agora basta configurar o seu eclipse para reconhecer o remote debug na porta escolhida. ;)

No entanto meu eclipse começou a se comportar de forma inesperada, fechando-se sozinho quando eu utilizava a função de autocomplete. Pronto, encontrei mais um bug na nova versão do Ubuntu.

Com algum tempo disponível e uma pesquina na página de bugs do eclipse, encontrei outras pessoas com o mesmo problema discutindo sobre possíveis soluções. Para quem interessar, o número do bug relatado é 304718.

Felizmente a solução foi simples, tratando-se somente de um problema na biblioteca xlrunner que é distribuida com o Ubuntu 10.04 – mais especificadamente versão 1.9.1.

Para resolver o problema, basta remover a versão 1.9.1 desta biblioteca e instalar a versão 1.9.2, para isto, no console digite:

sudo apt-get remove --purge xulrunner-1.9.1
sudo apt-get install xulrunner-1.9.2

Reinicie sua máquina e teste seu eclipse, o problema deverá estar solucionado agora ;)

2) “É impossível nós fazemos, milagres necessitam mais memória.”

3) “Erro #1221: Troque o usuário e pressione uma tecla.”

4) “HTML – Hoje Ta Mais Lento.”

5) “Nunca deixe um computador perceber que você está com pressa.”

6) “Existem apenas 10 tipos de pessoas neste mundo: as que entendem códigos binários e as que não entendem!”

7) “Meu computador é tão lento que não tem tempo de resposta, tem prazo de entrega.”

8) “Keyboard not found. Press F1 to continue.”

9) “Hardware é aquilo que você chuta e Software é aquilo que você xinga.”

10) “Se um dia a terra for dominada por máquinas, e nós escravizados por elas, então rezemos para que o mainframe seja da Microsoft.”

Ubuntu

Já faz algum tempo que estou utilizando o Ubuntu como minha distribuição Linux favorita, e recomendo a todos. O Ubuntu mantém simples toda e qualquer tarefa de manutenção do sistema, o que me consome menos tempo quando por exemplo preciso instalar alguns pacotes requeridos para compilar um driver nativo de comunicação com modem que estou trabalhando.

Utilizar o “apt-get install” no console ou o Synaptic no gnome é algo tão fácil quanto roubar doce de criança, e pensando nisso resolvi relembrar os tempos que trabalhava com o Suse Linux e com o ambiente KDE (nostalgia).

O primeiro passo foi bastante simples, descobrir qual pacote precisava instalar no Ubuntu para que o KDE ficasse disponível. Uma rápida busca no oráculo, e descobri que poderia instalar o Kubuntu no meu Ubuntu.

Ãhn?!

Pois é… Sendo o a única diferença entre o Kubuntu e o Ubuntu o ambiente gráfico (no primeiro KDE, no segundo Gnome), é possível e de forma bastante simples ter ao mesmo tempo, na mesma partição e mesmo S.O. ambas distribuições :) Entenderam? Não é piada não… até dei o apelido de KGubuntu (pronuncia cá-gu-buntu).

Mas porque KGubuntu?

Porque literalmente “kgo” todo meu Ubuntu :/ Eu queria testar o KDE, e acabei ferrando com o Gnome.  O meu Gnome ficou cheio de programas e atalhos para os programas do KDE (Kedit, Kcalc, etc), coisas que simplesmente não são necessários no Gnome.

Resumo da ópera e conclusão? Assim como instalei o Kubuntu, removi-o. Não apenas por ter alterado coisas em meu S.O. que não era para o bico dele, mas também porque a máquina sentou. O KDE continua com uma interface mais “desenhada”, que faz bem aos olhos, mas infelizmente é muito pesado e consome muitos recursos os quais utilizo intensivamente trabalhando.

Mas para quem quiser instalar um versão do KGubuntu em sua máquina, basta adicionar o pacote kubuntu-desktop no synaptic ou no console através do comando: apt-get install kubuntu-desktop

A estes, boa sorte ;)

A Sun está disponibilizando gratuitamente, em parceria com a AMD, o ebook High Performance Computing for Dummies. E para fazer o download basta preencher um pequeno formulário e voilà.

Onde conseguir? Neste link aqui: High Performance Computing for Dummies