O próprio nome MANIFESTO ÁGIL, soa como protesto, revolução, não aceitação dos padrões, revolta contra o tradicional e acho isso antiprofissional.
Quando se começa a falar de SCRUM X PMI, o pessoal do SCRUM já começa comparando "alhos com bugalhos".
E ai PMPs, vocês vão defender "nossa classe", "nossa" metodologia ou vamos assumir nossos erros e melhorar?
Acho melhor e mais inteligente a segunda opção e assumirmos que adotamos o PMI sem coragem de questionar e simplesmente por que não sabíamos gerenciar projetos no Brasil. O que tínhamos para isso? NADA, especialmente na área de TI. Só as grandes (muito grandes) empresas é que tinham algum gerenciamento de projeto, mesmo assim era só de implementação de pacotes vindos das matrizes do exterior, ou pacotes renomados e caríssimos, que vinham com uma metodologia de implementação própria. Então sabe como é, quem tem um olho em terra de cego é rei, ainda mais quando o rei fala inglês. E vamos continuando consumindo o que os capitalistas nos impõem, afinal é por isso que somos terceiro mundo.
Olha só as comparações:
Colaboração com o cliente é mais importante do que negociação de contrato.
Usam palavras bonitas né....."colaboração com o cliente".....olha só, conseguem fazer elogios e mostrar preocupação com os 2 lados, tanto os clientes como a TI (quem entrega).
O termo negociação é usado levando o sentido para a palavra "dinheiro", o que torna o coitado do tradicionalista um capitalista em projetos.
“Contrato” é ruim mesmo.......êta termo que ninguém gosta, mas experimenta então alugar sua casa ou apartamento e não fazer um contrato com seu inquilino.
Comparar colaboração com o cliente versus negociação de contrato? Para com isso.
Indivíduos e interações são mais importantes que processos e ferramentas. Pôxa, chamaram os tradicionalistas de insensíveis e robôs.
Quem disse que os tradicionalistas não valorizam os indivíduos e as interações e valorizam mais os processos e ferramentas (leia-se que eles quiseram dizer uma palavra só com as 2, ou seja, a metodologia PMBook). Eles comparam 2 coisas sentimentalmente falando e apelam para a questão dos indivíduos e dos relacionamentos contra a metodologia.
Software funcionando é mais importante que uma documentação muito extensa........alhos com bugalhos de novo.
Quem disse que a documentação é muito extensa e quem disse que não temos preocupação com o produto funcionar?
Quanta acusação. Alias, não eram vocês mesmo que nunca fizeram documentação de nada e agora dizem que as documentações são extensas?
Me mostrem as documentações extensas.
Olha só em que tipo de projetos os caras de pau do Scrum dizem que a metodologia é melhor adaptável:
a) Projetos com mudanças constantes. Eu leio sem planejamento e sem saberem o que querem (muita alteração de escopo, influenciando em outras áreas).
b) Equipes que aprendem ao longo do tempo. Reafirma o que eu disse, ninguém sabe direito o que quer e nem como fazer e viram cúmplices uns dos outros.
c) Complexidade e incerteza reduzem a visibilidade. Claramente falta de análises de riscos que o Scrum releva.
d) Colaboração é importante. Ora, é claro, ninguém sabe nada e todos são cúmplices. Vem como uma oportunidade de aprendizagem e precisam colaborar forçosamente, pois senão não sai nada. Não é por que são bonzinhos e colaborativos não.
Lembrem-se que os profissionais que atuam com projetos tradicionais e hoje usam Scrum são os mesmos, então por que não colaboravam antes? A metodologia do PMI não prevê a colaboração? Eu acho que colaboravam sim.
O PO pode justificar a estória ou DEVE justificar a estória? Vocês vão ver no exemplo que darei de um projeto feito com SCRUM se não tiver a justificativa, a probabilidade de dar certo é menor.
A metodologia mexe nos papéis das pessoas para “agradar a gregos e troianos”.
Por exemplo, o PO, proprietário do Produto é na verdade o gerente funcional, cliente que assumiu papéis de gerente de projeto também e dessa forma acabamos com o conflito de poder entre cliente e gerente de projeto.
Além disso, parte-se do princípio de que ele conhece os requisitos do sistema, mas não diz e nem padroniza como esse conhecimento será transmitido. Ou seja, coloca-se o gerente de produtos como gerente de projetos e requisitos ao mesmo tempo, que é o que eles sempre quiseram, além de tirar a responsabilidade da equipe de TI de conhecer os requisitos, outra coisa que TI sempre quis ficar livre também, por que era cobrada de erros como se parecessem que tinham que saber tudo sobre os processos de negócios.
Com essa metodologia, o cliente aprende TI e TI aprende sobre o negócio dia a dia. Uma forma rápida? ou preguiçosa e imediatista? Uma forma abrangente e que visa a integração ou que trata cada projeto isoladamente? Cadê a área de integração entre projetos e o PMO na metodologia Scrum?
Uma forma que gera menos erros ou mais remendos? Menos erros ou mais remendos por que como são verificados diariamente e semanalmente, nem chegam a ser percebidos como erros ou nem chegam a acontecer, por que consertam-os no meio do caminho.
Todo dia pode-se mudar o projeto, parecendo assim que ao final, se conseguiu entregar o planejado, que na verdade não foi planejado e sim foi sendo aprendido/construído.
Ai pegaram os pobres gerentes de projetos e os rebaixaram para serem colaboradores da equipe do PO. Pode crer que essa equipe vai fazer o papel tradicional de gerente de projetos, só que debaixo do PO.
SCRUM Master protege a equipe e retira impedimentos?
Protege de quem?
Quem coloca impedimentos?
Insinuações novamente?
Quais as técnicas que o SM utiliza? Poder, puxa saquismo, panos quentes, panos frios, demagogia, muita conversa com ambos os lados separadamente para não saírem no braço, jogo perde-perde e não se fala mais nisso?
Como esse papel era do gerente de projetos (o chato), pegou-se essa parte do papel do GP e passaram para um cara que se diz entendedor de metodologia de desenvolvimento.
Normalmente um analista de sistemas que fale as duas línguas, negócio e linguagem de TI, e lhe deram poder e uma posição de destaque e só o trabalho de colocar panos quentes e frios e como ele não tem que saber os requisitos e nem ser gerente de projetos (lembre que agora os GPs estão trabalhando para o PO), ele tem que ter conhecimentos de relationship management, comunicação e ser amigo de todos, com um chicote na mão, mas que bate bem devagar, em um nível aceitável para todos. Afinal ele não cobra a equipe (auto-gerenciável) e muito menos vai discutir com o PO que manja tudo do negócio (e não esqueça, já tem uma equipe de GPs).
Engraçado que o Scrum Master ensina o cliente. Ensina o que? ROI?, mas se ele não sabe os requisitos e nem é um GP?
Ensina a não controlar e não comandar? Deixa a equipe se auto-gerenciar? Acho que porque assim fica mais difícil identificar um culpado, pois culpar uma equipe toda é complicado. Quem faria isso no SCRUM, mas com PMI o GP tinha que fazer isso. A culpa no SCRUM é bem sub-dividida e então fica fácil assumir os erros e acertos e ninguém sai muito ferido. Lembrem-se todos são cúmplices.
Por acaso eu posso entender que o GP tradicional era um chato em cima da equipe que não conseguia se auto-gerenciar? Coitadinha da equipe.
Que tipo de planejamento o SM tem para as reuniões? Já que ele é o responsável?
A equipe no SCRUM é multidisciplinar? Como assim? Tem administrador, alguém especialista em riscos, alguém de compras, RH e custos?
Cadê o cronograma? Usam só uma ferramenta chamada relógio para controlar os prazos e adaptam os relógios a velocidade da equipe? ou deveria ser regulado para a velocidade que o negócio precisa?
Coitado do GP, agradeço a SCRUM por ter mostrado como os GPs sofriam injustamente e eram sempre os culpados pelo fracasso dos projetos. Claro, ele que tinha que “fazer tudo”.
Ai só para não assassinar totalmente o GP, eles colocaram um boneco como GP Master, um GP que fica responsável em dar respostas ao negócio em nível estratégico, fica encostado em uma salinha fazendo documentação e vendo a integração entre os projetos. Define algumas políticas nos projetos e virou como se fosse um diretor júnior, entende?
Mas com o SCRUM, ao invés de termos 2 ou 3 GPs em projetos grandes e como as funções do GP foram distribuídas para outras pessoas (de acordo com seus próprios interesses), hoje precisamos só de 1 GP no máximo e ele que se vire para arrumar trabalho e justificar sua posição e garantir sua empregabilidade.
Pontos positivos, ou melhor, só um ponto positivo que vejo: reuniões diárias de acompanhamento mais constantes que impedem do produto sair errado, mas isso não garante menor custo, menor prazo, maior qualidade, ou seja, conseguiu resolver um problema que especialmente a área de TI tem muito que era a de entregar coisas erradas ao cliente e só descobrir isso no "segundo tempo da partida". Minimizou o problema de comunicação, que todos os gerentes de projetos experientes sabem que sempre foi o maior problema nos projetos. Essa comunicação diária e semanal serve meio que um teste do sistema, por isso menos erros e mais retrabalho picado (ou remendos menores). Essa reunião diária é um chicote de “dois gumes”, pois expõe todos na frente um dos outros.
Reunião diária funciona e sabe por que? Por que temos que aprender pouca coisa de um dia para o outro, então fica mais fácil, mas não temos a visão global do produto e de seus benefícios (por isso que eles até dispensam a justificativa).
Cria competição e lida com o medo das pessoas de no outro dia mostrarem que não fizeram nada uns na frente dos outros.
As pessoas se sentem menos cobradas de terem que conhecer tudo e podem justificar e resolver seus erros rapidamente e isso não é considerado como mal entendimento e sim como uma coisa "normal" no SCRUM.
O product backlog tem como principal característica manter as prioridades (que vivem mudando por que a cada dia vai se descobrindo o que realmente se quer) e é claro que quem determina a prioridade é o dono do produto, mas nem sempre tecnicamente falando é fácil para o pessoal de TI mudar as prioridades devido as questões técnicas.
A ordem de priorização proposta pelo SCRUM com base no conhecimento que se tem da história pode ser uma faca de 2 gumes. Explico: se o PO não sabe detalhes de alguma história, então como usa-se esse critério para priorizar algo que não se conhece?
Normalmente o que não se conhece (e o que é mais difícil) é o cerne do sistema, a parte mais complexa, o núcleo, o cálculo mais complexo.
Depois se diz que a ordem de priorização do backlog é a ordem de priorização de implementação.
Afinal qual é a ordem de priorização?
E se tecnicamente/tecnologicamente para o pessoal de TI é mais PRODUTIVO desenvolver algum aspecto do sistema primeiro?
Na verdade a ordem de priorização é definida num jogo de cartas. Essa eu gostei e acho legal, democrático e justo. Evita futuros problemas, pois todos puderam opinar.
É uma forma de não dar chance de alguém dizer que não participou e culpar alguém.
Mas como definir prioridade só vendo a ponta do iceberg?
Onde está o cálculo do ROI desse backlog?
O produto entregue é mais ou menos assim: Um carro com um câmbio só com 1 marcha (pra que mais velocidade, andar é o que importa, mas e agora, quando vamos entregar as outras marchas?, o concorrente já tem 5 marchas), sem porta-malas (caramba, não sabíamos que poderíamos fazer uma viagem, afinal o carro só tinha 1 marcha), sem limpador de para-brisa (puxa, esquecemos dos riscos), só com o banco do motorista (para que pensar em outras pessoas, áreas, pra que integração?)
Acho a área de integração do PMBook pouco usada e acho que a palavra mais correta seria sincronicidade entre as áreas e não integração.
A velocidade da equipe se adapta a equipe, mas e se não for o suficiente conforme a velocidade que o PO precisa?
Quem determina no SCRUM quando um produto está efetivamente pronto para começar a ser usado? Da forma como é dito parece que quando terminamos um “bloco” de sprints e temos um pré produto, já podemos entregar algo ao cliente. Como assim?
Me dê um exemplo. Um bom e bem explicado exemplo.
Em 4 horas se define o que vai ser feito em 1 mês, certo?
Eu duvido que isso funcione dessa forma tão “certinha”. Acredito que se somarem todas as horas de reunião durante 1 mês, vão verificar que gastaram muito mais tempo de reunião com TODA uma equipe e que se compararmos com as horas de execução do trabalho efetivamente, verão que continuam gastando várias horas de “planejamento picados” (que eu prefiro chamar de entendimento dos requisitos picados), o que é absolutamente normal e esperado, ou seja, dizer que gastam 4 horas para definir o trabalho de 1 mês não é verdade. E as horas que gastam diariamente? Tem que somar tudo isso como horas de análise de requisitos.
É dito que se discute até tecnologia sendo usada e se temos algum problema com ela na reunião de planejamento 1 ???!!! Não acha que esse assunto não deve ser tratado nessa reunião?
Quanto tempo sobrará para discutir sobre o negócio efetivamente? O que o PO tem a ver com isso?
Seria prudente colocar até possíveis fornecedores em uma reunião dessas? E a confidencialidade dos assuntos?
Nas reuniões de planejamento 2, o PO participa? Se sim, acho tremendamente desnecessário por motivos óbvios: ele não tem que saber como a equipe vai fazer o trabalho, mesmo por que a equipe é auto-gerenciável, ou não? Na verdade é para tirar dúvidas de requisitos ainda, então vamos somar também nas horas de planejamento 1, pois estão em duplicidade.
Já temos o Scrum Master para participar dessa reunião e que deverá ter seu papel justamente de filtrar o que a equipe discutir e levar só o que interessa ao PO sobre a reunião e fazer o trabalho
que vocês dizem que é o do SM, ou seja, evitar atritos, dirimir dúvidas, etc.
Perceberam que o SM tem poucos papéis até agora?
Acho interessante a colocação de especialistas específicos nas reuniões de planejamento 2. Vou inserir esse conceito nas minhas reuniões mais fortemente. Eu já fazia isso, mas tenho me esquecido. Só acho que eles poderiam já participar da reunião de planejamento 1, mas sabe por que não participam? Por que na reunião de planejamento 1 ninguém ainda sabe nada do produto, então para que chamar um especialista, sem se saber no que esse especialista precisa ser?
Que bagunça de reuniões......Vocês conseguem realmente manter os focos nas reuniões naquilo a que elas se propõem?
A gente fala tanto de reuniões improdutivas nas empresas.......será que realmente as reuniões seguem seus objetivos e metas? ou são reuniões iguais e se fala de tudo um pouco?
Quanto tempo dura uma reunião de planejamento 1 e como é sua dinâmica (forma, documentação, processos, gráficos, etc.) Toda a equipe participa? Tem documentação?
Acho que na reunião diária poderia se falar de tecnologia sim, pois na reunião onde isso é proposto (planejamento 1) é a reunião onde está o PO, então não tem sentido discutir esse tipo de assunto na reunião de planejamento 1 e sim na diária, onde podem ser percebidos dificuldades na execução do trabalho com uma ou outra tecnologia.
Chamar um PO como visitante numa reunião dessas, pra mim, é um absurdo.
Mas é como eu digo.....vocês dividem os méritos, culpas e tornam-se todos cúmplices um dos outros e dessa forma, os egos se acalmam e a coisa tem que andar, mesmo que o produto final
saia meio "distorcido" do que cada um queria PEDIR e/ou ENTREGAR.
Quando vocês analisam e criam planos para os riscos? É através de cartas também e da opinião de cada um sobre o que acha sobre um risco?
É recomendável que durante uma sprint, nada mude, mas é possível isso acontecer. Vocês tem algum dado estatísticos de quantas sprints tiveram alterações durante sua execução e quantas sprints não tiveram mudanças?
Depois ao final, vocês dizem que é possível receber novas histórias durante a sprint. Ora, isso não é uma mudança de escopo? Só por que deram outro nome "receber novas histórias"?
Gostaria de saber como é atualizada diariamente um gráfico de burndown. QUEM o atualiza e com que dados, recebidos ou gerados por quem? Há uma concordância entre todos sobre os dados do gráfico? Acho que deveria ser o SM. Seria um bom papel para ele, já que é o intermediador e conhece os dois lados. Afinal, o que o SM realmente faz?
Do jeito que é colocado o projeto no modelo Scrum, é impossível um projeto dar errado, pois com acompanhamento diário, torna-se impossível mudar o rumo, perder o norte, não detectar problemas na equipe, etc.
Quem e quando se controla a qualidade das tarefas diárias quando as mesmas vão sendo colocadas como encerradas?
Então, vocês poderiam me mostrar dados sobre os motivos pelos quais, alguns projetos usando Scrum não deram certo?
Quais foram esses motivos? Quais foram as lições aprendidas?
No gerenciamento tradicional de projetos, as lições aprendidas também são estudadas não tão profundamente quanto deveriam e a relação causa-efeito também. As causas raízes e os malefícios que o projeto gerou não são muito considerados, stress da equipe, por exemplo.
Na reunião de retrospectiva, na qual o PO deveria estar, vocês tiraram. Nessa reunião todos tem que estar e lavar a "roupa suja" e também exaltar os pontos positivos, mas ai vocês evitam esse enfrentamento (no bom sentido) e a equipe não pode criticar o PO e nem o PO pode falar nada sobre a equipe. Continua o esquema de agradar a gregos e troianos.
Sobre os riscos, vou sugerir uma coisa.....criem uma tabela de riscos por backlog e mantenham esse quadro ao lado da tabela de backlog para irem acompanhando se os riscos tem probabilidade de acontecer ou não, ou cadastrar novos riscos identificados.
Não usam baseline? Acho que não dá tempo para isso, pois o projeto muda o tempo todo e o tempo é tão curto que baseline perde sua função.
Documentação inexistente? Qual a documentação final de um projeto gerenciado por Scrum?
Todos se suportam, pois é assumido de que não precisam saber e nem estudar nada de antemão, pois tudo será sendo feito aos “picados”.
Planejamento fica como irrisório e desnecessário e nem diz quem participa do planejamento e se tem algum responsável e/ou quem valida o planejamento.
E cadê a integração entre as áreas?
Eeeeiiiii GPs acordem, tão batendo em vocês pelas costas e vocês não tão nem vendo (pois estão trabalhando duro nos projetos).
Vamos questionar algumas coisas do PMI que estão na “metodologia”, fazemos, ou não fazemos.
Por exemplo: quem faz lista de fornecedores e quem utiliza essas listas nos novos projetos antes de contratar um fornecedor?
Vamos ter mais proximidade com nossos clientes e falar mais com eles, testar mais os produtos em blocos menores e não ficarmos preocupados em surpreender o cliente entregando algo bem melhor ou só quando estiver completamente pronto.
Vamos dar um exemplo de projeto então, para não ficar só nos exemplos isolados que dei acima?
Vamos fazer aquele projeto que todo mundo faz no começo da carreira que é o projeto de uma viagem, lembra?
Então........como todos já sabemos como funciona no modo tradicional, vamos só descrever como ele é feito no SCRUM.
Alguém diz saber o que quer, para onde temos que ir, só que esse cara não sabe como.
Então alguém que não conhece o lugar onde vamos chegar, levanta a mão e diz que sabe como.
Para intermediar essa falta de conhecimento de ambas as partes, coloca-se um mediador que vive convencendo ambas as partes de que ambos estão alinhados, aprendendo, se auto-gerenciando (ué....agora que percebi, se a equipe é auto-gerenciável, por que o PO assumiu algumas função de GP?, temos um GP Master ainda e precisamos de um mediador (só para fazer reuniões)?
Mas continuando a viagem, vemos que pelo Scrum podemos cair nas seguintes falhas que não foram devidamente estudadas para não acontecerem.
a) esquecemos de levar as malas.....tudo bem, ainda estamos no caminho do aeroporto, dá pra voltar
b) quando chegamos para pegar as malas, alguém auto-gerenciável, já arrumou as malas pra nós?
c) descobrimos que as malas estão desarrumadas, mas tudo bem, estamos aprendendo e eu mesmo que teria que fazer as malas vi que tinham coisas na mala que nem eu mesmo ia lembrar
d) nessa hora aparece o "pano-quente"
e) não custou nada tudo isso.......é melhor do que descobrir que as malas não foram quando chegarmos no destino (se chegarmos, pois no SCRUM o destino vai sendo traçado dia a dia por que o que disse saber pra onde queria ir percebeu que não era bem assim e os que não sabiam pra onde ir, mas diziam dizer saber como, já entenderam, que pelo menos, deve ser uma viagem longa ou curta e para onde, a depender do tamanho e conteúdo da mala.
f) Não esquenta não......não perdemos a viagem e nem a reserva, pois podemos jogar para o próximo sprint (sem custo?) (e o prazo?), mas pelo menos, a qualidade teve uma maior garantia de entrega de um melhor produto que está sendo criado agora em conjunto pelos dois lados que estão aprendendo.
g) cadê a justificativa da estória, da viagem?
Vocês tem alguma estatística sobre quantos projetos com sucesso e sem sucesso foram entregues pelo método tradicional e pelo método Scrum?
Por favor, se o SCRUM é uma nova forma de gerenciar projetos, me digam o que o SCRUM tem em comum com o PMI.
Compactar é diferente de agilizar. Tirar processos é diferente de agilizar. O Scrum serve para a área de TI, mas para projetos de menor risco. Experimente construir uma ponte usando Scrum, ou um sistema de controle de qualidade que lide com risco de vidas.
Gostaria de saber se tem algum índice de rotatividade de pessoal em projetos Scrum X em projetos com PMBook.
Se quiserem um trabalho de crítica sobre a metodologia do PMI, igual a esse, é só pedir.
