| Autor |
Mensagem |
john s mill
Membro |
# jun/13
· votar
manifestação em floripa = desfile de moda ao ar livre D:
|
Xeper
Veterano |
# jun/13
· votar
john s mill
E o eXtreme Go Horse? O que você acha dele?
Não podia deixar passar essa...
|
john s mill
Membro |
# jun/13
· votar
Xeper
Ah sim, sempre é bom relembrar os preceitos da metodologia mais usada na prática e menos usada na teoria:
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 8).
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 8). 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.
|
Xeper
Veterano |
# jun/13
· votar
^
^
^
Essas paradas sempre me lembram o verbete de POG da desciclopedia
|
Xeper
Veterano |
# jun/13
· votar
Mas não vou atrapalhar mais o papo de vcs com palhaçada... até pq o assunto é bem interessante, msm não manjado quase nada
Bjo bjo
|
st.efferding
Membro |
# jun/13
· votar
john s mill
Beleza, saquei o espírito =D
Quanto à documentação, relatórios, acompanhamentos, briefings e relacionados..... a documentação é uma parte muito importante em um projeto, IM not so experienced O, porém no momento em que adotamos uma metodologia ágil eu fico me perguntando o que é perda de tempo e o que não é, na prática mesmo.
A pergunta é a seguinte: eu estipulei relatórios de custos para cada etapa do projeto visando dividir o futuro relatório de custos final em pequenas partes. Essa prática é ok, eficiência dela compensa em relação a contabilizar tudo no final, ou não?
Ainda mais levando em consideração conceitos que, para eu e meus sócios, iniciando uma empresa, apenas com um projeto, contabilizar o custo de engenharia a.k.a. salário hipotético que teríamos em desenvolver o produto para um cliente externo, de forma a aprender a fazer previsões mais exatas do capital de investimento para um novo projeto ..
|
brunohardrocker
Veterano |
# jun/13
· votar
itt: tecnoposts
|
Drowned Man
Veterano |
# jun/13
· votar
brunohardrocker
vamos mudar o assunto aqui, dude
ah, e oi pra todos
|
Drowned Man
Veterano |
# jun/13
· votar
brunohardrocker
vamos mudar o assunto aqui, dude
ah, e oi pra todos
|
john s mill
Membro |
# jun/13
· votar
st.efferding
Isto tudo depende do contexto. Por exemplo, ao fazer estimativas tu pode usar tanto um sistema mais simples como os story points do Scrum quanto um mais elaborado como pontos por função. No caso de projetos em que eu não preciso dar o valor ao cliente logo no início, eu consigo usar story points, que não é tão custoso, mas quando necessita um detalhamento maior eu sou obrigado a usar pontos por função.
Quanto mais relatórios, teoricamente maior o controle, só que também maior o custo administrativo. A Prince2 é uma metodologia com grande enfoque em controle, ele faz aprovação de custos e controle em cada fase do projeto, o planejamento ocorre aos poucos (rolling wave planning)
A orçamentação eu faço desta forma: depois que eu tenho os requisitos funcionais e não-funcionais do projeto, eu crio a estrutura analítica do projeto e dividido o projeto em estruturas entre 8 e 80 horas (que eu imagino ser, ainda não estimado geralmente). Este tamanho é arbitrado pra não gerar um micromanagement e ao mesmo tempo não ser algo muito genérico.
Dentro deste pacote de trabalho, terão atividades, esta é uma por pessoa e deverão ser estimadas.
Então na composição do custo para fazer as atividades com estimativa de recursos (tanto humano quanto materiais e whatever), eu tenho o custo do pacote de trabalho, na soma de todos os pacotes de trabalho eu tenho o custo de um nível que é conhecido como carta de controle, para gerar a orçamentação final ainda precisa-se somar a reserva de contingência (você sempre deve deixar um valor para riscos que podem ocorrer e deseja tratar), isto vai formar o seu orçamento.
Depois ainda é bom deixar um percentual conhecido como reserva gerencial que só é usado em último caso, que é para os riscos que você não conseguiu identificar, mas existem. Varia muito, mas eu normalmente deixo uns 15% do orçamento total do projeto.
Quanto maior a divisão que você vai ter, maior a apuração, como eu disse, se vale a pena ou não depende muito do quanto você necessita de uma informação precisa e o quanto está disposto a pagar por ela, mas normalmente eu faço a orçamentação pelo nível mais baixo (atividades), isto no PMBOK é conhecido por estimativa top down ou decomposição.
|
john s mill
Membro |
# jun/13
· votar
Tá, eu sou muito prolixo D:
|
st.efferding
Membro |
# jun/13
· votar
john s mill
Capaz, foi uma ótima contribuição, acredito que esclareceu bem minhas dúvidas até o momento
eu sou muito prolixo D: (2)
é nozes o/
@potic
Oi, Flávia
|
FláviaTaline
Veterano |
# jun/13
· votar
Oi, Flávia
Oi. :)
|
brunohardrocker
Veterano |
# jun/13
· votar
Oi Flavia e Cindy,
|
FláviaTaline
Veterano |
# jun/13
· votar
Oi Bruno, \o
|
brunohardrocker
Veterano |
# jun/13
· votar
FláviaTaline
Buscando a janta que deixei esquentando... o/
|
brunohardrocker
Veterano |
# jun/13
· votar
FláviaTaline
E aí, qual é a de hoje?
Conte-me como é estar tremendo de frio mais que vara verde ao vento!
|
FláviaTaline
Veterano |
# jun/13
· votar
brunohardrocker
Comi pizza. Tô comendo muita porcaria... ._.
O que é o jantar aí? \o
|
FláviaTaline
Veterano |
# jun/13
· votar
brunohardrocker
Nem fala, tá friiiooo! Inverno chegou chegando. >.<
Tenho q sair, beijo. :*
|
brunohardrocker
Veterano |
# jun/13
· votar
FláviaTaline
Aquela pizza semanal é bom demais o/
Eu fiz panquecas :]
|
brunohardrocker
Veterano |
# jun/13 · Editado por: brunohardrocker
· votar
FláviaTaline
Curta o frio por mim, aqui tá quente o/
=*
|
MauricioBahia
Moderador |
# jun/13
· votar
Pessoal,
O sistema de votos já está ok hein! ;)
o/
|
brunohardrocker
Veterano |
# jun/13
· votar
MauricioBahia
Ficaram com medinho dos usuários fazerem protestos, né?
:]
|
Die Kunst der Fuge
Veterano |
# jun/13 · Editado por: Die Kunst der Fuge
· votar
MauricioBahia
"ok" é um termo forte demais.
Tá funfando meia boca, mas ainda com os bugs antigos, de não poder ver em que posts você votou.
|
MauricioBahia
Moderador |
# jun/13 · Editado por: MauricioBahia
· votar
brunohardrocker
haha!
Die Kunst der Fuge: Tá funfando meia boca, mas ainda com os bugs antigos, de não poder ver em que posts você votou.
Pô, tava funcionando agorinha, tudo certo. Os caras devem estar fazendo testes ainda então...
:(
|
Die Kunst der Fuge
Veterano |
# jun/13
· votar
MauricioBahia
Dá pra votar, mas continua um bug antigo. Depois que você vota não dá mais pra ver quantos votos o post tem, fica como se ele não tivesse recebido voto nenhum.
|
MauricioBahia
Moderador |
# jun/13
· votar
Die Kunst der Fuge: mas continua um bug antigo.
Você diz aquele do "Você não pode votar em si mesmo"? Esse já era! Agora falta só aparecer a contagem.
;)
|
MauricioBahia
Moderador |
# jun/13
· votar
Die Kunst der Fuge
Fora do OT aparece... O.o
|
Die Kunst der Fuge
Veterano |
# jun/13 · Editado por: Die Kunst der Fuge
· votar
MauricioBahia
Você diz aquele do "Você não pode votar em si mesmo"?
Não, esse impedia de votar.
Agora falta só aparecer a contagem.
Exato.
Fora do OT aparece... O.o
Acabei de testar no de música erudita, não tá aparecendo ainda não.
Você tem que votar e sair do tópico, quando voltar pro mesmo tópico não vai mais aparecer a contagem.
|
CindyFerrari
Veterano |
# jun/13
· votar
MauricioBahia
Fora do OT aparece... O.o
Eu tô vendo nesse tópico.
Já dá pra ver quantos votos nosso próprio tópico tem?
|