Building Minds - o Blog da OnCast

Sempre que chego em um ambiente de desenvolvimento muito quieto, esses onde todos ficam o dia todo com seus fones de ouvidos (nada contra os fones) sem trocar uma palavra, me dá uma sensação um pouco estranha, de que algo pode estar errado ali. O silêncio e o clima do ambiente de desenvolvimento acabam revelando muito sobre como uma empresa desenvolve seus softwares e valoriza seus funcionários.

O individualismo quase sempre leva a uma estrutura egoísta de trabalho, onde cada um se preocupa apenas com seus próprios problemas, sem se dar conta que estes pertencem a todos e sem fazer idéia do que está acontecendo com o restante do projeto. Desta forma o time não colabora, não busca os mesmos objetivos e acabam transformando o desenvolvimento de software em uma atividade monótona e desmotivante.

Em tempos de fábricas de software, as atividades nunca foram tão individualizadas. Muitas empresas ainda veêm uma equipe de desenvolvimento como um conjunto de recursos, substituíveis facilmente, prontos para seguirem os guidelines, padrões e normas que juntos ajudam a eliminar qualquer forma de inovação que poderia emergir.

A comunicação é a ferramenta fundamental para ter sucesso em qualquer projeto. Através dela é possível transformar complexidade em realidade, unir o time e fomentar a motivação.

Rodrigo Branas Comunicação

Esse refactoring é muito interessante quando feito sobre condicionais que lidam com parâmetros  que podem mudar com freqüência. Esses parâmetros podem ser tipos de relatórios, comandos utilizados para invocar métodos remotamente, estados de uma máquina entre outros.

O objetivo da utilização do polimorfismo é justamente dar flexibilidade e permitir que o sistema evolua (mude) sem precisar adicionar novos blocos de else if no código toda vez que um novo parâmetro for adicionado, alterado ou removido! Sendo assim, não precisa sair alterando todos os blocos if else do sistema, apenas os pontos mais suscetíveis a mudança e que a flexibilidade fará com que as operações de manutenção possam ser mais agradáveis.

Nosso foco são estruturas que dependem de parâmetros para executar ações como por exemplo gerar um extrato. Os extratos podem ser de vários tipos: Semanais, quinzenais, mensais, completos e tantos outros quanto os clientes necessitarem ao longo da vida útil do sistema.

Abaixo, a classe responsável por gerar um extrato utilizando um tipo passado como parâmetro:

Estruturas como essa além de serem procedurais, diminuem a performance do sistema e com o tempo aumentam os custos de manutenção do projeto, contribuindo para um código ilegível (imagine com 50 tipos de extrato) e desmotivante.

Uma forma interessante de resolver o problema é mapear os estados em uma enum e utilizá-la para mapear os estados polimorficamente:

E finalmente podemos refatorar o método condicional da classe que gera extratos para delegar a geração de extratos para as subclasses:

Lembrando que essa é uma forma simplificada da utilização do padrão Strategy, no entanto evitamos a criação excessiva de artefatos (cada estratégia numa subclassse) e utilizamos a enum para fazer esse trabalho.

Rodrigo Branas Arquitetura de Software

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

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

Com certeza um dos momentos mais interessantes do planejamento é a hora de estimar as estórias! As melhores estimativas surgem quando o escopo da estória é bem discutido entre os membros do time e cada um defende fortemente suas opiniões sobre como alcançar os objetivos.

Ferramentas como o Planning Poker são alternativas muito interessantes para prender a atenção do time e motivar todos a pensarem e participarem ativamente do processo de estimativa de cada estória em vez de aceitar passivamente o que os outros decidirem.

Em http://planningpoker.com/ é possível criar as estórias e adicionar os participantes!

Planning Poker Online!

O bom e mais ou menos velho baralho sempre terá seu valor, no entanto esse tipo de ferramente pode facilitar e simplificar ainda mais o processo, trazendo mais interatividade, estimulo e união para todo o time!

Rodrigo Branas Comunicação, Ferramentas

Não é raro observar em iterações onde o Sprint Planning 2 não foi feito, problemas como: estimativas parciais, daily meetings mais longas e menos objetivas, impedimentos descobertos tarde demais e falta de alinhamento do time em relação ao que deve ser feito em cada estória.

O Spring Planning 2 é o processo no qual toda a equipe junta percorre os itens do selected backlog, entende o que se espera de cada estória e pensa em questões como: Quais classes devem ser criadas? Quantas camadas do sistema serão impactadas? Impedimentos? Quais tabelas do banco de dados serão atualizadas? Que telas devem ser criadas? Quantos testes unitários devem ser feitos? Qual é o critério de aceite? …

Após esse processo, os cartões de atividades serão criados e o time todo estará mais alinhado com o que deverá ser feito para atingir o objetivo em cada estória.

Lembra aquela estimativa que foi feita no Sprint Planning 1? Após todo esse processo, ela ainda continua válida? Muitas vezes ela precisa ser alterada e isso é necessário para garantir que o time se comprometa com entregas que ele realmente tem a capacidade de fazer.

Durante as Daily Meetings, que devem ser de curta duração e se restringir a responder as perguntas objetivas: o que foi feito ontem? o que será feito amanha? existem impedimentos afetando o desenvolvimento da estória?

Não é incomum notar estórias decompostas de forma inadequada ou até atividades criadas “on the fly” (durante a própria Daily Meeting) e com isso dificultando as respostas básicas e objetivas para ter um processo ágil e transparente. Além disso, evita explicações acerca do escopo da atividade, já que todos sabem pois também fizeram parte do processo de definição de todas as atividades.

Falando em impedimentos, será que não é tarde demais para pensar neles? Imagine uma iteração de 3 semanas. O que acontece se na última semana, quando uma estória foi decomposta em atividades, “apareceu” um impedimento que já poderia estar sendo resolvido desde o início da iteração. Agora existe a possibilidade de não entregar mais a estória porque pode não existir mais tempo hábil para resolvê-lo. Quanto antes os impedimentos forem descobertos mais livre será o caminho para fechar a estória, com menos interrupções e mais motivação.

O que mesmo precisa ser feito nessa estória? Perguntas como essa sempre surgem no meio da iteração, afinal ninguem mais lembra da reunião com o Product Owner e detalhes importantes do escopo da estória acabam sendo esquecidos. Se as atividades tivessem sido criadas enquanto todo esse conhecimento ainda é recente na mente de cada integrante do time, questionamentos poderiam surgir e ajudar a entender melhor o objetivo de cada estória que deverá ser desenvolvida ao longo da iteração.

Rodrigo Branas Comunicaçã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

Um dos problemas mais críticos de um projeto é quando o cronograma foge do controle do time e as estimativas revelam-se erradas e sem maturidade. Isto demonstra que os processos utilizados para chegar a elas podem ter falhas. Frente a problemas como este, é importante ir fundo nas suas causas e planejar que tipo de melhorias podem ser feitas para tornar as próximas iterações bem sucedidas.

Nas primeiras iterações, é inevitável. De certa forma, é esperado que as estimativas não sejam realista por motivos como: desconhecimento do escopo, novas tecnologias e falta de entrosamento da equipe. Esses fatores reunidos, ocasionam a falta de estimativas confiáveis e o desconhecimento da velocidade real do time.

Com o passar do tempo, a fluência da equipe aumenta e é possível confiar mais no que está sendo estimado e  se comprometer com uma quantidade de trabalho, tendo a confiança de poder entregá-la com qualidade e dentro do prazo combinado.

Entretanto, é comum ver projetos já avançados com problemas no cronograma. Atrasados ou adiantados, ambos os casos são ruins. Demonstram que o processo de desenvolvimento tem problemas e que o time pode nao estar conseguindo mensurar corretamente o risco existente em cada estória.

Por isso, é importante recolher métricas, constantemente, para uma melhoria continua dos processos ligados a às estimativas. Depois de cada Daily Meeting, podemos avaliar de uma maneira simples e direta, seja marcando no próprio cartão ou em uma planilha, os resultado das estimativas. Caso elas tenham se cumprido, devem ser consideradas adequadas, caso contrário, baixas ou altas. Também é interessante ter algumas observações referentes aos motivos dos problemas, se for o caso.

Idealmente, a produtividade que foi acordada no inicio deve variar pouco, mostrando que o time é capaz de manter processos sustentáveis de desenvolvimento. Apesar de ser bom manter uma reserva gerencial, ou gordura, para se resguardar de quaisquer problemas que possam acontecer em durante a iteração, se este for um hábito constante, pode acabar ocasionando gráficos parciais e dados irreais, além de um processo opaco tanto para o time quanto para o cliente.

Analisando o gráfico, após uma iteração problemática, é possível notar os pontos que fizeram com que a iteração não fosse bem sucedida. As métricas das atividades fechadas nos dias em que a produtividade oscilou de forma acentuada devem ser analisadas com cuidado. É provavel que essas estimativas estejam marcadas como baixas ou altas, e com o objetivo de melhorar no futuro, podemos nos aprodundar nos motivos que causaram estes desvios.

Se as estimativas foram altas, medidas como planejar escopo extra ou antecipar estórias de alto risco podem ser interessantes para agregar mais valor à iteração e garantir uma entrega completa e com qualidade. É interessante justificar para o cliente que as superestimativas decorrerem de novas abordagens tecnológias ou de negócio do projeto, ou seja, frente a um risco que teve que ser considerado, com isso o time vai ganhar mais maturidade e com a lição aprendida vai saber lidar com situações parecidas em futuras iterações. Entretanto, caso não existirem motivos suficientemente justificados para elas, uma conscientização do time, acerca do problema e de como poderá afeta a imagem do time perante o cliente, deve ser feita.

Por outro lado se ocorrerem estimativas baixas, isso pode refletir um desconhecimento das técnologias envolvidas ou do negócio, comum no inicio do projeto, e isso vai trazer também maturidade para o time da mesma forma que aconteceu com as superestimativas. Caso as estórias sejam livres de débitos relacionados à novas técnologias ou escopo ainda não trabalhado, uma análise dos impedimentos que podem ter ocorrido durante o desenvolvimento é fundamental para identificar que ações corretivas que foram tomadas no momento em que os problemas aconteceram, e se ajudaram a evitar a queda de produtividade do time. No primeiro sinal de queda da produtividade por problemas de impedimentos é importante parar a atividade até que os impedimentos sejam resolvidos para evitar a desmotivação do e desperdicio do esforço do time, que poderia estar sendo convergido em estórias sem impedimentos.

Caso a desmotivação já tenha dominado o time, tomar medidas corretivas como pair programming ou move people around, podem ajudar a subir a moral do time e estabilizar o processo produtivo.

Com a obtenção e avaliação desse tipo de métrica, podemos entender melhor cada movimento que o gráfico realizou e como isso afetou a iteração e assim o time poderá se desenvolver de uma forma mais transparente,  madura e produtiva, com um alto grau de confiabilidade tanto nas estimativas, quanto na garantia da entrega do que foi assumido com o cliente, aumentando a confiança de ambos os lados e gerando novas oportunidades de negócio para a empresa.

Rodrigo Branas Comunicação, Riscos