If you're using CMMI as a religion, you're using CMMI wrong.
If CMMI is causing you more problems than it's worth, you're using CMMI wrong.
If ALL of your projects are generating a huge paper trail, you're using CMMI wrong. (Choose better "focus projects" for your appraisal.)
If CMMI is stifling innovation, you're using CMMI wrong.
If CMMI makes you focus on principles developed elsewhere instead of your business objectives, you're using CMMI wrong.
If CMMI isn't helping you improve your product quality, you're using CMMI wrong.
If CMMI isn't helping you, you're using CMMI wrong.
But that comes as no surprise. Most companies seem to be using CMMI wrong.
CMMI is a tool. If you hold it right, if you swing it right, if you have enthusiastic people skilled in using it, the tool can give you good results.
If you inflict the tool on reluctant people who don't have any experience in using it, you will likely get really bad results.
You should only use CMMI if you're serious about improving your software engineering processes. Don't blindly chase arbitrary numbers or timetables. Use it in ways that help you and don't use it in ways that harm you.
CMMI prompts you to think about which of your projects should use best practices from industry, like using requirements tools and bidirectional requirements traceability. You should use some of these practices on some projects, and you should avoid their use on other projects.
If you give your UML to your QA folks, they can do a better job at Validation. If you only give them your "shall" statements from DOORS, about all they can do is Verification.
The INCOSE Tools Database Working Group (TDWG) has a Requirements Management Tools Survey:
http://www.incose.org/productspubs/products/rmsurvey.aspx
The responses are self-reported by the tool vendors, but they appear to be mostly accurate.
This survey could help you choose between requirements management tools to help you find one that will fit your needs and your business style.
I'm a father of three and a college professor teaching computer programming, and I've found that Scratch is a very good "language" for teaching programming. It shows programming concepts such as looping, variables and interfaces in an immediately accessible and kid-friendly manner. It includes multimedia and event-driven programming capabilities. It uses the best features of immediate feedback of success and visible results to encourage exploration and fun.
Programming in Scratch helps kids
start simple and do complicated things later
create an animation for telling a story, playing an interactive game, or a video to share on the web
jump right in and understand the basics like variables, loops, arrays, etc, without getting bogged down in an over complex or restrictive language
learn to program by diving in and doing it
impress their friends
During the directed learning that takes place in a Scratch-oriented curriculum, the teaching team can introduce another programming language to show how syntax-oriented programming languages can perform the same tasks as the graphics-oriented systems. Any programming language can serve as that second language.
I find it a bit ironic that the best language for teaching programming languages isn't a language at all.
This is yet another example of a person introduced to a new technology who uses it unwisely. This will only become more common as more fools get newer, more powerful toys.
Can you think of other examples? I'll bet you can.
Slashdot Mirror
If you're using CMMI as a religion, you're using CMMI wrong.
If CMMI is causing you more problems than it's worth, you're using CMMI wrong.
If ALL of your projects are generating a huge paper trail, you're using CMMI wrong. (Choose better "focus projects" for your appraisal.)
If CMMI is stifling innovation, you're using CMMI wrong.
If CMMI makes you focus on principles developed elsewhere instead of your business objectives, you're using CMMI wrong.
If CMMI isn't helping you improve your product quality, you're using CMMI wrong.
If CMMI isn't helping you, you're using CMMI wrong.
But that comes as no surprise. Most companies seem to be using CMMI wrong.
CMMI is a tool. If you hold it right, if you swing it right, if you have enthusiastic people skilled in using it, the tool can give you good results.
If you inflict the tool on reluctant people who don't have any experience in using it, you will likely get really bad results.
You should only use CMMI if you're serious about improving your software engineering processes. Don't blindly chase arbitrary numbers or timetables. Use it in ways that help you and don't use it in ways that harm you.
CMMI prompts you to think about which of your projects should use best practices from industry, like using requirements tools and bidirectional requirements traceability. You should use some of these practices on some projects, and you should avoid their use on other projects.
If you give your UML to your QA folks, they can do a better job at Validation. If you only give them your "shall" statements from DOORS, about all they can do is Verification.
The INCOSE Tools Database Working Group (TDWG) has a Requirements Management Tools Survey: http://www.incose.org/productspubs/products/rmsurvey.aspx The responses are self-reported by the tool vendors, but they appear to be mostly accurate. This survey could help you choose between requirements management tools to help you find one that will fit your needs and your business style.
Scratch!
Programming in Scratch helps kids
During the directed learning that takes place in a Scratch-oriented curriculum, the teaching team can introduce another programming language to show how syntax-oriented programming languages can perform the same tasks as the graphics-oriented systems. Any programming language can serve as that second language.
I find it a bit ironic that the best language for teaching programming languages isn't a language at all.
Tyson gets my vote, too, but my kids like: Bill Nye the Science Guy, Beakman (from Beakman's World), Alton Brown.
The next MacGyver should be played by Ellen Page.
This is yet another example of a person introduced to a new technology who uses it unwisely. This will only become more common as more fools get newer, more powerful toys. Can you think of other examples? I'll bet you can.