Como posso superar um modelo de desenvolvimento de software mal estruturado?

Entrei para a empresa atualmente em que estou trabalhando como atualizadora. Devido ao número limitado de pessoas qualificadas no desenvolvimento de software GIS, e como eu estava entre um deles, fui recrutado diretamente como Gerente de Projeto.

Eu estava bastante familiarizado com Java e GIS e fiz pesquisas motivadas em serviços baseados em localização, mas não em gerenciamento de projetos e desenvolvimento de software estruturado. Foi um ano após minha graduação como especial em Geologia e durante o ano anterior eu estava trabalhando como acadêmico em uma universidade.

Graças ao interesse que eu estava tendo no trabalho, apareceu uma oportunidade e, eventualmente, fui responsável pelo departamento de Business Intelligence da empresa. A empresa acreditou em mim. Eu próprio estudei data warehousing e conceitos de BI e consegui combinar GIS com BI também.

Atualmente, também estou trabalhando com dois desenvolvedores em nossa ferramenta de BI em C # WPF, onde também desempenho o papel de desenvolvedor às vezes (o que eu gosto).

Eu tentei extremamente adotar boas metodologias de desenvolvimento de software com gerenciamento ágil de projetos, mas não teve muito sucesso. Além disso, embora eu acredite em códigos bem projetados no que diz respeito a um produto, devido à falta de conhecimento técnico que meu CEO possui (que está diretamente acima de mim), normalmente não recebo a quantidade de tempo necessária para fazê-lo. O tempo gasto é bastante aprimorado pela falta de conhecimento que temos na linguagem de codificação específica como um todo também (por exemplo, o WPF em oposição ao Java). Também não existe um sistema de controle de versão em vigor.

Estou extremamente farto do modo como as coisas estão indo, pois não está estruturado e acho que passo a maior parte do tempo pensando em como estruturar as coisas. Espero que vocês com boa experiência profissional possam me ajudar a superar essa situação.

Tivemos um problema semelhante (sem os detalhes técnicos, é claro) na empresa em que trabalho cerca de dois anos atrás.

Você só precisa fazer um passo de cada vez. Não tente adotar o desenvolvimento ágil de software com pressa. Há muitas coisas para aprender e aplicar. Também não deixe que a falta de conhecimento o derrube.

Construa devagar (mas o mais rápido que puder: P), de forma constante e segura.

Eu recomendaria as próximas etapas (para fazer isso, você pode mudar de gerenciamento para desenvolvimento por um tempo, mas isso deve ser bom)

1. Aprenda um bom sistema de controle de versão e aprenda-o bem. Pessoalmente, eu recomendaria git ou mercurial. Há muita documentação em ambos.
2. Crie um núcleo sólido de práticas e padrões . Leia livros, leia blogs, assista a screencasts com os membros da equipe. Isso dará um novo ar ao desenvolvimento.
3. Aprenda TDD / BDD e tente aplicá-lo no novo código , bem como no código antigo que você pode tocar ao executar um novo recurso.
4. Faça programação emparelhada . Duas cabeças pensam melhor que uma, e também 4 olhos são melhores que 2 :).
5. Encontre as ferramentas usadas mais recentes e mais comuns na comunidade do idioma que você está desenvolvendo atualmente. Aprenda sobre eles e tente incluir alguns deles no projeto. Veja como elas foram criadas e aprendidas.
6. Use scrum . Iterações, histórias, pontos da história, impedimentos são todos os conceitos com os quais você deve se familiarizar. Para mim, o scrum provou ser o melhor fluxo de trabalho para desenvolvimento e gerenciamento de software. Aplique e aprenda com a experiência de cada dia.
7. Ensine pelo exemplo . A maioria dos desenvolvedores iniciantes está ansiosa para aprender coisas novas, mas também alguns são muito preguiçosos. De qualquer forma, mostre a eles as novas coisas que você aprendeu e aplicou, e espero que isso agrade seus cérebros.

Além disso, se possível, contrate um consultor apenas para que ele possa verificar o processo e dar melhores conselhos.

Não fique preguiçoso ou desanimado. Apenas aprenda com seus erros e tente abordagens diferentes. Isto é apenas o começo!

Editar:

Aqui estão alguns dos links e livros que tenho lido / usado recentemente ...

Git de aprendizagem: Pro Git

Estes são alguns dos blogs que eu recomendaria (a maioria deles é orientada ao .NET):

• Blogs em Java
• O blog de Karl Seguin e sua série Foundations of Programming.
• CodeBetter.com
• Código pensado
• Los Techies
• Clean Coder
• E também este link para uma questão de estouro de pilha.

Para livros, você pode ver a lista Buiding A Solid Programming Core na amazon. Eu também recomendaria estes:

• Código Limpo
• Desenvolvimento Ágil de Software, Princípios, Padrões e Práticas
• Quase qualquer livro da Estante Pragmática

Como gerente, é seu trabalho obter o tempo necessário para concluir um projeto corretamente. Ao abordar o CEO, verifique se você tem todos os números que o apoiam e explique por que as estimativas são tão longas quanto são. É sua responsabilidade como gerente fazer com que o CEO entenda por que leva n horas / dias / semanas para concluir uma determinada tarefa. Às vezes, isso pode ser difícil, mas ainda não conheci um CEO que queira que sua empresa falhe e aposto que, se você colocar nesse tipo de termos (se tudo mais falhar), ele poderá mudar de ideia.

Se o CEO não estiver disposto a conceder a você o tempo necessário para concluir as tarefas, então IMHO, esteja pronto para seguir para outro emprego ou se preparar para as marchas da morte contínuas. Como último recurso, explique ao CEO o desgaste que, sem dúvida, virá de expectativas irreais.

Dito isso, você também precisa garantir que seus desenvolvedores estejam fornecendo estimativas precisas (tremendamente difícil, quase impossível sem os projetos técnicos adequados , que também devem estar em algum lugar).

O Agile não é bom em todos os domínios de desenvolvimento. Funciona para alguns tipos de projetos, falha miseravelmente em outros. Pode ser necessário tentar algumas metodologias diferentes antes de encontrar uma que funcione bem .

Configure o controle de versão . Realmente, leva de 5 a 10 minutos para configurar o Git, mais alguns minutos para que as operações básicas sejam executadas e um ou dois dias de leitura para que os conceitos mais avançados sejam reduzidos.

Hmm, não tenho certeza se eu te conheci em um evento Agile / XP em Toronto - isso parece familiar

Parece que você precisa de uma pausa. Tire um longo fim de semana, fique bêbado, se quiser, e esqueça o trabalho por alguns dias.

Facilite-se. O autodidata é bom, e apenas porque uma metodologia não funciona com as personalidades envolvidas, não significa que você está fazendo errado e não é um fracasso pessoal.

Há um site (beta) pm.stackexchange.com, direcionado ao Gerenciamento de Projetos, você pode obter alguns conselhos / suporte úteis lá - mas, por todos os meios, mantenha a pergunta aqui também.

Passando para o material técnico:

não existe um sistema de controle de versão

Coloque um como sua principal prioridade. Prefiro sistemas centralizados como o SVN (Subversion) ao invés de git / mercurial, porque um laptop roubado não tem tanto histórico localmente. Especialmente importante se algo super-secreto (como senhas e ssh-keys) fosse verificado por engano. Mas, é uma questão de gosto. Nada perde mais tempo do que bugs do 'controle manual de versão' - por exemplo, colocar o código de volta ao que você pensa que era.

Boa sorte

Parece que você tem vários problemas: 1. Comunicação com a gerência sênior não técnica para que eles apóiem ​​seu programa de aprimoramento; e 2. Dirigir o programa de melhoria para o sucesso.

A parte mais difícil do número 1 é simplesmente lembrar que a gerência sênior geralmente não se interessa pelos detalhes do que está trabalhando. (Se eles estivessem, eles mesmos estariam fazendo isso em vez de entregá-lo a você!) Parece que o grande obstáculo é o 'porquê' e você pode consultar o CMM 1.1 para obter uma descrição dos benefícios comerciais de uma melhoria de processo. programa. Se você usa o CMM ou algo mais para realmente melhorar seu processo, não importa para essa discussão, apenas os dados do estudo Carnegie-Mellon, que mostra que organizações mais maduras entregam projetos mais rapidamente, com menos variação no tempo de entrega.

Existem muitos caminhos para o sucesso na melhoria de processos, todos eles tendem a ser muito longos. A experiência com o CMM mostra que pode levar de 8 a 10 anos para passar do nível 1 ao 5. A experiência com 6 sigma mostra que cada iteração melhora um pouco, mas precisa de várias iterações para remover a maioria dos problemas em potencial e, quando você chegar a Com seis sigmas de qualidade, o trabalho está sendo realizado de maneira completamente diferente, sem ter que correr o risco de tentar substituir tudo de uma vez.

Se houver uma abordagem de melhoria de qualidade comumente usada em seu setor, tente ver como ela se aplica ao software e use-a para que o resto da empresa ouça sobre algo com o qual já esteja familiarizado e que apóie. Podemos conversar por horas sobre ferramentas e práticas específicas de software, mas os CEOs que não são de software o ajustarão rapidamente. Fale sobre as práticas padrão da indústria e ele se animará porque você está falando o idioma dele. Fale sobre software nos termos comuns do setor e ele começará a fazer perguntas relevantes para entender melhor seus desafios e seus planos para melhorar os resultados das empresas.

Você não receberá todas as solicitações de suporte dessa maneira; provavelmente terá muito menos aparências em branco e mais vitórias!

Boa sorte, senhor!

Todas as suas sugestões são realmente sensatas e são o caminho a seguir em muitas empresas. Mas eles não são universais, especialmente com equipes que não são tão experientes. A razão pela qual eles não são é que eles exigem uma certa quantidade de trabalho para configurar e manter - mesmo controle de versão - o que muitos supõem serem apostas em mesa para qualquer projeto de software. Por exigirem algum trabalho, também precisam oferecer algum benefício. E pode ser que, na sua situação específica, eles não o façam! Ou pelo menos as pessoas encarregadas de tomar as decisões não vêem o benefício!

Como outros já apontaram, você precisa:

• Tente adotar as práticas por sua vez. Não tente todos eles de uma vez, pois isso sobrecarregará as pessoas.
• Você precisa descobrir uma boa ordem para isso. Eu começaria com o controle de versão. Vá também com os mais fáceis. Quando as pessoas começam a confiar que você toma boas decisões e vêem os benefícios, é mais provável que adotem mudanças mais arriscadas.
• Crie um argumento sólido sobre o motivo pelo qual algo precisa ser implementado. Com 2-3 desenvolvedores que estão constantemente tornando o progresso visível para os usuários finais, é difícil justificar a adoção de uma metodologia de desenvolvimento mais elaborada, por exemplo. Você será visto como focado no processo e não no resultado.
• Tenha em mente quem você precisa convencer. Os desenvolvedores? O CEO?