Impressionante Instrumento musical

Impressionante o aparelho, fiquei muito animado! Que tal alguém me dar de presente?!
Dispositivo que permite uma "sinestesia auto-induzida" para que você consigo criar sua própria música.

Não entendeu nada neh?? Veja você mesmo:

Ares novos para um coração sufocado

Saudações...
Bem, nesta segunda-feira inicio um trabalho novo: Audaces, empresa que tem uma proposta bastante interessante de adesão ao Desenvolvimento Ágil, e vou participar desse movimento.

Boa sorte pra mim, boa sorte pra Audaces, e vamo que vamo!!

12 Competências para Produtividade

Atualmente estou empenhado em terminar a leitura do livro Leading Geeks de Paul Glen, com a intenção de visualizar novos rumos em minha carreira, mais focado numa área gerencial.
Me deparei com esse livro que tem muito a dizer a respeito de nossa postura como profissionais de TI e de que maneira podemos trabalhar para atingir da melhor forma possível equipes de desenvolvimento.
E sabe do que mais?? Tem muito a ver com Desenvolvimento Ágil!

Paul Glen traça o perfil do profissional de TI (gerente ou não) como uma pessoa que deve ser encarada em sua individualidade e respeitada por seu conhecimento. Assim, pode-se criar um ambiente motivador e que possa retirar o máximo de cada pessoa da equipe. Um líder deve saber encontrar maneiras de dar a liberdade necessária para cada um, e atender necessidades básicas (técnicas, sociais, financeiras e ideológicas) para chegar a esse objetivo.

Mas como medir a produtividade de alguém?? Quando determinar se um profissional está ou não agregando valor à empresa?

No livro, são definidas 12 Competências que podem ser utilizadas para a formação de um bom (porque nao ótimo) profissional de TI. Quem de vocês se identifica nesse perfil?
Minha intenção, no primeiro momento, não é criticar, mas apresentar a constatação do autor.

As 12 Competências para a Produtividade

1. Qualificação Técnica
2. Produtividade Pessoal
3. Habilidade de gerenciar múltiplas tarefas simultaneamente
4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
5. Habilidade de forjar compromissos entre negócio e varientes técnicas
6. Habilidade de gerenciar o relacionamento com clientes
7. Habilidade de gerenciar equipes técnicas
8. Habilidade de executar e manter políticas positivas de relacionamento
9. Habilidade em ampliar o relacionamento com clientes
10. Habilidade de influenciar outros para tornálos produtivos
11. Habilidade de gerenciar ambiguidades
12. Habilidade de gerenciar tempo e estimativas
    

Descreverei sucintamente todas elas:

1. Competência técnica
A mais simples de todas. E normalmente a única competência levada em consideração durante a contratação de um profissional. É a capacidade de utilizar o conhecimento técnico aplicado às necessidades de sistema. Importante também é a abrangência que este conhecimento possui. Ex: um DBA deve ter conhecimento técnico em mais de um banco de dados, senão ele pode estar fadado a um mundo bastante restrito de possibilidades.

2. Produtividade Pessoal
Dificilmente mensurável, mas muito importante. Não diz respeito à qualidade do trabalho produzido, mas à quantidade de esforço que se pode empenhar na realização de uma tarefa. O importante aqui é garantir que o profissional tenha a consciência de sua própria velocidade em realizar tarefas, isto é, qual o seu estilo de trabalho: rápido ou lento.

3. Habilidade de gerenciar múltiplas tarefas simultaneamente
Fato: não é novidade que projeto em produção geram demanda para desenvolvedores independentemente de prioridades (sim, se vc nao usa desenvolvimento ágil, isso é muito comum), o que exige do profissional a capacidade de deixar uma tarefa pela metade, resolver uma emergência e voltar do ponto em que havia parado (nota: difícil??)

4. Habilidade de descrever o contexto de negócio em que o trabalho(técnico) está inserido
Bom seria se todos os funcionários tivessem noção de regras de negócio. Esta competência diz respeito à capacidade de utilizar o conhecimento técnico para vislumbrar a agregação de valor ao negócio que a tecnologia pode trazer.

5. Habilidade de forjar compromissos entre negócio e varientes técnicas
Talvez a melhor definição desta capacidade esteja em comunicação. em todas as esferas, possibilitando que o profissional transite nos mais diversos ambientes do projeto: sejam áreas técnicas ou estratégicas, conseguindo assim garantir o entendimento de todos quando à solução proposta a um sistema

6. Habilidade de gerenciar o relacionamento com clientes
Aqui fica bem claro o papel do lider em mostrar a maneira que se deve tratar todos os clientes da equipe. Apesar da natureza individualista e instrospectiva dos profissionais de TI, é imprescindível ter desenvoltura e tato ao lidar com clientes.

7. Habilidade de gerenciar equipes ténicas
Somente poucos problemas técnicos e estratégicos podem ser resolvidos por apenas uma única pessoa. Isto quer dizer que, no ambiente de TI, o trabalho em equipe é extremamente necessário devido à complexidade da função. Assim, o papel de motivar e gerenciar equipes é importantíssimo (para gerentes, obviamente).

8. Habilidade de executar e manter políticas positivas de relacionamento
"Nenhum homem é uma ilha". Leve isso a sério!

9. Habilidade em ampliar o relacionamento com clientes
Capacidade de identificar necessidades e oportunidades para expandir a área de atuação com os clientes.

10. Habilidade de influenciar outros para tornálos produtivos
Inspiração e liderança estão muito ligadas a essa habilidade.

11. Habilidade de gerenciar ambiguidades
O quão facilmente o profissional consegue lidar no ambiente adverso que pode ser a Tecnologia? Como ele responde a interpéries durante o projeto?

12. Habilidade de gerenciar tempo e estimativas
(tradutor: aqui acredito que seja a capacidade de autoconhecimento que o profissional deve ter, e a maneira com que ele consegue gerir seus horários, compromissos e estimativas firmadas. Assim como a maneira dele portar-se ao descumprir uma delas.)


É isso... percebam que características técnicas são apenas uma pequena parte do complexo modelo de Paul Glen.

Guia para transição ao Desenvolvimento Ágil

Visitando o InfoQ - aliás, ótimo site, assisti a uma apresentação de David Hussman e Tor Stenstad dando um overview da experiência dos dois na migração para Metodologias Ágeis.

Como está em inglês, vou colocar alguns comentários importantes sobre questões pertinentes e úteis:

Transition to Agile

Antes de mais nada, vale salientar um comentário bastante importante: "Não existem balas de prata". Se você está atrás de um checklist que o levará ao clímax do desenvolvimento de software, à panacéia de todos os males mundanos.... bem, vc está enganado...

O projeto tratado na apresentação é de uma empresa grande, segundo Tor, uma das 500 da Fortune, possuidora de um modelo tradicional de desenvolvimento baseado em RUP.

A primeira iniciativa na adoção do desenvolvimento ágil (Iniciado com um projeto piloto - MUITO IMPORTANTE) foi tentar remover mitos relacionados ao Desenvolvimento Ágil, já que muitas pessoas pensam ainda que estejamos tratando de Code and Fix. Inclusive os programadores precisam entender que nossa postura não vai remover todo e qualquer processo dentro da empresa. Para isso, é importante a figura de alguém que já conheça do assunto, com experiência prática em XP, Lean, SCRUM, etc. Assim, evitaremos cair em diversos problemas corriqueiros dentro da implementação de processos de desenvolvimento. Listinha didática:

• Encontre um mentor (pode chamá-lo de consultor, nerd especializado, empresa parceira, programador mais espertinho)


• Remova os mitos


• Ajude a educar as pessoas


• Encontre um projeto piloto. NUNCA tente implacar um processo na empresa toda de uma vez

IMPORTANTE: Escolha a dedo as práticas que você deseja implementar. Não assuma a responsabilidade de implantar todas as técnicas de XP de uma vez só... vai ser problema na certa.

Como proceder:

• Compreenda o ambiente em que a empresa está inserida. É muito importante identificar até onde você pode alcançar no processo. Converse com as pessoas, descubra como elas trabalham. Somente assim essa mudança será o mais indolor possível.
• Começe atacando problemas pontuais, mas pense grande. Tente diminuir o tamanho das iterações, inicie uma conversa sobre teste de software, fale sobre TDD... aos poucos, com a intimidade que as pessoas ganham com a prática, desenvolva novos desafios para a equipe, implante uma nova prática, e construa um ambiente propício a esse aprendizado. Importante é verificar a forma que sua empresa é construida, e assim determinar quais práticas utilizar.
  
• Compartilhe a visão do projeto com TODOS os comprometidos. Muito importante que tanto a área de produto quanto teste, desenvolvimento e vendas tenham a mesma idéia dos objetivos que o projeto se propõe.
• Crie ambientes informativos para todos tenham acesso ao que ocorre no projeto. (Veja a discussão na lista xpRio)
  

Um termo interessante abordado: Living plan
O conceito faz referência à criação de um planejamento (nao um plano) que evolui à medida que o projeto progride no tempo. Este living plan emprega conceitos como:

• Crie um backlog para que você possa ter uma visão clara do quê deve ser implementado de uma forma macro
• Valorize as pessoas! Crie um ambiente onde as pessoas possam falar e ser ouvidas, e que sugestões e problemas identificados por membros de equipe tenham peso real na tomada de decisão
  
• Dimiua o tamanho das iterações para ter o feedback mais rápido de onde exatamente você está
• Utilize o desenvolvimento iterativo
• Faça com que os clientes participem do projeto. Torne-os engajados.
• Defina o que é uma funcionalidade terminada: encontre o real significado de término de uma funcionalidade. Se as premissas da empresa supõe a entrega de documentos, coloque-os na estimativa.
  

Achei interessante a visão que eles deram sobre o cliente:
Qual cliente não gostará de se envolver no desenvolvimento ao descobrir que ele é o responsável por tomar decisões de negócio para o projeto? Imagine-se com o poder de mudar o rumo de todo o projeto a cada mês/semana? Você não gostaria de participar?

Ponto importante: Tenha a coragem de refer o planejamento e todo o processo de desnevolvimento se algo estiver errado. Isto mesmo, utilize o Burndown Chart para a tomada de decisão. Se o gráfico lhe diz que algo está errado, MUDE!

Dicas para líderes

• Participe das reuniões diárias
• Converse com as pessoas, não tenha medo de receber críticas. Demonstre respeito pela opinião das pessoas da equipe e assuma a responsabilidade de mudar, caso algo esteja errado no que você estiver fazendo
• Crie uma comunidade dentro de sua empresa, fomente discussões, práticas, palestras. (Por que não organizar uma sessão de CodingDojo em sua empresa?)

Com vocês, o vídeo (desculpem... nao consegui deixar a apresentação "embebed" no meu site):



Assista a palestra na integra: http://www.infoq.com/presentations/agile-transition-hussman-stenstad

Coding Dojo Floripa dia 30/08

Saudações!
O Próximo DojoFloripa será dia 30/08 na Fundação Certi.
Necessário confirmar presença: (gaa@certi.org.br)

Mais informações: CodingDojoFloripa

You think you know (JavaScript) but you have no idea

Seguindo a iniciativa do Rafael Mueller, que por sinal foi muito bem sucedida, vou tentar apresentar um pouco sobre JavaScript, tentando desmistificar essa história de JS como uma Ciência Oculta, destinada apenas às famosas gambiarras do mundo do desenvolvimento de software.

Concordo com o Douglas Crockford quando ele diz que JavaScript é a Lingaguem de Programação mais não-compreendida do mundo. E digo mais, isso é culpa nossa!
Somos nós, programadores, que normalmente não buscamos a melhoria de nosso código fonte devido a uma série de fatores: falta de ferramentas de apoio, desinteresse ou preguiça. Acreditar que no desenvolvimento web a camada de apresentação não precisa da mesma atenção e cuidados que as camadas de persistência e negócio, é fadar o sistema ao limbo da manutenção.

Vou passar alguns conceitos, visando a melhoria do código produzido em javascript:

Você pode não gostar da idéia, mas a grande maioria dos computadores do mundo possuem ao menos um interpretador JS instalado.

Orientação a objetos

Sim! Orientado a objetos! De uma maneira diferente de algumas linguagens, mas javascript e totalmente orientado a objetos. E infelizmente como toda linguagem (ak. Java, Cpp, C#) também existe uma enorme possibilidade de produzir código ruim, escrevendo um programa sem a menor compreensão de OO.

JS possui objetos que podem conter dados ou métodos para tratar dados. Objetos podem conter outros objetos. Mesmo não possuindo a definição de classes, existe o conceito de constructor que possui o mesmo princípio. Ainda possui um sistema de objetos com herança (é-um) e agregação (possui-um).

Metodos e atributos privados? Claro que possue....

Vamos ao código:

Variáveis e Métodos públicos

Os membros de um objeto são sempre públicos. Podem ser modificados, utilizados ou alterados por qualquer função. Existem duas maneira de colocar novos membros a um objeto:

Utilizando um construtor:

function Container(param) {
 this.nome = param;
}

Criando Objeto:

var umContainer = new Container('nomeCont');

Assim, a umCantainer.nome possui o valor 'nomeCont'.

Utilizando o prototype:
Tecnica utilizada para adicionar metodo publicos a um objeto. O mecanismo de prototype é utilizado para herança, ele também conserva memória. Para adicionar um novo metodo a um objeto:

Container.prototype.getNome = function(){
  return this.nome;
}

Assim o método pode ser utilizado normalmente:

umContainer.getNome()

Métodos estáticos:
A estratégia de utilizar o prototype é uma grande vantagem para o desenvolvimento, entretanto os métodos criados através desse modelo ficam acessíveis apenas após a instância do objeto. Uma maneira de criar métodos estáticos em JS é através do mesmo princípio que utilizamos acima, com atributos:

function Container(param) {
 this.nome = param;

 this.metodoEstatico = function() {
      return 'Eu sou um método estático';
 }
}

Tanto o atribuito Container.nome quanto Container.metodoEstatico() estão disponiveis sem que haja a necessidade de instarciar a classe.


Variáveis e Métodos privados

Variáveis dentro de um objeto são considerados privados:

function Container(param) {
  this.nome = param;
  var secret = 0;
  var that = this;

  function diminuirUm() {
      if (secret > 0) {
           secret -= 1;
           return true;
       } else {
           return false;
       }
  }
}

Acima, o atributo secret é apenas acessível pela própria instância do objeto Container, assim como o metodo diminuirUm. O atributo that, descrito como a solução para um problema de Especificação da Linguagem ECMAScript, serve para tornar o objeto disponível para os métodos privados. Assim, para fazer uso de métodos privados, necessitamos apresentar o conceito de métodos Privilegiados, capazes de acessos metodos públicos e privados de um objeto.

Métodos privilegiados

São métodos destinados a serem acessíveis de forma pública, entretanto possuem acesso aos métodos privados de um objeto. É possível removê-lo ou alterá-lo, mas não é possível através dele ter acesso real (alteração, exclusão) aos métodos e atributos privados.

function Container(param) {
   this.nome= param;
   var secret = 3;
   var that = this;

   function diminuirUm() {
       if (secret > 0) {
           secret -= 1;
           return true;
       } else {
           return false;
       }
   }

   this.service = function () {
       if (dec()) {
           return that.nome;
       } else {
           return null;
       }
   };
}

service é um método privilegiado. Chamando umContainer.service() obteremos o retorno 'nomeCont' apenas por três vezes, e após isso será sempre retornado null. service é disponível para outros objetos, mas seus atributos não.


Será que consegui melhorar seu conceito?? Ainda não?? Logo tem mais!
Fonte

Douglas Crockford fala sobre JavaScript

SCRUM em português

Você está cansado de buscar materiais sobre SCRUM e só encontrar coisas em inglês? Tem preguiça de ler ou dificuldade em ouvir podcasts em inglês?? A AgilCoop tem a solução!!
Seus problemas acabaram: Aqui está! Um Agilcast de introdução ao SCRUM de forma rápida e direta. Ideal para quem não quer perder tempo ouvindo as porcarias da internet!:

TDD Anti-Patterns

Aqui está a tradução (e considerações) para o texto de James Carr entitulado TDD Anti-Patterns
Acredito que essa contribuição é válida, pois ainda vejo muitas pessoas buscando materiais em português sobre testes, e encontrando pouca coisa de qualidade. Segue o texto abaixo:


Catálogo de Anti-Padrões em TDD

• The Liar
  
• Todos os metodos de um teste unitário estão passando perfeitamente, aparentando serem validos, entretanto sob uma inspeção mais próxima é descoberto que o teste unitário não testa o real intuíto para que foi criado.

• Excessive Setup
  
• Um teste que necessita muito trabalho para ser configurado antes mesmo de ser executado. Algumas vezes centenas de linhas de código tornam-se necessárias para adaptar o ambiente a um único método de testes, com dezenas de objetos envolvidos. Aqui a maior dificuldade é compreender "o quê" realmente está sendo testado dentro de toda a "sujeira" que um setup pode causar. (tradutor: Lembrem-se sempre do princípio KISS)

• The Giant
  
• Um teste unitário que, mesmo sendo verdadeiro na intenção de validar um objeto, pode possuir centenas de linhas contendo inúmeros casos de teste (inúmeros mesmos). Esta pode ser uma indicação do que chamamos de God Object, objeto que possui responsabilidades demais dentro do sistema. Indício claro de alto acoplamento em seu sistema.

• The Mockery
  
• Muitas vezes um mock pode ser útil e bastante indicado. Mas desenvolvedores podem perder tempo desnecessariamente esforçando-se em mockear o que não está sendo testado. Percebe-se neste caso que a classe possuí tantos mocks, stubs ou fakes que no final das coisas o sistema não está sendo testado, mas o que é retornado da interação entre os mocks. (tradudor: use apenas o que for estritamente necessário!)

• The Inspector
  
• Um teste unitáro que viola o encapsulamente em um esforço de atingir 100% de cobertura de testes, mas está situação nem sempre é favoravél, pois qualquer tentativa de refactor pode quebrar testes desnecessariamente, necessitanto adequações nas classes de teste unitário.
• Generous Leftovers
  
• Uma instância de um teste unitário cria um dado que é persistido em algum lugar, e outro teste utiliza tal dado para seus próprios asserts. Caso algo saia errado, o teste que utiliza o dado cadastrado também falhará. (tradutor: Testes devem ser independentes! )

• The local Hero
• Um teste que é dependente de algo específico do ambiente de desenvolvimento em que ele foi escrito. O resultado: o teste passa perfeitamente na células de desenvolvimento, mas falha quando alguém tenta executá-lo fora desse ambiente.

• The Nitpicker
• Um teste unitáro que compara toda a saída quando o que lhe deveria interessar é uma pequena parte apenas, assim o teste deve se manter sempre alinhado com detalhes que o teste não deveria tratar. Esta situação é endemica em testes de aplicações web.

• The Dodger
• Um teste unitário que possui muitos testes para efeitos pequenos (e presumidamente simples de testar), mas nunca testando o comportamente real desejado. Encontrado em testes relacionados para testes de banco de dados, onde um método é chamado, e então o teste seleciona itens do banco e procede asserts contra os resultados.

• The Loudmout
  
• Um teste unitário (ou suite de testes) que enxe o console com mensagens de diagnóstico, logs e qualquer outro tipo de saídas, mesmo quando os testes estão passando. Algumas vezes durante a criação dos testes existe o desejo de manualmente ver a saída dos metodos, mas mesmo eles deixando de serem necessários, são deixados para trás.

• The Greedy Catcher
• Um teste unitário que trata exceções e sobrepões pilhas de execução (stack trace) algumas vezes com mensagens menos informativas, mas algumas vezes ainda apenas logando (Loudmouth) e deixando o teste passar.

• The Sequencer
  
• Um teste unitário dependente de uma lista que sempre é retornada em forma desordenada.

• Hidden Dependecy
  
• Primo de primeiro grau do "The Local Hero", um teste unitário dependente de um dado que deve ser populado em algum lugar par ao teste rodar. Se o dado não estive presente, o teste falhará deixando pouca informação para o desenvolvedor o que é necessário, ou porque o teste falhou... forçando-o a buscar através de uma floresta de código para descobrir de onde vem o dado que o teste deveria utilizar.

• The Enumerator
  
• Um teste unitário em que os nomes de métodos são apenas uma enumeração: teste1, teste2, teste3. Como resultado, a intenção dos testes torna-se pouco clara, e a única maneira de ter certeza é ler o código fonte e rezar para que esteja bem escrito.

• The Stranger
• Um método de teste que nem ao menos pertence ao Teste Unitário que ele está inserido. O método está realmente testando um objeto separado e independente, normalmente um objeto utilizado pelo objeto que sofre o teste.

• The Operating System Evangelist
• Um teste unitário que está ajustado apenas para um determinado sistema operacional para que possa funcionar. Um bom exemplo seria um caso de teste que utilize o separador de linhas do Windows para um assert, que falha apenas rodando em Linux.

• Success Against All Odds
• Um teste escrito para passar antes mesmo de falhar. Como um infeliz efeito colateral, o caso de teste acaba sempre passando mesmo que tenha sido feito para falhar.

• The Free Ride
• Ao invés de escrever um novo teste para uma nova funcionalidade ou característica, apenas um novo assert é criado ao final de um teste já existente.

• The One
• Uma combinação de alguns outros padrões, particularmente o TheFreeRide e TheGiant. Um teste unitário que contém apenas um único metodo que teste todo tipo de funcionalidade que um objeto pode conter. Um indicador comum é que o teste possui o mesmo nome da classe, e ainda com múltiplas linhas, setups e asserts
  

• The Peeping Tom
• Um teste que, compartilhando recursos, pode ver o resultado de outro test, e pode falhar mesmo que o sistema testado esteja em perfeito funcionamento. Verificado na ferramenta Fitnesse, onde a utilização de variáveis estáticas para abrigar coleções não eram corretamente limpas após a execução do teste, podendo surgir erros durante a execução de qualquer teste. Também conhecido com TheUninvitedGuests.

• The Slow Poke
• Um teste unitário que é incrivelmente lento para ser executado. Quando o teste é iniciado, os programadores podem ir ao banheiro, fumar um cigarro ou pior ainda, inicar o teste no final do dia e ir para casa, esperando que o resultado saia no dia seguinte.
  

Fonte

Treinamento de TDD: Testes! Código! Ação!

Evento que será realizado aqui perto, em Joinville - SC:

Treinamento de TDD na PyCon Brasil 3, em Joinville, SC.

Nível da Palestra: Intermediário

Como desenvolver código limpo, fácil de evoluir e que possa ser mudado sem medo quando necessário? Este treinamento é um exercício prático e interativo de Desenvolvimento Dirigido por Testes (TDD), uma das práticas mais eficazes da Programação eXtrema (XP). Os participantes serão guiados no desenvolvimento "ao vivo" de um jogo simples a partir de testes unitários, enfatizando os valores desta prática e a importância do foco constante no design simples e em código correto, conciso e legível.

Palestrantes

Rodrigo Bernardo Pimentel e Danilo Toshiaki Sato

São Paulo - SP

Rodrigo: Programador por profissão e hobby. Pythonista há alguns anos. Curioso. Escreve em http://isnomore.net.

Danilo: Desenvolvedor de software generalista, consultor da AgilCoop, mestre pela USP e blogger esporádico em http://www.dtsato.com.

Mais informações


Infelizmente não poderei ir... será que alguém do CodingDojo estará por lah?

Tipos de Teste - Palestra AgilCoop

A palestra abaixo foi apresenta pela AgilCoop, vale a pena, bem curtinha:
Edit: Palestra bastante simples e técnica, servindo apenas para um overview geral de como utilizar testes de software.

Agile Testing

A apresentação abaixo, retirada do Blog do Abu, feita no Google Tech Talks, trata sobre a maneira com que métodos Ágeis lidam com a questão de testes.
Mais do que uma apresentação, é o testemunho de uma utilizadora de XP e TDD: Elisabeth Hendrickson. Interessante a visão de alguém que se diz "não especialista" e que vem de um departamento de testes nos moldes mais tradicionais possíveis, em que um departamente isolado, sem contato com o código, testa o software desenvolvido.

Questões abordadas:

Foco em Testes é, antes de tudo, uma forma de Design de Software! (acostume-se a isso)

Seja adaptativo! Seja flexível: contrua com qualidade!

Built Quality in - isto é: a maior vantagem em se construir com o foco nos testes é que problemas são encontrados muito cedo no projeto, fazendo com que uma correção ou mudança não gera o impacto tradicional no projeto.

Trasforme os testadores em parte integrante da equipe de desenvolvimento. Crie um ambiente em que se possibilite a interação social e ativa de todos aqueles que deveriam estar comprometidos com o software.

Remova o estigma que testadores possuem em projetos: os chatos. Reúna testadores, designers e desenvolvedores e veja todos efecientimente colaborarem para o projeto. Torne-os comprometidos!

Automatize processos repetitivos!! Existem inúmeras ferramentas que dão a possibilidade de você manter builds automáticos, controle de versionamento, testes e estatísticas sobre seu desenvolvimento. Use-as!


Com vocês, Elisabeth

Veja também: Test Obsessed

50 ações para conter o Aquecimento Global

Há pouco tempo assisti a um filme impressionante: Uma Verdade inconveniente, onde Al Gore discursa sobre o aquecimento global. Muito bem fundamentado, o filme trata do aquecimento global, com a seguinte premissa: cabe a nós, cidadãos do mundo, o papel de conter o processo. E ainda há tempo.

Pesquisando sobre o assunto, acessando o Ueba encontrei um texto falando das 50 ações para conter o aquecimento global. Vou listar as mais simples e importantes abaixo:

• Gere menos lixo!!
• use canecas ao invés de copos descatáveis
• garrafinhas de água
• leve grandes sacolas ou bolsas ao supermercado
• se o intuíto de algum item é ir direto para o lixo, por quê levá-lo para casa? isso vale para papeizinhos de rua, sacos plásticos e extratos bancários impressos
• utilize menos CDs e DVDs substituindo-os por penDrivers e emails de grande espaço
  
• Troque suas lâmpadas incandescentes por fluorescentes
• 60% a menos de energia do que as convencionais
  
• Escolha eletrodomésticos de baixo consumo energético
• O imetro criou um selo de consumo de energia para aparelhos - Escolha produtos com este selo (Veja as tabelas de consumo)
  
• Não deixe seus aparelhos em standby
  
• Economize 15% a 40% da energia que seus aparelhos consomem
  
• Use a máquina de lavar roupas/louça só quando estiverem cheias
• assim, água e energia são economizadas
  
• Nunca é demais lembrar: RECICLE
• Que tal propor o seguinte: separação do lixo em seu condomínio?? Na sua empresa?? simples...
• Empresas hoje conseguem reduzir muitos custos com um programa simples: reciclagem de papel! Impressoes com problemas saem do lixo e transformam-se diretamente em dinheiro no caixa das empresa!
• Por que nao fazer o mesmo com o seu condomínio?? Que tal diminuir a taxa de arrecadação (o famoso rateio) mensal de todos os apartamentos com uma proposta de venda de papel para reciclagem e latas de alumínio??? COISA CHIQUE D+!!!!
  
• Reduza o uso de embalagens
  
• Eu acabo sendo chato... mas tente repetir a seguinte frase para o atendente que insiste em colocar numa sacola a caixa do dvd na locadora: "Não precisa de sacola, muito obrigado. Gera mais lixo". Qual será a reação dele??
• Vá às compras de mochila ou sacola e evite compras muito grandes: consumismo demais gera lixo demais
  
• Lave o carro a seco
  
• (veja este site )
• Vá de escada
• Hábitos saudáveis também são muito úteis. Pergunte-se: será que preciso realmente ir de elevador?
  
• ECONOMIZE ÁGUA
• Preciso dizer algo mais???
  

Veja a lista completa

Como fazer homens lavarem as mãos

Donos de bares e restaurantes: Seus problemas acabaram!!!
Chegou a revolucionária forma de conseguir que os homens menos higiênicos lavem as mãos ao saírem do banheiro!

Essencial!! Ergonomicamente viável e ecologicamente correto!!! (lembram daqueles manequins que são despejados após anos de uso em lojas de roupa??? Pois então!)

ROI na Melhoria de Processos

Juan Bernabó, da TeamWare, iniciou uma discussão muito pertinente sobre de que maneira calcular o ROI para a melhoria de processos com a implantação de práticas ágeis.

Pontos importante:

Danilo Sato possuí uma dissertação com o tema:
"Uso Eficaz de Métricas em Métodos Ágeis de Desenvolvimento de Software"

http://www.dtsato.com/blog/default/Personal/2007/08/10/Mestre-finalmente.html
http://www.agilcoop.org.br/portal/Artigos/dissertacaoDaniloSato.pdf

Vale a leitura!

Acompanhe a discussão na lista xpRio

ROI para o Desenvolvimento Ágil

Iniciando a série de comentário sobre o transforma equipes em times, precisamos levantar alguns conceitos importantes relacionados ao desenvolvimento de softwares de forma Ágil. A primeira idéia é relacionada ao retorno sobre investimento que a prática consegue proporcionar.

Apresentado pela primeira vez no site do Ivan Sanchez, o video abaixo traz uma explicação interessante sobre de que maneira o Desenvolvimento ágil pode, continuamente, agregar valor a um sistema, ultrapassando o clássico ciclo de vida do desenvolvimento de software, pois consegue gerar alto valor agregado ao longo da vida do software, alinhando-se com as necessidades de mercado, e respondendo rapidamente a mudanças de rumo do processo de negócio que o software está inserido.
A formula é simples:

O desenvolvimento ágil, através de iterações rápidas, de menor valor agregado em menor tempo de desenvolvimento consegue suprir a necessidade do mercado de soluções rápidas e alinhadas às necessidades de negócio, ampliando o desempenho financeiro que um software pode alcançar.

Com vocês, a explicação:

Webinars - Lean, SCRUM, Desenvolvimento Ágil

Saudações!
Agradecendo a indicação do Rafael Mueller, seguem abaixo as apresentações que a NetObjectives disponibilizou sobre Lean, SCRUM e Desenvolvimento Ágil...
Vale muito a pena assistir...

• Scaling Scrum with Lean and Design Patterns



• Using Lean Thinking for Portfolio Management



• Lean Thinking Overview

English as Second Language

Sessão utilidades!
Se você está tentando melhorar o seu inglês, esse site é uma ótima pedida... quase diariamente surgem podcasts sobre algum assunto em inglês... tudo simples e muito bem explicado... vale a pena cadastrar no seu leitor de notícias e ouvir de vez em quando...

Praticar é viver!
English as a Second Language

Segue abaixo um exemplo:

Diferença entre times e Equipes

A palavra da vez é: Comprometimento
Sabemos o que significa, mas muitas vezes desconhecemos suas reais manifestações. Assim, livros e mais livros sobre liderança, trabalho em equipe e gestão de pessoas surgem tentando exprimir sempre a mesma visão: pessoas comprometidas geram resultados positivos para a empresa.

E como alcançamos o comprometimento esperado?? - algumas idéias

• Criando o sentimento de responsabilidade pelos projetos


• Poder decisório dentro dos projetos


• Visibilidade dos objetivos e premissas que regem um projeto


• Ambiente propício ao aprendizado e convívio social agradável

Eu sei, tudo bem... complicado de executar o que escrevi?? Vago e simplório o que está na lista??
Será mesmo?? ...
Escreverei sobre os item acima no decorrer dessa semana...

Mas antes disso, o vídeo abaixo...

All Blacks é uma das melhores equipes de Rugby do mundo. Impressionante a forma com que a equipe inicia todas as suas partidas: com cânticos de guerra dos aborígenes Neo-zelandeses. Pode-se ver o empenho com que eles iniciam uma partida. Espetacular...
Reparem as caras dos adversários: queixo caído, intimidados... até eu fiquei com medo... tem uns dois ali que estão completamente alucionados... pra matar ou morrer! (lembram da história do porco e da galinha?)

Por que não formamos equipes de desenvolvimento de software dessa maneira???

Vestido inflável

Ok, eu sempre vou me perguntar o que fazem para ganhar a vida pessoas com essas idéias: Chegou a solução dos seus problemas!!! Você caminha demais? Nos dias de hoje, aonde é extremamente difícil achar um lugar para sentar, o que você faz??? De uma voltinha e encha você mesmo o seu vestido que se transforma numa cadeira! Olha só que coisa boa!!!
Repare nos pés dela: sim! bombas de encher pneu de bicicleta!!! com a caminha o vestido enche, se transformando numa poltrona, ideal para shows no maracanã lotado ou trilhas pela mata... aproveite!!!

E tem um vídeo ainda:

http://jooyounpaek.com/ssc_01.html

cada coisa que me aparece...


Fonte: http://www.engadget.com/2007/08/07/inflatable-dress-turns-into-a-chair-for-impromptu-sits/

SCRUM by Ken Schwaber

Com a palavra, um dos criadores do SCRUM, Ken Schwaber, em uma palestra na sede do Google.

Vale a pena conferir:



http://video.google.com/videoplay?docid=-7230144396191025011

O título

Bem, inicio meu primeiro post realmente com uma pequena explicação do tema, ou melhor, da escolha dele.

Fazendo uma pequena brincadeira com um clássico da literatura mundial (A Divina Comédia - Dante) tentarei apresentar às pessoas que por ventura possam ler as minhas postagens uma coisa diferente do que foi o livro ou a sua intenção.

Não farei aqui uma viagem metafórica aos confins do inferno para explicar as frustações humanas, seus fantasmas e demônios, suas fraquezas e paradoxos... Divina Comédia vem do lúdico,do imaginário que nos invade a todo o momento.

A Maldita Comédia podemos dizer que apresentará a vida como ela é! Sob a visão de um jovem de 20 e poucos anos que há muito tenta passar pelo mundo deixando alguma coisa para as pessoas, nem que seja um sorriso. E assim seguiremos, eu e você: um apresentando e outro recebendo emoções da vida realmente como ela deve ser mostrada... maldita! Sangrenta, verdadeira, literal e maravilhosamente engraçada.... sim maldita.... sim uma comédia...


é isso

Voltando à ativa

Saudações... vou voltar a escrever neste espaço.

O conteúdo existente em A Maldita Comédia continua disponível... e quem sabe eu ainda reagrupe tudo um dia...

Fiquem atentos!