I. What Is Dynamic Reteaming?
1. The Evolution Of Teams
2. Understanding Teams
3. The Power Of Team Assignment
4. Reduce Risk And Encourage Sustainability
II. Dynamic Reteaming Patterns
5. One-By-One Pattern
6. Grow-And-Split Pattern
7. Isolation Pattern
8. Merging Pattern
9. Switching Pattern
10. Anti-Patterns
III. Tactics For Mastering Dynamic Reteaming
11. Adapt Your Organization For Dynamic Reteaming
12. Plan Your Dynamic Reteaming Initiative
13. After Dynamic Reteaming: Transitions And Team Calibrations
14. Reflect And Determine How To Shift
IV. Conclusion
I. Strategic Design
1. Analyzing Business Domains
2. Discovering Domain Knowledge
3. Managing Domain Complexity
4. Integrating Bounded Contexts
II. Tactical Design
5. Implementing Simple Business Logic
6. Tackling Complex Business Logic
7. Modeling The Dimension Of Time
8. Architectural Patterns
9. Communication Patterns
III. Applying Domain-Driven Design In Practice
10. Design Heuristics
11. Evolving Design Decisions
12. EventStorming
13. Domain-Driven Design In The Real World
IV. Relationships To Other Methodologies And Patterns
14. Microservices
15. Event-Driven Architecture
16. Data Mesh
1. What Happens When There Are No “Best Practices”?
I. Pulling Things Apart
2. Discerning Coupling In Software Architecture
3. Architectural Modularity
4. Architectural Decomposition
5. Component-Based Decomposition Patterns
6. Pulling Apart Operational Data
7. Service Granularity
II. Putting Things Back Together
8. Reuse Patterns
9. Data Ownership And Distributed Transactions
10. Distributed Data Access
11. Managing Distributed Workflows
12. Transactional Sagas
13. Contracts
14. Managing Analytical Data
15. Build Your Own Trade-Off Analysis
Part I: Transformational Strategic Learning through Experimentation
Chapter 1: Business Goals and Digital Transformation
Chapter 2: Essential Strategic Learning Tools
Chapter 3: Events-First Experimentation and Discovery
Part II: Driving Business Innovation
Chapter 4: Reaching Domain-Driven Results
Chapter 5: Contextual Expertise
Chapter 6: Mapping, Failing, and Succeeding—Choose Two
Chapter 7: Modeling Domain Concepts
Part III: Events-First Architecture
Chapter 8: Foundation Architecture
Chapter 9: Message- and Event-Driven Architectures
Part IV: The Two Paths for Purposeful Architecture
Chapter 10: Building Monoliths Like You Mean It
Chapter 11: Monolith to Microservices Like a Boss
Chapter 12: Require Balance, Demand Strategy
Part I What Is Software Engineering?
1 Introduction
2 What Is Engineering?
3 Fundamentals of an Engineering Approach
Part II Optimize For Learning
4 Working Iteratively
5 Feedback
6 Incrementalism
7 Empiricism
8 Being Experimental
Part III Optimize For Managing Complexity
9 Modularity
10 Cohesion
11 Separation of Concerns
12 Information Hiding and Abstraction
13 Managing Coupling
Part IV Tools To Support Engineering In Software
14 The Tools of an Engineering Discipline
15 The Modern Software Engineer
I. Introductory Material
1. The Intersection Of Security And Reliability
2. Understanding Adversaries
II. Designing Systems
3. Case Study: Safe Proxies
4. Design Tradeoffs
5. Design For Least Privilege
6. Design For Understandability
7. Design For A Changing Landscape
8. Design For Resilience
9. Design For Recovery
10. Mitigating Denial-Of-Service Attacks
III. Implementing Systems
11. Case Study: Designing, Implementing, And Maintaining A Publicly Trusted CA
12. Writing Code
13. Testing Code
14. Deploying Code
15. Investigating Systems
IV. Maintaining Systems
16. Disaster Planning
17. Crisis Management
18. Recovery And Aftermath
V. Organization And Culture
19. Case Study: Chrome Security Team
20. Understanding Roles And Responsibilities
21. Building A Culture Of Security And Reliability
It feels like a whack-a-mole type thing because that is not a real book. I gave a workshop on that in Chicago. I forgot how many years ago, but somebody has put that up as a page on Amazon and I need to go and figure out where to go and get that taken down.
最後に、ナオミ・スタンフォード『Guide to Organisation Design: Creating high-performing and adaptable enterprises』です。9ページなど何度か言及されているこの書籍ですが、おもしろそうでした。Amazonだと2つページがあるのですが、Kindle版のある方のページのリンクを貼っておきます。
講師は英語話者だが、日本語の通訳者がついており、Zoomの同時通訳機能を使って、参加者の方で聴きたい言語(英語 or 日本語)を選んで聴くことができるようになっていた。この通訳の方がすばらしく、通訳を待って話のスピードが遅くなるという体験はほぼしないで済んだ。また、アギレルゴコンサルティングの川口さん(id:wayaguchi)が共同トレーナーとして臨席されており、参加者からの質問に対して補足説明を加えるなどしてくださって理解の助けになった。
研修の内容について
「チーム全体」で品質を考える
タイトルに「Agile Testing for the Whole Team」にあるように、研修のコアメッセージは「品質のことをチーム全体で考えよう」というものだったと思う。ここでいうチームとは「デリバリーチーム」であり、役割としてはテスター、開発者に加え、プロダクトオーナーのようなビジネスサイドのメンバーも含まれている。このメッセージは研修を通じて一貫したもので、当日に行ったワークショップでもPO、開発者、テスターというそれぞれの観点に立って意見を出してみるとしばしば促された。
個人的には一番関心があった部分。『実践テスト駆動開発』(通称GOOS)は読んだが、実務ではATDDは取り入れておらず、BDD(Behavior Driven Development)やSBE(Specification by Example)は概要を知っている程度で本は未読だった。
講師はATDD(Acceptance Test Driven Development)が最も包括的な用語だとして説明していた。ATDDといえばGOOSで、GOOSは技術的な側面にフォーカスした本なので、自分の理解も(『テスト駆動開発』付録Cの表現を借りると)「外側のループ」をTDDに足したものという捉え方をしていたのだが、この研修では自動化の前段階で、チーム全体で共通認識を作り、ストーリーのスコープを把握するためのものとしての側面を重視していた。