XP e "produtos fechados"

Veja bem, todos os produtos são abertos. O preço que é fixo.

Um exemplo simples, está ai o jdk 7 não tarda muito. O windows 7 , etc… o produto é o mesmo,mas o que consegue fazer é diferente.
O que ele consegue fazer é chamado de escopo. Na realidade escopo é algo do projeto e não do software em si.

Nenhum software, seja de que tipo for, tem o escopo fechado. Ou seja, o que o software fará e como fará muda constantemente. Mesmo depois de pronta a funcionalidade pode ser reformulada. Isto é natural e é assim mesmo.

Contudo isto não significa que o preço é variável. O preço é fixo.

O escopo inicial , ou seja, aquilo que inicialmente se pensou que o software faria - antes de começar a fazê-lo - tem um tamanho.
Este tamanho tem que ser estimado porque não pode ser mensurado. Esta estimativa de tamanho estabelece o tamanho do projeto.

Exemplo, um jogo tipo mário. O cara estima que todas as features tem , juntas, tamanho 5000 adicona-se 1000 para margem e estabece-se que o tamanho do projeto é 6000. estes 6000 não é dinheiro é tamanho. Mas o tamanho é convertido para custo e este para preço. Tamanho = preço. Mas preço = fixo, logo Tamanho = fixo.

Em 6000 cabem as features iniciais, o escopo inicial. Só que este escopo muda. Irá mudar com 100% de certeza. Então a solução é acomodar as novas features não colocando outras que estavam previstas. substituindo. As features ganham prioridades, as mais prioritárias são as que já se tem a certeza que têm que estar lá.

É como aqueles jarros de areia decorativa. O tamanho do jarro é fixo. as areis de cores vc poe as que quiser. a diferença é que o jarro vc pode esvaziar e começar de novo, no projeto não. O que está feito , está feito, já consumiu recursos ,já diminui dos 6000 originais.

Portanto vc pode sim ter um projeto de custo , preço e prazo fixos usando qq metodologia agil porque todas são baseadas em comunicação e respeito. É isso que vc está fazendo quando negocia vc comunica com o cliente sobre o que entra e não entra e ambos respeitam o tamanho fixo estabelecido no inicio.

uma outra forma é trabalhar com releases. assim vc define que o software como um todo terá N releases. Ou seja, o total das features só estarão na ultima,mas as intermediárias já funcionam e podem ser usadas normalmente. Apenas têm menos features.
Em jogos isto é usado. As famosas expansões. Isto porque é primeiro preciso avaliar se o jogo vai vingar. UM ERP tb. cada modulo é uma release. É tudo uma questão de organização e não de ser aberto ou fechado. O Escopo é sempre aberto e o tamanho (preço) é sempre fechado.

Já esclareceu bastante Sérgio, obrigado. Mais algumas dúvidas:

A partir do que você disse, eu poderia então considerar cada release um projeto certo ?

Como o meu software não é destinado a um cliente, ou seja, ele é vendido para diversos clientes e deve atrair novos. Nesse caso, não é exatamente o cliente, usuário final, que faz o papel do product owner, correto ?

rmendes08:

Já esclareceu bastante Sérgio, obrigado. Mais algumas dúvidas:

A partir do que você disse, eu poderia então considerar cada release um projeto certo ?

Não. O numero de releases, suas datas e seus tamanhos fazem parte do projeto. Outro nome para release é fase.
Um projeto com muitas fases continua sendo um só projeto.

Contudo ha muita margem para negociação aqui. Se o sistema é interno - ou seja, é um produto de "prateleira"
então as decisões sobre o ROI são da propria empresa. ela pode decidir quem embora 3 releses seja, do ponto de vista de marketing, produto, etc…ideal, ela pode decidir depois do primeiro release que o produto não vingou e abordar o resto do projeto.
Para produtos ondemand cada release pode ter o seu contrato proprio sob o guarda-chuva de um contrato para o projeto todo.

Como o meu software não é destinado a um cliente, ou seja, ele é vendido para diversos clientes e deve atrair novos. Nesse caso, não é exatamente o cliente, usuário final, que faz o papel do product owner, correto ?

O cliente da empresa não é o cliente da equipe. O cliente da equipe é o Product Owner. É dele a responsabilidade de descobrir o que os clientes da empresa querem , trabalhar essas ideias, e passar à equipe. Por exemplo, para jogos é comum haver gente apenas para beta-testing ou opinion groups que ficam jogando o jogo no seu estado atual e ficam dando ideias. Existem várias tecnicas de como a equipe de produto pode garimpar informação. Mas isso não é responsabilidade dos desenvolvedores.

Ou seja, não é usuário nem o cliente que faz o papel de PO. É alguem da empresa que tem a capacidade de pesquisar o que os clientes querem. É um esforço conjunto dos departamentos de marketing, produto e pequisa&desenvolvimento. Isso é digerido e com base nisso o PO diz o que tem que ser feito e em que prioridades.

O PO é quem está interessado em vender o software.

sergiotaborda:

rmendes08:

Já esclareceu bastante Sérgio, obrigado. Mais algumas dúvidas:

A partir do que você disse, eu poderia então considerar cada release um projeto certo ?

Não. O numero de releases, suas datas e seus tamanhos fazem parte do projeto. Outro nome para release é fase.
Um projeto com muitas fases continua sendo um só projeto.

Contudo ha muita margem para negociação aqui. Se o sistema é interno - ou seja, é um produto de "prateleira"
então as decisões sobre o ROI são da propria empresa. ela pode decidir quem embora 3 releses seja, do ponto de vista de marketing, produto, etc…ideal, ela pode decidir depois do primeiro release que o produto não vingou e abordar o resto do projeto.
Para produtos ondemand cada release pode ter o seu contrato proprio sob o guarda-chuva de um contrato para o projeto todo.

Bem, no meu caso, tenho um produto de “prateleira”, que se em algum aspecto não atende a uma necessidade do cliente, então ele pode requerir uma customização. No mais, independentemente das customizações, novas funcionalidades são adicionadas a cada release, e não há um ponto exato de parada. Isso não foge àquela definição tradicional de projeto, de que cada projeto deve ter início e fim ? As metodologias ágeis compartilham dessa visão ?

rmendes08:

sergiotaborda:

rmendes08:

Já esclareceu bastante Sérgio, obrigado. Mais algumas dúvidas:

A partir do que você disse, eu poderia então considerar cada release um projeto certo ?

Não. O numero de releases, suas datas e seus tamanhos fazem parte do projeto. Outro nome para release é fase.
Um projeto com muitas fases continua sendo um só projeto.

Contudo ha muita margem para negociação aqui. Se o sistema é interno - ou seja, é um produto de "prateleira"
então as decisões sobre o ROI são da propria empresa. ela pode decidir quem embora 3 releses seja, do ponto de vista de marketing, produto, etc…ideal, ela pode decidir depois do primeiro release que o produto não vingou e abordar o resto do projeto.
Para produtos ondemand cada release pode ter o seu contrato proprio sob o guarda-chuva de um contrato para o projeto todo.

Bem, no meu caso, tenho um produto de “prateleira”, que se em algum aspecto não atende a uma necessidade do cliente, então ele pode requerir uma customização. No mais, independentemente das customizações, novas funcionalidades são adicionadas a cada release, e não há um ponto exato de parada. Isso não foge àquela definição tradicional de projeto, de que cada projeto deve ter início e fim ? As metodologias ágeis compartilham dessa visão ?

Sim, como todo o programa que tb deve ter um principio e fim. Mas isso não significa que não possa haver um loop.

As releases tem várias formas de ser organizadas. O exemplo que dei antes é por motivação de mercado. Outra forma é por tema ou modulos. Aqui cada release é como se vc adicionasse um mini programa no programa original.

O ponto dos releases é o planejamento. Ou seja, tem que estar definido o quê vai entrar e o que não antes de começar. Não é uma questão de “vê o que dá para fazer e joga isso no proximo release”. A ideia de ter releases, ou fases é poder planejar melhor.
Cada relaese deve ter um tema ou seja um motivo macro que justifique a sua existencia. tudo dentro dela diz respeito a isso.
Exemplo comuns são Internacioanlização, Melhor interatividade, Integação com sistemas externos/ disponibilização de mecanismos a sistemas externos, portabilidade e performance. normalmente o tema do primeiro release é : o minimo possivel que causa o máximo de impacto. Isto porque queremos ter o produto na rua o mais depressa possivel, mas sem muita frescura.

As propriedades do projeto são independentes da metodologia. Lembre-se que a metodologia serve para conduzir o projeto , não para definir o projeto.

XP é mais indicado para produtos que qualquer outra metodologia. Vários clientes meus usam XP como a Web Goal, a Crivo, a Fortes. Todas são empresas de produtos que usam Scrum e/ou XP.

O que eu não vejo tanta aplicabilidade é para projetos outsourcing mesmo.

Muito bom, eu precisava de uns cases mesmo. Eu acho que a Millenium é a mais próxima do meu caso.

Não creio que os ganhos com o agile nesse caso serão tão mais fantásticos do que com outra metodologia, como o RUP. O problema de produtos de prateleira é que é muito caro atualiza-los depois que eles são inseridos no mercado, o que reduz drásticamente a aplicabilidade do método ágil.

No caso específico de jogos, a UML ajuda muito no planejamento dos componentes do jogo e suas interações. Não é incomum eles terem que ser retrabalhados durante os ciclos ou terem requisitos de tempo real.

Vale lembrar que mesmo as metologias não ágeis já não são completamente waterfall, e se dividem em ciclos de poucas semanas de desenvolvimento. A maioria já adota o Scrum que, do contrário que o Rodrigoy deu a entender, não é um método ágil, mas uma prática de projeto (surgida inclusive na indústria automobilística).

O problema é que os defensores do ágil hoje vendem a idéia de ágil = iterativo, não ágil = totalmente waterfall. Se isso for verdade, é melhor considerar o RUP também um processo ágil.

O desenvolvimento só se torna ágil ao se adotar um conjunto de práticas e, principalmente, como enfatizou o Sergio, comunicação clara, aberta e contínua com o cliente final. Entretanto, em alguns produtos de prateleira essa comunicação simplesmente não existe. Esse é outro fator que torna o desenvolvimento ágil menos vantajoso, já que seu cliente final será, na verdade, alguém do PM ou, no caso de um jogo, um game designer. Fora que muitas organizações simplesmente não aceitam um desenvolvimento assim tão próximo (ok, é uma idiotice, mas elas podem optar por gastar mal seu dinheiro).

Não é incomum na indústria, haver testes com o usuário final mais próximo do lançamento do produto. Note que nesse caso, os custos de manutenção já serão altos, e podem ser reduzidos com uma carga melhor de projetos e com uma análise mais detalhada de requisitos.

Se vale a pena mesmo ou não, é uma questão de verificar o quão altos esses custos serão, e o quão precisa é sua estimativa sobre o mercado. Se seu produto, embora de prateleira, não constitua um software muito grande, ou seja algo bastante conhecido do mercado, é provável que seja fácil adotar ágil o tempo todo. Se seu produto se tornará muito caro ou de distribuição difícil, ou é algo completamente novo para o mercado, o custo de mante-lo depois pode facilmente pagar o overhead que se tem em metodologias mais formais.

ViniGodoy:

Não creio que os ganhos com o agile nesse caso serão tão mais fantásticos do que com outra metodologia, como o RUP. O problema de produtos de prateleira é que é muito caro atualiza-los depois que eles são inseridos no mercado, o que reduz drásticamente a aplicabilidade do método ágil.

A primeira coisa a entender é que agil não é uma metodologia. Portanto comparar RUP com agile não faz sentido. É como comparar fruta com aqueduto. O aqueduto pode até ter um papel na produção da fruta, mas não é diretamente relacionado.

Segundo, não ha motivo algum, teorico ou prático que impessa a aplicabilidade de um método agil. É impossivel vc encontrar algum
projeto onde agil não possa ser aplicado. Porque agil não é uma meotodologia e sim um conjunto de permissas , de diretivas, elas podem ser aplicadas em qualquer metodologia compativel. Basta escolher uma metodologia que seja compativel tanto com ágil, tanto com os objetivos do projeto.

Terceiro . agil não significa “vai inventando à medida que vai fazendo”. Isso não é ágil, porque não respeita o valor de foco e não respeita o cliente (já que trabalhar assim exige refactoring pesado que é um gasto de tempo que pode ser eliminado facilmente com mais comunicação no inicio).

Quarto . Todo o processo inspirado por ágil se baseia em algum tipo de backlog. Este backlog tem que ser criado antes das iterações de desenvolvimento. Eu acho isto obvio, e scrum deixa isto claro , mas muita gente não sabe disto.
Portanto, aquela fase em que senta com o cliente (PO, whatever) e faz um brainstorm do que irá ser o produto não é iterativa nem pertence na primeira iteração. O que é iterativo é a alteração do backog. Pode acontecer, embora seja improvável, que esse backlog não mude. A diferença de agil é que não se assume que ele não mudará, aliás se assume que ele mudará. Contudo, isso não significa que se deve fazer um esforço para que esse backlog contenha as partes mais essenciais do projeto. Aliás, porque, o backlog é a peça central de todo o planejamento. Isto é muito claro em scrum, que como bem disseste é para gerencia e não para desenvolvimento.

Veja bem, o processo pode ser iterativo sem ser ágil e ágil sem ser iterativo. não ha nada inerente nos principios ageis que force a iteração. Mas, a verdade é que é um corolário da primeira diretiva que diz que :" O software evolui". O primeiro corolário é que ele não evolui continuamente e sim discretamente (em pacotes ) e dai advem a necessidade teorica e prática de considerar iterações.
Portanto, na realidade, depois de analise das coisas, vc descobre que agil tem que ser iterativo, mesmo não havendo anda que diretamente afirma isso. Contudo, o inverso não é verdadeiro. Algo iterativo não é necessáriamente agil, porque para ser agil outros requisitos têm que estar presentes.

O ponto comum (lugar comum?) é que as metodologias ad doc usadas por ai, as chamadas “tradicionais” no sentido que são as tradicionalmente usadas, são realmente waterfall. A prova é que todas acabam quando o software é entregue. Num processo iterativo, a entregua do software é apenas um passo, não é o fim. O fim é a extinção do backlog.

Veja bem, agil só pede responsabilidade (commitment) e comunicação. ela não define quem a terá.
O Scrum define o papel do PO (Project Owner, não Project Manager) para isso, mas isso é coisa do scrum. O XP define o “cliente presente” … ou seja, vc precisa definir quem terá a responsabilidade definida pelo mindset agil. É ai que entra a metodologia. Sò ai.

Agora, se vc escolher o cara errado, a culpa não é da metodologia nem do mindset agil, é de quem escolheu errado.
Embora o PO seja uma pessoa só ( decisor) isso não significa que as decisões sejam da cabeça dele. Nada impede de haver pessoas apoiando o PO. É por isso que se tem o departamento de Produto… Se vc não tem um , e desenvolve produto de prateleira, algo está errado na sua organização , não com agil ou com a metodologia. Como vc disse, é uma gastar dinheiro de forma idiota, mas isso vem com a experiencia e a cultura da empresa /equipe e não com a metodologia.

O meu ponto é que organização das equipas, a escolha dos responsáveis, dos testers e até dos desenvolvedores e das estratégias comerciais são problemas da empresa que não se resolvem com metodologias de desenvolvimento ou de gerencia. Embora, se possam resolver também dentro de um mindset agil.

Scrum não é Agil? Scrum surgiu na indústria automobilistica? Fontes por favor?

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.

É 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.

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. 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.

Não é, também, o caso de todo software de prateleira. Veja o caso da Valve, que distribui a maior parte dos updates automaticamente, via Internet.

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.

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

Note que ele não fala em software e, se eu não me engano, foi aplicado por primeiro na Honda.

Faz muito tempo o RUP adota um processo iterativo, e não assume a entrega como fim do projeto. As metodologias essencialmente waterfall já foram extintas, pelo menos na teoria. Veja como referência o livro do Craig Larman, sobre o processo unificado.

Faz muito tempo o RUP adota um processo iterativo, e não assume a entrega como fim do projeto. As metodologias essencialmente waterfall já foram extintas, pelo menos na teoria. Veja como referência o livro do Craig Larman, sobre o processo unificado.

RUP não é uma metodologia tradicional no sentido descrito. Eu estou falando das metodologias que são inventadas nas empresas sob o manto de outra o famoso :" O nosso processo interno é baseado no X" onde X é uma metodologia séria. Este “baseado” é que mata tudo e torna as coisas ad hoc.

Como eu falei antes, ser iterativo não é suficiente para ser considerado ágil. Qualquer UP é em tese iterativo, mas não é em tese agil.
Não ha nada em nenhum UP que se baseie aceitar valores. A aceitação dos valores não é requisito para UPs. Para ágil é. Esta é uma diferença subtil (para mim não é subtil, mas tlv seja para quem lê) ,mas é toda a diferença.

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).

ViniGodoy:

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…

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.

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.

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.

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.

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? :shock:

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.

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

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.

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

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:

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?

Pode citar um exemplo real?

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

rodrigoy:

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.

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? :shock:

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:

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

O que você comumente customiza no Scrum?

[

mochuara:

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

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

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.

mochuara:

sergiotaborda:

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)

sergiotaborda:

mochuara:

sergiotaborda:

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.

mochuara:

sergiotaborda:

mochuara:

sergiotaborda:

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.

mochuara se o Scrum do jeito que é não serve pra vc, use outro coisa, mas não fale jamais que é scrum!

Engraçado. Absolutamente todos os livros de metodologia que eu li, falam que você deve adapta-la as necessidades da sua empresa. Acho que a única exceção à essa regra é o PSP, que o autor foi enfático em recomendar que não se faça nenhuma alteração de prática.

Concordo com o Sérgio apenas no sentido de que a alteração não deve ser feita por preguiça. Antes de reclamar, você deve pelo menos tentar. Mas isso não significa que a metodologia ou o processo vá resolver sua vida, ou que não vá sofrer adaptações.

Se fosse assim, só poderíamos usar o SCRUM para fazer carros, ou na indústria de manufatura. A adaptação é o que promove a evolução de uma metodologia, principalmente quando ela é feita com consciência.

Você é físico, não é? Ou é matemático? Geralmente esse apego a definições vem de pessoas dessas duas áreas. Você realmente não entendeu o que eu quis dizer?
De qualquer forma, mesmo a denominação que usei é comum, muitos autores, inclusive consagrados na área, chamam de “processo ágil” aquela que adota o conceito ágil. Corrigir essa denominação para uma mais purista não invalida o resto da minha argumentação.

ViniGodoy:

Você é físico, não é? Ou é matemático? Geralmente esse apego a definições vem de pessoas dessas duas áreas. Você realmente não entendeu o que eu quis dizer?
De qualquer forma, mesmo a denominação que usei é comum, muitos autores, inclusive consagrados na área, chamam de “processo ágil” aquela que adota o conceito ágil. Corrigir essa denominação para uma mais purista não invalida o resto da minha argumentação.

Não me entenda mal. Não é uma questão se eu entendo ou não o que disseste. Sim, eu entendi o que querias dizer. A questão é chamar a atenção de quem estiver lendo para o detalhe da diferença. Por isso que eu escrevi “cuidado”. Para bom entendedor meia palavra basta,mas como ha pouco entendedores é melhor não economizar palavras.

Eu sou formado em Engenharia Fisica. Não é uma questão de apego. É que fisicos e matemáticos sabem bem o mal que uma definição mal dada ou mal entendida pode causar. É exatamente isso que estou tentando evitar que aconteça.

Veja bem, Scrum não é para desenvolvimento ao contrário de RUP ou XP. Scrum é para gerenciamento de projeto.
Aquilo que o produto é , na realidade, não faz a menor diferença.
Contudo aquilo que o projeto é, não muda. Projeto têm propriedades que são sempre invariantes independentemente do que está sendo o objetivo do projeto. Sempre à prazos, demandas, imprevistos, custos, decisões, impedimentos, planejamento , etc… são estas coisas que são o material do scrum, não codigo. Vc não vê uma linha falando de codigo em nenhum livro de scrum vc ve falar em software, produto, coisas “macro”.

O equivoco é considerar o que “adaptações” significa. Para a maioria das pessoas significa : " é uma plasticina, molde-a como quiser" mas não é isso que significa adpatar o scrum. adpatar o scrum é mais como montar um tripé. Não ha como evitar apoiar os três pés, mas ninguem precisa especificar onde eles têm que ser apoiados. As instruções dizem que no chão, mas nada o impede de apoiar duas pernas no chão e uma sobre a mesa desde que ajuste os tamnhos relativos das varetas.

Ha coisas que vc pode ajustar no tripé , assim como no scrum, e ha coisas que não. Has coisas que se vc mudar, vc deixa de ter um tripe. O mesmo com o scrum.

Saber quais são quais é que destingue quem conhece scrum, de quem não conhece.

A sensação que tenho é que tens uma visão superficial do que é scrum e embora simpatizes com as ideias ainda estás naquele limbo entre comparar com o tradicional, achar que é apenas uma coleção de boas práticas e aceitar que é mais que isso. Scrum é mais que boas práticas. É o conjunto d’ AS práticas.

É dificil vc definir uma metodologia ageis sem certas peças, porque elas são corolários diretos dos valores. Aos olhos desatentos pode parecer tudo a mesma coisa, mas não é. Por exemplo, o objetivo de usar quadros kanban-like no scrum não é organização, é visibilidade. Em scrum não é permitido utilizar apenas uma ferramenta computadorizada de kanban, vc tem que afixar onde todo o mundo veja, porque Visibilidade é um dos valores do scrum. Usar por usar, parece que usar softwares de kanban seriam mais práticos, mas fazer essa “adaptação” é violar o valor da Visibilidade, e é por isso que esse passo não pode ser dado.
Nada o impede de manter um quadro sincronizado com o computador ( ou uma tela lcd onde mostra o quadro kanban que o software gera) mas tem que está visivel. A ideia de “poe num site publico e todo o mundo acessa” tb não é visibilidade.
Este é um exemplo simples de como, embora ingénuamente parecendo que estamos usando uma tecnica antiga, estamos na realidade tornando real a adopção de um valor.

É por isso que para usar scrum vc precisa primeiro aceitas os seus valores.
Sim, é como se fosse meio que uma seita ou um ritual de passagem, mas é exatamente esse passo que parece simples e possivel a qualquer um, que não é simples e distingue os profissionais dos amadores… e dos sanguessugas…

Desconfiei. Eu cursei 2 anos de matemática, e também estava bastante apegado a definições nessa época.

Na verdade, onde eu trabalho usamos o SCRUM à risca.

sergiotaborda:

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.

Aparentemente vc não tem experiência com implantação de práticas/valores/processos (ou seja lá do que vc queira chamar a “agilidade”) em equipes de desenvolvimento.

Vc acha mesmo que consegue implantar Scrum da noite para o dia em uma equipe?

Veja bem, não estou falando de escolher “o que é melhor pra mim” ou de “preguiça de implantar tudo”.

Estou falando de mudança cultural, de mudanças que envolvem pessoas e implantação de novos processos e ferramentas. E mudanças como essas demoram. E são implementadas passo-a-passo.

Taz:

sergiotaborda:

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.

Aparentemente vc não tem experiência com implantação de práticas/valores/processos (ou seja lá do que vc queira chamar a “agilidade”) em equipes de desenvolvimento.

Não sei como deduziu isso …

Quando eu disse que conseguia ?

Veja bem, não estou falando de escolher “o que é melhor pra mim” ou de “preguiça de implantar tudo”.

Estou falando de mudança cultural, de mudanças que envolvem pessoas e implantação de novos processos e ferramentas. E mudanças como essas demoram. E são implementadas passo-a-passo.

E a sua pergunta é ?

sergiotaborda:

E a sua pergunta é ?

Vc não entendeu. Foi uma afirmação.

Vc foi ingênuo ao dizer que ou se usa ou não se usa “agilidade”!!!

Taz:

sergiotaborda:

E a sua pergunta é ?

Vc não entendeu. Foi uma afirmação.

Vc foi ingênuo ao dizer que ou se usa ou não se usa "agilidade"!!!

Mas eu não disse isso. Eu disse que ou vc usa ou vc não usa. Ou seja, ou vc usa scrum corretamente ou vc não está usando scrum.
Não tem como usar meio scrum.

Quando a pessoa/empresa diz que usa scrum, um conjunto de perguntas devem seguir essa afirmação.

• Quem é o scrum master ?
• Quem é o product owner ?
• Como vcs controlam o backlog ?
• Como vcs controlam o sprint log ?
• Qual é data da proxima release ?
• Qual é a velocidade da equipa ?
• Qual é definição de story point que estão usando ?
• Qual é a definição de pronto ?
• quantos story points tem o projeto ? e o sprint atual ? e quantos faltam para o fim do release ?
• onde são feitas as daily scrum meatings ?
• quem participa delas ?
• onde são feitas as demonstrações de final de sprint ?
• quem participa delas ?
• quantas horas extra a equipa está trabalhando ?
• qual é o fator de foco da equipa ?

a lista poderia prosseguir… mas esta já é bem exigente.
Repare que eu não estou perguntando como fazem o scrum, se eles fazem scrum, eu sei como eles fazem e estou perguntando detalhes. Repostas erradas que mostram que não estão usando scrum são

• Quem é o scrum master ? -> Não temos
• Quem é o product owner ? -> Não temos ou é o Scrum master
• Como vcs controlam o backlog ? -> não temos backlog.
• Como vcs controlam o sprint log ? -> não temos sprint log
• Qual é data da proxima release ? -> não sei ou depende de x (onde x é uma justificativa qualquer )
• Qual é a velocidade da equipa ? -> não sei
• Onde afixam os burdown charts ? -> não afixamos, usamos um sofware, não fazemos isso
• Qual é definição de story point que estão usando ? -> foi inventada pelos desnevolvedores, não sei qual é
• Qual é a definição de pronto ? -> não temos uma
• quantos story points tem o projeto ? e o sprint atual ? e quantos faltam para o fim do release ? -> não sei
• onde são feitas as daily scrum meatings ? -> não fazemos
• quem participa delas ? -> (supondo que as fazem esta pergunta é para saber se alguem fora da equipa sm + po + devs tb participa)
• onde são feitas as demonstrações de final de sprint ? -> não fazemos, ou , cada um interessado acessa um servidor central
• quem participa delas ? ( o mesmo que a pergunta do daily meeating)
• quantas horas extra a equipa está trabalhando ? a resposta certa é "nunca fazemos" ou "zero"
• qual é o fator de foco da equipa ? -> não sei ou pior : "o que é isso ?"

é muito fácil detectar se scrum está sendo feito ou não. Scrum é bastante exigente e não tolera "arranjos".
O que estou dizendo é que, ou vc faz tudo o que é exigido pelo scrum, ou vc não pode dizer que está usando scrum, nem que está usando algo baseado em scrum. A unica forma honesta de responder é dizer que está fazendo mau scrum.
Pelo menos assim vc indica que sabe que está errado e sabe o que é certo.

Implantar scrum é um fenomeno cultural, portanto,se as pessoas já tem a cultura certas as práticas são naturais e simples e vc pode começar a usar bom scrum desde o principio. Mas se é demorado implantar (maior parte das vezes é), então os pedacinhos do scrum que vc usa, não o classificam a dizer que está usando scrum. Vc está utilizando uma porcaria qualquer que nem vc sabe o que é. Isso não é agilidade, é enganação. Pura e simples.

sergiotaborda:

Taz:

sergiotaborda:

E a sua pergunta é ?

Vc não entendeu. Foi uma afirmação.

Vc foi ingênuo ao dizer que ou se usa ou não se usa "agilidade"!!!

Mas eu não disse isso. Eu disse que ou vc usa ou vc não usa. Ou seja, ou vc usa scrum corretamente ou vc não está usando scrum.
Não tem como usar meio scrum.

Quando a pessoa/empresa diz que usa scrum, um conjunto de perguntas devem seguir essa afirmação.

• Quem é o scrum master ?
• Quem é o product owner ?
• Como vcs controlam o backlog ?
• Como vcs controlam o sprint log ?
• Qual é data da proxima release ?
• Qual é a velocidade da equipa ?
• Qual é definição de story point que estão usando ?
• Qual é a definição de pronto ?
• quantos story points tem o projeto ? e o sprint atual ? e quantos faltam para o fim do release ?
• onde são feitas as daily scrum meatings ?
• quem participa delas ?
• onde são feitas as demonstrações de final de sprint ?
• quem participa delas ?
• quantas horas extra a equipa está trabalhando ?
• qual é o fator de foco da equipa ?

a lista poderia prosseguir… mas esta já é bem exigente.
Repare que eu não estou perguntando como fazem o scrum, se eles fazem scrum, eu sei como eles fazem e estou perguntando detalhes. Repostas erradas que mostram que não estão usando scrum são

• Quem é o scrum master ? -> Não temos
• Quem é o product owner ? -> Não temos ou é o Scrum master
• Como vcs controlam o backlog ? -> não temos backlog.
• Como vcs controlam o sprint log ? -> não temos sprint log
• Qual é data da proxima release ? -> não sei ou depende de x (onde x é uma justificativa qualquer )
• Qual é a velocidade da equipa ? -> não sei
• Onde afixam os burdown charts ? -> não afixamos, usamos um sofware, não fazemos isso
• Qual é definição de story point que estão usando ? -> foi inventada pelos desnevolvedores, não sei qual é
• Qual é a definição de pronto ? -> não temos uma
• quantos story points tem o projeto ? e o sprint atual ? e quantos faltam para o fim do release ? -> não sei
• onde são feitas as daily scrum meatings ? -> não fazemos
• quem participa delas ? -> (supondo que as fazem esta pergunta é para saber se alguem fora da equipa sm + po + devs tb participa)
• onde são feitas as demonstrações de final de sprint ? -> não fazemos, ou , cada um interessado acessa um servidor central
• quem participa delas ? ( o mesmo que a pergunta do daily meeating)
• quantas horas extra a equipa está trabalhando ? a resposta certa é "nunca fazemos" ou "zero"
• qual é o fator de foco da equipa ? -> não sei ou pior : "o que é isso ?"

é muito fácil detectar se scrum está sendo feito ou não. Scrum é bastante exigente e não tolera "arranjos".
O que estou dizendo é que, ou vc faz tudo o que é exigido pelo scrum, ou vc não pode dizer que está usando scrum, nem que está usando algo baseado em scrum. A unica forma honesta de responder é dizer que está fazendo mau scrum.
Pelo menos assim vc indica que sabe que está errado e sabe o que é certo.

Implantar scrum é um fenomeno cultural, portanto,se as pessoas já tem a cultura certas as práticas são naturais e simples e vc pode começar a usar bom scrum desde o principio. Mas se é demorado implantar (maior parte das vezes é), então os pedacinhos do scrum que vc usa, não o classificam a dizer que está usando scrum. Vc está utilizando uma porcaria qualquer que nem vc sabe o que é. Isso não é agilidade, é enganação. Pura e simples.

Vc continua não entendendo ou não se fazendo de entendido.

Eu desisto… :roll:

Taz:

sergiotaborda:

Implantar scrum é um fenomeno cultural, portanto,se as pessoas já tem a cultura certas as práticas são naturais e simples e vc pode começar a usar bom scrum desde o principio. Mas se é demorado implantar (maior parte das vezes é), então os pedacinhos do scrum que vc usa, não o classificam a dizer que está usando scrum. Vc está utilizando uma porcaria qualquer que nem vc sabe o que é. Isso não é agilidade, é enganação. Pura e simples.

Vc continua não entendendo ou não se fazendo de entendido.

Eu desisto… :roll:

Tlv se vc explicar melhor o que vc quer dizer eu entenda a sua posição…

mochuara:

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

A primeira linha de qualquer definição sobre RUP é que ele é um processo iterativo! De que cartola tirou essa cascata?

Aí começo a concordar com o que o Luiz Aguiar falou, começamos a matar uma metodologia a partir do momento que dizemos que X não é X, quando associamos a ela uma prática que ela abomina.

Você é físico, não é? Ou é matemático? Geralmente esse apego a definições vem de pessoas dessas duas áreas. Você realmente não entendeu o que eu quis dizer?

<piadinha>

Tá explicado?

</piadinha>

Toda empresa tem uma realidade, as vezes não da pra usar uma ou outra coisa do Scrum.

Lembrei duma palestra do Shoes que ele fez num evento da Caelum, ele disse algo mais ou menos assim:
“Customizar uma metodologia pode ser uma coisa boa, mas antes de customizar, experimente a metodologia na sua forma ‘pura’ pra você ter conhecimento suficiente para saber o que se deve customizar ou não”.

Bruno Laturner:

A primeira linha de qualquer definição sobre RUP é que ele é um processo iterativo! De que cartola tirou essa cascata?

Aí começo a concordar com o que o Luiz Aguiar falou, começamos a matar uma metodologia a partir do momento que dizemos que X não é X, quando associamos a ela uma prática que ela abomina.

É o que tenho falado, e que o que tenho observado com muita tristeza em nossa área.

Os livros sobre processos ágeis vendem a falsa idéia de tudo que não se encaixa no seu paradigma é em cascata, lento e penoso. É como uma época atrás, quando os defensores da injeção em dependência levavam a crer que tudo que não envolvesse DI seria penoso, unsafe e pouco flexível.

Acho que o pior local para se procurar referências sobre uma metodologia é estudando material que o concorrente dessa metodologia escreve.

E tenho visto muita gente defender apaixonadamente idéias, sem realmente conhecer processos diferentes daqueles aos quais se empolgaram.

Temos tantos casos de sucesso com RUP, como temos em XP, SCRUM ou qualquer outra metodologia. Isso porque, todas elas tem seus pontos fortes. Admito que o RUP talvez seja um pouco pesado para uma empresa pequena, e uma metodologia mais leve e menos burocrática possa ser mais adequada. Por que ter um processo com tanta documentação, se sua equipe tem no máximo 3 ou 4 indivíduos?

Agora, um processo mais pesado começa a se justificar em equipes maiores, em locais onde o custo de manutenção será muito alto, em desenvolvimento outsourcing e em locais onde o cliente não pode estar tão próximo assim.

Rubem Azenha:

sergiotaborda:

é muito fácil detectar se scrum está sendo feito ou não. Scrum é bastante exigente e não tolera "arranjos".
O que estou dizendo é que, ou vc faz tudo o que é exigido pelo scrum, ou vc não pode dizer que está usando scrum, nem que está usando algo baseado em scrum. A unica forma honesta de responder é dizer que está fazendo mau scrum.
Pelo menos assim vc indica que sabe que está errado e sabe o que é certo.

Implantar scrum é um fenomeno cultural, portanto,se as pessoas já tem a cultura certas as práticas são naturais e simples e vc pode começar a usar bom scrum desde o principio. Mas se é demorado implantar (maior parte das vezes é), então os pedacinhos do scrum que vc usa, não o classificam a dizer que está usando scrum. Vc está utilizando uma porcaria qualquer que nem vc sabe o que é. Isso não é agilidade, é enganação. Pura e simples.

Toda empresa tem uma realidade, as vezes não da pra usar uma ou outra coisa do Scrum.

Lembrei duma palestra do Shoes que ele fez num evento da Caelum, ele disse algo mais ou menos assim:
“Customizar uma metodologia pode ser uma coisa boa, mas antes de customizar, experimente a metodologia na sua forma ‘pura’ pra você ter conhecimento suficiente para saber o que se deve customizar ou não”.

O problema não está em você pegar um pouco de cada metodologia/filosofia e criar a sua (embora isso possa ser desastroso porque quem faz isso normalmente não sabe o que está fazendo). O problema está em que, depois de criar essa coisa hibrida, a batizar com um dos nomes de mercado das metodologias em que se baseou.

Coisas como o cara dizer que faz XP porque usa SVN, ou que usa scrum porque chama o gerente de scrum master. Absolutas asneiras deste tipo é que devem ser evitadas. O problema é que este tipo de asneira é mais comum do que parece e muitas das empreses que se dizem seguidoras da metodologia X , na realidade utilizam um hibrido maluco sem pés nem cabeça que nada tem a haver com a real metodologia X.

A unica coisa que se pede é honestidade. Digam “Usamos uma metodologia com influencia de X e Y” e não “usamos a metologia X”

Por todos os lugares onde passei alguem usa uma metodologia dita ser “baseada em RUP” , ok. Mas o que isso significa é :
Fazemos waterfall com os artefactos do RUP. Não admira que haja uma identificação de waterfall com RUP porque da mesma forma que essas pessoas chamam o seu hibrido waterfall de RUP, muitas pessoas chamaram o RUP de waterfall porque é isso que elas enxergam.

Agora , muita atenção, não se pode dizer que usa uma metodologia baseada em X quando os principios de X foram eliminados.
Ninguem que diz usar um processo baseado em RUP, que não é iterativo, pode afirmar que é baseado em RUP pois a “alma” do RUP não está lá. É este o ponto. Vc pode pegar a prática A,B e C da metologia X, mas se não pegar a “alma” o “core” da metodologia, não pode dizer que usa algo baseado em X. Aqui, no máximo, vc pode dizer “usamos algumas as práticas que se usam em X”

Isso será honesto, mas tb significa que vc não segue nada relevante, afinal de contas. E isso é mau para angariar desenvolvedores e mau para angariar clientes. então as empresas mentem, e mentem tão completamente, que chegam a acreditar na mentira que inventaram.

P.S. não entendi porque ser graduado em Eng Fisica pela univerdade de lisboa é piada, mas tudo bem…

sergiotaborda:

mochuara:

sergiotaborda:

mochuara:

sergiotaborda:

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.

Então descobrir o que funciona evitando a tendência é preguiça, reserva mental? Eu acho que é o contrário.

Scrum pode ser um conjunto de regras ou uma forma de criar coisas, depende de que lado vc se encontra entre teoria e prática.

Bruno Laturner:

mochuara:

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

W… T… F…

A primeira linha de qualquer definição sobre RUP é que ele é um processo iterativo! De que cartola tirou essa cascata?

Aí começo a concordar com o que o Luiz Aguiar falou, começamos a matar uma metodologia a partir do momento que dizemos que X não é X, quando associamos a ela uma prática que ela abomina.

Ser iterativo não é importante mas sim as iterações serem curtas ou longas. Ou vc é agil no que diz respeito a iterações, ou não é agil , que significa algum tipo de waterfall.

Customização é aquilo no qual você muda para não precisar mudar a si mesmo, quando você considera que o que você faz é melhor do que outras coisas, sem qualquer julgamento prévio.

:XD:

T+

Daí você entra no problema de definição, já que longo e curto são conceitos relativos. A iteração do RUP sugerida é de 3 semanas até 2 meses. Isso é longo para você?

(detalhe, não é “no mínimo 3 semanas, no máximo 2 meses”. As iterações no RUP costumam a ter tempo fixo, até para facilitar o controle do projeto)

Discordo. Pra mim, ser iterativo eh mais importante que o tamanho das iteracoes. Mudar o tamanho de iteracoes num projeto eh meramente questao de combinar com o time e tirar alguns obstaculos do caminho. Em compensacao, pegar um time que nao ta acostumado com feedback em ciclos e mudar a mentalidade eh dificil PRA CARALHO.

(http://farm3.static.flickr.com/2339/1873080885_335b59536c_o.jpg para quem nao conhece essa medida)

Daí você entra no problema de definição, já que longo e curto são conceitos relativos. A iteração do RUP sugerida é de 3 semanas até 2 meses. Isso é longo para você?

(detalhe, não é “no mínimo 3 semanas, no máximo 2 meses”. As iterações no RUP costumam a ter tempo fixo, até para facilitar o controle do projeto)

Vc quer uma teoria unificadora ou um processo pra funcionar numa situação específica?

Se vc precisa de 2 meses pra uma iteração então escolha uma metodologia waterfall, como RUP.

Se vc precisa de feedback mais rápido escolha uma metodologia agil. Simples assim.

mochuara:

Vc quer uma teoria unificadora ou um processo pra funcionar numa situação específica?

Se vc precisa de 2 meses pra uma iteração então escolha uma metodologia waterfall, como RUP.

Se vc precisa de feedback mais rápido escolha uma metodologia agil. Simples assim.

Hehehehe… vc não respodeu a pergunta.

Não, não foi isso que perguntei.

Perguntei a partir de quanto tempo você enquadra um projeto ou metodologia como “waterfall”? Afinal, você falou em tempo “longo” e “curto”. São termos relativos, pouco específicos. Fica muito fácil chamar qualquer coisa de “waterfall”, se você não especificar o que é longo.

Por exemplo, usei o RUP com uma iteração de 3 semanas. Isso é um período longo? O processo era realimentado com feedback, como o RUP prega. Por que ele seria um processo waterfall, e não iterativo?

Sim. Porque não existe essa coisa de “descobrir o que funciona”. Isso já foi feito por quem inventou a mecânica.
E o resultado é simples : vc tem que seguir todas as regras, porque senão é que não funciona mesmo.

Não dá para fazer aos poucos. Tem que ser tudo ou nada.

Scrum pode ser um conjunto de regras ou uma forma de criar coisas, depende de que lado vc se encontra entre teoria e prática.

Não. Não depende. Isso é ilusão. Uma coisa criada por quem é preguiçoso.

marcosalex:

sergiotaborda:

Então descobrir o que funciona evitando a tendência é preguiça, reserva mental?

Você está mostrando a SUA opinião.

Isso é uma tautologia. Todo o mundo aqui só dá opiniões. niguem representa oficialmente ,ou extra-oficialmente coisa alguma.
Acho que , daqui para a frente, pode-se abster de escrever o obvio.

Como é que você sabe que é adequado, ou não, se vc não usou ? Arrogância tb é um tipo de preguiça e reserva mental.
Pelo menos vc tem que tentar 1 vez. O problema é que 1 vez é pouco para vc entender o processo.
Mas mesmo assim melhor que já de cara dizer : isto não vou usar.

Quem de vcs acha que é natural “customizar” o scrum, por favor digam-nos que tipo de customizações vc fizeram/usam.
Só para a gente não ficar falando no vazio e no abstrato. Se vc não fizeram nenhuma, I rest my case.

marcosalex:

Sobre iterações curtas e longas, se minhas iterações foram curtas, mesmo usando RUP ou outro processo, eu posso falar que sou ágil? (estou perguntando).

Tamanho não é documento. Agilidade não tem a haver com o tamanho da iteração, mas com o fato de haver comunicação após cada uma. Se vc simplesmente define periodos de tempo, isso é iterativo,mas não é agil. Agil implica em seguir um conjunto de valores, que se traduzem em práticas, mas essas práticas são relacionadas ao “lado humano” e não ao processo, ao calendário ou ao sistema.

RUP é iterativo, mas não estabelece além de qualquer duvida,a necessidade de comunicar. ele meio que parte do principio que as pessoas farão isso, mas não estabelece como, onde , quando, quais são as regras, a frequencia, etc…

Iteratividade não é , per se, agilidade.

Depende.

Voce da mais valor as pessoas e interacoes do que aos processos e ferramentas?
Da mais valor a software funcionando do que documentacao abrangente?
E colaboracao com o cliente do que negociacao contratual?
Eh mais importante pra sua equipe responder a mudancas do que seguir um plano?

Entao, sim.

marcosalex:

sergiotaborda:

Como é que você sabe que é adequado, ou não, se vc não usou ? Arrogância tb é um tipo de preguiça e reserva mental.
Pelo menos vc tem que tentar 1 vez. O problema é que 1 vez é pouco para vc entender o processo.

Bom quer dizer que pra saber se eu vou morrer se saltar de um prédio de 40 andares eu tenho de pular? E mais de uma vez? :lol: :lol:

Sim. Por favor, experimente :twisted:

Se não ha idioma comum como eles comunicam ? O objetivo principal do scrum é comunicação. Sem isso, essas equipa está mal definida. SE eles têm idioma comum e ha compremetimento (outro valor scrum) então as pessoas arranjam um jeito.

A sua linha de argumentação é totalmente descabida e non sense. Vc só quer fomentar a confusão e não está interessado em aprender ou pelo menos entender os contra argumentos. E já não é a primeira vez…

Não é arrogância, é experiencia e conhecimento. Ou sempre que dizer que vc está enganado vc achas as pessoas arrogantes…
Se tá errado, tá errado. Porque eu tenho que arranjar uma forma eufemistica de dizer que vc está errado ?
Este é o problema do Brasil, muita habitação a passada de mão na cabeça.

Voce precisa dar um nome?

Precisa MESMO, desesperadamente, como se a parada nao tendo um nome perdesse a relevancia?

Ok, chame de METODOLOGIA FENOMENAL DO MARCOSALEX.

Pronto.

Eu falei que iteração por si só não é suficiente para definir o que é agile ou waterfall, mas não lembro de ter dito que iterações longas ou curtas são SUFICIENTES pra definir o que é agile ou waterfall (apesar que isto costuma funcionar na maioria das vezes!).

O que quer dizer pra gente com uma iteração de 3 semanas em RUP. Significa que uma especificação funcional foi feita, ou um protótipo executável, seu feedback foi do usuário ou da equipe que vai implementar, ou de testes???

Dificilmente vc consegue uma “iteração ágil” com 3 semanas de RUP.

marcosalex:

sergiotaborda:

A sua linha de argumentação é totalmente descabida e non sense. Vc só quer fomentar a confusão e não está interessado em aprender ou pelo menos entender os contra argumentos. E já não é a primeira vez…

Não é arrogância, é experiencia e conhecimento. Ou sempre que dizer que vc está enganado vc achas as pessoas arrogantes…
Se tá errado, tá errado. Porque eu tenho que arranjar uma forma eufemistica de dizer que vc está errado ?
Este é o problema do Brasil, muita habitação a passada de mão na cabeça.

Claro, claro. Então o que você diz é verdade absoluta e quem discorda de você é non-sense. Parabéns!! heheheh
Só que você muda de opinião mais de uma vez no mesmo tópico e ainda tem dois pesos e duas medidas conforme interessa.

Aos incautos, ingénuos e tapados, pode parecer que tenho vários pesos e medidas. Na realidade estou apenas explicando a mesma coisa de várias formas para ver se as pessoas entendem alguma. Eu não estou explicando para você mas para todos que leêm.

Estou explicando coisas sérias e falando sério sobre um assunto pouco conhecido e muito mal divulgado no Brasil. Se vc não acredita ou não aceita, ou o que eu digo vai contra a sua educação, ego ou religião, o problema não é meu. discuta isso com um professor, psicanalista ou padre.

Se vc tem algo a acrescentar à conversa, por favor, faça-o. Caso contrário, abstenha-se de participar para não nos fazer perder tempo.

Na boa, cara. Arruma uma namorada e desestressa.

Para sua informação eu sou casado. Mas obrigado pelo interesse.

O pior inimigo não sãos stakeholders e clientes mentecaptos que não sabem o que fazer com o dinheiro, nem os diretores e gerentes que não fazem a minima ideia do que é gerenciar produção de software e se baseiam em permissas da industria de linha de montagem … o pior inimigo é a falta de educação e o não reconhecimento de talento. A divulgação de informações erradas ou simplificadas que levam as pessoas menos preparadas acadêmicamente e profissionalmente a entenderem as coisas erradamente. Em cima disso, sendo obrigadas a se virarem por imposição dos citados gerentes e stakeholders acabam levando toda a área de desenvolvimento de software para o lixo.

Quem acha que tudo está bem como está vai ter uma grande surpresa quando o paradigma mudar. Ele vai mudar. Não porque os clientes querem, não porque os gerentes querem, mas porque quem entende o novo paradigma vai filtrar fora quem não entende.
É a seleção natural dos memes, no seu melhor.