Existe uma tribo nativa brasileira que desafia as teorias linguísticas de Chomsky. Existia a suposição de que esses nativos contavam apenas 1, 2 e muitos (para representar a quantidade a partir de 3), suspeita-se agora de que as palavras que representavam o número “um” é uma variação entre 1 e 4 (quem sabe o 3 como a primeira tese), a palavra que supostamente representava o “dois” outra variação até cerca de 10 e o “muitos” para algo realmente grande.

De qualquer forma, observe que o 3 é um limitante de grandeza intermediária entre o suposto “um” e “muitos” dos nativos.

Em recente estudo, o professor Michael Siegal investigou que bebês de até 18 meses compreendem a contagem até 3 e que conseguem compreender grandeza.

Não lembro se foram os criadores do Digg ou da 37 Signals que apresentaram há um tempo [não achei os slides no meu delicious] que se baseiam em 3 funcionalidades para trabalhar um produto mínimo, isso até ficou muito popular no meio dos criadores de Startup.

Desde a regra de três para reconhecimento de um padrão à 3 A (Arrange-Act-Assert) que esse número parece limitar uma espécie de contagem natural segundo as próprias teorias de Chomsky nas quais a capacidade de contar é inata do ser humano.

De qualquer forma já há algum tempo esse número me persegue nas minhas suposições, meio a esses fatos que podem não ter relação alguma e serem apenas coincidências eu trabalhei em um projeto o experimento de limitar a 3 o tamanho de uma funcionalidade.

Misturando esses fatos à abordagem da Pivotal Labs de limitar o tamanho máximo a 8 pontos popularizado no Pivotal Tracker.

Segundo a Pivotal, a partir de 8 pontos tudo é um grande chute e as pessoas já não fazem idéia do que é necessário para realizar determinada feature ou tarefa. Com base na minha suposição eu acredito que esse número deve cair a 3, justamente por entender que esse é o limitante da contagem natural e portando qualquer tarefa que ultrapassar tem que ser dividida.

Ainda não tenho dados sólidos para apresentar, é apenas um esboço de suposição, meu experimento não gerou números confiáveis. Vou tentar ter 3 experiências.

Posted in Metodologia, Métodos Ágeis ~ 3 Comments

Depois de um pareamento eu sempre tive o sentimento de esgotamento, verdadeira exaustão, aliado com uma sensação de dever cumprido. Mesmo cansado eu me sentia bem, mas não entendia o porquê.

Tom Rath e Jim Harter, pesquisadores do Gallup, chegaram a uma conclusão depois de tabular pesquisas para o livro “Wellbeing: The Five Essential Elements” ["Bem-estar: os cincos elementos essenciais", numa tradução livre] que em todas as situações pesquisadas as pessoas precisavam de pelo menos 6 horas por dia de socialização para se sentirem realizadas (bem), para cada hora de acréscimo seu humor fica melhor e para cada hora de decréscimo ele piora. A partir de 6 horas já não fazia diferença alguma, além de alguns pontos a mais como: socializar com mais de 3 pessoas diariamente  diminui o índice de bom humor e é o dobro do tempo que os especialistas em comportamento consideravam necessário.

Na nossa área existe uma teoria de que, por sermos Nerds, nós não nos socializamos. Pelo contrário, sessões de RPG por exemplo são mais intensivas do que horas de baladas e curtição na praia, são somente formas diferentes. O livro não indica a forma de socialização, nem se pode ser virtual (via Social Networks) ou face-a-face, apesar de que gerações diferentes tem suas preferências (óbvio).

Pois bem, nossas sessões de Pair Programming são em média por volta de 6h, temos garantido (segundo a psicologia) nosso grau de socialização diária para nos sentirmos bem. Outro benefício do PP que a psicologia agora nos dá uma explicação.

Jesus já recomendava:

E depois disto designou o Senhor ainda outros setenta, e mandou-os adiante da sua face, de dois em dois, a todas as cidades e lugares aonde ele havia de ir. Lucas 10:1

Posted in Melhores práticas, Metodologia, Métodos Ágeis, XP ~ 3 Comments

Após o post que escrevi sobre erros comuns ainda hoje de modelagem feitos principalmente na comunidade Java - mas não limitados a essa comunidade,  choveram de dúvidas de clientes e desenvolvedores próximos sobre quais as melhores práticas e como desenvolvemos.

Apesar de um tema com bastante bibliografia, muito material na internet e já uma certa maturidade no mercado nós notamos que ainda há um fosso enorme entre a realidade dos projetos atuais e a aplicação dessa teoria, principalmente um treinamento com um sentido mais prático.

Ainda não há uma base consistente e sólida de treinamentos e materiais sobre experiências reais e projetos que deram ou não certo.

Frente a isso nós formatamos um Workshop para responder todas essas indagações com um treinamento voltado ao “como fazer”, direto ao ponto, demonstrando a teoria “by the book” em um projeto de verdade com todas as situações que nos fazem relegar boas práticas e tornam o desenvolvimento tão caro e muitas vezes ineficaz.

Juntei o material de cursos passados, demos uma repaginada com a experiência dos últimos anos, o que funcionou e principalmente não funcionou para responder a todas as perguntas possíveis em um espaço relativamente curto de tempo, mas precisamente focado.

Se tiver interesse de participar, vá lá e se inscreva, faremos de tudo para deixá-lo apto a entender todo o ciclo de desenvolvimento moderno. Um curso para todos os níveis. Uma imersão no Ágil.

Posted in Behaviour Driven Development, Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Test Driven, XP, xpce ~ No Comments