Metodologias ágeis: Scrum
comentada em 24/07/2021 00:13

Uma boa indicação é o Scrum Guide, é como a bíblia do Scrum, recomendo a leitura!

The Scrum Guide

Melhor método que existe é o GH (Go Horse), ou sua evolução o XHG ( Extreme Go Horse).

Para aqueles que ainda não conhecem essa revolução nós processos, segue algum dos seus fundamentos:


1. Pensou, não é XGH.

2. Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

3. Quanto mais XGH você faz, mais precisará fazer.

4. XGH é totalmente reativo.

5. XGH vale tudo, só não vale dar o toba.

6. Commit sempre antes de update.

7. XGH não tem prazo.

8. Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

9. Seja autêntico, XGH não respeita padrões.

10. Não existe refactoring, apenas rework.

11. XGH é totalmente anárquico.

12. Se iluda sempre com promessas de melhorias.

13. XGH é absoluto, não se prende à coisas relativas.

14. XGH é atemporal.

15. XGH nem sempre é POG.

16. Não tente remar contra a maré.

17. O XGH não é perigoso até surgir um pouco de ordem.

18. O XGH é seu brother, mas é vingativo.

19. Se tiver funcionando, não rela a mão.

20. Teste é para os fracos.

21. Acostume-se ao sentimento de fracasso iminente.

22. O problema só é seu quando seu nome está no Doc da classe.

@luizatv hahahaha no começo eu tava pensando que era sério e pensei “poxa aqui na empresa fazemos tipo esse método”

@Portnoy mesma coisa onde eu trabalho. É a tendência mesmo. Mas, aqui a maioria dos projetos vejo que ainda tem um modelo misto de tradicional cascata e ágil.

@Art., uma coisa que está no livro do Sutherland sobre Scrum e que pude comprovar na prática: cronograma em cascata raramente (nunca, pra ser mais preciso) atende ao andamento do projeto e antes da metade da execução é abandonado. Daí lá no final, quando falta pouca coisa pra concluir, volta a ser útil. 

@Portnoy

Leia o livro Scrum: A arte de fazer o dobro do trabalho na metade do tempo.

Ele explica o método e além disso conta a história de como foi desenvolvido, quando existia um sério problema no banco de dados do FBI (se não me engano é isso).

Eu gosto muito do método, só acho que é mais aplicável na área de desenvolvimento, tecnologia e não em vendas, que é minha área.

Boa sorte.

@Chapulin, esse eu já li. Gostei. Mas por ser escrito pelo "dono" do negócio, tudo é muito perfeito lá. Rsrs

Por que vc acha que não é aplicável em vendas?

Transformação digital tem nada a ver com Scrum. Exemplo disso, trabalho em um das maiores startups do mundo e não usamos Scrum ou Kanban. O importante é a cultura da empresa, transparência e empoderamento dos times. A maioria das empresas usam Scrum só para pendurar post-it na parede e se diz uma empresa ágil. 

@Gandalf_Negao, interessante. Vocês usam alguma metodologia específica? 

A organização das equipes é fixa em departamentos ou por projetos? 

Nós tentamos implementar SCRUM na equipe aonde eu trabalhava. Funciona bem até certo ponto. Mas o saldo foi positivo.

Uma conclusão a que cheguei é que pra dar certo as tarefas tem que ser quebradas até níveis muito simples, que podem ser executadas por qualquer um do time sem muito "briefing". Aí a coisa vai bem.

Mas no nosso caso eram tarefas complexas e é difícil conseguir que qualquer um faça alguma parte sem ter feito as anteriores, e o "switching cost" (trocar a tarefa de pessoa) fica muito alto.

Scrum pode servir como norte, no entanto nunca tente usa-lo como ferramenta estática dentro de uma equipe. Acredite nunca dá certo.

Como experiência pessoal vejo que a proximidade do detentor das regras de negócios e a entrega contínua como pontos positivos do método. Entretanto a estimativa de complexidade, não é nem que você vai errar, é que mesmo que vc acerte, vc não vai saber que acertou. E mesmo que acerte e saiba que acertou, por algum "conhecimento místico", não vai te servir pra nada.

@Portnoy

Então... eu acho que o processo de vendas segue uma rotina diferente (pelo menos no meu caso, que são vendas técnicas, com visitas a clientes específicos, com tempo longo de maturação e fechamento dos projetos)... pode ser uma visão errada minha, mas não consegui aplicar.

A parte de autonomia das equipes, essa sim é muito boa.

Transformação digital acontece de cima pra baixo, olhando pra todos os deptos, processos, sistemas e pessoas e depois ir pensando em pequenos passos de implementação.

Não dá pra tirar o ERP véio e remendado, as 594 planilhas e colocar um sistema cloud por subscription e achar que vai voar... rsrs

É um desafio dos mais difíceis e não tem metodologia única, ao meu ver.

Altíssimo nível: se essa fosse minha tarefa atualmente, eu contrataria uma consultoria pra um projeto de 2 a 3 meses de design thinking, modelaria toda a nova arquitetura de sistemas integrada, e depois faria o rollout por áreas da mais fácil e menos dependente do sistema core pra mais complicada. 

Vejo as pessoas adotando o modelo Agile do Spotify by the book ou tentando implementar todas as cerimonias descritas no Agile Book antes mesmo de entender o porque de fazer cada uma...

Um dos maiores desafios do SCRUM é que a liderança da empresa acredita (de verdade) que isso possibilitará fazer a coisa mais rápido e não mais eficiente que é o seu propósito, fazendo o bebê nascer em 1 mês. Aqui o pessoal fala que o Scrum é um waterfall dividido em mais etapas... Invista em ter um Product Owner muito bom e que tenha capacidade de fazer qualificar e priorizar um backlog adequado... a metodologia de execução será um detalhe... o contrário não funciona

@Portnoy Qual a área da empresa que você trabalha? Também gostaria de implementar o método, ou pelo menos algumas técnicas, mas não trabalho em empresa de tecnologia, então parece que fica tudo mais travado.

@tylerdurden, eu trabalho em um escritório de produção de conteúdos educacionais. Diversos tipos de conteúdo, a depender do cliente. 

Tudo começa com um Por quê?
As vezes até 5 Por quê? Rs

Pq você acredita que precisa passar por uma transformação digital? E pq acredita que uma mudança de processos vai trazer benefícios?
Estes questionamentos vão direcionar melhor o método/técnica adequado, seja scrum, kanban, scrumban, okr, 4dx, etc.

Ainda assim,  ressalto que o método, ou as práticas e técnicas de cada método de agilidade, pouco importam. Todos são frameworks que sugerem e recomendam adaptações para cada realidade, sendo que o que importa mesmo é a sua essência de entrega de valor rápida ao cliente final, constante, com qualidade, baixo desperdício e menor risco.

Isto posto, e tendo certeza que investirão em tempo e dinheiro sabendo que a principal dificuldade será a mudança cultural e de pessoas, sugiro já terem métricas de largada que poderão provar a evolução do momento atual para o que desejam no futuro.
Acredite, a cobrança de validar se a mudança foi satisfatória sempre aparece no futuro e fica difícil comprovar se não provocar agora os principais motivadores. 

@Chavinho, bons pontos. 

Não sou eu que tomo as decisões dessa envergadura, mas imagino duas respostas:

Transformação digital para o negócio não morrer. Atualmente, boa parte dos produtos é feita como se fazia há 30 anos.
Mudanças nos processos porque os antigos já não são suficientes para se produzir no ritmo de entregas atuais. As entregas estão cada vez menores e o ciclo dos produtos também.

 

O que vc chama de métricas de largada? 

Quantidade de coisas produzidas, por exemplo? Tempo de produção? 

Acho esse vídeo sensacional sobre scrum.