@Odd Rune: Ja man klarer seg langt med basic unix-verktøy! Kjekt å være i stand til å bruke hele spekteret fra gnu verktøyene, videre opp i scriptspråk, videre opp til Java/C# for de “virkelig tunge løftene”.

Siden det nå var et unix-system Quick ‘n dirty regex, men til sånne jobber så duger det.

Jeg har ikke fått testet dette selv, men så en demo av det på JavaZone i 2009 og presentasjonen ligger her: http://files.looplabel.net/scripting.javazone.2009.anders.sandvig.pdf

Foreslo dette som en løsning på en brukerhistorie i prosjektet jeg jobber i, men desverre tok frykten overhånd og man endte med å bruke databasen til konfigurasjon og å fortsette med ren Java.

Når oppgavene ikke kan forenkles mer, kan noe av kompleksisteten flyttes til et annet ledd. Dvs hvis vi gjør operativsystemene litt smartere og it-systemene litt smartere blir det færre ting brukerne må huske på.

(Å kjøre integrasjontester som pirker på en database manuelt ved siden av Infinitest er heller ikke spesielt artig)

Men når denne type problemer har blitt løst, enten ved bedre test-organisering eller ved smartere verktøy, tror jeg alle oppegående utviklere kommer til å ha autotesting som en sentral del av sin verktøykasse. Fem år, topp!

Når det gjelder “enklest mulig arkitektur” er det vel få som er uenige i det. Spørsmålene vi alle bør stille oss (kanskje på Sterias Arkitektskole) er “hva er enklest?” og “hva er vi villig til å ofre for å gjøre det enklere?”

Brukervennligheten i programvaren er sannsynligvis det område hvor vi kan få størst gevinst med minst arbeid. Vi jobber ofte med en relativt god lag-seperasjon mellom forretningslogikk og den visuelle presentasjonen av informasjon, men vi feiler ofte å utnytte denne muligheten til å endre på grensesnittet. Kan være mange årsaker til det, det er ofte veldig kostbart å gjøre opplæring av nye funksjoner i større organisasjoner – tenker man derimot at alle ansatte sparer 5 minutter hver dag og får mer positiv energi av et program som er enklere å bruke, vil nok det regnskapet fort gå opp. Takk for kommentar!

Et annet aspekt er at forretningsmodellene gjerne er forskjellig mellom leveranse av en driftstjeneste og leveranse av en utviklingstjeneste. Det kan ofte virke som en driftsleverandør får best økonomisk resultat ved å gjøre minst mulig arbeid og at en utviklingsleverandør får best økonomisk resultat ved å gjøre mest mulig arbeid. Dette gjør noe med hvordan virksomhetene ledes og dermed noe med kultur og individuell adferd i respektive miljøer.

Det er spesielt morsomt med smidig-oppgaven. I en periode virker det veldig sannsynlig for observatørene at gruppen ikke vil stabilisere seg, før det plutselig “klikker”.

Takk for at du skrev en beskrivelse på dette.

Jeg ville lagt til et punkt relatert til det siste avsnittet. “Market thyself”: Det er nyttig å kunne både markedsføre spesifikke ting man jobber med, samt bygge sin egen “merkevare” over lengre tid. Uansett hvor mye kunnskap man har om de riktige tingene så hjelper det ikke dersom man ikke klarer å selge/markedsføre kunnskapen og arbeidet sitt til andre.

En liten gåte: Hva er forskjell på virus og anti-virus? Du kan bli kvitt virusen.

Vi hadde én feil i april (og noen endringer som vi klassifiserte som feil). Det viste seg at i deler av applikasjonen tok vi feil av kredit og debet. Her hadde vi ikke avstemmet nok med produkteier. Det som var litt bittert var at vi visste egentlig at vi ikke visste nok om hvordan kontoføringen skulle fungere. Så noe glapp. Nå har vi fiksa prosessen.

Det viste seg også at for å “forenkle” logikken hadde vi satt “-beløp” i metoden som opprettet en regnskapspost. Dette var fordi i det første caset vårt skulle beløpet vi fikk fra bruker inn postes med negativt fortegn. Når vi senere jobbet med regnskapsføring forvirret dette oss voldsomt inntil vi trakk negasjonen litt nærmere brukergrensesnittet.

Moralen: Kode som er litt funksjonell vrien bør ha så få skjulte mekanismer som mulig.

“Dersom man får en for streng tolking av sitt eget rammeverk, så mister man den pragmatiske tilnærmingen.”

Dette gjelder alle. Og jeg lurer på om problemet ikke er rammeverkene, men PERSONENE som gjør disse fortolkningene. Dette skyldes nok i stor grad også den økende graden av spesialisering vi ser i bransjen. Det er veldig lett for oss å grave oss ned i et fagfelt og dermed få skylapper. Den beste medisinen jeg kjenner mot dette er å jobbe i tverrfaglige team og stadig bli påminnet om HVORFOR og HVEM vi lager produktene for. Det er overraskende ofte vi peker på best practice og glemmer hvem vi lager systemet for. Er ikke det paradoksalt?

Det handler også om det gamle modsætningsforhold mellem udvikling og drift og de idealer, som over årene er opstået i begge lejre. Modsætningsforholdet stikker således dybere end ITIL versus SCRUM etc.

Efter mine erfaringer kan modsætningsforholdet delvis elimineres ved at den enkelte organisation analyserer og beslutter, hvilken tilgang, der bedst passer til organisationen:

- Modernistisk tilgang, der tror på, at det er muligt at forudsige og dermed planlægge fremtiden og rationelt designe, teste, implementere og evaluere løsninger og systemer. I et modernistisk perspektiv bliver frameworks som ITIL let idealmodeller, som organisationen mere eller mindre følger slavisk med nødvendigt bureaukrati til følge. Man glemmer let at ITIL skal tilegnes (adopt) og tilpasses (adapt).

- Socialkonstruktivistisk tilgang, der tror, at det vigtigste er at have klare fælles opfattelser og praksisser i organisationen. Ændringer opfattes som subjektive sociale konstruktioner, der kun lykkes hvis man har en fælles opfattelse af f.eks. koncepter og terminologi. Derfor hører man ofte i denne type organisationer udsagnet, at “det vigtigste, vi har opnået med ITIL (eller andre frameworks) er en fælles begrebsforståelse”. Da ændringer er subjektive, kan man ikke forudsige udfaldet af disse på lang sigt, hvorfor de socialkonstruktivistiske organisationer bekender sig til iterative, løbende forbedringer med udgangspunkt i eksisterende praksisser a la LEAN. Frameworks som ITIL bliver opfattet som inspiration for begrebsafklaring og løbende iterativ forbedring.

- Postmodernistisk tilgang, der tror, at det reelt ikke er muligt at sige noget om fremtiden end sige styre den. Virksomheder er komplekse organismer, der ikke kan styres, men som højst kan påvirkes gennem narrativer, tematisering (italesættelse, iscenesættelse etc.), ko-konstruktion og med-konstruktion, communities of practice etc. Best practices som ITIL opfattes som historier eller myter, der kan italesættes og dermed føre til ændringer i organisationen, med et minimum af bureaukrati.

Jeg kender til virksomheder, der har opnået gode resultater gennem alle tre tilgange – men absolut også virksomheder, som har haft fiasko med de samme tilgange.

Jeg tror derfor, at det som organisation er vigtigt at erkende, hvilke grundlæggende antagelser organisationen hviler på, da tilgangen som oftest viser sig at være mere vigtig end selve det framework, man tager udgangspunkt i. Sagt på en anden måde: Jeg tror ikke, at ITIL eller SCRUM i sig selv fører til succes eller fiasko. Det kombinationen af organisationens kultur, de valgte best practices og den valgte tilgang, der afgør udfaldet.

Men her er kanskje også noe av stridens kjerne: Smidige metoder er opptatt av lav formalisme i kommunikasjonen og hyppige endringer. Dette oppfattes ofte til å være i strid med ITIL sine prinsipper.

Er det faktiske forskjeller på hva erfaringen fra god utviklingspraksis og hva ITIL foreskrive?

Noen kjente og kolleger jeg kjenner tyr altfor ofte til unskyldninger og “blame-game” (er det min feil at IE ikke respekterer standarder? Er det min feil at prosjektleder ikke har opplyst meg om den forretningsregelen?). Tenk så latterlig, unødvendig og uprofesjonelt det i grunnen er..

Dere har et ydmykt forhold til feil, og det er bra! Å vise frem sine bugs er ydmykt, lærerrikt, ærlig og viser respekt for kunden.

Det er et veldig sentralt og viktig tema Ole-Vidar trekker frem her. Med økt utbredelse av både ITIL-rammeverk og Scrum-praksiser får man ofte en kollisjon mellom svært ulike paradigmer: det ene taler først og fremst planmessighetens og stabilitetens sak, mens det andre ønsker størst mulig albuerom for kreativ og spontan utvikling. Disse kunne har levd godt og lykkelig side om side hvis man så på dem som nettopp henholdsvis ytre rammer og retningslinjer for hva man slipper ut i test- og produksjonsmiljøene fra et ITIL-perspektiv, og spilleregler for det praktiske systemutviklingsløpet fra Scrum-perspektivet. Men når man lar dem få bli til urokkelige dogmer og ideologier, og forsøker å presse paradigmet sitt over på alle andre, blir det trøbbel.

De fleste kan forstå at det er ønskelig å beslutte handling først når man har dypdykket i en problemstilling og å kunne produksjonssette og tilby et produkt til en kunde så raskt som mulig, slik smidige metoder prediker. Men hva er hjelpen i det hvis ikke omverdenen klarer å henge med? Hva når kundene opplever oppgraderinger av programvaren vedkommende ikke rekker å utnytte fordi varselet om at det kom til å skje noe kom for brått på? Slike endringer er helt OK når det dreier seg om enkle webtjenester. Men når en leverandør endrer sine grensesnitt uten å gi samarbeidspartnerne tid til å justere på sine, kommer vel ikke tjenestene kundene fullt ut til gode før det har gått en del tid uansett?

Men som Ole-Vidar peker på: det andre perspektivet blir like ille: når en leveranse eller oppgradering blir liggende i månedsvis i pipeline fordi det må igjennom et meget rigid og tidkrevende endringsregime, blir også kundene av tjenestene skadelidende.

Nå har vi fått Smidig-veileder for PS2000-kontraktsstandarden, et stort og viktig skritt for å gjøre de merkantile sidene av smidigprosjektene mer solide. Hvem kan ta nå på seg å lage Smidig-veileder for ITIL-rammeverket? Eller er det noen som er i gang allerede?

En ting som jeg er rimelig sikker på er at den enkleste, kanskje sterkeste men ihvertfall den med “most bang for the buck” metoden for innovasjon er “challenge assumptions”! Masse overraskende innsikt å hente der, for ikke å snakke om ideer.

Og med det må man jo begynne med semantikken, der ligger mye “assumptions” bakt inn – en billig og grei metode.

Takk for tilbakemeldingen!

Jeg er kjent med – og enig i – din bredere forståelse av prosess. Det smidige manifestet bruker derimot “prosesser” i betydningen “forhåndsbestemte rutiner og prosedyrer”. Manifestet oppsto som en reaksjon mot de den gang etablerte, beskrevne forhåndsdefinerte prosessene for hvordan man skulle kjøre prosjekter (som typisk innebar masse planlegging og spesifisering før man begynte å lage noe som helst av det man egentlig skulle lage). Og selv om smidige metodikker i stor grad er bygget rundt noe som likner dine tanker om “barely repeatable processes”, så har man (hvem nå dét er) fortsatt å bruke den snevrere definisjonen av prosess.

Ord er viktige, utviklingen av kunnskap er avhengig av utviklingen av ord og deres meningsinnhold. Det smidige manifestet er et historisk dokument som har 10-årsjubileum neste år, med ord og meningsinnhold knyttet til sin tid. Kanskje det er på tide å endre forståelsen av “prosess” for å få nye innsikter?

Og så får jeg vel tillate meg å linke til http://thingamy.com/ siden du – kledelig beskjedent og dannet – lot være å linke dit selv

ikke hver dag jeg er her (men kommer gjerne oftere nå – så det Smidige Manifestet var nytt for meg.

Noe jeg umiddelbart reagrete på, som også jeg tro har betyding for kunder, og det var den smale implisitte definisjonen av “prosess”:

“Individer og samspill framfor prosesser og verktøy” – individer og samspill er jo prosess, sekventiell eller paralell jobbing, så lenge ikke “prosess” forståes smalt som rigid og forhånds bestemt. Prosess kommer man ikke unna og den kan godt være av en slik art at “prosess medlem bestemmer neste aktivitet utifra situasjon”. Dette er den mest vanlige type prosess der folk er involvert (omtrent 60% eller mer av WW GDP) og den trenger et rammeverk like mye som de lineære, forhånds satte prosessene. Dog et rammeverk type “elveleie” og ikke “rørgate”

Hvis prosess inkluderer denne mest vanlige typen så burde den paragrafen vært annerledes. Samme gjelder for “Å reagere på endringer framfor å følge en plan” idet den og implisitt anser prosesser som lineære og forutbestemte med eventuell “endringer/avvik”.

Hvis prosess ble definert som nevnt, at den ikke altid er frohåndsbestemt med krav til inngrep fra prosess medlem, da vil kunde og prosess medlem lettere forstå hva som skjer og hva skal skje med klar oversikt over hvilke punkter i prosessen der retningsendring er forventet.

Her er noe gammel kinesisk eller japansk visdom som jeg hørte for noen tiår siden:

“La all din tale gå gjennom tre filtre: 1. Er det sant? 2. Er det godt? 3. Er det nødvendig? Hvis noe ikke kommer gjennom disse filterne, så vær taus.”

Jeg syntes dette var bare SÅ bra! Den gangen. I dag synes jeg dette er totalt rubbish. Snakk med hverandre, og gi tilbakemeldinger. Ingen blir rikere av taushet, og ingen blir klokere.

Bakgrunn for spørsmålet finner dere her:
http://blogg.ergogroup.no/2010/01/13/praktisk-bruk-av-yammer-i-bedriften/

Og ikke minst mine bloggposter vedr Yammer her:
http://securitynirvana.blogspot.com/2009/12/yammering-about-security.html

og mitt svar til @henriksen (Ergo) her:
http://securitynirvana.blogspot.com/2010/01/yammering-reply-to-henriksen.html

mvh.
Per Thorsheim

Her er et innlegg som handler om internkulturens betydning for sosiale medier:
http://www.kjokkenfesten.no/2010/02/23/sosiale-medier-og-internkultur/

Men jeg er helt enig; synlighet kan bare være positivt. Så lenge kostnad ikke får prioritet fremfor kvalitet (kost bør være en akseptert konsekvens av fokus på kvalitet), er det bare sunt tror jeg.

Tanken er at det sikkert er mange som er der jeg var. Dessuten er det stimulerende å fortelle om hva man har oppdaget, og gjennom å skrive om det får man bearbeidet tankene bedre, sånn at man sementerer det man har lært.

This post was mentioned on Twitter by ramyo: Jeg og @jhannes har blogget om fordommer rundt smidig og brukervennlighet: http://bit.ly/brSH1D...