Joel 테스트에 대해 어떻게 생각하십니까? [닫은]


51

조엘 테스트 팀이 얼마나 좋은 결정 잘 알려진 테스트입니다. 요점에 대해 어떻게 생각하십니까? 당신은 그들 중 어느 것에 동의하지 않습니까? 추가 할 것이 있습니까?

답변:


41

Jeff Atwood는 프로그래머의 권리 장전을 가지고 있습니다.

게시물에서 :

  1. 모든 프로그래머는 두 개의 모니터를 가져야합니다
  2. 모든 프로그래머는 빠른 PC를 가져야합니다
  3. 모든 프로그래머는 마우스와 키보드를 선택할 수 있어야합니다
  4. 모든 프로그래머는 편안한 의자를 가져야한다
  5. 모든 프로그래머는 빠른 인터넷 연결을해야합니다
  6. 모든 프로그래머는 조용한 근무 조건을 가져야합니다

Joel의 목록에보고 싶은 항목이있는 것 같습니다. 특히 하드웨어 영역 (이중 모니터, 빠른 PC, 마우스 / 키보드, 편안한 의자, 빠른 연결).

언급되지 않은 유일한 것은 편안하고 조절 가능한 책상을 갖는 것 입니다.

다음을 변경하여 추가 할 수 있습니다.

현재 # 9 : 돈으로 살 수있는 최고의 도구를 사용하십니까?

개선 된 # 9 : 돈을 살 수 있는 최고의 도구 와 장비 를 사용하십니까 ?


# 6이 Joel 테스트에서 # 8과 동일하지 않습니까?
HerbN

Jeff Atwood의 # 6입니다. 그렇습니다.
spong

조엘 테스트 프로그래머가 깨끗하고 개발할 수 있도록 더 구체적인 것 같습니다, # 8을 제외하고, 노동 조건에 반대 버그 무료 소프트웨어
Archmede

13

포인트 8이 다음과 같이 흥미 롭습니다.

8. Do programmers have quiet working conditions?

읽었을 때 (같은 것)

8. Do programmers have their own office?

마지막 단락은 여전히 ​​시작됩니다.

이제 벽과 문이있는 별도의 사무실로 옮깁니다.

직원과 방문객 모두 내가 근무했던 모든 장소에서 항상이 테스트를 의심했습니다. 자신의 사무실을 가진 유일한 사람은 이사와 고위 관리자입니다.

실제 환경에서 소프트웨어를 작성하는 것은 일반적으로 팀 활동이므로 팀 동료와 대화하여 아이디어 등을 전달해야합니다. 즉, 인스턴트 메시징 시스템을 사용하더라도 별도의 사무실에있는 사람들과는 더 어렵습니다. 일을 이끌어 내고 사람들에게 코드와 다이어그램을 보여줄 수 있으면 많은 도움이됩니다. 이것은 분산 된 팀이 작동하지 않는다는 것은 아닙니다. 분명히 할 수 있고 할 수있는 것은 다른 문제 일뿐입니다.

내가 말하고자하는 것은 각 팀이 6-8 명으로 구성된 자체 사무실에 있어야한다는 것입니다 (팀 규모라고 가정). 그렇게하면 다른 팀 (있는 경우)을 방해하지 않고 상호 작용할 수 있으며 영업 팀이나 방문자의 방해없이 작업을 계속할 수 있습니다 (내가 일한 곳에서 정문을 통해 개발 영역으로 바로 들어갔습니다).

다른 개발자와 함께 작업하지만 각각 별도의 프로젝트에서 작업하는 경우 공유 사무실 이 유용 할 수 있습니다. 단, 미팅 룸에서 미팅을하고 다른 사람들의 마감일 등을 준수해야하는 경우에만 엄격합니다.

다른 대부분은 자명 한 진리입니다.


9
팀원들로부터 아이디어를 수신 거부하는 문제는 구두로 질문하는 것이 큰 방해가된다는 것입니다. 심각한 공동 작업이 필요한 경우 공동 작업 공간에서 작업하십시오. 그러나 "어떻게 이걸 하시겠습니까?"질문에 대해서는 IM을 사용하는 것이 훨씬 좋습니다.
Matt Olenik

@Matt-당신이 옳은 일이지만 사무실 공간은 항상 부족합니다. 회사는 빈 사무실에 돈을 쓰고 싶지 않기 때문에 자신의 공간에 팀을 두는 것이 도움이됩니다. 사무실을 "협업 공간"으로 바꿀 수 있습니다.
ChrisF

2
같은 방에서 8 명을 의미 할 수는 없습니까? 나는 이미 3 명의 다른 프로그래머와 방을 공유함으로써 짜증을 냈습니다. 각각은 자체적으로 작동하며 다른 하나는 완전히 관련이없는 프로젝트에서 작업하고 다른 하나는 백엔드 / 데이터베이스 담당자입니다. 다른 7 명과 방을 함께 사용하면 우편으로 갈 것입니다.
Baelnorn

1
@ChrisF : 아마도 그게 문제 일 것입니다. 같은 방에 앉아있는 우리 네 사람은 서로 프로그래밍과 현명한 관계가 거의 없습니다. 같은 방에 앉아있는 2 1/2 개의 프로젝트에서 4 명이 일하는 것과 비슷합니다. 그리고 지금 절대적되는 회의실에도 불구하고 바로 옆 책상에 다른 프로그래머와 반 시간 긴 토론을 잡고 마음을하지 않는 상사 추가 단지 복도를 가로 질러을 . >. <
Baelnorn

1
@ChrisF- "실제 세계에서 소프트웨어를 작성하는 것은 팀 활동입니다. 팀원들과 이야기를 나눠서 아이디어 등을 전달해야합니다. 별도의 사무실에있는 사람들과는 훨씬 더 어려워요." 그렇다면 개발 팀은 어떻게 다른 위치에 분산되어 있습니까? 저는 미국이나 브라질 또는 인도의 사람들 (IM 및 Adobe Connect)과 긴밀하게 협력 하고 소규모 팀에서 대규모 팀으로 공동 배치했습니다. 당신은 매우 파괴적인 환경입니다. 팀에서 일하는 것은 효율적으로 이루어질 수 있지만, 당신이 처방하는 것은 아무것도 아닙니다. (당신의 생각은 70 년대의 폭포에서
옳습니다

10

나는 그것을 좋아하지만 회사를 평가하기 위해 그것을 사용한다면 모든 품목의 무게를 동일하게 측정하지는 않을 것입니다. 소스 컨트롤을 갖지 않는 것은 훨씬 큰 문제이며 돈으로 살 수있는 최고의 도구를 구매하지 않는 것입니다.


9

나를위한 유일한 거래 차단기는 다음과 같습니다.

 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?

20
한 번에 많은 회사에서 빌드를 수행 할 수없고 버그 데이터베이스가없는 것에 대해 놀랐을 것입니다. 아마도 소스 제어에 대해서는 맞을 것입니다.하지만 많은 회사가 단순히 코드를 백업하기 위해 소스를 사용하고 소스 제어의 이점을 긁지 않을 것이라고 주장합니다.
Rob Sobers

1
현재 직장에서 시작했을 때 우리는 소스 제어 시스템을 가지고 있었지만 빌드는 한 사람의 컴퓨터에서 이루어졌으며 모든 단계를 알고 있었고 버그는 종이에서 추적되었습니다. 이것들은 이제 모두 "고정"되었지만, 절대로 이런 것들을 당연한 것으로 여기지 않을 것입니다.
HappyCat

6

좋은 기준선이라고 말해야하지만 측정 도구에는 다른 요인이 있습니다. 예를 들어, 내가 일한 단일 회사가 Daily Builds (나도 알고 있음)를 수행했지만 일부는 매우 훌륭했습니다.

개인적으로 목록에 추가 할 다른 항목이 몇 개 있습니다.

  1. 컨퍼런스에 참석하거나 책을 구매하거나 그와 같은 성격의 개발자 교육을 지원합니까?
  2. 작업 기능을 완료하는 데 필요한 경우 새 도구를 채택하는 간단하고 문서화 된 프로세스가 있습니까
  3. 개발자에게 생산성을 높일 수있는 장비와 환경을 제공합니까?

이것들은 무엇보다 이전 고용주로부터 "나를 화나게했다"는 것입니다. 그리고 이제 그들은 각각의 모든 기회에 대해 묻는 빠른 추적 질문입니다.


1
3이 아직 목록에 없습니까?
Casebash

그렇습니다. 그러나 나는 조금 다르게 내 목록을 작성했습니다.
Mitchel Sellers

5

나는 Joel의 요점 대부분에 동의합니다. "홀 웨이 유용성 테스트"에 대해 잘 모르겠습니다. 유용성 테스트는 확실하지만 실제로 복도에서 누군가를 잡아내어 자신의 직업이 아닌데도 프로그램을 테스트하게합니까? 사람들을 놀라게하는 좋은 방법 인 것 같습니다.


1
문화적 요소-지나치게 파괴적이지 않고 비즈니스 기능의 일부인 경우, 특히 비즈니스 목적이 애플리케이션 개발 인 경우에는 "사람을 끌지 말아야" 하지 않아야합니다.
Murph

1
요점은 다른 사람들의 일의 일부가되어야 하는가?
JeffO

7
복도 사용성 테스트의 핵심은 프로그램을 정기적으로 사용하지 않는 사람이어야한다는 것입니다. 일단 당신이 그것을 만들고 그리고 / 또는 (전용 테스터와 같이) 그것을 사용하여 시간을 보냈을 때, 앱에 대한 당신의 관점은 왜곡 될 것입니다
GSto

5

Joel 테스트는 팀의 우수성을 테스트하지 않습니다. 팀이 Joel 테스트를 얼마나 잘 준수하는지 테스트합니다.

다음은 팀이 얼마나 좋은지에 대한 더 나은 테스트입니다. 이것을 GrandmasterB 테스트라고합니다. 하나의 질문이 있습니다.

1) 작성하는 소프트웨어가 좋습니까?

'홀리 웨이 테스트'여부, 어떤 소스 컨트롤, 또는 빌드 프로세스가 무엇인지 (하나가있는 경우-모든 언어가있는 것은 아님) 그것은 나에게 중요하지 않습니다. 팀의 진정한 척도는 그들이 만든 소프트웨어의 품질입니다.

기본적으로 Joel 테스트의 모든 단계를 수행 할 수 있으며 여전히 배송되지 않는 불량 코드 및 제품으로 끝날 수 있습니다. 예를 들어, 소스 제어는 마술처럼 더 나은 코더를 만들지 않습니다. 코드를보다 쉽게 ​​관리 할 수 ​​있습니다. 최신 버전의 Visual Studio를 사용한다고해서 Visual Studio 2005 로 작성된 것보다 응용 프로그램이 더 잘 작동한다는 것은 아닙니다 .


14
요점이 없습니다. Joel 테스트는 소프트웨어의 우수성에 관한 것이 아니라 생산 프로세스의 효율성 에 관한 것입니다. Joel 테스트에 실패한 팀은 여전히 ​​좋은 제품을 만들 수 있지만 시간이 더 오래 걸리고 작업자가 비참 할 수 있습니다. 또한 도구는 소프트웨어만을 가리키는 것이 아닙니다. 또한 컴퓨터에서 책상과 키보드에 이르기까지 하드웨어를 의미합니다.
매트 올레 닉

나는 당신이 요점을 놓치고 있다고 생각합니다. 팀이 제 시간에 프로젝트를 마치고 양질의 소프트웨어를 생산하는 경우, 정의에 따라 효과적입니다. 그리고 그들은 정의상 효과적인 프로세스를 가지고 있습니다.
GrandmasterB

2
적시에 배송에 대해 언급 한 적이 없습니다. 또한 Joel Test에 실패한 (완전히) 효과적인 팀을 보게되어 매우 놀랐습니다. 버전 관리, 테스트 및 유용성과 같은 것들이 모두 중요합니다. 다른 아이템들도 꽤 큰 장애가 될 수 있습니다.
Matt Olenik

이것은 좋은 지적이지만 주된 약점은 주관성입니다. 경험, 기술 수준 및 사용 관점에 따라 소프트웨어 품질에 대해 의견이 다를 수 있습니다. 그러나 나는 요점을 좋아한다.
Bernard Dy

효과적인 프로세스가 팀 구성원 인 경우, 특히 팀 규모가 작은 경우에만 효과적 일 경우, 성장 또는시기 적절하지 않은 재난 또는 퇴직시 얼마나 잘 견딜 수 있습니까? 개발하는 사람들의 머릿속에 존재하는 프로세스를 통해 제대로 작동하고 정시에 제공되는 코드를 생성 할 수 있다는 것은 재난을위한 레시피입니다. 복구 할 수 없거나 단순히 원하지 않을 것입니다.
Finni McFinger

5

일반적인 의미에서 의미가 있다고 생각하지만 Fog Creek Software 가 수행 하는 특정 종류의 소프트웨어 ( shrinkwrap )를 중심으로 목록을 찾았습니다 . 그는 또 다른 게시물 인 Five Worlds 에서 그것에 대해 이야기하기 때문에 정말 놀라운 것은 아닙니다 . 그리고 그 세계 바깥에는 많은 발전이 있습니다.

예를 들어 일일 빌드 (3) 또는 유용성 테스트 (12)와 같은 위성 또는 자동 판매 기용 임베디드 소프트웨어 를 개발하는 경우 실제로 이해가되지 않는 조건이 있습니다 .


동의했다. "스택 상단"앱에서 멀어지면 많은 현대적인 아이디어가 조금 관련이없는 것처럼 보입니다.
Paul Nathan

동의한다. 기업 IT 상점에는 수축 랩을하는 것만 큼 매력적이지 않은 많은 개발자 작업이 있습니다. 이들 회사의 대부분은 소프트웨어 사업에 속하지 않기 때문에 대부분 Joel Test에서 약 4 점을받습니다.
Bernard Dy

6
임베디드 소프트웨어에 대한 단위 테스트를 작성하지 않고 빌드 시스템에서 자동으로 실행하는 이유는 무엇입니까?
Peter Mortensen
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.