Publications
As an Amazon Associate I earn from qualifying purchases.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Requirements |
|
"Getting the Most from a Requirements Management Tool." This white paper describes the many advantages
that requirements management tools provide over traditional specification documents, the typical capabilities of such
tools, and numerous tips for getting a high return on your investment in an RM tool. See Requirements Engineering Set #7.
"The Business Value of Better Requirements." Poorly written, ambiguous, and incomplete requirements cost software organizations a lot of wasted time and money. This white paper describes the many benefits of investing in high-quality requirements development and management processes, including a way to think about the return on investment that you can enjoy by making such improvements. See Requirements Engineering Set #7. "So You Want to Be a Requirements Analyst?" Everyone talks about "requirements analysis," but not much is said about the requirements (or business) analyst. What kind of person should do this job? What do analysts really do? What do they need to know? This article addresses these questions and summarizes some key analyst skills: listening, interviewing, analysis, facilitation, observation, writing, modeling, and more. Tips for the new analyst coming from either the technical or the user domain are also provided. "Requirements When the Field Isn't Green." Many software project involve adding enhancements to existing systems, rather than developing brand new, "green field," systems. This article describes seven principles that can guide how you apply sound requirements engineering practices on a maintenance project. "Habits of Effective Analysts." The requirements analyst plays an essential role on the software project team. Here I describe the habits, practices, and characteristics of effective requirements analysts. A list of critical skills the effective analyst must master is also included. "When Telepathy Won't Do: Requirements Engineering Key Practices." The best way to succeed with requirements engineering is to adopt known industry best practices. Eight such key practices are described in this article, helping any organization improve the way it elicits, analyzes, specifies, verifies, and manages its requirements. "Karl Wiegers Describes 10 Requirements Traps to Avoid." This article describes ten traps lurking in the requirements engineering minefield. Several symptoms that you might be stepping into each trap are presented, along with some suggested strategies for avoiding the trap or extricating yourself from it. |
Project Management |
|
"Are We There Yet?" Defining your product's release criteria is an essential part of laying the
foundation for a successful project. "It's June 30, so we must be done" isn't the
best plan. Your criteria must be realistic, objectively measurable, documented and
aligned with what "quality" and "success" mean to your customers. This article provides
many examples of how (and how not) to write effective release criteria.
"See You In Court." Too many outsourced software development project wind up in litigation. The root causes of the project failure and resulting legal conflict are often related to the project's requirements, to communication issues, or to the project management approaches used (or not used). This article presents 15 recommendations for keeping your outsourced project on track and out of court. A checklist helps you perform a health check on your project, to see if it's heading for trouble. "Good Money After Bad." Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. This article gives some tips on decision making that can help you avoid this outcome and shows how to use decision points to keep a good project moving along. "Standing on Principle." Adapted from Creating a Software Engineering Culture, this article gives many examples of high-integrity and high-intelligence interactions among managers, developers, and customers. "Creating a Software Engineering Culture." This article describes several cultural principles about software engineering that I think are important. These principles imply certain technical practices and managerial behaviors that are conducive to creating an environment focused on software quality through effective processes. |
Process Improvement |
|
"Software Process Improvement in Web Time." Basic process improvement
activities can benefit even fast-moving teams. This paper describes how Kodak's web development group undertook improvements in several
aspects of project management, post-project reviews, risk management, change control, requirements engineering, development life cycle, and peer reviews. The
approach taken and lessons learned are also presented.
"Read My Lips: No New Models!." This essay suggests that the software industry has more than enough models and frameworks for areas like process improvement, testing, metrics, inspections, risk management, and design methodologies. What we don't have is a large fraction of practitioners routinely applying these existing models in an effective way. Perhaps you'll agree with me; perhaps not. |
Peer Reviews |
|
"Seven Truths About Peer Reviews."
This article highlights seven important facts about peer reviews: peer reviews can take many forms;
inspections are a software industry best practice; there is no one true inspection method; peer reviews
complement testing; peer reviews are both technical and social activities; managers can make or break
a review program; and a peer review program doesn't run itself.
"Do Your Inspections Work?" This is a condensed overview of three ways to measure results from your inspections: efficiency, effectiveness, and return on investment. It describes several data items that you can easily collect from your inspections and some simple metrics to calculate from those data items. Inspections provide an easy way to begin a quality metrics program. "Humanizing Peer Reviews." Peer reviews are at least as much a social interaction as a technical exchange. This article addresses some of the social and cultural aspects of peer reviews, including ways to overcome resistance to the process, benefits that reviews provide for various team members, the role of management, and 10 signs of management commitment to the review process. "When Two Eyes Aren't Enough." Several different types of activities called "peer reviews" are described here, including inspections, team reviews, walkthroughs, pair programming, peer deskchecks, and passarounds. A table suggests which types of peer reviews are best suited for achieving specific review objectives. "When Reviewers Can't Meet." When participants in a peer review cannot meet face-to-face, you need to use distributed or asynchronous review techniques. This article describes several ways to deal with reviewers who are separated by space or time. "Seven Deadly Sins of Software Reviews." This article describes 7 common ways that technical reviews go wrong. Symptoms of the problem, and suggestions for getting the review back on track are also presented. Copyright © 2023 Karl Wiegers. All rights reserved. |