[quote=Luiz Augusto Prado]
Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais. [/quote]
O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.
[quote=Impossivel]
Nunca precisei dar manutenção em um sistema antes mesmo de ir entrar em produção.
Imagino que você possa ter um problema de processo se precisa fazer isso com frequência.[/quote]
Se você não precisa alterar funcionalidades antes mesmo do sistema entrar em produção, você tem a solução de todos os nossos problemas. Sugiro sinceramente que publique e espalhe esse seu conhecimento. Você vai ficar milionário.
Existe hoje toneladas de artigos, publicações, técnicas, justamente para facilitar a alteração de código pronto, mesmo antes de ser lançado. Técnicas e ferramentas que facilitam nossas vidas, deixando o código preparado para as mudanças de requisitos que costumam ser constantes em sistemas de médio porte pra cima.
Se você tem a solução definitiva pra isso, você tem o Santo Graal da engenharia de software. Por favor, compartilhe desse conhecimento conosco.
Só não me venha com o velho planejamento detalhado e levantamento completo e cuidadoso dos requisitos.
Só por no google:
pinkverify certified itil
Esxemlo que aparece:
http://www.cherwell.com/product/pink-verify-itil-processes
http://www.bmc.com/news/press-releases/2012/bmc-softwares-remedy-it-service-management-suite-awarded-itil-v3-certification.html
.
.
.
Uma das empresa onde trabalhei tem preferencia por certificados nesta bilioteca. Central IT
http://www.centralit.com.br/2_2-Certificacoes.html
Na minha opinião, se estão em primeiro no google, é porque tão dando certo.
Falou! boa sorte
[quote=Impossivel][quote=Luiz Augusto Prado]
Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais. [/quote]
O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.[/quote]
como que se relaciona o quote que fez com ‘burocracia “bem estruturada”’?
se, pra vc burocracia “bem estruturada” é o que pra mim é “cooperação” então é possível sim.
[quote=YvGa]
Se você não precisa alterar funcionalidades antes mesmo do sistema entrar em produção, você tem a solução de todos os nossos problemas. Sugiro sinceramente que publique e espalhe esse seu conhecimento. Você vai ficar milionário.
Existe hoje toneladas de artigos, publicações, técnicas, justamente para facilitar a alteração de código pronto, mesmo antes de ser lançado. Técnicas e ferramentas que facilitam nossas vidas, deixando o código preparado para as mudanças de requisitos que costumam ser constantes em sistemas de médio porte pra cima.
Se você tem a solução definitiva pra isso, você tem o Santo Graal da engenharia de software. Por favor, compartilhe desse conhecimento conosco.
Só não me venha com o velho planejamento detalhado e levantamento completo e cuidadoso dos requisitos.[/quote]
Não é que não preciso alterar funcionalidades antes mesmo de entrar em produção, é que se precisar fazer na versão em desenvolvimento, não vai afetar em nada o build que está sendo testado pra entrar em produção.
Talvez você esteja falando de alguma situação específica e não esta sabendo ser claro. Talvez uma situação que tem que lidar com algum tipo de software (ou banco de dados no caso de CRUDs) legado? Não sei, desculpa por não ter a bala de prata que vc busca. Como falei, eu trabalho com jogos. Minha engenharia é investida no produto, e não com atualização e legados.
Sobre a internet, existem toneladas de artigos publicados sobre basicamente tudo que se pesquisar, isso não quer dizer que as pessoas escrevendo esses artigos estão milionárias.
[quote=Luiz Augusto Prado][quote]
Por favor, cite empresas conhecidas por criarem software de qualidade e que usam ITIL.
[/quote]
Só por no google:
pinkverify certified itil
Esxemlo que aparece:
http://www.cherwell.com/product/pink-verify-itil-processes
http://www.bmc.com/news/press-releases/2012/bmc-softwares-remedy-it-service-management-suite-awarded-itil-v3-certification.html
.
.
.
Uma das empresa onde trabalhei tem preferencia por certificados nesta bilioteca. Central IT
http://www.centralit.com.br/2_2-Certificacoes.html
Na minha opinião, se estão em primeiro no google, é porque tão dando certo.
Falou! boa sorte[/quote]
Se estão em primeiro no google para “ITIL” é porque o software é bom?! 
#fail
Me avisa quando uma empresa de software ou tecnologia de ponta usar ITIL. Até lá não vejo porque um desenvolvedor precisa se importar com isso.
[quote=Luiz Augusto Prado][quote=Impossivel][quote=Luiz Augusto Prado]
Eu busco valores maiores que poder e dinheiro. Só a boa companhia já vale muito mais. [/quote]
O dia que uma burocracia “bem estruturada” como vc fala, conseguir criar software de qualidade eu vou acreditar.[/quote]
como que se relaciona o quote que fez com ‘burocracia “bem estruturada”’?
se, pra vc burocracia “bem estruturada” é o que pra mim é “cooperação” então é possível sim. [/quote]
O problema que pra funcionar, seu método depende em separar o trabalho entre “mentes superiores” (os clientes e Arquitetos) e pessoas com menos QI (desenvolvedores).
Obviamente que o arquiteto só tem a ganhar nessa configuração. Mas não acho que teria algo de errado em ganhar, se funcionasse…
O motivo que não funciona é porque burocracias são frágeis.
Nada a ver. tá viajando de novo. Onde eu disse isso de QI? Um dia um pode assumir um papel e outro outro. Vai depender da confiança que o funcionário merece.
Já ví muitos Juniores com 200 de QI e estão onde estão por pouca experiência e (ou) pouca confiança da empresa, mas que depois de 2 anos já são tão capazes de assumir a gestão de um projeto quanto qualquer outro sênior com menor QI que é sênior por experiência. Quem vai determinar quem vai ficar onde é o gestor e se existir acordo com o funcionário. E, por mais QI que um funcionário tenha, se ele for novato em desenvolvimento, deve começar por baixo. Como um júnior, se não tiver experiência nenhuma ou como pleno se tiver alguma experiência. Mas nunca como sênior, pois provavelmente não conhece o negócio. Quem for assumir a gestão, deve conhecer bem o negócio além de ter muita experiência com desenvolvimento.
Sobre ITIL, novamente, informo que não to defendendo que só empresas de sucessos a utilizam. O que to dizendo é que se vc não sabe muita coisa e tem pouca experiência em gestão de serviços, a leitura de ITIL (e se possível experiência pratica como estagiário) vai ser melhor que nada. Claro que nos anos 80, quando não existia ITIL, os gestores pensavam em manter o ciclo de vida dos processos internos de suas empresas vivos, só que agora, a ITIL reúne praticas de sucesso que estas empresas utilizam. A ITIL com certeza não é completa e nunca vai ser, porque obviamente mundo evolui. cada empresa adapta os métodos que acha que lhes convêm.
[quote=Impossivel]
Não é que não preciso alterar funcionalidades antes mesmo de entrar em produção, é que se precisar fazer na versão em desenvolvimento, não vai afetar em nada o build que está sendo testado pra entrar em produção.[/quote]
Isso depende da qualidade do código escrito, depende do quanto de duplicação de código existe, do quanto a intenção do código é clara. Se um programador tem que levar horas pra ler e entender um código feito por outro, ou por ele mesmo as vezes, isso causa efeito na data de entrega e atinge diretamente o cliente. Por isso ter código de qualidade faz diferença. Um código difícil de entender ou cheio de duplicações pode causar efeitos inesperados, mesmo em partes que já se consideravam prontas.
É isso que eu quero dizer com “dar manutenção em código antes dele entrar em produção”. Não sei como é nos games, mas não deve ser tão diferente. Muitas vezes o cliente muda de ideia, outras nós não conseguimos entender o que ele queria a princípio, outras ele lembra de algo que havia esquecido de dizer, outras vezes ele tem uma ideia maravilhosa que não pode ficar de fora (e que muitas vezes é fantástica mesmo e faz todo sentido que seja feita naquela hora).
E assim vamos, e pra que nós possamos dar aos nossos clientes essa possibilidade precisamos manter um código limpo, usando da melhor forma que podemos todas as ferramentas que temos em mãos. Isso também faz parte de “ter o cliente como foco principal”.
O que eu disse desde o princípio, e talvez não tenha sido claro realmente é: Conhecer ferramentas, técnicas, frameworks e saber a hora de usá-los e não usá-los faz parte do pacote “Foco no cliente.”
Digo e repito, eu já vi muita coisa mal feita sob a desculpa de que o cliente não se importa com nada disso. Vai se importar quando refletir nele o problema.
O texto é enorme.
Se refere ao eleito Lindy um fator para quebrar a ordem interna?
“eventos inesperados em um mundo imprevisível e que elas tenham a consciência e aceitem que esses eventos, uma hora ou outra, acontecerão”.
Riscos, todos temos. Podemos sair hoje de casa e amanhã de tarde estarmos enterrados.
Se puder explicar melhor… em resumo.
Em ITIL, por exemplo, um estágio do ciclo de vida do serviço: “Estratégia do serviço” é o responsável por fazer a análise de mercado e avaliar os riscos.
[quote=javaflex]
Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão.
É preciso mencionar pois não é tão difícil um dia saber de situações do tipo, com mais chances de encontrar em lugares que arquitetos vivem no mundo da Lua da TI, definindo padrões sem envolvimento com a realidade do dia-a-dia do desenvolvimento x usuário.
O que na prática tenho passado e achado ideal, é a equipe poder definir junto, isso leva mais ao equilíbrio. Claro que os seniors vão naturalmente ter maior grau de contribuição e peso, mas nada impede do júnior de repente saber de uma novidade técnica que resolva melhor uma nova funcionalidade que o usuário precisa, onde a maioria aceita e depois passa pela prova de conceito. Além claro, da soma de ideias poder formar uma grande ideia. Assim todos vão estar mais envolvidos para o mesmo objetivo, que é o atendimento das necessidades dinâmicas do usuário.
Só para deixar claro que costumo falar relacionado ao cenário de sistemas de informações.[/quote]
Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda. O modelo fordista já é mais paranoico. Quer apenas que os funcionários saibam apenas uma fração do processo. Esta é uma estratégia que considero ruim porque se torna igual a um formigueiro. Se a rainha morre, toda a colônia morre. A idéia da internet é genial pela forma como se pode contornar este tipo de problema. Difundindo o conhecimento dentro do sistema além de gerar mais confiança nos colaboradores, garantimos que não existam gargalos em uma única pessoa. O conhecimento, assim como ovos, não devem ser guardados em uma única cesta.
Na verdade o texto é um resumo, você pode pesquisar sobre o autor se quiser…
O importante é que o autor provou matematicamente que estruturas como as que você sugere são menos efetivas e quando tem algum erro, se espalha rapidamente provocando caos (basta uma decisão errado do arquiteto para haver deterioramento da qualidade do produto final).
Sem falar na necessidade que essas empresas tem de externalizar os riscos no cliente.
Talvez isso explica porque a CentralIT tem tantos clientes no governo, mesmo não sendo empresa que seja conhecido por criar software de qualidade?
[quote=Luiz Augusto Prado]
Riscos, todos temos. Podemos sair hoje de casa e amanhã de tarde estarmos enterrados.[/quote]
Interessante, porque nessa thread você insinuou que desenvolvimento de software devia ser livre de riscos para os desenvolvedores.
Está pedalando pra trás agora?
Ok, não é baseado no QI… mas sim quem lambe melhor a bunda do gestor.
Saquei. 
[quote=YvGa]
Isso depende da qualidade do código escrito, depende do quanto de duplicação de código existe, do quanto a intenção do código é clara. Se um programador tem que levar horas pra ler e entender um código feito por outro, ou por ele mesmo as vezes, isso causa efeito na data de entrega e atinge diretamente o cliente. Por isso ter código de qualidade faz diferença. Um código difícil de entender ou cheio de duplicações pode causar efeitos inesperados, mesmo em partes que já se consideravam prontas.[/quote]
Então é só contratar programadores que escrevem código de qualidade, e todos vão ficar milionários? Não precisa focar no produto?
Entendo seu ponto de vista, mas discordo.
[quote=YvGa]
É isso que eu quero dizer com “dar manutenção em código antes dele entrar em produção”. Não sei como é nos games, mas não deve ser tão diferente. Muitas vezes o cliente muda de ideia, outras nós não conseguimos entender o que ele queria a princípio, outras ele lembra de algo que havia esquecido de dizer, outras vezes ele tem uma ideia maravilhosa que não pode ficar de fora (e que muitas vezes é fantástica mesmo e faz todo sentido que seja feita naquela hora).[/quote]
É diferente no sentido de que todos os envolvidos precisam saber o que estão fazendo. Não existe “documento de requisitos” pra se apoiar. Você precisa focar no produto.
Você já viu games sendo desenvolvido primeiro coletando requisitos??? hehehe
[quote=YvGa]
E assim vamos, e pra que nós possamos dar aos nossos clientes essa possibilidade precisamos manter um código limpo, usando da melhor forma que podemos todas as ferramentas que temos em mãos. Isso também faz parte de “ter o cliente como foco principal”.[/quote]
O que é ótimo, mas um tanto offtopic, visto que o tópico é sobre focar no produto, e não no cliente.
[quote=YvGa]
O que eu disse desde o princípio, e talvez não tenha sido claro realmente é: Conhecer ferramentas, técnicas, frameworks e saber a hora de usá-los e não usá-los faz parte do pacote “Foco no cliente.”[/quote]
ver meu comentário acima.
[quote=YvGa]
Digo e repito, eu já vi muita coisa mal feita sob a desculpa de que o cliente não se importa com nada disso. Vai se importar quando refletir nele o problema.[/quote]
Novamente. O responsável por algo “mal feito” tem todo o motivo pra ocultar os verdadeiros motivos do seu fracasso e culpar outros de fora da equipe.
[quote=Impossivel]
Interessante, porque nessa thread você insinuou que desenvolvimento de software devia ser livre de riscos para os desenvolvedores.[/quote]
Onde que eu disse que a cobertura dos riscos é de 100%?
É troll.
Acho que já lhe falaram umas 3 vezes que ninguém disse isso.
É troll.
[quote=Impossivel][quote=Luiz Augusto Prado]
Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda.
[/quote]
Está pedalando pra trás agora?
Não, to dizendo que vc tem que engrenar com o que tem. O ideal é que todo mundo saiba o máximo. Vc vai conseguir isso facilmente? Não. É dificl de conseguir todos da empresa saberem tudo. Então se vira com o que tem e delega no máximo aquilo que cada um é capaz de executar.
é troll.
[quote=Impossivel]
Ok, não é baseado no QI… mas sim quem lambe melhor a bunda do gestor.
Saquei. :P[/quote]
Não trabalho neste tipo de empresa. Este tipo de empresa não se tem muito o que aprender e não nos prepara para o real competitividade do mercado.
[quote=Luiz Augusto Prado][quote=Impossivel][quote=Luiz Augusto Prado]
Também sou adepto deste pensamento. Desta forma cada um pode dar contribuição em qualquer parte que entenda.
[/quote]
Está pedalando pra trás agora?
Não, to dizendo que vc tem que engrenar com o que tem. O ideal é que todo mundo saiba o máximo. Vc vai conseguir isso facilmente? Não. É dificl de conseguir todos da empresa saberem tudo. Então se vira com o que tem e delega no máximo aquilo que cada um é capaz de executar.
é troll.
[/quote]
Não creio que seja possível delegar pra um júnior algo como “focar no produto”.
Pra isso ele vai ter que ter o conhecimento que você tem na torre de marfim. Lamento se isso parece ofensivo pra alguns, mas me parece ser o único jeito. Senão, no máximo o júnior estará limitado a tarefas banais que podem ser delegadas, como fazer CRUDs, e implementar DAOs, ou seja, o correspondente a um pedreiro ou técnico de elevadores do mundo digital.
Talvez essa seja a “desvantagem” de focar no produto? Você precisa de uma equipe de profissionais competentes que sabem o que estão fazendo… ou um arquiteto com superpoderes.
Qual dos dois você acha que é mais fácil conseguir não sei, mas sei qual pode criar software com foco no produto. Dica: não é o arquiteto com superpoderes.
Resumo
