Ambiente interno versus ambiente de desenvolvimento de software [fechado]


13

Na indústria, existe uma distinção entre um ambiente de 'desenvolvimento interno' em que os desenvolvedores de software escrevem um código que será usado pela própria empresa e um ambiente adequado de 'desenvolvimento de software' onde o software é construído para ser vendido / distribuído para o público.

Entre outras, uma diferença óbvia entre as duas é que uma empresa orientada para o desenvolvimento de software normalmente adere a algum tipo de ciclo de vida de desenvolvimento de software, como redação de especificações, testes, construção etc., enquanto a loja interna orientada geralmente faça as coisas de uma maneira mais casual, pois eles próprios são os usuários finais e sempre podem consertar algo que não foi feito corretamente.

Como estudante (como a maioria dos outros estudantes), eu meio que esperava que acabasse trabalhando em um ambiente de desenvolvimento de software, mas acabei conseguindo minha primeira posição em uma empresa que opera de maneira mais interna.

Às vezes, me pergunto se estou perdendo a experiência de desenvolvimento de software completa. Existe uma base para esse sentimento? Devo procurar ingressar em um ambiente de desenvolvimento de software adequado?


9
Eu acho que você está generalizando demais. As metodologias utilizadas não têm nada a ver com produtos internos versus projetos vendidos comercialmente. Eu trabalhei em um produto enviado que foi desenvolvido muito ad-hoc, ignorando muitas das que seriam consideradas práticas recomendadas. Também trabalhei em projetos internos que tinham especificações detalhadas, suítes de testes e uma infinidade de práticas de controle de qualidade.
Thomas Owens

As duas perguntas que você colocou só podem ser respondidas por você.
Leo

6
IMHO, seu problema não tem nada a ver com perder a empresa interna vs. a empresa de software. Parece que você está sofrendo por estar em um ambiente de desenvolvimento não estruturado e por não ter um mentor forte que o ajude a seguir as melhores práticas.
maple_shaft

1
Quer o software seja desenvolvido para venda ou para uso interno, tudo é chamado de "desenvolvimento de software". Comercial pode ser um termo melhor do que o que você chama de 'desenvolvimento de software'.
Caleb

1
Você está fundindo duas dimensões do desenvolvimento de software - processo de desenvolvimento estruturado ad-hoc x estruturado e desenvolvimento interno x produto. O grau de cada um pode variar de forma independente.
Sean McMillan

Respostas:


13

Na minha experiência, a distinção que você está fazendo entre "internamente" e "produto distribuível" é falsa.

Existem empresas que levam a sério o processo de desenvolvimento de software e outras que não. Se eles estão "em casa" ou "sob medida" ou "encolhimento" tendem a não ser tão importantes (embora se sejam provedores de encolhimento), se não tiverem processo, provavelmente não estarão no mercado para grandes).

Você deve procurar um local com os padrões de desenvolvimento que procura - ao entrevistar, é necessário fazer essas perguntas para garantir que o local seja do seu agrado a esse respeito (assim como a outros).


Eu estava escrevendo algo parecido com isso quando você postou. +1 apenas para a última frase, embora sejam todos pontos válidos.
Thomas Owens

@ThomasOwens - Sim, vi o seu comentário à pergunta depois de postar minha resposta e estava esperando uma resposta bem de você;)
Oded

10

Você pode ler este artigo

http://www.joelonsoftware.com/items/2007/12/04.html

de Joel Spolsky, que está lidando exatamente com sua pergunta.

Estou em uma posição em que tive que trabalhar nos últimos anos - um produto de software de médio porte sendo vendido e alguns softwares internos. A partir dessa experiência, posso dizer que há diferenças entre essas duas plataformas, mas a situação não é tão ruim quanto Joel a descreveu.

Por exemplo, a maioria do nosso software interno precisa ser executada apenas em um ambiente muito restrito. Muitas ferramentas trabalham apenas com uma certa planilha ou versão de banco de dados, com um ambiente de rede específico, com um número restrito de usuários, sem necessidade de rotina de instalação etc. Isso facilita muitas coisas e facilita o desenvolvimento, em comparação com os novos recursos introduzidos no nosso produto de envio. Por outro lado, isso não significa que meu código para os programas "internos" tenha uma qualidade inferior ou seja escrito de uma maneira "casual".


6

Há muito tempo, li um livro sobre Gerenciamento Ágil de Projetos (gostaria de lembrar o título), onde o autor distinguia sistemas com base em seus níveis de tolerância a defeitos no sistema. A tolerância a defeitos pode variar de muito alto - por exemplo, um utilitário usado por outros desenvolvedores (onde os bugs são apenas um inconveniente) a muito baixo - por exemplo, um sistema que esteja executando suporte de vida para astronautas (onde um bug poderia ameaçar a vida).

O argumento do autor era que a metodologia (e formalidade) de desenvolvimento precisava ter um escopo definido para a tolerância a falhas (ou criticidade) do sistema. Eu acho que essa distinção é a mais importante, em oposição à distinção entre desenvolvimento interno versus software para distribuição geral.

Imagine um hospital com desenvolvedores internos construindo sistemas de registros médicos que possam afetar a qualidade dos cuidados médicos. Nesse caso, a loja interna provavelmente seria mais rigorosa do que uma consultoria de site, que está construindo produtos da web para serem usados ​​pelo público em geral.


3

Trabalhei em empresas de software, agências de marketing, empresas de telefonia móvel e bancos, uma coisa que direi: é a cultura e a indústria da empresa que ditam o nível de processos aplicados. O ambiente mais rigoroso, lento, restritivo e testado que já experimentei foi o desenvolvimento interno de um banco. O mais casual foi uma agência de marketing.

Eu recomendaria aprender com essa experiência e usá-la para decidir sua direção futura para o seu próximo trabalho. A indústria de desenvolvimento de software não é uma ciência, sua arte / ciência, portanto, a variação e as diferenças de empresa para empresa. É mais importante que você aprenda a fazer as coisas corretamente em relação ao seu código. Embora seja útil anotar mentalmente as falhas ou a falta de processos, quando seu gerente puder implementar processos melhores.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.