XP - O que fazer quando não existe o apoio da equipe pra implantar a metodologia?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

rodrigoy wrote:

sergiotaborda wrote:
Por outro lado a sua limitação a achar que scrum é o que o Ken fala e diz mostra ainda mais a sua limitação no conhecimento de scrum. Aliás, o Ken acabou saindo da Scrum Alliance que ele mesmo fundou. Isso mostra várias coisas, mas mostra principalmente que não ha uma relação de identidade entre o ken e o scrum.

O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)?

Scrum não é apenas o que o Ken fala. Ele fala muita coisa, mas ele tende a apresentar o Scrum como uma coisa etérea que cada um pode moldar a seu gosto. Eu perfiro a abordagem mais principio-efeito. São colocados principios, são derivadas regras, são encontradas práticas que seguem as regras. Neste sentido é que o scrum é aberto porque ele não define as práticas, apenas as regras. É como no próprio jogo de rugby, cada jogador tem um objetivo , o jogo tem regras, portanto cada jogador sabe o que é "falta" e o que não é. Durante o scrum (a reunião dos jogadores) a estratégia é definida, mas quando o cara tem a bola cabe a ele, e apenas a ele alcançar o objetivo. Para isso ele tem que ter um conjunto de práticas que , dentro das regras, o levam ao objetivo. Cada jogador tem as suas, e é isso que o torna valioso à equipa. Alguns jogadores têm as mesmas práticas ou algumas práticas são comuns a todos os jogadores. Isso são as práticas da equipa.

Em software, as regras são definidas pelos mecanismos de priorização-planejamento-sprint-dayly-meeting. Cada um tem um papel a cumprir e sabe o que lhe cabe no jogo (PO, SM, testers, designer, arquiteto, etc...) A alguns caberão mais papeis que a outros... os jogadores escolhem as praticas: pair programing, teste unitário, a regra do escuteiro, uso de checkstyle, svn, IC ,etc.. algumas todos os jogadores - membros da equipa- adotam, algumas apenas alguns adotam. E assim vai.

O ponto é que as práticas de engenharia não são ditadas pelo scrum. Isso é ponto assente entre a comunidade scrum. Seria como no rubgy as regras do jogo dizerem exatamente como o jogador terá que fazer a jogada. Isso mata a criatividade e mata o jogo.

Vc nunca ouvira o Ken falar em coisas como estimativas e hiperprodutividade. Para ele isso simplesmente não existe - tlv porque ele trabalha principalmente como consultor de envangelhização e não na mesma empresa 5/7 em todos os projetos - contudo são conceitos extremamente importantes em scrum. Para quem não sabe o estado de hiperprodutividade é quando a equipa faz mais pontos do que seria matemáticamente possível ( ou seja o seu fator de foco é maior que 100%).

Enfim, o Ken não sabe tudo sobre Scrum. Ele não é o Papa. muitas outras pessoas trabalham e desenvolvem o scrum e temos que ouvi-las tb.
Se vc só leu os livros do Ken, vc só tem um lado da historia. Vc precisa ouvir os outros lados.
é neste sentido que não ha uma identidade Ken == Scrum.

Não há uma relação de identidade entre Ken e Scrum?

Acho que ficou claro que não.

Que relação há entre a saída do Ken da SA e a sua autoridade no assunto Scrum?

Esse é exatamente o problema. Vc está se baseando em argumento de autoridade. "Se o Ken falou, e ele é a autoridade , então é verdade".
Isso é o conceito usado para o Papa. Não funciona assim.

O Ken não concorda que é possivel ter um "manual do scrum" no sentido de ter regras que dizem o que é scrum e o que não é. Isto junto ao fato dele ter fundado a SA levou a que durante anos a ceritifcação scrum não tivesse exames e fosse basicamente uma piada. Isto mudou recentemente. Ou seja, as pessoas do scrum não mais se revêem no Ken e querem levar o Scrum a um patamar mais... digamos... concreto. De forma que o mau scrum possa ser provado mau scrum e o bom scrum provado bom.
Ao sair da posição de presidente da SA, ele deixa o cargo de "Papa" e exatamente por isso cai esse conceito que vc está usando de que "o Ken é que sabe do Scrum e o resto é um bando de seguidores".

Este argumento que vc está usando é um problema muito grande na adoção de Scrum e a nova SA visa eliminar este entrave "politico" e se concentrar mais no que realmente interessa : o Scrum. Mais sobre isso aqui.

Conceitualmente incorreta sua colocação e me lembra os aloprados da OMG quando falaram para o Ivar Jacobson que ele não tinha entendido nada de casos de uso.

Se é conceituamente incorreta é discutivel. Depende dos seus conceitos.

Se você toma a liberdade de dizer que o XP como ele é caiu em desuso, tomo a liberdade de dizer que coragem, algo citado no black book do Ken caiu em desuso. Isso nem consta no livro novo (que está mais direcionado para transparência, inspeção e adaptação) e sequer consta no Scrum Guide. Concorda comigo ou não?

Primeiro eu não disse que XP caiu em desuso. eu disse o XP "puro" , "abolutista" , "linha dura", caiu em desuso.
Segundo, quanto á coragem, ele nunca este na moda. Logo não pode estar em desuso. Se vc ler Agile Project Management withScrum vc tem muitos exemplos de como o scrum entra nas empresas , mas nenhum de falha.
Sendo que existem tantos projetos agil falhando é facil ver onde ha coragem e onde não ha. Ha onde dá certo, e é ausente onde não dá certo.

Sua colocação define o que é gestão e o que é engenharia. Me explica: User Stories é engenharia ou gestão? O que ocorre num planning é só gestão?

As historias em si são requisitos e requisitos são problemas a serem resolvidos. eles tanto são um problema para a eng como para a gestão. Requisito não é um prática ou uma regra é uma necessidade de limitar o problema. Podemos então dizer que não são nem um nem outro, ou ambos. Tanto faz.

Panning feito do jeito tradicional não ágil é puramente gerencial. É controle de custo e prazo (apenas). Panning feito do geito agil leva em consideração a realidades das coisas e da equipa e tem um braço estendiddo para o que a equipa pode e não pode fazer. Neste sentido , este planning tb é uma atividade mista. Contudo, o conceito de planejamento em si mesmo (temos que reunir e definir um caminho) tb é apenas gerencial. Tanto é que ele é aplicado em várioas tipos de projetos independentemente do tipo de trabalho (plenaejamento de vendas, de markaeting, etc..)

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Esta entrevista da se-radio aborda exatamente das diferença entre Scrum, XP e Kanban e fala também sobre a ameaça que os gerentes sentem quando houvem falar em agil.

http://www.se-radio.net/podcast/2010-02/episode-156-kanban-david-anderson ( em inglês)

mochuara wrote:Quanta besteira.. Porque quando falamos em RUP vc faz questão de dizer que evoluiu mas com Waterfall se baseia num conceito da decada de 80? Tudo evolui, até mesmo waterfall, e toda empresa que diz usar RUP esta na verdade fazendo uma versão mais moderna de waterfall.

Por que o RUP não é mais waterfall. Ele não usa o waterfall da década de 80.
Se você ainda usa waterfall, você não usa RUP.

This message was edited 2 times. Last update was at 01/03/2010 09:01:48

dreamspeaker wrote:
projeto - analise - implementacao

Continua sendo waterfall. Com ou sem estigmas.

mochuara wrote:
E qual o seu ponto, provar o que é waterfall ou negar que ele tenha evoluido? Eu falei que o RUP é um waterfall evoluído porque ele faz essas mesmas coisas, só que em ciclos.

Waterfall não está relacionado as fases. E sim a duração das fases. Ter uma única (ou pouquíssimas) repetições dessas fases é o que define um projeto como waterfall.
Se as fases forem curtas, e houver realimentação, você está num projeto interativo. Pode não estar num projeto ágil, mas não está mais num projeto waterfall.

Notícias, artigos e o maior fórum brasileiro sobre Java