A minha dúvida é sobre a aplicação de XP no desenvolvimento de “produtos fechados”, como um jogo, uma suite de escritório, um ERP, etc. Nesses casos, os requisitos mudam com menos freqüência do que em “projetos abertos”. Sendo assim, eu pergunto, faz sentido aplicar XP (ou outras metodologias ágeis) nesse tipo de desenvolvimento ? Alguém passou por essa experiência e poderia compartilhar ?
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 ?
[quote=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 ?
[/quote]
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.
[quote]
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 ? [/quote]
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.
[quote=sergiotaborda][quote=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 ?
[/quote]
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.
[/quote]
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 ?
[quote=rmendes08][quote=sergiotaborda][quote=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 ?
[/quote]
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.
[/quote]
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 ?
[/quote]
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.
[quote=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.
[/quote]
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.[/quote]
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).
[quote=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.
[/quote]
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.[/quote]
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