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.