Software Engineering, Project Management, and Effectiveness
When I ramp new folks on the team, I find it helpful to whiteboard how I build prescriptive guidance. Here's a rough picture of the process:
Examples I've used the same process for Performance Testing Guidance, Team Development with Visual Studio Team Foundation Server, and WCF Security.
Here's a brief explanation of what happens along the way:
Design The dominant focus here is identifying candidate problems, candidate solutions, and figuring out key risks, as well as testing paths to explore. The best outcome is a set of scenarios we can execute against.
Execution The dominant focus here is product results. It's scenario-driven. Each week we pick scenarios to execute against.
Release We produce a Knowledge Base (KB) of guidance modules and a guide. The guidance modules are modular and can be reused. The guide includes chapters in addition to the guidance modules. Here's examples from our WCF Security Guide:
Agile Publishing We release our guidance modules along the way to test reactions, get feedback and reshape the approach as needed.
Stable Reference Once we've tested and vetted the guidance and have made it through a few rounds of customer feedback, we push the guidance to MSDN.
My Related Posts
I'm testing another version of the home page on Software Guidance Share. Software Guidance Share is a perpetual work in progress. I think of it as my quick-and-dirty guidance KB for developers and solution architects. I continuously refactor information into reusable nuggets. I also test ways to browse the guidance and find relationships among the nuggets.
Here's a couple of example scenarios:
I haven't fleshed out some of the areas, but the Wiki gives me a lot of flexibility and it's easy to course-correct. In other words, it's more adaptable than adapted.