Ah, então vc usa Scrum?

Ainda estou aprendendo sobre o Scrum, técnicas ágeis e tudo mais.. Apesar de ainda ter muuuito o que aprender, já dá para notar alguns problemas interessantes..
Existem diversos posts em blogs, listas e artigos que já colocam em check se vc realmente está usando Scrum.

Não basta colocar um quadro de kanban na parede, colar uma porção de post-it's e já achar usa Scrum. Pelo contrário, talvez isso possa trazer mais complicações do que soluções.


Quando aplicado ao desenvolvimento de software, há algumas considerações quanto a utilização do Scrum. Além das clássicas listadas nas diversas fontes, acho que também cabe lembrar que antes de Scrum ser Scrum, ela é uma metodologia ágil.

A primeira pergunta é, vc realmente está usando uma Metodologia Ágil?


Usar Scrum e não aplicar a filosofia ágil não é usar Scrum. É intrínseco ao Scrum, que todas os conceitos do manifesto ágil sejam aplicados. Ou seja..

..o seu desenvolvimento é iterativo?


Para o desenvolvimento ágil não há desenvolvimento sem iterações. Como comentado no treinamento de Scrum que participei, Scrum que cria software com uma iteração nada mais é que um Waterfall travestido de Scrum. Não é Scrum! As iterações devem existir e ser as menores possíveis para dar o feedback adequado à equipe para que ela se adapte as mudanças mais rapidamente. Ao final de cada iteração deve ser entregue software testado e funcional para o cliente.

Mas vc está realmente fazendo testes?


O desenvolvimento ágil é iterativo. Logo, haverá refatorações constantes no código para melhorar a aderência ao modelo. Todas essas refatorações, devem ter uma garantia de que estejam funcionando e, principalmente, que nada que estava funcionando antes pare de funcionar. Se vc não garante a qualidade do seu código através de testes, lamento, mas vc também não está utilizando uma metodologia ágil para desenvolver software. Mas se vc está fazendo testes..

..eles são automatizados?

Legal, tudo o que existia e tudo de novo é testado. E quantas vezes forem necessárias! Pelo testador que entrou na ultima hora do projeto e não tem idéia do que o sistema faz.. =/ Se esse for o seu caso, lamento, mas vc não é Ágil!

Testes são um dos alicerces do desenvolvimento de software ágil. O testador ágil tem uma tarefa muito importante e totalmente diferente dos testers (também conhecidos como "apertadores de botão") das fábricas de softwares.

Ok, tendo um verdadeiro testador ágil na equipe, com certeza ele não terá que apertar todos os botões do sistema a cada entrega. Os testes devem ser automatizados..

..e integrados continuamente?

Mesmo utilizando todas as técnicas anteriores, se vc não integra o seu código continuamente, lamento, mas vc também não é ágil para desenvolver sóftware! Sem o suporte dos testes automatizados e da integração continua, o processo do desenvolvimento ágil fica comprometido.

Mas a comunicação está boa?

Vc circula relatórios das atas das reuniões? Comunica a todos os integrantes da equipe por emails formais (que ninguém lê..)? Cada integrante sabe apenas o que ele está fazendo? Se um integrante tem uma dúvida de onde obter uma determinada informação ele não pensa duas vezes: cria um novo campo em alguma tabela e pronto? Se há alguma dúvida sobre algum aspecto do projeto ou história, é assumida a idéia do integrante da equipe sem consultar ninguem?

Se esse for o seu cenário lamento, mas sua equipe não é ágil!

A comunicação (pessoal, face-a-face) é um dos princípios do desenvolvimento ágil.
Todos os integrantes tem que saber de tudo! O tempo todo!

O Scrum Master então, sabe tanto, mas tanto que sabe qual é o shampoo preferido de cada integrante da equipe (rs..).

Sem comunicação constante, face-a-face, de cada detalhe e/ou dúvida não há Scrum.

..o seu Scrum Master e o seu Product Owner.. hum, peraew, vc tem um Scrum Master E um Product Owner, né?


O Scrum precisa de um Scrum Master e de um Product Owner. O Product Owner é quem sabe o que o produto final deverá ser. Uma equipe sem Scrum Master e/ou sem Product Owner não é Scrum! O foco do desenvolvimento poderá seguir uma direção incorreta. E o projeto irá falhar.

..eu tenho um Scrum Master.. ele está bem.. ué, cadê o Scrum Master?


Um time onde o Scrum Master que não é PIG ou que é ausente, não pratica Scrum. É o Scrum Master que garante o funcionamento do Scrum. Sem ele as práticas do framework irão começar a se perder e não haverá Scrum.

Ok, entendi! Mas qual é o problema de dizer que uso Scrum?


Afirmar que usa Scrum sem aplicar suas técnicas mínimas, sem o desenvolvimento ser iterativo, sem os testes e sem eles serem automátizados, sem haver a integração continua e sem o ScrumMaster e/ou o ProductOwner, simplesmente não acontecerá Scrum. O que ocorrerá é:

• Como não há Product Owner os desenvolveres não terão com quem levantar as funcionalidades do sistema. Eles sentirão falta de documentos formais de requisitos, que não existirá por ser um pseudo-Scrum. As tarefas serão mal estimadas e executadas.
  
• Não haverá testes automatizados para garantir a qualidade do software e os testes ficará a cargo de alguem não preparado para tal, o que resultará em erros, em homologação e até em produção.
  
• Sem a retrospectiva aplicada corretamente, o ScrumMaster não poderá remover os obstáculos apresentados pelo time para a próxima iteração.
  
• A pressão irá tomar conta do projeto.
  
• Haverá fortes ocorrências do famigerado comando-controle.
  
• Os componentes da equipe ficarão arrumando culpados entre os que deveriam ser time.
  
• Haverá descontentamento que resultará em desmotivação.
• O espírito de time se perderá.

..e resultado de tudo isso é:

• O projeto falhará.
• A equipe ficará insatisfeita com o que ela acha que é o Scrum..
• A empresa fornecedora ficará insatisfeita com o que ela entendeu que era o Scrum..
• O fornecedor ficará insatisfeito pois seu produto não saiu do jeito que queria e/ou no prazo planejado. Ele ainda achará que a culpa foi do Scrum. E (pior!) achará que no método clássico as coisas funcionavam porque havia maior controle, documentação, cronogramas e tudo aquilo que nós sabemos que não funciona.

Bom, levando em conta todos esses aspectos negativos de uma "falsa" adoção de Scrum, responda rápido:

Vc realmente usa Scrum?

=\