>This message will be repeated in english.
Jag har haft turen att jobba med bra folk. Testa det.
Bra beslut som ifrågasätt av bra människor ger ett ännu bättre resultat.
I have hade the luxury of working with good people. Try it.
Good decisions that are questioned by good people gives an even better result.
>This message will be repeated in english
Ibland händer det att ett projekt går över tiden eller blir fördyrat av annan orsak. Då måste man göra något.
(Efter man har skurit bort dokumentationen och ner på testningen) letar man efter funktionalitet att ta bort; men vilken?
Jag vill dela med mig av tanken “Ta bort funktionalitet men inte värde.”
Exempel: Kunden vill kunna välja på flera roller för varje användare som kan logga in. Värdet behålls om man kan be kunden logga in som olika användare istället (username_adm, username_op, username_reader).
Detta är inte alltid tillämpbart eftersom vi försöker ta bort funktionalitet som inte tillför något värde. Men tanken finns där.
Sometimes a project goes over budget. Then you have to do something.
(After cutting away documentation and down on testing) one looks for functionality to remove; but which?
I want to share the thought “Remove functionality but not value.”
Example: The customer wants to be able to log in with one user but then to choose from several roles. Functionality is cut but value is kept if the customer is persuaded to logging in with several users (username_adm, username_operations, username_reader).
This is not alwasy doable since we have gotten quite good at removing functionality that is not needed. But the though is still there.
>This message will be repeated in english.
<floskelvarning/>
Jag jobbade för några år sedan på ett företag där ledningen hade läst en bok och nu skulle “platta till organisationen”. Det startades ett förändringsarbete och efter ett knappt år var vi nere i 2,5 lager istället för de 3 vi hade tidigare.
Vi var tydligen platta nog.
Men… koncernchefen var inte koncernchef för att han var full av dåliga idéer. Han kanske såg mer då än jag. Något jag förstår först nu. Som ingen av oss förstod då.
Gör en wiki-analogi där allting ligger på samma nivå men man länkar fram och tillbaka beroende på behov.
Jag har hittat en artikel som lättfattligt beskriver detta. Artikeln har dessutom den fördelen att den har bra rubriker och lättläst text så den är lätt att skumma.
Om du tänker mer i “projekt” än “organization” byt ut orden.
http://www.eu.socialtext.net/wikinomics/index.cgi?the_wikified_organization
<buzz word warning>
I worked some years ago at a company where the management had read a book. So we were to “flatten the organisation”. The wagon was set rolling and after less than a year we were down to 2,5 layers instead of the 3 we had earlier.
We were obviously flat enough.
But… the top dog was probably not top dog because he was full of stupid ideas. He probably saw more than I. Something I understand now. Something none of us understood then.
Make a wiki analogy where everything is on the same level but the links back and forth create the patterns.
I have found an article about this. Besides begin easy to read it has good headlines so it is skimmable.
If you think more of “project” than “organization” just exchange the words.
http://www.eu.socialtext.net/wikinomics/index.cgi?the_wikified_organization
>This message will be repeated in english.
Jag har hittat en artikel om Agile projekt som är kort nog att hinna läsa och oteknisk nog att förstå även om man inte är utvecklare.
Den passar alltså att ge till folk som inte förstår teknik men ändå inte gillar agile.
I have found an article about Agile projects that is short enough to be readable and lacks tech talk to allow non-developers to understand it.
Alas it is fit to be sent to people who don’t understand technique but is still against or reluctant to agile.
>This message will be repeated in english.
En artikel med en skiss på hur länge man skall debugga. Ibland skall man lämna buggen innan man har hittat den.
Detta hänger bra ihop med min syn på bug/ärende-hanterare. Skriv ner buggen/ärendet och lämna det till någon – vem som helst som kan ta buggen/ärendet vidare och fortsätt med det du jobbade på när du hittade buggen. Nu ligger buggen/ärendet i listan över saker att göra och någon kommer prioritera den.
Märk att om du däremot skall rätta buggen så skall du ta reda på orsaken och inte bara rätta symptomen.
An article with a sketch of how far you should debug. Sometimes one should leave the tracking before the bug is found.
This corresponds well with my view of how a bug/issue-manager should work. Write down the bug/issue and leave it to someone else. Now the bug/issue is in the list and it will be prioritised.
Note that if you are supposed to fix the bug you have to fix the very cause and not only the symptoms.
From the article:
“…stops debugging it and files the bug. He doesn’t dig into the implementation itself to see where the memory leak is happening. He never gets to the exact cause. But, what he has done is find somebody to assign the bug to, and then he moved on…”