Quão atualizado é o teste de Joel? [fechadas]

Fechado . Esta questão é baseada em opiniões . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela possa ser respondida com fatos e citações editando esta postagem .

Fechado há 6 anos .

Quero convencer meus parceiros de que devemos ter uma especificação e que os bugs devem ser corrigidos antes de escrever um novo código. Devo me referir ao teste de Joel ? Você acha que o teste de Joel está atualizado? Eu acho que não ter uma especificação é um gerenciamento de projeto ruim. Você concorda com o teste de Joel? Você poderia adicionar algo? Não menciona, por exemplo, código-fonte aberto.

issue-tracking specifications joel-test

— Niklas
fonte

O Joel Test é direcionado aos processos de desenvolvimento de software e contratação de desenvolvedor. Como está a maneira pela qual você licencia seu software ou se publica ou não sua fonte relacionada a isso?

— Marjan Venema

Marjan Obrigado pela pergunta. Eu estava pensando que desde que o teste de Joel foi concebido, o código aberto tem sido uma tendência e, se alguém for muito negativo sobre o código aberto, provavelmente eu gostaria de saber como uma equipe se opõe ao código aberto, se é que é. Concordo que questões de direitos autorais possam estar além do escopo, mas o programador não pode trabalhar com uma equipe que pensa que o código aberto é uma questão de poder visualizar o código-fonte e também a pergunta 13 pode ser "Você tem um sistema de backup?" e 14 "Você tem uma segurança mais forte que o MD5?" onde as respostas devem ser sim.

— Niklas

Ok, isso faz sentido. Os esforços de código aberto devem não apenas ser "consumidos", mas também contribuídos, embora não necessariamente com código (pense em suporte monetário). Os sistemas de backup são importantes, mas não confinados ao desenvolvimento e, como tal, não os adicionaria ao teste de Joel. Mas se eu entrevistei um negócio que não fez nada sobre backups, eu estaria correndo pela porta. Segurança também não acrescentaria. Para a segurança desenvolvida pelo software, pode não ser uma preocupação (aplicativos internos) e, portanto, não se presta a uma resposta sim / não, além da segurança não precisar ser específica para o desenvolvimento.

— Marjan Venema

Obrigado por compartilhar o conhecimento comigo. É verdade que o backup é importante, mas não específico do desenvolvimento.

— Niklas

Muitas boas perguntas geram algum grau de opinião com base na experiência de especialistas, mas as respostas a essa pergunta tendem a ser quase inteiramente baseadas em opiniões, e não em fatos, referências ou conhecimentos específicos.

— mosquito

Respostas:

Acho que o teste de Joel está atualizado - é tão atualizado quanto os outros softwares escritos que são "atemporais".

Fazer desenvolvimento de produtos (que inclui desenvolvimento de software) sem uma especificação é apenas loucura.

Como você sabe para onde quer ir?

Há apenas um ponto que vou fazer sobre escrever uma especificação (na verdade, não acho que as especificações de Joel sejam muito boas ... melhores que nada, mas não tão boas quanto poderiam ser). Esse ponto é:

Ao escrever uma especificação, diga apenas o que o produto deve fazer, não como deve ser feito.

Isso significa que você não determina os detalhes da implementação em uma especificação. Essa é uma atividade de design e você deixa isso para a experiência e criatividade dos designers.

[Existe apenas uma exceção a esta regra: Às vezes, um determinado detalhe ou método de implementação é obrigatório ou obrigatório, nesse caso, coloque-o. Por exemplo, se o software precisar ser escrito em PHP e isso não for negociável, ele será incluído. a especificação. Deve haver muito poucas instâncias disso.]

Devo acrescentar: não ter rastreamento de bugs é um ato de loucura igual. É simplesmente a maneira mais não profissional e tola de operar e levará a uma grande dor e sofrimento.

— rapid_now
fonte

Obrigado pela resposta muito rápida e valiosa. Outro exemplo de loucura que me atingiu foi a afirmação de que tudo deveria ter a mesma prioridade. Parece que fazer o oposto dessas regras malucas levará ao sucesso.

— Niklas

"tudo tem igual prioridade" - também conhecido como "tudo é o número 1". Isso é, francamente, besteira absoluta. Tudo deve ser priorizado, brutalmente, em termos de dano aos negócios. Então você trabalha no # 1. Se você está parado no # 1 por algum motivo, trabalha no # 2. E assim por diante. Se você tem pessoas que não podem trabalhar no # 1 por algum motivo e acabam trabalhando no # 9 - tudo bem, desde que haja um bom motivo. ("Eu me senti assim e seu cooooooool" NÃO é uma boa razão). Também não há problema em priorizar novamente. Fazer isso com mais frequência do que semanalmente também é loucura.

— quickly_now

Obrigado pela sabedoria. Concordo plenamente que tudo deve ser priorizado. Meu parceiro também afirmou que não devemos ter problemas nem rastreador de problemas. Mas acho que documentar problemas é correto e até o líder de mercado mantém um rastreador de problemas. Mais uma vez, fazendo o oposto da regra vai funcionar ...

— Niklas

@ 909Niklas Você provavelmente deve olhar para obter um outro parceiro, para manter a sua vida futura mais confortável ...

— Marcel

+1 apenas para: ao escrever uma especificação, diga apenas o que o produto deve fazer, não como deve ser feito.

— Marcel

Vou interpretar o advogado do diabo aqui e sugerir que o Teste de Joel não esteja atualizado. É muito geral. À medida que a tecnologia amadureceu, as perguntas deveriam ser mais específicas do que quando ele escreveu o teste.

Documentos de especificações, pelo menos grandes documentos de especificações iniciais não são necessários agora que temos histórias de usuários e processos de desenvolvimento Agile. Esta pergunta deve ser alterada para "O nível de documentação é apropriado para as soluções que estão sendo projetadas?" Histórias de usuários menores e mais restritas, que são entregues a cada duas semanas, são muito mais úteis na maioria dos casos do que um grande documento inicial que descreve o produto em detalhes. No entanto, se você estiver construindo o próximo Mars Rover, convém um documento de projeto detalhado detalhado. Se você perguntasse se uma empresa possui especificações de design, não ficaria surpreso ao ouvir uma resposta "na verdade, não usamos processos ágeis e histórias de usuários".

Em segundo lugar, a pergunta "compilações diárias" deve mudar para uma pergunta sobre integração contínua. A menos que você esteja criando um software que leva horas para ser construído (o que 99,99% dos locais não o fará), a pergunta deve ser feita se a empresa usa integração contínua.

A maior parte do teste de Joel realmente não foi datada. Ainda é uma boa maneira de obter uma indicação do ambiente de trabalho.

— Stephen
fonte