| |
| |
About the Authors | |
| |
| |
Preface | |
| |
| |
| |
Introduction | |
| |
| |
| |
The Touchstones: Lean and Agile | |
| |
| |
| |
Lean Architecture and Agile Feature Development | |
| |
| |
| |
Agile Production | |
| |
| |
| |
The Book in a Very Small Nutshell | |
| |
| |
| |
Lean and Agile: Contrasting and Complementary | |
| |
| |
| |
Lost Practices | |
| |
| |
| |
What this Book is Not About | |
| |
| |
| |
Agile, Lean - Oh, Yeah, and Scrum and Methodologies and Such | |
| |
| |
| |
History and Such | |
| |
| |
| |
Agile Production in a Nutshell | |
| |
| |
| |
Engage the Stakeholders | |
| |
| |
| |
Define the Problem | |
| |
| |
| |
Focusing onWhat the System Is: The Foundations of Form | |
| |
| |
| |
Focusing onWhat the System Does: The System Lifeblood | |
| |
| |
| |
Design and Code | |
| |
| |
| |
Countdown: 3, 2, 1. . . . | |
| |
| |
| |
Stakeholder Engagement | |
| |
| |
| |
The Value Stream | |
| |
| |
| |
The Key Stakeholders | |
| |
| |
| |
Process Elements of Stakeholder Engagement | |
| |
| |
| |
The Network of Stakeholders: Trimming Wasted Time | |
| |
| |
| |
No Quick Fixes, but Some Hope | |
| |
| |
| |
Problem Definition | |
| |
| |
| |
What's Agile about Problem Definitions? | |
| |
| |
| |
What's Lean about Problem Definitions? | |
| |
| |
| |
Good and Bad Problem Definitions | |
| |
| |
| |
Problems and Solutions | |
| |
| |
| |
The Process Around Problem Definitions | |
| |
| |
| |
Problem Definitions, Goals, Charters, Visions, and Objectives | |
| |
| |
| |
Documentation? | |
| |
| |
| |
What the System Is, Part 1: Lean Architecture | |
| |
| |
| |
Some Surprises about Architecture | |
| |
| |
| |
The First Design Step: Partitioning | |
| |
| |
| |
The Second Design Step: Selecting a Design Style | |
| |
| |
| |
Documentation? | |
| |
| |
| |
History and Such | |
| |
| |
| |
What the System Is, Part 2: Coding It Up | |
| |
| |
| |
The Third Step: The Rough Framing of the Code | |
| |
| |
| |
Relationships in Architecture | |
| |
| |
| |
Not Your Old Professor's OO | |
| |
| |
| |
How much Architecture? | |
| |
| |
| |
Documentation? | |
| |
| |
| |
History and Such | |
| |
| |
| |
What the System Does: System Functionality | |
| |
| |
| |
What the System Does | |
| |
| |
| |
Who is Going to Use Our Software? | |
| |
| |
| |
What do the UsersWant to Use Our Software for? | |
| |
| |
| |
Why Does the UserWant to Use Our Software? | |
| |
| |
| |
Consolidation ofWhat the System Does | |
| |
| |
| |
Recap | |
| |
| |
| |
"It Depends": When Use Cases are a Bad Fit | |
| |
| |
| |
Usability Testing | |
| |
| |
| |
Documentation? | |
| |
| |
| |
History and Such | |
| |
| |
| |
Coding It Up: Basic Assembly | |
| |
| |
| |
The Big Picture: Model-View-Controller-User | |
| |
| |
| |
The Form and Architecture of Atomic Event Systems | |
| |
| |
| |
Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring | |
| |
| |
| |
Documentation? | |
| |
| |
| |
Why All These Artifacts? | |
| |
| |
| |
History and Such | |
| |
| |
| |
Coding it Up: The DCI Architecture | |
| |
| |
| |
Sometimes, Smart Objects Just Aren't Enough | |
| |
| |
| |
DCI in a Nutshell | |
| |
| |
| |
Overview of DCI | |
| |
| |
| |
DCI by Example | |
| |
| |
| |
Updating the Domain Logic | |
| |
| |
| |
Context Objects in the User Mental Model: Solution to an Age-Old Problem | |
| |
| |
| |
Why All These Artifacts? | |
| |
| |
| |
Beyond C++: DCI in Other Languages | |
| |
| |
| |
Documentation? | |
| |
| |
| |
History and Such | |
| |
| |
| |
Epilog | |
| |
| |
| |
Scala Implementation of the DCI Account Example | |
| |
| |
| |
Account Example in Python | |
| |
| |
| |
Account Example in C# | |
| |
| |
| |
Account Example in Ruby | |
| |
| |
| |
Qi4j | |
| |
| |
| |
Account Example in Squeak | |
| |
| |
| |
Testing Perspective | |
| |
| |
| |
Data Perspective | |
| |
| |
| |
Context Perspective | |
| |
| |
| |
Interaction (RoleTrait) Perspective | |
| |
| |
| |
Support Perspective | |
| |
| |
| |
Bibliography | |
| |
| |
Index | |