Você precisa de Agile?

Parece que de repente, “todo mundo” começou a buscar ser ágil.

A primeira vista isso pode até ser visto como bom, uma vez que vários métodos ágeis são bem mais sensatos do que os métodos tradicionais. Porém, infelizmente, muitos estão apenas indo na “onda do Agile”, e esses correm um alto risco de morrer na praia.

Por experiência própria, posso dizer que Agile não é pra qualquer empresa/equipe.

E dentre as várias coisas que aprendi (a duras penas), foi que nem sempre precisamos de Agile, ou melhor, nem sempre o que mais precisamos é Agile.

Para ilustrar esse aprendizado, vou utilizar o exemplo da famosa XPTO Solutions.

A XPTO Solutions também conheceu o Agile, por meio de materiais de terceiro é claro (uma dica: busque primeiro o conhecimento da fonte original). E após ver que os seus concorrentes já estavam utilizando métodos ágeis, decidiu adotar também. E como a maioria, começou com Scrum.

No começo tudo parecia uma maravilha, vários post-its coloridos na parede, o gráfico burn-down correndo bem, etc. Porém, após algumas sprints, percebeu-se que tinham finalizados várias funcionalidades, porém nada tinha ido para a produção, e nem o cliente tinha visto o software que estava sendo desenvolvido, pois estava distante, e o máximo de participação que ele tinha na sprint, era feita por e-mail ou telefone com o Scrum Master.

Outro problema que apareceu, foi que muitas tarefas eram retrabalhos e resoluções de bugs, pois eles não faziam testes unitários e 70% dos desenvolvedores ainda eram juniores, e não conheciam práticas como TDD e ainda não tinham uma base sólida na linguagem de programação que é usada na XPTO.

O problemas que aconteceram na XPTO não são incomuns. E se formos analisar muitos desses problemas não têm nenhuma relação com o Agile, e iriam acontecer independente da metodologia utilizada.

Problemas como equipe inexperiente, cliente distante, gestão de conhecimento ineficiente, falta de motivação, acomodação, etc são comuns em qualquer empresa. E a solução ou medidas que poderiam amenizar os seus efeitos não estão numa metodologia de desenvolvimento de software.

Por isso que eu enfatizo, que antes de implementar Agile, precisamos analisar o ambiente a nossa volta, assim como um agricultor verifica o terreno para saber o que pode plantar nele. Não adianta forçar ser Agile, o seu desenvolvedor não irá testar só porque agora é Agile, o seu cliente não irá participar mais e/ou aceitar o contrato de escopo negociável, só porque agora a sua empresa é Agile.

E é bom lembrar, que Agile não é um fim, e sim um meio para você construir software com mais eficiência e qualidade, ter uma equipe mais motivada e um cliente mais satisfeito.

É importante ter em mente, que Agile não é apenas uma questão de mudança de hábito, mas também cultural . Vários paradigmas precisam ser quebrados quando implementamos Agile, e alguns deles já foram quebrados por pessoas como o Ricardo Semler, muito antes do Manifesto Ágil surgir, como por exemplo: uma participação mais democrática da equipe no dia-a-dia e nas decisões da empresa e valorizar mais pessoas do que processo.

Podemos fazer uma implementação de Agile de forma mais harmoniosa e sensata, ao buscar saber o que realmente precisamos antes do Agile em sí, uma vez que muitos dos problemas que enfrentamos, não estão relacionados com a metodologia que está sendo usada. Lembre-se, que “para que a semente dê frutos, é necessário preparar a terra.”

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte imagens:

http://bit.ly/aevP0r

http://bit.ly/c2t8zd

http://bit.ly/a8Y15t

Scrum

Há muito tempo, estava querendo fazer um post sobre Scrum. Mas só agora realmente, tomei iniciativa em fazê-lo.

Falar sobre Scrum é algo fácil e ao mesmo tempo difícil. Fácil por ser algo simples, e é difícil, pois há muitas outras pessoas falando sobre ele, então a chance de fazer um “post papagaio” é grande. E quando falo de muitas outras pessoas falando sobre Scrum, não é apenas quantidade e sim muita qualidade. E isso é um ponto muito forte, que vejo do Scrum, ele é muito vivo! As pessoas pesquisam, discutem, “blogam”, etc sobre Scrum.

O intuito desse post é passar algumas opiniões que tenho sobre Scrum, e também “papagaiar” um pouco sobre ele, afinal para muitos ele é ainda apenas mais um buzzword. Espero que gostem, qualquer coisa só “cornetar”, ou melhor, comentar. 🙂

Mas afinal o que é Scrum?

Vou primeiro colocar a definição que entendo como a melhor, do Ken Schwaber, um dos criadores do Scrum, e depois colocar uma definição pessoal:

“Um processo Ágil ou ainda um framework para gerenciamento de projetos Ágeis. É um processo de gerência de projetos, certamente não é uma metodologia, pois isto seria pesado demais.” (Ken Schwaber)

Scrum são boas práticas para gerenciar projetos de forma a otimizar o ambiente de trabalho, motivar as pessoas e satisfazer as reais necessidades do cliente. (Fabrício Ferrari de Campos)

Mas por favor, não se apegue muito as definições, o importante é conhecer as práticas e conceitos que o Scrum traz e os benefícios que podemos ter aplicando-os na nossa empresa.

As características principais do Scrum são:

• Ágil;
• Empírico;
• Incremental;
• Iterativo.

Mas o que significa a sigla Scrum?

Que sigla?… Não, não. Scrum não é uma sigla, é o nome de um tipo de jogada que acontece no jogo de rugby para retornar a bola,  onde é necessário a participação de todos os jogadores. Se um falhar, todos falham. Por isso que você ver uma imagem parecida com essa abaixo, em vários posts sobre Scrum (e não poderia ser diferente nesse…rsrs).

Quem é quem no Scrum?

O Scrum organiza de forma diferente os papéis existentes num projeto:

• Scrum Master: Remove os impedimentos, garante o uso do Scrum e protege o time de interferências externas. Líder colaborador!
• Product Owner (PO): Preocupado com o ROI, se voltará dinheiro para o bolso do cliente, conhece as necessidades do cliente, funciona como proxy em ambientes com mais de um cliente. Gerencia a visão e a entrega!
• Time: Formado geralmente por 4 ou 5 pessoas e multidisciplinar. Ele define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.

Como é o processo do Scrum?

Só clicar na imagem para vê-la ampliada.

Como você pode ter percebido, o Scrum tem um processo bem definido e neste ponto ele é rígido, até pelo fato dele determina poucas coisas (tanto que consegui ilustrar num único desenho), mas o que determina você tem que seguir. Por isso, é rígido.

Vantagens e Desvantagens

Como é de praxe ao conhecer algo novo, sempre buscamos saber quais são as vantagens e desvantagens, portanto, segue abaixo as principais vantagens e desvantagens do Scrum:

• Vantagens
  • Os papéis são bem definidos, todos têm conhecimento sobre as suas responsabilidades;
  • É um processo ágil e flexível, tornando melhor a reação as mudanças que ocorrem durante o projeto;
  • É focado no controle e gerenciamento, buscando minimizar os riscos e maximizar a qualidade;
  • Os times são pequenos, a comunicação é mais eficiente;
  • Espírito colaborativo.
• Desvantagens
  • Ausência de práticas de Engenharia de Software, pois é voltada para o gerenciamento do projeto;
  • Necessita a associação de uma outra metodologia de Engenharia de Software, por exemplo XP;
  • É difícil de ser implementada, principalmente devido a resistência de mudanças culturais.

As duas primeiras desvantagens poderiam até ser desconsideradas, pois Scrum é voltado para a gerência de projetos e não para o desenvolvimento.

Scrum é mais uma modinha? Ou veio para ficar?

Acredito que a resposta depende muito da perspectiva que a pessoa tem, pois olhando de fora parece sim mais uma modinha, assim como ocorreu com o PMBOK. Sendo simplista a pessoa poderia até pensar que é apenas mais uma metodologia que tenta ser melhor do que as demais. Porém, para quem tem uma visão interna, que está realmente envolvido com o dia-a-dia do projeto, Scrum veio para ficar sim, ou melhor, os seus valores vieram para ficar.

Daí você pode está se perguntando, mas que valores são esses?

• Transparência;
• Ser empírico;
• Auto-organização;
• Integridade;
• Entrega de valor.

Além disso, o Scrum também tem como base os princípios ágeis do manifesto ágil:

• Indivíduos e iteração entre eles mais que processos e ferramentas.
• Produto em funcionamento mais que documentação abrangente.
• Colaboração com o cliente mais que negociação de contratos.
• Responder a mudanças mais que seguir um plano.

Nossa! Então Scrum é a famosa bala de prata!? Irá resolver todos os meus problemas?

Eu particularmente, sou bastante cético quando alguém fala que tal metodologia, framework, etc irá garantir o sucesso do seu projeto de desenvolvimento de software. Por isso, minha opinião é a mesma com Scrum.

Para mim ele é muito bom! Dentre os conhecimentos que temos sobre metodologias e afins na empresa em que trabalho, é o que melhor se encaixou a nossa realidade e o que trouxe mais melhorias.

Mas voltando a pergunta original do tópico, ele não irá resolver todos os seus problemas, pelo contrário, ele irá torná-los mais visíveis, e esse é um ponto que acho incrível. Pois se algo não estiver indo bem todos irão perceber bem rápido. Aliás uma das ferramentas que o Scrum traz  e que ajuda na visualização do andamento do projeto é o gráfico Burndown.

Qualquer pessoa, consegue identificar pelo gráfico acima, que a quantidade de testes automatizados esperada para o sprint 1 não foi alcançada. Eu poderia listar uma série de causas que fez com que o objetivo não fosse alcançado, afinal o gráfico apresenta um cenário real. Mas não é esse o intuito do post.

Portanto, precisamos nos lembrar que a metodologia em si não irá resolver os problemas, mas sim, poderá nos ajudar. Quem resolve os problemas são as pessoas!!!

Scrum é fácil de ser implantado?

Se fosse fácil qualquer um faria!

Há uma série de obstáculos que fazem com que a implantação do Scrum não seja uma missão fácil, entre eles:

• Não tem como você exigir que haja auto-gestão na sua equipe se ela não é uma característica dos membros da equipe;
• Implantar numa equipe grande demais (mais de 5 pessoas, por exemplo);
• O seu cliente não tem o menor interesse de cooperar. Ele é parecido com uma criança mimada que só quer e ainda bate o pé;
• O único comprometimento que os membros da sua equipe tem, é em relação ao salário deles.

Mas me diga uma coisa, alguém já disse para você que desenvolvimento de software é fácil?

É para todos os obstáculos apresentados há uma ou mais soluções:

• Treine a sua equipe, uma das maiores capacidades do ser humano é da aprendizagem, portanto incentive o seu uso;
• Divida a sua equipe, “modularize” melhor o sistema;
• Converse com o seu cliente, explique que a cooperação dele é fundamental para o sucesso do projeto;
• Motive a sua equipe, mostre que o que ela faz não é apenas garantir a própria sobrevivência.

Portanto, temos que está sempre preparados para superar os obstáculos, transformando-os em motivação. Afinal seria muito chato se você chegasse no trabalho e fizesse sempre o mesmo trabalhinho sem a menor dificuldade. 😉

Última pergunta. Por que falam tanto sobre Scrum?

No meu entender são dois motivos principais:

• Scrum está dando certo na empresas;
• As pessoas gostam de trabalhar com Scrum.

Quando você faz alguma coisa é dá certo, qual é a sua reação? Conta para outras pessoas, não é!? E irá contar para mais pessoas ainda quando você gosta do que está fazendo. Eu mesmo, falo sobre Teste e Qualidade de Software porque gosto, simples assim. E estou agora falando sobre Scrum pelo mesmo motivo. 🙂

Mas por favor, não interprete errado a minha simples pesquisa, não estou falando que usar as práticas do PMBOK não dá certo, ou coisas do gênero.

Minha intenção é que esse seja o primeiro de muitos posts sobre Scrum, afinal esse foi mais um bombardeio de informações. Até mais!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Você sabe o que é Scrum? – Nelson Abu

Scrum é um framework? – Luiz Claudio Parzianello

Scrum Gathering 2009 – Primeiro dia – Parte 2 – André Pantalião

SCRUM Processo de Desenvolvimento de Software – Dra. Eliane Martins (UNICAMP)

Magno, A. Apresentação do curso Certified Scrum Master (CSM). São Paulo, Caelum, 2008.

Imagens:

Formação do Scrum – Faculdade Oberlin

Define metas das iterações, auto-gerenciado e produz produto com qualidade e valor para o cliente. Gerencia a sprint de desenvolvimento.

Qual a melhor metodologia?

Essa é uma questão polêmica, e vejo muitos profissionais tentando responder e justificar a sua resposta. E a cada vez, que eu leio algo sobre o assunto, fico com uma outra dúvida: Será que existe a melhor metodologia para o desenvolvimento de software?

Mas antes de abordar as metodologias de software, vamos definir o que é metodologia.

De acordo com a Wikipédia, “Metodologia é o estudo dos métodos”. Hmmm, não ajudou muito, neh…

Vamos agora ver o que o Michaelis tem a dizer sobre metodologia:

1 Estudo científico dos métodos. 2 Arte de guiar o espírito na investigação da verdade. 3 Filos Parte da Lógica que se ocupa dos métodos do raciocínio, em oposição à Lógica Formal. M. didática: teoria dos procedimentos de ensino, geral ou particular para cada disciplina; didática teórica.

Essa segunda definição é bem profunda, e ajudaria bastante os marqueteiros, imagina só um falando: “A metodologia da nossa empresa, representa a arte de guiar o espírito ao cumprimento dos requisitos.”

Juntando as definições que foram apresentadas, podemos dizer que metodologia é um conjunto de procedimentos que são realizados visando um objetivo maior.

Vamos agora, ir para o mundo do desenvolvimento de software, no qual há várias metodologias que podem ser seguidas. Podemos dividir as principais metodologias em três categorias:

• Cascata: Cascata Clássica, Cascata Modificada e Modelo V;
  
• Iterativa: Modelo Espiral e RUP;
  
• Ágil: Extreme Programming (XP) e Scrum.

Cada uma dessas metodologias, como tudo na vida, tem suas vantagens e desvantagens, abaixo apresento uma comparação das metodologias, de acordo com alguns cenários:

Como pode ser visto na figura acima, de acordo com os cenários apresentados, a melhor metodologia seria o RUP. A razão para esse fato, é que a figura foi retirada do material para a certificação IBM Certified Specialist – Software Quality, e o RUP é um processo proprietário criado pela Rational Software Corporation, adquirida pela IBM. Logo a IBM apresenta o RUP como melhor metodologia, o que pode até ser verdade, dependendo do projeto de software.

Agora você pode está se perguntando: “Como assim, pode até ser verdade, ou uma metodologia é a melhor ou não é!”.

Aí está justamente o erro: tentar definir a melhor metodologia. Buscar a melhor metodologia para a sua empresa é algo louvável, afinal, boa parte das empresas de TI, ainda usam a metodologia VAMO QUE VAMO, ou pior ainda, a EMPURRANDO COM A BARRIGA. Mas selecionar a melhor e colocá-la goela abaixo na sua empresa, com certeza não é o melhor caminho, e ao invés de achar uma solução, você vai achar mais problemas.

Para tentar explicar melhor o meu ponto de vista, vou fazer uma analogia com os eletrodomésticos e eletrônicos da sua casa. Você como um consumidor atento e sempre buscando a qualidade, alinhada ao custo-benefício, tem eletrodomésticos e eletrônicos das diversas marcas: LG, Sony, Arno, Brastemp, Consul, Bosch, Philips, etc. Cada um dos eletrodomésticos e eletrônicos atende uma necessidade da sua família, e para cada um há um melhor fabricante, portanto, você não vai comprar tudo de uma única marca, até porque uma única marca não fabrica todos os tipos de eletrodomésticos e eletrônicos.

Ao escolher uma metodologia você também tem diversas necessidades e várias metodologias que buscam saciar a sua necessidade. Você até pode encontrar tudo o que você precisa em uma única metodologia, mas dificilmente você vai seguir todos os seus conceitos e métodos. O melhor a ser fazer é tentar encontrar um meio-termo, ver o  que há de melhor em cada metodologia e o que se adapta a sua realidade. E quando a sua realidade mudar, mude também a sua metodologia, devemos sempre lembrar que a mudança não é ruim, e sim uma grande oportunidade.

E lembre-se que se uma metodologia funcionou bem em um projeto, era poderá não funcionar tão bem em outro projeto, e vice-versa.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

Engineering Quality in Software Development, Module 1: Overview of Software Development Practices (AzIT)