| Autor |
Mensagem |
Dressaaa
Veterano |
# nov/08
Estou fazendo um trabalho sobre CMMI e me interessou saber como ele funciona na prática. Já li vários comentários que alguns acham que criar e manter todos os processos é muito complicado.
Já outros dizem que organizar o trabalho foi a salvação da empresa etc etc. Mas não sei qual cargo que essas pessoas exercem na empresa. Cada um deve ter uma visão disso relacionada ao seu papel dentro do contexto.
Como eu trabalho em uma empresa que está muiiiito longe de ter algum processo, muito menos algum auditado, hehehehe, queria fazer uma pesquisa entre as pessoas que vivem nesse dia-a-dia.Desde gestores até a tia do café, e como o OT tem gente de todo tipo (de nerd), resolvi tentar.
Então, quem quiser contribuir com o conhecimento geral, relatem as suas experiências com processos e gerenciamento de projetos de software, de preferência em empresas que estejam de acordo com a metodologia CMMI.
Se render quem sabe até escrevo um artigo.
Dissertem, e viva a engenharia!
P.S. Se o papo não render desvirtuem a vontade.
|
CheshireCat
Veterano |
# nov/08 · Editado por: CheshireCat
· votar
Trampava. Mas na real, ela só seguia na teoria, porque era uma baita zona. E lá ia a estagiária(eu) organizar a documentação do projeto, desatualizada quase um ano...
Ah, antes de ir pra área de desenvolvimento, eu fiquei uns meses na qualidade. Aí fazia auditorias, essa parte era divertida, sair pela empresa fazendo perguntas como se eu fosse alguém importante. =D
|
ROTTA
Veterano |
# nov/08 · Editado por: ROTTA
· votar
Dressaaa
Como eu trabalho em uma empresa que está muiiiito longe de ter algum processo, muito menos algum auditado, hehehehe, queria fazer uma pesquisa entre as pessoas que vivem nesse dia-a-dia.
O fato de você estar pensando no assunto é excelente, mesmo sua empresa estando no "nível zero" ainda. =)
Estou fazendo um trabalho sobre CMMI e me interessou saber como ele funciona na prática.
Eu trabalho, e inclusive acompanhei de perto o processo de avaliação. Mas, infelizmente, não posso lhe dar grandes detalhes porque é a política da empresa. A empresa já era certificada ISO9001 há alguns anos e tinha o gerenciamento de projetos (baseado no RUP e PMBOK) implantado. Aliás, é com isto que eu trabalho...
Tenha em mente que o modelo CMMI não vai lhe dizer como fazer as coisas, e sim o que fazer, através de práticas e goals que você deve satisfazer. Por exemplo, o modelo diz que você deve gerenciar requisitos, e indicará algumas práticas para isto (note que as práticas são bem gerais) mas não lhe dirá detalhadamente "como".
Um alerta: cuidado com o que você lê pela internet. Assim como tem muita coisa boa, tem um bom tanto de ladainha e inutilidades.
Abraços.
|
The Blue Special Guitar
Veterano |
# nov/08
· votar
"Engenharia de software é a área para onde vão os que fazem informática mas perceberam que fizeram o curso errado quando estavam no último semestre."
hahahahaaha
Eu particularmente acho engenharia de software um saco, principalmente no que fala sobre processos de desenvolvimento.
E o pior é que esses caras ainda ganham bem, só fazer um cursinho de RUP e aprender a enganar com uns quatro ou cinco diagraminhas que dá pra fazer no Rational Rose e o cara já sai ganhando 3 ou 4 mil reais por mês =P
|
ROTTA
Veterano |
# nov/08 · Editado por: ROTTA
· votar
The Blue Special Guitar
só fazer um cursinho de RUP e aprender a enganar com uns quatro ou cinco diagraminhas que dá pra fazer no Rational Rose
Eu não sei em que empresa você trabalhou e nem qual seu envolvimento com processos de software, mas quando se constrói software de verdade (com vendas de alguns milhões/ano), com centenas (ou mais) de pessoas, fica difícil coordenar o trabalho deste povo todo se você não mantiver alguns artefatos. Rastreabilidade é só o fator mais evidente. Nosso processo é baseado no RUP, mas não usamos nenhuma ferramenta da Rational, por exemplo.
Os "diagraminhas" que você falou, e que onde trabalho são mantidos pelos analistas e arquitetos de software, cumprem esta função. Se não agrega valor, não é feito. Algumas vantagens: facilidade de hand over de projeto para manutenção, visão compartilhada, treinamento da equipe (pode entrar um programador novo que é muito mais fácil de começar a render), etc.
Alguns poderão dizer que existem alternativas no desenvolvimento ágil (trabalhei com XP há alguns anos, antes de entrar na empresa atual), mas não vou entrar neste mérito.
Abraços.
|
The Blue Special Guitar
Veterano |
# nov/08
· votar
ROTTA
Trabalhei numa empresa que também utilizava um processo baseado no RUP e fiquei bastante surpreso ao ver a quantidade de documentação que os caras geravam, desde o levantamento inicial de requisitos até o suporte, embora eu fosse programador e não trabalhasse diretamente na geração dos documentos.
Os caras usavam os próprios templates para documentos fornecidos pela Rational na suite do Rose, além de diversas ferramentas do pacote deles.
No final, o que eu percebia, era uma quantidade imensa de documentação redundante, que poderia ser sintetizada facilmente em alguns poucos documentos mais claros e objetivos. Para quem trabalha na programação, como era o meu caso, isso era indiferente, pois o trabalho usava o mecanismo de "tickets" de tarefas a serem realizadas, o que também era documentado pelo analista que lançava o ticket para ser implementado.
|
ROTTA
Veterano |
# nov/08
· votar
The Blue Special Guitar
Trabalhei numa empresa que também utilizava um processo baseado no RUP e fiquei bastante surpreso ao ver a quantidade de documentação que os caras geravam
Você tocou no ponto-chave de processo de software hoje em dia, e uma das razões pelas quais as metodologias ágeis estão tão na moda. Volto a frase que falei lá em cima: se não tem valor, não se faz. O CMMI usa, por exemplo, a expressão tailoring para dizer, sendo bem direto, que tudo que está lá deve ser cuidadosamente adaptado para a realidade da empresa.
O que muita empresa "não tão esperta" faz é interpretar ao pé da letra o que são apenas sugestões e adotar burocracia para criar evidências e documentos sem valor. Acertei ou passei longe?
Observo que 8 (ou mais) em cada 10 desenvolvedores questionam e pensam como você. Boa parte deles não fez (por não querer ou não ter conhecimento para isto) uma análise da finalidade de cada documento, e por causa disso raramente são capazes de sugerir algo melhor. Ao mesmo tempo, existem muitas empresas que exageram na burocracia, e pagam caro por isso.
Abraços.
|
TG Aoshi
Veterano |
# nov/08
· votar
Dressaaa
Sem querer desvirtuar, mas...
Caramba, você ainda existe? =p
|
Bog
Veterano
 |
# nov/08 · Editado por: Bog
· votar
Dressaaa
relatem as suas experiências com processos e gerenciamento de projetos de software
Minha experiência consiste em fugir deles enquanto posso. :)
The Blue Special Guitar
Eu particularmente acho engenharia de software um saco, principalmente no que fala sobre processos de desenvolvimento.
heheheh, esse é dos meus!
só fazer um cursinho de RUP e aprender a enganar com uns quatro ou cinco diagraminhas
Mas também não é assim, né cara!
Já que foi tocado no assunto, duas coisas:
1. Após trabalhar com vários e vários engenheiros de áreas diversas, conclui que engenharia de software é um termo meio impreciso. O que se convencionou chamar de engenharia de software às vezes tem mais a ver com arquitetura do que com engenharia. Engenharia tem requisitos bem mensuráveis no mundo real, por trabalhar com coisas físicas. Como software envolve muitos requisitos abstratos e até subjetivos, acho que tem mais relação com arquitetura. Sem contar que as leis que regem a engenharia de software muitas vezes não são físicas, nem muito exatas.
2. Eu não acho, como muitos, que a engenharia de software é dispensável. Só acho que ela se aplica muito mais a um tipo específico de projeto: aquele onde o grau de ignorância a respeito da parte técnica é baixo. No geral, é o tipo de projeto que as empresas por aí encontram - software corporativo e afins. Mas como trabalho com pesquisa, volta e meia penso que engenharia de software não se aplica ao que eu estou fazendo, ao menos não com todas essas formalidades que vejo por aí. Não dá para desenvolver e avaliar um novo algoritmo de rastreamento de pessoas por imagens seguindo essas regras - não faz sentido, e você a princípio nem sabe direito o que precisa fazer! Uma vez estabelecido o algoritmo, a engenharia de software passa a fazer sentido na hora de transformá-lo em produto.
Mas isso me deixa um pouco chateado. Nas empresas "normais", programador muitas vezes é técnico ou estagiário, visto como alguém que faz apenas "trabalho braçal", já que está tudo definidinho na documentação - isso quando o próprio código já não foi gerado automaticamente por alguma ferramenta qualquer. Eu, como alguém que gosta de programar mas não gosta de processos de desenvolvimento, enxerguei uma barreira aí. Já trabalhei com programação um pouco mais "hardcore", e notei que no "mundinho corporativo", isso existe pouco - um bom programador raramente é 100% exigido, e no geral, é um trabalho até meio repetitivo. Por isso, volto à frase do início: resolvi fugir da engenharia de software, dos processos, e de todo o software corporativo em geral. Virei cientista! =P
|
CheshireCat
Veterano |
# nov/08
· votar
Com a minha pequena experiência, eu acho que documentar o projeto direitinho é necessário. Principalmente se for um projeto que a empresa já desenvolve há anos e o cliente sempre fica pedindo pra acrescentar mais coisas ou alterar uma funcionalidade. Se não tiver tudo muito bem documentado, chega uma hora que fica um caos total.
Na hora de testar também(quando eu estava na qualidade), se a documentação estivesse desatualizada, eu tinha que ficar caçando os programadores ou gerentes de projeto pra saber o que deveria acontecer quando eu clicasse num botão. (nem sempre era algo óbvio =P)
Bog
Nas empresas "normais", programador muitas vezes é técnico ou estagiário, visto como alguém que faz apenas "trabalho braçal", já que está tudo definidinho na documentação - isso quando o próprio código já não foi gerado automaticamente por alguma ferramenta qualquer. Eu, como alguém que gosta de programar mas não gosta de processos de desenvolvimento, enxerguei uma barreira aí.
Poxa, concordo com você. Quando o cara começa a subir na empresa, ele deixa de botar a mão na massa e começa a coordenar o projeto, fazer reunião com cliente etc... Eu até pensei "Mas que droga! Vou ser pra sempre peã(er... peão tem feminino?), ser gerente de projeto é muito chato!" =P
|
Dressaaa
Veterano |
# nov/08
· votar
TG Aoshi
Hehehehe, pois é, fiquei meio afastada do fórum (sem tempo), mas as vezes passo por aqui. Difícil achar algo interessante pra comentar, então geralmente não deixo rastros.
|
Chespirito
Veterano |
# nov/08
· votar
O q é CMMI?
|
Dressaaa
Veterano |
# nov/08
· votar
ROTTA
Um alerta: cuidado com o que você lê pela internet. Assim como tem muita coisa boa, tem um bom tanto de ladainha e inutilidades.
Pois é, justamente por isso que gostaria de ouvir opiniões de quem realmente vivência...
Mas, infelizmente, não posso lhe dar grandes detalhes porque é a política da empresa.
Respeito a decisão da sua empresa de não divulgar dados a respeito dos processos internos porém acho um pensando errado. Acho que se a empresa que conseguiu organizar o seu trabalho através dos preceitos da engenharia de software deveria procurar ao máximo disseminar o conhecimento, não digo "ensinar a pescar" mas pelo mostrar os melhores caminhos para "encontrar a pesca".
Acho que muitas empresas, como você falou para o TBSG, estão procurando melhorar seus processos porém ainda não encontraram a forma correta de fazer (pricipalmente as pequenas e médias que não podem investir muito). Por isso acho que quem já conseguiu deveria contribuir para que as outras encontrem o caminho, de alguma forma. Não tendo a visão de que "está ajudando os inimigos" e sim que está contribuindo com a evolução de toda a área de tecnologia.
Observo que 8 (ou mais) em cada 10 desenvolvedores questionam e pensam como você.
Talvez não seja somente a falta de interesse da maioria dos desenvolvedores em buscar entender a necessidade da engenharia de software, mas a forma com que a gerencia organiza as funções e a equipe. Talvez o desenvolvimento nem chega a saber os benefícios do organização porque a gerencia pensa que esse assunto diga respeito somente a si mesmo.
Penso que se a empresa pretende melhorar seus processos, primeiramente todos devem estar cientes dos benefícios que ela traria, e que trabalhem juntos para fazer acontecer.
Perceba que enchi, de "acho" e de "penso que", porque como já falei, não vivencio isso, portanto não posso afirmar nada, apenas suponho, hehehehe.
|
Dressaaa
Veterano |
# nov/08
· votar
The Blue Special Guitar
Eu particularmente acho engenharia de software um saco, principalmente no que fala sobre processos de desenvolvimento.
E o pior é que esses caras ainda ganham bem, só fazer um cursinho de RUP e aprender a enganar com uns quatro ou cinco diagraminhas que dá pra fazer no Rational Rose e o cara já sai ganhando 3 ou 4 mil reais por mês =P
Respeito a sua opinião mas acho que opiniões assim tão "duras" são prejudiciais, não só para a sua empresa como para a toda a area de tecnologia.
Talvez porque você esteja diretamente ligado ao desenvolvimento, você não percebe a necessidade de toda essa papelada e burocracia, até porque o perfil da maioria dos desenvolvedores é confiar muito no resultado do seu trabalho, e como não lida diretamente com o cliente, nem chega a saber que o cliente geralmente não gosta do resultado do seu trabalho (não porque o trabalho não esteja bom, mas porque as pessoas têm espectativas diferentes sobre as coisas). E também porque a sua empresa ainda não conseguiu se organizar corretamente nessa "cultura". E também talvez a gerencia da sua empresa não procure com a opinião dos outros membros da equipe.
Trabalho em uma empresa bem pequena, que não produz softwares complexos, e também não tem processos definidos. Porém além da área de criação (não programo mas também participo das conversas do desenvolvimento), as vezes faço contato com os clientes e geralmente me envolvo com todos os problemas que essa falta causa aqui, dentro da nossa pequena empresa. E agora que estou estudando engenharia de software na faculdade, estou percebendo ainda mais essa falta. (Pena que a gerencia aqui nem sabe o que é engenharia de software :/)
Sugiro a você não ser tão crítico assim, e procurar se envolver um pouco mais nesse "mundo". Não sei se a sua empresa permite, mas já que você acha que há muita documentação redundante, você poderia sugerir uma melhor organização dos documentos etc etc. Talvez ia ajudar a abrir um pouco a sua cabeça.
Mas só sugiro, beleza, como já disse, respeito a sua opinião! =D
|
Bog
Veterano
|
# nov/08
· votar
Dressaaa
as pessoas têm espectativas diferentes sobre as coisas
Hhehe, como se diz por aí, existe uma diferença entre o que o cliente diz que quer, o que o cliente pensa que quer e o que o cliente quer.
Se alguém se lembra, tinha um episódio da 2a temporada dos Simpsons onde um certo irmão do Homer aparece e resolve projetar um carro exatamente como ele diz que quer. O nome é "Oh Brother, Where Art Thou?". É extremamente ilustrativo desta idéia, hahah.
|
The Blue Special Guitar
Veterano |
# nov/08 · Editado por: The Blue Special Guitar
· votar
Dressaaa
Eu não falei que os processos de desenvolvimento e os conceitos de engenharia de software são desnecessários, só disse que a forma extremista como muitas empresas os adotam é um absurdo.
Concordo com isso que o Bog falou:
Nas empresas "normais", programador muitas vezes é técnico ou estagiário, visto como alguém que faz apenas "trabalho braçal", já que está tudo definidinho na documentação - isso quando o próprio código já não foi gerado automaticamente por alguma ferramenta qualquer. Eu, como alguém que gosta de programar mas não gosta de processos de desenvolvimento, enxerguei uma barreira aí.
Percebo que muitas empresas que às vezes investem demais no dito processo de desenvolvimento, na outra parte, deixam a desejar na área de desenvolvimento, contratam programadores estagiários que vão ganhar R$ 300 por mês para trabalhar 8h por dia. No final, o software está extremamente documentado, mas a qualidade e a otimização do produto final está bastante questionável.
Assim era na empresa onde trabalhei, que usava um processo baseado no rup. Os caras faziam a modelagem, geravam um código com a própria ferramenta. Daí bastava para os programadores fazer os ajustes naquele código, aplicar nas interfaces, etc. Mas esses códigos gerados por ferramentas CASE geralmente são uma droga, cheio de lixo e coisas que não são otimizadas. O código implementado braçalmente por um bom programador seria muito mais eficiente, limpo e fácil de entender do que aquilo lá.
O que era fácil de perceber era a distância entre a qualidade dos modelos e a qualidade do produto final... no meu modo de ver, era algo gritante.
Enfim, eu acredito que a engenharia de software tem o papel dela, mas esse papel não deve ser intrusivo nas atividades básicas realizadas no processo de desenvolvimento. Ela tem mais que organizar as coisas e facilitar a administração do desenvolvimento em si, sem ser intrusiva demais ditando como devem ser realizadas as atividades em cada fase do processo.
hehee..mudando de assunto um pouco, percebo que em regra o pessoal que trabalha com desenvolvimento tem um certo ódio de quem trabalha na parte de engenharia... eu também ficava puto quando uma dita "engenheira de software" vinha dar piteco no meu trabalho, dizendo pra fazer "isso", fazer "aquilo". Dava pra perceber que ela não sabia nada de programação, embora fosse formada em alguma área de computação.
Mas em regra, na própria faculdade, dá pra perceber que quem não gosta muito de esquentar a cabeça programando (a maior parte dos não-nerds do curso) vai para as áreas mais "light" da informática, como a Engenharia de SW, qualidade de SW, etc.
|
Bog
Veterano
|
# nov/08
· votar
The Blue Special Guitar
a maior parte dos não-nerds do curso) vai para as áreas mais "light" da informática
Hahah, e no meu curso, os nerds de verdade iam trabalhar com Linux na Conectiva. Eu como nerd rebelde que sou, fui convidado, mas recusei.
...
para
...
pensa
...
Ou talvez isso signifique que eu sou mais nerd que eles ainda, hahaha. No meu lab, tem 16 caras, todos com mais do que 25 anos, dos quais 3 são casados e 2 tem namoradas (eu incluso). Medo!
|
Dressaaa
Veterano |
# nov/08
· votar
Bog e CheshireCat
Minha experiência consiste em fugir deles enquanto posso. :)
um bom programador raramente é 100% exigido
Hehehe, pois é, você explicou bem porque não gosta dela.
Mas acho que o fato do programador não ser 100% exigido, ou não poder fazer o que é o mais legal da profíssão e que geralmente é o perfil do desenvolvedor, que seria o desafio de encontrar uma solução de um problema, ou de fato utilizar a sua lógica, não deve-se ao fato de que ele receba tudo já definido e sim da forma como organizamos as equipes.
Explicando... esse modelo de hierarquia de trabalho, acontece em empresas de vários ramos. Depende da cultura da empresa, a maioria delas sempre tem os que de fato produzem e os que definem como e o que será produzido.
Em empresas que produzem software onde não há processo definidos, o desenvolvedor acaba analisando e produzindo, e as que tem processos definidos, existem pessoas responsáveis pela análise e que definem o trabalho do desenvolvedor. Por isso a culpa pelo desenvolvedor virar um "trabalhador braçal" acaba sendo atribuida ao processo e a tadinha da engenharia de software, mas na verdade deve-se ao modelo hierarquico que a maioria das empresas organiza a sua equipe.
A vantagem que a tecnologia tem sobre isso é que, uma pessoa que monta um brinquedo plástico, por exemplo, não precisa necessariamente ser um engenheiro ou conhecer como aquele brinquedo foi produzido. Já o desenvolvedor, por menos que ele saiba, ele tem conhecimento suficiente para produzir um resultado sobre alguma especificação, mesmo que não produza da forma correta, ou que não produza da melhor forma.
Vai da cultura da empresa, fazer com que o desenvolvedor participe da análise, ou seja um mero "trabalhador braçal". Eu particularmente acho que mais pessoas geram melhores resultados (acredito naquele preceito de que duas cabeças pensam melhor do que uma), mas dependendo o tamalho da equipe isso pode ser difícil de gerenciar.
Mas sei lá, não entendo muito... hauhauhauahua
Só acho que ela se aplica muito mais a um tipo específico de projeto
Concordo com você que todas as regrinhas lá não devem se aplicar a todos os casos. Acho mais importante que a própria empresa crie um forma de se organizar, com base na engenharia de software, de acordo com o seu ramo de negócio.
Hhehe, como se diz por aí, existe uma diferença entre o que o cliente diz que quer, o que o cliente pensa que quer e o que o cliente quer.
Tem esse vídeo aí, fala sobre criação, mas o cliente é igual pra todo mundo eu acho, huahuahua
|
Bog
Veterano
|
# nov/08 · Editado por: Bog
· votar
Dressaaa
esse modelo de hierarquia de trabalho, acontece em empresas de vários ramos.
Sim, mas ao ver o programador como um "pedreiro" que empilha os tijolinhos segunto o projeto do engenheiro, deixam passar um detalhe importante, MUITO importante - programar pode ser uma atividade altamente intelectual e nada "braçal".
Existe uma diferença abismal entre "aqui você coloca essa query" e "aqui você coloca um algoritmo que faz uma visão 3D do ambiente a partir de um conjunto de n webcams comuns". O primeiro é realmente braçal, mas o segundo é um problema em aberto para o qual simplesmente não existe solução no momento. ;)
Eu sempre fugi dessas coisas, mas sei que uma vez contratamos uma empresa para desenvolver parte de um projeto. Eles eram todos organizadinhos, mas sinceramente, a analista não tinha a menor noção. Ela vinha com muito desse papo de modelo para cá e use case para lá, mas algumas das "coisinhas" que ela deixava para os programadores eram simplesmente problemas sem solução, ou bem complicadinhos para um mero estagiário no 2o ano da faculdade. Deu pena de ver eles se batendo para fazer o trabalho "braçal" de inventar algoritmos que dariam uma dissertação de mestrado - se tivessem funcionado.
Modelos bonitinhos e até design patterns são muito legais quando o trabalho é repetitivo e comum. Mas no cerne da informática, ainda estão os algoritmos, e embora muita coisa SEJA repetitiva, tem muita coisa que exige conhecimento e qualificação. No papel, dizer "aqui você faz uma busca nessa lista" pode parecer simples, e normalmente É simples, se a tal lista estiver em um banco de dados comum e a busca for uma query comum. Mas chega uma hora em que pode fazer toda a diferença do mundo se a tal lista é um vetor, lista encadeada, árvore de prefixos, árvore B... Pior, talvez não exista suporte na plataforma para nada disso, e o nosso "pedreiro" vai ter que fazer uma nova implementação de árvore B rodando em cima de, digamos, um aparelho que nem geranciamento de memória faz sozinho. Coloque aí mais uns amiguinhos como restrições de tempo real, onde a diferença entre 1ms e 2ms pode ser gigantesca, e um ambiente onde não existe suporte nativo para multi-tarefa... e pronto. A tal "busquinha" vira um inferno para o nosso "pedreiro".
Mas note que eu estou falando aí de cenários onde o grau de ignorância é alto, onde você nem sabe o que vai funcionar, ou onde as otimizações possíveis só ficam sendo conhecidas na implementação de fato. Na maior parte dos sisteminhas corporativos - aquela coisa de uma interface em Java aqui, uma ligação com BD ali ou um frontend ASP acolá, acho que os programadores podem ser mais "juniores". A palavra-chave aí é "grau de ignorância". Em uma empresa normal, quanto mais você puder evitar cair em problemas para os quais você não sabe a solução, melhor. Soluções bem estabelecidas podem ser aplicadas mecanicamente, especialmente se forem recorrentes. Se você tiver um pacote que faz tudo já, melhor ainda. Mas em certos lugares, isso não existe, e você vai precisar tirar algoritmos mágicos da manga. Aí, sem um bom desenvolvedor, é um abraço.
Vou dar um outro exemplo abominável que eu conheci durante a faculdade. Tive colegas que não programavam nada bem, e entraram como estagiários em um banco. E foram colocados para programar os caixas eletrônicos. Até que um dia, um colega que manjava um pouco mais entrou lá também. Ele disse que depois daquele dia, ficou com MEDO de usar caixas eletrônicos, tamanha a maçaroca que existia ali. Era uma mistura de códigos velhos e novos, feitos por estagiários que haviam saído de lá há anos, e mesmo que existisse documentação (o que não existia), era uma codificação tão porca que era inacreditável que aquilo passasse nos testes. E passava, porque as falhas são raras. Mas certas falhas que acontecem 1 vez a cada 10 anos na hora dos testes, multiplicado por 10 mil caixas eletrônicos, pode acontecer 1000 vezes por ano. E dá-lhe gente perdendo dinheiro. Aplicação que envolve dinheiro, vidas humanas, e segurança, não pode ser feita de qualquer jeito. Nesses lugares, código porco não devia ter lugar.
Enfim, eu sei que na maior parte dos projetos, esses esquemas funcionam bem. Mas eu simplesmente não sentiria prazer se tivesse que fazer esse tipo de trabalho. E por isso, fui para onde os projetos têm um nível de ignorância absurdamente alto - pesquisa. É um mundo onde cadeias de Markov, aproximações lineares e transformadas de Fourrier são muito mais importantes do que use cases e design patterns. Enfim, é um mundo mais divertido para mim, hahaha.
|
Bog
Veterano
|
# nov/08
· votar
Dressaaa
Credo, que post enorme. Mas, a propósito, video legal, eheheh! :)
|
toty
Veterano |
# nov/08
· votar
só post enorme, to com preguiça nem vou ler.
|
ROTTA
Veterano |
# nov/08
· votar
Dressaaa
Percebi que você é de Blumenau também. A empresa onde atuo foi avaliada como CMMi nível 3, e é a primeira do estado e a 32ª no Brasil neste nível. Desenvolvemos tecnologia (framework) e os aplicativos, com mais de 9 mil clientes.
Acho que muitas empresas, como você falou para o TBSG, estão procurando melhorar seus processos porém ainda não encontraram a forma correta de fazer
Exatamente, e o mercado de consultoria percebeu isto há muitos anos. Não tem fórmula mágica.
Acho que se a empresa que conseguiu organizar o seu trabalho através dos preceitos da engenharia de software deveria procurar ao máximo disseminar o conhecimento
Pode ser, mas não é o caso quando se tem um mercado de centenas de milhões/ano. Filantropia não tem muito espaço entre concorrentes.
Perceba que enchi, de "acho" e de "penso que", porque como já falei, não vivencio isso, portanto não posso afirmar nada, apenas suponho, hehehehe.
"Achar" alguma coisa é excelente, um claro sinal de personalidade e infelizmente conheço gente que carece disto. Agora colocar em prática o que se "acha", e ir avaliando e aprimorando no meio do caminho, seja em que carreira for, é o caminho.
Eu li os posts dos demais mas respondi para você porque foi a única que me citou. De qualquer forma, vou acrescentar algumas coisas que penso sobre desenvolvimento de software.
Existem empresas que se estruturam no clássico analista + programador, e neste caso concordo plenamente quando disseram que o peso intelectual da atividade do programador é alto. No entanto, outras empresa possuem estruturas mais complexas, com papéis de arquiteto, analista e projetista, realmente deixando para o programador (a base da pirâmide neste caso) pouca margem para inovação no negócio e nos conceitos (note que não estou falando dos fontes, onde esta margem sempre existirá).
É neste segundo contexto que o CMMi faz mais sentido, ainda que possa ser aplicado em estruturas mais simples. Na outra "margem do rio" estão as metodologias ágeis (Scrum, XP, FDD, Crystal), que em geral estão pouco ligando para o CMMi, e que focam na entrega de software funcionando para o cliente acima de outras coisas, como a documentação e a modelagem (claro que tem sua dose disto).
Abraços.
|
ROTTA
Veterano |
# nov/08 · Editado por: ROTTA
· votar
toty
só post enorme, to com preguiça nem vou ler.
Este é curtinho:
http://forum.cifraclub.com.br/forum/11/198280/
Abraços.
|
Luiz Almeida
Veterano |
# nov/08
· votar
É o fim da picada!!! Tópico sério no off topic!
Trabalhei numa empresa que tinha como base a "ABNT", então antes de se criar um projeto ou executar um processo, era necessário seguir as normas da empresa, e se constasse na norma que era necessário arquivar "fisicamente" até rascunho da mesa de reunião, assim era feito.
Todas as normas da empresa foram desenvolvidas pelos próprios funcionários que exerciam as tarefas a serem normalizadas.
Não trabalho com informática, por isso não sei o que foi discutido acima, mas "acho" que o que escrevi tem alguma coisinha a ver com o assunto.
Ps.: Se perguntarem, produção siderúrgica.
|
Bog
Veterano
|
# nov/08 · Editado por: Bog
· votar
ROTTA
Só para ilustrar um pouco como pode ser perigoso assumir que a codificação é simples:
Suponha que você entra em um projeto que trabalha com processamento de imagens.
#SITUACAO A
Para um punhado de problemas, existem pacotes inteiros com soluções quase completas - comprados de alugma 3rd party, ou desenvolvidos em projetos anteriores da empresa. Se a codificação se resume a chamar um punhado de métodos nessas classes, e o pessoal "de cima" especifica quais são esses métodos, pronto, a sua organização funcionou perfeitamente e todos estão felizes.
#SITUACAO B
Infelizmente, para muitos problemas não existe a tal solução "quase completa". Mas mesmo pare esses casos, existem pacotes que contêm primitivas básicas (imagens, pixels) sobre as quais você pode construir a sua solução. Aqui, começa a aventura. Suponha, por exemplo, que eu tenho que aplicar um algoritmo sobre uma imagem, e para isso preciso visitar todos os pixels dela, e depois preciso de um buffer com um formato específico (por ex, um widget Bitmap). Existem pelo menos 2 formas de fazer isso:
1.
Bitmap bmp;
for (int i = 0; i < imagem.largura (); i++)
for (int j = 0; j < imagem.altura (); j++)
{
imagem.algoritmo (imagem.getPixel (i,j));
bmp.setPixel (i,j) = imagem.getPixel (i,j);
}
2.
Bitmap bmp;
for (pixel* ptr = imagem.dataMatrix (), int i = 0; i < imagem.largura () * imagem.altura (); i++, ptr++)
imagem.algoritmo (*ptr)
mempcy (bmp_buffer, imagem.dataMatrix (), imagem.largura () * imagem.altura ())
bmp.setBuffer (bmp_buffer)
Por mais estranho que possa parecer, a forma 1, mais legível, também é BEM menos eficiente, especialmente se a imagem for grande. Do ponto de vista da funcionalidade, 1. e 2. são idênticos, produzem o mesmo resultado, são apenas um detalhe de implementação. Mas em processamento de imagens, a forma como você faz um loop pode ser a diferença entre 30 frames por segundo (qualidade de TV) e 15 frames por segundo (video "quebradiço"). O problema é que o jeito 2. de fazer exige conhecimento sobre como o tal pacote formata as imagens, como o tal Bitmap é codificado, e como fazer um truquezinho simples com ponteiros (por ex, em C++). Um programador/desenvolvedor xarope não vai fazer do jeito 2.
#SITUACAO C
Suponha agora que você está desenvolvendo para um novo modelo de celular, para o qual não existem pacotes de processamento de imagens, apenas um punhado de primitivas de um SO simples. Mesmo que a tarefa seja simples, aqui você vai precisar definir até o formato dos buffers da imagem. E agora? Usar memória contígua? Linhas contíguas e colunas separadas? Matrizes esparsas? Codificação usando 1, 3 ou 4 bytes dependendo do número de canais da imagem? Codificação usando valores inteiros?
Aqui, subitamente começa a fazer toda a diferença do mundo se você trabalha com "unsigned char [w*h*channels]" ou "LinkedList <LinkedList <Pixel>>".
#SITUACAO D
Suponha agora que a plataforma é um aparelho bem simples, que tem um display controlado por um microcontrolador limitado. Suponha que você tem severas restrições de memória e tempo real, mas não tem nem SO para trabalhar. Alocação de memória é feita na mão. Você precisa dividir o tempo do microcontrolador com outras tarefas.
De repente, até o número de instruções em assembler começou a ser importante.
Para a felicidade das empresas, a maior parte dos projetos consegue se encaixar de alguma forma na SITUAÇÃO A - você aplica soluções já conhecidas, testadas e bem estabelecidas, o programador "liga os fiozinhos". Mas já vi muito também da SITUAÇÃO B, onde a forma de se fazer o código é relevante, mas colocam um estagiário qualquer para fazer. Quando chegamos na SITUAÇÃO C, os detalhes de implementação já não são mais tão "detalhes assim". Esse tipo de situação é rara na maior parte das empresas que trabalham com "soluções em informática", mas quem encara esse tipo de situação definitivamente não quer um programador/desenvolvedor xarope. E eu já vivi algumas vezes a SITUAÇÃO D.
Note que eu não coloquei acima uma outra situação, a SITUAÇÃO E, que é a que eu vivo no meu dia a dia atualmente.
#SITUAÇÃO E
Suponha que não existe algoritmo conhecido para resolver o problema de processamento imagens proposto. ;)
Aqui, você entra em um mundo estranho, onde ler um artigo sobre a formação das imagens no córtex de primatas pode ser mais importante do que ler um livro chamado "Ultimate Design Patterns"; um mundo onde os termos "transformada rápida de Fourrier", "vetor gradiente" e "filtro Gaussiano" fazem muito mais sentido do que "use case" ou "cliente", ehahhaha.
|
ROTTA
Veterano |
# nov/08
· votar
Bog
O exemplo "pegar pronto" ou "desenvolver nós mesmos" ocorre em alguma intensidade em quase todos os projetos de desenvolvimento.
Nos exemplos que você trouxe, todas as variáveis e situações apontadas seriam tratadas pelo arquiteto, projetista e programador, em ordem de complexidade e abrangência. Importante esclarecer que, neste esquema, um percentual muito pequeno das decisões técnicas caberia ao programador. Todos os três papéis que citei programam, em ordem inversamente proporcinal ao nível de abstração que atuam.
Obviamente, isto não é verdade no cenário "analista + programador", tão típico nas empresas Brasil afora.
Abraços.
|
ROTTA
Veterano |
# nov/08
· votar
O que estou querendo defender, em resumo, é que bons programadores são importantes, mas existem abordagens onde atuam outros papéis técnicos (que são a sequência natural da carreira de um programador competente, aliás!), onde aumenta-se a complexidade e a abrangência.
Poucas empresas, eu repito, definem isto claramente.
Abraços.
|
Bog
Veterano
|
# nov/08
· votar
ROTTA
Importante esclarecer que, neste esquema, um percentual muito pequeno das decisões técnicas caberia ao programador. Todos os três papéis que citei programam, em ordem inversamente proporcinal ao nível de abstração que atuam.
Ahhhhhnnmm. Estou começando a sacar. Mas então, por exemplo, na SITUAÇÃO #2, de quem é a responsabilidade por decidir fazer um truque com ponteiros e a cópia do bloco inteiro de memória, em vez de um par de for's e o set pixel a pixel?
cenário "analista + programador", tão típico nas empresas Brasil afora.
Eu sou obrigado a admitir que esse é o único cenário que eu vi enquanto estava na faculdade - seja nos estágios, seja nas conversas com colegas, seja nos projetos feitos com empresas contratadas. Por isso, obviamente a minha opinião é enviezada. Mas foi por encontrar esse cenário com tanta frequência que em 2001 eu decidi que ia ser cientista, e não trabalhar no mercado corporativo. Não acho que as coisas tenham mudado tão radicalmente nesses 7 anos, mas é bom saber que alguém notou que essa divisão onde um desenha diagramas e o outro suja as mãos só funciona em projetos onde o programador só "liga os fiozinhos".
A propósito, notei que andam falando de "arquiteto" ultimamente. Ehehehe, acho que mais alguém, além de mim, achou que engenharia de software tinha mais a ver com arquitetura do que com engenharia. :P
|
ROTTA
Veterano |
# nov/08 · Editado por: ROTTA
· votar
Bog
Mas então, por exemplo, na SITUAÇÃO #2, de quem é a responsabilidade por decidir fazer um truque com ponteiros e a cópia do bloco inteiro de memória, em vez de um par de for's e o set pixel a pixel?
Normalmente, no cenário que passei, é do projetista. Se for algo arquiteturalmente muito relevante (não parece ser o caso), pode partir do arquiteto. O importante é que os papéis não estão isolados; pelo contrário.
Mas foi por encontrar esse cenário com tanta frequência que em 2001 eu decidi que ia ser cientista, e não trabalhar no mercado corporativo. Não acho que as coisas tenham mudado tão radicalmente nesses 7 anos
Eu fiz o caminho inverso. Achei que seria cientista, comecei e acabei virando gestor.
A propósito, notei que andam falando de "arquiteto" ultimamente. Ehehehe, acho que mais alguém, além de mim, achou que engenharia de software tinha mais a ver com arquitetura do que com engenharia. :P
Não só falando. O papel existe e é o supremo decisor técnico do projeto. A Microsoft, por exemplo, usa um conceito mais alto nível para arquiteto, mas também possui o papel/cargo. Até onde sei, não é tão incomum assim...
Abraços.
|
Bog
Veterano
|
# nov/08 · Editado por: Bog
· votar
ROTTA
no cenário que passei, é do projetista
Pronto, agora estou começando a entender, hehehe. Realmente, é uma organização diferente da que eu vi tantas vezes na minha frente. Obrigado por esclarecer. Talvez eu até fosse um pouquinho mais feliz no mundo corporativo se entrasse numa empresa com essa mentalidade - eu poderia continuar "sujando as mãos", e deixaria a parte burocrática de acessar banco de dados e ler arquivos de entrada para o programador-pedreiro, hahaha. Sei que na época, a idéia de viver como os meus colegas me pareceu bem distante do que eu queria para mim.
Quanto ao negócio do "arquiteto", eu disse "falando" no sentido de chamar desta forma. Se chamam assim, é porque outras pessoas (com mais relevância que eu!) concordam com aquilo que eu disse lá no meu 1o post, que "engenharia de software" na verdade devia ser "arquitetura de software", hehehe. Mas isso não é uma coisa recente mesmo, desde que eu ouvi o termo "engenharia de software" a primeira vez, comeceri a pensar que o trabalho parecia muito mais com o de um arquiteto do que com o de um engenheiro. É só terminologia, mas ainda assim, é bom para diferenciar as coisas. Embora isso ainda não os livre totalmente do CREA, hahahah...*
*A historinha aqui é que teve uma universidade estadual do Paraná que queria fazer um curso de Engenharia de Software, com foco diferente de Ciência da Computação ou Sistemas de Informação. Acho que a idéia era boa, mas por problemas com o CREA, ficaram com o nome de CC mesmo, apesar de estarem bem mais voltados para a produção de software do que para a parte científica. Se eles tentassem fazer um curso de "Arquitetura de Software", o CREA continuaria no pé deles. =/
|