Most of the organizations in today's world have some legacy software or systems. With pressures coming from outsourcing and cost-cutting, new applications are constantly being added to existing IT frameworks. In most cases, it is risky to completely replace the existing systems. As a result, most places have complex applications and systems frameworks. In order to achieve a successful coexistence of several applications on different platforms and technology architecture, teams are faced with some major questions, such as "Should we interoperate or integrate?"
Successfully persuading others to adopt your point of view is a matter of neither magic nor luck. It's a skill and like any skill, improvement takes know—how, opportunity, and practice. In this column, Naomi Karten offers pointers to help you strengthen your persuasion skills.
This article describes how you can ensure better test coverage through traceability and team reviews.
In this article, the author provides a guideline comprised of seven steps involved in the entrance and exit criteria process for system testing. It is not enough to state the criteria within the Master Test Plan. Rather, you must actively participate in defining the activities associated with meeting the criteria, drive towards its successful completion and manage risks if and when they arise. Examples are also provided so that you can tailor them to your specific project.
When attempting to adopt best practices we often can't see the forest for the trees. We can see what we are doing wrong, but how will that help us to see what to do right? In this article, we will discuss a few common Lean Anti-Patterns. Anti-Patterns are commonly recurring practices that are counter productive. We call them quot;Leanquot; Anti-Patterns because these anti-patterns result from violating Lean principles. Lean principles form the basis for Scrum practices. Looking at how Lean Anti-Patterns violate lean principles gives us insight into how we need to modify our practices to be more effective.
Traditionally, we think about projects is in termsof scope, time, cost, quality, human resources, communication, and risk. Thisway of thinking mainly originated in industries other than software development.It fits software development projects poorly, because these projects are mainlyabout people's abilities.
Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.
Because so much of what we do in software and project management is abstract, metaphors are particularly important communication tools. When I heard Peopleware author Tim Lister describe reducing project scope as "throwing cargo overboard," I adopted it immediately. If you are worried about getting to port on time with the fuel available, consider throwing low-value or optional cargo overboard; your voyage might still be considered an overall success.
Scope creep, also known as feature creep, is a common project killer. It is critical for a project manager to know how to effectively manage this situation when it occurs. In this article, Darren Levy explains how to tackle scope creep in ten easy-to-follow steps.
As delivery cycles get shorter, rapid test techniques are gaining in popularity. In this article, Sridhar Kasibhatla and Andrew Robins explore the concept of using coverage maps and test notes to support exploratory testing and concurrent test design. These maps and test notes also are used to review and track test coverage and can help document dynamically generated test cases for future re-use.