Passo muito tempo trabalhando em projetos nos quais sou o único desenvolvedor, gerente de projeto, designer, responsável pelo QT (Sim, eu sei ... Ruim!), E às vezes até sou o cliente.

Eu tentei de tudo para planejar projetos e gerenciar a mim mesmo, desde sentar e trabalhar no estilo livre até que o projeto seja concluído o tempo que for necessário, até uma versão individual do scrum na qual realizei uma reunião de progresso comigo mesma. -man queima gráfico todas as manhãs (sem brincadeira).

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

Manter uma lista clara de seus objetivos é vital. É fácil para a fluência de recursos assumir um projeto autogerenciado. A abordagem TDD "é feita quando funciona" também é útil. Isso impede 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. Frequentemente, sou capaz de "me envergonhar" de códigos incorretos ou voltar aos trilhos se a programação estiver caindo.

Aqui você vai ... http://xp.c2.com/ExtremeProgrammingForOne.html

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

• Você pode criar uma planilha de solicitações de recursos, priorizá-las e escolher a que mais se destaca.
• defina os critérios de aceitação (como é a aparência) e codifique-o em um teste executável
• Em seguida, defina as tarefas de engenharia a serem concluídas
• Escreva testes de unidade, faça a coisa mais simples (YAGNI) e refatore o tempo todo. O objetivo é fazer o teste de aceitação externa passar
• Timebox cada sessão. Para um gerenciamento de tempo eficaz, você também pode olhar para a técnica Pomodoro .
• Use o controle de versão e configure um servidor de IC / um arquivo em lotes para criar uma instalação ou zip do seu software
• Demonstre com frequência. Encaminhe o feedback para a planilha original e priorize novamente

A única coisa que você não pode fazer em uma equipe é PairProgramming.

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

1. Faça o mínimo possível de trabalho de baixo nível. Use o máximo de bibliotecas e ferramentas possíveis, incluindo coisas que você acha que pode codificar facilmente (não faça isso, basta usar a biblioteca).
2. Adote a abordagem de cima para baixo. Codifique apenas as coisas que você realmente precisa.
3. Quando você vir um problema no termo abstrato, pesquise no google e use trabalhos de pesquisa da comunidade acadêmica que já foram comprovados. Você só precisa codificar o algoritmo deles.
4. Projete seu sistema para que você possa mudar livremente as coisas, tanto quanto possível. (incluindo copiar e colar algum código daqui para lá). O objetivo é economizar tempo quando você perceber que cometeu um erro. Tente minimizar a quantidade de trabalho que você deve jogar fora quando cometer um erro. Um pedaço de código que deve ser jogado fora (em vez de copiar e colar daqui e dali) é a equivalência de tempo que você perdeu ao escrever esse código.
5. Faça muitos testes automatizados para que você possa fazer regularmente testes de regressão sempre que fizer uma alteração
6. Separe as responsabilidades do seu projeto (ou seja, reduza o acoplamento). Torne as coisas o mais modular possível
7. Use um depurador para depurar e use a pesquisa binária para encontrar o defeito.
8. Refatorie constantemente seu código para reduzir o acoplamento (explícito) e a exposição de métodos públicos (acoplamento implícito).
9. Nada realmente. Isto está aqui apenas no caso de eu poder inventar algo novo: P

Revisões de código.

Isso é particularmente útil, pois você explicará o código para alguém que não trabalhou no mesmo projeto, para que não tenha nenhuma das suas suposições sobre como ele deve funcionar.

Eles também terão o benefício adicional de compartilhar conhecimento em toda a empresa; assim, quando alguém tiver que trabalhar no projeto (devido ao fato de as pessoas estarem ocupadas em outro lugar, doentes, renunciando ou demitidas), não terão que começar do zero .

Criei minha própria versão do ágil, que conta com histórias, interação intensa com o cliente, lançamentos frequentes e desenvolvimento orientado a testes. Uso um wiki para rastrear histórias, envolver o cliente o máximo possível ao 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 a implementação. Configurei um servidor de controle de qualidade no qual o cliente pode experimentar lançamentos frequentes (às vezes diariamente à medida que novos recursos são desenvolvidos) para que eu receba feedback rapidamente. Eu raramente faço mais de três iterações sem uma liberação para o controle de qualidade. O cliente decide quando a versão do controle de qualidade tem recursos suficientes para entrar no ar - e se nenhum outro recurso fora da lista precisa ser desenvolvido.

Na minha empresa, nosso grupo trabalha no mesmo projeto, mas em fatias relativamente independentes. 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ê continua. Se você esperar até considerar que seu código terminou para fazer uma revisão, normalmente você já investiu muito tempo para considerar as principais mudanças na arquitetura, embora certamente muitos defeitos sejam descobertos nas revisões de código.

Além disso, percebo que o Desenvolvimento Orientado a Testes é um chavão saturado ultimamente, mas pode ser uma grande ajuda para desenvolvedores individuais, pois fornece uma verificação de qualidade à medida que avança, e quando os testes se tornam difíceis de escrever, você sabe que provavelmente precisará de alguma reestruturação de seu código. Também ajuda os mantenedores posteriores a não quebrar acidentalmente o código de maneiras difíceis de detectar.

Eu sugiro o seguinte:

1. Desenvolvimento orientado a testes
2. O uso fácil de "TODO: observe aqui" no seu código quando você vê algo que não pode fazer imediatamente e volta para eles quando tiver tempo para permanecer no facebook esperando o cliente ligar novamente
3. Escreva o seu código, pois o seu cliente o comprará olhando o código não apenas o resultado, imagine-o como o presidente de uma revisão de código.
4. Preencha seu código de afirmações

Eu gostaria de poder dizer que fui capaz de praticar o que prego 100% das vezes, mas o BDD parece ser uma boa abordagem a ser adotada em sua situação:

Aqui está um link com mais informações: http://en.wikipedia.org/wiki/Behavior_driven_development

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

Acho que o uso de ferramentas de formatação de código, como o ReSharper, garante que, pelo menos visualmente, o código seja fácil de entender para outros desenvolvedores.

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

filosofia: XP / TDD + GTD

linhas gerais:

• entrevistar as partes interessadas
• modelos de tela, orientações, protótipos de papel (conforme necessário)
• brainstorming de reportagem / matéria (com e sem partes interessadas)
• brainstorming de caso de teste (com e sem partes interessadas)
• tempo de reflexão geral sobre design / arquitetura (conforme necessário)
• planejamento de iteração (com as partes interessadas)
• iterações
• revisão de processos, treinamento, planejamento de manutenção etc. (conforme necessário)

Qualquer metodologia apropriada ajudará - independentemente do número de pessoas no projeto. Portanto, escolha um de cada vez e veja como você pode aplicar e mapear para o seu domínio e avaliar o sucesso deles.

Talvez o mais interessante seja perguntar que metodologias não jogar fora, porque há apenas 1 pessoa trabalhando no projeto.

E o principal que me destaca é o Controle de Origem (Sim, isso é uma ferramenta, mas faz parte do seu fluxo de trabalho, também um processo). As pessoas podem se sentir tentadas a passar isso, já que "não precisam oferecer suporte a 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 do que algo como o SVN.

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

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

Ágil

recursos, histórias e casos de teste são muito mais instrutivos que a 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 me tornar ágil e em deixar um rastro ágil de histórias e testes que outras pessoas possam seguir, mas não acredito que nenhum outro processo ou metodologia permaneça enquanto as pessoas estiverem trabalhando sozinhas.

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