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?
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.
Aqui você vai ... link
O XP aumenta muito bem, pois é ideal para equipes pequenas e focadas.
A única coisa que você não pode fazer em um time de um é o PairProgramming.
Se você estiver trabalhando sozinho. Aqui estão os conselhos:
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.
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.
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.
Sugiro-lhe o seguinte:
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.
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!
filosofia: XP / TDD + GTD
descrição geral:
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.
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.
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.
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.
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?