[OFF] "Metodologia" eXtreme Go Horse
623 views
Skip to first unread message
Bruno
Mar 28, 2012, 2:44:47 PM3/28/12
to PHP MG
Alguém aí já trabalhou ou trabalha numa empresa (como a qual eu
trabalho) que utiliza a metodologia de gerenciamento de projetos
eXtreme Go Horse? Se já sabem do que estou falando... contém aí o que
acham disso e se há esperanças.
Hein? O quê? Bom deixa eu explicar...
Muitas empresas utilizam ainda o processo unificado (UP), outras nem
isso, e as mais espertas utilizam o SCRUM (mais moderno e menos
burocrático). É claro que há exceções e vou deixar os possíveis
comentários para discutir as polêmicas.
Aqui na empresa onde estou, após uma tentativa frustrada de
implantação do SCRUM, fiquei tentando identificar ao certo qual é a
metodologia (ou variação de alguma outra) nós seguimos e cheguei a
seguinte conclusão: eXtreme Go Horse!
Isso não é uma metodologia exatamente (apesar de alguns discordarem),
mas sim uma "brincadeira" que inventaram para descrever processos
caóticos (avacalhados) por aí. Aqui onde eu trabalho é chamado de
"Cultura da empresa".
Segue a descrição do XGH...
1- Pensou, não é XGH.
XGH não pensa, faz a primeira coisa que vem à mente. Não existe
segunda opção, a única opção é a mais rápida.
2- Existem 3 formas de se resolver um problema, a correta, a errada e
a XGH, que é igual à errada, só que mais rápida.
XGH é mais rápido que qualquer metodologia de desenvolvimento de
software que você conhece (Vide Axioma 14).
3- Quanto mais XGH você faz, mais precisará fazer.
Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas
todos eles serão resolvidos da forma XGH. XGH tende ao infinito.
4- XGH é totalmente reativo.
Os erros só existem quando aparecem.
5- XGH vale tudo, só não vale dar o toba.
Resolveu o problema? Compilou? Commit e era isso.
6- Commit sempre antes de update.
Se der merda, a sua parte estará sempre correta.. e seus colegas que
se fodam.
7- XGH não tem prazo.
Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE
conseguirá implementar TUDO no tempo necessário (nem que isso implique
em acessar o BD por um script malaco).
8- Esteja preparado para pular fora quando o barco começar a afundar?
ou coloque a culpa em alguém ou algo.
Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa,
mais o sistema vira um monstro. O dia que a casa cair, é melhor seu
curriculum estar cadastrado na APInfo, ou ter algo pra colocar a
culpa.
9- Seja autêntico, XGH não respeita padrões.
Escreva o código como você bem entender, se resolver o problema,
commit e era isso.
10- Não existe refactoring, apenas rework.
Se der merda, refaça um XGH rápido que solucione o problema. O dia que
o rework implicar em reescrever a aplicação toda, pule fora, o barco
irá afundar (Vide Axioma .
11- XGH é totalmente anárquico.
A figura de um gerente de projeto é totalmente descartável. Não tem
dono, cada um faz o que quiser na hora que os problemas e requisitos
vão surgindo (Vide Axioma 4).
12- Se iluda sempre com promessas de melhorias.
Colocar TODO no código como uma promessa de melhoria ajuda o
desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É
claro que o refactoring nunca será feito (Vide Axioma 10).
13- XGH é absoluto, não se prende à coisas relativas.
Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais
pense na qualidade e sim no menor tempo que a solução será
implementada, aliás? não pense, faça!
14- XGH é atemporal.
Scrum, XP? tudo isso é modinha. O XGH não se prende às modinhas do
momento, isso é coisa de viado. XGH sempre foi e sempre será usado por
aqueles que desprezam a qualidade.
15- XGH nem sempre é POG.
Muitas POG?s exigem um raciocínio muito elevado, XGH não raciocina
(Vide Axioma 1).
16- Não tente remar contra a maré.
Caso seus colegas de trabalho usam XGH para programar e você é um
coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada
Design Pattern que você usa corretamente, seus colegas gerarão 10
vezes mais código podre usando XGH.
17- O XGH não é perigoso até surgir um pouco de ordem.
Este axioma é muito complexo, mas sugere que o projeto utilizando XGH
está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é
inútil e você pode jogar um tempo precioso no lixo. Isto fará com que
o projeto afunde mais rápido ainda (Vide Axioma . Não tente gerenciar
o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.
18- O XGH é seu brother, mas é vingativo.
Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado,
não o abandone. Se começar um sistema utilizando XGH e abandoná-lo
para utilizar uma metodologia da moda, você estará fudido. O XGH não
permite refactoring (vide axioma 10), e seu novo sistema cheio de
frescurites entrará em colapso. E nessa hora, somente o XGH poderá
salvá-lo.
19- Se tiver funcionando, não rela a mão.
Nunca altere, e muito menos questione um código funcionando. Isso é
perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10).
Tempo é a engrenagem que move o XGH e qualidade é um detalhe
desprezível.
20- Teste é para os fracos.
Se você meteu a mão num sistema XGH, é melhor saber o que está
fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes
são desperdício de tempo, se o código compilar, é o suficiente.
21- Acostume-se ao sentimento de fracasso iminente.
O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é
diferente. As pessoas costumam achar que as chances do projeto
fracassar utilizando XGH são sempre maiores do que ele ser bem
sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O
projeto foi por água abaixo mas você aprendeu algo? Então pra você foi
um sucesso!
22- O problema só é seu quando seu nome está no Doc da classe.
Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da
equipe morra ou fique doente por muito tempo, o barco irá afundar!
Nesse caso, utilize o Axioma 8.
Fonte: google.com
trabalho) que utiliza a metodologia de gerenciamento de projetos
eXtreme Go Horse? Se já sabem do que estou falando... contém aí o que
acham disso e se há esperanças.
Hein? O quê? Bom deixa eu explicar...
Muitas empresas utilizam ainda o processo unificado (UP), outras nem
isso, e as mais espertas utilizam o SCRUM (mais moderno e menos
burocrático). É claro que há exceções e vou deixar os possíveis
comentários para discutir as polêmicas.
Aqui na empresa onde estou, após uma tentativa frustrada de
implantação do SCRUM, fiquei tentando identificar ao certo qual é a
metodologia (ou variação de alguma outra) nós seguimos e cheguei a
seguinte conclusão: eXtreme Go Horse!
Isso não é uma metodologia exatamente (apesar de alguns discordarem),
mas sim uma "brincadeira" que inventaram para descrever processos
caóticos (avacalhados) por aí. Aqui onde eu trabalho é chamado de
"Cultura da empresa".
Segue a descrição do XGH...
1- Pensou, não é XGH.
XGH não pensa, faz a primeira coisa que vem à mente. Não existe
segunda opção, a única opção é a mais rápida.
2- Existem 3 formas de se resolver um problema, a correta, a errada e
a XGH, que é igual à errada, só que mais rápida.
XGH é mais rápido que qualquer metodologia de desenvolvimento de
software que você conhece (Vide Axioma 14).
3- Quanto mais XGH você faz, mais precisará fazer.
Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas
todos eles serão resolvidos da forma XGH. XGH tende ao infinito.
4- XGH é totalmente reativo.
Os erros só existem quando aparecem.
5- XGH vale tudo, só não vale dar o toba.
Resolveu o problema? Compilou? Commit e era isso.
6- Commit sempre antes de update.
Se der merda, a sua parte estará sempre correta.. e seus colegas que
se fodam.
7- XGH não tem prazo.
Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE
conseguirá implementar TUDO no tempo necessário (nem que isso implique
em acessar o BD por um script malaco).
8- Esteja preparado para pular fora quando o barco começar a afundar?
ou coloque a culpa em alguém ou algo.
Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa,
mais o sistema vira um monstro. O dia que a casa cair, é melhor seu
curriculum estar cadastrado na APInfo, ou ter algo pra colocar a
culpa.
9- Seja autêntico, XGH não respeita padrões.
Escreva o código como você bem entender, se resolver o problema,
commit e era isso.
10- Não existe refactoring, apenas rework.
Se der merda, refaça um XGH rápido que solucione o problema. O dia que
o rework implicar em reescrever a aplicação toda, pule fora, o barco
irá afundar (Vide Axioma .
11- XGH é totalmente anárquico.
A figura de um gerente de projeto é totalmente descartável. Não tem
dono, cada um faz o que quiser na hora que os problemas e requisitos
vão surgindo (Vide Axioma 4).
12- Se iluda sempre com promessas de melhorias.
Colocar TODO no código como uma promessa de melhoria ajuda o
desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É
claro que o refactoring nunca será feito (Vide Axioma 10).
13- XGH é absoluto, não se prende à coisas relativas.
Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais
pense na qualidade e sim no menor tempo que a solução será
implementada, aliás? não pense, faça!
14- XGH é atemporal.
Scrum, XP? tudo isso é modinha. O XGH não se prende às modinhas do
momento, isso é coisa de viado. XGH sempre foi e sempre será usado por
aqueles que desprezam a qualidade.
15- XGH nem sempre é POG.
Muitas POG?s exigem um raciocínio muito elevado, XGH não raciocina
(Vide Axioma 1).
16- Não tente remar contra a maré.
Caso seus colegas de trabalho usam XGH para programar e você é um
coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada
Design Pattern que você usa corretamente, seus colegas gerarão 10
vezes mais código podre usando XGH.
17- O XGH não é perigoso até surgir um pouco de ordem.
Este axioma é muito complexo, mas sugere que o projeto utilizando XGH
está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é
inútil e você pode jogar um tempo precioso no lixo. Isto fará com que
o projeto afunde mais rápido ainda (Vide Axioma . Não tente gerenciar
o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.
18- O XGH é seu brother, mas é vingativo.
Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado,
não o abandone. Se começar um sistema utilizando XGH e abandoná-lo
para utilizar uma metodologia da moda, você estará fudido. O XGH não
permite refactoring (vide axioma 10), e seu novo sistema cheio de
frescurites entrará em colapso. E nessa hora, somente o XGH poderá
salvá-lo.
19- Se tiver funcionando, não rela a mão.
Nunca altere, e muito menos questione um código funcionando. Isso é
perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10).
Tempo é a engrenagem que move o XGH e qualidade é um detalhe
desprezível.
20- Teste é para os fracos.
Se você meteu a mão num sistema XGH, é melhor saber o que está
fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes
são desperdício de tempo, se o código compilar, é o suficiente.
21- Acostume-se ao sentimento de fracasso iminente.
O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é
diferente. As pessoas costumam achar que as chances do projeto
fracassar utilizando XGH são sempre maiores do que ele ser bem
sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O
projeto foi por água abaixo mas você aprendeu algo? Então pra você foi
um sucesso!
22- O problema só é seu quando seu nome está no Doc da classe.
Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da
equipe morra ou fique doente por muito tempo, o barco irá afundar!
Nesse caso, utilize o Axioma 8.
Fonte: google.com
Lucas Arruda
Mar 28, 2012, 3:00:04 PM3/28/12
to ph...@googlegroups.com
XGH é exatamente a falta de metodologia.
Infelizmente a falta de metodologia é justamente a "metodologia" de muitas empresas de TI. Acho que quase todo mundo já trabalhou ou pelo menos conhece uma empresa assim.
Se eu fosse fazer um apanhado, diria que é a realidade de 60~80% - sendo bonzinho - das empresas de TI.
[]'s
Lucas Arruda
lucasarruda.com
[]'s
Lucas Arruda
lucasarruda.com
--
Você recebeu esta mensagem porque está inscrito no grupo "PHP MG" no grupos do Google.
Site oficial do grupo: http://www.phpmg.com
Para postar neste grupo, envie um e-mail para ph...@googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para phpmg-un...@googlegroups.com
Regras da lista: http://groups.google.com/group/phpmg/web/regras-da-lista
Para ver mais opções, acesse http://groups.google.com/group/phpmg
Marcelo Linhares
Mar 28, 2012, 3:04:12 PM3/28/12
to ph...@googlegroups.com
Eu já participei de projeto com metodologia "bumba meu boi", há algum tempo até fiquei de escrever um "manifesto bumba-meu-boi", algo como 8 linhas, bem "lean".
--
Marcelo Linhares
Pessoal -> marcelolinhares.com
Na verdade o GH é uma sátira do pmi e processos UP based, enquanto o eGH é um "go-horse ágil"!
Mas a sua reflexão é bem válida, hoje em dia está todo mundo falando que é "agil" pra esconder o caos, comoditizou práticas ágeis e tem um monte de agência que senta em reunião e perguntado qual metodologia utiliza fala-se: "Somos ágeis, usamos SCRUM"
Se você não tem o mínimo de prática de engenharia de software, algo como integração contínua, deploy contínuo, testes, versionamento de código (não to falando dos famigerados .old), servidor de homologação, produção, ferramenta de issue tracker, alguma ferramenta de documentação (vide wiki, gdocs, etc..), etc.. etc...
Você está fazendo o "bumba meu boi" e não está sendo ágil!
E se a palavra TDD ainda te causa estranheza, é pq vc tá precisando se atualizar!
--
Você recebeu esta mensagem porque está inscrito no grupo "PHP MG" no grupos do Google.
Site oficial do grupo: http://www.phpmg.com
Para postar neste grupo, envie um e-mail para ph...@googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para phpmg-un...@googlegroups.com
Regras da lista: http://groups.google.com/group/phpmg/web/regras-da-lista
Para ver mais opções, acesse http://groups.google.com/group/phpmg
Marcelo Linhares
Pessoal -> marcelolinhares.com
Presentes e Flores em BH? maisfloresbh.com.br
CachaçaExpress - Seu portal de Cachaças na Internet
http://www.cachacaexpress.com.br/
CachaçaExpress - Seu portal de Cachaças na Internet
http://www.cachacaexpress.com.br/
Marcus Paulo Mazzon Dias
Mar 28, 2012, 3:07:41 PM3/28/12
to ph...@googlegroups.com
Aonde eu trabalho e assim kkk e agora estou de atestado de 10 dias. Eles estao loucos kkk
Tayron Miranda
Mar 28, 2012, 3:15:42 PM3/28/12
to ph...@googlegroups.com
rsrsr Já estive em empresa assim onde o processo que se mantia era o "Manda quem pode, obedece quem tem juizo", dai o melhor jeito que via pra amenizar isso era criar um filtro entre a metodologia da empresa e a nossa de desenvolvimento.
Ela era simples, apenas você dizia que vc deve receber as tarefas em tal formato, elas seriam analizadas em tempo record ( na verdade a resposta era quase instantâneo rsrsrrs ), dai se retornava o prazo para finalizar à tarefa e o porque do tempo estimado.
Caso a tarefa seja absurda e afete toda a lógica ou como quase sempre nem há muita logica que condiz com o projeto. Tentava-se ganhar tempo estipulando prazos maiores e específicava em qual érea iria afetar, mesmo que o usuário ou próprio patrão nunca visse essas alterações...
Dai ganhava-se tempo para realizar as atividades, entrevar à tempo e deixar o patrão feliz!!!
Enfim, zuação à parte, o idéal é tentar padrozinar a forma que as tarefas chegam até o desenvolvedor (primeira luta), depois disso para cada tarefa estimula-se um prazo ( E nunca comece uma nova tarefa sem antes terminar algo que já tenha começado "By segunda luta"). Terceiro adequar as loucuras ao projeto ( Quinta luta ). Feito tudo isso, funcionou, não está dando pau e seu patrão gostou.. corra para o abraço |o/
--
Tayron Miranda - Programador Pleno em PHP
(31) 9121-7921
(31) 8613-8615
www.tayronmiranda.com.br
www.usefulclasses.com.br
Ao encaminhar esta mensagem, por favor:
1. Apague o MEU endereço eletrônico;
2. Coloque o endereço de email de seus amigos no CCO (COM CÓPIA OCULTA),
assim você evita que nossos emails caiam em spam.
Ela era simples, apenas você dizia que vc deve receber as tarefas em tal formato, elas seriam analizadas em tempo record ( na verdade a resposta era quase instantâneo rsrsrrs ), dai se retornava o prazo para finalizar à tarefa e o porque do tempo estimado.
Caso a tarefa seja absurda e afete toda a lógica ou como quase sempre nem há muita logica que condiz com o projeto. Tentava-se ganhar tempo estipulando prazos maiores e específicava em qual érea iria afetar, mesmo que o usuário ou próprio patrão nunca visse essas alterações...
Dai ganhava-se tempo para realizar as atividades, entrevar à tempo e deixar o patrão feliz!!!
Enfim, zuação à parte, o idéal é tentar padrozinar a forma que as tarefas chegam até o desenvolvedor (primeira luta), depois disso para cada tarefa estimula-se um prazo ( E nunca comece uma nova tarefa sem antes terminar algo que já tenha começado "By segunda luta"). Terceiro adequar as loucuras ao projeto ( Quinta luta ). Feito tudo isso, funcionou, não está dando pau e seu patrão gostou.. corra para o abraço |o/
--
Você recebeu esta mensagem porque está inscrito no grupo "PHP MG" no grupos do Google.
Site oficial do grupo: http://www.phpmg.com
Para postar neste grupo, envie um e-mail para ph...@googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para phpmg-un...@googlegroups.com
Regras da lista: http://groups.google.com/group/phpmg/web/regras-da-lista
Para ver mais opções, acesse http://groups.google.com/group/phpmg
--
Tayron Miranda - Programador Pleno em PHP
(31) 9121-7921 (31) 8613-8615www.tayronmiranda.com.br
www.usefulclasses.com.br
Ao encaminhar esta mensagem, por favor:
1. Apague o MEU endereço eletrônico;
2. Coloque o endereço de email de seus amigos no CCO (COM CÓPIA OCULTA),
assim você evita que nossos emails caiam em spam.
Jean Pimentel
Mar 28, 2012, 3:29:20 PM3/28/12
to ph...@googlegroups.com
Scrum (ou outra) é igual sexo na adolescência. Todo mundo fala que faz mas poucos fazem. E dos que fazem, muitos fazem errado.
Att,
Jean Pimentel - www.jeanpimentel.com.br
Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. - David Gelernter
Att,
Jean Pimentel - www.jeanpimentel.com.br
Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. - David Gelernter
Marcelo Linhares
Mar 28, 2012, 3:32:04 PM3/28/12
to ph...@googlegroups.com
caralho.... perfeito a observação, tipo "enterro de anão", todo mundo sabe que existe, mas ninguém vê.. heheh
--
2012/3/28 Jean Pimentel <jea...@gmail.com>
Marcelo Linhares
Mar 28, 2012, 3:22:46 PM3/28/12
to ph...@googlegroups.com
Se eu fosse fazer um apanhado, diria que é a realidade de 60~80% - sendo bonzinho - das empresas de TI.
Verdade Lucas, e das "agências digitais" é realidade de 98% das empresas.
Não tão distante, mas ainda no assunto, a "cultura" das agências off-line estão tomando conta das agências digitais: http://fuckyeahpubliciotarios.tumblr.com/
Tayron Miranda
Mar 28, 2012, 3:22:16 PM3/28/12
to ph...@googlegroups.com
Loucos? Aposto que estão subindo pela parede querendo que vc trabalhe a todo custo, nem que seja em casa.. buahahhahahahah
Lucas Arruda
Mar 28, 2012, 4:25:56 PM3/28/12
to ph...@googlegroups.com
Marco Van Brain
Mar 28, 2012, 4:17:36 PM3/28/12
to ph...@googlegroups.com
A empresa que eu entrei com sócio era assim, estou mudando aos poucos, mas sabe o jeitinho brasileiro já faz parte do DNA da galera e tá difícil de mudar.
Quero comprar a licença dos softwares para trabalhar sem problemas e ter acesso a suporte, recebo e-mails da galera com um arquivo zip ou rar e um keygen lá dentro ( kkkkkk).
Vou abolir XGH ou então, peço pra sair kkkkk.
Abraços!
--
Marco Antonio
Produtor Multimídia
(31) 8558 1944 - Oi / 9158 3800 - TIM / 9772 0516 - VIVO
Marco Antonio
Produtor Multimídia
(31) 8558 1944 - Oi / 9158 3800 - TIM / 9772 0516 - VIVO
Tayron Miranda
Mar 28, 2012, 3:42:27 PM3/28/12
to ph...@googlegroups.com
Mas de uma forma genérica as empresas querem o produto o mais rápido possível, não se importa com a qualidade mas sim com o visual e o resultado financeiro.
A empresa onde estive precisava do site para poder começar faturar, ela ficou quase 4 meses sem faturamento, somente investindo dinheiro para que seu produto saísse..
Conclusão: As empresas tem necessidade de fazer algo mais poucas tem recurso e tempo para se ter o que precisam. Por isso que essa realidade não irá mudar tão cedo.
A empresa onde estive precisava do site para poder começar faturar, ela ficou quase 4 meses sem faturamento, somente investindo dinheiro para que seu produto saísse..
Conclusão: As empresas tem necessidade de fazer algo mais poucas tem recurso e tempo para se ter o que precisam. Por isso que essa realidade não irá mudar tão cedo.
Lucas Arruda
Mar 28, 2012, 10:02:28 PM3/28/12
to ph...@googlegroups.com
Marcos,
Ou você muda sua postura e influencia o grupo, ou melhor você pular fora do barco.
Veja que a cultura geralmente está entranhada no DNA da empresa e no comportamento dos funcionários. É muito difícil mudar, mas não é impossível!
[]'s
Lucas Arruda
lucasarruda.com
[]'s
Lucas Arruda
lucasarruda.com
gustavo monteiro castro
Mar 28, 2012, 10:43:51 PM3/28/12
to ph...@googlegroups.com
Todas empresas em que trabalhei, sem exceção, bebem na fonte do eXtreme Go Horse Programming.
Gustavo Monteiro Castro
Tayron Miranda
Mar 29, 2012, 6:57:41 AM3/29/12
to ph...@googlegroups.com
É XGH na veia manoooo!!!! rsrsrrs
Danilo Sabbagh
Mar 29, 2012, 4:38:04 PM3/29/12
to ph...@googlegroups.com
xGH não é só uma metodologia,
--
Danilo Sabbagh
Project Manager @ Beelive
@DaniloSabbagh
http://www.linkedin.com/in/danilosabbagh
+55 31 8861 3128
é arte
é filosofia
é receita de sucesso!
Aqui na empresa e em todas empresas que trabalhei sempre usamos a go horse não so nos projetos mas como exemplo de vida. =)
agora sério;
Racho de rir de programador que não sabe NADA de design patterns vir falar de xgh :)
Não tem a menor idéia do que e como funciona unit testing... o unico controle de versão que sabem usar é ftp.
Scrum não é nenhuma magica e pode ter certeza que para implementa-lo precisa de programadores e não de executores de código.
Ter um ambiente de desenvolvimento, fazer uma aplicação legal não se baseia em simplesmente uma metodologia legal um paradigma adequado, precisa de mão de obra.. senão a unica coisa que vc vai ver no seu scrum é que seus programadores são incapazes de integrar os modulos que fazem, que são incompetentes em testes e que eles precisam horas ( ou story points) de maneira tão regular quanto o sono do charlie sheen.
Alem dos scrum existem inúmeras metodologias XP. E existem paradigmas muito bons que não são capazes de suportar algumas metodologias tão endeusadas por ai.
Aqui na empresa usamos por exemplo o Lean Startup. Dentro dele tivemos de remover VARIOS passos e adequar inúmeros outros dentro do desenvolvimento para conseguir adequar a metodologia.
Cada empresa tem o profissional que merece e cada profissional trabalha na empresa que escolheu ou conseguiu.
Danilo Sabbagh
Project Manager @ Beelive
@DaniloSabbagh
http://www.linkedin.com/in/danilosabbagh
+55 31 8861 3128
Marco Van Brain
Mar 30, 2012, 12:46:48 AM3/30/12
to ph...@googlegroups.com
Danilo
"Quem pode pode, quem não pode, toca pagode!" - De Leve
William Rufino
Mar 29, 2012, 7:59:34 PM3/29/12
to ph...@googlegroups.com
Guilherme Freire
Apr 4, 2012, 2:15:41 PM4/4/12
to ph...@googlegroups.com
Trabalho numa empresa pública e aqui o que mais se adapta e XP por incrível que pareça funciona
Reply all
Reply to author
Forward
0 new messages