[quote=Guerr@]Que se manifeste alguém que se sentiu provocado e já utilizou o Scrum para estimar o preço de um software!!!
[/quote]
Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/
Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.
eu cheguei no melhor caminho, até estranhei, pq eu fiquei em dúvida em alguns pontos sore qual a melhor solução. creio que isso se deve a uma certa falta de experiencia com alguns dos patters propostos, alguns eu só conheço, nunca precisei implemententar nada usando eles.
Enquanto não tiver fontes oficiais e referencias tudo aqui nao passa de falacia, opnioes e pontos de vista e este ultimo o pior, é por causa dele que existem tantas religiões e apenas uma biblia.
Agora vamos a alguns pontos, é possivel estimar com scrum? Bom parece que sim, mas ser possivel é muito diferente de foi criado para ou ainda é uma feature dele. Então me falem, existe um capitulo no guia oficial scrum(se é que existe esse cara) especificamente tratando de tecnicas scrum de fazer estimativas? Se sim, entao parabens, voce esta certo estimar faz parte do escopo do scrum, senão sinto muito, mas os que defendem o contrario estao certos. Ao que me parece a maneira de estimar que voce exemplificou é tipo um framework caseiro que voce ou outra pessoa achou/criou/inventou para se estimar o prazo/preço do produto antes do inicio da criação do mesmo usando os artefados do scrum(Product Backlog??), entao parabens sabemos que voce sabe fazer contas matematicas, mas o scrum nao foi essencialmente criado para tal.
Vamos a uma referencia, Por Ken Schwaber, Maio de 2009:
E olhe que estamos falando aqui de produto final, ao que me pareceu na citação era a versão do sprint.
Ainda no mesmo texto acima:
Baseado na sua técnica de estimar antes de iniciar o runtime, eu teria que ter um backlog do produto completo desde o inicio, o que ja foje tambem do descrito acima que diz que o backlog do produto é dinâmico e se eu nao tenho o detalhamento de cada feature logo de inicio como posso estimar(sua técnica) quantos pontos e sprints vou precisar para terminar o produto final e dar assim um preço/prazo para o cliente?
Em suma, eu com todo meu conhecimento avançado de scrum que aprendi todo neste post e na referencia acima digo: não existe técnica scrum para se estimar o preço e prazo de entrega de um produto, logo de cara antes do inicio de construção do mesmo( o exemplo da licitação), é possivel tentar fazer isto a partir de artefatos scrum(product backlog?) sim, mas não é uma técnica scrum e tambem exigiria que o product backlog estivesse completo desde o inicio e não sofresse alteração, fosse estatico.
LOGO, estou concordando com a MJ, me provem o contrario :?
[edited]
ops demorei tanto pra responder que tiveram varios outros posts, hehe mas nao saiu muito disso, apenas a nova referencia do sergio que vou ler agora.
Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/
Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.
[/quote]
Errr, ou meu ingles esta muito ruim, ou voce acaba de confirmar tudo que eu disse no post anterior, tem certeza que tu leu o que citou acima??
[quote]
I had to admit to Tony that I didn?t know how to use Scrum to address his business. Scrum?s principle is ?the art of the possible,? not ?you give me what I paid for, when you said that you?d deliver it.? For several years after my meeting with Tony, this problem rolled around in my head and just wouldn?t go away, until finally I realized that Scrum had no silver bullet?it had to go about addressing fixed-price, fixed-date contracts exactly the way any other process would, including the defined, heavyweight methodologies. There simply was no way around analyzing the customer?s requirements enough to understand the scope of the problem and designing enough to understand the number and complexity of the architecture and design artifacts. What a terrible realization! This meant adding a waterfall phase to the front of the Scrum methodology that would produce documentation. That was terrible, and what possible benefit could Scrum provide after it had been so corrupted? [/quote]
[edit]
mais um pedaço:
[quote]
The more I thought about it, the more I realized that?even though Scrum couldn?t be used in its entirety?EngageX or any other organization bidding on fixed-price, fixed-date contracts could use Scrum to gain competitive advantage in bidding on fixed-price, fixed-date requests for proposals (RFPs).[/quote]
Ele fala como empresas que trabalham com preços e prazos fixos podem usar o scrum para ganhar competitividade, e NÃO como estimar com o scrum nesta empresas.
É acho que a discussão morreu depois desta.
Acho que morreu mesmo!
Antes de mais nada gostaria de agradecer o Sergio por postar essa referência excelente que eu desconhecia e totalmente pertinente ao assunto discutido.
A primeira questão a ser colocada é que o Scrum não ataca diretamente este ponto. Se isso incomodou Ken Schwaber por um bom tempo, como ele afirma, não é tão obvio assim como estava sendo argumentado aqui no forum…
Ele afirma no texto que neste caso a solução é adicionar uma fase tradicional antes do Scrum, mostrando que sozinho ele não resolve este tipo de problema.
Saudações!!!
O que me atraiu e me fez escrever um artigo nesse formato é que ele faz as pessoas refletirem para tomar uma decisão e não simplesmente lerem para absorver a informação, muitas vezes sem raciocinar em cima do que está sendo falado. É neste “ficar na dúvida” que realmente você acabou adquirindo uma visão mais crítica dos padrões.
Uma coisa que vi, não só nesta discussão, mas na visão de muitos que vendem o Scrum por ai é que ele serve pra tudo. Não é bem assim. Ele pode ser parte de um todo, mas não o todo em si.
Parabéns a todos por esta ótima discussão e esclarecimento.
Existe ai uma situação de sobrevivencia nas questões que são de poder de desenvolvimento sobre gestão de projetos, ao colocar SCRUM como fator de estimar a melhor soluções é perfeitamente cabivel pois o que se busca é a inteligencia aplicada e isso requer o melhor time de desenvolvimento. Na ótica das metodologia tradicionais percebe-se uma forma de equacionalizar o problema ao invés de saber tratar de requisito como uma melhor ciência a produzir a melhor solução, concordo com o ponto de Vista do Sergio Taborda, acho que a revista Mundo Java se adiantou e não buscou melhor concepção sobre outros fatores que implicariam em uma avaliação melhor em conceitos sobre gerencia de projetos.
[quote=fredferrao][quote=sergiotaborda]
[quote=Guerr@]Que se manifeste alguém que se sentiu provocado e já utilizou o Scrum para estimar o preço de um software!!!
[/quote]
Scrum sendo usado em licitações : http://etutorials.org/Microsoft+Products/Agile+Project+Management+with+Scrum/Appendix+D+Fixed-Price+Fixed-Date+Contracts/
Escrito pelo Ken Schwaber (um dos inventores do scrum) citando experiências reais.
[/quote]
Errr, ou meu ingles esta muito ruim, ou voce acaba de confirmar tudo que eu disse no post anterior, tem certeza que tu leu o que citou acima??
[/quote]
Sim. Seu inglês deve estar ruim.
O problema é complexo e o Ken demorou para achar como tirar partido do Scrum nessa situação.
Este livro é de 2004 o que significa que depois disso houve tempo para outros desenvolvimentos.
Além disso o Ken sempre fala que Scrum para ele é a arte do possivel. Isto significa que as tecnicas scrum têm que ser dobradas para se encaixarem nos casos e é isso que o livro todo mostra. A citação é de um apendendice. Leia o livro completo para entender que ha um jogo de cintura associado ao scrum, especialmente fora da zona de conforto : ou seja, fora da teoria, que é o dia a dia das pessoas.
Além disso, embora o Ken tenha sido um dos percursores do Scrum , existem muitas outras pessoas trabalhando nele e com ele. Nesse aspeto as referencias que tenho do Ken são meio atrazas. Você não vê ele falar de fator de foco , por exemplo.
Scrum é uma coisa nova, e ainda ha trabalho sendo desenvolvido. Um outro apendice mostra como Scrum foi adaptado para poder ser compativel com CMMI. É por isso que existe a certificação de scrum master e PO.
O que quero mostrar com isto é que vc não vai encontrar um livro explicando a teoria do scrum com um monte de formulas e peseudo suporte intelectual. Scrum é baseado em pragmatismo empirico que é uma forma totalmente diferente de pensar e atuar. O conceito de definir e aceitar valores antes de tudo o resto supracede qualquer matemática e qualquer hierarquia.
Uma tenica não é válida apenas se existe um livro que a descreva. Ela é válida se ela traz resultados. Se muitas pessoas a usam e a estudam ela começa a aparecer nos livros. Se vocês querem esperar por livros falando o mesmo que estou dizendo o atrazo é vosso. Mas se vocês querem ler os livros de agora e entender o caminho das pedras, ha muita coisa para ler. Começando com
Software Estimation: Demystifying the black art que faz uma abordagem clássica e moderna (agil) do problema de estimar, seguido de Agile Estimating and Planning que demonstra como se fazem estimativas ageis. Este livro não é sobre Scrum especificamente,mas sobre agil em geram. Como a mecanica dos SP e sprints é mais ou menos universal em agil muitas coisas podem ser transferidas diretamente.
O que quero que fique claro é que :
O mundo de desenvolvimento de software sempre foi orfão de uma teoria administrativa cientifica e concreta que se mostrasse válida e util para gerenciar projetos. Lean e Scrum trouxeram isso adotando uma postura empirica em vez de dedutiva e porque é baseado em ciencia verdadeira é uma postura que funciona. Mas como toda a ciencia , ela tem que vencer dogmas e conceitos que historicamente são usados sem justificação. Junte-se a isso o fato de Agil ser baseado em valores - que são coisas morais e não podem ser ensinados - e vc tem uma mistura explosiva. Ou vc odeia scrum ou vc ama scrum. Se vc já usou, vc concerteza ama ou odeia. E isso é porque ele vai diretamente onde doi. Se vc não for um profissional vc não aguenta. A minha sensação é que o Scrum recebe muito desdem porque as pessoas ou têm medo do que ele representa, ou tem preguiça de usar , ou não têm capacidade de o entender embora tenha boas intenções. O livro citado do ken demonstra isso muito bem. E é isso que vejo aqui tb. O meu alerta é apenas para que procurem se informar melhor e saibam crivar o que leêm.
Esse argumento é fraco. RUP tb não foi criado para serem usados pontos de função ou pontos de caso de uso. E mesmo assim as pessoas usam RUP e Pontos de Função juntos.
Não sei onde vc acha que isso contradiz o que eu disse. O backlog sim tem que ser estimado e priorizado. E ha várias tecnicas
para como priorizar o backlog. E sim, essas tecnicas são fora do scrum porque o scrum não vai nesse detalhes ele simplesmente diz: O PO tem que priorizar.
O PO tem que ser virar. O Scrum tb não diz “Equipa estimem usando planning poker” mas é a tecnicas que dá mais certo.
Scrum nunca lhe diz como vc tem que fazer algo, apenas o quê tem que ser feito, quando , porquê e por quem.
É por isso que não fala na metodologia Scrum e sim no processo Scrum
Não. Não teria. Esse é o erro de quem ainda pensa do modo tradicional.
Vc tem que entender que ha duas entidades aqui: O projeto e o software. O projeto e o produto.
VC tem um projeto guiado por uma equipa constituida para realizar um produto. Produto e projeto são coisas separadas.
O product backlog diz respeito ao produto e ele é usado como ferramenta para o projeto. Ele não é o projeto, ele é o produto.
Tome atenção : as estorias do product backlog (PB) dizem respeito ao produto. Todas elas tem tamanhos e por portanto o PB tem um tamanho.
No instante zero o PB tem um tamanho. Uma semana depois tem outro, etc… o tamanho do PB vai mudando no tempo porque :
O tamanho do PB é alterado, mas isso apenas significa que o tamanho do software é alterado. O escopo do software é alterado.
O do projeto não.
Como é isso possivel ? Porque o tamanho do projeto não é o do backlog.
Acho que não prestou atenção no que escrevi no outro post. Vc usa o backlog do software para estimar o tamanho do projeto.
Estimar! Vc joga com um numero base de SP e coloca fatores nele. Os mesmo que vc colocaria numa outra estimativa qq. Riscos, Equipa, Equipamentos, Ambiente, etc…
Uma vez chegado num numero esse numero pertence ao Projeto, não ao software. è por isso que vc pode contratar X SP por Y reais.
Esse X inclui pelo menos um release oficial de X pontos ou menos. ( ou menos, não mais).
Se depois desses X pontos, ainda houver no backlog do software muitas features que valem a pean vc faz outro contrato por mais Z pontos. E assim vai.
Essa coisa que fazer projeto = software é o jeito tradicional e tosco de entender um projeto de software. O projeto de software começa antes do software estar pronto e acaba depois dele estar pronto.
Afinal a distribuição não faz parte da criação, mas faz parte do projeto.
Não ha contradição entre o backlog ser dinamico e o projeto ser constante.
Se o numeto é constante ele pode ser estimado. Tão simples quanto isso. Quer vc acredite ou não.
Tambem estou com o Guerra, cansei…
Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.
Mas enfim cansei.
"Errar é humano, persistir no erro é BURRICE!!"
Humildade
Acrescente essas duas na tua vida e sera mais feliz!
Se o que negociamos na primeira reunião (Sergio, na primeira reunião) é o projeto, e o escopo vai sendo amadurecido durante as reuniões de levantamento (o Alexandre e o Guerra destacaram bem), então o cliente está comprando um projeto que poderá variar grandemente no quesito funcionalidades (assumindo como regra que o prazo final não muda).
Pior, porque irá variar em função da expertize da equipe. Times mais experientes conseguem entregar mais “coisas” implementadas em SPRINTs, Ou seja, depois de contratada a empresa que irá fazer o serviço, só deus sabe o que será entregue no prazo. Pode atender plenamente, mas pode se extender por mais tempo, ao longo dos SPRINTs. Se o cliente decidir pagar mais para continuar o projeto, porque percebe a evolução, o projeto continua.
Bem, neste momento, acho que devo destacar que já presenciei muitas negociações iniciais de projetos, para várias empresas de vários segmentos, e ao menos na minha vivência, digo que o comportamento apresentado pelos negociadores do projeto diz que :
"NÂO È ASSIM QUE FUNCIONA!!!"
O Cliente deseja saber antes de começar quanto vai custar (ele nem sabe o que é Sprint), e deseja tudo o que têm em mente.
Em uma licitação a coisa é pior ainda.
As consultorias costumam preparar documentos de pré-projeto ou documentos de Visão, com várias cláusulas que indicam o que “não é escopo do projeto”, de forma a eliminar possíveis problemas futuros.
Com frequência acontecem realocações de pessoas dentro da empresa, e o sponsor do cliente pode mudar. Se não há documentos muito formais que indicam o que foi combinado e como seria implementado, problemas acontecem.São raros os projetos onde um mesmo time de pessoas (cliente e consultoria) trabalham desde o início até o final.
Ainda, todas as fases de maturação que foram propostas pelas metodologias durante vinte anos, e artefatos que representam os vários aspectos do desenvolvimento (análise estática - diagramas de classes, análises dinâmicas - sequências, estados). São doze artefatos definidos pela UML. Isto tudo deve ter sido um grande devaneio destes loucos, entre eles Jacobon, Booch e Rumbaugh, já que tudo foi reduzido a um conjunto de discussões e anotações em um papel de pão. Acho esta visão até um desrespeito ao que foi criado.
Quem já gerenciou equipes sabe que existem profissionais de mais alto nível, que têm a capacidade de desenhar o projeto em um nível mais alto, utilizando UML por exemplo, e programadores muito bons, mas que não conseguem ter uma visão de mais alto nível do projeto. São raros, mas muito raros mesmo, os que conseguem conversar com o usuário, entender a demanda, rabiscar em um papel o desenho de como vai ficar, de uma forma que o usuário entenda, ter força de persuasão, montar mentalmente quais são os patterns que serão utilizados e ainda sentar e codificar. Este processo demanda tempo de maturação, é a forma como o cérebro humano funciona. Aposto que todos nós já tivemos situações onde mais de 80% do código estava pronto, quando dá um estalo no chuveiro pela manhã, com uma idéia que revoluciona o projeto, mas o que foi feito precisa ser reescrito. Como se lida com isto ?
Vou lembrar uma historinha para vocÊs :
Quando o ASP foi criado (verdade que o PHP surgiu primeiro, mas o usado extensamente foi o ASP), as tecnolgias que dominavam eram programáticas. Perl, CGI, todas elas você tinha que codificar o HTML dentro do código. Era muito difícil. Quando o ASP popularizou, gerou um sucesso monumental. Era fácil criar páginas, tinha uma produtividade dezenas de vezes maior do que as tecnologias anteriores. A prototipação era visual. O que aconteceu depois de alguns anos ?
Se verificou que fazia o programador tender a criar vários códigos, dava pouca manutenção e os projetos travavam. Eu mesmo participei de projetos (graças a deus não programei em ASP) onde se chegou em uma situação que não era mais possível evoluir. Somente depois do fracasso se amadureceu para o modelo MVC para WEb, com Servlets e JSPs, dividindo visual e códigos. Até a própria Microsft modificou seu modelo de construção. Isto levou mais de 5 anos para fracassar.
Resumindo, o SCRUM como conhecemos hoje ainda é muito novo, e portanto existe pouca jurisprudência para sabermos se o modelo se sustenta no futuro. Tenho medo de daqui a alguns anos (e agora ninguém ainda pode afirmar nada nem a favor nem contra) as pessoas sentirem saudades daqueles montes de documentação, com milhares de códigos na mão e meia dúzia de papeis de pão. Torço para que isto não aconteça, e é por isto que disse no meu primeiro email : as pessoas estão ignorando completamente o passado e criando novos modelos. Quem das pessoas da velha guarda (que têm experiência) se rendeu a estas novas metodologias ?
[]s
Glauco Reis
[momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?
Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”
Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem]
Tambem estou com o Guerra, cansei…
Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.
Mas enfim cansei.
"Errar é humano, persistir no erro é BURRICE!!"
Humildade
Acrescente essas duas na tua vida e sera mais feliz![/quote]
Vamos ter base para continuar a conversa, ninguém esta aqui pra ficar sustentando suas ideias , fale de um autor, coloque uma referencia seja mais objetivo.
Acho que morreu mesmo!
[/quote]
Acredito que existe um ponto de vista mais particular do que algo que seja melhor experimental ou convincente, estamos diante de um paradigma ou não estamos aceitando outras informações com melhor receptividade.
Tambem estou com o Guerra, cansei…
Só nao venha enganar os outros com falacias de meu ingles é ruim, a discussao aqui é sobre estimar e texto que voce citou nada fala disto, mass por acaso do destino voce mesmo deu um tiro no proprio pé e acabou com a discussão quando postou a referencia, e todos ja viram, não ha mais o que falar.
Mas enfim cansei.
"Errar é humano, persistir no erro é BURRICE!!"
Humildade
Acrescente essas duas na tua vida e sera mais feliz![/quote]
Vamos ter base para continuar a conversa, ninguém esta aqui pra ficar sustentando suas ideias , fale de um autor, coloque uma referencia seja mais objetivo.[/quote]
:shock: :shock: :shock: Duran???
A UNICA referencia postada foi um tiro no pé, de resto só sobram ideias e opniões próprias, por favor volte a pagina 1 e comece a ler novamente.
E não estou continuando nada, ja foi, The End, That’s All folks, finish.
O que me atraiu e me fez escrever um artigo nesse formato é que ele faz as pessoas refletirem para tomar uma decisão e não simplesmente lerem para absorver a informação, muitas vezes sem raciocinar em cima do que está sendo falado. É neste “ficar na dúvida” que realmente você acabou adquirindo uma visão mais crítica dos padrões.
[/quote]
Sim, isto foi muito legal. Tanto que depois sequi os outros caminhos, pra ter certeza do porquê que as outras solução não eram tão boas, quais os problemas delas, e as causas posteriores. Nota 10 o artigo.
[quote=Thiago Senna][momento-viagem]
Tenho uma teoria viajante - sinceramente acho que o cliente só sabe que ele precisa de um sistema, mas não tem a menor idéia do que automatizar. E nós, bons programadores que somos implementamos o que eles nem sabem direito. Se nós invertessemos o papel, por exemplo - ao invés de querermos o cliente próximo de nós para entendermos o problema dele, que tal enviarmos o especialista em TI para junto deles?
Que tal o seguinte rótulo para a sua consultoria: “Contrate nossa consultoria e colocaremos dois profissionais de TI dentro de sua empresa para fazer um estágio e usar seus fortes conhecimentos em computação para identificar todos os pontos passíveis de automação.”
Hoje mais parece que o cliente é quem tem que entrar no nosso mundo, quando na verdade deveria ser o contrário.[/momento-viagem][/quote]
Não que va fazer estagio, mas sempre que fiz meus sisteminhas próprios, eu sempre fui na empresa do cliente, ver como é feito todo o processo manualmente para entender como a coisa funciona, a partir dai faço minhas anotações e a vou pro escritorio, precisando eu volto la no cliente, sempre fiz assim. Acho importante ver o processo sendo feito manualmente.
Vocês querem que Scrum possa estimar projetos tradicionais ? É isso ? Vcs estão loucos ?
Scrum só pode estimar projetos feitos com Scrum!
Vejamos passo a passo as diferenças:
[quote=glaucoreis]Se o que negociamos na primeira reunião (Sergio, na primeira reunião) é o projeto,
[/quote]
Já começa mal.
Em scrum existem várias reuniões - as que forem necessárias - para que se determine o product backlog inicial.
Isto é feito da primeira reunião se o PO é experiente e o representante do cliente sabe do assunto, mas pode ser mais do que uma.
Geralmente é mais do que uma porque o representante não sabe tudo. Esta fase é semelhante à escrita de um documento de visão pois o Product backlog (PB) é exactamente isso, neste momento. Eu disse, neste momento.
O que se negocia na primeira reunião não é o projeto. Na primeira reunião não se negocia nada. É uma conversa para levantar o propósito do software.
Depois que o PO está satisfeito com PB a bola passa para o outro lado…
Sim, reuniões de levantamento. Essas reuniões levam ao Product Backlog. Mas em nenhuma ha negociação de nada. É recolha de informação. (A menos é claro, que a empresa cobre por esse levantamento.)
O cliente está comprando a implementação de um software. ele não está comprando projetos. É a software house (SH) que cria e gerencia o projeto, porque ele é um caminho para a implementação do software. O cliente está pagando pela criação do software, não pela gerencia do projeto. As funcionalidades que o cliente quer podem mudar a cada reunião com o PO, o ponto é que chegado em um ponto o PO vai interromper a visita ao cliente e visitar a equipa para se preparar para responder ao cliente na proxima reunião.
O que o PO pede à equipa é a estimativa das funcionalidades. Isto é equivalente ao gerente pedir que os desenvolvedores estimem o projeto. Apenas a forma como é feito muda. O objetivo é o mesmo : estimar.
A equipa faz um planning poker ou outra tecnica e chega em numeros. E chega tb numa lista de perguntas para o PO e uma lista de riscos.
Esta estimativa é independente do prazo. São as funcionalidades que estão sendo estimadas. Não o projeto.
Isso não é Scrum. Scrum é determinista. A todo o momento é possivel saber o que vai ser entregue e o que não vai. Mais do que isso acontece uma entrega no fim de cada sprint e não apenas uma no final do projeto. O cliente pode começar a mexer com o software no fim do primeiro sprint.
A duração dos sprints e o numero de sprint até à entrega é fixo. Se não é fixo,não é scrum.
portanto ao longo do periodo de desenvolvimento é verdade que mais features entram no PB tudo é reistimado e tudo é re-priorizado, mas isso não muda uma virgula na quantidade e duração dos sprints.
aquilo que a equipa consegue entregar é sim proporcional à sua experiencia e sim cada equipa tem uma velocidade diferente , ou seja, entrega um numero de pontos diferente. Algumas equipas entram em estado de hiper-produtivdade que significa que a velocidade delas é maior do que seria “temporalmente” possivel. Isto é muito obvio se usar dias ideias como medida de SP.
Repare que em scrum a equipa estima e a equipa faz. O que ela estima é baseado nos mesmos espertise que ela usa para fazer.
é bem diferente do tradicional em quem o funcional espirra um numero calculado e os desenvolvedores sofrem para se encaixar nesse numero. A estimativa scrum não é apenas um numero, é um compromisso.
Pois não funciona. Metodos tradiiconais não funcionam. Existem N autores explicando porquê.
Agora, quantas reuniões dessas que vc assistiu eram de projetos Scrum ? quantos desses projetos scrum eram realmente scrum ?
Na minha vivencia vejo muitas empresas acertarem preços na primeiro reunião. Isso é simplesmente idiota. Empresas que sabem fazer direito não fazem isso.
“começar” é relativo. Em scrum o desenvolvimento começa depois que o projeto foi estimado, avaliada e assinado.
Depois que o PO tem o PB estimado pela equipa ele volta ao cliente e discute os prazos e os custos. O PO precisa entender se está perante um projeto de custo fixo ou de prazo fixo. Conforme isso ele negocia. Não ha preço inicial sem saber o que o cliente quer.
Depois que ha essa conversa o PO faz umas contas simples e dá prazos e custos. O conrato é feito baseado no PB neste momento. ele está estimado em SP e está priorizado. O contrato conta com custos e prazos e com clausulas que colocam o cliente consciente de que está inserido num processo Scrum. São dados poderes ( como adicionar featues no backlog) e são retirados poderes (como alterar prazos). ou ele concorda ou não.
Na prática , uma empresa usando Scrum tem que evangelizar muito como parte do proceso. Mas é algo que se paga a longo prazo.
Na prática tb, a empresa tem que se proteger do cliente porque ele tende a querer paraticar acções tradicionais que vão contra o scrum. O SM e PO tem esta responsabilidade de educar o cliente e proteger a empresa. às vezes eles tb têm que educar a empresa e ai fica complicado. Complicado, não impossivel. Scrum é muito usado in house porque neste cenário não ha clientes na historia, mas sempre existem stakeholders , sejam clientes ou não, e a responsabilidade do PO perante eles é sempre a mesma.
Nada impede isso em scrum. Nada impede que vc coloque o PB num excel e anexo num documento do contrato.
Isso não é scrum. o PO não pode mudar. O SM sim. A equipe sim.
Aliás existem tecnicas para isso.
Contratos são sobre compromissos entre empresas, não entre pessoas.
Contrato é sempre formal. É idiota pensar em fazer software on demand sem contrato.
O ponto é que o contrato não tem que ser assinado no primeiro dia, nem precisa ser um monte de conversa fiada.
Ele pode ser um instrumento de educação e de proteção do scrum.
No fim o cliente só pensa uma coisa : entra dinheiro, sai software. Isto o scrum faz direito. Com sprints de um mês a cada pagamento da parcela do cliente sai uma versão do software. isto os clientes adoram porque eles veêm o dinheiro ser convertido em “coisa”. E mais, eles adoram poder mudar de ideias. Com scrum eles podem. em contratos normais não.
Se vc usa 12 artefactos UML para cada classe, andar, nodo e decisão do projeto a escolha é sua.
Em Scrum vc pode fazer a mesma coisa. Só que esses documentos vão estar prontos no fim.
Em scrum a definição de “pronto” é aberta. Se a sua definição inclui 12 artefactos UML, que seja. So que isso vai
1: aumentar o numero de SP por estoria - a menos que a equipa aumente, o que é ruim
2: vai entregar menos funcionalidades por spritn - o que é ruim, porque alarga o projeto.
Em scrum ninguem proibe vc de usar uml e escrever documentos no word ou no excell. o que scrum proibe é que isso não seja contabilizado. Tem que ser contabilizado. A resposta a “Qual o tamanho em SP de um webservice de login?” depende do conceito de pronto. Se o conceito é : implementado, testado e documentado no manual do usuário, vc tem X pontos. Se é: 12 artefactos de uml, implementado, testado e manual do usuario é Y. Claro que Y > X para uma mesma equipa.
Dizer que scrum é um decrespeito ao pessoal da UML é simplesmente um falso argumento. Primeiro que UML não é documentação, nem é implementação. Segundo que usar scrum não impede usar UML.
Vc está confundindo as coisas. Mostrando que realmente não sabe o que é Scrum. Em scrum os desenvolvedores não falam com o cliente. quem faz isso é o PO e o SM. A equipa é auto-gerenciável com impedimentos sendo removidos pelo SM. Pessoas com formas diferentes de pensar podem trabalhar juntas se lhes for dado o poder de se auto-organizarem. O problema só nasce quando um gerente quer se meter no meio. PO não têm que entender de sistemas nem desenvolvedores de negocio. é para isso que serve o SM,para fazer a ponte. O que tem que acontecer é que o PO confia nos desenvolvedores e vice-versa. Se os desenvolvedores dizem não, é não. Se eles dizem 10 é 10. Comprometimento é o valor mais alto no scrum e ele que mata todos esses problemas que falou.
Isso é mencionado na reunião de daily scrum nessa mesma manhã. se os outros membros da equipa concordarem que realmente vale a pena, o problema é levado pelo SM para o backlog. A equipa estima essa alteração. Na proxima reunião de sprint o PO prioriza essa estoria tecnica. Muito provavelmente ele não vai priorizá-la muito alto. Aqui tudo depende do problema.Se for um problema visivel para o PO que afeta o software ele vai priorizar alto. se for alguma mania do desenvolvedor ele prioriza baixo.
mas pode acontecer que a ideia que o cara teve é relevante apenas em relação a como as coisas estão sendo feitas no codigo. usar um factory em vez de um singleton, usar jms em vez de webservices… algo assim muito particular da implementação morre na daily scrum. É um ajsute de rota da propria equipa de desenvolvimento e não do software como um todo. O SM é essencial para arbitrar a diferença entre uma situação e outra.
Não é culpa do scrum ser bom e as pessas serem atrazados mentais.
Scrum e agil em geral oferece solução para todos os problemas que mencionou. Quem sabe dos problemas e entende agil sabe mudar. Quem não quer ou não sabe fica nessa ilusão que scrum é mais uma coisa do monte.
O ponto é muito simples : ou vc conduz um projeto em scrum ou vc não conduz em scrum. Não ha meio termo.
Se vc conduz vc onsegue estimar. Consegue mais do que isso. Consegue o comprometimento da equipa e do cliente para com o software. E é isso que realmente importa e é isso que realmente está faltando.
Clientes querem software e pagam por software. Software Houses querem projetos e cobram por projetos.
Confundir software e projeto é o erro da metodologias tradicionais. qualquer pessoa com mais de 5 anos no mercado sabe que as metodologias tradicionais não funcionam, são stressantes e fazem as SH perder dinheiro. E sabem tb que as empresas não veêm isso.
Vocês que acham que scrum não permite estimativas ainda estão pensando tradicionalmente, ou seja, o que vc querem dizer é que :“Scrum não oferece as estimativas que estou acustomado a ver”. Pois não. Mas isso não significa que ele não ofereça.
Não se pode esperar que um processo agil funcione da mesma forma que um tradicional. Isso é absurdo. Se fosse assim não seria ágil. Fica patente nos vosso discursos que vcs não sabem relamente o que significa Scrum ou agil. Confundem agil com um monte de interações.
Agil é mais determinista do que vcs acham. Leiam o Agile Estimation and Planing se não entendem porquê.
Ha uma analogia que eu gosto muito mas a maioria não vai entender ,mas aqui fica:
metodos tradiconais são como a fisica classica. Chega-se numa conclusão conhecendo todos os passos do processo. Os resultados são bons mas limitados e não explicam certos fenómenos. metodos ageis são como a fisica quantica. Chega-se numa conclusão sem saber todos os passos. Os resultados são melhores e todos os fenomenos são explicados. Agilidade sobre do mesmo problema que a fisica quantica no inicio do seculo passado. Muitas pessoas não entendem porque não conseguem pensar de forma abstrata sem conhecer todos os passos. Mas isso é limitação das pessoas, não das ideias e conceitos da teoria.
E você tem tido sucesso implementando assim? Pq eu aposto pelo menos nessa idéia!
Veja, sistemas corporativos são sistemas mais complexos que “sisteminhas” e os profissionais de TI se contentam com User Stories e Casos de Uso sem ir colocar a mão na massa pessoalmente. UML, User Stories, Casos de Uso entre outros, na prática, não passam de ferramentas de adivinhação.