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.
QSM: Volume 1.2: Why Software Gets In Trouble
Contents
Part IV. Fault Patterns
Chapter 1: Observing and Reasoning About Errors
Summary
[V] 조직이 소프트웨어 오류를 처리하는 데 어려움을 겪는 이유 중 하나는 오류와 관련하여 발생하는 많은 개념적 오류 때문이다. One of the reasons organizations have trouble dealing with software errors is the many conceptual errors they make concerning errors.
[V] 어떤 사람들은 오류를 도덕적인 문제로 만들고, 그것들이 처리되는 방식으로 인해 사업적 정당성을 잃어버린다. Some people make errors into a moral issue, losing track of the business justification for the way in which they are handled.
[V] 품질은 오류의 부재가 아니지만, 많은 오류의 존재는 제품의 품질의 다른 척도를 파괴할 수 있다. Quality is not the same thing as absence of errors, but the presence of many errors can destroy any other measures of quality in a product.
[V] 오류를 잘 처리하지 못하는 조직은 오류에 대해서도 명확하게 말하지 않는다. 예를 들어, 그들은 종종 결함(faults)과 실패(failures)를 구분하지 못하거나, 결함(faults)을 이용하여 조직 내의 사람들을 비난한다. Organizations that don't handle error very well also don't talk very clearly about error. For instance, they frequently fail to distinguish faults from failures, or use faults to blame people in the organization.
[V] 잘 기능하는 조직은, 그들이 결함과 실패를 자신의 프로세스를 제어하기 위한 정보로 사용하는 조직된 방법을 보면 알아볼 수 있다. 시스템 고장 사고(STI: System Trouble Incident)와 시스템 결함 분석(SFA: System Fault Analysis)은 실패(failures)와 결함(faults)에 대한 정보의 근본적인 소스이다. Well functioning organizations can be recognized by the organized way they use faults and failures as information to control their process. The System Trouble Incident (STI) and the System Fault Analysis(SFA) are the fundamental sources of information about failures and faults.
[V] 오류-처리 프로세스는 최소한 다섯 종류로 구분된다: 탐지(detection), 문제 지점 찾기(location), 해결(resolution), 예방(prevention), 배포(distribution). Error-handling processes come in at least five varieties: detection, location, resolution, prevention, and distribution.
[V] 개념적 오류 외에도, 사람들이 오류에 대해 저지르는 여러 가지 일반적인 관찰 오류가 있다. 선택 오류(Selection Fallacies), 관찰을 거꾸로(backwards) 하는 오류, 컨트롤러 오류(Controller Fallacy) 등. In addition to conceptual errors, there are a number of common observational errors people make about errors, including Selection Fallacies, getting observations backwards, and the Controller Fallacy
Chapter 2: The Failure Detection Curve
Summary
[V] 실패 탐지는 탐지하기 가장 쉬운 실패가 가장 먼저 검출되는 실패라는 동어 반복에 의해 지배되었기 때문에, 탐지가 진행될수록, 작업이 더 어려워지고, 꼬리가 긴(long tail) 특징적인 실패 탐지 곡선(Failure Detection Curve)을 만들어 낸다. Failure detection is dominated by the tautology that the easiest failures to detect are the first failures to detect, so that as detection proceeds, the work gets harder, producing a characteristic Failure Detection Curve with a long tail.
[V] 실패 탐지 곡선의 긴 꼬리(long tail)는 관리자가 실패 탐지 작업을 잘못 추정하는 주요 원인 중 하나이다. The long tail of the Failure Detection Curve is one of the principal reasons managers misestimate failure detection tasks.
[V] 실패 탐지 곡선은 자연적인 역동을 나타내기 때문에, 그것이 말하는 것보다 더 좋은 성과를 내기 위해 우리가 할 수 있는 일은 없다. 그러나, 우리는 더 나쁜 성과를 낼 수도 있다. 만약 우리가 어떻게 실패 감지 프로세스를 관리하는지에 주의하지 않으면 말이다. Because the Failure Detection Curve represents a natural dynamic, there is nothing we can do to perform better than it says. We can, however, perform much worse, if we're not careful of how we manage the failure detection process.
[V] 실패 탐지 곡선이 모두 나쁜 소식은 아니다. 시간에 흐름에 따라 검출된 고장의 패턴은 특정 수준의 실패 탐지에 도달하는 시간을 예측하는 데 사용할 수 있다. 테스트 커버리지를 저해하는 일이 발생하지 않는 한. The Failure Detection Curve is not all bad news. The pattern of detected failures over time can be used as a predictor of the time to reach any specified level of failure detection, as long as nothing is happening to undermine test coverage.
[V] 테스트 커버리지를 저해할 수 있는 것 중 일부는, 결함을 차단하기, 결함을 마스킹하기, 테스트하기에는 늦은 릴리즈 등이다. Some of the things that can undermine test coverage are blocking faults, masking faults, and late releases to test.
[V] 늦게 완성되는 모듈들은 부실한 코딩의 사이클에서 발생할 수 있는데, 이는 고장 가능성이 높은 모듈일 가능성이 더 높다는 것을 의미한다. 늦게 완료되는 모듈의 테스트 속도를 높이기 위해 고안된 관리 정책은 실제로는 문제를 더 악화시킬 수 있으며, 소위 "불운(bad luck)" 추정의 이유를 설명할 수 있다. Late finishing modules may arise from a cycle of poor coding, which means that they are more likely to be fault-prone modules. Management policies designed to speed testing of late finishing modules may actually make the problem worse, and may account for much so-called "bad luck" estimating.
Chapter 3: Locating The Faults Behind The Failures
Summary
[V] 시스템 크기는 결함 위치의 역동에 직접적인 영향을 미치지만, 간접적인 영향도 있다. 우리는 크기/복잡성 역동을 이기기 위해 분할과 정복(device and conquer)을 사용하며, 배달 시간을 맞추기 위해 노동력을 나누기도 한다. 그러나, 이러한 노력은 시스템 크기가 결함 발견에 걸리는 시간에 미치는 여러 가지 간접적인 영향을 일으킨다. System size has a direct effect on the dynamics of fault location, but there are indirect effects as well. We use divide and conquer to beat the Size/Complexity Dynamic, and we also divide the labor to beat delivery time. These efforts, however, lead to a number of indirect effects of system size on fault location time.
[V] 어느 조직이 자신의 STI들을 어떻게 처리하는지를 관찰하면 그 조직의 문화에 대해 많은 것을 파악할 수 있다. 특히, 당신은 그 조직의 문화적 패턴이 증가하는 고객이나 문제 수요에 대해 어느 정도로 스트레스를 받고 있는지 파악할 수 있다. You can learn a great deal about its culture by observing how an organization handles its STIs. In particular, you can learn to what degree its cultural pattern is under stress of increased customer or problem demands.
[V] 중요한 역동은 STI의 순환을 묘사하는데, 더 많은 STI들이 순환에 있을수록 비선형적으로 증가한다. An important dynamic describes the circulation of STIs, which grows non-linearly the more STIs are in circulation.
[V] STI를 잃는 것과 같은 프로세스 오류도 결함 지점을 찾는 시간을 증가시킨다. Process errors such as losing STIs also increase location time.
[V] 정치적 문제도, 지위의 경계와 같은, 결함 지점을 찾는 시간의 연장에 비선형적으로 기여할 수 있다. STI 보유자를 처벌해 순환 시간을 줄이려는 관리 행위가 오히려 역효과를 낳을 수 있다. Political issues, such as status boundaries, can also contribute non-linearly to extending location time. Management action to reduce circulation time by punishing those who hold STIs can lead to the opposite effect.
[V] 일반적으로, STI를 허술하게 취급하면 관리 부담이 증대되고, 결국에는 STI의 허술한 취급으로 이어진다. STI가 통제 불능이 되면, 경영진은 그들의 문화 패턴에 대해 어떤 정보를 주고 있는지 연구한 뒤, 단순한 증상이 아니라 근본 원인(root cause)을 파악하는 조치를 취해야 한다. In general, poorly controlled handling of STIs leads to an enlarged administrative burden, which in turn leads to less poorly controlled handling of STIs. When STIs get out of hand, management needs to study what information that gives them about their cultural pattern, then take action to get at the root causes, not merely the symptoms.
Chapter 4: Fault Resolution Dynamics
Summary
기본 결함 해소 역학은 크기/복잡성 역학의 또 다른 사례로, 결함이 많아질수록, 또한 결함당 복잡성이 클수록, 시스템이 커질수록 고장의 해결 시간이 비선형적으로 증가한다. Basic fault resolution dynamics are another case of Size/Complexity Dynamics, with more faults and more complexity per fault leading to a non-linear increase in fault resolution time as systems grow larger.
부작용은 고장해결에 비선형성을 더한다. 부작용을 고려하는 데 더 많은 시간이 걸리거나, 한 가지를 바꾸고 무심코 다른 것을 바꿀 때 부작용을 일으키기도 한다. Side effects add more non-linearity to fault resolution. Either we take more time to consider side effects, or we create side effects when we change one thing and inadvertently change another.
가장 분명한 부작용의 유형은 고장 피드백이며, 고장 피드백은 고장 피드백 비율(FFR)으로 측정할 수 있다. 결함 피드백은 다른 결함을 해결하는 동안 결함을 생성하는 것이다. 고장은 기능적 또는 성능적 결함일 수 있다. The most obvious type of side effect is fault feedback, which can be measured by the Fault Feedback Ration (FFR). Fault feedback is the creation of faults while resolving other faults. Faults can be either functional or performance faults.
FFR은 프로젝트 제어 붕괴에 대한 민감한 척도다. 잘 통제된 프로젝트에서 FFR은 프로젝트가 예정된 종료에 가까워질수록 감소해야 한다. The FFR is a sensitive measure of project control breakdown. In a well-controlled project, FFR should decline as the project approaches its scheduled end.
FFR을 제어하는 한 가지 방법은 고장 해결 방법이 "단 한 줄의 코드"라 하더라도 신중한 검토를 실시하는 것이다. 작은 변화가 문제를 일으킬 수 없다는 가정은 작은 변화로 이어져 큰 변화보다 더 큰 문제를 일으킨다. One way to keep the FFR under control is to institute careful reviewing of fault resolutions, even if they are "only one line of code." The assumption that small changes can't cause trouble leads to small changes causing more trouble than bigger changes.
결함 및 성능 비효율의 추가 외에도 시스템이 악화되는 여러 가지 방법이 있으며, 이러한 방법은 일반적인 프로젝트 측정에 나타나지 않는다. 예를 들어, 설계 무결성이 파괴되고, 문서가 최신 상태로 유지되지 않으며, 코딩 스타일이 복잡해진다. 이 모든 것이 시스템의 유지 보수성의 저하로 이어진다. There are a number of ways in which a system deteriorates besides the addition of faults and performance inefficiencies, and these ways do not show up in ordinary project measurements. For instance, design integrity breaks down, documentation is not kept current, and coding style becomes patchy. All of these lead to a decrease in the system's maintainability.
모듈형, 즉 "블랙박스"의 무결성이 깨졌을 때, 시스템은 각각의 변화로부터 증가하는 "리플 효과"를 보여준다. 즉, 한 가지 변화가 많은 다른 변화를 일으키기 위해 파급되는 것이다. When the integrity of a modular, or "black box," design breaks down, the system shows a growing "ripple effect" from each change. That is, one change ripples through to cause many other changes.
시스템의 악화를 피하려면, 시스템뿐만 아니라 유지관리성 또한 유지되어야 한다. If we are to avoid deterioration of systems, they must not only be maintained, but their maintainability must also be maintained.
관리자와 개발자는 정비 난관에 대한 보호로서 초기 설계에 대한 과신력을 보이는 경우가 많다. 이런 종류의 과신감은 쉽게 타이타닉 효과로 이어질 수 있는데, 왜냐하면 코드에 문제가 있을 수 없다는 생각은 코드를 모든 종류의 잘못된 방법에 노출시키기 때문이다. Managers and developers often show overconfidence in the initial design as protection against maintenance difficulties. This kind of overconfidence can easily lead to a Titanic Effect, because the thought that nothing can go wrong with the code exposes the code to all sorts of ways of going wrong.
Part V. Pressure Patterns
Chapter 5: Power, Pressure, and Performance
Summary
압력/성능 관계에 따르면 압력이 가해질 경우 잠시 성능을 끌어올린 다음 반응이 없어지기 시작하다가 붕괴로 이어질 수 있다고 한다. The Pressure/Performance Relationship says that added pressure can boost performance for a while, then starts to get no response, then leads to collapse.
마지막 결함을 찾도록 압력을 가하면 마지막 결함을 찾는 시간이 쉽게, 어쩌면 무한정 길어질 수 있다. Pressure to find the last fault can easily prolong the time to find the last fault, perhaps indefinitely.
스트레스/컨트롤 다이나믹은 우리가 외부 압력에 반응할 뿐만 아니라, 우리가 통제력을 상실하고 있다고 생각할 때 자신에게 가하는 내부 압력에 반응한다고 설명한다. 이 동적 특성은 압력/성능 관계를 더욱 비선형적으로 만든다. The Stress/Control Dynamic explains that we not only respond to the external pressures, but to internal pressures we place on ourselves when we think we are losing control. This dynamic makes the Pressure/Performance Relationship even more non-linear.
압력에 의한 고장은 여러 가지 형태로 나타난다. 특히 사물을 자기 뜻대로 보라는 동료들의 압력에 대응하여 판단력이 가장 먼저 갈지도 모른다. Breakdown under pressure comes in many forms. Judgment may be the first thing to go, especially in response to peer pressure to see things their way.
사람들이 육체적으로든 정신적으로든 프로젝트를 떠나면, 그것은 그들 자신을 떠날 가능성이 더 높은 나머지 사람들에게 압력을 가한다. As people leave a project, either physically or mentally, it adds pressures to the remaining people, who are then more likely to leave themselves.
관리자는 이미 군림하고 있는 전문가에게만 새로운 과제를 부여하는 것을 선택함으로써 '말뚝이 다이나믹'을 만들어 낼 수 있다. 이것은 그들의 부하와 전문성을 더해주기 때문에 그들은 다음 과제를 받을 가능성이 더 높다. Managers may create a Pile-On Dynamic by choosing to give new assignments only to those people who are already the reigning experts. This adds to their load, and their expertise, which makes it more likely they'll get the next assignment.
생명을 위협하는 상황이 아닌데도 '공황 반응'으로 스트레스에 반응하는 사람도 있다. 그런 사람들은 스트레스를 많이 받는 프로젝트에 참여해서는 안 되며, 그렇지 않으면 스트레스를 가중시킬 뿐이다. Some people respond to stress with a Panic Reaction, even though the situation is not anything like life-threatening. Such people must not be in high-stress projects, or they will only add to the stress.
압력을 관리할 수 있다. 노동자들이 자율규제하고, 경영자들이 힘을 실어주고, 더 많은 압박에 대한 대비태세를 측정하기 위해 성과보다는 대응력을 발휘하는 것이 도움이 된다. Pressure can be managed. It helps if the workers are self-regulating, the managers are empowering, and that responsiveness, rather than performance, is used to measure readiness for more pressure.
Chapter 6: Handling Breakdown Pressure
Summary
소프트웨어 프로젝트는 시간의 현실이 마침내 그들이 실제로 어디에 있는지 깨닫게 할 때 일반적으로 무너진다. 그러나 이렇게 되면 표시되는 증상은 각 프로젝트와 개인마다 고유하게 나타난다. Software projects commonly break down when the reality of time finally forces them to realize where they actually are. When this happens, however, the symptoms displayed are unique to each project and each individual.
많은 증상들은 일을 이리저리 뒤척이며, 아무것도 이루지 못하거나 심지어 실제로 프로젝트를 거꾸로 보내는 것과 같다. 이러한 역학관계 중 하나는 기존 근로자들 간의 업무 분담을 통해 브룩스의 법칙을 물리치려는 시도다. Many symptoms are equivalent to shuffling work around, accomplishing nothing or, even worse, actually sending the project backwards. One such backwards dynamic is the attempt to beat Brooks's Law through splitting tasks among existing workers.
비효율적인 우선 계획은 아무것도 하지 않는 일반적인 방법이다. 여기에는 모든 것을 최우선 순위로 설정하거나, 프로젝트 우선 순위에 관계 없이 자신의 우선 순위를 선택하거나, 가장 쉬운 작업을 먼저 수행하는 것 등이 포함된다. Ineffective priority schemes are common ways of doing nothing. These including setting everything to number one priority, choosing your own priority independent of project priority, or simply doing the easiest task first.
아무것도 하지 않는 최종적인 방법은 '뜨거운 감자'를 순환시키는 것인데, '측정' 시간이 되면 경영진이 책상 위에 있으면 자신에게 불리하게 작용한다. A final way of doing nothing is to circulate "hot potatoes," which are tasks that management counts against you if they are on your desk when "measurement" time comes.
관리자들이 실제로 아무것도 하지 않고 있다는 것을 관찰할 수 있는 여러 가지 방법이 있다. 그들은 그럴지도 모른다. There are a number of ways to observe that managers are actually doing nothing. They may
품질이 나쁜 제품을 받아들이고 있다. be accepting poor quality products
일정 미끄러짐을 수용하지 않음 not be accepting schedule slippage
리소스 오버런을 수용하고 있음 be accepting of resource overruns
작업자가 사용할 수 없음 be unavailable to their workers
프로젝트를 제대로 수행할 시간이 없다고 주장 assert that they have no time to do the project right
시간의 압박에 의해 프로젝트가 무너지고 있다는 확실한 신호는 관리자와 노동자가 합선 절차를 시작하는 것이다. 이러한 불변성은 관리자가 개선하고자 했던 바로 그 품질이 단락 작용에 의해 악화되는 부메랑 효과를 만들어낸다. A sure sign that a project is breaking down under time pressure is when managers and workers start short-circuiting procedures. This invariable creates a boomerang effect in which the very quality the manager intended to improve is made worse by the short-circuiting action.
시간과 자원을 절약하기 위해 열악한 품질을 선적하기로 한 결정은 항상 부메랑 효과를 낳는다. 우회 품질보증도 비슷하다. 이 두 가지 전술은 무엇보다도 개발 과정의 파괴, 더 많은 비상 사태와 방해, 그리고 사기의 파괴로 이어진다. The decision to ship poor quality to save time and resources always creates a boomerang effect. Bypassing quality assurance is similar. Both of these tactics lead, among other things, to destruction of the development process, more emergencies and interruptions, and devastation of morale.
사기가 저하되어 프로젝트 불경기로 접어들면 개선은커녕 공정의 질도 유지되지 않는다. 위기 이전에 구축된 신뢰는 조직이 더 빨리 회복하는 데 도움이 되겠지만, 위기 동안 신뢰를 구축하려는 시도는 역효과를 낳을 것이다. 특히 "나를 믿어!" When morale deteriorates into project depression, process quality will not be maintained, let alone improved. Trust built before the crisis will help an organization recover more quickly, but attempts to build trust during the crisis will probably backfire—especially if they are in the form of telling: "Trust me!"
다수의 고객이 부메랑 사이클에 대한 압력을 증가시켜 결과적으로 품질이 저하되어 고객이 멀어지게 되고, 따라서 조직이 안정화되거나 조직이 사망하게 된다. Multiple customers increase the pressure on the boomerang cycle, up to the point that the resultant poor quality drives away customers, thus stabilizing the organization—or killing it.
Chapter 7: What We've Managed To Accomplish
Summary
우리의 실패를 연구함으로써 얻을 수 있는 인상에도 불구하고, 우리는 소프트웨어 산업의 지난 40년 동안 많은 것을 해냈다. In spite of the impression we might get from studying our failures, we've managed to accomplish a great deal in the past 4 decades of the software industry.
우리가 많은 것을 성취한 이유 중 하나는 우리들 중 많은 이들이 가지고 있는 가장 강력한 자산인 사고의 질이다. One of the reasons we've accomplished a great deal is the quality of our thinking, which is the strongest asset many of us have, when we use it.
관리자를 선발하는 과정 때문에 우리 산업은 아마 어려움을 겪었을 것이다. 프로그래밍 업무에 자신을 선택하는 사람들은 아마도 관리직에 가장 적합한 "자연인"은 아닐 것이다. 그럼에도 불구하고 훈련을 받으면 관리를 잘 하는 법을 배울 수 있었다. 하지만 우리가 관리자을 존중하지 않는 한, 그들은 그들이 필요로 하는 관리 교육을 10분의 1도 받지 못할 것 같다. Our industry has probably suffered because of the process by which we select our managers. People who select themselves into programming work probably are not the best "naturals" for management jobs. Nevertheless, they could learn to do a good job of managing, if they were given the training. As long as we don't honor management, however, they're not likely to receive one-tenth the management training they need.
소프트웨어와 하드웨어 도구의 공급자에게 귀를 기울인다면 소프트웨어 산업의 성과는 당신이 믿을 수 있는 것보다 훨씬 더 크다. 우리가 잘 하고 있지 않지만, 그들의 도구가 우리가 필요로 하는 마법의 총알이 될 것이라고 믿게 만드는 것이 그들의 이익이다. The accomplishments of the software industry are much greater than you would believe if you listened to the purveyors of software and hardware tools. It is in their interest to make us believe that we're not doing very well, but that their tool will be the magic bullet we need.
우리는 위대한 일을 성취하고 싶기 때문에 마법의 총알에 어리버리들이 되는 경향이 있지만, 위대한 일은 보통 대중적인 이미지와는 달리 일련의 작은 단계를 통해 성취된다. We tend to be suckers for magic bullets because we want to accomplish great things, but great things are usually accomplished through a series of small steps, contrary to the popular image.
야심이 너무 강해서 생산성이 얼마나 높아졌는지 인식하지 못할 수도 있다. 우리가 어떤 것을 잘 해내는데 성공하면, 우리는 즉시 우리의 성과를 평가하기 위해 멈추지 않고 좀더 웅장한 것을 시도한다. We may fail to recognize how much our productivity has increased because we are so ambitious. Once we succeed in doing something well, we immediately attempt something more grand, without stopping to take stock of our accomplishments.
각각의 패턴이 우리 산업의 발전에 기여했다. 패턴 0은 일반 대중들에게 컴퓨터를 덜 무섭게 만들었다. 패턴 1은 우리의 생산성에 기여하는 많은 혁신을 이루었다. 패턴 2는 이러한 기술 혁신을 일상적인 방법으로 많은 대형 프로젝트를 완료할 수 있도록 하는 방법론으로 묶어 왔다. 패턴 3은 우리에게 더 큰 프로젝트를 통제하는 데 필요한 것을 가르쳐 주었다. 패턴4와 5의 기여는 여전히 가능성의 비전 측면에서 더 많지만, 그것은 실제 성취만큼 진척에 중요하다. Each pattern has contributed to the development of our industry. Pattern 0 has made computers less frightening to the general public. Pattern 1 has made many innovations that have contributed to our productivity. Pattern 2 has strung these innovations together into methodologies that make it possible to complete many larger projects in routine ways. Pattern 3 has taught us what is needed to keep even larger projects under control. The contributions of Patterns 4 and 5 are still more in terms of visions of possibilities, but that's as important to progress as actual accomplishments.
메타패턴은 산업 전반의 문화의 발전 패턴이다. 다시 한 번 각 패턴이 메타패턴의 발전에 기여했고, 우리는 소프트웨어 취급법을 배울 뿐만 아니라 소프트웨어 취급법을 배우고 있다. Meta-patterns are the development patterns of the culture of the industry as a whole. Once again, each pattern has contributed to the development of meta-patterns, and we are not only learning to handle software, but are learning how to learn to handle software.
QSM: Volumn 2.1: How to Observe Software Systems
Contents
Part I. 받아들이기 (Intake)
Chapter 1. 관찰이 왜 중요한가 (Why Observation is Important)
Summary
소프트웨어 엔지니어링 관리가 거의 실패할 때마다 제품 뿐만 아니라 공정의 품질 문제 때문에 실패한다. Almost any time software engineering management fails, it fails because of quality problems in the process as well as the product.
관리가 효과적인 관찰을 하지 않고 있기 때문에 품질 문제가 관리를 "깜짝 놀라게" 한다. Quality problems "surprise" management because management is not making effective observations.
관리자들이 관찰하지 못하는 것 중 하나는 그들 자신의 소프트웨어 엔지니어링 문화인데, 이것은 놀랍지 않다. 왜냐하면 문화는 "당신이 알고 있다는 것을 모르고 있는 무언가"이기 때문이다. One of the things managers fail to observe is their own software engineering culture, which is not surprising, because culture is "what you know that you don't know you know."
크로스비는 문화 패턴의 아이디어를 산업 프로세스 연구에 적용하고, 크게 각각에서 발견되는 관리 태도를 바탕으로 5가지 패턴을 관찰했다. Crosby applied the idea of cultural patterns to the study of industrial processes and observed five patterns based largely on the management attitudes to be found in each.
소프트웨어 엔지니어링 연구소(SEI)는 크로스비의 작업을 소프트웨어와 연관시키고, 각 패턴에서 발견되는 프로세스의 종류와 관련된 5가지 수준의 "프로세스 성숙도"를 식별했다. The Software Engineering Institute (SEI) related Crosby's work to software and identified five levels of "process maturity" related to the types of processes found in each pattern.
(조직 내) 사람들이 행동한다고 말하는 것에 따라 조직을 분류하면, 다음과 같은 수의패턴의 시스템과 매치할 수 있다: Classifying organizations by what people in them say they're doing, we can match them to the numbers of other systems of patterns as follows,
무자각 Oblivious: "우리는 우리가 프로세스를 수행하고 있는지도 모르고 있다." "We don't even know that we're performing a process."
가변 Variable: "우리는 지금 이 순간 우리가 느끼는대로 무엇이든 한다." "We do whatever we feel like at the moment."
루틴 Routine: "우리는 우리의 루틴을 따른다 (패닉에 빠졌을 때를 제외하고)" "We follow our routines (except when we panic)."
조정하는 Steering: "우리는 우리의 루틴이 만들어내는 결과들에 따라 우리의 루틴을 선택한다." "We choose among our routines by the results they produce."
예측하는 Anticipating: "우리는 루틴의 과거 경험을 바탕으로 루틴을 수립한다." "We establish routines based on our past experience with them."
일치적인 Congruent: "우리 모두는 언제나 모든 것을 개선하는데 관여한다." "We all are involved in improving everything all of the time."
소프트웨어 문화 패턴을 결정하는 SEI 방법은 설문조사를 실시하고 인터뷰와 관찰로 이를 추적하는 것으로 시작한다. 인터뷰와 관찰이 생략되면, 설문은 무용지물보다 더욱 나쁜 것이 될 수 있다. The SEI method of determining software cultural pattern starts by conducting a survey and following it up with interviews and observations. If the interviews and observations are omitted, the survey can prove worse than useless.
각각의 문화는 각각의 독특한 관찰 스타일을 가지고 있다. Each culture has its own characteristic observation style.
무의식 (패턴0)과 가변 (패턴1) 문화는 일반적으로 약간의 문제가 발생한 후에만 관찰하며, 이는 비용과 위험을 크게 증가시킨다. The Oblivious (Pattern 0) and Variable (Pattern 1) cultures typically observe only after there is some trouble, which greatly increases their costs and risks.
루틴 (패턴2) 조직은 소프트웨어에 대한 접근법과 관찰에 있어 훨씬 더 체계적이 되려고 노력한다. 그들은 실패 정보에 초점을 맞추는 경향이 있다. 루틴 패턴은 위기로 인해 놀라기 전까지 많은 것들을 잘 처리한다. Routine (Pattern 2) organizations try to be much more systematic in their approach to software and thus to observation as well. They tend to focus on failure information. The Routine pattern handles a lot of things well, until they are surprised by a crisis.
조정하는 (패턴3) 조직은 종종 루틴 조직의 신생 "측정치" 프로그램을 변형시키고 인간의 행동을 보다 직접적으로 관찰하려고 한다. Steering (Pattern 3) organizations often transform the fledgling "metrics" programs of the Routine organization and try to observe human behavior more directly.
조정하는 관리자들은 어떻게 적절하게 따라야 할지 알고 있다, 비난하는 것이 아니라, 정보를 수집하는 것을 통해 Steering managers know how to follow through appropriately, not by blaming but by gathering information.
실패 감지의 다중 소스는 라이프 사이클의 어느 특정 순간에 탐지 가능성이 더 크다는 것을 의미한다. 조기 발견은 개발 및 사용 비용 절감을 의미한다. Multiple sources of failure detection means greater likelihood of detection at any particular moment in the life cycle. Early detection means reduced development and usage costs.
예상하는 (패턴4) 조직은 측정을 사용하여 문제 예방에 초점을 맞추고 있으며, 관리자가 이용할 수 있는 정보의 출처를 지속적으로 개선하고 있다. Anticipating (Pattern 4) organizations use measurement to focus on prevention of problems, and are continually improving the sources of information available to managers.
일치적 (패턴5) 조직은 더 미묘한점에 주목함으로써 더 일찍 관찰하는 법을 배운다. 그들은 또한 메타 관찰, 즉 그들 자신의 관찰 방법에 대한 관찰에 대해서도 연구한다. 그리고 그들이 배우는 모든 것은 그들의 조직 전체에 적용된다. Congruent (Pattern 5) organizations learn to observe earlier, by taking note of more subtle things. They also work on meta-observation—the observation of their own ways of observing. And everything they learn is applied throughout their organization.
Chapter 2: 무엇을 관찰할지 고르기 (Selecting What to Observe)
Summary
그들이 체계적으로 관찰하고 관찰하지 못하는 것에 의해 당신은 관리 뿐만 아니라 문화적 패턴도 특징지을 수 있다. You can characterize management as well as cultural patterns by what they systematically observe and fail to observe.
상호작용 모델(SatirInteractionModel)의 첫번째 주요 단계는 수용이다. 나는 세상으로부터 데이터를 얻기로 결심하고, 어떤 데이터를 얻어야 할지를 선택하며, 충분할 때 결정한다. The first major step in the Interaction Model is intake. I decide to obtain data from the world, I select which data to obtain, and I decide when I have enough.
입력 단계에서, 우리는 우리가 세상에 존재하는 것, 심지어 의도적으로 보내지는 것조차 정확히 얻지 못하고 있을 가능성을 알아야 한다. In the input step, we need to be aware of the possibility that we aren't getting exactly what is out there in the world, even what is intentionally sent.
세상으로부터 오는 데이터는 어느 누구도 특정한 방식으로 반응하게 하지 않는다. Data coming from the world doesn't make anyone react in a certain way.
모든 상황은 관찰의 가능성을 제시하지만, 나는 어떤 가능성을 받아들일지 선택해야 한다. 모든 것을 관찰하는 것은 인간적으로 가능하지도 않고 경제적으로도 가능하지도 않다. 한 가지를 관찰하려면 다른 것을 관찰하는 것을 생략해야 한다. Every situation offers possibilities for observation, but I must choose which possibilities to accept. Observing everything is neither humanly possible nor economically feasible. To observe one thing, I must omit observing something else.
명시적인 보상과 처벌이 없더라도 어떤 것을 암묵적으로 관찰하는 것만으로도 그것을 더욱 강화시킨다. Even without explicit rewards and punishments, the mere fact of observing something implicitly reinforces it.
측정의 의미에 대한 개인적 모델이 없다면 측정은 위험하다. 개인적인 관찰 모형은 우리의 관찰 노력을 인도하여 내가 통제하려고 하는 바로 그 프로젝트에 의미 있고, 효율적이며, 최소한의 방해만 될 것이다. 측정 모델은 무엇을 측정해야 하는지, 어떻게 데이터를 해석해야 하는지, 왜 측정하는지, 얼마나 정밀하게 측정해야 하는지 알려준다. Measurement is dangerous without a personal model of what the measurements might mean. A personal model of observation guides our observation efforts so they will be meaningful, efficient, and minimally disturbing to the very project I'm trying to control. The measurement model tells me what to measure, how to interpret those data, why I'm measuring, how much precision I need to measure.
많은 예들은 잘못된 모형을 사용하는 것 또한 문제를 일으킬 것이며, 어쩌면 전혀 모델이 없는 것보다 더 나쁜 것일 수도 있다는 것을 암시한다. Many examples imply that using a wrong model will also cause problems, perhaps even worse than no model at all.
시스템의 상태를 알때만 오직 그 행태를 조절할 수 있는 분별 있는 개입을 할 수 있다. Only when I know the state of the system can I make sensible interventions to control its behavior.
동일한 관찰에 다른 의미를 부여하는 능력은 아마도 패턴2(루틴) 조직의 특징인 소프트웨어 재난의 많은 부분을 설명할 것이다. The ability to put different meanings on the same observation probably accounts for many of the software disasters that are so characteristic of Pattern 2 (Routine) organizations.
가능한 통제 개입의 관점에서 해석할 수 없는 관찰은 유용하지 않다. 우리가 이런 식으로 해석할 수 있는 관측은, 그것이 "측정"처럼 보이지 않는 경우에도 유용하다. Observations that we can't interpret in terms of possible control interventions are not useful. Observations that we can interpret in this way are useful, even if they don't seem to be "measurements."
조직의 중요한 척도 중 하나는 관리자들이 동작하는 모델이 없는 지나치게 정밀한 측정에 얼마나 몰두하는가이다. One important measure of an organization is how preoccupied the managers are with overly precise measurements for which they have no working models.
두 가지 주요한 관리상의 실수는 시스템 사고력 부족과 의미있는 관찰을 생성하지 못한 것이다. 어느 정도는, 한 사람에게 더 잘해주는 것이 다른 사람에게 나쁜 짓을 한 것에 대한 보상에 도움이 된다. Two major management mistakes are lack of systems thinking and failure to generate meaningful observations. To some extent, doing better on one helps compensate for doing badly on the other.
Chapter 3: 제품을 시각화하기 (Visualizing the Product)
Summary
품질에 대한 데밍과 크로스비의 아이디어는 모두 제조 조직에서의 경험에서 파생된 것이다. 그러나 소프트웨어 개발은 일차적으로 제조가 아닌 엔지니어링 프로젝트 관리 운영이다. Both Deming's and Crosby's ideas on quality are derived from experience with manufacturing organizations. Software development, however, is not primarily a manufacturing operation, but an engineering project management operation.
제조 관리와 프로젝트 관리 모두 제어의 사이버네틱스 모델을 공유한다. 사이버네틱 모델을 적용하려면 출력이 가시적ㄱ이어야 한다. 즉, 소프트웨어에 의해 자동으로 충족되지 않는 조건이다. Both manufacturing management and project management share the cybernetic model of control. For the cybernetic model to be applicable, outputs must be visible—a condition that is not automatically met by software.
관찰자로서 행동할 때, 사람들은 일반적으로 시각, 청각, 운동, 후각, 그리고 미각, 등 이러한 감각들에 의존한다. 우리는 각자 좋아하는 감각이 있지만, 우리가 좋아하는 감각의 사용이 박탈되었을 때, 우리는 다른 감각으로 적응할 수 있다. When acting as observers, people ordinarily have these sensory modalities to draw upon—visual, auditory, kinesthetic, olfactory, and gustatory. We each have our favorite modalities, but when deprived of the use of our favorite modality, we can adapt by using the others.
우리는 소프트웨어를 간접적으로밖에 경험할 수 없다. 그것은 어떤 번역 과정 (프로그래머가 소프트웨어와 집적 접촉하는 것처럼 말하는 경우가 많지만)을 거치기는 하지만. 수많은 친숙한 소프트웨어 도구들이 소프트웨어를 더 잘 보이게 하기 위해 고안되었다. 이러한 관측 가능성 도구는 레이더가 어떤 전쟁을 해야 하는지를 소프트웨어로 만드는 것이다.: 그들은 "어둠 속에서" 조종하는 것을 가능하게 한다. We can only experience software indirectly, though some translation process (although programmers often talk as if they are in direct contact with software). An enormous number of familiar software tools have been designed to make software more visible. These observability tools are to software what radar was to warfare: they make it possible to steer "in the dark."
같은 정보를 전달하는 서브 모달리티일수록 메세지가 강해진다. 반면에, 복수의 모달리티는 특정 관찰자에게는 정보를 왜곡할 수 있다. 이러한 왜곡은 과학을 위한 것은 아니지만 관리를 위해 완벽하게 정당화될 수 있다. The more sub-modalities that carry the same information, the stronger the message. On other hand, multiple modalities may distort the information for certain observers. Such distortion may be perfectly justified for managing, though not for science.
우리의 뇌 용량은 제한적이기 때문에, 우리는 같은 측정에 대해 두 개 이상의 사진이 필요하다. 그 사진들의 왜곡은 우리의 제한된 정신력을 극복하기 위해 우리가 지불하는 대가이다. Because our brain capacity is limited, we need more than one picture of the same measurement. The distortions in those pictures are the price we pay for overcoming our limited mental capacity.
소프트웨어의 모든 사진은 지도인데, 그 지도는 영역이 아니다. 효과적인 다른 모달리티의 표현 뿐 만 아니라 많은 시각화 지도가 동일한 영역에 필요하다. Every picture of software is a map, and the map is not the territory. For effective software management, many maps—many visualizations as well as representations in other modalities—are needed of the same territory.
제품의 관찰을 방해하는 것은 어떤 것이든 조직이 더 높은 수준의 생산성과 품질을 달성하지 못하게 한다. 가시성이 없이는, 우리는 어떤 프로젝트에 대한 통제권을 보장할 수 있는 능력을 상실한다. Anything that prevents observation of the product also prevents the organization from achieving higher levels of productivity and quality. Without visibility, we lose the ability to guarantee control over any project.
완료된 제품은 사람들이 가장 먼저 시각화할 수 있어야 하는 것이다. Deming은 자신이 작업하고 있는 것을 시각화할 수 없는 사람들은 분명히 그것의 품질에 대한 실질적인 기여를 하는데 어려움을 겪을 것이라고 관찰했다. The finished product is the first thing that people should be able to visualize. Deming observed that people who can't visualize what they're working on will certainly have a hard time coming up with real contributions to its quality.
가시성이 매우 중요하기 때문에 우리는 다음 세 가지 질문을 함으로써 조직이 패턴3 혹은 조정하는 문화에 도달했는지 여부를 신속하게 평가할 수 있다: 모든 것을 볼 수 있는가? 시각화할 수 있는가? 일그러지지 않은 채로? Visibility is so important we can make a quick assessment of whether or not an organization has reached a Pattern 3, or Steering, culture by asking three questions: Is everything available to view? visualizable? undistorted?
Chapter 4: 절차(프로세스)를 시각화하기 (Visualizing the Process)
Summary
예측하는 (패턴4) 관리자들은 각 제품의 품질을 단순히 조절하는 것이 아니라, 모든 제품의 품질을 동시에 조절하는 방식으로 관리한다. Anticipating (Pattern 4) managers are not just steering the quality of each product, they are steering the quality of all products at the same time by steering the process.
프로세스가 여러분의 제품인 경우, 당신은 소프트웨어를 볼 수 있고, 시각화할 수 있으며, 왜곡되지 않은 상태에서 사용했던 것과 동일한 기준을 사용하여 프로세스를 시각화할 수 있어야 한다. When processes are your products, you must be able to visualize your processes, using the same criteria you used when software was the product: available to view, visualizable, and undistorted.
프로세스 정보는 반드시 인간 감각 시스템이 사용할 수 있는 형식으로 제시되어야 한다. 데밍의 작업은 프로세스 데이터를 시각 시스템에 사용할 수 있도록 하기 위해 다양한 그림의 중요성을 강하게 강조해 왔다. Process information must be presented in formats that the human sensory system can use. Deming's work has strongly emphasized the importance of a variety of pictures to make process data available to the visual system.
프로세스 정보의 피드백은 제품 정보와 같은 모든 왜곡의 희생물이며, 몇 가지 더 있다. Feedback of process information is prey to all the same distortions as product information—and a few more.
제품 가시성보다는 프로세스 가시성에 대한 질문을 가지고 조직이 패턴4 또는 예상하는 문화에 도달했는지 여부를 신속하게 평가할 수 있다. 패턴4 관리자는 다른 어떤 것이든 모든 것이 정보라는 견해를 가지고 있다. We can make a quick assessment of whether or not an organization has reached a Pattern 4, or Anticipating, culture, with questions about process visibility rather than product visibility. Pattern 4 managers take the view that no matter what else it is, everything is information.
모든 사람이 공유된 시각화 기법을 배운다면, 그들은 프로세스 개선을 논의할 때 공통의 어휘를 공유하게 된다. 이것은 데밍 접근법의 필수적인 부분이다. If everyone is taught a shared set of visualization techniques, they will share a common vocabulary when discussing process improvement. This is an essential part of the Deming approach.
시각화는 흐름, 원인과 효과, 분포, 추세를 설명하는데 사용할 수 있다. Visualizations can be used to describe flow, cause and effect, distributions, and trends.
프로젝트 제어판은 프로젝트의 모든 활력 징후를 보여주기 위해 하나의 작은 영역에 다수의 시각화를 결합한다. 관리자는 프로젝트 제어판을 모니터링하여 프로젝트의 일부 측면에 주의가 필요한 시점을 신속하게 알 수 있다. A project control panel combines a number of visualizations in one small area to show all the vital signs of the project. By monitoring the project control panel, a manager can know quickly when some aspect of the project requires attention.
Part II. 의미 (Meaning)
Chapter 5: 해석에 대한 한 케이스 스터디 (A Case Study of Interpretation)
Summary
SatirInteractionModel은 사람들이 항상 그들이 가지고 있는 데이터로부터 의미를 부여하려고 노력한다고 말한다. The Satir Interaction Model says that people always attempt to make meaning from the data they take in.
소프트웨어 문화는 시간이 지남에 따라 지속되는 무의식적인 패턴을 통해 그 존재를 알려준다. 그들의 무늬는 여러 가지 방법으로 볼 수 있다. 슬립차트는 조직의 약속과 전달의 차이를 해석하는데 도움을 주는 데이터의 시각화로서, 조직의 문화를 잘 특징짓는 것이다. Software culture makes its presence known through unconscious patterns that persist over time. Their patterns can be seen in many ways. The slip chart is a visualization of data that helps us interpret the differences between an organization's promise and delivery—a good characterization of its culture.
슬립차트는 이미 이용 가능한 정보와 공개 정보를 이용하여 어떤 프로젝트에서든 저렴하게 얻을 수 있는 측정을 묘사하고 있다. 정보는 예정된 전달 날짜, 해당 전달 날짜의 변경 사항 및 해당 변경이 발표된 날짜로 구성된다. The slip chart depicts a measurement that can be obtained cheaply on any project using information already available and public. The information consists of scheduled delivery dates, changes in those delivery dates, and the dates on which those changes are announced.
슬립은 전달 예정일의 변경사항이다. 공고일은 새로운 예정 전달일이 공개된 날이다. 슬립에는 새로운 전달 날짜와 다음 새로운 전달 날짜의 발표 날짜를 표시하여 문화적 패턴을 보여준다. A slip is a change in the scheduled delivery date. The announcement date is the date on which a new scheduled delivery date is made public. The slip chart reveals cultural patterns by plotting the new delivery date versus the announcement date for that next new delivery date.
공고 일자와 옛날 전달 일자의 차이가 리드이다. 슬립-리드 차트는 슬립과 리드에 관련된 스캐터 다이어그램이다. The difference between the announcement date and the old delivery date is the lead. The slip-lead chart is a scatter diagram relating slips and leads.
건강한 프로젝트에서는, 슬립을 발표하기 전에 예정된 날짜에 프로젝트가 가까워질수록 슬립은 작아진다. In a healthy project, the closer the project is to the scheduled date before announcing a slip, the smaller that slip will be.
각 슬립은 오버헤드 지연을 추가하는데, 그것은 "작은 슬립은 받지 말라"라는 조언의 하나의 이유이다. Each slip adds an overhead delay, which is one reason for the advice, "Take no small slips."
일관된 측정 패턴은 조직 문화의 많은 측면을 드러낸다. 슬립 차트, 슬립-리드 차트, 램프 차트 등 다양한 시각화를 통해 데이터에서 의미를 추출할 수 있다. Consistent patterns of measurement reveal many aspects of an organization's culture; the meaning can be extracted from the data with a variety of visualizations, such as slip charts, slip-lead charts, and ramp charts.
시각화에 대한 사람들의 반응도 의미를 나타내는 데이터를 제공한다. People's reactions to visualizations also provide data that suggest meaning.
가장 중요한 문화적 의미는 데이터 해석이 소프트웨어 엔지니어링 관행의 개선을 가져올 수 있는 학습을 차단하기 때문에 데이터 해석을 차단하는 태도다. The most important cultural meanings to unearth are attitudes that block interpretations of data because they block the learning that could lead to improvement in software engineering practices.
이러한 더 깊은 의미를 밝혀내는 열쇠는 스스로에게 이렇게 묻는 것이다. "이러한 측정을 생성했던 행동을 발생시킨 모델은 무엇인가?" The key to uncovering these deeper meanings is to ask yourself, "What are the models that generated the behavior that produced those measurements?"
램프 차트는 단순히 기준선에 대한 선이 고정된 슬립차트일 뿐이다. 이 차트는 어떤 조직이 압력을 받아 발표하는 일정을 무시한다는 것을 드러낼 수 있다. A ramp chart is simply a slip chart with lines to the baseline filled in. This chart may reveal that an organization ignores the schedules it announces under pressure.
Chapter 6: 관찰로부터 의미를 만들 때 자주 하는 실수들 (Pitfalls When Making Meaning from Observations)
Summary
SatirModel은, 자료를 받은 후, 내 내적 단계는 내가 취한 것을 해석하는 것이라고 말한다. 나는 나의 과거 경험에 따라 해석하는데, 그것은 같은 관찰에 대해 다른 해석을 할 수도 있다. The Satir Model says that after receiving data, my next internal step is to interpret what I have taken in. I interpret according to my past experience, which may be different from the past experience of others, so we may have different interpretations of the same observation.
두 가지 이상의 해석이 가능하다는 것을 항상 명심해야 한다. 만약 당신이 받은 것에 대해 적어도 세 가지의 다른 해석을 생각할 수 없다면, 당신은 그것이 무엇을 의미할지에 대해 충분히 생각하지 못했다. It's always important to remember that more than one interpretation is possible. If you can't think of at least three different interpretations of what you received, you haven't thought enough about what it might mean.
해석은 관찰이 아니다. 차이점을 명확히 하기 위해, 우리는 데이터 질문을 한다: "무엇을 보거나 들어서 그러한 결론을 내리게 되었나요?" Interpretation is not observation. To keep the difference clear, we ask the Data Question: "What did you see or hear that led you to that conclusion?"
해석하기 위한 다소 체계적인 과정은 다음과 같다: Here is a somewhat systematic process for making interpretations:
데이터를 받아들인다. 데이터 질문을 사용하라. Take in data. Use the Data Question.
의미에 대한 가설을 세운다. Form hypotheses about meaning.
가설을 하나로 줄인다. 가장 가능성이 높은 것을 골라라. Reduce hypotheses to one. Choose the most likely.
그것이 중요한지 판단해라. Decide if it's important.
그에 대해 무엇인가 행한다. 가설을 무효화할 수 있는 검정을 수행하라. Do something about it. Perform a test that could invalidate the hypothesis.
가설이 무효화되었는지 확인하기 위해 데이터를 취한다. 그렇다면 1단계, 2단계 또는 3단계로 돌아가라. Take in data to see if the hypothesis is invalidated. If it is, return to step 1, or 2, or 3.
값비싼 측정 프로그램을 시작하기 전에 시도할 수 있는 싸고 쉬운 방법들이 많이 있다. 갇낳나 것부터 시작해서 해석 과정을 적용하라. There are many cheap and easy measures you can try before embarking on an expensive measurement program. Start with something simple and apply the interpretation process.
메타 관찰은 관찰에 관한 관찰이며, 종종 관찰 자체보다 더 많은 것을 우리에게 말해준다. 원하는 데이터를 얻을 수 없더라도 조직에서 데이터를 얻고 보관하는 문제에 대한 데이터를 항상 얻는다. Meta-observations are observations about observations, and often tell us more than the observations themselves. Even if you can't get the data you want, you always get data about the problems of getting and keeping data in an organization.
가설을 무효화하려는 시도는 다음과 같은 함정으로 인해 중요하다: The attempt to invalidate hypotheses is important because of the following pitfalls:
검증이 없으면 보이는 것과 다를 수 있다. Something may not be what it seems, if there is no verification.
데이터는 무의식적으로 선택되었을 수 있다. Data may have been unconsciously selected.
데이터는 의식적으로 선택되었을 수 있다. Data may have been consciously selected.
오해로 인해 측정이 잘못될 수 있다. Measurements may be wrong because of misunderstanding.
변조로 인해 측정이 잘못될 수 있다. Measurements may be wrong because of falsification.
Chapter 7: 품질에 대한 직접적인 관찰 (Direct Observation of Quality)
Summary
품질 좋은 소프트웨어를 생산하기 위해서는 이걸 알아야 한다: "이 제품의 품질은 무엇인가, 지금 당장?" 이 질문에 답하는 데는 두 가지 다른 접근법이 있다 - 즉, 직접 접근법과 간접 접근법이다. To produce quality software you need to know: "What is the quality of this product, right now?" There are two different approaches to answering this question—the direct approach and the indirect approach.
많은 사람들에게, "품질"은 누구도 반대할 수 없을 정도로 모호한 용어다. 궁극적으로, 모든 사람은 품질에 대한 동일한 정의를 가지고 있으며, 이와 같은 것이 된다: "품질이란 내가 좋아하는 것은 어떤 것이든지" For many people, "quality" is such an ambiguous term that nobody could be against it. Ultimately, everyone has the same definition of quality, and it goes something like this: "Quality is whatever I like."
품질은 상대적이다. 어떤 사람에게는 품질이 가치 있는 것이다. 가치란 자신의 요구 사항을 충족시키기 위해 기꺼이 돈을 지불하는 것이다. 한가지 올바른 방법을 찾는 것이 가장 강력한 욕구를 가진 완벽주의자들은 품질에 대한 이 상대적인 정의에 만족하지 못할 것이다. 하지만, 그렇다면 완벽주의자들은 어떤 것에도 만족하지 않을테니, 그것들을 잊어라. Quality is relative. Quality is value to some person. Value is what are people willing to pay to have their requirements met. Perfectionists whose strongest desire is to find the one right way will not be satisfied with this relative definition of quality. But, then, perfectionists won't be satisfied with anything, so forget them.
오늘날 소프트웨어 조직은 품질 문제로 과부화되어 더 이상 소프트웨어 개발 사업에 효과적으로 대처하지 못하고 있다. 그러나 많은 관리자들은 이 과부하와 품질 문제 사이의 관계를 인식하지 못한다. Many software organizations today are so overloaded with quality problems that they are no longer coping effectively with their business of developing software. Yet many managers fail to recognize the relationship between this overload and quality problems.
관리자들은 또한 그들 자신의 행동과 그들이 얻고 있는 결과 사이의 관계를 인식하지 못한다. Managers also fail to recognize the relationship between their own actions and the results they're getting.
모든 소프트웨어 문제는 품질 문제다. 품질의 0번째 법칙에 따르면, 만약 당신이 품질에 관심이 없다면, 당신은 다른 어떤 요구조건도 충족시킬 수 있다. 품질을 조절할 필요가 없다면 다른 어떤 것도 조절할 수 있다. Every software problem is a quality problem. The Zeroth Law of Quality says, If you don't care about quality then you can meet any other requirement. If you don't have to control quality, you can control anything else.
품질은 우리가 찾을 수 있는 가장 직접적인 소프트웨어 측정 방법이며, 품질을 측정하는 유일한 직접적인 방법은 아이디어가 중요한 사람들과 함께 하는 것이다. 궁극적인 정치적 질문은, 그러므로, 누가 품질의 정의를 통제할 수 있는가이다. Quality is the most direct software measure we can find, and the only direct way to measure quality is with the people whose ideas count. The ultimate political question is, therefore, Who gets to control the definition of quality?
권력은 부패한다. 그리고 구너력이 가장 철저하게 부패하는 것은 관찰의 의미를 부여하는 능력이다. 소프트웨어 개발자들이 품질의 정의를 통제할 때, 그들은 단기적으로는 잘 할 수 있지만, 궁극적으로 고객들을 그들이 찾을 수 있는 첫 번째 경쟁자로 몰아갈 것이다. Power corrupts. And what power corrupts most thoroughly is the ability to make meaning of observations. When software developers control the definition of quality, they may do well in the short run, but they will ultimately drive their customers to the first competitor they can find.
오차의 부재의 측정은 품질의 직접 측정과 같지 않다. 진정한 품질 향상은 항상 고객이 원하는 것을 아는 것에서 시작된다. 그것은 품질을 직접적으로 측정하는 유일한 방법이다. The measurement of the absence of errors is not the same as direct measurement of quality. Real quality improvement always starts with knowing what your customers want. That's the only direct measure of quality.
Chapter 8: 비용과 가치 측정하기 (Measuring Cost and Value)
Summary
품질을 향상시키는 동기는 항상 품질의 가치에 대한 연구로 시작하지만, 많은 관리자들이 비용과 가치를 혼동하는 것 같다. The motivation for improving quality always starts with a study of the value of quality, but many managers seem to confuse cost and value.
그 존재를 정당화하라는 압력을 받았을 때, 조직은 비용측면을 강조할지 가치측면을 강조할지를 결정해야 한다. 비용 관찰에서 가치 관찰로의 전환은 조직이 패턴2에서 패턴3으로 전환했음을 보여주는 가장 강력한 지표다. When under pressure to justify its existence, an organization has to decide whether to emphasize the cost side or the value side. The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 to Pattern 3.
"노력은 계산된 것으로 이동한다." 비용 계산은 비용 절감으로 이어진다. 값 계산은 가치 향상으로 이어진다. 비용 절감은 연간 예산에 의해 제한된다. 가치 향상은 무제한이다. "Effort moves to what is counted." Cost counting leads to cost reduction. Value counting leads to value enhancement. Cost reduction is limited by the annual budget. Value enhancement is unlimited.
누군가가 "소프트웨어의 가격이 너무 바씨다"고 말할 때, 그것은 항상 "소프트웨어는 (나에게) 충분한 가치가 없다"는 의미의 암호화된 메시지라고 할 수 있다. 가치는 항상 인식된 가치이기 때문에 우리는 누가 인지하고 있는지 알아야 한다. When someone says, "Software costs too much," it's always a coded message meaning, "Software isn't worth enough (to me)." Value is always perceived value, so we must know who is doing the perceiving.
소프트웨어 프로젝트가 간단히 무너질 때, 품질 질문은 대답하기 쉽다. 품질은 0이다. 모든 품질 붕괴의 밑바탕은 소프트웨어에서 우리가 이전에 인간이 시도했던 것보다 더 높은 정밀도를 통해 품질을 달성하려고 시도하고 있다는 단순한 사실이다. When a software project simply collapses, the quality question is easy to answer—quality is zero. Underlying all quality collapses is the simple fact that in software we are attempting to achieve quality through precision higher than human beings have ever attempted before.
소프트웨어는 젊고 성숙된 사업이다. 초기 시스템에서 품질을 생산하기 위해 수용할 수 있는 프로세스였던 것이 그것의 더 크고 더 복잡한 후계자에서는 받아들일 수 없게 된다. 따라서 소프트웨어 가치가 붕괴되지 않을 때도 소멸한다. Software is a young, maturing business. What was an acceptable process for producing quality in the earlier system becomes unacceptable in its larger, more complex successors. Thus, even when software value doesn't collapse, it decays.
열역학 제2법칙에는 품질을 얻기 위해서는 대가를 치워야 하며, 원하는 품질이 높을수록 더 많은 대가를 치뤄야 한다고 되어 있다. 인간 본성의 제1법칙은 아무도 열역할 제2법칙이 그들에게 적용된다고 믿고 싶어하지 않는다고 말한다. The Second Law of Thermodynamics says that you have to pay to get quality, and the higher quality you want, the more you have to pay. The First Law of Human Nature says that nobody wants to believe the Second Law of Thermodynamics applies to them.
품질에 대한 투자는 돈과 노력 이상의 것이어야 한다. 지속적으로 품질을 생산하기 위해, 관리자들은 새로운 사고방식을 배워야 한다. The investment in quality must be more than money and hard work. To produce quality consistently, managers must learn new ways of thinking.
시스템 사고방식은 품질을 생산하기 위해서는 요구사항이 변화할 때, 또는 요구사항의 이해도가 변화할 때 그 요구사항을 감시해야 한다고 말한다. 그러면 우리는 필요한 것과 생산되는 것 사이의 편차에 기초하여 프로세스에서 조정을 해야 한다. 그것은 관리자의 일이다. Systems thinking tells us that to produce quality, we must monitor requirements as they change, or as our understanding of them changes. Then we must make adjustments in the process on the basis of deviations between what is required and what is produced. That's the manager's job.
2차 요건을 통한 품질 측정은 간접적인 측정으로, 측정과 품질을 연관시키기 위해서는 추가 단계가 필요하며, 그 추가 단계가 잘못될 수 있기 때문이다. 잘못 해석될 가능성이 있다는 것은 관찰을 간접적으로 할수록 세심하게 관리해야 한다는 것을 의미한다. Measurement of quality through secondary requirements is indirect measurement, because it requires an extra step to relate the measurements to quality, and that extra step could go wrong. The possibility of misinterpretation means that the more indirect the observation, the more carefully it must be managed.
표준에 대한 불만은 표준에 부합해야 하는 사람이 표준과 표준의 가치 사이에 인과 관계를 맺지 못할 때 발생한다. 세부적인 영향 사례 방법과 단일 최대 유익성 방법을 통해 우리는 이러한 연결을 만들어 품질을 측정할 수 있다. Discontent over standards arises when people who must conform to the standards cannot make the cause-effect connection between the standard and the value of the standard. The detailed impact case method and the single greatest benefit method allow us to make this connection and thus measure quality.
상세 영향 사례 방법은 변화의 가치 영향에 대한 철저한 연구다. 그것은 효과 다이어그램을 통해 요구사항을 추적하는 아이디어에 기초한다. The detailed impact case method is an exhaustive study of the value impacts of a change. It is based on the idea of tracing requirements through a diagram of effects.
가장 큰 편익 방법은 추정 방법의 비용과 시간을 실제 수준으로 낮추면서 바닥 추정치를 가치에 넣는 한 가지 접근법이다. 가장 큰 단일 유익성 방법의 기본 질문은 "이 변화에 귀속시킬 수 있는 가장 큰 유익성은 무엇인가?"이다. The single greatest benefit method is one approach to putting a floor estimate on value, while keeping the cost and time of the estimating method down to practical levels. The basic question of the greatest single benefit method is "What is the one greatest benefit that you can attribute to this change?"
Chapter 9: 메타 측정 (Meta-Measurement)
Summary
메타 측정은 측정 시스템의 측정이다. 메타 측정은 제어 시스템 고장에서는 측정 시스템이 가장 먼저 분해되는 것 중 하나이기 때문에 중요하다. Meta-measurement is the measurement of the measurement system. Meta-measurement is important because in control system failures, the measurement system is one of the first things to break down.
인식 부족은 제어 시스템 고장을 관찰하는 가장 확실한 방법이다. 품질 위기 동안, 아무도 그들에게 실제로 무슨 일이 일어나고 있는지 모른다. Lack of awareness is the surest way to observe a control system failure. During a quality crisis, nobody knows what's really happening to them.
품질 위기의 소프트웨어 조직은 그 문제의 특수성은 말할 것도 없고, 얼마나 많은 문제를 겪고 있는지에 대한 정확한 정보를 산출할 수 없다. Software organizations in quality crises cannot produce accurate information about how many problems they are experiencing, let alone the specific nature of those problems.
품질 위기의 또 다른 신뢰할 수 있는 메타 측정 증상은 프로젝트 관리 보고서를 갱신하지 않는 것이다. Another reliable meta-measurement symptom of a quality crisis is failure to update the project management reports.
스펙(명세)과 같은 필수 아이템을 무시할 수 없을 때는 단순히 잊어버리는 경우가 많다. 따라서, 당신은 사람들에게 스펙과 같이 그들이 해야 할 일에 필요한 것들을 찾도록 한 다음, 그것들이 어디에 있는지 또는 그것들이 존재하는지 기억하는데 얼마나 오래 걸리는지 관찰함으로써 꽤 쉽게 품질 문제의 수준을 진단할 수 있다. When essential work items such as specifications can't be ignored, they are often simply forgotten. Thus, you can diagnose the level of quality problems quite easily by asking people to find things that they need to do their work—like the specifications—then observing how long it takes to remember where they are, or if they even exist.
우리의 지적 통제 시스템이 무너지고 있을 때, 우리가 찾고 있는 것에 대한 정확한 설명이나 이름조차 줄 수 없다. 그러한 부정확한 언어는 지적 통제의 상실을 말해주는 신호다. When our intellectual control system is breaking down, we cannot even give you an accurate description or name of what we are looking for. Such imprecise language is a tell-tale sign of loss of intellectual control.
위기에 처했을 때 상황을 단순화하는 것이 이치에 맞는다. 우리가 이것을 하는 한 가지 방법은 어려운 사실을 무시하는 것이다. 우리는 문제가 발생하는대로 처리하지 않고, 다른 사람이 문제를 처리할 수 있도록 기록하지 못하며, 최악의 경우 의도적으로 문제를 기록하지 못한다. When we're in crisis, it makes sense to simplify the situation. One way we do this is by trying to ignore difficult facts. We don't handle problems as they arise, we fail to record problems so that others can handle them, and in the worst case, we intentionally fail to record problems.
성공적인 제어 시스템은 제어되는 시스템의 동작에 대한 정보 뿐만 아니라 그 성능을 측정하기 위해 어떤 표준을 사용하는지에 대한 외부 정보도 가지고 있어야 한다. 따라서 외부 성능 표준에 대한 지식 부족은 우리가 품질 문제에 처해 있다는 확실한 신호다. A successful control system must not only have information on the behavior of the system being controlled, but also external information about what standards are to be used for measuring that performance. Lack of knowledge of external standards of performance is thus a sure sign we're in quality trouble.
문제가 있는 조직은 전반적인 성과에 대한 표준을 가지고 있지 않지만, 적어도 현재의 작품, 즉 사양에 대한 표준을 가지고 있어야 한다. 우리 조직이 심각한 품질 문제를 겪고 있을 때 규격을 포기하는 것은 유혹적인 "해결책"이다. The troubled organization doesn't have standards of overall performance, but at least it should have standards for the present piece of work—in other words, specifications. Letting go of specifications is a tempting "solution" when our organization is experiencing serious quality problems.
서면 명세서는 명세서를 충족시키는 척하려는 조직에 위험하기 때문에, 문서화되지 않은 구두계약에 대한 많은 언급을 듣게 된다. Written specifications are a danger to the organization that's trying to pretend that they're meeting specifications, so you hear many references to undocumented verbal agreements.
우리 조직이 문제에 잠겼을 때도 한 발짝 물러서서 우리 자신을 살펴서 그들이 올바른 일에 그들의 창조성을 적용할 수 있게 한다면 그것은 회복될 수 있다. Even when our organization is submerged in problems, it can recover if we are able to step back and get a look at ourselves so they can apply their creativity to the right things.
때때로 우리는 우리가 무슨 일이 일어나고 있는지 파악하고 있다고 믿지만, 실제로 확인하기에는 너무 과부화되어 있다. 우리가 결국 틀렸다는 것이 밝혀졌을 때 우리의 지나친 자신감은 훨씬 더 큰 문제를 일으킬 수 있다. 우리의 인상적인 많은 "측정"들은 사실 우리의 의사소통 패턴을 제대로 파악하지 못하게 하는 연기 스크린이다. Sometimes we believe we have a grip on what's happening, but are too overloaded to actually check. Our overconfidence can cause even more trouble when we're eventually proved wrong. Many of our impressive "measurements" are actually a smoke screen that keeps us from getting a true picture of our communication patterns.
다른 연기 스크린은 의사-리뷰다. 우리의 기술적 검토가 의사-검토가 되었다는 어떤 징후도 적색 깃발을 불러올 것이다. Other smoke screens are pseudo-reviews. Any indication that our technical reviews have become pseudo-reviews should raise a red flag.
상황이 충분히 나빠지면, 우리는 상황을 통제할 수 있도록 돕기 위해 통신선을 끊기 시작한다. 그러나 이 절단은 결국 모든 선이 절단되는 자기 보강 피드백 역동성을 만들어냄으로써 상황을 악화시킨다. 일부 통신회선이 폐쇄되기 시작하면 개방된 상태로 남아있는 통신회선은 품질이 저하될 수 있다. When things grow bad enough, we start cutting communication lines to help us keep things within our control. This cutting, however, worsens the situation by creating a self-reinforcing feedback dynamic in which all lines are eventually cut. When some communication lines start to shut down, those lines that do remain open may deteriorate in quality.
우리의 의사소통 채널은 우리가 서로 문제에 대해 직접적으로 이야기하지 않거나 할 수 없을 때 악화되지만 침묵하거나 험담하거나 소문을 퍼뜨리거나 간접적으로 행동한다. Our communication channels deteriorate when we don't or can't talk directly to one another about problems, but remain silent, gossip, pass rumors, or act indirectly.
중복작업은 품질위기의 전형이다. 우리는 종종 치수를 복제하거나, 치수를 더 좋게 보이려고 하거나, 우리 자신의 기분을 좋게 하기 위해 치수를 목제한다. Duplicated work is typical of the quality crisis. We often duplicate measurements, to try to make them look better, or to make ourselves feel better.
점점 더 많은 회의들이 점점 더 적게 성취한다. 무엇이든 알아낼 수 있는 유일한 방법이 회의에 참석하는 것이라고 느낄 때 회의는 더 커지기 때문에, 우리는 그 상황에서 우리가 할 수 있는 최선의 일을 하기 위해 노력해야 한다. More and more meetings accomplish less and less. Meetings grow larger when we feel that the only way to find out anything is to be at a meeting, so we have to go in an attempt to do the best job we can, under the circumstances.
우리는 종종 동료들로부터 자신을 고립시킴으로써 과부하를 줄이려고 노력한다. 고립이 육체적이든 감정적이든, 우리는 실제로 우리의 가장 큰 원조를 제거함으로써 좋은 일을 할 수 있는 능력을 해친다. We often try to reduce our overload by isolating ourselves from our co-workers. Whether the isolation is physical or emotional, we actually hurt our ability to do a good job by removing our greatest source of assistance.
사태가 정말 나빠지면, 우리는 위기가 얼마나 나쁜지 더 잘 알게 할 수 있는 정보의 출처로부터 우리 자신을 차단할 수도 있따. 어떤 새로운 정보에 대한 즉각적인 반응은 그것을 부인하는 것이다. "사실화된 사실이 없다"고 말한다. 그리고, 종종, 어떤 사실들도 만들어낼 수 없다. If things become really bad, we may cut ourselves off from any source of information that might make us more aware of how bad the crisis really is. The instant reaction to any new piece of information is to deny it, saying there are no substantiating facts. And, frequently, no facts can be produced.
우리 모두는 기꺼이 나쁜 소식을 전달하는 시스템의 일부가 되기 전에 두 번 생각한다. 우리가 유용한 측정값을 산출할 수 있는 정보시스템을 구축하거나 유지하지 않을 때, 우리는 측정 없이 관리하려고 노력해야 하고, 그 결과 위기의 불씨를 부채질해야 한다. All of us think twice before we willingly become part of the system for delivering bad news. When we don't build or maintain information systems that could produce useful measurements, we then have to try to manage without measurements—and as a result fan the flames of crisis.
QSM: Volume 2.2: Responding to Significant Software Events
Contents
Part III. 중요성 (Significance)
Chapter 1: 감정적인 중요성을 측정하기 (Measuring Emotional Significance)
Summary
관찰의 세 번째 단계는 의미를 발견하는 것이다 - 즉, 현실 세계의 복잡성을 우리의 뇌가 다룰 수 있는 크기로 줄일 수 있는 필터를 제공하는 것이다. The third step in observation is discovering significance—providing a filter to reduce the complexity of the real world to a size our brain can handle.
인간은 우리가 받아들이는 데이터에 귀속되는 의미에 대해 어떤 감정적인 반응을 함으로써 반응한다. 그것이 우리가 그 의미의 의의를 아는 방법이다. Human beings respond to the meaning we ascribe to the data we take in by having some emotional reaction. That's how we know the significance of the meaning.
측정 사업에 감정이 들어오면 우리들 중 많은 이들이 길을 잃기 시작한다. 생각이나 감정은 사물을 아는 방식에 따라 다르다. 생각은 과정이지만, 느낌은 직접적이고, 궁극적이며, 아는 경향이 있다. When feelings come into the measurement business, many of us start to get lost. Thoughts and feelings differ in the way you know each thing. Thinking is a process, while feeling tends to be direct, ultimate, knowing.
비록 추리의 과정에 의해 감정이 생긴다는 것을 알지 못하지만, 생각은 감정을 불러일으킬 수 있다. 그리고 나서, 다시, 감정은 생각을 불러일으킬 수 있다. 이 두 과정은 관찰의 세계와 가장 혼란스러운 상호작용의 내부 처리를 특징으로 한다. Although we don't know we have a feeling by a process of reasoning, thoughts can give rise to feelings. And then, in turn, feelings can give rise to thoughts. These two processes characterize the internal processing of the most confusing interactions with the world of observations.
감정을 의식하고, 다른 감정과 구별하는 것은, 당신의 감정, 오직 당신의 감정만이 궁극적으로 어떤 측정의 중요성을 결정하므로, 당신의 관찰로 올바른 일을 하는데 도움을 줄 수 있다. Being aware of a feeling, and differentiating it from other feelings, can help you do the right things with your observations, because your feelings, and only your feelings, ultimately determine the significance of any measurement.
사람들이 소중하게 여긴다고 하는 것이 행동 방식과 일치하지 않을 때도 있다. 그들의 행동이 그들이 가치있다고 말하는 것의 논리적 결과와 일치하지 않을 때, 우리는 그들의 행동을 "비일치적이다"라고 부른다. 비일침적 행동은 사람들이 진정으로 소중하게 여기는 것을 위장하기 때문에 품질의 제 1의 적이다. Sometimes what people say they value doesn't match the way they behave. When their actions don't jibe with the logical consequences of what they say they value, we call their behavior "incongruent." Incongruent behavior is the number one enemy of quality, because it disguises what people truly value.
감정 - 곧 중요성 - 은 종종 미래의 결과의 이미지에 의해 결정된다. 래칫 라인은 만료일로, 만약 놓치면 회복 불가능한 비용이 발생한다. 습관적으로, 래칫 라인을 넘는 것은 지지되는 가치와 행동 사이의 불일치를 보여주는 명백한 예다. Feelings—and thus significance—are often determined by the image of consequences in the future. A ratchet line is a due date that, if missed, will incur non-recoverable costs. Habitually crossing ratchet lines is a clear example of incongruence between espoused values and behavior.
또 다른 강력한 미래 이미지는 만료일을 놓치고 무언가 가치 있는 것을 창조할 기회를 놓치는 이미지다. 우리는 그러한 날짜를 "기회의 라인"이라고 무른다. Another strong future image is the image of missing a due date and losing a chance to create something of value. We call such a date an "opportunity line."
비일치적인 조직이 기회 라인에 접근할 때, 슬립은 "생각할 수 없는" 것이 된다. 정서적 압박감 속에서 사람들은 말 그대로 생각을 멈춘다. When an incongruent organization approaches an opportunity line, a slip become "unthinkable." Under the emotional pressure, the people literally stop thinking.
주관적 영향 방식은 고객에게 중요한 것이 무엇인가라는 질문에 답하는 과정이다. 품질은 객관적으로 측정할 수 있는 것이라는 모든 가식을 포기함으로써 성공한다. The subjective impact method is a process of answering the question of what is significant to the customers. It succeeds by giving up all pretense that quality is something that can be measured objectively.
주관적 영향 방식은 청중들이 새로운 것을 평가하는 기준을 사용한다. 그것은 청중들로부터 중요한 질문들이 무엇인지, 그리고 누가 믿을 수 있는 대답을 가지고 있는지를 알아내므로, 당신은 올바른 질문으로 적합한 사람들을 인터뷰할 수 있다. The subjective impact method uses that audience's criteria for evaluating something new. It finds out from your audience what the significant questions are, and also who has believable answers, so you can interview the right people with the right questions.
Chapter 2: 실제로 일어나기 전에 실패를 측정하기 (Measuring Failures Before They Happen)
Summary
대부분의 조직들이 어느 정도 자기성찰에 착수하는 방아쇠는 실패다. 컴퓨터 사용의 모든 골치 아픈 측면들 중에서, 실패는 대부분의 사람들에게 단연코 가장 짜증나는 것이다. 우리가 실패의 비용을 신중하게 측정했을 때, 우리는 일반적으로 더 신뢰할 수 있는 소프트웨어를 생산함으로써 큰 가치를 더할 수 있다는 것을 발견한다. The trigger for most organizations to embark on some self-examination is failure. Of all the troublesome aspects of using computers, failures are by far the most annoying to the most people. When we measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software.
소프트웨어 고장으로 막대한 손실이 발생한 경우를 많이 인용할 수 있다. 이러한 거대한 손실의 대부분은 보편적인 패턴을 따른다. 일반적인 소프트웨어 엔지니어링 안전장치 없이 운영체제로 신속하게 "다양한" 변경이 이루어진다. 그 변화는 정상적인 운영에 직접 투입된다. 작은 실패는 많은 용도에 곱하여 큰 결과를 낳는다. Many cases can be cited where huge losses resulted from software failures. Most of these huge losses follow a universal pattern. A quick, "trivial" change is made to an operational system, without any of the usual software engineering safeguards. The change is put directly into the normal operations. A small failure is multiplied by many uses, producing a large consequence.
그러한 실패에 대한 경영진의 반응도 패턴을 따른다. 먼저 손실을 줄인 다음 프로그래머를 해고하고, 감독자를 프로그래머로 강등시키고, 지배인을 직원 자리에 앉히고, 상급 관리자들을 손대지 않게 한다. Management reaction to such a failure also follows a pattern. First play down the loss, then fire the programmer, demote the supervisor to programmer, put the manager in a staff position, and leave higher managers untouched.
실패 예방의 제1규칙, "관찰할만한 가치가 없는 것은 없다." 누군가가 어떤 것이 너무 작아서 관찰할 가치가 없다는 생각을 표현하는 것을 들을 때, 항상 살펴봐라. The First Rule of Failure Prevention says, "Nothing is too small to be worth observing." When you hear someone express the idea that something is too small to be worth observing, always take a look.
제2차 실패 방지 규칙인, 제1차 재무관리 원칙은, "X달러의 손실은 항상 재정적 책임이 X달러를 초과하는 임원의 책임"이라고 말한다. 그러므로 소프트웨어 장애에 대한 통제에 대한 책임은 조직의 최고 수준에 있다. The First Principle of Financial Management, which is also the Second Rule of Failure Prevention says, "A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars." Thus, the responsibility for controls on software failures rests at the highest levels of the organization.
실패를 관찰할 때는 생각보다 훨씬 늦는다. 실패를 예방하는 방법을 찾는 것이 더 좋지만, 우리 자신의 실패는 우리가 보기 가장 어렵다. 다른 사람의 실패를 통해 배우도록 해라. By the time you observe failures, it's much later than you think. Better to find ways of preventing failures, but our own failures are hardest for us to see. Try learning from the failures of others.
실패는 연약함, 어리석음, 뚱뚱함, 재미, 사기, 광신, (하드웨어의) 실패, 그리고 운명, 이렇게 8F에서 올 수 있다. Failures may come from the following eight F's: frailty, folly, fatuousness, fun, fraud, fanaticism, failure (of hardware), and fate.
실수에 대한 직접적인 관찰은 의미가 없지만, 사람들이 실수에 어떻게 대비하는가에 대한 메타관찰은 의미가 있다. 실패 예방을 위한 절차를 설계하고, 자연의 사실을 인정하고, 절차가 진행되는 것을 보는 것이 관리직이다. The direct observation of a mistake has no significance, but the meta-observation of how people prepare for mistakes does. It's a management job is to design procedures for failure prevention, acknowledging facts of nature and seeing that the procedures are carried out.
실수하지 말라고 애원하거나 협박했다가 나무라는 것은 패턴1과 패턴2 조직의 특징이다. 작동하지 않는다. Imploring or threatening people not to make mistakes, then blaming them if they do, is characteristic of Pattern 1 and Pattern 2 organizations. It doesn't work.
교육, 멘토링, 기술검토 프로그램을 구축하고 지원하는 것이 관리자의 일이다. 만약 이것이 실행되지 않거나 효과적으로 수행되지 않는다면, 당신은 실패의 관리에 대해 상당한 메타관찰을 갖게 될 것이다. It's management's job to establish and support training, mentoring, and technical review programs. If these aren't done, or aren't done effectively, then you have a significant meta-observation about the management of failure.
관리자는 자신이 고용하고 보유하는 사람에 대해서도 책임을 진다. 뚱뚱한 직원을 식별하고 그것에 대해 아무것도 하지 않는 관리자들은 이중으로 뚱뚱하다. Managers are also responsible for whom they hire, and retain. Managers who identify a fatuous employee and don't do anything about it are doubly fatuous.
사람들이 시스템을 가지고 재미를 느끼는 방법의 목록은 끝이 없고 예측할 수 없다. 그래서 재미는 실패의 모든 원천 중에서 가장 위험한 것이다. 단 두 가지 예방책이 있다: 개방적이고 눈에 보이는 시스템과 그 자체로 충분히 재미있는 일. The list of ways people have fun with a system is endless and unpredictable, which is why fun is the most dangerous of all sources of failure. There are only two preventives: open, visible systems and work that is sufficiently fun in and of itself.
사기나 광신도의 위협은 관리자가 체계적인 기술적 검토와 기타 실패 예방 활동을 도입하도록 동기를 부여할 수 있다. The threat of fraud or fanaticism can motivate managers to introduce systematic technical reviews and other failure prevention activities.
하드웨어 고장은 발생하지만, 하드웨어 고장의 원인을 자신의 문제로 돌리는 관리자들은 자신의 관리 능력에 대해 중요한 것을 말하고 있다. Hardware failures happen, but managers who blame hardware failures for their problems are telling you something important about their management ability.
나쁜 관리자는 불운을 믿는다. 관리자가 "불운"에 대해 말하는 것을 들으면, 관리자라는 단어를 "운"으로 대체한다. Bad managers believe in bad luck. When you hear a manager talking about "bad luck," substitute the word "manager" for "luck."
Chapter 3: 정확하게 듣기 (Precision Listening)
Summary
사람들은 자신이 말하는 것을 들을 수 없어서 자신의 부정확한 추리에 귀를 기울일 수 없기 때문에 어리석은 짓을 한다. 정확하게 경청하는 법을 배우면 조직 문화의 평균적인 어리석음을 관찰할 수 있다. People do foolish things because they can't hear themselves talking, so they can't listen to their own imprecise reasoning. By learning to listen with precision, you can observe the average foolishness of an organization's culture.
인과응보의 왜곡은 한 가지가 다른 것을 발생시킨다고 거짓으로 주장한다. 한 가지 형태의 인과 왜곡은 단순한 선형적 사고, 즉 한 가지 원안/한 가지 효과, 그 반대다. "존슨은 이 프로젝트를 늦게 만들었다." A cause-effect distortion falsely claims that one thing makes another happen. One form of cause-effect distortion is simple linear thinking—one cause/one effect, and vice versa. It often takes the form of blaming, as in, "Johnson made this project late."
또 다른 형태의 인과 왜곡은 "존슨이 망치지 않았더라면 우리가 그 일자리를 얻었을텐데"에서처럼 종종 비난의 형태로 왜 그 일이 일어나지 않았는지에 대한 추측이다. Another form of cause-effect distortion is a speculation about why things didn't happen, again, often in the form of blaming, as in, "We would have gotten the job if Johnson hadn't messed up."
전능한 가정에 따르면, 나는 단순히 내가 믿거나 믿지 않는 것에 의해서 다른 사람에게 일이 일어나게 할 힘을 가지고 있다. 아무도 다른 사람에게 어떤 것을 느끼게 할 수 없다. 당신이 사람들에게 어떤 감정을 느끼게 할 수 있다고 믿기 시작할 때, 당신은 명확하게 생각하지 않는다. 당신이 다른 사람들이 당신을 어떤 식으로 느끼게 할 수 있다고 믿기 시작할 때, 당신은 훨씬 더 혼란스러워진다. According to the omnipotence assumption, I have the power, simply by what I believe or don't believe, to make things happen to other people. Nobody can make anybody else feel anything. When you start to believe you can make people feel a certain way, you're not thinking clearly. When you start to believe other people can make you feel a certain way, you're even more muddled.
데이터 질문 - "무엇을 보거나 들은 것이 당신을 그 믿음으로 이끌었는가?" - 전능적 가정, 마음을 읽는 가정 및 기타 인과관계 왜곡을 해소하는 효과적인 방법이다. The Data Question—"What did you see or hear that led you to that belief?"—is an effective way clear up the omnipotence assumption, the mind-reading assumption, and other cause-and-effect distortions.
일반화는 소수의 관찰된 사례에서 다수의 관찰되지 않은 사례로 이성을 부여한다. 일반화는 필수적이지만, 종종 너무 지나치다. 보통, 그러한 과잉 일반화는 "전부", "모든", "모두", "항상", "절대로", "아무도", 또는 "아무것도"와 같은 보편적인 양자들에 의해 언어로 표현된다. Generalizations reason from a few observed cases to a large number of unobserved cases. Generalizations are essential, but are often carried too far. Usually, such over-generalizations are represented in speech by universal quantifiers, such as "all," "every," "everybody," "always," "never," "nobody," or "none."
일반화를 취소하기 위한 첫 번째 단계는 내포된 일반화를 세부사항으로 대체하는 것이다. 다음 단계는 데이터 질문을 적용하는 것이다. The first step for undoing generalizations is to replace the implied generalizations with specifics. The next step is to apply the Data Question.
또 다른 왜곡 범주는 "반드시", "필수", "해야 한다"의 사용에서와 같이 일반화와 인과관계를 결합한다. 이러한 일반화의 진실이나 거짓을 발견하는 방법은 끊임없이 "왜?"를 묻고 데이터 질문을 적용하는 것이다. Another distortion category combines generalization with cause and effect, as in the use of "must," "should," "have to," or "ought to." The way to discover the truth or falsity of these generalizations is to endlessly ask "Why?" and also to apply the Data Question.
가치관은 종종 허공에서 끌어낸다 - 의견 제시자가 없는 의견. 가치 평가의 숨겨진 원천을 다루는 방법은 "누구?"를 계속 물어봄으로써 그 사람에게 의견을 돌려주는 것이다. Values are often pulled out of the air—opinions without an opinionator. The way to deal with hidden sources of valuation is to bring opinions back to the person by continuing to ask, "Who?"
삭제는 말씨에서 흔히 볼 수 있고 유용한 속기이지만, 혼란스러운 사고를 초래할 수 있다. 삭제에는 다음이 포함된다. Deletions are a common and useful shorthand in speech, but can lead to confused thinking. Deletions include
명목화 (활동 집합을 하나의 보편적 명사로 구분) nominalization (converting a set of activities into a single universal noun)
참조지수 부족 (사람, 장소 또는 사물은 문장에서 제외) lack of referential index (people, places, or things are left out of a sentence)
지정되지 않은 명사 또는 동사 (특정하게 들리지만 어떤 의미라도 가질 수 있는 단어) unspecified nouns or verbs (words that sound specific but could mean anything)
구문 삭제 (누락된 문장의 삭제, 바로가기) syntactic deletions (portions of sentences that are omitted, as a shortcut)
모든 삭제를 명확히 하는 방법은 당사자에게 구체적인 내용을 요구하는 것이다. The way to clarify all deletions is to ask the person to get specific.
모든 실패가 고객의 눈에 같은 (부정적인) 가치를 갖는 것은 아니다. 더구나 같은 실패는 눈마다 다른 가치관을 가질 수 있다. 사람들의 말을 주의 깊게 듣는 것은 그들이 잠재적 실패에 어떤 중요성을 부여하는지 아는데 도움이 될 것이다. 만약 그들이 낮은 의미를 갖는다면, 그들은 적절한 예방조치를 취할 것 같지 않다. Not all failures have equal (negative) value in the customer's eyes. Moreover, the same failure can have different values in different eyes. Listening carefully to people will help you know what significance they place on potential failures. If they place low significance, then they're unlikely to take proper precautions.
사람들이 잠재적 오류 (예상 비용, 실패에 부수되는 개인적 중요성, 실패 확률과 그 결과에 대한 주관적 평가, 그리고 개인적 통제의식)를 방지하기 위해 조치를 취하는지 여부를 결정하는 몇 가지 요인은 있다. Several factors determine whether people take action to prevent a potential error—expected cost , the personal significance attached to failure, subjective evaluation of the probability of a failure and its consequences, and the sense of personal control.
귀 기울이는 법을 배우면 사람들이 시스템, 조직, 마술, 작품의 특정 부분을 건너뛰는 이유 등 수십 가지 방법으로 위기를 예측하는 소리를 들을 수 있다. 아마도 무엇보다도, 당신은 실제적인 불안감을 감추려는 시도의 확실한 신호인 잘못된 낙관주의의 허세를 들을 수 있을 것이다. If you learn to listen, you can hear people predicting a crisis in dozens of ways—how they talk about the system, about the organization, about magic, and about reasons for skipping certain parts of the work. Perhaps most of all, you can listen for the bravado of false optimism, a sure sign of an attempt to cover real feelings of insecurity.
Part IV: 반응 (Response)
Chapter 4: 관찰을 행동으로 번역하기 (Translating Observation Into Action)
Summary
중요한 것은 관찰이 아니라 관찰에 대한 반응이다. 많은 모델들이 관찰과 측정에 대해 이야기한다. SatirInteractionModel은 반응이 사건과 어떻게 연결되는지 보여주는데 있어 독특하다. It's not the observation that counts, it's the response to the observation. Many models talk about observation and measurement. The Satir Interaction Model is unique in showing how responses are connected to events.
생각이 생각을 촉발시킬 수 있듯이, 생각은 감정을 촉발시킬 수 있고, 감정은 생각을 촉발시킬 수 있으며, 감정은 다른 감정을 촉발시킬 수 있다. 내 느낌은 그 순간의 내 전반적인 자기 가치관에 달려 있다. Just as thoughts can trigger thoughts, thoughts can trigger feelings, and feelings can trigger thoughts, so can feelings trigger other feelings. My feeling-about-the-feeling depends on my general sense of self-worth at that moment.
감정에 대한 강한 감정은 인생에서 일찍 획득한 어떤 생존 규칙과 관련이 있다. 대부분 작은 관찰 하나하나가 내 생존을 위협한다고 느끼지 않는다. 만약 내가 한다면, 이건 당신이 나에 대해 말할 수 있는 중요한 메타관찰이다. Strong feelings about feelings are related to some survival rule acquired early in life. Most of the time, I don't feel that my survival is threatened by every little observation. If I do, then this is an important meta-observation that you can make about me.
대부분의 경우인 나의 생존이 위협받지 않을 때, 나는 논리적인 대응을 간단하게 준비하는데, 이것은 통상적으로 어떤 방어적인 대응보다 해석하기 쉽다. When my survival isn't threatened, which is most of the time, I simply prepare a logical response, which is usually easier to interpret than some defensive response.
감정을 숨기려 할 때 사용하는 방어적인 반응이 아주 많다. 나는 문제를 다른 곳에 투영하거나, 주의를 산만하게 할 수도 있다. 나는 내가 정말로 그런 감정을 가지고 있다는 것을 부정할 수도 있고, 내 관찰을 왜곡할 수도 있다. There are a great many defensive responses that I use when I attempt to hide my feelings. I may project the problem somewhere else, or create a distraction. I may deny that I really having that feeling, or distort my observations.
"생존" 반응은 사상의 부정확함을 초래하고, 사상의 부정확함은 품질을 파괴한다. 그렇기 때문에 소프트웨어 엔지니어링 관리자는 개인이나 조직 전체의 감정 상태를 측정할 수 있어야 한다. "Survival" responses lead to imprecision in thought; imprecision in thought destroys quality. That's why software engineering managers must be able to measure the emotional state of a person or of their entire organization.
우리는 어떤 사람이 다른 시간에, 다른 사람들과 다른 상황에 있는 것처럼 반응할 때 "비일치적" 대응이라고 말한다. 비일치적 반응은 문제 해결에 기여하지 않는다.방어적인 반응을 관찰함으로써 관찰 시스템이 실패하는 것을 관찰할 수 있다. We say that a response is "incongruent" when someone responds as if they were in a different situation, with different people, at a different time. Incongruent responses don't contribute to problem-solving. By watching the defensive responses, you can observe the observation system failing.
문제는 아무것도 아니다. 그 문제에 대처하는 것이 모든 것이다. The problem is nothing. The coping with the problem is everything.
사람들은 다양한 방법으로 그들의 말을 검열한다. 우리는 검열관을 이용하여 실제로 말한 것 뒤에 숨겨진 의미를 훨씬 더 많이 발견할 수 있다. 사람들은 명시적으로나 무의식적으로 은폐하고 있는지도 모른다. People censor what they say in a variety of ways. We can use the censoring to discover far more hidden meanings behind what is actually said. The people may be covering up explicitly or unconsciously.
코멘트의 규칙은 특별한 종류의 생존 규칙으로, 내 입에서 나오는 것을 지켜 "위험한" 말은 하지 않는다. A rule for commenting is a special kind of survival rule, one that guards what comes out of my mouth so I don't say anything "dangerous."
비언어적 반응은 두 부류로 나뉜다, 통제 가능한 것과 통제 불가능한 것이다. 이 두 가지를 나의 언어적 반응과 결합하면 결과가 나온다. 즉 내가 받아들이는 ㅁ것에 대한 반응으로 말하고 하는 것이다. Non-verbal responses fall into two categories, controllable and uncontrollable. Combining these two with my verbal response gives the outcome—what I say and do in response to what I take in.
상호작용 과정은 복잡하지만, 상호작용 모델의 도움으로 우리가 보고 듣는 것을 풀 수 있어, 사람들에게 실제로 일어나고 있는 일의 유용한 측정치로 바꿀 수 있다. The interaction process is complex, but with the help of the Interaction Model, we can unravel what we see and hear, transforming it into useful measurements of what's really happening with people.
스트레스에 대처할 수 있는 부조리한 방법 중 하나는 내적 반응을 내적으로 유도하고, 다시 내 자신의 수용으로 되돌아가고, 루프에 갇히게 됨으로써 생기는 "래칭"이다. One of the incongruent ways that I can cope with stress is "ratcheting," which is caused by directing my response internally, back to my own intake, and becoming locked in a loop.
Chapter 5: 동감적인 위치에서의 관찰들 (Observations from the Empathic Position)
Summary
위기상황에서 가장 효과적인 개입 중 하나는 다른 관점에서 취해진 정보를 제공하는 것이다. 관찰자 역할을 할 때마다 "self" 위치, other" 위치, "context" 위치를 선택할 수 있다. One of the most effective interventions in a crisis is to provide information taken from a different point of view. Whenever you act as observer, you have a choice of the "self" position, the "other" position, or the "context" position.
내가 비일치적일 때, 나는 한 명의 관찰자 자리에만 몸을 가두는 경향이 있다. 이것은 나를 비난하고, 달래고, 지나치게 합리적이거나, 무관한 행동으로 이끌지도 모른다. When I'm being incongruent, I tend to lock myself into one and only one observer position. This may lead me to blaming, placating, superreasonable, or irrelevant behavior.
인류학 현장학은 공감적 관찰의 원형이다. 어떤 인류학자들은 숙주 문화에 너무 몰입해서 "원래로 간다." (어떤 소프트웨어 컨설턴트도 같은 일을 한다.) Anthropological fieldwork is the archetype of empathic observation. Some anthropologists become so immersed in their host cultures that they "go native." (Some software consultants do the same thing.)
조사(survey) 위치는 사회학의 위치로서, 인류학자의 참여자 관찰 위치와 대비되는 외부 관찰자 위치다. 조사 위치는 많은 데이터를 관리 가능한 형태로 압축하지만, 중요한 세부 정보를 잃을 수 있다. The survey position is the position of sociology, an outside observer position as contrasted with the participant observation position of the anthropologist. The survey position compresses a great deal of data into manageable form, but may lose crucial detail.
숙련된 참가자 관찰자는 각 개인의 데이터에 접근하는 방법, 특히 다른 기법 중, "에믹 인터뷰"를 사용하여, 즉 상대방을 "내부화"시키는 방법을 알고 있다. The skilled participant observer knows how to access the data in each individual using, among other techniques, "emic interviewing"—a way of getting "inside" the other person.
에믹 인터뷰는 데이터 수집 이상의 것이다. 그것은 항상 정보를 주는 사람과 종종 수신자를 변화시킨다. Emic interviewing is more than data gathering. It always changes the person who gives information—and often the receiver as well.
에믹 인터뷰는 조사 데이터와 연계하여 표 뒤에 숨은 의미와 중요성을 잘 파악할 수 있다. Emic interviewing can be used nicely in conjunction with survey data to uncover the meaning and significance behind the tabulations.
숙련된 관찰자는 루머 방앗간에서, 루머 방앗간을 가동하지 못하게 하는 방법에 관한 정보를 포함하여, 유용한 정보를 추출할 수 있다. 루머 방앗간은 그들의 루머를 체크아웃으로부터 보호하는 "봉투"에 싸서 보존한다. Skilled observers can extract useful information from the rumor mill, including information about how to put the rumor mill out of operation. Rumor mills preserve themselves by enclosing their rumors in "envelopes" that protect them from being checked out.
공감하는 입장은 퍼즐링 관찰을 이해하는 강력한 도구다. 예를 들어 다음과 같은 휴리스틱을 적용할 수 있다. 누군가가 "미친척" 행동을 할 때, 공감하는 위치로 가서 미친척의 논리적인 이유를 찾아라. The empathic position is a powerful tool for understanding puzzling observations. For instance, you can apply this heuristic: When somebody is acting "crazy," go to the empathic position and find a logical reason for the craziness.
삼각 상호작용(또는 삼자 상호작용)은 상호작용과 관찰이 모두 있는 첫 번째 그룹이기 때문에 관찰에 특별한 의미를 갖는다. 상호작용에 대한 관찰은 그것이 우리가 프로세스를 개선하기 위한 피드백을 얻는 방법이기 때문에 중요하다. 조직이 패턴1 또는 패턴2에서 패턴3으로 이동함에 따라, 관리 도구들 사이에서 적절한 위치를 고려하여 상호 작용에 대한 이러한 관찰을 보기 시작한다. The triad—or three-party interaction—has special significance for observation, because it is the first grouping in which there is both interaction and observation of interaction. Observation of interaction is important because that's how we get the feedback to improve processes. As an organization moves from Pattern 1 or 2 to Pattern 3, we begin to see this observation of interaction given its proper place among the management tools.
상호작용의 관찰이 직접, 또는 정기적으로 피드백되지 않을 때, 우리는 그 조직이 "가십"에 빠져 있음을 발견할 수 있다. 공감하는 입장은 가십과 그것의 해로운 영향을 다루는데 도움을 줄 수 있다. When observation of interaction is not fed back directly, or regularly, we may find the organization enmeshed in "gossip." The empathic position can help you deal with gossip and its damaging effects.
사람들이 말하지 않는 것이 그들이 하는 말보다 더 중요한 경우가 많으며, 그 역시 공감하는 입장에서 가장 잘 이해할 수 있다. 공감하는 입장은 부조리를 발견하는데 특히 유용하다. What people don't talk about is often more important than what they do talk about, and that too can be understood best from the empathic position. The empathic position is especially useful for spotting incongruity.
공감하는 입장에서 자신도 모르게 관찰하는 사람이 많다. 그들은 그들이 정말로 다른 사람들의 감정에 공감할 때, 종종 전체 조직과 공감할 때, 뭔가를 느끼고 있다고 믿는다. 이 능력은 강력한 측정 도구를 제공할 수 있다. Many people observe from the empathic position without realizing it. They believe that they are feeling something, when they are really empathizing with the feelings of other people—often with the entire organization. This ability can provide a powerful measurement tool.
Chapter 6: 실패의 무리들을 다루기 (Dealing With Swarms of Failures)
Summary
많은 패턴2 조직들은 실패의 무리에 시달려 장기간의 상황을 개선하려는 시도는 순간의 비상사태에 의해 오락가락한다. 군집 탈출에 필요한 정보를 얻으려면 패턴2 관리자가 상황별 위치에서 관찰할 수 있는 방법이 필요하다. Many Pattern 2 organizations are so plagued with swarms of failures that attempts to improve the long-term situation are diverted by the emergencies of the moment. To get information to start escaping the swarms, Pattern 2 managers need ways to observe from the context position.
오류의 떼를 제어하는 것은 정확한 언어로부터 시작된다. 실패(증상)와 결함(질병)을 구분하는 것이 득이 된다. 실패는 "프로그램 운용의 외부 결과가 요건에서 벗어나는 것"이다. 결함은 "특정 조건에서 실행될 때 고장을 일으키는 프로그램의 결함"이다. Getting control of swarms of errors starts with precise language. It pays to distinguish between failures (the symptoms) and faults (the diseases). A failure "is the departure of the external results of program operation from requirements." A fault "is the defect in the program that, when executed under particular conditions, causes a failure."
- 보관해야 할 첫 번째 필수 통계는 시스템 문제 사고에 대한 STIs (System Trouble Incidents)라고 불리는 실패의 데이터베이스이다. 두 번째 필수 통계량은 시스템 결함 분석을 위한 SFAs(System Fault Analysis)라고 불리는 결함의 데이터베이스이다. The first essential statistic to keep is a database of failures, called STIs, for System Trouble Incidents. The second essential statistic is a database of faults, called SFAs, for System Fault Analysis.
통계에 주의해야 구별할 수 있다 We must be careful in our statistics to distinguish
원점: 우리 프로세스의 어느 단계에서 결함이 발생했는가 origin: at what stage in our process the fault originated
해결: 결함을 수리하기 위해 시스템의 어떤 부분을 변경할지 resolution: what part(s) of the system will be changed to remedy the fault
STI를 분류하기 위한 심각도 코드는 분석에서 어떤 의미를 만들어낼 수 있는 SFA에 넣는 경우에 유용할 수 있다. 또 다른 가능성은 고객에게 가치(예를 들어 돈)를 기준으로 심각도 코드를 설정하는 것이다. Severity codes for classifying the STIs can be useful if they are put in SFAs, where the analysis may create some meaning. Another possibility is to base severity codes on value (e.g., money) to the customers.
오류 처리를 감지, 위치(격리 또는 추적이라고도 함), 해결, 예방의 네 가지 활동으로 나눌 수 있다. 각자 자기만의 역동성을 가지고 있다. We can divide error-handling into four activities—detection, location (sometimes called isolation or tracing), resolution, and prevention. Each has its own dynamic.
소프트웨어 개발 조직에서의 오류 작업의 대부분은 실제로 예방 작업이지만, 사람들은 종종 오류를 예방하기 위해 대부분의 활동을 하는 것을 볼 수 있는 관점이 부족하다. Most of the error work in a software development organization is actually prevention work, though the people often lack the perspective to see that most of their activities are in place to prevent error.
어떤 조직이든 문화 패턴의 가장 민감한 척도 중 하나는 얼마나 빨리 문제를 찾아내고 제거하는가 하는 것이다. 고장 위치 파악 및 해결에는 네 가지 주요 요인이 있다: One of the most sensitive measures of the cultural pattern of any organization is how quickly it finds and removes problems. There are four major factors in the time to locate and resolve faults:
STI 순환 횟수 the number of circulating STIs
가장 쉬운 문제를 먼저 고쳐서 선택하는 것 selection by fixing the easiest problems first
고장 해결을 위한 지속적인 변경으로 유지 보수성 상실 loss of maintainability with continued changing to resolve faults
기존 고장을 해결하는 동안 새로운 결함 도입 introduction of new faults while resolving the old
효과적인 관리자들은 STI가 몇 개나 정리됐는지에는 별로 관심이 없고, 정리할 것이 얼마나 남았는지에 관심이 있다. 불행히도 프로젝트 매니저는 제품에 얼마나 많은 결함이 남아 있는지 측정할 방법이 없을 것이다. 단, 얼마ㅏ 많은 STI를 생산할지는 말할 것도 없다. Effective managers are not really interested in how many STIs have been cleared up, but how many remain to be cleared up. Unfortunately, a project manager would have no way to measure directly how many faults remain in a product, let alone how many STIs they would produce.
고장 제거의 둔화가 프로젝트 시간을 과소평가하는 주요 원인이다. STI가 많을 때는 이같은 둔화가 막바지에 이른 데서 오는 것이 아니며, 곧 완료될 것으로 예측하는 데도 사용할 수 없다. 어설픈 관리자들은 어쨌든 그것을 사용한다. The slowdown of fault removal is a major reason why project times are underestimated. When there are large numbers of STIs, this slowdown doesn't result from nearing the end, and cannot be used to predict an imminent completion. Poor managers use it anyway.
위의 네 가지 비선형 요인에 의해 속도가 느려진다. 그들의 행동이 합리적이고 경제적이 되려면 관리자들은 그들의 환상을 버리고 어떤 요소가 과정을 늦추는데 가장 중요한지를 발견해야 한다. The slowdown results from the four nonlinear factors listed above. For their actions to be sensible and economical, managers must shed their illusions and discover which factor is most important in slowing the process.
STI 순환 시간을 밝히기 위한 한 가지 핵심 측정은 STI를 수령하는 시간과 최종 해결자가 이를 수령하는 시간 사이의 시간이며, 이를 "복제 위치 시간" 또는 RLT라고 부를 수 있다. 또 다른 척도는 STI를 제거하는 평균 시간이다. One key measurement to reveal STI circulation time is the time between receipt of an STI and the time the eventual solver receives it, which we may call the "resolver location time," or RLT. Another measure is the average time to remove an STI.
측정은 네 가지 핵심 요인을 분리하는 데 도움이 될 수 있다. 순환 STI는 STI가 최종 해결사에 도달하는 데 걸리는 시간을 표로 작성함으로써 탐지할 수 있다. Measurements can help to keep the four key factors separate. Circulating STIs can be detected by tabulating the time it takes for an STI to reach its eventual solver.
가장 쉬운 문제를 먼저 고쳐서 선택하는 것은 각각의 문제를 고치는 시간을 표시한 후에 그 문제를 고치는 방법을 찾아낼 수 있다. Selection by fixing the easiest problems first can be detected by plotting the time to fix each problem, after it has been located.
과거 결함을 해결하는 동안 새로운 결함의 도입은 "수정된 결함에 대해 코드가 생성된 날짜"의 히스토그램을 표시함으로써 감지할 수 있다. Introduction of new faults while resolving the old can be detected by plotting a histogram of the "date the code was created for faults that were corrected."
지속적인 고정을 통한 유지관리성 상실은 해결 시간 대 변경된 코드 라인 수 대 변경된 코드 라인당 평균 시간으로 표시하여 측정할 수 있다. 또한 각 변경에 영향을 받는 모듈의 평균 개수를 기준으로 변경사항의 평균 크기를 측정할 수 있다. Loss of maintainability with continued fixing can be measured by the time to resolve versus the number of lines of code changed, plotted as the average time per line of code changed. We can also measure the average size of changes, in terms of the average number of modules affected by each change.
그 난이도가 (일반적으로 더 어려운) 제도의 악화에서 오는 것인지, 선택 효과에서 오는 것인지는 알 수 없다. 다른 많은 간단한 측정도 가능하며, 각 조직들은 그들 자신의 실패의 무리와 싸우는데 무엇이 효과가 있는지 선택해야 할 것이다. It can be hard to know whether the difficulty is coming from the deterioration of the system (generally harder to work with) or selection effects (fewer, but more difficult, errors). Many other simple measurements are possible, and each organization will have to choose what works for them in combatting their own swarms of failures.
Part V: 0차원 측정 (Zeroth-Order Measurement)
Chapter 7: 측정 가능한 작업들로 이루어진 프로젝트들 (Projects Composed of Measurable Tasks)
Summary
0차원 측정은 고품질 소프트웨어의 품질 관리를 위한 확실한 경로에서 당신을 시작하는데 필요한 최소 활동 세트다. 그것들은 다른 측정 시스템이 구축되어야 하는 기초를 형성한다. 이 베이스가 없다면 대부분의 다른 측정은 무의미하거나 오해의 소지가 있을 것이다. Zeroth-order measurements are the minimum set of activities you need to start you on a sure path to quality management of quality software. They form the base on which any other measurement system must be built. Without this base, most other measurements will be meaningless or misleading.
0차원 측정의 기본은 These basics of zeroth-order measurement are
측정 가능한 과제의 프로젝트를 구성하여 양질의 제품을 생산하는 방법에 대한 지식 knowledge of how to compose a project of measurable tasks to produce a quality product
프로젝트의 품질에 대한 진행에 대한 공공의 관점을 만들고 유지하는 시스템 a system of creating and maintaining a public view of progress on the project's quality
품질에 대한 우리의 의미를 문서화하는 요구사항의 시스템 a system of requirements that document what we mean by quality
품질을 향한 진행의 모든 부분을 측정하기 위한 일관된 검토 시스템 a consistent system of reviews to measure every part of the progress towards quality
소프트웨어 측정을 시작하기 가장 좋은 시기는 다른 것을 하기 전이다. 측정은 초기 계획에 포함되어야 하며 계획이 변경될 때 유지되어야 한다. 효과적인 측정은 사후 고려로서 "덧칠할" 수 없지만, 반드시 설계되어야 한다. The best time to start measuring software is before you do anything else. Measurement must be built into the initial plan and maintained as the plan changes. Effective measurement cannot be "painted on" as an afterthought, but must be designed.
어떤 종류의 노력이라도 관찰하는데 있어 필수적인 첫 단계는 그것을 측정 가능한 프로젝트로 바꾸는 것이다. 이것은 어떤 종류의 작업으로도 할 수 있다. The essential first step in observing any kind of effort is to transform it into a measurable project. This can be done with any kind of task.
프로젝트는 변화를 이루기 위한 노력이다. 그런 변화는 인식이나 욕망, 현실에 힘써서 이루어질 수 있다. A project is an effort directed towards accomplishing some change. Such a change can be accomplished by working on perceptions, desires, or realities.
측정 가능한 프로젝트를 계획하기 위한 하나의 접근방식은 다음과 같은 단계로 구성된다: One approach to planning for a measurable project consists of these steps:
반복주기 프로세스를 준비한다. Prepare for an iterative process.
고객이 누구인지 파악한다. Establish who the customers are.
무엇이 보존되어야 하는가? What should be preserved?
목표를 선택한다. Select a goal
측정 가능한 방법으로 목표를 진술하라. State the goal in an measurable way.
과하게 프로젝트를 구속하지 않는 방식으로 목표를 진술한다. State the goal in a way that does not overly constrain the project.
장애물이 없는지 확인한다. Check for obstacles.
자원을 확인한다. Check for resources.
계획을 시작하라. 거꾸로. Start to plan, backward.
목표 진술은 다양한 시험을 거쳐야 한다. 그들은 무엇을 원하는지에 관한 것이지 원하지 않는 것에 관한 것이 아니다. 가용 자원으로 달성할 수 있는 방식으로 이들을 구성한다. "당신의 목표가 달성되었다는 것을 확인할 수 있는 어떤 것을 보고 느낄 것인가?"라는 질문으로 그들을 확인한다. 또한 각 단어의 의미 범위를 탐색하여 확인하라. Goal statements should be subjected to a variety of tests. They should be in terms of what is wanted, not in terms of what is not wanted. Frame them in ways that are achievable with available resources. Check them with the question, "What will you see, hear, or feel that will confirm that your goal has been achieved?" Also check by exploring the range of meaning of each word.
어떤 계획이라도 계획 - 미래가 어떻게 될 것인가에 대한 일련의 추측 - 일 뿐이다. 당신의 일련의 예측에는 잘못될 수 있는 많은 것들이 있다. 따라서 점진적인 목표 측면에서 큰 프로젝트를 계획하는 것이 현명하다. 각 목표에 도달하거나 근사치를 계산한 후에, 프로젝트는 재계획된다. Any plan is just a plan—a series of guesses about how the future will work out. There are many things that can go wrong in your series of predictions. Therefore, it is wise to plan big projects in terms of incremental goals. After each goal is reached or approximated, the project is replanned.
Chapter 8: 계획들과 진척에 대해 커뮤니케이션하기 (Communicating About Plans and Progress)
Summary
프로젝트의 각 부분이 잠재적으로 측정할 수 있다고 해서 실제로 측정되거나 측정치가 적시에 적절한 사람에게 도달하는 것은 아니다. Just because each part of a project is potentially measurable doesn't mean it will actually be measured, or that the measurements will reach the right people at the right time.
사람들이 전체 프로젝트와 그들의 작업이 어떻게 연관되어 있는지 파악하지 못할 때, 그들은 제품의 질을 떨어뜨리거나 심지어 프로젝트의 완성을 위협하는 일을 할 것이 확실하다. 그러므로 계획은 의사소통할 수 있는 동시에 의사소통할 수 있는 역할을 가진 모든 사람이 이해할 수 있어야 한다. When people lack a grasp of the entire project and how their work relates to it, they're sure to do something that unknowingly undermines the quality of the product, or even threatens the very completion of the project. Therefore, a plan must be understandable to everyone who has a part in it—both communicable and communicated.
향상된 의사소통 체계는 인간 조직에서의 의사소통에 관한 몇 가지 기본적인 규칙의 이해에 달려 있다: An improved communication system rests on an understanding of some basic rules about communication in human organizations:
아무리 좁은 채널이라도 사람들 사이에는 항상 소통이 있다. There's always communication among people, even with the narrowest channel.
비밀 통신 채널은 항상 발전한다. Secret communication channels always develop.
항상 미스 커뮤니케이션이 존재한다. There's always miscommunication.
의사소통은 항상 당신이 생각하는 것보다 어렵다. Communication is always harder than you think it's going to be.
한 곳에서 의사소통을 개선하면 다른 곳에서는 더 어려워질 것이다. Improving communication in one place will make it harder in another place.
0차원 측정 시스템을 위해서는 조직이 개방되어야 한다. 조직이 많이 열리면 열릴수록 두 번째 조건인 정직에 맞추기 쉽다. 세 번째 조건은 사람들이 다른 사람들로부터 배우는 것이다. For a zeroth-order measurement system, the organization must be open. The more open an organization, the easier it is to meet the second condition: honesty. The third condition is people learning from other people.
첫번째 0차원 주문 측정 도구는 계획 상태를 달성하기 위해 어떤 작업을 수행해야 하는지, 그리고 지금까지 어떤 진척이 이루어졌는지를 보여주는 인과관계 다이어그램 형식의 공공 프로젝트 진행률 포스터(PPPP: Public Project Progress Poster)이다. The first zeroth-order measurement tool is the Public Project Progress Poster, which is a form of cause-and-effect diagram showing what tasks must be accomplished to achieve the planned states, and what progress has been made so far.
PPPP는 업무 뿐만 아니라 업무 산출물을 측정하는 역할을 하는 검토를 보여주는 표준 업무 단위로 구성된다. 또한 검토를 위한 측정 기준이 되는 요건을 포함한 전제조건이 포함되어 있다. The PPPP is built of standard task units, which show not only the task, but the review that serves to measure the product of the task. It also includes the prerequisites, including the requirements that serve as the standard of measurement for the review.
마지막에 검토하지 않으면 과제는 제품을 생산하는 것이 아니라 제품 후보자에게만 생산된다. 지원자는 검토에 의해 제품이 측정될 때까지만 제품이 되며, 그러한 측정은 요구 사항에 비해 유리하다. Without the review at the end the task doesn't produce a product, but only a product candidate. A candidate only becomes a product until it has been measured by a review and those measurements compared favorably to the requirements.
프로젝트 포스터를 게시하면 모든 사람이 보고 이해할 수 있는 성취해야 할 것을 시각화한 공공 프로젝트 포스터가 된다. 주간 업데이트는 Public Project Poster를 Public Project Progress Poster로 변환한다. Posting the Project Poster makes it a Public Project Poster—a visualization of what is to be accomplished that all can see and understand. Weekly updating converts the Public Project Poster into a Public Project Progress Poster.
포스터에는 오늘의 날짜를 나타내는 타임 라인이 배치되어 있어, 모든 사람이 어떤 작업이 예정대로 진행되고 있는지, 어떤 것은 그렇지 않은지 알 수 있다. A time line is placed on the Poster to represent today's date, so everyone can see which tasks are on schedule, and which are not.
포스터를 통과하면 누구나 작업 단위의 품질과 상태를 즉시 알아볼 수 있다. 시간선 왼쪽은 과거 시간을 나타내기 때문에 아무것도 바꿀 수 없다. 그 프로젝트를 재개하는 사람은 반드시 오늘의 선 오른쪽에 있어야 하므로, 우리는 "과거를 다시 쓰지" 않는다. The quality and status of the work unit can be recognized instantly by anyone passing the Poster. Nothing to the left of the time line can be changed, because it represents past time. Any replanning the project must be to the right of the today line, so we don't "rewrite the past."
일단 PPPP가 가동되면 트러블을 감출 수 없고 해석하기 쉽기 때문에 조직에 놀라운 변화가 나타나기 시작한다. 관리자는 자체적인 성과 측정치를 게시함으로써 측정에 대한 일치된 메세지를 전달한다. 그리고 사람들은 프로세스 개선이나 퇴화를 쉽게 볼 수 있기 때문에 동기부여가 된다. Once the PPPP goes into operation, amazing changes start to appear in the organization, because trouble can't be hidden and is easy to interpret. By posting a measure of their own performance, management sends a congruent message about measurement. And people are motivated because it's easy to see process improvement or degeneration.
Chapter 9: 측정 도구로서의 리뷰 (Reviews as Measurement Tools)
Summary
기술적 검토는 불쾌한 진실을 감히 직면할 수 있기 때문에 0차원 측정의 핵심 요소인 동시에 모든 상위 수준도 마찬가지다. PPPP는 프로젝트 관리에 있어 기술 검토의 역할을 명확히 한다. Technical reviews are key elements of zeroth-level measurement—and all higher levels as well—because they dare to face unpleasant truths. The PPPP makes clear the role of the technical review in project management.
비록 테스팅이 모든 결함을 제거했다 하더라도, 리뷰는 기계 시험보다 일찍 많은 결함을 제거하기 때문에 일정 성능을 개선하는데 도움이 될 것이다. 검토된 프로젝트는 더 느리게 시작되는 것처럼 보이지만, 기계 테스트를 불균형하게 단축시키기 때문에 실제로 더 빨리 마무리된다. 또한 코딩이 수행되기 전에 설계 결함이 발견될 경우 많은 코딩이 제거된다. Even if testing did remove all faults, reviews would be helpful at improving schedule performance because reviews remove many of the faults earlier than machine testing. Reviewed projects do seem to start slower, but actually finish faster because they shorten machine testing disproportionately. Reviews also eliminate a great deal of recoding when they find design faults before coding is done
검토는 테스팅의 대안이 아니라, 단순히 특수한 성질을 가진 테스트의 또 다른 형태일 뿐이다. 리뷰는 기계 테스트보다 더 일찍 사용할 수 있다. 리뷰는 기계 테스트와 다른 결함의 프로필을 찾아낸다. 리뷰는 시간이나 자원에 있어서 준비에 대한 투자를 거의 필요로 하지 않는다. Reviews are not an alternative to testing, but simply another form of testing that has special properties. Reviews can be used earlier than machine tests. Reviews find a different profile of faults than machine tests. Reviews require little investment in setup, either in time or resources.
테스트로서의 모든 이점 외에도, 리뷰는 테스팅하는 동안 가르친다. 리뷰 참가자는 리뷰에서 기술적 문제, 자신에 대한 정보 및 기타 정보에 대해 배운다. 따라서, 리뷰가 제품을 향한 것처럼 보이지만, 장기적으로는 그것의 주요 효과가 과정에 있다. In addition to all their benefits as tests, reviews teach while testing. Review participants learn about technical issues, about themselves, and about others in the review. Thus, although the review seems to be directed at the product, its major effect in the long run is on the process.
매 리뷰에 대한 기술 검토 요약 보고서는 프로젝트 이력 파일에 보관되며, 제품 후보 측정에 대해 알아야 할 사항을 관리자들에게 알려준다. 요약 양식은 측정이 어떻게 이루어졌는지, 즉 측정 뒤에 있는 "스토리"와 프로젝트를 관리하는데 필요한 정확한 정보를 모호하지 않게 문서화한다. The Technical Review Summary Report for every review is kept in the project history file and tells managers what they need to know about the measurement of a product candidate. The summary form documents how the measurements were done—the "story" behind the measurement and precisely the information needed to manage a project, in unambiguous terms.
리뷰어들은 제품 후보자의 품질에 대해 다음과 같은 가능한 판단을 하도록 제한된다: The reviewers are constrained to the following possible judgments of the quality of the product candidate:
현재대로 승인됨 accepted as is
사소한 개정으로 승인됨 accepted with minor revisions
주요한 개정이 필요함 major revisions required
재구축이 필요함 rebuild required
리뷰가 완료되지 않음 review not completed.
프로젝트를 통제하는데 필요한 보수적인 판단을 보장하기 위해 결론을 도출하는데 있어 몇 가지 핵심 원칙을 고려한다: To ensure the kind of conservative judgment needed to control a project, consider several key principles in arriving at a conclusion:
항상 가장 보수적인 선택을 하라. Always take the most conservative choice.
의견 차이를 들어보라. Listen for differences of opinion.
서명에 대한 반응을 확인하라. Notice the reaction to signing.
문제를 다시 열려는 시도를 주의하라. Watch for attempts to reopen issues.
강한 감정을 눈치채고 확인하라. Notice and check out strong feelings.
이러한 원칙을 준수함으로써 전체 프로젝트 실패의 위험을 줄일 수 있는 신뢰성 있는 측정치를 확보한다. By following these principles, the organization obtains reliable measurements that reduce the risk of total project failure.
어떤 작업에서든 제품 후보를 검토할 수 있다. 그렇지 않다면 그것은 과제가 아니다. 아마도 가장 중요한 제품 후보는 다른 어떤 측정치일 것이다. 왜냐하면 궁극적으로는 모든 측정치는 어떤 사람이나 사람의 의견에 달려 있기 때문이다. 기술적 검토는 모든 측정이 알려진 신뢰성을 갖도록 의존성을 공식화하는 방법이다. "검토하기 전까지는 측정이 아니다"라는 점을 기억하라. The product candidate from any task can be reviewed. If not, it's not a task. Perhaps the most important product candidate is any other measurement because ultimately every measurement rests on the opinions of some person or persons. The technical review is a way of formalizing that dependency, so that all measurements are of known reliability. Remember: "It's not a measurement until it's been reviewed."
기술 검토는 또한 다른 제안된 측정의 효율성이나 효과성을 시험할 수 있는 표준이다. The technical review is also a standard against which any other proposed measurement can be tested for efficiency or effectiveness.
Chapter 10: 요구사항: 측정의 기반 (Requirements: The Foundation of Measurement)
Summary
기술적 검토는 절대적 측정은 아니지만, 항상 요구조건에 상대적이다. Technical reviews are never absolute measurements, but are always relative to the requirements.
비신뢰성의 제0법칙은 소프트웨어 엔지니어링의 제0법칙의 특정한 한 가지 사례에 지나지 않는다: "품질에 신경을 쓰지 않으면 다른 목적을 달성할 수 있다." The Zeroth Law of Unreliability is merely one particular case of the Zeroth Law of Software Engineering: "If you don't care about quality, you can meet any other objective."
요구사항 프로세스의 목적은 막연한 요구를 고객이 원하는 바를 명시적이고 모호하지 않은 진술로 바꾸는 것이다. 우리는 이 진술들을 무엇이 원하는지, 즉 피드백 제어 프로세스의 근본적인 측정에 사용할 수 있다. The purpose of any requirements process is to change vague desires into explicit and unambiguous statements of what customers want. We can use these statements for comparison of what was built with what was desired—the fundamental measurement of any feedback controlled process.
음의 차원 측정은 아예 측정하지 않는 것보다 나쁜 측정이다. 요구사항 추측은 음의 차원 측정의 한 예다. A negative-order measurement is one that is worse than not measuring at all. Guessing requirements is one example of a negative-order measurement.
세계는 폭포수 모델과 다른 선형 프로세스 모델이 요구하는 방식으로 작동하는 경우는 거의 없지만, 프로젝트가 진행됨에 따라 새로운 요구사항을 창출하고 있다. 요구사항 개발 프로세스는 소프트웨어 개발 프로세스와 제품의 모든 사용자와 지속적으로 대화한다. The world seldom works the way the Waterfall Model and other linear process models require, but goes on generating new requirements as the project proceeds. The requirements development process is in constant dialogue with both the software development process and all users of the product.
요구사항의 상태를 관찰할 수 없는 경우, 프로젝트는 그 추이를 아무도 알지 못하는 사이에 요구사항에서 벗어날 수 있다. 아무도 눈치채지 못한 채 측정 기준이 바뀌었기 때문에 검토 과정에 의한 측정은 무의미해진다. If the status of requirements is not observable, the project can drift away from its requirements without anyone being aware of the drift. Measurements made by the review process then become meaningless, because the standard of measurement has changed without anyone noticing.
요구사항 정의 프로세스는 항상 소프트웨어 개발 프로세스와 병행하여 실행되지만, 그 과정은 서로 다른 문화적 패턴에서 상당히 다르게 보인다. A requirements definition process is always running in parallel with the software development process, but the process looks quite different in the different cultural patterns.
패턴2(루틴) 문화는 소프트웨어 구축 프로세스보다 요구사항 프로세스가 덜 중요하다는 것을 전달할 수 있는데, 이 경우 계획 수립에 거의 노력을 기울이지 않고, 자원이 투입되지 않으며, 누구도 전임 책임을 지지 않으며, 훈련이 경박해 보이며, 도구가 불필요해 보일 것이다. 실질적인 요구사항 절차는 없을 것이고, 개발은 통제되지 않을 것이다. Pattern 2 (Routine) cultures may communicate that the requirements process is less important than the software-building process, in which case little effort will be devoted to planning, resources will not be committed, nobody will take full-time responsibility, training will seem frivolous, and tools will seem superfluous. There will be no real requirements process, and development will be uncontrolled.
패턴3(조정하는) 요구사항 프로세스는 그 자체로 통제된 피드백 프로세스로서, 소프트웨어 제품과 동등하게 중요하며, 다른 프로세스와 마찬가지로 경영진의 지원을 받는다. A Pattern 3 (Steering) requirements process is a controlled feedback process in its own right—with its own products equal in importance to the software products, and supported by management just like any other process.
요구사항이 심각하게 받아들여져도 프로세스를 파괴하는 누설이 있을 수 있다. 누출 연구는 요구사항이 변경되는 통제되지 않은 수십 가지 방법을 찾을 수 있다. Even when requirements are taken seriously, there may be leakage that destroys the process. A leakage study may turn up dozens of uncontrolled ways in which requirements change.
요구사항의 잠재적 원천이 매우 많기 때문에, 0차원 측정은 누출을 통제된 요구사항으로 변환해야 한다. 이 프로세스를 시작하는 한 가지 방법은 서명된 시작 작업 수락 보고서(Startup Task Acceptance Report: STARt)를 사용하는 것이다. Because there are so many potential sources of requirements, zeroth-order measurement must convert leaks to controlled requirements. One way to begin this process is through the use of a signed Startup Task Acceptance Report (STARt).
STARt와 함께라면, 건설업자가 그 일을 수행하는데 필수적인 요소들을 가지고 있다는 것에 대해 전문적인 명성을 걸었다는 것을 알 것이다. 이 서명은 이 중요한 순간에 모든 관련자들이 주의 깊은 상태에 있도록 강요하기 때문에, 의사소통은 높은 수준의 품질을 유지한다. With STARt, you know that the builder has staked a professional reputation on having the essentials for performing the task. The signature forces everyone involved to be in an attentive state at this crucial moment, so that communication remains at a high level of quality.
Chapter 11: The Wayfinder
하와이의 태평양 부근은 우리 행성의 3분의 1을 차지하고 있으며 모든 대륙을 합친 것보다 더 크다. 그것은 995 부분의 물과 5 부분의 땅이지만, 그것의 거의 모든 10,000개 이상의 섬들이 몇 세기 전에 유럽 탐험가들이 이 지역에 도착하기 훨씬 전에 발견되었다. 광범위한 오픈 오션 항해는 광활하고 외딴 폴리네시안 삼각지대를 정착시켰고, 쿡 선장이 "지구상에서 가장 넓은 국가"라고 부르는 것을 발견했을 때 놀라움을 자아냈다. 이 폴리네시아 "국가"의 사람들은 언어, 문화, 유전적 유산을 공유했다. 그러나 그들은 문맹자였고, "절약자"였으며, 서구 문명의 지도와 도구가 부족했다. 서양인들은 원주민들이 외해를 안정적으로 여행하고 있다고 믿는데 어려움을 겪었고, 반면 그들의 조상들은 해안선에 매달리고 있다. Hawaii's Pacific Ocean neighborhood engulfs a third of our planet and is larger than all our continents combined. It is 995 parts water and 5 parts land, yet almost all of its more than 10,000 islands had been discovered long before European explorers arrived in the region a few centuries ago. Extensive open-ocean voyaging settled the vast, remote Polynesian Triangle of islands and made possible the astonishment of Captain Cook at coming upon what he called "the most extensive nation on Earth." The people of this Polynesian "nation" shared a language, culture, and genetic inheritance. But they were illiterate, "savage" and lacked the maps and instruments of Western civilization. Westerners had difficulty believing that native wayfinders had been reliably traveling the open sea while their own forebears—afraid of falling over the edge—were clinging to their coastlines.
2000마일 이상의 공해로 항해하는 일은 많은 면에서 대형 소프트웨어 시스템을 구축하거나 유지하는 것과 견줄 만하다. 미개척자들에게는 우선 간단해보인다. 그리고 나서, 더 생각해 보면, 그것은 불가능할 정도로 복잡해지고 위험해진다. 그러나 길잡이에게 각각의 일은 같은 종류의 관찰력을 요구한다. The task of navigating to a tiny atoll over 2,000 miles of open ocean is in many ways comparable to building or maintaining a large software system. To the uninitiated, it first seems simple. Then, on further thought, it becomes impossibly complex and dangerous. To the wayfinder, however, each task requires the same kind of observational powers.
광활한 태평양에 홀로 육지가 보이지 않는 곳에서 폴리네시아 길찾기들은 놀라운 정확성을 가지고 항해했다. 이와 유사하게, 소수의 소프트웨어 엔지니어링 관리자는 놀랄만한 품질의 (관찰력이 적은) 결과로 프로젝트를 지휘할 수 있다. Alone on the vast Pacific, out of sight of land, the Polynesian wayfinders navigated with (to Europeans) astonishing accuracy. Similarly, a few software engineering managers are able to steer projects with (to less observant managers) results of astonishing quality.
폴리네시안 웨이파인더는 약간의 바다 부풀기, 구름 형성, 밝기, 색깔, 태양, 달, 별의 위치, 수류와 온도의 변화, 선상 돼지에 의해 감지되는 향기, 표류하는 파편과 해초, 새 종과 비행 패턴, 카누의 투구와 롤, 그리고 서구인들이 여전히 이해하지 못하는 다른 미묘한 측정들을 사용한다. The Polynesian wayfinder uses slight ocean swells; cloud formations, brightness, and color; the position of the sun, moon, and stars; shifts in water currents and temperature; the scents detected by an on-board pig; drifting debris and seaweed; bird species and flight patterns; the pitch and roll of the canoe; and other subtle measurements that Westerners still do not comprehend.
소프트웨어 엔지니어링 웨이파인더는 양식에 서명할 때 약간의 망설임과 호흡 변화, 진행률 포스터의 색과 패턴, 사람들이 회의에 앉아 있는 위치, 실패에 대응하기 위한 시간 이동, 긴장된 땀과 탄 커피 냄새, 배달 날짜의 표류, 활동과 불활성의 패턴, 음성의 피치와 rate; 그리고 다른 더 적은 관리자들은 절대 이해할 수 없는 다른 미묘한 측정들을 사용한다. The software engineering wayfinder uses slight hesitations and changes in breathing on signing a form; the color and pattern of a Progress Poster; the positions people sit in meetings; shifts in time to respond to failures; the odor of nervous sweat and burnt coffee; drifting of delivery dates; patterns of activity and inactivity; the pitch and rate of voices; and other subtle measurements that lesser managers may never comprehend.
이 책을 다 읽었으면 소프트웨어 길잡이가 되기 위한 큰 항해에서 작은 부분을 완성한 것이다. 당신의 다음 단계는 당신의 아웃리거에 올라타서 항해하는 것이다. 모든 감각을 열어놓고, 당신의 마음을 해석하고 배우라. If you've finished this book, you've completed one small part of your grand voyage toward becoming a software wayfinder. Your next stage is to climb into your outrigger and set sail, keeping all your senses open and your mind clear to interpret and learn.
그리고 안심하라. 해변에 평지인들이 떼지어 서서 지구 가장자리에서 떨어질 거라고 외칠테니, 당신의 감정을 잘 알고 올바른 방향을 잡으라. And rest assured, there will be a horde of flatlanders standing on the beach shouting that you're going to fall off the edge of the Earth, so stay aware of your feelings and steer the right course.
즐거운 여행이 되기를! Bon voyage!