"Metodologias" para desenvolvimento de software OO

Qualquer projeto que tenha fase de analise, fase de projeto, fase de etc. é waterfall, e está algumas décadas no passado. Procure uma metodologia iterativa e ágil de desenvolvimento, recomendo Scrum.

aproveite essa reestruturação e “de uma chance” para a dupla SCRUM + XP

Eu ainda não vi bons cases de XP na prática, vi algumas aberrações na embratel aqui no Rio que me deixaram um pouco traumatizado, a galera sempre simplifica muito na hora de implementar …

Já o Scrum ouvi falar dele há umas duas ou três semanas: ouve uma palestra no RioJUG apresentado na Santa Luzia e a gelera que conheço que foi gostou muito, voltou dizendo que ficaram andando em círculos pra demonstrar um conceito lá. Muito bem lembrado. Mas pela descrição que me deram eu havia entendido que esse “processo” ou “metodologia” estava mais preocupado com a gerência e coordenação (me disseram por alto que isso é conseqüencia do excesso de chefes e a burocracia que os processos estão gerando).

Não sei do Scrum, mas o XP não estaria mais para processo não? Tipo o RUP. Na minha cabeça tenho que metodologia é algo menor.

Uso waterfall sem problemas, gosto de pensar que posso voltar pra revisar e melhorar o quê estou escrevendo.

Na prática, vôcê está usando Scrum?

1. A palestrs em questão foi sobre Scrum mas o case da ImproveIT é de XP

2. Até onde eu sei isso de XP na Embratel foi um engodo

3. Pode ser que você se de bem com Waterfall, especialmente para projetos muito pequenos e sem um cliente final, mas a in eficácia do processo no âmbito geral é provada estatisticamente há mais de vinte anos. claro que se dá certo para você pdoe ser o caso de uma exceção (baseado na minha experiência eu sicneramente duvido, mas pode acontecer)

4. Na Globo.com existem departamentos que já trabalham com princípios como iterações curtas, planning game e TDD há mais de seis meses e estão na fase da implantação do Scrum

5. Se você gosta de revisar o que escreve vai gostar ainda mais de abordagens iterativas como RUP, XP e Scrum que fazem isso com disciplina e qualidade

6. XP é mais uma prática de engenharia, Scrum de gerência de projeto. pdoem ser utilizadas em conjunto

É verdade, IMHO, SCRUM é um framework mais dedicado a parte gerencial, enquanto XP tem práticas e valores com um foco maior no desenvolvimento.

Eu acho que se vc procurar, vc vai encontrar ótimos cases de XP na prática. Eu já participei de um projeto usando XP e o resultado foi ótimo.

Mas se a procupação é somente com a gerência, eu acho que SCRUM ou Lean são boas opções.

Na verdade é bem o contrário. Estou procurando por “metodologias” mesmo, “receitas de bolo” para a fase de projeto. Logo no início do processo do MPS BR fui “convidado” para os cursos e comentei com o Zé (meu gerente) que eu conhecia uma metodologia para projeto que eu achava que poderia ser encaixada no nosso processo (a UML Components).

Estava compilando a documentação dessa “metodologia” quando entrei aqui no fórum e vi o artigo sobre o ICONIX, que me chamou bastante a atenção. Daí caiu a ficha: “Woody - é melhor trocar idéias antes de decidir pelo UML Components …”

Nosso processo é (ou será, pois não está 100%) baseado em RUP, com alguns trecos de outros processos (CMMI). O processo como um todo já está bem adiantado, meu gerente têm bastante experiência com tailoring do RUP. Fiquei responsável pela parte da especificação da fase de projeto em si.

Pelo pouco que vi do ICONIX cheguei à conclusão que esse também poderia ser aplicado.

Lean? Nunca ouvi falar, vou pesquisar!

pcalcado:

6) XP é mais uma prática de engenharia, Scrum de gerência de projeto. pdoem ser utilizadas em conjunto

Não existe RUP sem processo iterativo (e não existe processo iterativo de uma iteração só ) então ou você trabalha com ‘fase de análise’ e etc. ou usa RUP (o RUP possui fases mas é um conceito beeeeem diferente).

UML components é uma metodologia de engenharia que pode ser comparada em alguns aspectos com XP, e possui o fim bem específico de produzir arquiteturas CBD, hoje em dia este conceito não anda muito em voga.

CMMI e MPS.BR não são processos, são certificações dadas à processos que obedeçam características específicas. Teoricamente a maioria dos processos, incluindo os baseados em XP, RUP e Scrum, podem obtêr estas certificações.

Minha sugestão:

• Iterações curtas (o quanto depende do ambiente, 15 a 30 dias é ótimo para a maioria dos casos)
• Test-Driven Development
• Planning Game com um backlog único priorizado
• Agile Modeling (veja livro do Scott Ambler)

Só com estas ferramentas simples você já tem um modelo muito eficiente.

TheMask:

Vou rezar para o Vinícius Teles não ler isso. :roll:
Mais detalhes aqui.

Eu discordo do Vinicius neste aspecto. Scrume XP são muito parecidos e altamente compatíveis, mas não são a mesma coisa. Discordo principalmente deste ponto:

Para mim XP e Scrum são baseados nos mesmos princípios e por isso são compatíveis, mas possuem foco completamente diferente. Scrum simplesmente não fala sobre software ou programar, fala sobre resolver problemas (que podem ser de qualquer tipo).

O papel do facilitador (Scrumaster no caso) para mim é fundamentalmente diferente. Minha maior dificuldade como ScrumMaster é ficar fora das decisões técncias, geralmente eu visto o chapéu de coach e Master, o que não é o ideal. Idealmente o ScrumMaster fica fora de qualquer decisão neste sentido. Se eu usasse XP não teria sequer esta questão filosófica.

É como se por fazer um programa OO possuíssemos uma arqutietura de componentes. Ambos se baseiam no mesmo princípio mas possuem focos completamente diferentes.

2 perguntas: nunca viu pessoalmente, ou vc so nao le noticias sobre TI, mesmo?

Outra: o que vc quer dizer com “a galera sempre simplifica muito na hora de implementar”?

pcalcado:

• Iterações curtas (o quanto depende do ambiente, 15 a 30 dias é ótimo para a maioria dos casos)

Apenas para deixar claro, acredito que quando o Phillip fala de 15 à 30 dias, ele quer dizer para você escolher um duração entre 15 à 30 dias. Não é para começar uma iteração que pode terminar dentre 15 ou 30 dias. “timebox” é o conceito.
Acredito que iterações de 1 semana também são uma ótima opção, vai depender do seu ambiente de desenvolvimento…

Saiu um eBook gratuito na InfoQ sobre como uma empresa Sueca estão usando Scrum e XP juntos “Scrum and XP from the Trenches”:

O livro inclui:

• Dicas praticas para a maioria das praticas de Scrum e XP
• Dificuldade tipicas e como foram resolvidas
• Diagramas e fotos ilustrando o dia a a dia do trabalho
• Testando e desenvolvendo guiado por testes
• Escalando e coordenando múltiplas equipes
• Lidando com a resistência de dentro e fora das equipes
• Técnicas de planejamento e estimativa de prazos

Eu adoraria ter iterações de uma semana. Pena que apra botar algo em produção hoje eu preciso de 4 dias de ritual burocrático, daí acabo fazendo de 15, que na verdade de dias úteis ficam uns 5.

Eu gosto de iteracoes de 2 semanas pra times grandes (15+), mas se fazer um deploy requer um bode em cima dum pentagrama rodeado por velas pretas, va la: 15 dias eh bem aceitavel.

Delicado como sempre né? Como você sugerio e pra ser sincero tá difícil. Acho que é essa a idéa do fórum não é? Trocar idéia com gente mais experiente (em algum assunto expecífico).
Nunca vi pessoalmente, pra projetos grandes (projetos com mais de um ano). Citei até um exemplo.

cv:

Outra: o que vc quer dizer com “a galera sempre simplifica muito na hora de implementar”?

Falei m quando disse que usava waterfall. Ultimamente (na empresa em que estou) estou usando “civiranego”, mas usei muito GSMS (EDS) e RUP (Ebt e outra). Usei iterativo. Sry.

pcalcado:

2) Até onde eu sei isso de XP na Embratel foi um engodo

TDD é test driven developemnt certo? agora esse outro, planning game, nunca ouvi falar. Vou pesquisar …

Quanto a abordagem iterativa: realmente gostei - pena que é muito difícil vender sistemas nesse formato. O cliente sempre quer um começo, meio e fim muito bem definido pra justificar pelo que estão pagando, eles contam com apenas uma iteração e o gerente acaba quase sempre repassando isso pro projeto e desenvolvimento em uma única iteração …

Verdade. Ambas certificações já sugerem um formato inicial de trabalho, muito por alto. Quiz dizer que nosso processo irá utilizar um pouco de cada (90% RUP, pelo que conheço do meu gerente).

IMHO, se vc espera conseguir CMMI/MPS.BR pra ter a certificação “Minha empresa é CMMI/MPS.BR nível X” eu diria que você pode adaptar desenvolvimento Ágil com o que essas certificações exigem.

Se você quer mais produtividade, vá pelo desenvolvimento Ágil.

Esses dias um “arquiteto de soluções” da microsoft me falou uma frase interessante… “Obter certificação CMMI é fácil, dobre o custo e triplique o prazo de seus projetos”

Se você for buscar por Lean, vai ver que o primeiro princípio é “Eliminate waste”, que não combina muito bem com o que CMMI/MPS.BR exigem…

Acho que é impressão sua. O cliente geralmente pede uma data de início e uma data de fim, quantas iterações tem no meio não é algo que ele geralmente se importe. Note que tieratividade != Escopo Aberto.

Verdade, mas lembre-se que eu sou arquiteto/desenvolvedor/seilá - como disse antes isso normalmente é definido pelo gerente …

É o que eu quero, mas sabe como é. Vou escrever a proposta e ver o quê dá …

Estou vendo que o Scrum parece ser mais simples do quê imaginei, tem até o standup meeting diário que vi no XP. Vi tambem que ele pode ser combinado com o RUP. Acho que vou ficar com o scrum e “simplificar” a parte de desenvolvimento do ICONIX. Vamos ver, tem chão bagaraio …

E meu gerente quer tudo em 3 semanas (LOL).
Ainda bem que o enrolation tabajara não tem copyright

Gente, desculpem a ignorância, isso é brincadeira né?
What is Scrum?
A variation on Sashimi, an “all-at-once” approach …

Sashimi? Que comparação!!!

além do já citado “SCRUM & XP from trenches” eu aconselho “SCRUM Reference” http://www.contrado.com.au/site/pdf/scrum.pdf e “Scrum et al” http://video.google.com/videoplay?docid=-7230144396191025011

agodinhost:

Sashimi? Que comparação!!!

Sashimi (além de uma iguaria japonesa) é um princípio de processo de conceito bem simples: uma iteração é completa em si.

Pegue um pedaçod e filé de salmão e corte um pedaço. Você tem sashimi. Corte este pedaço em dois. Você tem 2 sashimis e não duas metades de sashimi.

Assim são as iterações e entregas em Scrum. O sistema é um filé de salmão e você aprte ele em pequenos sashimis, nunca entrega meio sashimi, sempre um sashimi, seja qual for o tamanho adotado.

Dá pra fazer uma grana!!! Porquê que vou te vender um sashimi se posso, com o mesmo material, te cobrar 10? 8;

Muitíiiiisimo obrigado!!! Vida social 0, Material pra estudar 10 (sem penalts!)

Muitíiiiisimo obrigado!!! Vida social 0, Material pra estudar 10 (sem penalts!)

Quer ganhar a maratona, mas não quer correr os 42 KM ?

Scrum + FDD

FDD? Aiiiiii, agora é -2 pra minha vida social.
Vou pesquisar esse também.
Valeu

Feature Driven Development certo Luiz?
Realmente nunca ouvi falar.
Você usa?
Achei muito material disponível em http://www.featuredrivendevelopment.com/ mas não achei menção a nenhum case nacional …

http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

agodinhost,

Tenho uma notícia boa e outra ruim. Primeiro a ruim: nunca ví processo prescritivo funcionar direito. Nem mesmo o RUP seguido ao pé da letra funciona. Todos os RUPs que funcionam são customizados. Essas receitinhas de bolo não existem.

Sei que para nossa área parece irresistível tentar controlar como a equipe vai se comportar. As pessoas tem medo quando um caso de uso fica ligeiramente diferente um do outro. Ficam incomodadas quando um diagrama está de um jeito e outro de outro. Esse “medo” é natural, mas o custo para você eliminar esse medo é alto demais!

Já trabalhei em muitos projetos e nesses projetos nenhum teve a dinâmica do processo igual. Os requisitos mudam, as pessoas mudam, a arquitetura muda, a geografia muda. Cada processo é diferente do outro. Para a gestão em geral, eles acham que com o processo as pessoas passam a ser descartáveis. Eles acham que com o processo eles não vão mais precisar reter talentos. É uma motivação errada para se ter um processo.

Vou falar uma coisa muito importante: a maioria das vezes que o gestor covarde diz que quer um processo se você pesquisar a fundo você vai ver que as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste e gerenciar o projeto. O processo de maneira alguma vai suplantar deficiências no skill das pessoas. Não é função do processo ensinar ninguém.

Um processo altamente prescritivo é motivado pelo medo, esse medo vai levar você a montar uma área SQA que vai te custar caro, o medo vai levar você ao vício do controle e você vai precisar de um PMO. O medo vai levar você ao lado negro da força.

Sendo um pouco mais prático SCRUM é uma metodologia que funciona muito bem com processos empíricos. O melhor exemplo de processo empírico que já ví é o post do Phillip acima. Resumindo em miúdos, todo processo de desenvolvimento de software deve ser baseado em INSPEÇÃO e ADAPTAÇÃO. O lado da engenharia pode ser um mix de práticas que você usa como uma caixa de ferramentas. Esse conceito é muito aceito atualmente. Tenho aplicado Casos de Uso, FDD e Domain Modeling para muitos projetos na parte de requisitos.

A notícia boa é que você está no lugar certo para fazer essas perguntas…

Olá

Xiii, até os indianos estão correndo atrás de metodologias ágeis. Vejam Go Agile - The Mantra For Business Success

O negócio é abrir o olho e o blog do Vinicius é um excelente ponto de partida. Vejam as entrevistas de gente que implantou ISO, MPS.BR e CMMI e que hoje trabalha com SCRUM em http://blog.improveit.com.br/

[]s
Luca

Concordo com a maior parte do que vc disse, mas discordo quando vc afirma que “as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste”.

9 de cada 10 projetos afundam por incompetência GERENCIAL e não por incompetência técnica.

A incompetência técnica também é gerencial. Se as equipes não sabem desempenhar o trabalho é culpa do gestor.

Acho que coloquei minha frase de uma maneira errada. Você já trabalhou em alguns lugares onde tudo que dá errado as pessoas botam a culpa na falta de processos? Nesse cenário geralmente o problema é a falta de treinamento e não falta de processos.

“Treinamento” é pra onde se mandam cachorros, não é?

Assino embaixo. Embora seja um tanto quanto difícil selecionar as pessoas com este perfil (sem falar em encontrá-las!!)

É vc contra treinamento? Essas pessoas que não são autodidata fazem o que? Cortam os pulsos?!?!

Fui propositalmente exagerado, como deve ter sido possível perceber.

É claro que há nichos e nichos, em qualquer área. Mesmo quando se fala de desenvolvimento, há uma gama de funções cujo perfil ideal é bastante variado.

No entanto, quando se trata de projetos de alta tecnologia, onde os paradigmas mudam dia a dia, o perfil da equipe é determinante para o sucesso ou fracasso. E ser auto-didata é uma das características mais desejáveis nesse perfil. Acredito que não haja treinamento que mude isso (mas aí já entramos num campo antropológico demais pra prosseguir).

Pessoalmente, acho que cortar os pulsos é uma solução um tanto quanto dramática. Sugiro tentar buscar outra área, onde ser auto-didata não seja um requisito tão presente e forte.

[]s
-bruno

Muitas pessoas participam de projetos tanto para o bem ou para o mal:

http://www.everything2.com/index.pl?node_id=685346

Não creio que não ser auto-didata seja uma restrição muito grande. Realmente não existe treinamento para que uma pessoa seja auto-didata, mas se o seu projeto vai ser desenvolvido no Jboss Seam você que é auto-didata pode aprender a tecnologia em 3 dias e fazer um treinamento para as outras pessoas que não são auto-didata.

Talvez uma dessas pessoas seja um code hose que depois que aprender o Seam vai implementar 3 casos de uso por dia, enquanto você só implementará 1.

Alguém possui este arquivo (e os outros que estavam neste site)? O site não existe mais e pela descrição parece que o conteúdo é bom…

rodrigoy:

nunca ví processo prescritivo funcionar direito.

rodrigoy:

Sei que para nossa área parece irresistível tentar controlar como a equipe vai se comportar. As pessoas tem medo quando um caso de uso fica ligeiramente diferente um do outro. Ficam incomodadas quando um diagrama está de um jeito e outro de outro. Esse “medo” é natural, mas o custo para você eliminar esse medo é alto demais!

rodrigoy:

Vou falar uma coisa muito importante: a maioria das vezes que o gestor covarde diz que quer um processo se você pesquisar a fundo você vai ver que as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste e gerenciar o projeto. O processo de maneira alguma vai suplantar deficiências no skill das pessoas. Não é função do processo ensinar ninguém.

rodrigoy:

Um processo altamente prescritivo é motivado pelo medo, esse medo vai levar você a montar uma área SQA que vai te custar caro, o medo vai levar você ao vício do controle e você vai precisar de um PMO. O medo vai levar você ao lado negro da força.

Tks

Tks, foi pros meus favoritos.

+1 estrelinha!!

Taz:

Concordo com a maior parte do que vc disse, mas discordo quando vc afirma que “as pessoas da equipe não sabem levantar requisitos, eleger uma arquitetura, programar OO, definir estratégia de teste”.

9 de cada 10 projetos afundam por incompetência GERENCIAL e não por incompetência técnica.

Pode até ser incopetência gerencial, mas trabalhamos em time não é? quer dizer que se o projeto afunda a culpa toda é do gerente? putz, me lembre de nunca ser seu gerente!!!
Lembre que o gerente vive re-negociando os prazos que nem sempre conseguimos cumprir (lembra daquele requisito que vc disse que fazia em 3 dias???)
E o coitado acaba sendo obrigado a acreditar naquele mané que ficou o dia inteiro acessando internet …

rodrigoy:

É vc contra treinamento? Essas pessoas que não são autodidata fazem o que? Cortam os pulsos?!?!

bzanchet:

No entanto, quando se trata de projetos de alta tecnologia, onde os paradigmas mudam dia a dia, o perfil da equipe é determinante para o sucesso ou fracasso. E ser auto-didata é uma das características mais desejáveis nesse perfil. Acredito que não haja treinamento que mude isso (mas aí já entramos num campo antropológico demais pra prosseguir).

rodrigoy:

Não creio que não ser auto-didata seja uma restrição muito grande. Realmente não existe treinamento para que uma pessoa seja auto-didata, mas se o seu projeto vai ser desenvolvido no Jboss Seam você que é auto-didata pode aprender a tecnologia em 3 dias e fazer um treinamento para as outras pessoas que não são auto-didata.

Infelizmente não saímos de fábrica com tecla SAP (e algumas mulheres com mute)

Alguém possui este arquivo (e os outros que estavam neste site)? O site não existe mais e pela descrição parece que o conteúdo é bom…Tb quero, please …

Olá

Agodinhost, seu tópico ficou excelente. Aprendi muito com ele.

Quanto ao PDF, baixe do excelente blog do Mueller e aproveite para ler mais um bocado por lá e ainda visitar outros bons blogs com links lá.

[]s
Luca

Luca:

Agodinhost, seu tópico ficou excelente. Aprendi muito com ele.

Luca:

Quanto ao PDF, baixe do excelente blog do Mueller e aproveite para ler mais um bocado por lá e ainda visitar outros bons blogs com links lá.

Luca:

http://queroseragil.files.wordpress.com/2007/09/scrum.pdf

Olá

Ei 05, não precisa pedir para sair.

Insista, tente dos 2 links. Editei várias vezes a mensagem até que consegui baixar deste link.

[]s
Luca

Estava passeando, como de costume, pela internet quando me deparei com outra metodologia (não é sacanagem okay? por mais que pareça é sério).

Feature-Oriented Domain Analysis (http://gp.uwaterloo.ca/fmp/exampleModels/index.html , último paper listado na página, capítulo 2)

Alguém aqui já usou?

Código Coletivo.

(não vai existir maneira prescritiva de limitar esse risco. DESENVOLVIMENTO DE SOFTWARE = ATIVIDADE SOCIAL INTENSA)

rodrigoy:

Código Coletivo.

rodrigoy:

(não vai existir maneira prescritiva de limitar esse risco. DESENVOLVIMENTO DE SOFTWARE = ATIVIDADE SOCIAL INTENSA)

:lol: :lol: :lol:

Discordo. Isso pra mim é mito. Desenvolvedor em si e no geral não costuma ser anti-social, até porque se o fosse, dificilmente estaria empregado. Creio que as práticas do XP ajudam muito a superar a preguiça e possessividade de alguns desenvolvedores (esse sim é o problema quando se fala de código coletivo).

BiraBoy:

Creio que as práticas do XP ajudam muito a superar a preguiça e possessividade de alguns desenvolvedores (esse sim é o problema quando se fala de código coletivo).

agodinhost:

Luca:

Agodinhost, seu tópico ficou excelente. Aprendi muito com ele.

Valeu!!! Eu também!!!

Luca:

Quanto ao PDF, baixe do excelente blog do Mueller e aproveite para ler mais um bocado por lá e ainda visitar outros bons blogs com links lá.

Gostei!!! +1 estrelinha, foi pro favoritos.

Houve algum problema com o wordpress e ele estava dando o link como “not found”, contudo já está funcionando normalmente

E agradeço o elogio do Luca ao meu blog

Edit: o wordpress este mostrando “not found” novamente, vou hospedar o arquivo em outro lugar e depois eu aviso

Edit2: novo link http://queroseragil.files.wordpress.com/2007/10/scrum_reference.pdf (teimoso, hospedei no mesmo lugar )

Senhores

Sou novo neste forum.
Estou fazendo uma pesquisa e gostaria de saber se vcs poderiam me ajudar.
Quais são as principais diferenças entre XP e Scrum?
Em qual tipo de negócio uma metodologia é melhor que a outra?
Elas são concorrentes ou podem ser unidas pra um melhor resultado no desenvolvimento de um Software?

Abraço

Lincoln Amorim:

Quais são as principais diferenças entre XP e Scrum?

Abraço

Scrum é tipo uma droga pra conter os animos de programadores que cresceram acostumados com a ideia que waterfall é ruim. Funciona assim, as empresas não querem mudar o seu processo antigo mas ao mesmo elas sofrem pressão de programadores para que isso ocorra, então ela contrata alguns evangelistas Scrum certificados (por alguma entidade que surgiu do nada), implementam algumas firulas com nome esquisito que funcionam até certo ponto e pronto. Muito mais simples que mudar de fato o processo original, porque pra isto seria necessário ter developers conhecendo do negócio, e outras coisas igualmente complicadas de implementar na prática.

Lincoln Amorim:

Senhores

Quais são as principais diferenças entre XP e Scrum?
Em qual tipo de negócio uma metodologia é melhor que a outra?
Elas são concorrentes ou podem ser unidas pra um melhor resultado no desenvolvimento de um Software?

Scrum é um processo de gerencia, XP é um processo de desenvolvimento.
Elas podem ser unidas já que tratam de áreas diferentes. Scrum trata do gerenciamento do andamento do projeto,
XP trata de escrever o codigo do software. Scrum pode ser usado fora do âmbito do software, xp não.

XP interfere um pouco na gerencia e tem o conceito de Product Owner como o scrum, mas não tem o conceito de Scrum Master.
Esta interferência deve-se ao fato que uma metodologia agil de desenvolvimento é inutil sem os conceitos de Sprint , Product Owner e Backlog. Então existe um overlaping entre XP e Scrum neste ponto.

uma não é melhor que a outra porque não são comparáveis.

XP inclui práticas como pair programing, repositório partilhado,testes antes do código e todos partilham responsabilidade pela qualidade do codigo. A parte “administrativa” do XP é , na prática, semelhante ao scrum, embora o foco seja outro.

mochuara:

Lincoln Amorim:

Quais são as principais diferenças entre XP e Scrum?

Abraço

Scrum é tipo uma droga pra conter os animos de programadores que cresceram acostumados com a ideia que waterfall é ruim. Funciona assim, as empresas não querem mudar o seu processo antigo mas ao mesmo elas sofrem pressão de programadores para que isso ocorra, então ela contrata alguns evangelistas Scrum certificados (por alguma entidade que surgiu do nada), implementam algumas firulas com nome esquisito que funcionam até certo ponto e pronto. Muito mais simples que mudar de fato o processo original, porque pra isto seria necessário ter developers conhecendo do negócio, e outras coisas igualmente complicadas de implementar na prática.

hauhauhau…

cara, tu eh uma figura… precisamos tomar um (uns) chopps.

Abraço.

Opa, só mandar uma msg quando vier pra esses lados de ca. 8)

Recomendo o site do evento Maré de Agilidade, onde você pode assistir um vídeo de Serge Rehem sobre Scrum em 15 minutos.

http://maredeagilidade.blogspot.com/2009/08/scrum-em-15-minutos.html

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

Se vc esta desenvolvendo customizações de algo pronto acho que Kanbam pode ser util no seu caso.

Mas é o caso de fazer um piloto.

obrigado peczenyj, vou da uma olhada ‘nesse kanban’ rsrs

ragonzato:

… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

O Kanban é 1 framework não intrusimo, ou seja, ele não interfere no seu “atual” Processo de Sofware: vc pode adicioná-lo ao RUP, ou ao Scrum, etc. Porem, creio ser ideal adotar primeiro o trio citado acima e, depois que vc conseguirem assimilar os valores, filosofia do Agile, aí sim adicionar o Kanban, o qual, juntamente c/ o Lean, tem um foco muito forte na melhoria contínua.

ragonzato:

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

Meu Deus que zona heuehuehue

derlon:

ragonzato:

… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

Oi ragonzato, blz?!!
P/ ser sincero, nunca cheguei a (estar numa equipe q) efetivamente a utilizasse na prática, mas eu sou 1 grande fã do FDD. E creio q vc pode conciliar muito bem Scrum+FDD+XP. Assim:
:arrow: Scrum - p/ as equipes pegarem a manha de se auto-gerenciarem/auto-organizarem; ganhar cadência|velocidade; melhorar comunicação/feedback; enfim, inspeção e adptação.
:arrow: FDD: Modelagem na medida certa (nem de mais, nem de menos).
:arrow: XP: TDD, refactoring, excelência técnica, pair-programming (se for o caso), etc.; juntamente c/ Scrum, prega processo Iterativo/Incremental.

O Kanban é 1 framework não intrusimo, ou seja, ele não interfere no seu “atual” Processo de Sofware: vc pode adicioná-lo ao RUP, ou ao Scrum, etc. Porem, creio ser ideal adotar primeiro o trio citado acima e, depois que vc conseguirem assimilar os valores, filosofia do Agile, aí sim adicionar o Kanban, o qual, juntamente c/ o Lean, tem um foco muito forte na melhoria contínua.

Opa, estamos mais ou menos por este caminho. Vamos inserir progressivamente alguns conceitos de Scrum na gerencia de projeto, FDD e TDD para desenvolvimento. Também estamos pensando em passar a usar protótipos para validação de requisitos, alguém utiliza esse método? Mas estou om duvida a respeito da viabilidade (de tempo) de aplicar essa técnica.

Daniel_MV:

ragonzato:

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

Meu Deus que zona heuehuehue

Para você ter uma ideia, chamamos o help-desk de buraco negro, de tanto chamado para correção de bug que tem :S

ragonzato:

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

ragonzato,

Não sei pq, mas essas caracteristicas citadas por vc pareceram bem familiar… por acaso os dois ERPs que vc dá manutenção estão escritos em Superbase e Vb 6 + Transact SQL?

sds

wescleyfcosta:

ragonzato:

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

ragonzato,

Não sei pq, mas essas caracteristicas citadas por vc pareceram bem familiar… por acaso os dois ERPs que vc dá manutenção estão escritos em Superbase e Vb 6 + Transact SQL?

sds

Graças a deus eu não dou manutenção a esses sistemas, entrei na empresa há pouco tempo para trabalhar no projeto de melhoria do processo, e felizmente estamos conseguindo bons resultados. Já definimos um ?novo processo? e estamos com alguns projetos ?pilotos? em andamento

wescleyfcosta:

ragonzato:

Estou em uma situação parecida a do ‘agodinhost’, fui encarregado de ‘coordenar’ o processo de ‘implantação’ do Mps.Br nível G na empresa que trabalho. Porém o meu caso é ainda pior (eu acho), não existe processo algum hoje é caótico total, e além disso a empresa trabalha com produtos ‘prontos’ 2 ERP distintos , mas… os cara do comercial querem vender pra tudo que cliente… resumindo a empresa trabalha quase que exclusivamente a customização desses ERP’s. Estava pensando em “Tentar” a idéia do FDD lá, visto que hoje a empresa faz a ‘divisão’ do trabalho por funcionalidade, mas sem planejamento ou modelagem alguma, é cada desenvolvedor por si!.
Alguém já usou essa metodologia, ou tem algum material para me indicar, ou mesmo sugestão de alguma outra metodologia/combinação. Qualquer sugestão é bem vinda, Obrigado.

ragonzato,

Não sei pq, mas essas caracteristicas citadas por vc pareceram bem familiar… por acaso os dois ERPs que vc dá manutenção estão escritos em Superbase e Vb 6 + Transact SQL?

sds

Quanto aos ERPs… Um deles ‘nasceu’ em Cobol (alguns clientes ainda usam a versão Cobol ate Hoje) depois foi reescrito em Delphi + Firebird. Já o segundo ERP é Delphi + MySqL.

Uma dúvida que tenho, me corrijam se eu estivar errado, mas Refactoring é uma metodologia de desenvolvimento, certo? e ela está diretamente atrelada a uma fase pós-implantação do projeto?

Outra coisa, existe alguma outra metodologia de desenvolvimento para um projeto que já está pronto ou tudo vai ser Refactoring?

Não sei se me expressei bem!

Obrigado.