답변:
Jeff Atwood는 프로그래머의 권리 장전을 가지고 있습니다.
게시물에서 :
- 모든 프로그래머는 두 개의 모니터를 가져야합니다
- 모든 프로그래머는 빠른 PC를 가져야합니다
- 모든 프로그래머는 마우스와 키보드를 선택할 수 있어야합니다
- 모든 프로그래머는 편안한 의자를 가져야한다
- 모든 프로그래머는 빠른 인터넷 연결을해야합니다
- 모든 프로그래머는 조용한 근무 조건을 가져야합니다
Joel의 목록에보고 싶은 항목이있는 것 같습니다. 특히 하드웨어 영역 (이중 모니터, 빠른 PC, 마우스 / 키보드, 편안한 의자, 빠른 연결).
언급되지 않은 유일한 것은 편안하고 조절 가능한 책상을 갖는 것 입니다.
다음을 변경하여 추가 할 수 있습니다.
현재 # 9 : 돈으로 살 수있는 최고의 도구를 사용하십니까?
에
개선 된 # 9 : 돈을 살 수 있는 최고의 도구 와 장비 를 사용하십니까 ?
포인트 8이 다음과 같이 흥미 롭습니다.
8. Do programmers have quiet working conditions?
읽었을 때 (같은 것)
8. Do programmers have their own office?
마지막 단락은 여전히 시작됩니다.
이제 벽과 문이있는 별도의 사무실로 옮깁니다.
직원과 방문객 모두 내가 근무했던 모든 장소에서 항상이 테스트를 의심했습니다. 자신의 사무실을 가진 유일한 사람은 이사와 고위 관리자입니다.
실제 환경에서 소프트웨어를 작성하는 것은 일반적으로 팀 활동이므로 팀 동료와 대화하여 아이디어 등을 전달해야합니다. 즉, 인스턴트 메시징 시스템을 사용하더라도 별도의 사무실에있는 사람들과는 더 어렵습니다. 일을 이끌어 내고 사람들에게 코드와 다이어그램을 보여줄 수 있으면 많은 도움이됩니다. 이것은 분산 된 팀이 작동하지 않는다는 것은 아닙니다. 분명히 할 수 있고 할 수있는 것은 다른 문제 일뿐입니다.
내가 말하고자하는 것은 각 팀이 6-8 명으로 구성된 자체 사무실에 있어야한다는 것입니다 (팀 규모라고 가정). 그렇게하면 다른 팀 (있는 경우)을 방해하지 않고 상호 작용할 수 있으며 영업 팀이나 방문자의 방해없이 작업을 계속할 수 있습니다 (내가 일한 곳에서 정문을 통해 개발 영역으로 바로 들어갔습니다).
다른 개발자와 함께 작업하지만 각각 별도의 프로젝트에서 작업하는 경우 공유 사무실 이 유용 할 수 있습니다. 단, 미팅 룸에서 미팅을하고 다른 사람들의 마감일 등을 준수해야하는 경우에만 엄격합니다.
다른 대부분은 자명 한 진리입니다.
나를위한 유일한 거래 차단기는 다음과 같습니다.
8. Do programmers have quiet working conditions?
흥미로운 것은 Stack Overflow 채용 공고에 의해 실패했을 가능성이 가장 큰 질문입니다.
특히 회사에 두 명 이상의 프로그래머가있는 경우 일부 질문은 실패하기 어렵습니다.
1. Do you use source control?
2. Can you make a build in one step?
4. Do you have a bug database?
내가 신경 쓰지 않는 다른 대부분의 대부분. 솔직히 말하면 :
12. Do you do hallway usability testing?
거짓말 쟁이를 감지 할 수있는 방법이 있습니다 :
5. Do you fix bugs before writing new code?
좋은 기준선이라고 말해야하지만 측정 도구에는 다른 요인이 있습니다. 예를 들어, 내가 일한 단일 회사가 Daily Builds (나도 알고 있음)를 수행했지만 일부는 매우 훌륭했습니다.
개인적으로 목록에 추가 할 다른 항목이 몇 개 있습니다.
이것들은 무엇보다 이전 고용주로부터 "나를 화나게했다"는 것입니다. 그리고 이제 그들은 각각의 모든 기회에 대해 묻는 빠른 추적 질문입니다.
나는 Joel의 요점 대부분에 동의합니다. "홀 웨이 유용성 테스트"에 대해 잘 모르겠습니다. 유용성 테스트는 확실하지만 실제로 복도에서 누군가를 잡아내어 자신의 직업이 아닌데도 프로그램을 테스트하게합니까? 사람들을 놀라게하는 좋은 방법 인 것 같습니다.
Joel 테스트는 팀의 우수성을 테스트하지 않습니다. 팀이 Joel 테스트를 얼마나 잘 준수하는지 테스트합니다.
다음은 팀이 얼마나 좋은지에 대한 더 나은 테스트입니다. 이것을 GrandmasterB 테스트라고합니다. 하나의 질문이 있습니다.
1) 작성하는 소프트웨어가 좋습니까?
'홀리 웨이 테스트'여부, 어떤 소스 컨트롤, 또는 빌드 프로세스가 무엇인지 (하나가있는 경우-모든 언어가있는 것은 아님) 그것은 나에게 중요하지 않습니다. 팀의 진정한 척도는 그들이 만든 소프트웨어의 품질입니다.
기본적으로 Joel 테스트의 모든 단계를 수행 할 수 있으며 여전히 배송되지 않는 불량 코드 및 제품으로 끝날 수 있습니다. 예를 들어, 소스 제어는 마술처럼 더 나은 코더를 만들지 않습니다. 코드를보다 쉽게 관리 할 수 있습니다. 최신 버전의 Visual Studio를 사용한다고해서 Visual Studio 2005 로 작성된 것보다 응용 프로그램이 더 잘 작동한다는 것은 아닙니다 .
일반적인 의미에서 의미가 있다고 생각하지만 Fog Creek Software 가 수행 하는 특정 종류의 소프트웨어 ( shrinkwrap )를 중심으로 목록을 찾았습니다 . 그는 또 다른 게시물 인 Five Worlds 에서 그것에 대해 이야기하기 때문에 정말 놀라운 것은 아닙니다 . 그리고 그 세계 바깥에는 많은 발전이 있습니다.
예를 들어 일일 빌드 (3) 또는 유용성 테스트 (12)와 같은 위성 또는 자동 판매 기용 임베디드 소프트웨어 를 개발하는 경우 실제로 이해가되지 않는 조건이 있습니다 .