O assunto principal, é como chamar o Scrum. Eu respondi por lá, mas parece que moderaram a minha resposta. Fica difícil saber a verdade, mas como eu tenho meu espaço, vou colocar aqui a minha resposta, e quem quiser discutir de forma sadia, fique a vontade. Uma rapidinha sobre como chamar o Scrum.
Deixo a mensagem aqui agora para discutirmos.
"
Oi Miguel,
Algumas coisas que você falou me chamaram a atenção. Eu estou aprendendo sobre métodos ágeis e gostaria de entender melhor a sua frase.
Primeira parte: "Metodologias são mais prescritivas"
"Ágil" é considerado metodologia. Você a acha muito prescritiva com 4 definições de valores e 12 principios. Ou você acredita que não deveríamos chamar de metodologia? Não entendi por que você colocou quantidade de prescrições na definição de metodologia.
No dicionário Oxford, metodologia é:
Algumas coisas que você falou me chamaram a atenção. Eu estou aprendendo sobre métodos ágeis e gostaria de entender melhor a sua frase.
Primeira parte: "Metodologias são mais prescritivas"
"Ágil" é considerado metodologia. Você a acha muito prescritiva com 4 definições de valores e 12 principios. Ou você acredita que não deveríamos chamar de metodologia? Não entendi por que você colocou quantidade de prescrições na definição de metodologia.
No dicionário Oxford, metodologia é:
"a system of methods used in a particular area of study or activity:"
No dictionary.com, está escrito:
"a set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences."
Não vejo problemas em ver o Scrum como um método definido de gerenciar o desenvolvimento de softwares:
"a particular form of procedure for accomplishing or approaching something, especially a systematic or established one"
Oxford Dictionary - Method
Com isso, semanticamente, acho que poderiamos chamar o Scrum de metodologia, pois, matematicamente, o conjunto de um elemento (método), continua sendo um conjunto.
Também vejo o Scrum prescrevendo como deve ser o seu processo de desenvolvimento, principalmente definindo um ciclo de reuniões de X em X semanas. Eu vejo o Scrum como uma ilha de desenvolvimento (sprint) cercada de reuniões por todos os lados. Veja bem, não estou afirmando que isso é bom ou ruim, só estou expondo a minha visão.
Vamos ao Oxford novamente:
a series of actions or steps taken in order to achieve a particular end
Oxford Dictionary - Process
Oxford Dictionary - Process
Por que seria errado chamar o Scrum de um processo de desenvolvimento de software?
Na segunda parte da sua frase, você disse o seguinte: "e não extensíveis como o Scrum e raramente podem ser modificadas."
Nesta parte acredito que você estava defendendo o Scrum como framework:
a basic structure underlying a system, concept, or text
Oxford Dictionary - Framework
Oxford Dictionary - Framework
Isto é, algo fundamental que serve de base para alguma coisa. Esta "alguma coisa" é extendida do framework. Sua idéia de framework me parece correta.
Agora analisando mais de perto a questão do Scrum ser um "framework", onde e como ele é extensível e modificável?
Abraços
Na minha visão, framework é uma das coisas que o Scrum não é. E você, acha que o Scrum é um framework? Por que?
Qual a importancia disso? Você vê valor em discutir em como chamar o Scrum?
Não sei se estou falando besteira... também não vejo nada de mal em ser chamado de metodologia, processo ou framework, mas imagino que quando chamam SCRUM de framework é por ser incompleto. Ele não diz exatamente as soluções para seus problemas (Eu também não sei dizer se uma metodologia deveria dizer), mas por exemplo... Scrum não diz que você tem que usar user story ou use case, nem que você tem que usar um quadro kanbam c/ post-its, a forma de estimar estórias etc. Acho que SCRUM parte do princípio que você tem maturidade p/ tomar as decisões que mais se adequam ao seu cenário mas você faz tudo isso dentro daquela forma de trabalhar, com seus papéis e eventos que já conhecemos.
ResponderExcluirSinceramente eu não acho que isso faça tanta diferença.
Parabéns pelo blog, sempre acompanho mas é a 1ª vez que comento.
Francisco, muito obrigado por essa colocação de ideias. Era mais ou menos o que eu esperava.
ExcluirNão se preocupe em dizer besteiras. Vivo dizendo neste blog. Acho que colocar ideias é importante e, se alguém não concorda, nada como argumentar.
Mas vamos ao assunto... eu posso estar errado, mas acredito/vejo o Scrum definindo processo. Como eu disse na thread, eu vejo o Scrum como uma ilha: uma etapa de desenvolvimento cercada de reuniões por todos os lados (inclusive dentro da etapa de desenvolvimento). Tudo bem, o Scrum não define como as tarefas devem ser chamadas, entretanto recomenda o uso de estórias. Inclusive, acho que isso nem é um ponto tão importante, pois acredito que funciona das duas formas. Acho que o objetivo seja ter tarefas bem descritas e rastreáveis.
Quando questiono o Scrum como framework é que não o vejo como extensível na sua definição de processo. Eu posso tirar a review? Meu cliente (de fato) está presente no meu dia a dia. Não preciso de review. Posso tirar a daily? Meu time está sempre junto e impedimentos e pequenos acertos no plano são feitos a todo momento. Posso tirar a retrospectiva? Meu time faz melhoria contínua todo dia e nestas reuniões só comemos e jogamos videogame (não que isso não seja importante, mas não precisa ser chamado de retrospectiva). Eu quero adicionar um tipo de review dentro da sprint, pois a empresa do meu cliente é perto da nossa e ele quer acompanhar mais de perto o que está acontecendo.
Veja bem, são apenas argumentos.
Não vejo o Scrum para equipes auto-organizadas, mas para formar equipes auto-organizadas e auto-gerenciaveis. Vejo o Scrum como um remédio. Não é que você não esteja fazendo a daily pois, na verdade, você a está fazendo continuamente. Não é que não tenha retrospectiva pois, na verdade, ela acontece a todo momento. Elas só não estão *acopladas* a minha sprint. E para isso sim é necessária maturidade.
IMHO, para ser um framework, o Scrum não poderia ser rígido no seu processo. Eu deveria poder mexer na Planning, Sprint Planning, Sprint - Daily, Review e Retrospectiva. Isso não deveria ser um mantra.
Obs: Não estou afirmando que o Scrum é bom ou ruim. Estou discutindo a sua classificação como framework.
Opa,
ResponderExcluirVocê caiu na pegadinha. O Scrum não é metodologia, é apenas um framework, com artefatos, papéis e eventos, que podem ser adaptados à realidade de cada um (fazer do seu jeito), embora muitos gurus do agile esqueçam desse detalhe.
Como pode ver, não tem processos no Scrum. Nada que é sugerido interfere diretamente na forma de produção (projetar, desenvolver, testar, implantar, executar). Apenas orienta parte do planejamento.
Uma metodologia determinaria uma forma de trabalhar, já o Scrum apenas faz sugestões, é extensível e modificável.
Quantidade de membros da equipe (3-9), porém, se adequado, pode usar mais (modificável).
Releases, não previstas, mas podem ser controladas junto com as sprints (extensível).
Vou além, você não é obrigado a fazer todas as reuniões. Eventualmente uma ou outra (reuniões diárias, por exemplo) não serão necessárias. Mas, é aconselhável fazê-las. Você disse que seu cliente está presente, mas está realmente acompanhando? A review serve para mostrar o resultado final. E a retrospectiva é uma documentação da melhoria contínua. Que adianta "melhorar diariamente" se na sprint seguinte ninguém mais lembra de nada? A retrospectiva serve para reavaliar o todo, e como compromisso de que todos procurarão não cometer os mesmos erros.
Ou seja,
Scrum -> Framework
Não entendo como tantas pessoas, inclusive as que se dizem praticantes, não conseguem entender algo tão simples e prático como o Scrum.
Cuidado com os equívocos companheiro :D
Felipe, obrigado pelos conselhos.
ExcluirPelo que pude perceber, talvez você tenha uma visão do Scrum parecida com de alguns amigos meus, mas que, infelizmente, não é a "visão oficial", inclusive do próprio Schwaber: "Você pode mudar o Scrum, mas não o chame mais de Scrum". Isso mostra uma fidelidade grande à prescrição do processo.
Na verdade, você mesmo mostra essa fidelidade, quando parece confiar muito mais em um documento gerado na retrospectiva que em uma melhoria contínua. Quem garante que o documento de melhoria será observado no próximo sprint?. O ScrumMaster? Ok. Então por que ele também não pode garantir a melhoria contínua? Lembrando que retrospectiva timeboxed não é melhoria contínua e sim periódica.
Quem disse que o cliente presente não estaria acompanhando? Sim podem acontecer casos, mas que também podem ser remediados. Então eu devolvo a pergunta: Quem garante que, mesmo na review, ele esteja acompanhando? Ele pode estar no seu smartphone durante a reunião ou pode estar pensando em outras coisas. Comprometimento do cliente (ou PO) não está relacionado a reviews timeboxed.
Não acredito que tamanho da equipe seja uma extensibilidade do Scrum. Não faz o menor sentido para mim.
Você me convenceria de que o Scrum é um framework se um dos passos do seu processo pudesse ser removido (ou outros adicionados) sem, oficialmente, nos obrigassem a muda-lo de nome. Só deixando bem claro que isso não faz a menor diferença para mim, pois não quero dizer que estou rodando Scrum, sou CMMI ou que tenho centenas de PMPs no meu projeto. Quero, simplesmente, garantir que o meu cliente está feliz.
Não sei de onde você tirou essa definição de metodologia. Referencias? Pelas referencias que tenho, metodologia, como eu disse no post, é um conjunto (um ou mais) de métodos de se fazer alguma coisa. O Scrum não define pelo menos um método de fazer alguma coisa?
Enfim, não vi nos seus argumentos algo que negue a característica de processo ou metodologia do Scrum. Ainda mais, não vi nada que garanta que o Scrum é um framework.
Alguns de seus argumentos são baseados em princípios falsos como, por exemplo, de que a retrospectiva ou review funcionam melhor se forem timeboxed que se fossem contínuas. E lógicas baseadas em falsos princípios tem um nome: falácia.
Tome cuidado, meu amigo, com duas coisas:
1. "Process over people and interaction". Não é o Scrum (ou Kanban ou Crystal ou FDD) que é importante. Entregar valor de qualidade, no custo e prazos combinados, deve ser o seu foco.
2. Não esqueça nunca da palavra mágica "depende". Tudo depende do contexto. Por não atentarem para o contexto que muitas empresas falharam ao tentar imitar o TPS e foram inclinadas a admitir que "isso só funciona na Toyota".
Observe os princípios e valores, analise o seu contexto, seu ambiente e, assim, comece a tentar adaptar as práticas para o seu ambiente, para o seu contexto. Não engesse o seu pensamento porque você ama o Scrum. Se você ama o Scrum, já está falhando no primeiro valor do manifesto ágil.
Abraços