Joel 테스트는 얼마나 최신 상태입니까? [닫은]

파트너에게 사양이 있어야하고 새 코드를 작성하기 전에 버그를 수정해야한다고 설득하고 싶습니다. Joel 테스트를 참조해야합니까 ? Joel 테스트가 최신이라고 생각하십니까? 사양이없는 것이 나쁜 프로젝트 관리라고 생각합니다. Joel 테스트에 동의하십니까? 무언가를 추가 할 수 있습니까? 예를 들어 오픈 소스는 언급하지 않습니다.

필자는 Joel 테스트가 최신이라고 생각합니다. "영원한"소프트웨어 쓰기만큼 최신입니다.

사양없이 제품 개발 (소프트웨어 개발 포함)을하는 것은 광기입니다.

가고 싶은 곳을 어떻게 알 수 있습니까?

스펙 작성에 대해 한 가지 요점이 있습니다 (실제로 Joel의 스펙이 매우 우수하다고 생각하지는 않습니다. 아무것보다 낫지 만 가능한 한 좋지는 않습니다). 요점은 :

사양을 작성할 때는 제품이 어떻게해야하는지 말고 제품이해야 할 일만 말하십시오.

이것은 스펙에서 구현 세부 사항을 지시하지 않음을 의미합니다. 그것은 디자인 활동이며 디자이너의 경험과 창의성에 맡기십시오.

[이 규칙에는 단 하나의 예외가 있습니다 : 때로는 특정 구현 세부 사항 또는 메소드가 필수이거나 필요한 경우에이를 삽입해야합니다. 예를 들어, 소프트웨어 를 PHP로 작성 해야 하고 협상 할 수없는 경우 사양. 이 경우는 거의 없습니다.]

버그 추적이 없다는 것은 동등한 광기의 행위입니다. 그것은 운영하기에 가장 전문적이고 어리석은 방법이며 큰 고통과 고통으로 이어질 것입니다.

나는 여기서 악마의 옹호자를하고 조엘 테스트가 최신이 아니라고 제안 할 것이다. 너무 일반적입니다. 기술이 발전함에 따라 테스트를 작성할 때보 다 질문이 더 구체적이어야합니다.

사용자 사례와 민첩한 개발 프로세스가 있으므로 사양 문서, 최소한 큰 선행 사양 문서는 필요하지 않습니다. 이 질문은 "설계된 솔루션에 적합한 문서 수준입니까?"로 변경해야합니다. 2 주마다 제공되는 더 작고 더 단단한 사용자 스토리는 대부분의 경우 제품을 자세히 설명하는 큰 선행 문서보다 훨씬 유용합니다. 그러나 다음 Mars Rover를 구축하는 경우 자세한 선행 설계 문서가 필요할 수 있습니다. 회사에 설계 사양이 있는지 묻는다면 "실제로 우리는 민첩한 프로세스와 사용자 스토리를 사용하지 않습니다"라는 응답을 듣는 것에 놀라지 않을 것입니다.

둘째, "일일 빌드"질문은 지속적인 통합에 대한 질문으로 바뀌어야합니다. 빌드하는 데 몇 시간이 걸리는 소프트웨어 (빌드의 99.99 %가 수행하지 않을 것)를 작성하지 않는 한, 회사는 지속적인 통합을 사용하는지 여부를 질문해야합니다.

Joel 테스트의 대부분은 실제로 날짜가 없습니다. 여전히 작업 환경을 나타내는 좋은 방법입니다.