|
Metrics That Matter: Making Measurements Meaningful for Everyone Metrics are only worthwhile if you review and use them. Do your quality reports go directly from the inbox to the trash can? A quality metrics program can be a great asset to your organization. Engineering, sales, and the company overall can benefit from having such a program. This article will help you explore ways to make measurements meaningful outside of QA.
|
|
|
QA Consciousness Raising Change is hard, but leading your managers and co-workers toward higher quality needn't be dull and dreary. In this article, author Lisa Crispin explains several techniques you can use to take your organization to the next level, including gauging your visibility and recruiting a quality champion.
|
|
|
Project Archaeology This article aims to show you the rich variety of information that can be used to help you build a good model of the system you are involved with. Some of the areas covered are: the business context; the language; the organizational structure; the culture; and cross-departmental relationships.
|
|
|
Focused Improvement Improving processes takes planning, time, and effort. A formal improvement project that applies the best practices of development to process improvement can help focus your team and effect real and lasting change.
|
|
|
A Baker's Dozen of Dirty Words III offers alternatives to thirteen commonly misused terms and phrases, including walkthrough, quality assurance, phase, O-O analysis, maintenance, function, and estimate.
|
|
|
The Two Faces of Quality Lina Watson questions the conflicting views of quality assurance and describes the distortions that can occur between software process realities and their perceived image in the corporate world.
|
|
|
Faults of Omission Brian Marick is obsessed with faults of omission in software code, and he thinks you should be too. In this Bug Report, Marick describes coding omissions, design omissions, and requirements omissions, and offers some ways to prevent (or at least test) them.
|
|
|
One Size Does Not Fit All For all of the effort we've made in the software field to find the best methodology, the best programming language, the best operating system, the best set of tools, even the best process maturity model—the search for the "best" is often futile. Robert L. Glass urges you to not be confined by a software approach that doesn't match your specific needs.
|
|
|
The Spirit of the Times Brian Marick points to Web resources and email lists that help keep you current with software and computing trends.
|
|
|
Learning from Pathfinder's Bumpy Start Steve March discusses problems experienced by the Mars Pathfinder. He imparts the following lessons: 1) design defensively in the face of complexity; 2) design defensively for post-shipment problems; and 3) beware of best cases.
|
|