QSM: Volume 1.1: How Software is Built
Contents
Part 1. 품질의 패턴들 (Patterns of Quality)
Chapter 1: 품질이란 무엇인가? 그것이 왜 중요한가? (What Is Quality? Why Is It Important?)
Summary
[V] 품질은 상대적이다. 한 사람에게 좋은 품질은 다른 사람에게 낮은 품질일 수도 있다. Quality is relative. What is quality to one person may even be lack of quality to another.
[V] 상대성을 찾는 것은 "품질에 관한 그 진술의 뒤에 있는 그 사람이 누구냐"라고 물음으로써, 품질에 관한 진술 속에서 암묵적인 사람이나 사람들을 탐지하는 것을 포함한다. Finding the relativity involves detecting the implicit person or persons in the statement about quality, by asking, "Who is the person behind that statement about quality."
[V] 어떤 사람이나 사람들에게 있어서 품질은 가치보다 크거나 작지 않다. 이러한 관점은 우리가 이러한 문장들을 조화시킬 수 있도록 해준다: "결함을 0으로 하는 것이 고품질이다.", "기능이 많은 것이 고품질이다.", "우수한 코딩이 고품질이다.", "고성능이 고품질이다.", "적은 개발 비용이 고품질이다.", "쾌속 개발이 고품질이다.", "사용자 친화성이 고품질이다.". 모든 진술이 동시에 사실일 수 있다. Quality is neither more nor less than value to some person or persons. This view allows us to reconcile such statements as,"Zero defects is high quality." , "Lots of features is high quality." , "Elegant coding is high quality." , "High performance is high quality." , "Low development cost is high quality." , "Rapid development is high quality." , "User-friendliness is high quality." All of the statements can be true at the same time.
[V] 품질은 거의 항상 정치적/감정적인 문제이다. 비록 우리가 그것이 합리적으로 해결될 수 있는 것처럼 행동하기를 좋아한다고 해도. Quality is almost always a political/emotional issue, though we like to pretend it can be settled rationally.
[V] 품질은 오류로부터의 자유와 동일하지 않다. 공식적인 요구 조건에도 부합하지 않는 소프트웨어 제품이 어떤 사용자들에게는 높은 품질로 간주될 수도 있다. Quality is not identical with freedom from errors. A software product that does not even conform to its formal requirements could be considered of high quality by some of its users.
[V] 품질을 향상시키는 것은 매우 어렵다. 조직들은 일을 하는 특정한 패턴을 고수하는 경향이 있기 때문이다. 그들은 현재 수준의 품질에 적응하고, 새로운 수준으로 변화하는데 무엇이 필요한지 알지 못하며, 실제로 알아내려고 노력하지 않는다. Improving quality is so difficult because organizations tend to lock on to a specific pattern of doing things. They adapt to the present level of quality, they don't know what is needed to change to new level, and they don't really try to find out.
[V] 소프트웨어 조직에서 채택한 패턴은 몇 개의 클러스터, 하위문화에 속하는 경향이 있는데, 각각은 그 특징적인 결과를 낳는다. The patterns adopted by software organizations tend to fall into a few clusters, or subcultures, each of which produces characteristic results.
[V] 문화는 본질적으로 보수적이다. 이 보수주의는 기본적으로 다음과 같은 것들에 나타나 있다 Cultures are inherently conservative. This conservatism is manifested primarily in
특정 수준의 품질에 대한 만족도 the satisfaction with a particular level of quality
훨씬 더 잘하려고 하는 시도로 그 수준을 잃는 것에 대한 두려움 the fear of losing that level in an attempt to do even better
타문화들에 대한 이해의 부족 the lack of understanding of other cultures
그들 자신 문화의 불투명성 the invisibility of their own culture
V
Chapter 2. 소프트웨어 하위 문화들 (Software Subcultures)
Summary
[V] PhilipCrosby의 "품질은 공짜다" 아이디어는 아마도 몇 가지 손보면 소프트웨어에 적용될 수 있다. Philip Crosby's "Quality is Free" ideas can be applied to software, though perhaps with several modifications.
[V] 소프트웨어에서, 요구사항을 준수하는 것은 제조 작업에서처럼 요구사항이 확실할 수 없기 때문에 품질을 정의하기에 충분하지 않다. In software, conformance to requirements is not enough to define quality, because requirements cannot be as certain as in a manufacturing operation.
[V] 소프트웨어에 대한 우리의 경험에 따르면 "결함 0"은 대부분의 프로젝트에서 현실적이지 않다. 왜냐하면 마지막 몇 가지 결함에 대한 가치가 감소하기 때문이다. 더욱이, 다른 결점이 줄어들면 지배적이 되는 경향이 있는 요구사항 결점들이 있다. Our experience with software tells us that "zero defects" is not realistic in most projects, because there is diminishing value for the last few defects. Moreover, there are requirements defects that tend to dominate once the other defects are diminished.
[V] 크로스비의 주장과는 다르게, 소프트웨어에서는 "품질의 경제학"이 있다. 우리는 완벽을 추구하는 것이 아니라, 가치를 찾는 것이다, 가치로 정당화되지 않은 완벽에 대한 심리적 욕구가 없는 한. Contrary to Crosby's claim, there is an "economics of quality" for software. We are not searching for perfection, but for value, unless we have a psychological need for perfection not justified by value.
[V] 어떠한 소프트웨어 문화 패턴도 성공적일 수 있다. 올바른 고객이 주어진다면. Any software cultural pattern can be a success, given the right customer.
[V] "성숙도"는 하위문화 패턴에 대한 올바른 단어가 아니다. 추론될 수 없는 우월성을 내포하고 있기 때문이다. "Maturity" is not the right word for sub-cultural patterns, because it implies superiority where none can be inferred.
[V] 우리는 최소 6가지 소프트웨어 하위 문화 패턴을 확인할 수 있다: We can identify at least six software sub-cultural patterns:
패턴0: 무의식 Pattern 0: oblivious
패턴1: 가변적 Pattern 1: variable
패턴2: 루틴 (그러나 불안정) Pattern 2: routine (but unstable)
패턴3: 조정하는 Pattern 3: steering
패턴4: 예상하는 Pattern 4: anticipating
패턴5: 일치적인 Pattern 5: congruent
[V] 거의 모든 소프트웨어 조직이 다른 패턴에서 발견되기 때문에, 패턴 4,5에 대한 관찰은 거의 존재하지 않는다. Hardly any observations exist on Patterns 4 and 5, as almost all software organizations are found in other patterns.
[V] 이 책에서 우리는 주로 패턴 1~3을 살펴볼 것이다 - 어떻게 하면 만족스러운 패턴을 유지하거나 더 만족스러운 패턴으로 이동할 수 있는지 In this book, we shall be concerned primarily with Patterns 1-3—how to hold onto a satisfactory pattern or move to a more satisfactory one.
Chapter 3. 패턴을 변화시키기 위해서는 무엇이 필요한가? (What Is Needed To Change Patterns?)
Summary
[V] 각 패턴은 독특한 사고방식과 의사소통 방식을 가지고 있다. Each pattern has its characteristic way of thinking and communicating.
[V] 패턴을 바꾸는데 있어 가장 먼저 필수적인 것은 그 패턴의 특징적인 사고 패턴을 바꾸는 것이다. The first essential to changing a pattern is changing thought patterns that are characteristic of that pattern.
[V] 사고 패턴은 모델로 구성되며, 새로운 모델을 사용하여 사고 패턴을 바꿀 수 있다. Thinking patterns consist of models, and new models can be used to change thinking patterns
[V] 안정성이 떨어지는 패턴에서 모델은 정밀할 필요가 없고, 단지 설득력만 있으면 된다. 사실, 정확한 모델은 안정성을 먼저 확립하지 않으면 말이 안될 것이다. In the less stable patterns, models need not be precise, but merely convincing. Indeed, precise models wouldn't make any sense without first establishing stability.
[V] 모델은 우리에게 이러한 점을 도와준다: Models help us to:
사고의 차이를 발견한다. 그것이 큰 결과를 낳기 전에 discover differences in thinking, before they have big consequences
아이디어를 함께 연구한다. 팀 빌딩을 촉진하기 위해 work on ideas together, to facilitate team-building
다양한 프로젝트 프랙티스가 필요한 이유를 이해하는데 understand the reasons for various project practices
새로운 사람이 훨씬 빨리 생산적이 될 수 있도록 커뮤니케이션을 기록 record communication so newcomers can get productive much faster
다음번에 프로세스를 개선하는데 사용할 수 있는 기록을 유지 maintain a record we can use to improve our processes for the next time
창의적이 되기, 왜냐하면 프로젝트는 결코 루틴하지 않을 것이기 때문에 be creative, because projects will never be routine.
[V] 더 좋은 패턴을 고를 준비를 하기 전에, 항상 "현재 우리의 패턴은 충분히 좋은가?"라고 물어봐야 한다. Before you set about choosing a better pattern, you should always ask, "Is our present pattern good enough?"
[V] 당신이 선택하는 패턴은 조직적 요구, 고객 요구, 문제 요구 사이의 트레이드 오프에 달려 있다. 이러한 트레이드오프들은 "패턴 공간"에서 한 점을 선택함으로써 나타낼 수 있다. The pattern you choose depends on a tradeoff among organizational demands, customer demands, and problem demands. These tradeoffs can be represented by choosing a point in "pattern space."
[V] 소프트웨어 조직에게는, 새로운 패턴을 선택하지 않고 그 대신 고객의 요구나 문제 요구를 줄임으로써, 정체되려는 유혹이 항상 존재한다. There is always a temptation for a software organization to stagnate by not choosing a new pattern, but instead reducing customer demands or problem demands.
[V] 새로운 패턴이 필요하다고 인식하는 프로세스는, 필요로 하는 정보로부터 조직을 폐쇄하는 순환적 논쟁에 의해 방해된다. The process of recognizing that a new pattern is needed is hindered by circular arguments that close the organization to the information it needs.
[V] 폐쇄적인 서클들을 여는 열쇠는 이 질문이다, "당신의 성공률은 괜찮은가?". 그러나, 폐쇄적인 서클은, 이 질문을 하지 못하게 하는 경향이 있다. The key to opening closed circles is the question, "Is your rate of success okay?" Closed circles, however, tend to prevent this question from being asked.
[V] 신뢰의 부족은 이 핵심 질문에 진실하게 대답하지 못하게 하는 경향이 있으므로, 조직의 변화는 종종 신뢰를 발전시키기 위한 행동들로부터 시작된다. Lack of trust tends to keep this key question from being answered truthfully, so organizational change often begins with actions for developing trust.
Part II. 관리의 패턴들 (Patterns Of Managing)
Chapter 4: 관리를 위한 제어 패턴들 (Control Patterns for Management)
Summary
[V] Aggregate Control Model(제어 총합 모델)은, 중복되는 해법들에 충분한 비용을 지출할 의향이 있다면, 결국 원하는 시스템을 얻게 될 것이라고 알려준다. 때로 이것이 가장 실용적인 방법이거나 우리가 생각할 수 있는 유일한 방법이다. The Aggregate Control Model tells us that if we're willing to spend enough on redundant solutions, we'll eventually get the system we want. Sometimes this is the most practical way, or the only way we can think of.
[V] 피드백 제어 모델(Feedback Control Model)은 우리가 원하는 것을 얻는 보다 효율적인 방법을 시도한다. 컨트롤러는 시스템이 현재 무엇을 하고 있는지에 대한 정보를 기반으로 시스템을 제어한다. 이 정보와 시스템을 위해 계획된 정보를 서로 비교하여, 컨트롤러는 시스템의 동작을 계획에 보다 더 가깝게 하기 위해 설계된 행동을 한다. The Feedback Control Model tries for a more efficient way of getting what we want. A controller controls a system based on information about what the system is currently doing. Comparing this information with what is planned for the system, the controller takes actions designed to bring the system's behavior closer to plan.
[V] 엔지니어링 관리(Engineering Management)의 업무는 엔지니어링 프로젝트에서 컨트롤러 역할을 하는 것이다. 엔지니어링 관리의 실패는 피드백 제어 모델 측면(Feedback Control Model)에서 이해할 수 있다. 패턴2 관리자는 종종 이러한 이해가 부족하며, 이는 종종 왜 그들이 그렇게 많은 낮은 품질의 프로젝트나 실패한 프로젝트를 경험하는지 설명해준다. The job of Engineering Management is to act as controller in engineering projects. Failures of engineering management can be understood in terms of the Feedback Control Model. Pattern 2 managers often lack this understanding, which often explains why they experience so many low quality, or failed, projects.
[V] 무슨 일이 일어나야 할지에 대한 계획이 없으면 프로젝트가 실패할 수 있다. Projects can fail when there is no plan for what should happen.
[V] 컨트롤러가 어떤 중요한 일이 실제로 일어나고 있는지 관찰하는데 실패하면 프로젝트가 실패할 수 있다. Projects can fail when the controller fails to observe what significant things are really happening.
[V] 컨트롤러가 관찰된 것과 계획된 것을 비교하는데 실패하면 프로젝트가 실패할 수 있다. Projects can fail when the controller fails to compare the observed with the planned.
[V] 컨트롤러가 실제 계획에 근접하기 위한 조치를 취할 수 없거나 하지 않으면 프로젝트가 실패할 수 있다. Projects can fail when the controller cannot or will not take action to bring actual closer to planned.
Chapter 5 명시적인 관리 모델들 만들기 (Making Explicit Management Models)
Summary
[V] 모든 관리자와 프로그래머는 그들의 소프트웨어 패턴에서 사물들이 어떻게 작용하는지에 대한 모델들을 가지고 있다. 비록 많은 모델이 명시적으로 언급되기보다는 그들의 행동에 내포되어 있지만 말이다. 사람들이 현실을 직시하지 못하고 잘못된 시스템 모델들을 사용하기 때문에 소프트웨어 프로젝트들에서 일이 꼬이곤 한다. Every manager and programmer has models of how things work in their software pattern, though many models are implicit in their behavior, rather than stated explicitly. Things go awry in software projects because people are unable to face reality and because they use incorrect system models.
[V] 선형 모델(Linear model)들은 가산성1 때문에 매력적이다. 선형 시스템들 모델링하기 쉽고, 예측하기 쉽고, 제어하기 쉽다. 관리자들은 보통 선형 모델이 매우 매력적이기 때문에 규모의 오류2를 범한다. Linear models are attractive because of additivity. Linear systems are easier to model, easier to predict, and easier to control. Managers often commit scaling fallacies because linear models are so attractive.
[V] 효과 다이어그램은 모델 시스템 역동이 비선형성을 드러내도록 돕는 도구다. 2차원 그림인 만큼, 그것은 비선형 시스템을 설명하는 데에 말로 된 설명보다 더 적합하다. The diagram of effects is a tool for helping model system dynamics to reveal non-linearities. Being a two-dimensional picture, it is more suited than verbal descriptions to the job of describing non-linear systems.
[V] 효과 다이어그램을 그리는 한 가지 방법은 출력, 즉 통제하고자 하는 행동을 하는 변수부터 시작하는 것이다. 그런 다음, 그 변수에 역으로 영향을 미칠 수 있는 다른 변수들을 브레인스토밍하고 차트화하라. 이것들로부터, 이 차트를 한 번 더 거슬러가면서, 2차 효과들을 밝혀내라. 그것들을 사용해 원초 효과들로부터 관심 변수까지 추적할 수 있다. 중요한 것들은 승수 효과를 명시적으로 표시할 수도 있다. One way of developing a diagram of effects is to start with the output—the variable whose behavior you wish to control. You then brainstorm and chart backwards effects from that variable—other variables that could affect it. From these, you chart backwards again, unveiling secondary effects, which you can trace through the primary effects to the variable of interest. You may want to explicitly indicate multiplicative effects because of their importance.
[V] 비선형성이 일이 꼬이는 이유이다. 그래서 비선형성을 찾는 것이 시스템 모델링의 주요 작업이다. Non-linearity is the reason things go awry, so searching for non-linearity is a major task of system modeling.
Chapter 6: 피드백 효과 (Feedback Effects)
Summary
[V] 험프티 덤프티 신드롬은 프로젝트 매니저들이 그들의 매니저에게 예의바르게 고집을 부릴 수 없는 한 가지 이유와, 그 결과로 어떤 일들이 일어나지를 설명한다. The Humpty Dumpty Syndrome explains one reason why project managers are unable to be courteously stubborn to their managers, and what happens as a result.
[V] 프로젝트는 탈주한다 - 폭발하거나 붕괴한다 - 관리자들이 다음과 같은 두 가지 오류를 믿기 때문이다: 가역성 오류 (액션들은 항상 되돌릴 수 있다)와 인과 오류 (모든 원인이 하나의 효과를 가지고, 어떤 것이 원인이고 어떤 것이 효과인지 알 수 있다는 것.)가 그것이다. Projects run away—explode or collapse—because managers believe two fallacies: The Reversible Fallacy (that actions can always be undone) and The Causation Fallacy (that every cause has one effect, and you can tell which is cause and which is effect.)
[V] 브룩스의 법칙의 효과는 관리 행동에 의해 더욱 악화될 수 있다. 더욱이, 같은 형태의 관리 행위가 일반화된 브룩스의 법칙(Generalized Brooks's Law)으로 이어질 수 있는데, 이는 관리 행위가 어떻게 종종 프로젝트 붕괴의 주요 원인이 되는지 보여준다. The effect of Brooks's Law can be made worse by management action. Moreover, the same pattern of management action can lead to a Generalized Brooks's Law, which shows how management action is often the leading cause of project collapse.
- [V] 관리 행동이 탈주에 기여하는 한 가지 이유는 일탈에 너무 늦게 대응하는 경향이다. 이는 관리를 그 자체가 비선형적 결과를 가지는 커다란 액션들로 내몬다. 그래서 "일찍 행동하라; 작게 행동하라"가 필요한 것이다. One reason management action contributes to runaway is the tendency to respond too late to deviations, which then forces management to big actions which themselves have non-linear consequences. That's why it's necessary to "act early; act small."
[V] 네거티브 피드백은 시스템에서 포지티브 피드백 루프로 인한 탈주를 방지할 수 있는 속도와 힘을 가진 유일한 메커니즘이다. 패턴3 컨트롤러에는 두 가지 주요한 네거티브 피드백 루프가 있는데, 하나는 자원들을 포함하고 다른 하나는 요구사항들을 포함한다. Negative feedback is the only mechanism that has the speed and power to prevent runaway due to positive feedback loops in a system. The Pattern 3 controller has two major negative feedback loops with which to exercise control—one involving resources and one involving requirements.
Chapter 7: 소프트웨어 조정하기 (Steering Software)
Summary
[V] 다른 여러 좋고 이상적인 방법론들은 붕괴를 방지하는데 도움이 되지 못하는데, 그것들은 프로젝트가 이상적인 모델에서 벗어날 때 취해야 할 부정적인 피드백 행동들을 규정하지 않기 때문이다. Many otherwise good ideal methodologies fail to help prevent collapse because they don't prescribe negative feedback actions to be taken when the project deviates from the ideal model.
[V] 방법론이 피드백을 규정할 때, 그들은 종종 제품 레벨, 또는 너무 큰 피드백 단계들에 대해서만 말한다. 통제에 효과적이 되려면, 피드백은 모든 레벨, 즉 개인, 제품, 프로세스 및 문화적 수준에서 작은 증분으로3 작동해야 한다. When the methodologies do prescribe feedback, they often speak only of the product level, or feedback steps that are too large. To be effective for control, feedback must operate in small increments, at all levels, personal, product, process, and cultural.
- [V] 소프트웨어 전문가는 종종 효과 모델에서 인간의 의사결정 지점을 간과한다. 한 가지 이유는 상태를 시각화할 수 있는 능력이 전혀 없기 때문이며, 종종 그것들은 프로세스의 "기타 출력물"이지, 제품과 직접 연결되지는 않기 때문이다.
Software professionals often overlook the human decision point in models of effects. One reason is their inability to visualize certain states at all, often because they are "other outputs" of the process, and not directly connected with the product.
[V] 프로젝트를 성공적으로 제어하기 위해서는, 역동의 피해자가 될 필요가 없다는 것을 배워야 한다. 인간의 의사결정 요소가 관련되었을 때, 중요한 것은 사건이 아니라 그 사건에 대한 당신의 반응이다. To control a project successfully, you have to learn that you need not be a victim of the dynamics. When human decision points are involved, it's not the event that counts, it's your reaction to the event.
Chapter 8: 조정에 실패하기 (Failing to Steer)
Summary
[V] 많은 프로젝트 매니저들은 자신들이, 프로젝트의 운명을 통제할 수 없는, 피해자라고 믿기 때문에 잘 조정하지 못한다. 그러한 매니저들은 "피해자 언어"를 사용하기 때문에 쉽게 구분할 수 있다. Many project managers fail to steer well because they believe they are victims, with no control over the destiny of their project. You can easily identify these managers by their use of "victim language."
[V] 관리자가 관리적인 통제가 어디에 있는지 인식하고, 이 통제권이 다른 형태를 취할 수 있다면, 브룩스의 법칙(Brooks's Law)은 피해자의 법칙이 될 필요가 없다. Brooks's Law doesn't have to be a victim law if the manager recognizes where the managerial control is, and that this control can take different forms.
[V] 일반적인 역동에서는, 프로젝트 진행에 대해 정확하지만 나쁜 소식을 전하는 메신저를 처벌하곤 한다. 이러한 개입은 "부정적인 대화"는 피하지만, 반면에 매니저가 프로젝트가 정상적으로 진행되게 하는 효과적인 개입을 할 가능성을 약화시킨다. A common dynamic is punishing the messenger who brings accurate but bad news about project progress. This intervention avoids "negative talk," but also diminishes the chance of the manager's making effective interventions needed to keep a project on the road.
[V] 그리스 시대부터, 사람들은 개입을 잘못해왔을 뿐 아니라, 반대로 개입해왔다. 효과 다이어그램을 명확하게 짜는 것은 두 당사자가 서로에게 돌진하며 파멸로 몰고 가는 상황을 정리하는 데 도움이 될 수 있고, 동시에 스스로가 상황을 나아지게 하고 있다고 생각할 수도 있다. Since the time of the Greeks, people have not only gotten their interventions wrong, they've gotten them backwards. Laying out a clear diagram of effects can help you sort out a situation in which two parties are driving each other to destruction, all the while thinking they are helping the situation.
Part III. Demands That Stress Patterns
Chapter 9: 왜 조정하는 것은 항상 어려운가 (Why It's Always Hard to Steer)
Summary
[V] 인간 개입 역동은 우리가 잠재적으로 통제할 수 있는 것이지만, 컨트롤러가 얼마나 훌륭하게 일을 할 수 있는지를 제한하는 일련의 "자연적인" 역학이 항상 존재한다. 컨트롤러의 업무 중 큰 부분은 그 자연적인 역동을 가능한 한 최상의 제어 하에 유지할 수 있는 개입 역동을 고안하는 것인데, 이것은 결코 완벽할 수 없다. Human intervention dynamics are those over which we potentially have control, but there is always a set of "natural" dynamics which put a limit on how good a job any controller can do. A large part of the controller's job is devising intervention dynamics that can keep the natural dynamics under the best control possible, which can never be perfect.
[V] 계산의 제곱 법칙(The Square Law of Computation)에 따르면 계산의 복잡성은 계산할 요소의 수가 증가함에 따라 비선형적으로 증가한다. The Square Law of Computation says that computational complexity grows non-linearly as the number of factors in the computation grows.
[V] 제어는 컨트롤러들이 "자연"을 상대로 하는 게임이라고 생각할 수 있다. 틱택토, 체스 같은 '완벽한 정보'의 게임조차도, 완벽하게 플레이하기 위해서는 '보드'의 크기가 커질수록 두뇌 파워가 비선형으로 증가해야 한다. Control can be thought of as a game that the controller plays against "Nature." Even games of "perfect information," such as Tic-Tac-Toe and Chess, require non-linear increases in brainpower to play perfectly as the size of the "board" increases.
[V] 단순화가 항상 필요하다. 컨트롤러들은 언제나 그들의 정신 용량4을 넘어서는 "게임"을 잘 플레이하고 있기 때문이다. 단순화는 러프한 동적 모델과 대략적(approximate)인 규칙 - "항상 프로젝트를 모듈로 분해하라"와 같은 - 의 형태를 취한다. Simplification is always needed, because controllers are always playing a "game" well outside their mental capacity. Simplification takes the form of rough dynamic models and approximate rules such as "Always break a project down into modules."
[V] 소프트웨어 엔지니어링 관리는 체스보다 어렵다. 프로젝트를 제어하는 것은 "불완전 정보"의 게임이고, "보드"의 크기도 고정되어 있지 않기 때문이다. Software engineering management is harder than Chess, because controlling a project is a game of "imperfect information," and the size of the "board" is not fixed.
[V] 규모/복잡성 역동(Size/Complexity Dynamic)은 소프트웨어 엔지니어링 전반에 걸쳐 결함 위치 역동(Fault Location Dynamic) 및 그룹 상호 작용 역동(Group Interaction Dynamic)과 같은 여러 형태로 나타난다. The Size/Complexity Dynamic appears in many forms throughout software engineering, forms such as the Fault Location Dynamic and the Group Interaction Dynamic.
Chapter 10: What It Takes To Be Helpful
Summary
[V] 우리의 뇌는 결코 우리의 야망에 비해서 충분히 크지 않을 것이기 때문에, 우리는 항상 사고 도구가 필요할 것이다. 이를테면 규모/노력 그래프와 같은. Our brains will never be big enough for our ambitions, so we'll always need thinking tools, such as size/effort graphs.
[V] 규모/노력 그래프는 규모/복잡성 역동에 대해 추론하는데 사용될 수 있다. 이를테면 프로젝트를 추정하거나 두 가지 다른 기술의 영향을 비교할 때처럼 말이다. 그러나 그래프는, 로그-로그 그래프와 같은, 역동의 비선형적 성질을 왜곡하거나 숨길 수도 있다. 우리는 데이터와 표현 방법의 변형을 통해 안정된 의미를 보는 것을 반드시 배워야 한다. Size/effort graphs can be used to reason about the Size/Complexity Dynamic, such as when estimating a project or comparing the impact of two different technologies. Graphs, however—such as log-log graphs—can also distort or conceal the non-linear nature of the dynamic. We must learn to see the stable meaning through the variations in the data and the method of presentation.
[V] 규모/복잡성 역동 때문에, 가장 유능한 프로그래머조차도 충족시킬 수 없는 요구 사항을 작성하는 것은 쉬운 일이다. Because of the Size/Complexity Dynamic, it's easy to write requirements that the most competent programmers cannot satisfy.
[V] 어느 하나의 방법이나 도구가 문제 규모의 전체 범위에서 최고인 경우는 드물다. 규모/노력 그래프는 관리자가 두 가지 방법을 결합하여 복합 패턴으로 만들어 각 방법에 대해 가장 적합한 범위를 채택하는데 도움이 될 수 있다. A single method or tool is seldom the best over the entire range of problem sizes. Size/effort graphs can help managers combine two methods into a composite pattern that adopts the best range for each one.
[V] "최저선"이 모든 기술 선택을 좌우하는 것은 아니다. 관리자들은 종종 실패의 위험을 줄이기 위해 최저선에 많은 돈을 지불하려고 한다. 크기/위험 그래프는, 특히 크기/눈금 그래프와 함께 사용할 때, 이러한 선택에 대해 추론하는 데 도움이 될 수 있다. "The bottom line" doesn't dictate all technology choices. Managers are often willing to pay a lot on the bottom line to reduce the risk of failure. The size/risk graph can help in reasoning about these choices, especially when used in conjunction with the size/effort graph.
[V] 만약 당신이 조직을 바꾸려고 한다면, 첫 번째 규칙은, 히포크라테스가 의사들에게 주는, "해치지 말라"가 되어야 한다. If you set out to change an organization, the first rule should be the one given to physicians by Hippocrates" "Do no harm."
[V] 우리는 모두 크기/복잡성 역동(Size/Complexity Dynamic)의 영향을 받기 때문에, 도움이 되려고 의도된 상호작용은 종종 관련성이 없거나, 실제론 파괴적으로 끝나기도 한다. 어떻게 보이건, 어떻게 들리건, 모두가 도움이 되려고 노력하고 있다고 가정하는 것은 좋은 생각이다. We are all subject to the Size/Complexity Dynamic, so interactions intended to be helpful often wind up being irrelevant, or actually destructive. It's a good idea to assume that regardless of how it looks or sounds, everyone is trying to be helpful.
[V] 우리는 <추가의 원리>를 적용하여 사람의 레퍼토리에 더욱 효과적인 모델을 추가할 때 가장 많은 도움을 줄 수 있다. We can help most when we apply the The Principle of Addition to add more effective models to a person's repertoire.
Chapter 11: 고객 요청에 대한 응답들 (Responses to Customer Demands)
Summary
[V] 고객과의 관계는 조직들을 특정 소프트웨어 문화 패턴으로 이끄는 두 번째 중요한 요인이다. The relationship with customers is the second important factor driving organizations to particular software cultural patterns.
[V] 단순히 고객의 수를 늘리는 것은 다음과 같이 조직에 엄청난 변화로 피해를 입힐 수 있다: Simply increasing the number of customers can wreak vast changes on an organization, such as
개발 부하 증가 increasing the development load
유지보수 부하 증가 increasing the maintenance load
개발 작업의 패턴 방해 disrupting the pattern of development work
[V] 다른 한편으로, 소프트웨어 개발 조직은 고객들에게 심각하게 파괴적이 될 수 있다. 이것이 고객이 소프트웨어 개발 조직의 컨트롤러가 되려고 노력하는 이유이며, 여러 컨트롤러들이 존재하는 상황으로 이끈다. 컨트롤러 수가 많을수록, 다른 컨트롤러에 "무작위성"이 더 많이 나타난다. On the other hand, a software development organization can be extremely disruptive to its customers. That's why customers try to be controllers of the software development organization, leading to a situation of multiple controllers. The more controllers, the more "randomness" there appears to the other controllers.
[V] 소프트웨어 개발에 영향을 미칠 수 있는 외부인의 배역은 어마어마하다. 다음과 같은 역할을 포함하여: The cast of outsiders who may influence software development is enormous, including such roles as
고객 및 사용자 customers and users
마케팅 부서 the marketing department
다른 대리인들 other surrogates
프로그래머들, 스스로 사용자 대리인으로 임명한 programmers as self-appointed user surrogates
테스터, 공식 및 비공식 대리인으로서 testers as official and unofficial surrogates
기타 계획되지 않은 대리인들 other unplanned surrogates
[V] 이러한 아웃사이더 역할의 상당수는 유효한 고객의 수를 줄이기 위한 시도로 계획되어 있다. Many of these outsider roles are planned as attempts to reduce the effective number of customers.
[V] 일부 대리인은 개발 시스템과 훨씬 더 친밀하기 때문에, 그들의 상호 작용의 힘과 빈도를 사용하여 그들의 유효 고객 수의 감소를 부정할 수 있다. Because some of the surrogates are much more intimate with the development system, they may negate their reduction of the effective number of customers with the force and frequency of their interactions.
[V] 고객과의 상호작용은 고객의 수가 증가함에 따라 위험 투성이다. 인터럽트들이 증가한다. 회의의 규모와 빈도가 증가한다. 인터럽트된 회의들로 인한 시간 손실이 증가한다. 이 모든 증가는 비선형이다. Interactions with customers are fraught with peril as the number of customers grows. Interruptions increase. Meetings increase in size and frequency. Time lost because of interrupted meetings increases. All of these increases are non-linear.
[V] 더 많은 고객이 오면, 지원해야 할 구성들이 더 많아진다. 구성들이 많아진다는 것은, 추가적인 코딩, 더 복잡한 테스트, 덜 효과적인 테스트 적용 범위, 더 긴 수리 시간을 의미한다. With more customers comes more configurations to support. More configurations means additional coding, more complex testing, less effective test coverage, and longer repair times.
[V] 고객이 여러 명일 때마다 출시들이 필요하다. 고객에게 제품이 출시되자마자, 개발 조직의 그늘에 있을 때와는 전혀 다른 역동을 가정한다. Releases are needed whenever there are multiple customers. As soon as a product is released to customers, it assumes an entirely different dynamic than when it was held in the shadow of the development organization.
[V] 소프트웨어 제품의 여러 버전들은 유지보수를 엄청나게 복잡하게 하지만, 공식적이든 비공식적이든, 더 많은 고객은 더 많은 버전을 의미한다. 빈번한 릴리즈는 개발/유지보수 과정을 복잡하게 만들지만, 빈번하지 않은 릴리스도 그러하다. 그래서 거의 모든 소프트웨어 문화는 매년 2회 정도로 릴리즈를 안정시키는 경향이 있다. Multiple versions of a software product complicate maintenance enormously, but more customers means more versions, whether official or unofficial. Frequent releases complicate the development/maintenance process, but so do infrequent releases, so that almost all software cultures tend to stabilize releases at around two per year.