Melhor Metodologia de Desenvolvimento para uma Pessoa?

76

Eu gasto muito tempo trabalhando em projetos nos quais sou o único desenvolvedor, gerente de projeto, designer, pessoa do QT (Sim, eu sei ... Ruim!), e às vezes até sou cliente.

Eu tentei quase tudo para planejar projetos e gerenciar a mim mesmo, desde apenas sentar e trabalhar de forma livre até que o projeto termine, seja o tempo que for necessário, até uma versão para uma pessoa do scrum na qual realizei uma reunião de progresso comigo mesmo mais de um homem queimar gráfico todas as manhãs (não está brincando).

Para aqueles de vocês que passam muito tempo trabalhando sozinhos, qual é a melhor maneira de se organizar, gerenciar projetos grandes (para uma pessoa) e manter a produtividade o mais alta possível?

    
por gnat 17.10.2008 / 22:12
fonte

16 respostas

28

Manter uma lista clara de seus objetivos é vital. É fácil para o rastreamento de recursos assumir um projeto autogerenciado. O TDD "é feito quando funciona" abordagem é útil também. Isso evita que você se torne um perfeccionista.

Uma coisa que realmente me ajuda é imaginar o que outro engenheiro ou gerente de projeto diria em qualquer situação. Muitas vezes eu sou capaz de "me envergonhar" de código ruim, ou voltar no caminho certo se a programação está escorregando.

    
por 17.10.2008 / 22:17
fonte
23

Aqui você vai ... link

O XP aumenta muito bem, pois é ideal para equipes pequenas e focadas.

  • Você pode criar uma planilha de solicitações de recursos, priorizá-las & escolha o mais alto.
  • defina os critérios de aceitação (como é feito) e codifique-os em um teste executável
  • Em seguida, defina as tarefas de engenharia para realizar o trabalho
  • Escreva testes unitários, faça a coisa mais simples (YAGNI) e refatore o tempo todo. O objetivo é fazer com que o teste de aceitação externo passe
  • Timebox de cada sessão. Para uma gestão eficaz do tempo, você também pode consultar a técnica Pomodoro .
  • Use o controle de versão & Configure um servidor de IC / um arquivo de lote para criar uma instalação ou um zip do seu software
  • Demo frequentemente. Encaminhar o feedback para a planilha original e redefinir prioridades

A única coisa que você não pode fazer em um time de um é o PairProgramming.

    
por 21.10.2008 / 03:55
fonte
16

Se você estiver trabalhando sozinho. Aqui estão os conselhos:

  1. Faça o menor trabalho de baixo nível possível. Use o máximo de biblioteca e ferramentas que você puder, incluindo coisas que você acha que pode codificar facilmente (não faça isso, apenas use a biblioteca).
  2. Adote a abordagem de cima para baixo. Apenas codifique coisas que você realmente precisa.
  3. Quando você vir um problema em um termo abstrato, pesquise no google e use documentos de pesquisa da comunidade acadêmica que já foram comprovados. Você só precisa codificar seu algoritmo.
  4. Projete seu sistema para que você possa alterar livremente as coisas o máximo possível. (incluindo copiar e colar algum código daqui até lá). O objetivo é poupar tempo quando você perceber que cometeu um erro. Tente minimizar a quantidade de trabalho que você tem que jogar fora quando você cometer um erro. Um pedaço de código que tem que ser jogado fora (em vez de copiar e colar daqui e de lá) é a equivalência de tempo que você perdeu escrevendo esse código.
  5. Muitos testes automatizados para que você possa fazer regularmente testes de regressão sempre que fizer uma alteração
  6. Separe as responsabilidades de seu design (isto é, reduza o acoplamento). Tornar as coisas tão modulares quanto possível
  7. Use um depurador para depurar e usar a pesquisa binária para encontrar defeitos.
  8. Refatore constantemente seu código para reduzir a exposição (explícita) de acoplamento e métodos públicos (acoplamento implícito).
  9. Nada realmente. Isto é aqui apenas no caso de eu poder fazer algo novo: P
por 07.07.2014 / 18:33
fonte
13

Revisões de código.

Estes são particularmente úteis, pois você estará explicando o código para alguém que não tenha trabalhado no mesmo projeto para que eles não tenham nenhuma suposição sobre como ele deve funcionar.

Eles também terão o benefício adicional de compartilhar conhecimento em torno da empresa, então quando alguém tiver que trabalhar no projeto (devido a pessoas ocupadas em outro lugar, doentes, tendo renunciado ou sido demitido) elas não precisarão começar do zero.

    
por 28.03.2011 / 22:39
fonte
7

Na minha empresa, o nosso grupo trabalha no mesmo projeto, mas em partes relativamente independentes dele. Uma coisa que fazemos muito por aqui é quando algo que você está fazendo parece um pouco complicado, ou você está em uma bifurcação na estrada com mais de uma maneira de implementar algo, você pega outra pessoa e discute os prós e contras antes você prossegue. Se você esperar até considerar o seu código terminado para fazer uma revisão, você normalmente já investiu muito tempo para considerar grandes mudanças na arquitetura, embora certamente muitos defeitos sejam descobertos em revisões de código.

Além disso, percebo que o Test Driven Development é um pouco chavão saturado ultimamente, mas pode ser uma grande ajuda para desenvolvedores solo porque ele fornece uma verificação de qualidade e, quando os testes se tornam difíceis de gravar, você provavelmente precisa de alguns reestruturação do seu código. Também ajuda os mantenedores posteriores a não quebrarem acidentalmente o código em maneiras difíceis de detectar.

    
por 28.03.2011 / 23:52
fonte
6

Eu rolei minha própria versão de agile que conta com histórias, interação intensa com o cliente, lançamentos frequentes e desenvolvimento orientado a testes. Eu uso um wiki para rastrear histórias, envolver o cliente o máximo possível para escrevê-las e fazer com que o cliente trabalhe comigo para priorizar e organizar os lançamentos. Eu uso o TDD para conduzir o design e implementar. Eu configuro um servidor de controle de qualidade onde o cliente pode experimentar lançamentos freqüentes (às vezes diariamente, à medida que novos recursos são desenvolvidos) para que eu obtenha feedback rapidamente. Eu raramente faço mais de 3 iterações sem liberação para o controle de qualidade. O cliente decide quando a versão do controle de qualidade tem recursos suficientes para serem ativados - e se nenhum outro recurso da lista precisar ser desenvolvido.

    
por 17.10.2008 / 22:20
fonte
4

Sugiro-lhe o seguinte:

  1. Desenvolvimento orientado por testes
  2. Eavy uso de "TODO: note aqui" no seu código quando você vê algo que você não é capaz de fazer imediatamente, e volte para eles quando tiver tempo para ficar no facebook esperando pelo seu cliente ligar de volta
  3. Escreva seu código como seu cliente irá comprá-lo olhando o código não apenas no resultado, imagine seu cliente como o presidente de uma revisão de código.
  4. Preencha seu código de afirmações
por 29.12.2008 / 17:12
fonte
3

Eu gostaria de poder dizer que eu era capaz de praticar o que eu prego 100% do tempo, mas o BDD parece ser uma boa abordagem para entender sua situação:

Este é um link com mais informações: link

    
por 17.10.2008 / 22:18
fonte
2

Eu estou em um barco muito parecido. Eu tento seguir princípios ágeis (assim como os entendo) o máximo possível. Provavelmente não estou fazendo as coisas "corretamente", mas tive muito sucesso em meus projetos tentando seguir princípios ágeis. É preciso muita disciplina, pois não há equipe para garantir que você não comece a usar atalhos.

    
por 17.10.2008 / 22:16
fonte
2

Eu acho que usar ferramentas de formatação de código, como o ReSharper, garante que, pelo menos visualmente, o código seja fácil de pegar para outros desenvolvedores.

Em termos de metodologias reais, é difícil para um único desenvolvedor ficar com qualquer um em particular. Eu sou um consultor que geralmente trabalha sozinho, e acho mais fácil para mim e para o cliente usar um processo ágil. Eu normalmente tento fazer com que meus clientes insiram diretamente seus requisitos em uma ferramenta como o Trac (ou eu, em seu nome). Isso não só ajuda outros desenvolvedores a identificar o propósito do código, mas também a si mesmo 3 meses depois!

    
por 28.03.2011 / 22:54
fonte
2

filosofia: XP / TDD + GTD

descrição geral:

  • entreviste as partes interessadas
  • modelos de protótipos, passo a passo, protótipos de papel (conforme necessário)
  • brainstorming de feature / story (com e sem stakeholders)
  • brainstorming de caso de teste (com e sem stakeholders)
  • tempo de design / arquitetura geral (conforme necessário)
  • planejamento de iteração (com partes interessadas)
  • iterações
  • revisão de processos, treinamento, planejamento de manutenção, etc. (conforme necessário)
por 02.04.2011 / 01:35
fonte
1

Qualquer metodologia apropriada ajudará - independentemente do número de pessoas no projeto. Portanto, escolha uma por vez e veja como você pode se inscrever e mapear seu domínio e medir seus sucessos.

Talvez seja mais interessante perguntar quais são as metodologias para não jogar fora porque há apenas uma pessoa trabalhando no projeto.

E o principal que se destaca para mim é o controle de origem (sim, isso é uma ferramenta, mas faz parte do seu fluxo de trabalho, portanto, também um processo). As pessoas podem se sentir tentadas a dar isso, já que "não precisam suportar várias pessoas editando o código ao mesmo tempo".

Ironicamente, acho que uma solução de controle de versão distribuída como o GIT é melhor para um indivíduo que é algo como o SVN.

    
por 28.03.2011 / 22:49
fonte
0

Se o código for descartável, pode ser um pouco solto com metodologias, mas qualquer coisa importante e eu diria que sua maneira de tratá-lo como um projeto de equipe com uma pessoa é muito boa e disciplinada.

Escreva seu código para o próximo cara ler, não você ... seja legal com ele / ela. Até mesmo o código "jogar fora" permanece para sempre.

    
por 17.10.2008 / 22:15
fonte
0

Ágil

recursos, histórias e casos de teste são muito mais instrutivos do que documentação mais formal, e um conjunto de testes de trabalho é melhor para demonstrar como usar algo ou como algo funciona do que qualquer quantidade de árvores mortas

Também é mais fácil entregar o trabalho entre as iterações.

    
por 28.03.2011 / 23:00
fonte
0

Como consultor, sugiro que você encontre uma maneira de sempre haver pelo menos dois desenvolvedores em qualquer tarefa.

Concordo em ser ágil e em deixar um rastro ágil de histórias e testes que outras pessoas podem seguir, mas não acredito que ou qualquer outro processo ou metodologia irá ficar enquanto as pessoas estão trabalhando no solo.

    
por 29.03.2011 / 04:25
fonte
0

Acho que as revisões de código são um bom começo, mas gosto quando é informal e divertido, como fazer uma revisão de código de par ou emparelhar programação para resolver um determinado problema / problema ou algum aprimoramento (por exemplo, alterar código legado para atender novos padrões de codificação). Às vezes dois pares de olhos são melhores que um e também é divertido, eu sinto que compartilhar e discutir parece mais aberto. Você também pode ter como almoço formal / informal e discutir sessões para falar sobre o que você fez individualmente ou como um grupo, por exemplo. mencionar sobre um novo padrão que você usou ou novas tecnologias como um problema foi resolvido?

    
por 28.03.2011 / 22:48
fonte