|
Another excellent article. But i'm saddened to find i arrive here over a month down the road since article 5 in the series and there's no sign of any further articles
When can i get my next fix?
|
|
|
|
|
Yes yes yes!!! Need more!
This is GREAT collection of articles. And it's free - well maybe the rest won't be
Or maybe Matt is asleep
I don't know, but I can't wait for that architectural document part.
Ozren Krznarić
|
|
|
|
|
I've just started reading this series and made my way thru part 2. Excellent living documentation of a system.
I have a question: is this issue system only designed for us software developers, or will there be other user roles as well?
I know it's difficult enough to get software developer happy when using 'self-built-system', but my boss will also use this tracking system and the sales people too and the support people, and so on...
There will be many different user roles in this kind of system. Therefore the demands of the system often are very very huge. Everybody should use it everyday for everything. The big problem is to set up the limits for the system, and having people around to accept those limits. Before starting the development. In my company (80 employees, 20 developers), we haven't succeeded with this. Therefore the solution for us today is to use such a system only for developer people. I think we have failed, if my department is the end station for this system.
Maybee this question already has been answered. Then it's enough giving me a shortcut to the answer...
As you can see I have a quite pessimistic view of own developed software for standard everyday purposes. The last really good issue tracking system I've used was inside Lotus Notes 1994 (monolithic at this time). It worked for several user roles. Big company of course.
Our company and it's traditions will tell us what systems has been introduced with good results before. Maybee it can tell us what software we can deploy tomorrow (without making revolution)?
/Håkan
------------------------------------------------
- Bachelor in systems analysis
- Systems developer, C#, Java, C, VB3-6
- DBA, database design, SQL
------------------------------------------------
|
|
|
|
|
Good Question.
At the moment it appears to be a system that will never be built.;) (Not really, I have just been bogged down with my day job, some side work and life in general. I hope to get back to this within a week.)
The simple answer:
This system should be useable by many different "roles" of users. Though not listed (as yet) as a specific line-item requirement, the customizability of the system lends itself to use by many roles of users.
The long answer:
Without a firm understanding on my part of the requirements for this system for particular roles of users, it is not possible to completely design a user-interface or use-case for these roles. Therefore, the system may be useable by various roles, but will be optimized for the use-case of a developer. The modular design of the system should allow for new UI's and tools to be added without affecting existing tools, but this is beyond the scope of version 1.0.
So, if you want to suggest a few use-cases for various roles, feel free. I'd love to hear your ideas.
Thanks,
Matt Gullett
|
|
|
|
|
Some thinkable user roles in this kind of system and what they may want to do with it:
- Support people: primary contact with the customer. Inputs most of the issues, tries to solve the easy ones on the fly. Attaches one or more customers to the issue.
- Developers, analysts. Inputs issues, often more technical ones. Does the analys of what is affected and what the consequenses will be, both functional and technical. Suggests a solution and estimate the time for it.
- Maintainance project lead: takes out "most important list" each week and walk through the items with developer lead and functional responsible.
- IS/IT responslible: Wants statistics for each project, estimated time and actual time, type of issues, various grouping and sorting. When finding som strange peaks he want's to see why directly.
I think that's the most common user's
Another thread:
Have you thought about having your own requirement lists in this kind of system? I have, a project bulding new software often have the first series of requirements well structured in documents. Then the project goes on with the implementation for 6 months, a lot of changes to the original demands has already been done because the customer has come up with new or changed demands (same thing) and the developers bring them in to save time. Then they say "we document this later to save time for our development". The new demands lies unstructured in e-mails, documents everywhere, notes on peoples desktops and even just in the head of the developer. Hmm, quite sad. If we had a good tool to take care of requirements too, projects should deliver in time more often.
/Håkan
------------------------------------------------
- Bachelor in systems analysis
- Systems developer, C#, Java, C, VB3-6
- DBA, database design, SQL
------------------------------------------------
|
|
|
|
|
How's the next (Day 6) article coming?
|
|
|
|
|
Thanks for the interest. I hope to publish day 6 and day 7 this coming weekend. I have already written them, but I have not finished reviewing and refining them.
In case you're wondering why it has taken so long, I have had a project at work that has slipped the schedule and I have had a few life events come up. I hope to get back on track starting this weekend.
|
|
|
|
|
Hello,
I just started to read your series of articles on the project life cycle and found that part 6 and 7 are not around. Were they removed from CP, or did you stop the project? In the latter case, it would be a waste of such a nice article serie, which I really enjoy...
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
[pre-submit edit] Sorry for the very long post. I developed my own thoughts while writing this down. Might all this is interesting for you, but you can find some "core results" below under "boiling this down" below[/edit]
OK, I just got caught by your "Priority issue".
(Note: I read the rest of the articles only spurious - In the following I'm usign the terms submitter, reviewer and solver loosely as roles - well aware that it can be the same person)
"Priority" is not useless, it is important. It is the parameter that tells the coder what to do first, so your projects needs to manage it.
Yet, I agree, a static priority is useless - the "real life priority" changes with reader, time, and changes in the project.
First, to take apart your ideas further -
- 2.: A wider scale just accumulates more subjective parameters (some people always crank it up to 100, others rarely go over 60 to have room for something more serious - you would have to average out the submitters "voting behavior")
- 3.: No use, and to much data. What counts is the priority for the coder the task is assigned to (this also means: reassigning a task might change the "real life priority"!)
- 4.: decaying priorities don't model reality well, and are a (counterproductive) inducement to "wait and hope the bug goes away".
Rule of thumb: For the submitter a bug must be "fire and forget". For the solver, it must be "nagging until I fix it". The task of the reviewer is to arrange the "nagginess" depending on inside and outside needs.
Conclusion: Real life priority, depending on factors that a easy-to-use system can not acquire completely, determines the position in the "work queue" of an individual solver. The Priority assigned by the submitter is merely a hint for the position in the queue.
So, indeed, it looks like what we really need is a "work queue" for each solver, that can be rearranged easily by reviewers.
(so, internally, a floating scale doesn't seem so bad, but it's nto a value to be entered)
Tracable Priority criteria
Some criteria for priority can easily be managed by an issue tracking system. Please let me first recount my own experience before coming to boiled-down conclusions (I need to write it down to sort my thoughts ). For the software I work on, I "peter-internally" assign the following criteria:
- Boss Stopper these are mostly issues that hinder in-house use of our software, i.e. co-workers (or my boss) can't continue their work because of it. This typically makes them "fix now".
- Undeliverable - we can't release with this issue in place.
- Showstopper - we can't demo our product with this. Quite overlaps with Undeliverable, but there are differences. Showstoppers that are not Undeliverable usually rank below Undeliverable, but get boosted above them before trade shows, workshops, etc.
- Major Support Issue Stuff that kind of works, but customers have problems with it and need additional support (documentation, phone, e-mail).
- Money Makers Usually new features that attract new customers, or make existing customers want to pay for.
- Happy Makers Things you think is fun, customer think it's fun, and acountants say "we don't get money for this".
- Design issues Tricky. This is usually stuff where the initial design shows a weakness (or the current implementation is horrible), but the user sees nothing of. The "fix" is often very invovled, requires extensive testing, just to make sure users don't notice. Mostly, the main concern is "if we don't fix it, it might kill us". I'd rank them barely below Undeliverable, my boss just above happymakers
- Passerby Some very simple, completely isolated, absolutely uncritical issue that I could fix and check in in the five minutes till lunch break.
OK, boiling this downi
Submitters can't know the "correct" priority of an item. Real Priority changes with date and project level decisions, and cannot be managed on an per-issue level.
Priority criteria can be split into "Major" and "Minor" criteria, each issue is characerized by a major and 0..n minor criteria.
The simple solution would be a drop-down for the major criteria, and checkboxes for the minor ones (of course the list of major and minors must be configurable). Reviewers can temporary "boost" all issues that belong to a minor category.
There is a more involved solution that would actually allow factoring in external factors quite nicely, and replace the initial priority field with something more informative: Issues belong to a Milestone, and Milestones have priorities.
Milestones could be various things: Simple Dates, Project Milestones, Code Freezes, Delivery Dates, Trade Shows, internal stuff like "before implementing the new module XYZ", or even "virtual" things like "the day when our application is so simple my grandma can use it" (a better selling use case for the latter would be: application is suitable for a new target market).
Milestones could get a a default boost by proximity. A per-issue-priority could still be used for finer categorization of the issue. If "estimated time" is carefully assigned to each issue, there can be "can't achieve milestone" warnings. etc.
If the issue tracker already implements version-specific tracking, you might already have the framework for milestone-based priorities. It might be that an issue can belong to multiple "milestones" (as they could model the "minor criteria" from above: showstopper, design issue,...). All this might require to integrate with the project management (IMO Issue tracking is very tightly coupled to project management that they either need a transparent interface, or must be integrated with each other).
Yet, I hope this gives you a clever idea that is both functional and reasonbale to implement.
OK, some other thoughts I want to get rid off
Before I understood the importance of priority, I was first thinking into a "solving a social problem by social engineering" direction. For example, you could give every submitter an account of 10..30 points, that can be spent to raise an issue above "standard priority". he gets these points back only when the issue is solved or demoted to a lesser level. The weakest point I see here is that the submitter has no incentive to set the priority correctly - it's mainly the Project Managers (reviewers) interest.
You could do this also internally, like this: e.g. you have assigned assign 0 "credits" to "normal", 1 to "high" and 2 to "critical". When the open issues of one submitter exceed a set limit (e.g. 10 credits), you scale his priorities down: with a credit sum of 15, the "high" priority would be only worth 0.67 credits, and "criticals" only 1.5
Again, this works only when submitters are interested in assigning the "best possible priority" (which they might not even know), and it might actually penaltize testers that are more effective.
Whoah. that's long...
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen
|
|
|
|
|
I've been speed reading through this series but I thought I might be able to contribute to the concept of Priority. First of all, I agree completely with the futility of the Priority field.
Having done a lot of project management and working with MS Project I found that priority is not only based on the daily "action items" but the overall project's critical path. While you could calculate the priority of a task based on where it sits in the overall project path that can sometimes be vague.
Understanding how we prioritize is key, however also understanding the scope of the task is important. Having metrics for this is where the difficulty comes in. When we receive a task, we make a quick judgement call on how long it will take, but how often to we bother to make a note of it. We often then organize them based on what we think we can get accomplished now, next or later.
If you can come up with a way to get the task owner (or fulfiller's) metrics on scope (est. work, deadline) and any precedence it may need to have then you can fairly easily derive a priority. Ultimately this can provide the capability to identify priority conflicts ... which is ultimately the purpose of labeling tasks with priority is it not? Which brings you to the bigger issue... resolving priority conflicts.
The lack of conflict resolution in any task management or scheduling software is where you tend to lose users. If I get two clients sending me high-priority tasks, I must make a decision about which one takes precedence in my workflow. It would be very helpfull if I had a tool to assist me in managing this.
Hope my ideas are beneficial in some way.
|
|
|
|
|
Just finished a Project Management course. What a treat to find this real world example, and written in such an engaging manner.
1. You pontificate on religious wars over programming language choices. What about platform: Windows, *nix, Mac, Web? You talk also about delaying specific technical choices, but seem pretty well committed to Windows. Fine. Just concerned you'll leave out web submittal/review of items.
2. Priorities. Absolute values mean little, particularly spread across projects. What one really wants to know is what order do I do things in? Maybe a drag & drop ordering of tasks? 'Course, whose priority is it? Maybe a "wideband Delphi" technique to settle on ordering? Nah, don't have that kind of turnaround time.
So rather than a subjective value, perhaps the more-or-less objective Impact (suggested elsewhere), like: Nothing works, Something doesn't work, Something doesn't work sometimes, Something doesn't work like it should, etc.
Your item 3 under priorities, "Too much work, and even more meaningless." I don't see at all. Especially glib dismissal "too much work." If anybody gets to specify priority then everbody could, and you could keep a moving average.
3. Wonder if subscription handling is appropriately part of email module.
4. Is it time to put up a project notebook? A set of links pointing to latest Requirements, Plan, WBS, etc.
5. And one of those documents might be an acronym dictionary!
6. Such flexibility in design of forms and issues types makes me wonder how the heck one can keep continuity, comparability? I've seen where users enter their own categories and wind up with a dozen variants of the same thing, such that you can't track them.
7. For the wish list: XML import/export.
Keep up the great work.
--David
|
|
|
|
|
davidqxo wrote:
What about platform: Windows, *nix, Mac, Web?
I would argue that this is a requirement dictated by the users of this system (software developers using Windows). Obviously, this does not mean that the server-side software must be windows, nor does it mean that there cannot be a web component. In-fact, the reason for having a state and persistince server is to abstract the data management away from the client. This would allow for easy development of a web application.
davidqxo wrote:
perhaps the more-or-less objective Impact
Definitely this is better than priority.
davidqxo wrote:
Your item 3 under priorities, "Too much work, and even more meaningless." I don't see at all. Especially glib dismissal "too much work." If anybody gets to specify priority then everbody could, and you could keep a moving average.
I disagree. Priority is inherently subjective and allowing the proliferation of the subjectivity does not make it more objective. Also, doing so requires work on the part of the user to make a decision as to what the priority is and unless the value is temporal in someway, it just increases the meaninglessness. Questions arise such as "Should user A be able to see the priority set by user B?". "What priority prints on reports?" Questions like that make me very hesitant to consider such a feature.
davidqxo wrote:
. Wonder if subscription handling is appropriately part of email module.
Good question. I think what I have in-mind is much simpler than what you may be thinking. What I want is for other apps (ie. Agent service and SPS) to get instant (quasi-instant) notifications that new mail has arrived. This would expedite the user workflow. That is the extent of this feature, nothing sophisticated. At its simplest, this could be a named synchronization event.
davidqxo wrote:
4. Is it time to put up a project notebook? A set of links pointing to latest Requirements, Plan, WBS, etc.
Great question. The answer is absolutely yes. Day 6 will be targeted at assessing the project and will have a large section called "The paper trail". I fully intend to include document templates and a complete design document for this project.
davidqxo wrote:
5. And one of those documents might be an acronym dictionary!
I think every project I have ever worked on has proliferated acronyms. Also, symantics are important in a project since the difference between a "prospect" and a "lead" can be quite big. Acronyms, symantic word usage and jargon should all have definitions.
davidqxo wrote:
6. Such flexibility in design of forms and issues types makes me wonder how the heck one can keep continuity, comparability? I've seen where users enter their own categories and wind up with a dozen variants of the same thing, such that you can't track them.
You have a point, anytime users can add discrete values at-will, there is a great risk of duplication, ambiguity, etc. This is a big problem with most software, not because they allow the addition of new values, but because they do not. The problem swings both ways. When there are not enough discrete values, the system is either not used, or some users mentally re-define other fields, or data is lost, or the comments field becomes used for everything and other fields values become meaningless. Either way, the value of the data deminishes. (I have seen systems where people put astericks in-front of names to indicate some type of importance, but other users think asterick means something entirely different. I have also seen systems where the comment/notes field is used for everything and all other fields have NULL or default values in them.)
I see 2 major configurations. First you have configurations where a single person is the major contributor to the system. In this case, it is up to that person to maintain data integrity, but one person can typically do that. The second configuration is a team environment with no one main contributor. In this configuration there is a need for locked-down fields/value lists. This is actually a user-requirement (see day 1). One thing I see as a possibility is to still allow people to add fields, but those new fields/values are cosndiered "pending" until reviewed. Also, I believe that the system should be able to identify infrequently used fields for review.
Sorry for the long-winded response.
Thanks for the reply and comments, they are appreciated.
Matt Gullett
|
|
|
|
|
Thanks for great feedback on my feedback.
Priorities, what a mess: conflict with multiple, competing priorities, confusion over urgency versus importance.
A place where one might countenance multiple priorities: submittor assesses their issue's severity/urgency, and projects manager (could be individual) orders the work within a project and across projects.
But not to belabor the point. Too much other great, more interesting stuff going on.
--David
|
|
|
|
|
davidqxo wrote:
Priorities, what a mess
Yup. Couldn't agree more.
davidqxo wrote:
A place where one might countenance multiple priorities
I think you're right. Within a controlled workflow system you can have multiple independent priorities potentially without loosing meaning. So long as the workflows have short turnaround times.
|
|
|
|
|
First of all, I must say I enjoy reading your articles because of your style of writing. I want to express some of my concerns about some of the comments you are making in your articles and I think some new developers might think it is an OK thing to do.
First of all, using multiple languages when designing software depends on the size of the project and the client (not the end user, but the one supporting it). You cannot expect IT departments to support multiple languages because the overhead of maintaining these skills is high from management prespective. That is why IT departments tend to standarize on languages used. If someone quits or gets hit by a yellow bus, how quick can they find a replacement?
That brings my second point. Documentation and system design is a must for these companies otherwise how ca a new person come in and support it if they do not understand it. For small projects that is fine, but when you are dealing with big projects, it becomes easy to change one code somewhere not knowing the implications elsewhere.
Last concern, while it works fine for this project since it is developed for a single user by that same user (conflect of interest?), I see the project getting bigger than needed. For example, and just an example, why dynamic email accounts even came up if for a single user? was there tangable measurable benefits for the exta time to invest in such feature or was it because the user wants it? people may want the world, analysts needs to give them reality check.
fadi
|
|
|
|
|
hmmm two first of alls... thats not good...
|
|
|
|
|
Thanks for the feedback. Your concerns have been brought up before and let me say that you are exactly right.
Fortunantely, the design phase of this project isn't over yet, so there is time to recover from most problems related to documentation, language selection and scope. I have already begun working on Day 6 and the main topics of Day 6 are "The Paper Trail" (ie. documentation, doc templates, etc) and "Project assesment" which covers assessing the scope of the project, as well as addressing the realities of software development such as team development, available skills, etc.
One of my goals with this article series is to present how software is developed from front-to-back, but covering all the phases, not just the ones usually covered in books. I want to demonstrate how designs change, requirements must be addresses, scope and feature-creep must be handled, not from a manner-of-fact position, but from a practical one. All of the books I have ever read tend to take the after-the-fact approach of telling us how it should be done, but do not demonstrate the process in a realistic way. I hope to demonstrate what is a realistic and manageable process that is often misunderstood and ommited by software developers (young and old alike).
I really appreciate the feedback and would love to hear back from you on what other topics I need to cover to add realism, or address concerns.
Thanks,
Matt Gullett
PS. I hope I allied your concerns, and I really believe that you will be pleased with the next set of articles because they will be dealing with exactly what you mentioned. (Paul Watson and others have brought up these issues in previous days, but I have been delaying covering them until I felt the time was right.)
|
|
|
|
|
Your style of writing is really inspiring. I do enjoy your articles because they do show the thought process, both good and bad, that we go through when developing software.
Reading the articles and watching the project evolve triggered a panic button I always have when dealing with scope and features so I had to make sure
You are doing great work and thanks for sharing!
Fadi
|
|
|
|
|
Did you ever get any updates to this?
Or is it now dead in the water.
Trust me, being the father of 4 (oldest 2 are 5 years old), I realize life can get in the way of itself.
|
|
|
|
|
If someone quits or gets hit by a yellow bus, how quick can they find a replacement?
Well, this is always a possibility. Isn't that why managers make the "big bucks"?
|
|
|
|
|
Like the articles.
Only one concern.
You specify the RDBMS as SQL Server or MSDE.
I think it might be more useful to specify the interface method e.g. ODBC or OLE DB and any database requirements - like it has to support dynamic SQL in its stored proc's.
If specified like this the actual RDBMS doesn't matter so long as it meets the criteria.
Rest is rather long, sorry :
I wrote a simple issue tracking system years ago. It was actually simple enough that we used it on our projects .
I ended up with the same problem with priority and ended up with the last solution you mentioned - i.e. enhancement, bug, show stopper, ...
I'm not sure what paradigm the current systems use, but I used a request-action framework.
Someone would submit a request as one of : Bug, Add, Modify, Remove, Comment.
Each request would have associated with it a series of actions, the first being the submit action.
Based on the type of request and the project it was assigned to, a person was tasked with deciding who the request should be routed to – this would add an accept action.
Each action had ‘done by’ and ‘assigned to’ fields, so when one person was done with the action they would forward it to someone else until the final action was the closing of the request.
We really wanted to be able to clearly see everyone who touched the request, when they got the action and finished it. This also allowed us to follow the ping-pong path the requests took.
Here are the main categories we used :
Type of employee :
Developer - The gods themselves
User - Generic user
Tester - Special user
Support - User support
Manager - Can't complete anything, but can reassign and close … ironic
Admin - Administrator
Type of request :
Bug - Report a bug
Add - Request a new feature
Modify - Request a redesign of part of a project/function/interface
Remove - Request the removal of a feature
Comment - Make a note that doesn't require immediate action (auto closed)
Type of action :
Submit - Submit a request
Accept - Some fool has accepted the request
Assign - Assign (or reassign) a request
Complete - Complete request
Test - Test completed request (if appropriate)
Release - Place completed/tested request in a release build (if appropriate)
Close - Close request
A typical scenario might be :
User A submits an Bug request for project X, a new request record is created as well as a submit action – ‘done by’ = A, ‘assigned to’ = Mary (default based on project).
Mary (in charge of requests for project X) looks at it and sends it to John, the head developer for project X, this creates an accept action – ‘done by’ = Mary, ‘assigned to’ = John.
John gets it and assigns it to Bob, a junior developer, this creates an assign action – ‘done by’ = John, ‘assigned to’ = Bob
Bob gets it, verifies it is a bug and fixes it, this creates a complete action – ‘done by’ = Bob, ‘assigned to’ = Sally (a Q/A tester).
Sally gets the new build, tests it and it fails regression, this creates a test action – ‘done by’ = Sally, ‘assigned to’ = Bob
Bob takes another shot at it, fixes his mistake, sends it back to Sally, …
Until finally it is routed to someone who can put the change into a release build and then close the request.
...cmk
|
|
|
|
|
Once again an excellent article and an enjoyable read. You realize your preaching to the choir right? If you were saying exactly what most of us think/experience your articles wouldn't be as exciting.
Just a thought about notifications etc. Have you considered IM platforms as a possible notification method? Perhaps a client app takes a dump and automatically sends the dump report to your bug tracking application. The bug is investigated and then assigned to employee A. Employee A could be notified that he has an issue waiting? I know email. But I had to play the b!@#$rd client that throws in a last minute request. Just a thought. Maybe next version?
subliminal message: gaim, gaim, gaim. Gaim has the (some) answers.
--
"The money power of the country will endeavor to prolong its rule by preying upon the prejudices of the people until all wealth is concentrated in a few hands and the Republic destroyed."
-- Abraham Lincoln
|
|
|
|
|
Damn Pesky Users!
Great idea. I guess this could be done by just extending the agent service. I intend (as the article states) to have a plug-in interface throughout the system, so maybe I (or someone) will write just such a plug-in.
Again, really great idea.
Thanks,
Matt Gullett
|
|
|
|
|
Hi Matt,
I enjoy the reading as usual...
I think you should have a severity field aside to the priority. Developers seem to think more in terms of severity and boss, in terms of priority.
Regards,
Ernest
|
|
|
|
|
Good point. Severity is kind-of subjective, but probably better than priority.
Thanks,
Matt Gullett
|
|
|
|
|