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.
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
Marcadores:
agil,
cliente presente,
eh,
on-site costumer,
whole team,
xp
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?
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?
Assinar:
Postagens (Atom)