Articles in the patterns & practices Category
Headline, patterns & practices »
This post is a write up of how we do Customer-Connected Engineering on the Microsoft patterns & practices team. Our Customer-Connected Engineering process has been a key part of our success and impact in the software industry. While this write up is about how patterns & practices implements Customer Connected Engineering, you might find that you can tailor and adapt some of the principles for your scenario or context.
patterns & practices »
The Microsoft patterns & practices team has been around since 2000. The patterns & practices team builds prescriptive guidance for customers building applications on the Microsoft platform. The primary mission is customer success on the platform. As part of that mission, patterns & practices delivers guidance in the form of reusable libraries, in-tool experiences, patterns, and guides. To put it another way, we deliver code-based and content-based guidance.
On the Microsoft patterns & practices team, we use Vision / Scope as a key milestone. It’s where we frame the problem, identify the business opportunity, and paint a vision of the solution. It’s a forcing function to get clarity on the customer, their scenarios, and our scope for the project. We generally use a “fix time, flex scope” pattern, so this means having a candidate backlog that we prioritize with customers.
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.
Design, User Experience, patterns & practices »
I think of a persona as a specific (yet generalized) instance of a role to “personify” and represent what users that play that role, might be like. While we originally argued over the details of the personas, a great by-product was that we focused on the distinctions across our various customer sets. This helped reduce ambiguity during product design. It also helped us make calls on where to put our resources and effort.
Featured, patterns & practices »
This post is a walk through the halls of our Microsoft patterns & practices team workspace.
Ward Cunningham among others was a big influence early on in making it happen. The patterns & practices team workspace is optimized for agile development practices. The workspace features writeable walls, configurable workspace, speaker phones, projectors, focus rooms, and a customer room.
I took the pictures about a year ago. Some things have changed, but the key things are still the same. I arranged the pictures as a lap through the halls to make it …
Featured, Lessons Learned, patterns & practices »
I’ve been a part of the Microsoft patterns & practices team for several years. I’ve shipped a lot of things and learned a lot of stuff. Here’s a distillation of some of my key lessons learned. I’m leaving myself room so that I can expand or elaborate on some of the points downstream.
Top Ten Lessons
Here’s my favorite lessons at a glance:
Win the heart, the mind follows.
Know the tests for success.
Fix time, flex scope.
Use the system to educate.
Work with the right people, on the right problems, making the right impact.
Have the …
Frames, Process, patterns & practices »
One of my earlier projects on the patterns & practices team at Microsoft was originally called Life-Cycle Practices. Later, I renamed it to Life-Cycle Templates. Finally, I settled on Engineering Practices. Engineering Practices became a key organizing theme for our work and served as the foundation for our ALM frame.
Knowledge AreasThe Engineering Practices Frame uses the following categories to organize software development knowledge.
Requirements and Analysis
Architecture and Design
Notice that the top buckets map to disciplines while the bottom buckets (Security Engineering and Performance Engineering) map to quality attributes. …
patterns & practices »
This is one of my favorite figures that shows how we do solution engineering in patterns & practices at Microsoft:
It all starts with a scenario. It has to be a meaningful problem. You can’t evaluate an architecture in a vacuum. In order for us to build useful baseline architectures, we need to pick the right scenarios that flex the right engineering decisions.
Patterns are simply problem and solution pairs. In our case, we tend to focus on application, architecture or solution level patterns.
Baseline architectures are skeletal applications. They’re just …