Building Minds - o Blog da OnCast

No segundo grau todos aprendemos sobre o conceito de “entropia” na física e química. Entropia neste contexto está associada com a capacidade de um sistema mudar espontaneamente de estado. Quanto menor a entropia de um sistema, mais chance o mesmo tem de mudar; quanto maior a entropia, menos chances de mudar, ou seja, o sistema é mais estável.

Um fato importante sobre a entropia é que, em um sistema isolado, ela nunca decresce. Isso significa que o sistema sempre tende para o estado mais estável. Para exemplificar, considere uma mistura de água e açúcar: o açúcar tende a se dissolver na água (uma mudança espontânea), mas o contrario é improvável de acontecer, pois a entropia do sistema já dissolvido é maior do que a entropia inicial.

Mas o que isso tudo tem a ver com desenvolvimento de software? Encarando o software desenvolvido como um sistema físico, a conclusão lógica é que, se não houver um gasto de energia para manter a entropia baixa, o sistema tende à estagnação. Quanto maior a entropia do software, mais difícil ter mudanças no mesmo.

Aproximando a idéia de entropia para a metodologia Scrum, podemos fazer uma associação com as máquinas de movimento perpétuo. A idéia da máquina é que ela gere uma quantidade de energia igual ou maior do que a energia necessária para a mesma funcionar, formando assim um ciclo de retroalimentação infinito. Ora, como a entropia de um sistema isolado sempre cresce, uma máquina com este funcionamento é teoricamente impossível. E é por isso que no ciclo do Scrum existe o conceito de melhoria continua.

A melhoria continua representa uma injeção externa de energia que torna possível a existência de um processo como o Scrum. Essa energia é necessária para que a equipe de desenvolvimento consiga se adaptar e abraçar as mudanças (quem trabalha com desenvolvimento sabe que essas mudanças acontecem mais do que muitos desejariam).

Para deixar claro, imagine uma equipe X já estabelecida (com conhecimento no domínio e na tecnologia) que quer aumentar a velocidade de desenvolvimento. A velocidade sempre tende a se estabilizar; as pessoas não vão programar mais rápido por que um cliente pediu, ou por que um gerente fez uma ameaça. Se a velocidade mudou, alguma outra variável mudou no sistema. O exemplo mais óbvio é a perda de qualidade do código: testes deixam de ser escritos, a comunicação com o cliente é prejudicada (desenvolvedores fazem mais suposições sobre o domínio do que deveriam). Outras possibilidades são a mudança da tecnologia usada (frameworks, ou mesmo a linguagem), melhoria no conhecimento dos desenvolvedores, ou mudanças relacionadas ao processo de desenvolvimento.

As mudanças no processo são o que fazem o Scrum funcionar para equipes tão heterogêneas (e que geram reclamações relacionadas às certificações). O Scrum deve ser modificado para se adaptar as equipes, e não só no início de um projeto, mas durante cada iteração. O projeto deve servir como um laboratório: quando a equipe se sentir confiante, mudanças no processo devem ser inseridas (de preferência uma de cada vez) para gerar oscilações na entropia. Como os sprints no Scrum são relativamente pequenos, se a mudança for negativa ela pode ser rapidamente revertida. Se a mudança for positiva, ótimo! Em ambos os casos, a mudança serviu como experiência para a equipe, e ela agora tem mais conhecimento sobre o processo e sobre as suas próprias limitações. No pior dos casos, a mudança serve para que os membros da equipe não fiquem acomodados.

Para identificar possíveis mudanças pode-se usar as retrospectivas, identificando pontos fracos a serem remediados e também os pontos fortes a serem reforçados. Retrospectivas, porém, são um assunto para outro post.

Renato Besen Auto-gestão, Metáforas

Muitas vezes temos a necessidade de executar um mesmo teste repetidas vezes mudando apenas alguns parâmetros. A solução mais simples caso sejam poucos testes é replicar o método de testes e mudar as variáveis, ou então criar um método com as asserções desejadas e chamá-lo com os diferentes parâmetros.

Ambas as possibilidades apresentadas pecam, pois não respeitam o princípio DRY. Uma solução muito mais elegante é usar os testes parametrizados, uma possibilidade que para quem usa JUnit existe a partir da versão 4.

O funcionamento é simples: um método no teste, anotado com Parameters, deve retornar uma coleção de arrays, que serão os parâmetros de execução:

@Parameters
public static Collection<Object[]> parameters() {
    List<Object[]> list = new ArrayList<Object[]>();
    list.add(new Object[] {"asshole!", "jerk!"});
    list.add(new Object[] {"what the hell?", "what the heck?"});
    return list;
}

Cada array desta coleção fornecerá os argumentos para o construtor do teste, possibilitando assim que estes valores sejam salvos em campos da classe, e utilizados por quem precisar dos mesmos:

public ProfanityFilterTest(String input, String output) {
    this.input = input;
    this.output = output;
    filter = new ProfanityFilter();
}

A classe de testes deve ser configurada para rodar com um runner específico, o Parameterized:

@RunWith(Parameterized.class)
public class ProfanityFilterTest {
[...]

Com estes passos básicos, ao rodar a classe testes, cada teste será chamado uma vez com os parâmetros fornecidos.

Para conferir o código completo baixe ProfanityFilter.java e ProfanityFilterTest.java.

Renato Besen Arquitetura de Software, Auto-gestão

Um pouco de psicologia no desenvolvimento ágil de software:

A motivação do grupo é fundamental no desenvolvimento ágil, se cada membro da equipe não revisar seu estado de ânimo a cada dia e a cada iteração acaba ocorrendo um fenômeno psicológico em que forças antagônicas ao trabalho em equipe surgem na psiquê da pessoa (um pequeno ódio do trabalho). A psicologia realmente é fundamental em qualquer ambiente de trabalho pois lidamos com pessoas que pensam vivem e possuem emoções. Concordo em aumentar o enfoque desta parte humana na comunidade ágil pois no processo de migração de metodologias “legadas” acabamos nos preocupando muito somente com o processo e deixando um pouco de lado a parte humana.

Os nutricionistas dizem: “Somos o que comemos” e nós como engenheiros de software dizemos: “Também somos o que pensamos” pois nos alimentamos emocionalmente dos nossos pensamentos. Nossas criações dependem muito da capacidade de raciocínio.

Intuitivamente nosso amigo Paulo Ragonha sugeriu uma nova forma de dash board, a idéia surgiu no início da iteração e apresentou resultados satisfatórios. Em alguns momentos filosóficos no puf chegamos a conclusão de que o novo dash board é uma abstração simplificada de como nosso cérebro funciona. O Cérebro possui uma gigantesca memória, e as informações comumente utilizadas ficam mais próximas do “mecanismo” de raciocínio, no caso do nosso Brain Dash Board (batizado pela equipe) as estórias e tarefas que estamos trabalhando no momento ficam distribuídas no centro (onde existe maior concentração de foco visual da equipe) enquanto as estórias e tarefas não utilizadas ficam na região periférica. Concluímos que existe uma forte tendência do ser humano em replicar fora o que leva dentro e ótimas idéias surgem quando a mente está organizada, como fazemos com o backlog no nosso dash board.

Layout de Dash Board que se parece com o cérebro humano.

admin Auto-gestão, Metáforas

O resultado do trabalho de uma equipe tem relação direta com o comportamento e as atitudes de cada membro do time durante o desenvolvimento do projeto. Com o objetivo de conquistar mais maturidade após cada iteração, melhorando continuamente os processos de estimativa e a qualidade das entregas, é preciso estar inserido em um ambiente colaborativo, flexível e principalmente auto-organizado, que consiga despertar a pró-atividade e responsabilidade dentro da equipe.

Se auto-gerenciar sem dúvida é um grande desafio. Desde que nascemos, nos acostumamos com relações de comando e controle com nossos pais e professores, não assumindo na maior parte do tempo grandes responsabilidades. Com o tempo e a entrada no mercado de trabalho, o medo de errar acaba sendo um incentivador para permanecer nessa zona de conforto, confiando a outras pessoas o gerenciamento de nossas ações e responsabilidade pelos nossos resultados. É preciso ter coragem e força de vontade para superar o medo e vencer o desafio de se expor, assumindo os riscos de um comportamento pró-ativo e inovador.

Mas antes de tentar modificar o comportamento das pessoas, é preciso tratar os vícios de arquiteturas organizacionais verticalizadas, burocráticas e sem foco no cliente. Pensando em liderança servidora, a adoção de um modelo de gestão mais flexível e colaborativo é fundamental. Ao estimular a participação do time, substituindo a figura do gerente pela de um líder, a preocupação deixa de ser em determinar como, quando e em que ordem pré-determinada cada pessoa deve agir dentro do processo produtivo e passa a ser em como traçar objetivos claros, remover bloqueios e cuidar para que interferências externas não prejudiquem o trabalho da equipe.

A utilização de especificações detalhadas cria uma relação de dependência da área de negócio, diminuindo a comunicação e colaboração dentro do time de desenvolvimento. Combinado com a imposição de estimativas, propicia um ambiente altamente robotizado, insustentável e com alto índice de rotatividade em decorrência da falta de motivação.

Ter um objetivo é fundamental para motivar as pessoas a pensarem. Fazer com que o produto evolua com mais qualidade exige que a comunicação seja intensificada envolvendo o cliente no processo de desenvolvimento, dando a ele a oportunidade de confrontar suas idéias, raciocinando sobre como cada funcionalidade se encaixa dentro do produto e se realmente ela é importante para gerar o valor necessário ao seu negócio e aumentando seu grau de satisfação.

Criar ambientes multidisciplinares ajuda a reduzir os silos, convergindo todo o potencial produtivo de pessoas de diferentes áreas de conhecimento de forma sincronizada e assertiva. A mistura de uma arquitetura organizacional servidora e focada nas expectativas do cliente com uma equipe multidisciplinar guiada por objetivos claros, auto-organizada e sincronizada propicia um ambiente ideal.

Como resultados e benefícios temos:

• Melhoria da comunicação interna e agilidade na tomada de decisão.
• Foco dos gestores na estratégia da empresa deixando as decisões importantes dos projetos para as equipes.
• Aumento da satisfação dos funcionários em um ambiente melhor para se trabalhar.
• Surgimento de líderes fazendo com que a empresa possa assumir novos projetos.
• Qualidade e confiabilidade nas entregas aumentando o grau de satisfação do cliente.
• Aumento da participação no mercado e da lucratividade da empresa.

Rodrigo Branas Auto-gestão

Durante décadas, se não séculos, os administradores e gestores em geral sempre tiveram uma certeza: Para ter resultados você tem que motivar sua equipe, bonificando-os quando alcançam os resultados.

Parece bastante coerente este pensamento, e realmente é. Não reconhecer o comprometimento de sua equipe e os grandes resultados por eles alcançados não é só pouco humano como também uma grande falha de um líder. A recompensa é algo importante.

Agora vem o porém: lembre-se, recompensa não é pressão! Esse é o ponto em que o mercado hoje falha em perceber, e falha feio. Pressão em ambientes inovadores pode destruir toda a possibilidade de criativadade. Se você considera sua equipe inteligente e se o trabalho de sua equipe exige um mínimo de esforço intelectual, pressão (ou motivação que gere pressão) vai invariavelmente levar sua equipe a um desempenho menor. Você vai ficar frustado.

O vídeo abaixo mostra exatamente este fato, com número e exemplos. Ele explica a diferença entre motivação interna e motivação externa. Mostra a diferença de uma equipe comprometida com um problema que precisa de solução, e não comprometida com alcançar um bônus ou evitar de ser punido. Vale a pena ver.

Esse vídeo foi enviado pelo Jaime Schettini para nossa lista interna de discussão. Obrigado Jaime pelo vídeo!

Rodrigo Machado Auto-gestão

Eu vi uma discussão interessante sobre priorização x estimativas x risco em uma lista da OnCast hoje. Gostei bastante do aprendizado e resolvi transcrever algumas coisas aqui.

Podemos ter diversas formas de priorizar nosso backlog, em geral analisamos o custo de desenvolvimento, o valor gerado para o cliente e o risco inserido numa estória. Sendo assim, considerando apenas valor gerado e risco, temos o seguinte:

- Primeiro desenvolve-se o que gera maior valor e tem maior risco para o cliente;
- Depois desenvolve-se o que gera maior valor e tem menor risco para o cliente;
- Em terceiro desenvolve-se o que gera menor valor e tem menor risco para o cliente;
- E, aquilo que tem maior risco e menor valor procuramos não executar.

Se a estimativa para uma dada estória/tema é de 13sp, parece bastante razoável e adequada em termos de estimativa para um trabalho que leva aproximadamente uma semana de esforço. Agora, se apenas 3 é a estimativa e uma semana é o tempo de esforço, indica que o risco pode ter sido subestimado. Neste último caso, me parece que um pouco mais de aprendizado sobre o que precisa ser feito, vai melhorar as estimativas e auxiliar a identificar melhor o risco.

Em geral, não alteramos nossas estimativas iniciais durante a iteração. Usamos esta informação para melhorar as estimativas da próxima iteração e, ao longo de iterações subsequentes, a velocidade vai equalizar-se e as estimativas passam a se tornar “quase certeiras”.

Uma estória, idealmente, é feita pelo time todo ao mesmo tempo (cada membro pega uma tarefa da estória mais prioritária no momento), e neste contexto o tamanho de estória ideal para proporcionar um boa granularidade e uma boa visibilidade no seu burndown chart é de 3 a 5 story points. Estórias pequenas não deveriam ter mais story points do que isto e deveriam levar em média 2 dias para serem implementadas, lembrem-se - pelo time todo. Então esta dica mostra que uma estória com maior risco, digamos 13 story ponits, projeta um período de aproximadamente 1 semana para ser implementada, o que me leva a crer que as estimativas do time estavam bem assertivas, considerando os 13 story points estimados na discussão que observei.

Dado que estamos usando a escala Fibonacci, utilizamos os gaps que existem entre estimativas maiores para acomodar a incerteza do risco. Então, se não tenho muita idéia do que pode vir a ser o meu risco, utilizo estimativas maiores e os gaps da Fibonacci vão me ajudar a equalizar minhas estimativas, mesmo em estórias com risco - num futuro próximo.

Samuel Crescêncio Auto-gestão, Riscos

A queda da produtividade do time pode ter suas origens em fatores motivacionais. Percebê-los a tempo é fundamental para que medidas corretivas possam ser tomadas a tempo de restabelecer o foco do time, eliminar o desperdício e reduzir o risco de não conseguir entregar o que foi combinado com o cliente no final da iteração.

Vários fatores podem causar a desmotivação de uma parte ou até de todo o time durante uma iteração. Estórias sem um objetivo claro, atividades decompostas de forma inadequada, complexidade e impedimentos constantes são fatores que podem ser resolvidos pelo próprio time antes e durante o processo de desenvolvimento, evitando a queda de produtividade e de motivação.

Uma estória sem um objetivo claro, pode levar o time por caminhos incertos, causando retrabalho, ao invés de convergir toda a sua força produtiva para contribuir com o aumento do progresso da iteração. As reuniões de planejando têm seu papel fundamental na extração do máximo de informações acerca do escopo de cada estória, tornando o processo de desenvolvimento objetivo e reduzindo a possibilidade de estimativas equivocadas.

Mesmo em uma estória onde não existem duvidas em relação ao que deve ser feito, a forma como a decomposição das atividades é feita serve para guiar o time em meio ao escopo definido, antecipando possíveis impedimentos que podem ocorrer. Além de contribuir positivamente com o foco no que deve ser desenvolvido, é possível mensurar o progresso da estória de uma forma mais precisa, prevendo os atrasos e adiantando as medidas corretivas que podem ser executadas para mitigá-los e garantir a entrega no final da iteração.

Impedimentos podem impactar fortemente a produtividade do time durante uma iteração. Após decompor as estórias é possível, salvo nas primeiras iterações, identificar atividades criticas que possam impedir o desenvolvimento da estória. Antecipar esses impactos é fundamental. Paralelizar a resolução dos impedimentos das estórias seguintes com o desenvolvimento das estórias atuais abre caminho para o processo produtivo seguir livremente, com menos interrupções.

Manter um canal de comunicação sempre aberto, ajuda a diminuir o risco de deixar que problemas se agravem e comprometam a entrega do time no final da iteração. Quando todos se envolvem e passam a agir como uma equipe comprometida, as barreiras técnicas são superadas, os impedimentos são resolvidos mais facilmente e os bons resultados vêm naturalmente.

Rodrigo Branas Auto-gestão, Comunicação