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

Olá.

Aproveitando o espírito natalino de fé e o final de ano que se aproxima, segue abaixo umas frases que estão no Guide Scrum.

Sei que muitos de vocês são verdadeiras feras mas sempre é bom lembrar de coisas legais em nossa profissão e que reforçam os valores que precisamos manter todos os dias.

Um forte abraço do Marcucci e um ótimo final de ano a todos!

O SCRUMMASTER

O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras.

O ScrumMaster ajuda o Time Scrum e a organização a adotarem o Scrum.

O ScrumMaster educa o Time Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver projetos e produtos de maior qualidade.

O ScrumMaster ajuda o Time Scrum a entender e usar o autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não gerencia o Time Scrum; o Time Scrum é auto-organizável.

O time se auto-organiza para se encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint, tanto durante a Reunião de Planejamento da Sprint quanto no próprio momento da execução.

O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o ScrumMaster responsável.

PILARES

1) TRANSPARÊNCIA

A transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos não apenas devem ser transparentes, mas também o que está sendo visto deve ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada.

2) INSPEÇÃO

Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas. A frequência da inspeção deve levar em consideração que qualquer processo é modificado pelo próprio ato da inspeção. O problema acontece quando a frequência de inspeção necessária excede a tolerância do processo à inspeção.

Os outros fatores são a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho.

3) ADAPTAÇÃO

Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado.

Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

Existem três pontos para inspeção e adaptação em Scrum.

3.1 A Reunião Diária é utilizada para inspecionar o progresso em direção à Meta da Sprint e para realizar adaptações que otimizem o valor do próximo dia de trabalho.

3.2 A Revisão da Sprint e de Planejamento são utilizadas para inspecionar o progresso em direção à Meta da Versão para Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint.

3.3  A Retrospectiva da Sprint é utilizada para revisar a Sprint passada e definir que adaptações tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.

A finalidade da Retrospectiva é inspecionar como ocorreu a última Sprint em se tratando de pessoas, das relações entre elas, dos processos e das ferramentas.

A inspeção deve identificar e priorizar os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a composição do time, preparativos para reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para transformar itens do Backlog do Produto em alguma coisa “pronta”.

No final da Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis que ele implementará na próxima Sprint. Essas mudanças se tornam a adaptação para a inspeção empírica.

SOBRE O TIME SCRUM

Se o time sentir que se comprometeu com mais do que podia, ele se encontra com o Product Owner para remover ou reduzir o escopo do Backlog do Produto selecionado para a Sprint.

Se o time sentir que sobrará tempo, ele pode trabalhar junto ao Product Owner para selecionar mais do Backlog do Produto.

Quando um Time começa com o Scrum, Sprints de duas semanas o permite aprender sem se afundar na incerteza. Sprints desse tamanho podem ser sincronizadas com outros Times adicionando-se dois incrementos juntos.

admin Metáforas

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

Defino Débito Técnico como a distância entre o estado de um artefato técnico e como ele o seria em seu estado da arte. No ramo de desenvolvimento de software, é a medida de quanto uma deficiência técnica compromete o futuro do projeto e pode ser utilizado para antecipar problemas como bugs, baixa produtivadade, dificuldades com manutenção e dificuldades com transferência de tecnologia. Sua unidade é o spag (Sg), ou spaghetti :).

O termo foi cunhado em 1992 por Ward Cunningham, mas até hoje não há consenso de seu significado. Steve McConnell divide Débito Técnico em duas categorias: Intencional e Não Intencional (leia seu artigo). Uncle Bob em seu artigo “A Mess is not a Technical Debt” fala que um débito técnico não intencional (negligente) não deve ser considerado débito técnico. Martin Fowler subdivide débito técnico de duas maneiras: Prudente/Imprudente e Intencional/Inconsciente, gerando os quadrantes de débito técnico.

Minha classificação é algo como a de Steve. É muito útil determinar a existência de um Débito Técnico apenas avaliando o software em si, sem considerar as condições em que foi inserido. A separação entre intencional e não intencional não pode ser determinada apenas analisando o artefato. Um código mediano não é inapropriado se houve estratégia e todos estão conscientes das consequências da sua inserção.

Logo, a todo código ruim ou mediano dou o nome de Débito Técnico, a todo código que compromete o produto ou o futuro do projeto. É uma métrica direta da qualidade do software. Utilizo a subdivisão Intencional/Inconsciente para identificar se houve/não houve justificativas estratégicas para tal débito. As classificações Prudente/Imprudente dadas por Martin, credito mais à equipe, e não ao débito técnico em si.

Vamos descorrer um pouco mais sobre a distinção entre Débito Técnico Intencional e Débito Técnico Inconsciente.

Débito Técnico Intencional

Fazer o refactoring para abrigar a nova funcionalidade nos custará 5 dias, utilizar a arquitetura atual, mesmo que entortando alguns conceitos, nos custará 1 dia. Nossa entrega é no meio desta semana e a multa por atraso é indecente.

Qualquer gestor responsável diria:

1 dia! Faremos simplista agora! Agendamos um refactoring na próxima release, mesmo que nos custe 10 dias depois.

Existem momentos na vida de um projeto que atingir os deadlines é mais importante que a qualidade. O mundo está cheio de desafios: concorrência acirrada, time-to-market, pressões externas e internas… Não observar estes desafios é a pior das negligências de um projeto. De nada adianta um projeto que não atinge seus objetivos. Conhecer os prós e contras de suas estratégias é primordial para fazer a escolha correta.

Em uma boa equipe Scrum, o Product Owner tomaria esta decisão, principalmente porque conhece as necessidades do mercado. À equipe técnica (team) cabe o papel de levantar alternativas e alertar o Product Owner sobre os prós e contras de cada uma. O balanço entre qualidade e metas é o resultado esperado, bem como um agendamento de refactorings para amortizar o eventual débito técnico resultante.

Débito Técnico Inconsciente

Este débito técnico pode ser incorrido por algumas razões:

• Uma equipe técnica iniciante falha ao enxergar uma solução que não comprometa o futuro do projeto.
• O Product Owner é negligente ao considerar os riscos de suas ações, não considera os argumentos da equipe técnica e falha ao avaliar as necessidades de médio e longo prazo de seu projeto.
• O imponderável, algo que não pode ser antecipado nem por uma equipe sênior. Isto é comum a trabalhos de pesquisa e desenvolvimento de cunho científico.

De maneira geral, acredito que nem todo Débito Técnico não intencional seja negligente. Como visto acima, existem casos em que a complexidade do trabalho irá impor que débito técnico seja naturalmente inserido e permaneça desconhecido por algum tempo. Isto não configura negligência. Entretanto, ignorar o fato de que débitos técnicos serão inseridos é negligência. Cabe à equipe toda monitorá-los e corrigi-los a medida que sejam identificados.

Rodrigo Machado Metáforas, Riscos

Uma experiência interessante: Pegue uma pulga, a coloque em um pote e o tampe. O que você vai observar é que durante um tempo esta pulga ficará pulando e batendo contra a tampa na esperança de fugir. Passado algum tempo a pulga se condicionará a não pular tão alto já que pular alto não está se provando eficiente (a menos que o objetivo seja ter uma dor de cabeça).

O que acabou de acontecer com a pulga é o estabelecimento de um paradigma, um conjunto de regras que levam a uma conclusão, no caso “Pular alto não me levará a lugar algum”.

Abra a tampa e o que acontece? Ao contrário do esperado a pulga não vai fugir. O condicionamento impõe à pulga que ela não pule alto, o paradigma em que ela vive diz que pular alto não é uma boa prática.

Leia mais…

Rodrigo Machado Metáforas

Atualmente, muitas empresas estão adotando metodologias ágeis e em especial o Scrum com o objetivo de melhorar a gestão de seus projetos de software. No inicio, os projetos utilizam um workflow simplificado para sinalizar o andamento da iteração. Esse fluxo normalmente é composto por 3 estados:

• TO DO: Estórias selecionadas para o backlog da iteração que estão aguardando para serem iniciadas.
• IN PROGRESS: Estórias em andamento, sendo executadas pelo time no momento.
• DONE: Estórias prontas para serem entregues.

Segue abaixo um exemplo de um Scrum board com um fluxo simplificado:

Com o passar do tempo, surge a necessidade de amadurecer esse workflow, mapeando ações técnicas e de qualidade que reunidas formam o conceito de Definição de Pronto (ou Definition Of Done).

A Definição de Pronto reúne os critérios que o time deve seguir para que uma funcionalidade possa ser realmente considerada pronta, não só técnicamente mas também com qualidade. Essa definição é composta por uma lista de ações como: escrever testes de aceitação, codificar, revisar o código, validar o que foi feito com o product owner, fazer o deploy no servidor de produção ou qualquer outra coisa que precise ser feita para que a funcionalidade possa ser entregue atendendo as necessidades de negócio. Com a evolução do projeto, é importante estar sempre observando e adaptando esses critérios para que eles possam acompanhar a realidade projeto, estando alinhados com as expectativas do cliente.

Os problemas surgem quando algumas ou muitas dessas ações não são executadas corretamente e assim muitas estórias consideradas prontas pela equipe acabam tendo problemas na hora da revisão com o product owner, não sendo aceitas. Um fator que contribui para isso é a utilização de estados nebulosos no workflow do projeto. Decompor o estado “in progress” em estados que representem importantes ações da Definição de Pronto aumenta a visibilidade do time sobre qual etapa do processo está sendo executada e facilita a identificação e remoção de gargalos, aumentando a eficiência do processo.

Segue abaixo um exemplo de Scrum board com um workflow contendo os estados de codificação, revisão de código e deploy :

Para manter o fluxo constante, é importante evitar o acumulo excessivo de estórias em cada estado. Estes acumulos criam estoques que diminuem o ritmo e a freqüência de entregas, incentivando um comportamento multitarefa que contribui para um fluxo ineficiente e com desperdícios.

Segue abaixo um exemplo de Scrum board com acumulo de estórias em revisão de código causando a demora do deploy de varias estórias já codificadas:

O número de estórias em cada estado é denominado WIP (Work in Progress). Limitar o valor do WIP contribui para impedir a sobrecarga do sistema e faze-lo trabalhar com a sua capacidade real. Assim, as demandas começam a se adequar a capacidade de produção do sistema e não o contrário. Além disso, a ocorrência de impedimentos acaba causando uma interrupção no processo (ou stop the line), afetando o trabalho de toda a equipe e fazendo com que os impedimentos sejam resolvidos rapidamente.

Para entender melhor sobre a dinâmica da teoria das filas que a limitação do WIP proporciona é fundamental acessar uma simulação completa do funcionamento do kanban em: http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

Segue abaixo um exemplo de Scrum board com limite do WIP em 1 para o estado de codificação, em 1 para o de revisão de código e em 3 para o de deploy. Dessa forma, nunca poderá haver mais de uma estória em codificação, uma estória em revisão de código e três estórias em deploy, aumentando a colaboração da equipe e a utilização de técnicas como o pair programming. Lembrando que esses valores variam dependendo do objetivo e quantidade de pessoas na equipe. A alteração dessas variáveis pode ajustar o processo, afetando a produtividade do sistema.

Dessa forma é possível criar um workflow que prioriza a visibilidade do trabalho em execução, evidenciando impedimentos e gargalos, além de manter o sistema estável e constantemente otimizado. Com isso é possível entregar com mais freqüência e com mais qualidade, melhorando a percepção do cliente e criando um ambiente de desenvolvimento melhor para todos.

Segue abaixo alguns links para blogs importantes que falam sobre o assunto:

http://www.limitedwipsociety.org/

http://blog.crisp.se/henrikkniberg/

http://leansoftwareengineering.com/

http://www.alissonvale.com/englishblog/

http://damonpoole.blogspot.com/

Segue também uma lista de ferramentas e padrões utilizados no processo:

• Value Stream Mapping
• Visual Management
• Pull System & Single Piece Flow
• Limited WIP
• Buffers & Queue Limits
• Classes of Service
• Leveling Work
• Two tiered Systems (Expand/Collapse)
• Swimlanes/Expediting
• Triggers
• Priority Filters
• Perpetual Multivote

Rodrigo Branas Ferramentas, Metáforas

Há algum tempo atrás enviei para os colaboradores da OnCast o vídeo abaixo, e acredito que seja interessante compartilhar aqui no blog para quem ainda não viu.

The Downfall of Agile Hitler

Revendo o vídeo lembrei também de um post no Bliki do Martin Fowler, FlaccidScrum.

Acredito que a leitura desse post é importante para que possamos ter consciência de onde podemos falhar e como. O vídeo ilustrada de uma forma bem-humorada um tipo de problema, onde as equipes não dão a devida atenção a algumas práticas que garantem a qualidade do software, por exemplo técnicas do Extreme Programming.

Enfim além da diversão do vídeo vale a pena refletir sobre o assunto.

André Branco Metáforas

Outro dia, quando Caio e eu estivemos em um de nossos clientes, estávamos conversando com uma pessoa do setor de vendas e sentimos dificuldade em explicar-lhe como o desenvolvimento ágil pode ser bom no que diz respeito às mudanças. Ficamos neste embate até que me surgiu uma idéia, correndo o risco de me tornar o metafórico da OnCast, vou transcrever a estória que contei para ele:

Imagine que você nos contrate para fazer um garfo, pois fora convidado para um jantar e tinha que levar seu talher.

Depois de iniciado o processo de confecção do garfo você descobre que o cardápio do jantar vai ser sopa. Portanto o garfo não será de grande serventia, melhor seria usar uma colher.

Se estivesse dependendo do desenvolvimento tradicional, teria que esperar o garfo ficar pronto para que então fosse iniciado o processo de confecção da colher.

Se fosse através do desenvolvimento ágil, teríamos durante o processo de confecção do garfo uma mudança no sentido, e passaríamos a fazer não mais um garfo, porém uma colher.

É isso que temos com o desenvolvimento ágil, a facilidade em aceitar uma mudança no sentido do projeto. A perda com essa mudança é proporcional ao seu tamanho e também ao tamanho do projeto. Ou seja, se, no exemplo acima, ao invés de uma colher precisássemos mudar de um garfo para um Hachi (aqueles pauzinhos usados no oriente) teríamos muito mais dificuldade e possivelmente um aumento no número de iterações.

Essa resposta rápida às mudanças é um dos quatro valores do desenvolvimento ágil “Responder às mudanças sobre seguir um plano” e é também um dos princípios abordados no manifesto ágil “Até mesmo mudanças tardias de escopo no projeto são bem-vindas.”. Por ser um dos alicerces de nossa metodologia, temos que  acreditar, aceitar e, o mais complicado, fazer com que o cliente acredite nisso.

Marcelo Silva Metáforas, Riscos

Essa foi a pergunta que a Mirela, nossa Assessora de Marketing, fez ao Adriano e ao Samuel, dois dos três sócios da OnCast Technologies. Após receber várias respostas enumerando as qualidades do SCRUM/XP/Lean, me permitiram que falasse sobre uma delas. Expliquei que havia me identificado bastante com a característica do processo ágil que permite desenvolvimento de software sustentável, um dos princípios elencados no Manifesto Ágil.
Uma das maneiras de se atingir isso é com a criação de código simples, outro princípio discretizado no Manifesto Ágil. Com um código simples torna-se fácil a percepção de falhas precocemente, atacando cedo, aquele que poderia ser o câncer de todo o processo. Acabei criando o seguinte exemplo para explicar essa faculdade:

Imagine que um cliente nos peça que façamos uma casinha de Lego de determinada cor. Para isso nos entrega todas as peças necessárias sem notar que nos havia entregue uma peça de outra cor.

Caso executássemos essa tarefa utilizando o desenvolvimento tradicional, tirando toda burocracia envolvida, faríamos a casa e ao terminar, perceberíamos que na base da casa havia uma peça de cor errada. Isso implicaria em desconstruir toda a casa e, por sua vez, reconstruí-la, perdendo um tempo que o cliente provavelmente não possuía.

Caso estivéssemos usando o desenvolvimento ágil, teríamos notado a peça errada antes mesmo de terminar a casa, faríamos sua troca pela peça correta e continuaríamos nosso desenvolvimento sem essa perda tão considerável de tempo.

O que quis dizer com este exemplo é que um problema, dentro do desenvolvimento ágil, é atacado assim que é encontrado, desta forma é suplantado, minimizando o tempo gasto com isso.

Fazendo um gancho do exemplo do Lego com o desenvolvimento de softwares, podemos lembrar do Test-Driven Development (TDD) que é a abordagem que nos ajuda a encontrar a “peça” errada, antes desta “peça” influenciar nas outras “peças” que compõe o software.

Em suma, pode-se dizer que o desenvolvimento ágil tenta mitigar o efeito “bola de neve”, tornando mais simples e contínuo o processo criativo.

Marcelo Silva Ferramentas, Metáforas, Riscos