Trying to weed through all the marketing driven releases from MS is not an easy task, but in the end it is something that always needs to be done.
In this blog I discuss DNA, SOA, Software Architecture, VB.NET, CMMI, Agile Development - Doing what Microsoft does, not what they say to do…
I would like to know if you are going through the same problems
Doing what Microsoft does, not what they say to do… DNA, SOA, Software Architecture, VB.NET, CMMI, Agile Development
Sher J
Good Feedback Arnon. Makes sense. MCS guys were always trying to push MSF onto our projects. Never have seen it implement to where it helped a project, so I usually make the projects switch to UP, or a scaled down RUP that I take over, which tried to use MSF. It was just too wide open and didn't have the guidance needed to successfully be implemented. It always caused a ton of confusion among those that have never implemented a formal process prior to trying to use it.
Your right CMMI guidance will help, maybe as an introduction, but I will stick with SEI for CMMI guidance on my real projects that need to be CMMI compliant. My last gig the CMMI team lead refused to even open it. I haven't looked at the Agile implementation for 2 weeks now to see if they have improved that, but the shape the templates were in will cause a ton of confusion and they aren't very usable.
I have heard the office team used SCRUM and are planning on helping put together an instance of that. It may be worth looking at.
As I have said in some of my blogs, I would like to see them put togther a Product Line Engineering MSF process guidance template, since that is the heart of their Software Factory movement. But only after they have implemented it, and only if they plan on putting it together completely with asset templates that are usable.
Jules730
Steve Kelly has added some relevant thoughts to my original blog on this topic on his blog here.
willis
I like MSF 4 much better than I did MSF 3 - MSF 3 always seemed to me too vague to be of real value . MSF 4 on the other hand is more reasonable, and supported by tools - which I think makes it viable when you are required to have a plan driven (vs. Agile) process.
The point with CMMI is that it is only a framework and not a process (that's why, for example, SCRUM can be (for the most part) CMMI 3 ) - so you still need to come up with a process to implement it. Also, as far as I know, Microsoft is working with SEI to make sure MSF 4 will be compliant (at least that's what I understood from David Anderson when I was still working for MS)
MSF 4 Agile, is more of a lightweight process than it is an agile one (i.e. it is not as agile as XP or SCRUM are)
Regarding SCRUM and team System - take a look at http://blogs.conchango.com/howardvanrooijen/archive/2005/11/16/2401.aspx
Arnon
Bob Morley
Blackice
A little more confusion from the Marketing Machine.
http://realworldsa.dotnetdevelopersjournal.com/vbnetcsharp.htm
Sorin Varzaru
As far as I know MSF originated from MCS rather than the product groups (at least up to version 3) so it was based on experience with regular IT applications and not MS products.
Regarding MSF for CMMI improvement - While Microsoft doesn't really have motivation to comply with CMMI ) many organizations (esp. ones working with government agencies) do have to comply with CMMI (usually level 3 or better). The fact that Microsoft produced tool support for complying with that can, in my opinion, make life easier for vendors and is a step in the right direction.
Arnon
GopinathK
As for 'Doing what Microsoft does' I guess I will try that if I ever get around to developing office tools, operating systems or compilers. For now I'm mainly doing IT projects and thats not exactly MS's specialty...
Doc Bodkins
Interesting topic. I had the feeling that the MSF has some sort of "holes" after reading Steve McConnel's books, but I never could define specifically what are these holes, because I am not an expert of the MSF and I didn't read it deeply.
After reading this topic, I asked my Microsoft budy about the development practices in microsoft, and this was his reply:
Our development practices differ amongst groups. The group I’m from (MSN adCenter) has very traditional development practices, where the program management comes up with a functional specification which is reviewed with Developers and Testers. After that, the Developers write the Technical Specification Document (implementation details, ideas), get it reviewed with Test/Dev and then start coding for it. Simultaneously testers write the Test Case documents and discuss with PMs and Developers.
Development wise it’s more like a design based, bottom up schedule. But in some other groups in MS, we’re using Scrum and Agile development practices, where lot of iterative time is given to the design (called sprints) and then significantly less time for coding. It also includes pairing (30, 60 and 90 minutes), of developers who sit together to solve a common problem.