XP e "produtos fechados"

ViniGodoy wrote:Sim, nasceu na indústria automobilistica e de consumo, como praticamente todas as práticas de gerência de projeto.

Só um adendo nada a ver, Kanban também foi introduzida na indústria automobilística (na Toyota - inclusive, meu orientador do estágio me contou que existe um livro de Kanban e da Toyota, explicando como a Toyota se tornou uma potência com o auxílio do Kanban).

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

ViniGodoy wrote:Quando me referia a agile, no tópico acima, referia-me a qualquer processo ágil. Pq, embora o agile realmente não possa ser comparado com RUP, pode-se pegar uma metodologia qualquer, como XP, e compara-la.

Cuidado, "processo agil" não existe. Existem "processos baseado em agilidade". Não faz sentido comparar metodologia com conceito. XP, RUP são metodologias, agil é um conceito. A palavra mais certa é "mindset", cuja tradução poderia seria "estado de espirito".

Não é o que vc faz, mas como vc pensa e que valoresl vc segue que definem se é agil ou não.

Agil pode ser comparado apenas a outros "estados de espirito" ,mas nunca a processos ou metodologias.
Claro, podemos comparar metodologias inspiradas em agil como Scrum e XP com aqueles que não são...

É sempre bom lembrar que a premissa que norteia o desenvolvimento ágil: a de que o custo de alteração de software não se eleva muito a medida que o desenvolvimento avança. Note que isso é verdade para a maior parte do desenvolvimento hoje em dia, especialmente o web, onde o deployment tem custo irrisório.

Não sei de onde tiraram isso embora já vi muita gente defender isso : "alterar software é barato, então, viva o refactoring"

Isto é uma asneira. Alterar software não é barato. A prova é simples.
Utilizemos scrum como exemplo. Vc tem o backlog com stories. Cada uma tem um tamanho. Este tamanho é proporcional ao esforço. Dependendo da velocidade da equipa e da equipa em si mesma este tamanho gera um custo.
Quando vc queima o backlog e vai realizando as estorias elas já consumiram esforço e portanto geraram custo.
As historias já feitas não são refeitas. Nunca! Portanto agilidade não é poder ficar alterando o que já está feito

O que acontece é aparecer uma estoria de alteração. Mas esta estoria é nova tem o seu tamanho e esforço proprios
que têm que ser equacionados e posicionados no backlog. Em scrum o tramanho do backlog é fixo, logo, a alteração só será feita de alguma outra coisa não for feita.

Estre trade-off demonstra que alterar software já produzido não é barato. É um pensamento mágico e ingénuo achar que refactoring - que é uma tecnica de desenvolvimento - sai sem impacto na gerencia do projeto.

Agora, em projetos de prateleira, isso pode se verificar apenas até a primeira versão do software. Alguns softwares aqui onde trabalho, por exemplo, são impressos em CDs e distribuídos em mercados e lojas. O que envolve uma complexa cadeia. Uma modificação mais radical, poderia envolver nova impressão de CD, e uma nova ativação da cadeia, o que é um custo significativamente alto.

Vc está confundindo as coisas. quando o software é impresso em CD isso é uma release. O processo iterativo que deu origem a esse release já aconteceu e está terminado. Mas e a proxima release ? Essa ainda está em desenvolvimento. Que quando acabar será impressa em CD de novo.

Vc está confundindo o release com entrega. O Scrum, por exemplo, obriga a uma entrega a cada sprint. Mas o release é só no fim de todos os N sprints previstos para o release. A entrega do sprint é uma demo, que serve para orientar decisões para os proximos sprints e provar que as coisas foram feitas. Mas apenas o release é o software comercializável.

É obvio que vc pode fazer 1 release com um unico sprint, mas na prática isso é embecil.

As coisas pioram se você pensar em updates em locais remotos do Brasil, como o sertão nordestino ou o certas regiões do Amazonas, onde mal chega energia elétrica, quem dirá internet.

A logistica de destribuição não é problema da metodologia de criação. Cabe à empresa encaixar as duas conforme o seu negocio.
A partir do release - o entregável final e comercializável - vc está fora do processo/projeto de desenvolvimento, passou a estar no processo de distribuição. E isso são outros 500.

Eu estou dizendo tudo isto pq vc passa a ideia de que agil não pode ser usado por causa da forma de distribuição. Isso não procede.
Em alguns posts parece que vc acha que agil não pode ser usado em projeto de custo ou prazo fechado. Tb não procede. Aliás melhorar o Time To Market é um dos objetivos que levou ao agil em primeiro lugar.

ViniGodoy wrote:Não foi isso. Disse que o uso do Scrum, por si só, não constitui um processo de desenvolvimento ágil. Você pode ter ciclos de scrum praticamente sem revisão de backlog, ou com uma revisão feita só por pessoal do desenvolvimento, o que seria um processo baseado, mas não ágil.

Se alguém fala que faz isso, isso não é Scrum e NÃO pode ser mencionado que é baseado em Scrum, esse tipo de coisa que matou o RUP e esta puxando scrum/xo pro mesmo buraco.
Esse tipo de customizacão equivocada deve ser eliminada de qualquer comparacão com scrum/xp/lean, porque todo tipo de problema aderente a isso recai sobre os nomes base e não sobre as customizacões.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

Luiz Aguiar wrote:

ViniGodoy wrote:Não foi isso. Disse que o uso do Scrum, por si só, não constitui um processo de desenvolvimento ágil. Você pode ter ciclos de scrum praticamente sem revisão de backlog, ou com uma revisão feita só por pessoal do desenvolvimento, o que seria um processo baseado, mas não ágil.

Se alguém fala que faz isso, isso não é Scrum e NÃO pode ser mencionado que é baseado em Scrum, esse tipo de coisa que matou o RUP e esta puxando scrum/xo pro mesmo buraco.
Esse tipo de customizacão equivocada deve ser eliminada de qualquer comparacão com scrum/xp/lean, porque todo tipo de problema aderente a isso recai sobre os nomes base e não sobre as customizacões.

Customizar Scrum é considerado um equivoco desde quando?

Não misture as coisas, o que matou o RUP não foi sua customização, pelo contrário, foi sua falta de flexibilidade.

Scrum pode sim ser muito util no desenvolvimento não agil.

mochuara wrote:Customizar Scrum é considerado um equivoco desde quando?

Não tem problema nenhum, desde que se saiba muito bem oq esta fazendo, o problema depois é falhas aparecerem e a culpa cair sobre o scrum e não sobre a burrada que alguém fez o customizando.
É muito fácil alguém olhar e falar, eu vou tirar isso, isso e mais isso aqui que eu não gosto ou não acho tão útil, ai fala que usa um scrum que ele customizou, mas não sabe o porque da existência daquelas práticas que ele retirou ou as modificou.

[]s

ViniGodoy wrote:
Sim, nasceu na indústria automobilistica e de consumo, como praticamente todas as práticas de gerência de projeto. Quer uma referência? Que tal o artigo que introduziu o conceito de Scrum:
http://apln-richmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf

Amigo, o artigo cita Scrum, mas pensando no Rugby. Vc leu esse artigo? Ele também diz da Canon, Fuji e mais uma porrada de empresas. Seria muito simplista dizer que Scrum saiu da area automobilistica. Sim o Scrum tem pitada de várias idéias, como Lean o próprio TPS e etc, mas a junção dessas coisas que o Ken e o Sutherland fizeram era puramente para projetos de produtos de software.

mochuara wrote:

Customizar Scrum é considerado um equivoco desde quando?

Lá vamos nós de novo... Me fala UMA customização que você pode fazer no Scrum sem ferir o Scrum.

mochuara wrote:
Não misture as coisas, o que matou o RUP não foi sua customização, pelo contrário, foi sua falta de flexibilidade.

Qual falta de flexibilidade? Fontes desse ponto de vista? O RUP é a metodologia mais flexível que existe. É a mais aberta a customização. Qual é a sua opinião? O que mata o RUP?

mochuara wrote:
Scrum pode sim ser muito util no desenvolvimento não agil.

O que vc quer dizer com isso? O que seria um desenvolvimento não ágil? Cascata? Sem auto-organização? Sem programadores?

mochuara wrote:Scrum pode sim ser muito util no desenvolvimento não agil.

Pode citar um exemplo real?

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

rodrigoy wrote:
Lá vamos nós de novo... Me fala UMA customização que você pode fazer no Scrum sem ferir o Scrum.

Defina o que é "ferir o Scrum" e porque eu deveria me importar com isto.

rodrigoy wrote:
O que vc quer dizer com isso? O que seria um desenvolvimento não ágil? Cascata? Sem auto-organização? Sem programadores?

Desenvolvimento não agil é desenvolvimento cascata. RUP é cascata.

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

mochuara wrote:

Luiz Aguiar wrote:

ViniGodoy wrote:Não foi isso. Disse que o uso do Scrum, por si só, não constitui um processo de desenvolvimento ágil. Você pode ter ciclos de scrum praticamente sem revisão de backlog, ou com uma revisão feita só por pessoal do desenvolvimento, o que seria um processo baseado, mas não ágil.

Se alguém fala que faz isso, isso não é Scrum e NÃO pode ser mencionado que é baseado em Scrum, esse tipo de coisa que matou o RUP e esta puxando scrum/xo pro mesmo buraco.
Esse tipo de customizacão equivocada deve ser eliminada de qualquer comparacão com scrum/xp/lean, porque todo tipo de problema aderente a isso recai sobre os nomes base e não sobre as customizacões.

Customizar Scrum é considerado um equivoco desde quando?

Desde sempre.
Embora seja publicitado que Scrum não é uma metodologia mas um "framework" de metodologia isso não significa que o scrum é customizável.

O Scrum define pontos fixo que são que lhe dá nome. Existem certas obrigações que vc tem que cumprir ou não será scrum que vc está fazendo. Aliás, para diferenciar scrum real desse scrum inventado o pessoal fala de "bom scrum e mau scrum".

Bom scrum é o verdadeiro scrum onde vc segue as regras e obrigações. Por exemplo, scrum exige um PO, um SM e que sejam pessoas diferentes. Não tem sm ? não é scrum. não tem PO ? não é scrum. Além disso vc precisa de um product backlog, um release backlog, sprint baclogs e precisa entregar uma versão pronta do sistema a cada sprint. "pronto" em scrum tem um significado especial.

Mas então, se o scrum é fixo pq se diz que é um "framework" ? onde está a parte extensivel/"customizável" ? Afinal, sem isso, não podemos dizer que é um "framework".

A parte "customizável" está, por exemplo, na definição de Pronto. Na teoria a entrega está pronta se está testada , documentada, implementada e funciona. Mas vc pode tirar o "documentada" se isso não for necessário e o "testada" é relativo. (testado com quanto de corbertura ?) Agora, funcionar e estar implementado é fixo.

Outro ponto "customizável" é a definição de Story Point. Qual é a escala ? o que representa 1 SP ? É uma escala relativa em que 1 SP é o esforço de uma tarefa X ? 1 SP = Dia Ideal ? É a escala de finbonaci ? de quadrados ? outra ?

Além disso o Scrum não força coisas como Pair programing ou valores como compatilhamento de codigo já que isso é metodologia de desenvolvimento e não de gerenciamento do projeto. (para essa parte temos o XP). Se vc documenta , vc precisa documentar o Manual do Usuário. Todos os outros artefactos são opcionais. Quais, como e quando são feitos é opcional.

Agora, essa coisa de "eu pego o que acho legal e digo que uso scrum" é totalmente burrice. Asneira de asno mesmo.

mochuara wrote:
Defina o que é "ferir o Scrum" e porque eu deveria me importar com isto.

O que você comumente customiza no Scrum?

[

mochuara wrote:
Desenvolvimento não agil é desenvolvimento cascata. RUP é cascata.

Bem, por mim a thread termina aqui... vc demonstrou completo desconhecimento do assunto. Boa sorte.

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:
Desde sempre.
Embora seja publicitado que Scrum não é uma metodologia mas um "framework" de metodologia isso não significa que o scrum é customizável.

Voce esta partindo do pressuposto que o objetivo de uma customizacao seria obter outro scrum como resultado. Mas pra mim uma definicao clara de Scrum é apenas uma conveniência, não o 11o mandamento a ser seguido.

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

mochuara wrote:

sergiotaborda wrote:
Desde sempre.
Embora seja publicitado que Scrum não é uma metodologia mas um "framework" de metodologia isso não significa que o scrum é customizável.

Voce esta partindo do pressuposto que o objetivo de uma customizacao seria obter outro scrum como resultado. Mas pra mim uma definicao clara de Scrum é apenas uma conveniência, não o 11o mandamento a ser seguido.

Bom, o que posso dizer é que vc está enganado. Scrum não define por conveniência, ele define por muito boas razões, as quais se derivam dos conceitos ageis. Elas sim são o 11º mandamento. Ou vc segue, ou vc esquece. Não tem meio termo.

É muito simples.
(vc tem margem para definir algumas constantes, mas não a equação nem as variáveis)

GUJ Master Membro desde: 20/05/2009 11:21:32 Mensagens: 1776 Offline

sergiotaborda wrote:

mochuara wrote:

sergiotaborda wrote:
Desde sempre.
Embora seja publicitado que Scrum não é uma metodologia mas um "framework" de metodologia isso não significa que o scrum é customizável.

Voce esta partindo do pressuposto que o objetivo de uma customizacao seria obter outro scrum como resultado. Mas pra mim uma definicao clara de Scrum é apenas uma conveniência, não o 11o mandamento a ser seguido.

Bom, o que posso dizer é que vc está enganado. Scrum não define por conveniência, ele define por muito boas razões, as quais se derivam dos conceitos ageis. Elas sim são o 11º mandamento. Ou vc segue, ou vc esquece. Não tem meio termo.

É muito simples.
(vc tem margem para definir algumas constantes, mas não a equação nem as variáveis)

Eu não falei que Scrum define por conveniencia, eu falei que o praticante deve ter a definição clara de Scrum como uma conveniência, a não ser claro que vc seja um evangelista desesperado.

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

mochuara wrote:

sergiotaborda wrote:

mochuara wrote:

sergiotaborda wrote:
Desde sempre.
Embora seja publicitado que Scrum não é uma metodologia mas um "framework" de metodologia isso não significa que o scrum é customizável.

Voce esta partindo do pressuposto que o objetivo de uma customizacao seria obter outro scrum como resultado. Mas pra mim uma definicao clara de Scrum é apenas uma conveniência, não o 11o mandamento a ser seguido.

Bom, o que posso dizer é que vc está enganado. Scrum não define por conveniência, ele define por muito boas razões, as quais se derivam dos conceitos ageis. Elas sim são o 11º mandamento. Ou vc segue, ou vc esquece. Não tem meio termo.

É muito simples.
(vc tem margem para definir algumas constantes, mas não a equação nem as variáveis)

Eu não falei que Scrum define por conveniencia, eu falei que o praticante deve ter a definição clara de Scrum como uma conveniência, a não ser claro que vc seja um evangelista desesperado.

Então, esse é o problema das pessoas de hoje em dia, principalmente no Brasil. Demasiado permissivismo.
Se vc vai seguir uma metodologia porque vc quer mudá-la ou seguir apenas parte dela ou utilizar que vc acha legal e não o resto ?
Isso é simplesmente um tipo de preguiça. Ou vc é honesto consigo mesmo e com os outros e segue tudo, ou vc não segue nada.
Ou vc inventar uma coisa qq , mas não diz que é scrum.

Regras são para se seguir. Scrum é um conjunto de regras.
Se vc quer seguir as regras, siga-as todas! Se vc não quer seguir alguma, não siga nenhuma.
Qualquer coisa no meio é reserva mental.

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