Process ToolsVisual Studio Team System enables you to choose and adapt a process that suits your team environment. Process authoring and customization tools helps in tailoring the process to blend best practices and tune it based on team experience.
Process Guidance Team Blogs
Become a Fan of p&p summit!Become a fan of p&p summit on Facebook by clicking here . We have a fan drive going on right now to get 250 fans by June 30th. If we hit that number, one lucky fan will ge... moreTuesday, Jun 23
I am a PC and have Windows 7 RC installedI got my primary machine loaded with Windows 7 RC this past Friday. Had an issue with multiple monitor but a video driver upgrade took care of it. I am liking it so far. If yo... moreTuesday, May 5
HowTos for VSTSQ: How to delete a Work Item Type on TFS.
A: You can delete a Work Item Type on TFS 2008. You’ll need to use the Power Tools. There is a DestroyWITD command.
... moreWednesday, Feb 6
Implementing SOX with TFSI touched on this topic on a previous post in December, when I mentioned that Andrew Delin from the VSTS Process team was working on a comprehensive whitepaper to be delivered... moreFriday, Apr 4
| The Latest from the Forums
IT Architecture & Planning (ITAP) Advisor Anyone knows if the MSF certification would give someone an edge landing a job with Microsoft as a IT Architecture & Planning (ITAP) Advisor. Obviously, there are many other requirements for such a job, but would this help? Do you know of other certifications that might help?
Implement a Development Task, one task?This workstream is written for one task, singular but I think anyone can easily realize that many items such as design reviews can be done on multiple tasks at one time. The issue we're having is with design. It seems arbitrary to associate designing software with a single task. For instance, I may initially realize I have to build a component out of analysis as a solution to a requirement. As I get further into analysis I realize that there are a few problems to solve so I break down the task accordingly. These "solutions" will likely become a set of related classes spanning multiple tasks. Design (at least in OO) is about object responsibility and interaction. My point here is that I may have 3 tasks that needed "thinking about design" all at the same time. I'm writing about detailed design, not architecture. Unfortunatly the design activity is written in such a way that some of our developers insist design must take place on a per task basis.
My question is, is the guidance specifically trying to associate design as a per task activity and if so, for what reason? Or should it be interpretted with some flexability. Obviously we'll do what's best for us, I'm just looking to understand the original intent of the guidance.
Thanks!
Please clarify Identify Inconsistencies for REQM 1.5We're trying to understand this activity and how corrective actions, etc... could be taken. Is this activity incomplete? Should it supply some kind of checklist to look over beyond just the two reports and I'd expect it to say we create tasks for corrective actions. We may have a hard time convincing the appraiser on this one.
Looking for a Legend or guide to CMMI DiagramsThe various workstreams have a diagram associated with the process.
Although some things are fairly apparent, I hate to assume anything when making such bedrock processes.
Is there a guide to reading the diagrams? Is there an name for the diagram method?
Some things specifially, the diagrams show a given process as a large box with empty circles on the inputs/outputs of the process as well as within the process.
Some dots are black though and the meaning is unclear. Is this displayling logic, or some other signal?
Some interface dots are not within squares, but either triangles or semi-circles, do they have meaning?
I'll take any answers, but would prefer a document spelling out everything.
TIA,
Ray
Confusion about Create Solution Architecture, planning and build tracks, please clarify We see the planning tracks as stuff you do to prepare for future iterations and the build track as stuff you generally do in the iteration, even if it's just pre-launch.
Our confusion lies in where Create Solution Architecture is executed. We figure that you need requirements for architecture (of course...) but if your incrementally updating the architecture each iteration you need to know which requirements will be worked on.
Thus we came up with the idea that Create Solution Architecture might come between "Select Iteration Backlog" and the "Iteration Analysis" activities in Plan an Iteration. This however seems odd that build track activities would come before planning track activities.
Another thought is that the architecture could be based on all approved requirements regardless of whether they've been assigned to an iteration.
Please help me clarify this. If you can give an example of the activities that neighbor that workstream I'd really appreciate it.
|
| |