QSM Vol 1
주요 쳅터
- Acknowledgments
- Preface
- Patterns of Quality
- What Is Quality? Why Is It Important?
- A Tale of Software Quality
- The Relativity of Quality
- Quality Is Value to Some Person
- Precision Cribbage
- Why Improving Is So Difficult
- Software Culture and Subculture 1.7 Helpful Hints and Suggestions 1.8 Summary 1.9 Practice
- Software Subcultures
- Applying Idea to Software
- Six Software Subcultural Patterns
- Pattern 0: Oblivious
- Pattern 1: Variable
- Pattern 2: Routine
- Pattern 3: Steering
- Pattern 4: Anticipating
- Pattern 5: Congruent
- Helpful Hints and Suggestions
- Summary
- Practice
- What Is Needed to Change Patterns?
- Changing Thought Patterns
- Using Models to Choose A Better Pattern
- Opening Patterns to Information
- Helpful Hints and Suggestions
- Summary
- Practice
- What Is Quality? Why Is It Important?
- Patterns of Managing
- Control Patterns for Management
- Shooting at Moving Target
- Aggregate Control Model
- Patterns and Their Cybernetic Control Models
- Engineering Models
- From Computer Science to Software Engineering
- Helpful Hints and Suggestions
- Summary
- Practice
- Making Explicit Management Models
- Why Things Go Awry
- Linear Models and Their Fallacies
- Diagram of Effects
- Developing a Diagram
- Nonlinearity Is The Reason Things Go Awry
- Helpful Hints and Suggestions
- Summary
- Practice
- Feedback Effects
- The Humpty Dumpty Syndrome
- Runaway, Explosion, and Collapse
- Act Early, Act Small
- Negative Feedback - Why Everything Doesn't Collapse
- Helpful Hints and Suggestions
- Summary
- Practice
- Steering Software
- Methodologies and Feedback Control
- The Human Decision Point
- It's Not the Event That Counts, It's Your Reaction to the Event
- Helpful Hints and Suggestions
- Summary
- Practice
- Failing to Steer
- I'm Just a Victim
- I Don't Want to Hear Any of That Negative Talk
- I Thought I Was Doing the Right Thing
- Helpful Hints and Suggestions
- Summary
- Practice
- Control Patterns for Management
- Demands That Stress Patterns
- Why It's Always Hard to Steer
- Game of Control
- Size / Complexity Dynamic in Software Engineering
- Helpful Hints and Suggestions
- Summary
- Practice
- What Helps to Stay in Control
- Reasoning Graphically About the Size / Complexity Dynamic
- Comparing Patterns and Technologies
- Helpful Interactions
- Helpful Hints and Suggestions
- Summary
- Practice
- Responses to Customer Demands
- Customers Can Be Dangerous to Your Health
- The Cast of Outsiders
- Interactions with Customers
- Configuration Support
- Releases
- Helpful Hints and Suggestions
- Summary
- Practice
- Why It's Always Hard to Steer
- Fault Patterns
- Observing and Reasoning About Errors
- Conceptual Errors About Errors
- Misclassification of Error Handling Process
- Observational Errors About Errors
- Helpful Hints and Suggestions
- Summary
- Practice
- The Failure Detection Curve
- The Difference Detection Dynamic
- Living with the Failure Detection Curve
- Helpful Hints and Suggestions
- Summary
- Practice
- Chapter Appendix: Official Differences Between the Pair Pictures in Figure 13-1
- Locating the Faults Behind the Failures
- Dynamics of Fault Location
- Circulation of STI's Before Resolution
- Process Faults: Losing STI's
- Political Time: Status Walls
- Labor Lost: Administrative Burden
- Helpful Hints and Suggestions
- Summary
- Practice
- Fault Resolution Dynamics
- Basic Fault Resolution Dynamics
- fault Feedback Dynamics
- Deterioration Dynamics
- Helpful Hints and Suggestions
- Summary
- Practice
- Observing and Reasoning About Errors
- Pressure Patterns
- Power, Pressure, and Performance
- The Pressure / Performance Relationship
- Pressure to Find the Last Fault
- Stress / Control Dynamic
- Forms of Breakdown Under Pressure
- Management of Pressure
- Helpful Hints and Suggestions
- Summary
- Practice
- Handling Breakdown Pressures
- Shuffling Work
- Ways of Doing Nothing
- The Boomerang Effect of Short-Circuiting Procedures
- How Customers Affect Boomerang
- Helpful Hints and Suggestions
- Summary
- Practice
- What We've Managed to Accomplish
- Why Systems Thinking?
- Why Manage?
- Estimating Our Accomplishments
- What Each Pattern Has Contributed
- Meta-Patterns
- Helpful Hints and Suggestions
- Summary
- Practice
- Power, Pressure, and Performance
1장: 품질이란 무엇인가? 왜 중요한가?
품질은 상대적이다. 품질은 사람에 연관되어 있기 때문이다.
- 품질은 요구사항을 만족하는 것이다.
품질은 누군가의 요구사항을 만족하는 것이다.
따라서 품질에 대한 정의는 정치적이고 감정적 측면을 포함한다. 품질은 어떤 사람의 의견이 중요한지에 대한 일련의 결정을 항상 포함하고 있기 때문이다. 그러나 품질에 사람이 연관되어 있다는 사실은 간과되기 쉽다. 정치적, 감정적인 요소는 소프트웨어 세상에서는 잘 다뤄지지 않기 때문이다. 반대로 사람이 연관되어 있기 때문에 품질이 상대적이라는 사실을 이해하면 품질에 대해 사람들이 서로 모순되는 생각을 가지고 있는 상황이 설명된다.
품질을 높이는 것은 쉽지 않다. 왜 그럴까?
- 그렇게 나쁘지는 않아: 외부에서 압력을 받지 않는 한 품질 개선 동기가 생기지 않는, 정체상태의 조직 때문에.
- 그건 불가능해: '품질의 가치는 측정하는 것이 불가능하다'라는 생각.
- 속박 효과: 조직이 처해있는 현재의 여러가지 상황이 여러 부분에서 변화를 속박함.
소프트웨어 조직이 어느 특정 품질 수준에 속박되어서, 조직의 변화가 '문화의 보수적인 속성'으로 인해 방해받을 수 있다.
- 현재의 품질 수준에 대한 만족
- 개선을 시도하다가 오히려 품질 수준을 잃는 것에 대한 두려움
- 다른 문화에 대한 이해 부족
- 자기 자신의 문화에 대한 불가시성
위와 같은 요인 때문에 변화가 어렵다. 고품질 소프트웨어의 새로운 문화를 달성하기 위해서는 개발자나 관리자가 이러한 요인을 효과적으로 처리하는 능력을 배워야 한다.
그러기 위해서는,
- 나의 현재 수준에 대한 인식 및 다음 수준에 대한 관심/흥미 지원
- 현재 수준을 잃는 것에 대한 두려움보다 개선을 시도하는 과정에서 얻을 유익함/즐거움/도전에 대한 동경/갈망
- 다른 수준/문화에 대한 접촉/경험 확대
- 나 자신에 대한 끊임없는 가시성 확보 (저널, Where Am I 확보)
를 해야 한다.
연습문제
제품의 초기 버전이나 경쟁 제품을 사용해 본 다음, 특정 소프트웨어가 시간의 흐름에 따라 그 가치와 품질에 대한 정의가 어떻게 변화했는지를 논의하라.
- 개발 초기: 배경화면이 예뻐야 한다. 빠른 속도로 열람할 수 있어야 한다.
- 사용자들의 요구: 배경화면의 종류가 다양해야 한다.
- 사용자들의 요구: Crop 기능이 올바로 동작해야 한다. 내 폰의 크기에 맞는 배경을 제공해야 한다.
당신의 조직의 하드웨어 아키텍처를 표준화 할 경우에, 조직이 속박될지도 모르는 일련의 특성들의 리스트를 작성하라.
- OS
- Python library, Python version
- 담당 개발자
- 컴파일러
- 컴파일해서 쓰고 있는 NginX 웹서버
- IDC의 응급 지원 서비스
- iPhone, Android 시장 선택
여러분이 속해 있는 조직의 사람들이 제품의 품질 수준에 정말 만족하는지를 나타내는 증거는 무엇인가? 그 수준에 불만을 표시하는 사람들을 조직은 어떻게 다루고 있는가?
만족에 대한 증거
- 접속자 수 증가
불만 표시자 다루는 방법
- ...