|
|
us bank development ticket tracking system
 |
In order to cope with the sudden onslaught
of tickets, I found I had to create my own ticket system. They had an
older version of ClearQuest, and unlike other ticket systems that you
could use as a working environment (Lockheed's MARS or US WEST's PCRM
come to mind), theirs wasn't quite up to the task. Plus, development
assignments came in from a variety of sources, not all through official
channels. So I developed a simple MS Access based system to document my
workload. Later, as I got more involved in various projects, I added the
ability to create status reports for various teams, project managers,
and to send detailed reports with a couple of mouse clicks, while my
colleagues would be scrambling through the piles of papers on their
desks in order to figure out where they were at on each project. |
 |
These tickets could be quite confusing.
They had related Rational requirements, but there was no field per se in
the ticket system to note this, so I had to make sure I created a field
to capture this information. This proved incredibly helpful when I
wanted to track down all the development work I had done against a
particular set of requirements. They tracked by percentage done, so I
did too. I captured the unit test URL, so once I got WebSphere up and
running after I rebased from stream in ClearCase, all I had to do was
click on it and I could pick up where I'd left off. I also copied and
pasted the names of the files that I touched in the course of my
development so that when WSAD crashed (as it often did), I knew where to
pick back up. |
 |
I made sure to capture such data as when
the code had been delivered to stream. That way, when another developer
or manager had a question about versioning or when changes would appear
in what build, I could say, "This fix was delivered on the 12th." Then
they'd know whether their build had the changes or not. I had various
reports; this one was an overall report showing the status of every
single ticket that was still open or recently closed since the last
status meeting. |
 |
Made a series of custom reports for each
project. The project managers found it incredibly helpful that they got
such detailed status on their issues in a timely manner. Using the
PTBSync utility, I set organizer alarms to go off the afternoon before
each status meeting for each project so I could generate their status
report, email it to the PM, and get back to work. This saved lots of
time. |
 |
Sometimes I was asked if I had worked on a
particular ticket number, so I made this little housekeeping type report
for myself so that I could look that up and see if I'd done it already.
In SQL Server there is a DISTINCT command; MS Access being a similar
product of course doesn't have that per se, but it does have a unique
records display function of sorts which I used here. |
 |
The problem description was taken from the
ClearQuest ticket. As I acquired more information about the problem,
subsequent emails, etc., I put that information in the Notes section.
The resolution was the only thing the PMs saw, so that was the space
where the "official" explanation of the fix went. Once I'd delivered
final status at the weekly project meeting, the ticket could then go off
my radar screen. |
 |
I made a helpful little utility that
brought up all the recently closed tickets so that I could mark the
issues as "off the radar screen" once status had been given in their
respective project meeting. Then these tickets would no longer appear in
my reports, obviating the need for creating reports by date. The
development ticket cycle was too fitful to try to pin fixes down by
dates. |
|
