Retrospectiva do Ano

Se você está acostumado aos métodos ágeis, sabe que feedback é um dos valores fundamentais. Ele é dado em diferentes momentos e, de forma sistemática, aparece a cada final de iteração no que se convencionou chamar retrospectiva.

Fora da informática esse termo não é incomum. Todos os meios de comunicação, por exemplo, fazem retrospectivas do ano. Ali eles apresentam todos os fatos que consideraram relevantes. No contexto de desenvolvimento de sistemas, a ideia é pegar a informação do time de desenvolvimento. Sem limitação sobre os assuntos.

Normalmente as nossas retrospectivas são feitas verbalmente com auxílio de papel e caneta. Pela primeira vez, resolvemos fazer um período maior que o sprint e usando post-its. Dessa vez, fizemos para o ano todo, separando a parede em três grandes colunas rotuladas como: "Boas", "Não Funcionaram" e "A Melhorar".

O funcionamento da atividade é simples. Vários post-its e canetas a disposição de todos. Cada um do time escreve o que quiser. Todos tem direito de ler o que os outros escreveram, assim como repetir o que já foi apontado, para reforçar alguma ideia. Depois do número de colagens na parede ter estabilizado, vem a rodada de comentários sobre os pontos levantados.

O resultado foi ótimo. O fortalecimento das relações da equipe foram repetidamente ressaltadas. Mais do que isso, aquilo que não funcionou além de identificado, foi analisado. Sem exceção, tudo relacionado a segunda coluna recebeu propostas de alteração para que efetivamente sejam melhor praticadas. Ainda estamos compilando os resultados para que possamos decidir, entre todas as possibilidades, quais atacar prioritariamente.

2010 promete!

E você, tem feito retrospectivas?

JBoss, JProfiler, Eclipse e Linux

Para usar o JProfiler no Eclipse dentro do Linux (testado no Fedora 12) são necessários os seguintes passos:

1. Instalar o Fedora 12
2. Instalar o Eclipse
3. Instalar o Web Tools Platform
4. Instalar o JBoss Tools
5. Instalar o JProfiler

Uma vez feita a integração com o Eclipse (leia a documentação do JProfiler) e também a integração do Eclipse com o JBoss Tools (configurado) é necessário adicionar as bibliotecas do JProfiler na carga de bibliotecas do sistema:

#---
cat > /etc/ld.so.conf.d/jprofiler.conf << __END__
/opt/jprofiler6/bin/linux-x86/
__END__
ldconfig
#---


Adicionar a linha: "-agentlib:jprofilerti=port=2025" a execução do JBoss no Eclise:



Ao executar o JBoss disparar o JProfiler e conectar à uma nova seção remota na porta 2025

Problemas com Eclipse no Fedora 12

Descrição do problema:

Alguns botões, especialmente OK e Finish, não respondem ao clique do mouse. É necessário manter o foco no botão (mantendo o mouse sobre o botão, por exemplo) e pressionar a tecla ENTER.

Solução (simples):

É necessário sobre-escrever uma variável de ambiente antes de executar o eclipse:

#---
GDK_NATIVE_WINDOWS=true eclipse
#---


solução (para atalho no desktop):

Crie um script shell e o use como comando no atalho:

#---
cat > ~/bin/eclipse.sh << __END__
GDK_NATIVE_WINDOWS=true eclipse
__END__
chmod 755 ~/bin/eclipse.sh
#---






Fonte: http://forums.fedoraforum.org/showthread.php?s=a3c988d542abeeb3b04991ab5c12070d&p=1301362#post1301362

DICOM

A transmissão de imagens médicas vem sendo feita há algum tempo. Nada mais natural, então, que surgissem alguns padrões nessa área, como o DICOM. Aqui, o estamos usando no manuseio de alguns exames, como Ecocardiografia e Retinografia. Tenho certeza que mais empresas e estudos brasileiros também estão. Assim, criamos uma lista de discussão para que diferentes pessoas possam trocar experiências e dúvidas. Se te interessa, dá uma conferida:

* Nome do grupo: DICOM - Brasil
* Página inicial do grupo: http://groups.google.com.br/group/dicom-brasil
* Endereço de e-mail do grupo: dicom-brasil@googlegroups.com

Autonomia, Domínio e Propósito

O Gustavo me mandou um vídeo muito interessante sobre motivação. O apresentador reflete sobre a obsolência do sistema de recompensa e apresenta uma solução para o século XXI. Para ele, uma melhor abordagem para a resolução de problemas é baseada em "Autonomia, Domínio e Propósito". Eu estava mesmo lendo esses dias um material que citava como um dos valores centrais da comunidade ágil a autoridade sobre os assuntos técnicos. Segundo os autores, os desenvolvedores estão sempre batalhando para manter seu código simples e direto. Eles avançam sempre para estar de acordo com o que há de melhor em solução tecnológica.

Olhando para os quadros com tarefas (presentes em XP, Lean/Kanbam e afins) onde cada membro da equipe escolhe o que fazer, vemos um bom exemplo de autonomia. Ora, quer melhor exemplo que a livre escolha, sem microgerência, para desenvolver o coeficiente de viração própria e a responsabilidade? Ter o poder de decidir qual tarefa atacar, podendo se basear no que já conhece para ganhar tempo, ou no que não sabe para ganhar conhecimento, fortalece toda a equipe. Longa vida ao nosso quadro!

Aqui no Elsa, é fácil ver o propósito do projeto. Ajudar a ciência e a população são causas muito nobres. Domínio, é uma busca individual, coletiva e diária. Acho que estamos no caminho certo. E você, também está?

Segurança ou paranóia

Quando se trata de segurança normalmente existem dois grupos de pessoas: os paranóicos e os otimistas. Eu faço parte do primeiro. Mas a questão é até que ponto a paranóia é realmente paranóia e quando ela passa a ser necessária? O que se observa em metodologias ágeis é que se deve fazer aquilo que é estritamente necessário para o funcionamento do sistema/programa. Mas puxando a "brasa" para o meu lado: quando o sistema deixou de funcionar porque houve um problema segurança, isso não entra no estritamente necessário? Afinal deixou de funcionar.

A questão vai além da definição mais clássica segurança, que é a proteção do sistema contra acesso não autorizado. Mas isso se aplica também a questões de acesso indevido mas autorizado. Como uma funcionalidade que deveria ter acesso restrito à alguns usuários mas por descuido ou relaxamento do programador não teve a sua restrição imposta. Além disso existem as questões da chamada "programação otimista", onde se confia que as coisas irão funcionar, sem que se busque verificar se elas realmente funcionam. Lógico que "blindar" cada parafuso do sistema é bobagem, assim como tentar aplicar alguma validação formal em todos os métodos (nada a ver com TDD). Mas existem momentos em que sim a paranóia não somente é necessária mas como pré-requisito para que se evitem dores de cabeças no futuro (nem tão) distante.

Cliente Presente

Fui a uma formatura esses dias e o paraninfo tinha uma frase de cumplicidade com seus afilhados que era algo como "Tamo junto". A origem da frase remetia ao fato de tanto o professor como os alunos estarem no mesmo lado, trabalhando pela formação acadêmica todas as sextas a noite e sábados dia todo. Alguns dias depois, fui a um evento de testes onde o palestrante pediu para os presentes se apresentarem. Após um membro da platéia se definir programador, surgiu a piadinha "Temos um inimigo na trincheira."

Essas duas situações me fizeram refletir um pouco sobre algumas práticas ágeis e como elas são importantes para o sucesso do sistema. Uma delas, definida como Cliente Presente (do original em inglês On-site Costumer) e preza que todos os colaboradores de um projeto devem sentar juntos, formando um time. Com isso, absolutamente todos são contribuintes em uma equipe ágil. Vale para equipe técnica e para clientes. Principalmente para o segundo grupo, essa atuação vale em qualquer ponto onde a possam exercer, como na definição de prioridades e/ou criação de testes. Assim, acaba acontecendo que cada um dos papéis possíveis não seja necessariamente propriedade exclusiva de um indivíduo.

Aqui no ELSA, essa prática é bastante real e fácil de ser observada. Temos uma equipe epidemiológica perto e sempre presente nas definições, análises e testes, facilitando muito o trabalho da equipe de desenvolvimento. Sendo a estrutura organizacional do projeto construída sobre um modelo de colegiado, possuir pessoas capacitadas a garantir o papel de Product Owner geograficamente vizinhas às atividades de análise, programação e testes é fundamental. No caso específico dos releases, seus testes de aceitação, complementares aos testes feitos pela equipe durante o desenvolvimento, nos garantem o sucesso das novas versões do sistema que são visíveis aos outros centros do estudo.

É bom saber que aqui estamos mais de acordo com o paraninfo. Se todos os membros da equipe querem o sucesso do mesmo software, a quem serve criar inimizades no grupo?