| Issue Tracking | KEVIN RESCHENBERG
01-03-2005 |
Happy New Year!
I still have a bottle of PeopleSoft-label champagne (!) that hasn't
been opened. I guess it's about time, isn't it?
Do you have a good issue tracking system? If you do any PeopleSoft development
at all, you need one.
Your system could be anything from a purchased package to freeware to an in-house-developed
system to an Excel spreadsheet. It could include workflow and object management
(such as that provided by the Stat product), or it could be just a list of
changes. Your needs are determined by the level and scope of development, the
size of your PeopleSoft support group, the frequency of changes, your security
and migration policies, and other factors.
At a minimum, the system should allow all members of the support group to enter
and review the list of changes. It should be a permanent record—that is, once an issue
has been resolved, it should not be deleted from the list (unless no objects
were changed). It should capture the name of the person who requested the change,
the name of the primary developer, a clear description of the request that will make
sense even a year later, the reason
for the request, and the associated dates. There are, of course, many other things
that you could track, but beware of overloading the system with too many types of
information—they will be ignored. Ideally, the system should be easy to use and flexible.
Take care to determine the major purposes of the system. Do you have a large support group
and many fast-moving issues? You'll probably need workflow. Do your projects tend
to be large development efforts? Look into project management features. Are the developers
separated from the functional users or testers? Clear communication of the requirements
is important.
Documentation is essential, but don't pile on too much. For example, don't store code
in the issue tracking system if it isn't responsible for migrating objects. Out-of-date
documentation is worse than none.
A good issue tracking system will help you maintain control over your development
environments, assign and track work, do upgrades, research system problems, comply with
Sarbanes-Oxley requirements...the list goes on and on.
Next week I'll discuss linking the issue tracking system with objects so that you can
track changes in both directions—to and from the objects.
|
