August 10th, 2017
If I ever get around to writing The bug management system (one that works as good as for instance Stack overflow) I hope to have the bugs classified as Bohrbugs, Heisenbugs, Mandelbugs and Schrödinbugs.
Praise where praise is due.
On a side note I don’t mean a bug should be categorised into one of the types above. It should, if applicable, be tagged with one or more.
This I say because I believe a bug is not a bug but a task. Everything is a task.
Then in my stupendous system I would not call it a task but something without meaning. “radish” “kopannkaka” “thigglymijig” “kuto” “item”
January 18th, 2008
This message is repeated in English below.
Allting är en bug. Eller snarare: allting är ett ärende.
Oavsett om ärendet skapar en krasch, är fel storlek på loggan eller innebär installation av en UPS är det något som skall tilldelas människa och tid.
Min åsikt är att lägga allting i samma hög. Och med allting menar jag allting. Sedan prioriterar man ärendena och plockar från toppen. Om detta liknar valfri agil metod är det inte för att Henrik Kniberg, Kent Beck och jag har kommunicerat utan för att det är ett bra tillvägagångssätt.
Varje ärende måste ha ett unikt ID. Ett ID som inte hänger ihop med ärenderubriken. Detta unika ID måste gå att säga och skriva; jag föreslår konsekutiv numrering, 1, 2, 3…
För icke-databasssystem använder jag dagens datum följt av 01, 02, ..99 (20080118.01) för att jag brukar kunna hålla antalet ärenden idag i huvudet och har ännu inte råkat ut för fler än 99 på en dag.
Det här med en och samma ärendetyp har Microsoft Team Foundation missat. När man skapar ett ärende i det kan man välja mellan olika ärendetyper och när man har valt kan man inte ändra. TFS är konfigurerbart så man kan säkert välja bort alla ärendetyper utom en, men att det överhuvudtaget finns känns konstigt för mig.
Uppdatering: 20170810: Sedan några år kan man byta typ på ärendet i TFS.
Jag önskar mig ett ärendehanteringssystem där man får en översikt av sina ärenden mer än som bara listor med rubriker. Jag önskar mig en sorts bollar med snören emellan där man smidigt kan se vad som hänger ihop och hur mycket som påverkas om man drar i en av bollarna.
Everything is a bug. Or rather: everything is an task.
Disregarding the issue creates a crash, is the wrong image size or installation and configuration and testing of a UPS it is something that will be given a human and time.
My opinion is that everything should be in the same pile. With everything I mean everything. Then the tasks are prioritised and picked off of the top. I you, dear reader, now recognises and starts looking at your books about agile project methods this is not a coincidence. I am not saying that Henrik Kniberg, Kent Beck and I have communicated but because it is a good method.
Furthermore every task must have a unique ID separated from the title of the task. It must also be short enough to say and write – I suggest just numbering them from 1 and on as they are created. In spreadsheets and other non-database systems where I cannot track the unique key I usually use the format yyyymmdd-nn because one can probably store the number of tasks that day temporarily in the head and I have never written more than 99 issues in one day.
Looking at Microsoft Team Foundation I say that they have stumbled regarding the everything-is-a-task thing since there are several task types (In TFS a task is a special kind of task/issue/item/todo item/bug/…) and once you have chosen one type there is no going back. To their defence I have to mention that TFS is configurable and one can choose to use just one of the types. But the very existence of non-changeable issue types is strange.
Update 20170810: Since a few years it is possible to change the type of an issue in TFS.
On my wish list is an task manager where the browsing and handling of taks are outstanding. I wish of something like balls interconnected with strings and when you juggle one ball you se whatever it pulls/affects.