Delay the decisions until they solve themselves or disappear. Sometimes postponing is futile and a decision has to be made. Then make it, but not earlier than that.
Sometimes one need more balls to not decide than to decide.
( And or course… not making a decision is also a decision… )
This message is repeated in English below.
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.
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.
With no information you have one task.
1) deduce the right information
With the wrong information you have to:
1) understand the information
2) find out that the information is wring
3) deduce the new information
I have an idea of how to induce communication in a project.
I really wanted to do pair programming but didn’t dare to insert it into the project due to some reasons.
After a while I noticed that even with templates to code from, people did things in their own way (naturally) and that people had different knowledge about the customer’s plans.
I then thought about rotating the tasks, like one only works with a task for 2 days and then everyone switches. This forces people to communicate (i.e. ask others what they have done) and to sync their programming styles with each other.
I never forced this though.
But if anyone have – feel free to tell me the outcome.
In my experience no task takes less than 15 minutes.
If the very work is 30 seconds the rest is still used for administration, coffe, bathroom, email, web, usenet, talk, phone, looking out the window, rereading, testing, adjusting table, moving screen, listening to song, youtube, blog, slashdot, stretching, scratching, looking at blue led, picking nails, cleaning keyboard, preparing for home going, preparing for next day, cleaning black board, moving picture in cubicle, watering plant, removing old plant, tripping over old cofee cup, looking at bird, wondering about the name of the slow disc drive for commodore 64 and humming a song that refuses to leave the brain.
This means that a maximum of 8 things are done each day.
>If you (the reader) is familiar with TQM the following three rows should be familiar:
Don’t inspect quality in.
Constantly improve the system.
Break down barriers between departments.
If you are not familiar with TQM it is perhaps the reason Japan’s industry creates things faster, cheaper and better than the west. Deming is a name to remember for this.
Now… what can we learn from this?
Don’t inspect quality in.
In a large enough project there are special testers that apply their magic when the code already is written. Wouldn’t it be nice to not write the bug in the first place?
Constantly improve the system.
When did you last look over you development method? Your debugging method? Your deployment method? There is even a book written about it called Debugging the Development Process.
Break down barriers between departments.
Does your project have “programmers”, “designers”, “architects”, “testers” and “project leaders”? Why does it? Because the need arouse or just because that is how it was done last time?
The inspiration for this article was found here.