|
Size: 3002
Comment:
|
Size: 3243
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| The question then is, what organizational size works best for smaller software projects? The answer depends on the individual(s) involved in the project. | 그렇다면 의문은, 소규모 소프트웨어 프로젝트에 가장 적합한 조직 규모는 무엇인가? 답은 프로젝트에 참여한 개인(들)에 따라 다르다. |
| Line 11: | Line 11: |
| The productivity of a single individual can be higher than that of a collection of productive individuals. We have seen single-person developments generate 25KSLOC of deliverable code in 4 months (a craft interface for a telecommunication system); two-person developments do 135 KSLOC in 30 months. Many of these adhered faithfully to all stipulated reviews and verification steps. | 한 개인의 생산성은 생산적인 개인 집합의 생산성보다 높을 수 있다. 우리는 1인 개발로 4개월만에 2만5천 라인의 전달 가능한 코드(통신 시스템을 위한 크래프트 인터페이스)를 생산하는 것을 보았다. 2인 개발은 30개월 동안 13만5천 라인을 수행한다. 이들 중 다수는 규정된 모든 리뷰 및 검증 단계를 충실히 준수했다. |
| Line 13: | Line 13: |
| Boehm [Boehm1981] notes a 20-fold spread between the least and most effective developers. A telecommunications developer recently told me that “having the right expertise means the difference between being able to solve a problem in a half hour, and never being able to solve the problem at all.” | Boehm은 가장 효과가 적은 개발자와 가장 효과적인 개발자 사이에 20배의 분포가 있다고 지적한다. 한 통신 개발자는 최근에 "적절한 전문 지식을 가진다는 것은 문제를 30분 안에 해결할 수 있느냐, 아예 문제를 해결할 수 없느냐를 구분짓는다"라고 말했다. |
| Line 15: | Line 15: |
| (Note: Boehm quotes Grant and Stackman [Grant1966] with a 26- fold spread, page 667.) | (참고: Boehm은 Grant and Stackman [Grant1966]을 26배 스프레드로 인용함.) |
| Line 17: | Line 17: |
| The result of using a SOLO VIRTUOSO (4.2.5) is an organization limited to small development. Though there is a singleton development role, other roles may be necessary to support marketing, toolsmithing, and other functions. The productivity of a suitably chosen singleton developer is enough to handle sizable projects; here, we establish 25KSLOC as a limit. | Solo Virtuoso (솔로 거장)를 사용한 결과는 소규모 개발로 제한된 조직이다. 단 하나의 개발 역할이 있지만, 마케팅, 도구 제작 및 기타 기능을 지원하려면 다른 역할이 필요할 수 있다. 적절하게 선택된 싱글톤 개발자의 생산성은 상당한 규모의 프로젝트를 처리하기에 충분하다; 여기서, 우리는 2만5천 라인을 제한으로 삼겠다. |
| Line 19: | Line 19: |
| Therefore: | 따라서: |
| Line 21: | Line 21: |
| Do the entire design and implementation with one or two of your most effective developers. | 가장 효과적인 개발자 한두 명과 함께 전체 설계 및 구현을 수행하라. |
| Line 25: | Line 25: |
| This pattern is not a “License to Hack.” The work of SOLO VIRTUOSOS (4.2.5) is still subject to technical reviews, validation, and verification at appropriate times in the development cycle — STAND UP MEETING (5.2.7), ENGAGE CUSTOMERS (4.2.6). This combines nicely with DEVELOPING IN PAIRS (4.2.28). | 이 패턴은 "해킹에 대한 허가증"이 아니다. Solo Virtuosos의 작업은 여전히 개발주기 - [[OrgPatterns/Stand up Meeting]], [[OrgPatterns/Engage Customers]] - 의 적절한 시기에 기술 검토, 검증(validation) 및 확인(verification)을 거쳐야 한다. 이것은 [[OrgPatterns/Developing in Pairs]]와 잘 결합된다. |
| Line 27: | Line 27: |
| See also MODERATE TRUCK NUMBER (4.2.24), which raises concerns about the use of this pattern in risk-averse business. | 위험 회피 비즈니스에서 이 패턴의 사용에 대한 우려를 제기하는 [[OrgPatterns/Moderate Truck Number]]도 참조하라. |
... 우리는 시간과 예산 내에서 대규모 소프트웨어 시스템을 구축하는데 필요한 최적의 조직 규모를 설명했다 - OrgPatterns/Size the Organization. 다음의 패턴은 더 작은 시스템 (2만 5천줄보다 적은)에서, 제품이 제시간에 예산 안에서 만들어져야 하지만, 첫번째 릴리즈 이후에는 빠른 성장이 예상되지 않는 경우에 무엇을 해야 할지 설명한다.
✥ ✥ ✥
소규모 소프트웨어 프로젝트 (코드 2만 5천줄 미만)에 인력이 너무 많으면, 커뮤니케이션 오버헤드가 증가하고 소프트웨어를 전적으로 스스로 제작할 수 있는 재능있는 개인이 묶여 "마력(horsepower)"이 감소한다.
우리는 조직 규모가 비선형 방식으로 결과물에 영향을 미친다고 말했다 (OrgPatterns/Size the Organization). 우리는 또한 커뮤니케이션 오버 헤드가 크기의 제곱 만큼 증가한다는 것을 관찰했다. 이는 조직이 크기의 제곱 만큼 응집력이 떨어지고 조직의 "마력(horsepower)"이 선형으로만 증가한다는 것을 의미한다.
그렇다면 의문은, 소규모 소프트웨어 프로젝트에 가장 적합한 조직 규모는 무엇인가? 답은 프로젝트에 참여한 개인(들)에 따라 다르다.
한 개인의 생산성은 생산적인 개인 집합의 생산성보다 높을 수 있다. 우리는 1인 개발로 4개월만에 2만5천 라인의 전달 가능한 코드(통신 시스템을 위한 크래프트 인터페이스)를 생산하는 것을 보았다. 2인 개발은 30개월 동안 13만5천 라인을 수행한다. 이들 중 다수는 규정된 모든 리뷰 및 검증 단계를 충실히 준수했다.
Boehm은 가장 효과가 적은 개발자와 가장 효과적인 개발자 사이에 20배의 분포가 있다고 지적한다. 한 통신 개발자는 최근에 "적절한 전문 지식을 가진다는 것은 문제를 30분 안에 해결할 수 있느냐, 아예 문제를 해결할 수 없느냐를 구분짓는다"라고 말했다.
(참고: Boehm은 Grant and Stackman [Grant1966]을 26배 스프레드로 인용함.)
Solo Virtuoso (솔로 거장)를 사용한 결과는 소규모 개발로 제한된 조직이다. 단 하나의 개발 역할이 있지만, 마케팅, 도구 제작 및 기타 기능을 지원하려면 다른 역할이 필요할 수 있다. 적절하게 선택된 싱글톤 개발자의 생산성은 상당한 규모의 프로젝트를 처리하기에 충분하다; 여기서, 우리는 2만5천 라인을 제한으로 삼겠다.
따라서:
가장 효과적인 개발자 한두 명과 함께 전체 설계 및 구현을 수행하라.
✥ ✥ ✥
이 패턴은 "해킹에 대한 허가증"이 아니다. Solo Virtuosos의 작업은 여전히 개발주기 - OrgPatterns/Stand up Meeting, OrgPatterns/Engage Customers - 의 적절한 시기에 기술 검토, 검증(validation) 및 확인(verification)을 거쳐야 한다. 이것은 OrgPatterns/Developing in Pairs와 잘 결합된다.
위험 회피 비즈니스에서 이 패턴의 사용에 대한 우려를 제기하는 OrgPatterns/Moderate Truck Number도 참조하라.