Sistema de Coleta Versão 1.0

A última implantação no servidor de produção de 2010 acabou sofrendo com final de semestre e festas de fim de ano e virou a primeira de 2011. Com ela, finalmente, a versão 1.0 do sistema de coleta de dados. Pensando que a primeira funcionalidade usada foi liberada em dezembro de 2008, essa distância de tempo é sucesso ou fracasso?

Do ponto de vista extremamente tradicional, poderia ser avaliado como fracasso, pois alguns centros do estudo já não estão coletando dados diretamente com os participantes. Contudo, a natureza incremental do desenvolvimento, associado a uma definição de prioridades pelo product owner, gerou diferentes implantações que foram agregando valor desde a primeira liberação.

O trabalho não acabou. A cadeia de produtos para estudos epidemiológicos que estamos criando sempre traz novidades para serem implementadas. No entanto, é bom saber que chegamos à totalidade dos formulários e funcionalidades de coleta. Que arredondamos o número da versão para 1.0. Porém, o melhor de tudo, é saber que os seis centros não estavam parados a espera da primeira versão do software. É comprovar na prática que o ROI já vinha sendo percebido a bem mais tempo.

Desenvolvimento ELSA no Agile Brazil 2010

Nos dias 24 e 25 de julho, Porto Alegre sediou o Agile Brazil 2010. É sempre muito interessante ter cabeças pensantes reunidas em um mesmo lugar para trocar experiências. Ainda mais com visitas ilustres como Martin Fowler, que fez o primeiro keynote do evento. Sendo em Porto Alegre, foi também uma ótima oportunidade de reencontrar alguns amigos que acabo vendo pouco.

A equipe do desenvolvimento estava presente quase que em sua totalidade. Números oficiais do evento informavam cerca de 800 inscritos, fazendo com que o ELSA representasse 1% de todo mundo. Na foto ao lado, metade do time em um pequeno registro feito pelo @flaviosteffens: Émerson, Nadjia, Daniel e Diego.

Passado algum tempo do evento, acho que o principal efeito que ficou na comunidade que participou das atividades foi a vontade de fazer. Todos com muitas ideias e empolgação. Acho que até por isso a expectativa de que o do próximo seja ainda melhor que esse, principalmente nas trilhas praticante/experiente.

Foco nas Pessoas

O Chaos Report do ano passado mostrou que apenas 32% dos projetos em TI são bem-sucedidos. Segundo a tabela comparativa (e aqui embaixo reproduzida em apenas uma linha) retirada de uma entrada do site Project Smart, houve um decréscimo em relação a 2006 (de 35% para 32%), mas uma melhora significativa em relação à década passada (de 16% para 32%).

As explicações são muitas. O post de onde essa tabela foi retirada aponta como uma das grandes vantagens o aumento de profissionais certificados. Esse argumento é base pra uma briga boa que encontra como principal confrontador o Uncle Bob. Ninguém tem dúvida que existe muita gente a favor das letrinhas mágicas (uma rápida olhada nos seus contatos do LinkedIn prova isso). Mas, será que são as certificações que fazem diferença?

O sucesso de nosso último release foi, para mim, baseado em dois aspectos. Primeiramente, diferente de algumas outras vezes a iteração foi bem-definida e executada. Adicionalmente, criamos o desafio de mudar algumas tecnologias para outras que já havíamos avaliado como melhores do que as que estavamos usando. Depois de muito tempo de "nessa iteração não temos tempo para migrar", definimos em conjunto pela mudança. Esse motivador surgiu da equipe. Resultado final: software entregue no prazo, com todas as funcionalidades e com melhora no processo de desenvolvimento, através de novas práticas e tecnologias. O que será que mudou? Ninguém foi certificado em nada de um release para o outro...

Para mim, a resposta para o sucesso está em uma das bases do Manifesto Ágil foi cumprida: "valorizar: 1. Indivíduos e interação entre eles mais que processos e ferramentas". A equipe tinha uma clara ideia do que deveria ser feito, sem pendências de requisitos. As funcionalidades foram entregues para teste em tempo hábil e está sendo colocado a campo para gerar feedback em situações reais. A comunicação entre essas duas "equipes" e o trabalho que elas devem executar para garantir um bom software foi valorizado acima de tempo ou prazo. Mesmo havendo troca de ferramenta, ela foi feita como desafio para os desenvolvedores, ou seja, foi encaminhada como motivador da curiosidade natural de quem trabalha com programação, ao invés de imposição de alguém. Ou seja, independente de como é feito, de qual tecnologia é usada, os sistemas sempre serão baseados em pessoas e elas são o verdadeiro kernel de qualquer projeto.

Acentos no século XXI

É incrível como alguns serviços ainda não conseguem trabalhar com acentos. Minha surpresa, hoje, foi descobrir que eu baguncei a vida do SVN para todos os arquivos que fiz upload. Assim, para você, que como eu, acabou colocando acento e tem de voltar atrás para trocar o seu nome na integração Eclipse + SVNKit a dica é a seguinte:

apague o arquivo .keyring que fica no diretório ECLIPSE_HOME/configuration/org.eclipse.core.runtime/

Outras alternativas como eclipse.exe -vmargs -Duser.name=”usuario” NÃO vão funcionar. Ele até troca o valor do @author, mas não atualiza a conexão com o servidor.

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?

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á?

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?