Customer Connected Engineering (CCE) is a practices we use across our patterns & practices teams for engaging customers throughout the life cycle. We involved customers during the planning, development, and release of our deliverables. This is a draft slide set that shares how we do Customer Connected Engineering inside patterns & practices, including our key practices and guiding principles.
One of the most effective approaches I've found for chunking up a project for incremental value is using a Scenario and Feature Matrix. Scenarios are Your Rows, Features are Your Columns A Scenario and Feature Matrix organizes scenarios and features into a simple view. The scenarios are your rows. The features are your columns. You list your scenarios in order of "MUST", "SHOULD", and "COULD" (or Pri 1, 2, and 3) .. through vNext. You list your features by cross-cutting and vertical. By cross-cutting, I mean that feature applies to multiple scenarios. By vertical, I mean that feature applies to just one scenario. It helps to think of scenarios in this case as goals customers achieve.
The Agile Architecture Method is a way to bake quality into the life cycle. It's also an iterative and incremental approach for architecture and design. In its simplest form, it's a way to help you identify potential hot spots against your prioritized scenarios. The hot spots are key engineering decision. The main hot spots are cross-cutting concerns, such as data access, exception management, logging ... etc. and quality attributes, such as security, performance, reliability ... etc.
One of the best ways I've found to map out a problem space is to create what I call, "Scenario Frames." I call them scenario frames because they are an organizing frame of scenarios. Simply put, they're a set of one-liner stories or scenarios organized by categories. The beauty of a scenario frame is that it can contain macro-level or micro-level scenarios and, because it's a tickler list, it's easy to traverse.
A few folks have asked me about Axiomatic design. I figure an example is a good entry point. An associate first walked me through axiomatic design like this. You're designing a faucet where you have one knob for hot and one knob for cold. Why's it a bad design? He said because each knob controls both temperature and flow. He said a better design is one knob for temperature and one knob for flow. This allows for incremental changes in design because the two requirements (temperature and flow) have their independence. He then showed me a nifty matrix on the board that mathematically *proved* good design.
12Page 1 of 2