Everything is a bug
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.
Tags: bug
>Jag begriper inte det där med att du skulle vilja ha id på ärendena i ett ärendehanteringssystem som “ett löpnummer + datum” …låter ju inte klokt i skallen. I Bugzilla (och Mercury TD) kan du lägga in en personlig variabel som ska gälla alla dina ärenden och det får du sätta till vad du vill, du även skriva regler för hur den variabeln skall sättas automatiskt osv. Men att begränsa ett helt ärendesystem till att omöjligen kunna ta emot fler än 99 ärenden per dag är ju ren vansinne. På vilken “helpdesk” som helst får de in många många fler än 99 ärenden på en dag och även på större projekt.
Dessutom är inte “20080118.24” särskillt lätt att säga. “Sorteringsproblem 34” är mycket enklare eller “Skit det funkar inte – 12”
>> Jag begriper inte det där med att du skulle vilja ha id på ärendena i ett ärendehanteringssystem som “ett löpnummer + datum”
Det gäller bara om man inte har en databas som kan ge mig ett garanterat unikt ID. T.ex. råkar jag alltför ofta ut för att vara tvungen att använda ett kalkylblad eller svarta tavlan som ärendehanterare.
För att ha ett garanterat unikt ID gör jag då denna kompromiss.
>Men vilken DB idag kan inte garantera ett unikt id?
>> Dessutom är inte “20080118.24” särskillt lätt att säga. “Sorteringsproblem 34” är mycket enklare eller “Skit det funkar inte – 12”
Håller med. Jag hade gärna haft IDn som bloggar ofta har på inläggen, med en nyckel som är en konkatenering av rubriken.
Men ett ärende som börjar som “Ta bort gamla kunder” kan bli “Arkivera gamla kunder” och byte av unik identifierare är inte att tala om för då försvinner spårbarheten.
Det kan kanske fungera att göra en konkatenering så “Sorteringsproblem i kundtabell” får unikt id SortLemIKundEll-112″ där förkortningen ger en möjlighet att tänka tillbaka till en titel. Och när ärendet ändrar titel går man över till att bara kalla det för 112. [tack johan för den insikten/idén]
Märkligt att “ärende 112” och “kolla bug 6544” eller “kolla bug 6544, den om gridden” fungerar så bra som det gör.
Någonting som inte fungerar är att prefixa ärenden med kategori, typ b för bug och f för feature. Detta för att då är buggen en bug även om man upptäcker att den faktiskt bara var en obekvämlighet.
>>> LosManos: Det gäller bara om man inte har en databas som kan ge mig ett garanterat unikt ID.
> Johan: Men vilken DB idag kan inte garantera ett unikt id?
Excel, annat kalkylblad, Notepad, Notepad2, svarta tavlan oavsett färg, blädderblock, collegieblock, KeyNote, Kopain, baksidan av ett fönsterkuvert eller något av de andra icke-databasstödda ärendehanteringssystemen jag har använt.
Självklart skall man ha ett databasstött ärendehanteringssystem men alltför ofta finns det inte.
>Det känns fortfarade som om du blandar ihop saker och ting. Ett “ärende” i en ärendehanteringssystem borde väll (om man inte är tvingad att bygga det med assembler i ett stordator från 50 talet) ha dels ett godtyckligt namn, ett datum och ev. ett prefix(löpnummer) om du vill att namn+datum måste vara unikt.
Ta borde bort mellanslag, att använda konstlade id:n för att sortera kronologin osv…sånt hör väll ändå till det förgångna?
>Om du skriver ner ärendena i ett block kan du ändå inte sortera…kanske bör du gå över till postitlappar eller något sorts pärmsystem. Lägger du dem i en textfil så kan du enkelt sortera efter flera olika kolumner med sort kommandot (finns i unix,linux,cygwin,emacs sen för alltid)…har du använt Excell är det kanske kört och du är tillbaka på assmbler/stordator/50-talet. Mitt tipps där är att inte använda skiten.