projeto - analise - implementacao
Continua sendo waterfall. Com ou sem estigmas.
projeto - analise - implementacao
Continua sendo waterfall. Com ou sem estigmas.
[/quote]
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.
[quote=Paulo Silveira][quote=sergiotaborda]
XP são práticas de desenvolvimento de software. Scrum são práticas de gerenciamento de projeto.
[/quote]
O Yoshima tem razão, XP não são apenas praticas de desenvolvimento de software. User stories, small releases, iteration planning são práticas que quem praticava Xp antes de Scrum já conhecia.
Agora mudou. Aí sim.[/quote]
:lol: :lol:
User stories , small releases, iteration planning são estruturas de todas as metodologias ageis. dizer que XP é mais do práticas que engenharia
é redundante, até tautologico, porque se não for mais que isso, não é uma metodologia. É o arcabouço agil em si mesmo.
Então o que diferencia XP de Scrum, não são essas coisas que são comuns a todas as metodologias ageis. Isso é o que eles têm em comum e pelo qual são consideradas ageis.
Embora eu nunca tenha dito que XP são apenas práticas de engenharia, e sim que ele se diferencia de outras metodologias pelas práticas de engenharia, vale a consideração que as práticas de planejamento de XP não são realmente próprias ao XP e sim comuns a todos os mecanismos ageis.
(O livro Agile Software Estimation deixa isto mais obvio.) A pessoas planejam sprints em todos os mecanismos ageis. A diferença é o que se considera o " objetivo do sprint". Em scrum, por exemplo, e á diferença de XP, o sprint precisa levar a codigo apto para deploy. Em XP isso não é obrigatório.
São essas diferenças filosoficas que diferenciam se está usando XP ou outra coisa.
O meu ponto é apenas que, toda a parte de planejamento assocaida ao XP é feita melhor se usado Scrum. Por outro lado, o ponto é tambem que as práticas associadas ao XP como TDD e repositorios de codigo não são exclusivas do XP. São práticas do desenvolvimento de software que o XP amarra e estabelece critérios de uso para elas, mas as práticas não são do XP, são usadas pelo XP. Ha uma diferença.
Enfim, a ideia é apenas dizer que podem ser usadas as práticas de desenvolvimento sem que isso caracterize XP e também ser feliz e ter bons resultados. Não é preciso entrar na onda “extremista” do XP de tudo ou nada. Para a parte de planejamento Scrum tem mais ou melhores efeitos que a do XP porque os valores são mais rigidos nessa parte. E para a parte de engenharia as práticas per se são suficientes.
Nao quero provar nada. Soh achei esquisito o termo “waterfall evoluido”. Se o waterfall evoluiu pra alguma coisa nao eh mais waterfall, oras.
Eu tenho comigo que processos de desenvolvimento de software soh servem pra alguma coisa se as pessoas envolvidas servem pra alguma coisa. RUP, XP, Scrum, e mais meia duzia de nomes ai, soh servem pra algo se as pessoas envolvidas estao “envolvidas”, repetindo a repeticao. De resto nao entro em discussoes detalhistas, nem tenho know-how pra isso.
E outra, se faz em ciclos nao eh waterfall (a nao ser que vc esteja considerando que a agua evapora e cai na cachoeira novamente) :mrgreen:
Sergio, você escreve muito. Seja mais direto. Coloque seu ponto de vista sem fazer estripulias. Fica difícil discutir com você como sempre. Só um desabafo.
Se eu tirar o Scrum do XP ainda sobra:
Valores:
- Simplicidade (é um conceito de gestão)
- Coragem (é um conceito de gestão)
Princípios (que envolvem Gestão):
- Falha
- Humanismo
- Passos de Bebê
4,.Redundância
Práticas (mais uma vez, somente as que envolvem GESTÃO):
- Ambiente Informativo (psc, esses quadrinhos da moda Scrum não é prática do Scrum)
- Ciclo Trimestral (sim, se você leu o livro do Ken, note que ele não fala sobre planejamento de release, dá zero para ele)
- Folga (equipes Scrum não precisam disso, são Chuck Norris por natureza)
- Histórias (opa, mais uma prática de Gestão do XP, noooooosa, stories não é do Scrum?)
- Sentar-se Junto (será que os POs ficam o tempo todo com a equipe?)
- Trabalho Energizado (prática de Gestão).
É falácia. O Scrum define sim práticas de engenharia. Leia o livro do Ken. O papel do ScrumMaster é promover boas práticas de engenharia. O pedaço de funcionalidade potencialmente implantável é uma prática de engenharia, e uma das mais difíceis.
Estude melhor o XP. XP menos Scrum não fica só práticas de engenharia como provado acima. Isso é falácia de Scrummeiro. Os tópicos que coloquei acima não estão no Scrum e pode ter certeza que ritmo sustentável, sentar-se junto, coragem e humanismo mudam mais a gestão do que as coisas do Scrum. Sim, o Scrum tem o mérito de ser mais simples, mas o humanismo do XP é algo que muda a gestão completamente. XP não fere o humanismo em detrimento a performance.
[quote=sergiotaborda]A diferença é XP é extremo , num esquema de tudo ou nada. ou faz pair programing toda a hora ou não é XP. Este tipo de pensamento está em decaimento e XP , hoje em dia, resume-se a um conjunto de práticas de engenharia que junto com scrum.
[/quote]
Fontes por favor? Artigo, pesquisa? Quem disse que está em decaimento?
[quote=sergiotaborda]Em uma empresa real, ou se faz isso, ou nunca se mudará nada.
Você não conseguirá convencer os gerentes de forma racional. Eles têm que sentir que XP/Scrum é melhor que o método atual.
Eles têm que sentir que não vão perder o emprego , que não vão perder o salário de “gerente” (eles pensam que num ambiente assim o gerente é dispensável e por isso eles têm medo de mudar). Vc não pode argumentar contra o medo. Não funciona.
[/quote]
Mais uma vez, cases por favor? Quais empresas você tentou isso e não deu certo? Qual a sua experiência? Engraçado, meus melhores argumentos são contra o medo…
Sergio, Sergio. Isso aconteceu num cliente meu. A Synchro. Antes relutantes e depois confiantes, e isso com um treinamento de 8 horas. O mais engraçado de tudo isso é que este cliente que estou atuando agora é uma das maiores seguradoras do país com faturamento de 8 bilhões de reais, o Agile lá vai escalar para 300 devs e convencí eles em uma palestra de 2 horas. Na semana passada ministrei um treinamento de TDD e XP na Imagem (img.com.br). Esses caras se convenceram lendo o Débito Técnico. Não é lavagem cerebral, tenho bons argumentos e bons cases, principalmente em clientes ISV e empresas pequenas. Eu sei das dificuldades que esses gestores tem. É bem simples até, mas a decisão é do gestor. A palestra é simplesmente para tirar dúvidas. Concordo que empresas como a minha são involuntariamentes beneficiadas pelo efeito “santo de casa não faz milagre”, por isso recomendei essa estratégia para a Carol.
Pessoal, antes de mais nada, obrigada pela contribuição de todas, foram muito esclarecedores e me ajudaram muito, estou discutindo tudo que vocês passaram com a equipe aqui.
[quote=ViniGodoy]
A diferença entre ser “inspirado” pelo RUP e usar o RUP é a que a carol está sentindo. O RUP não é um processo waterfall, há muitos anos. Muitas empresas confundem adotar UML com implementar o RUP, assim como muitas empresas que fazem stand-up meeting se dizem fazendo Scrum ou XP.[/quote]
Pois é ViniGodoy, exatamente esse o problema, talvez se simplesmente usarmos o RUP da maneira correta já seria um avanço, mas o que acontece é a cascata mesmo, e a burocracia não deixa, o que importa são documentos, documentos e documentos :argh
[quote=rodrigoy]
Carol, não recomendo começar este trabalho sem ter apoio da gerência. Agile não são práticas para simples otimização local. É algo bem mais amplo e envolve a empresa toda. Para se ter uma idéia, o mindset do processo de contratação do cliente que estou atuando agora é o impedimento que estou combatendo para defender a implantação Agile. Logicamente que você tem beneficios em melhorar a comunicacão da equipe e etc… Mas os benefícios serão maiores se todos participarem. Feudos são o pior inimigo para implantações Agile.o
Se você estiver em São Paulo nós da Aspercom podemos fazer uma palestra gratuita. Mas seus caciques tem que participar.[/quote]
Obrigada pela dica, sem dúvida ajudou muito, infelizmente, infelizmente mesmo, estamos no planalto central bem longe de sampa. Mas leio bastante seu blog e tento assimilar para trazer uma solução aqui.
Vou planejar aqui com a equipe uma estratégia para seguirmos em frente, seja de um jeito ou de outro, traçar alguns planos A, B… O que não dá é continuar fazendo software da maneira como é feita :roll:
Obrigada a todos pela atenção e colaboração, foram de grande valia suas experiências.
[quote=rodrigoy]Sergio, você escreve muito. Seja mais direto. Coloque seu ponto de vista sem fazer estripulias. Fica difícil discutir com você como sempre. Só um desabafo.
[/quote]
:lol: não obrigo ninguém a ler.
Não resta não. Os valores de Scrum implicam coragem e simplicidade (Foco).
Esses principios e prática não são do scrum nem do XP. São principios gerais.
Como tal não têm nenhum peso argumentativo para mostrar que XP é mais que scrum + práticas de engenharia.
“promover” e “definir” são coisas diferentes. A posição do scrum e especialmente do ken é “a arte do possivel”. Neste sentido se é possivel trabalhar com boas práticas de engenharia, faça-o. Aliás, sempre que perguntado sobre como/quais são essas práticas ele relega dizendo que deveriamos olhas as práticas do XP (The Enterprise And Scrum).
Promover significa que deve uma boa prática deve ser defendida face a uma má prática ou nenhuma prática. Mas o scrum não define o que é uma “boa prática” da mesma forma que não define o que significa “pronto”. Ele apenas afirma que a equipa deve estabelecer esses conceitos e defendenlos/promovê-los. É bem diferente do XP que explica o que é pair programming e fala que vc deve usá-lo.
Não não é uma prática de engenharia. É uma prática de gestão de projeto. O poder é do product owner não dos desenvolvedores. Em scrum - a apenas em scrum - é uma obrigação dos desenvolvedores ter o produto em modo de deploy no final de cada sprint. Nos outros modelos ageis isso não é obrigatório. É um nice to have e não um must have como no scrum.
Eventualmente a equipa pode deixar o projeto nesse estado a cada final de sprint em xp, mas isso não é uma obrigatoriedade. E não o é ex
Não foi provado nada. Vc nem sequer deu argumentos.
Fontes por favor? Artigo, pesquisa? Quem disse que está em decaimento?
[/quote]
http://www.se-radio.net/podcast/2009-11/episode-150-software-craftsmanship-bob-martin
Ninguem afirmou que está em decaimento, mas se infere isso pelos comentários que as pessoas fazem.
Quando alguem defende que pair programing não deve ser feito todo o tempo e que é muito melhor parear apenas quando necessário
está-se dizendo nas entrelinhas que XP na sua forma “pura” e “absoluta” não é mais necessário. Da minha experiencia e de equipes que vi usar XP na forma pura, não ha realmente ganho em parear toda a hora. Mais pessoas estão vendo isso…
Mais uma vez, cases por favor? Quais empresas você tentou isso e não deu certo?
[/quote]
Não estou em liberdade para dizer os nomes. (procure o meu curriculo e tire sua conclusões dai)
O ponto não é esse. O ponto é: essas pessoas eram gerentes de visão-curta que acham que seu processo waterfall é RUP ?
Essas pessoas já tinha lido algum material sobre agil ao ponto de estarem curiosas em como isso poderia os ajudar ?
Se a sua resposta é sim às duas perguntas então não conta. Estamos falando de pessoas que estão no primeiro grupo e não no segundo.
My point exactly. Se as pessoas já estão convencidas à priori sua palestra não as está convencendo de nada. No máximo está detalhando passos e tirando duvidas. Estamos falando de gerentes que não sabem ler, que não querem ler ou que têm raiva de quem leu. Tlv não seja o universo de gerentes que vc conhece nas sua andanças pelas empresas de 8 bilhões de faturamento, mas são os que eu conheço nas empresas de milhares em faturamento: gerentes que usam a palavra “agil” como chamariz ou para embelezar o seu processo warterfall e não têm sequer noção do que é um valor moral, muito menos um valor agil.
Sim, sim Sérgio… Scrummeiros geralmente dizem que Scrum envolve tudo. Projetos de software e etc… É bastante engraçado pois a literatura base do Scrum que é o livro do Ken SÓ DÁ EXEMPLOS DE PROJETOS DE SOFTWARE. Scrummeiros também seguem o seguinte lema: Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.
Me dê mais detalhes. Aonde Coragem e Simplicidade estão no Scrum? No Foco? Que relação há entre Foco e Coragem? O que você entende por Coragem no XP?
(eu sei que vc vai colocar no Google “courage +xp” e me mandar o primeiro link)
Ter o sistema “deploy ready” é uma prática de gestão? Oras, então Pair Programming é para Foco e assim, seria mais uma prática de gestão do XP para complementar meu argumento. Taí!!! Pair Programming é uma prática de gestão do XP que não tem no Scrum… Se vale dizer que qualquer prática é de gestão fica ainda mais fácil ainda defender meu argumento. Ou será que é o Sérgio Taborda que decide quais práticas são de gestão e quais são de engenharia.
Engraçado, a maioria das pessoas que falam que fazem agile, que implantam agile, que fazem isso e aquilo no mercado nunca estão em liberdade para dizer nomes. Eu acho isso muito estranho. Muito mesmo. Sem fundamentar seu argumento em fatos não dá para continuar a discussão.
Só para reafirmar, SIM, todo o meu trabalho que faço atualmente nesta seguradora partiu de uma palestra que ministrei no ano passado a pedido e um aluno que NÃO ERA GERENTE. Se você não consegue fazer isso eu te recomendo um curso de vendas.
[quote=rodrigoy]Sim, sim Sérgio… Scrummeiros geralmente dizem que Scrum envolve tudo. Projetos de software e etc… É bastante engraçado pois a literatura base do Scrum que é o livro do Ken SÓ DÁ EXEMPLOS DE PROJETOS DE SOFTWARE. Scrummeiros também seguem o seguinte lema: Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.
Me dê mais detalhes. Aonde Coragem e Simplicidade estão no Scrum? No Foco? Que relação há entre Foco e Coragem? O que você entende por Coragem no XP?
(eu sei que vc vai colocar no Google “courage +xp” e me mandar o primeiro link)
[/quote]
Vc não leu o link que mandei ? então leia este http://sergiotaborda.wordpress.com/scrum/valores/
Valores do scrum :
Comprometimento , Foco , Abertura , Respeito, Coragem
Valores do XP (http://en.wikipedia.org/wiki/Extreme_Programming#Values)
Comunicação , Simplicidade, Feedback , Respeito, Coragem
O termo “Abertura” é tradução livre de Openness que é o valor se estar aberto a conversar e a entender o ponto de vista do outro e mostrar o seu. É isso que leva a pendurar burndown charts por ai… vc está aberto a que qualquer pessoa a qualquer momento o interpele sobre aquele gráfico.
Isso é mais que comunicação e mais feedback, é os dois juntos com mais a capacidade de se expor ao escrutinio de pessoas fora do projeto ( outras equipas, outros departamentos, auditorias, etc…)
Se simplicidade não resultado de manter o foco, não sei o que é simplicidade. Tlv vc entenda simplicidade como DRY ou KISS ou faça agora e refatore depois. Eu não entendo assim. XP não invoca o valor de comprometimento e é por isso que não é uma metodologia de gestão.
Acho que vc acabou de mostrar que não conhece Scrum. Coragem é um dos valores básicos. Não teria como vc me perguntar onde coragem está no scrum se vc conhecesse scrum.
Se vc não conhece scrum é inutil vc querer nos convencer do que quer que seja.
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.
“Se o Scrum diz que serve para voar, então, passáros, moscas, aviões e asteroides estão incluídos no Core do Scrum.”
Esta sua frase não diz nada e mostra uma vez mais que vc desconhece o assunto, ou no minimo está apelando para um argumento de ridicularização que tb não abona em nada a sua argumentação.
Não é o Sergio Taborda que decide, mas é o Sergio Taborda que vai lhe explicar a diferença, pois parece que vc não sabe.
Práticas de engenharia têm que ver com o software em si e as técnicas que são usadas para o criar. Elas são válidas e usadas em qualquer mecanismo de gestão de projeto pois elas são independentes de haver um orçamento, um prazo, etc… Elas são comuns a todos aqueles que fazem software seja em que tipo de projeto for e sob qualquer tipo de gestão.
Práticas de gestão são relacionadas a projetos. Elas são independentes do tipo de projeto e do produto que estão sendo feito. Elas se preocupam em manter orçamentos e prazos e expectativas do cliente seja ele quem for.
Um esquema de projeto que apenas tem um release para o cliente não ha demanda para que seja possivel fazer o deploy antes do prazo do release.
Em scrum, embora haja um plano de release, o Product Owner pode decidir , no fim de qualquer sprint, adiantar esse release. Esta prática costa custos e aumenta o prazo util, melhorando as expectativas do cliente. Isto é uma prática de gestão sim. Ela é aplicada em qualquer tipo de produto cujos requisitos possam ser entregues em vários releases, que básicamente são todos os que não seguem um modelo waterfall.
Se vc pagar os custos legais do processo com que irei levar se revelar eu digo. Além do que ninguém o está impedindo de saber. Procure.
Além do mais qual é a diferença se eu lhe disser os nomes ? vc vai lá verificar ? Vc quer forçar um argumento de autoridade do tipo “eu sei porque aconteceu comigo na X e Y”. Qual é a diferença disso para “Eu sei porque aconteceu comigo” ? ou vc confia na minha palavra ou vc não confia. Leh dizer os nomes não muda a sua confiança , e portanto não muda o seu argumento.
O ponto é muito simples: Nem todos os projetos de implantação de agil são sucessos. Alguns falham. Vai-me dizer que é mentira isso ? Convença-nos então que isto não é real. Os mais comums são :
Teams Lacking Authority and Decision-Making Ability - todo o gerente tacanho vai impedir isto por entender que isto é uma forma minar a autoridade dele.
A Culture that Does Not Support Learning - A cultura do gerente e da empresa ( sim porque alguem poderia sobrepor-se ao gerente, mas isso tb não acontee) não aprende. muitos entram no agil porque é buzzword. Porque vende mais dizer que a empresa é Agil. É o mesmo conceito de marketing que dizer que a empresa tem idade média de 30 anos. Agil não é isso. Mas para eles não importa. Marketing não se importa com o que é, apenas com o que vende.
Denial is Embraced Instead of the Brutal Truth- o gerente se nega a tentar entender agil. Se nega a tentar entender porque os desenvolvedores querem mudar para agil. A unica palavra que se houve é “não”.
Este tipo de entraves não dependem da vontade ou skill do envangelista agil e sim do seu poder politico dentro da empresa. Se a ordem vier de cima, para adotar agil, tem que adotar e acabou. Mas isso, é raro.
Tlv vc não tenha conhecido nenhum destes gerentes - provavelmente porque nunca trabalhou numa equipa de desenvolvimento comandada por um - mas eu e muita gente aqui conhece. Vc pode achar que a sua palestra é infalível e espero bem que seja, o problema é que essas pessoas de que falo nunca estariam em uma a menos que a vida delas dependesse disso.
Você vir aqui dizer que basta que a carol mande os gerentes na sua palestra para que tudo vire XP do dia para a noite é no mínimo ingénuo e demonstrativo da sua falta de conhecimento do mercado real visto pelos olhos de quem trabalha todos os dias com desenvolvimento em projetos comandados por gerentes agile-haters.
O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)? Que relação há entre a saída do Ken da SA e a sua autoridade no assunto Scrum? Não há uma relação de identidade entre Ken e Scrum? 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 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?
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?
Sergio, não preciso me justificar sobre meu conhecimento e principalmente minha atuação no mercado. Aliás, não achei seu curriculum em lugar nenhum. Outra sugestão: vamos acalmar os ânimos… desculpe se coloquei algo que te ofendeu. Não vamos partir para ofensas pessoais. Abraços!
[quote=rodrigoy][quote=sergiotaborda]
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.
[/quote]
O Scrum não é o que o Ken Schwaber fala (aka o cara que criou o método)?
[/quote]
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.
Acho que ficou claro que não.
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.
Se é conceituamente incorreta é discutivel. Depende dos seus conceitos.
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.
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…)
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)
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.
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.