Tekniske temaer på Smidig 2010

[Karianne Berg]

Hei,

Jeg tenkte jeg skulle starte en egen tråd her så jeg ikke fullstendig
sporet av den forrige debatten. Dilemmaet er dette: Hvert år får vi
ønsker om tekniske temaer på Smidig, men hvert år er det disse
lyntalene som blir klart minst besøkt. Hva tror dere er grunnen til
dette? Hva kan vi som arrangørkomite gjøre for å få bedre deltakelse
på de tekniske temaene?

- Karianne

[Christin Gorman]

Hei,

Personlig drar jeg på ting som javazone for å høre tekniske foredrag, mens jeg drar på smidig-konferansen for å høre om "smidige ting". Smidig/agile handler jo tross alt om prosess, teknologi er ganske fraværende fra manifestet.  Men det betyr ikke at det ikke er viktig å velge programmerings-språk/arkitekturer/teknologi som gjør det enklere å være smidig.  Så jeg er absolutt enig i at en "teknisk" bit er viktig.

Kanskje oppmøtet hadde øket om man tydelig linket de tekniske temaene til det konferansen tross alt dreier seg om: smidighet? Forslagene Jonas Follesø kom med i forrige tråd synes jeg var veldig gode i så måte.  Man kunne kalt temaet "smidig programmering" eller et eller annet, bare for å understreke temaets relevanse til konferansen? Bare noen tanker.

 

Vennlig hilsen,

Christin

 

2010/8/18 Karianne Berg <karian...@gmail.com>

--
Du mottar denne meldingen fordi du abonnerer på Google-gruppen «smidigkonferansen».
Hvis du vil legge inn en melding i denne gruppen, kan du sende e-post til smidigko...@googlegroups.com.
Hvis du vil avslutte abonnementet på denne gruppen, sender du en e-post til smidigkonferan...@googlegroups.com.
 Hvis du vil ha flere alternativer, kan du besøke gruppen på http://groups.google.com/group/smidigkonferansen?hl=no.

[Jonas Follesø]

Jeg tror nettopp oppfatningen av at teknologi ikke er viktig i forhold til smidig, og at smidig handler om prosess er mye av grunnen til at enkelte smidige prosjekter feiler.

Ron Jeffries har poengtert dette i forhold til ting som motvirker effekten av Scrum:

"failure of the team to inspect and adapt, especially in taking on good development practices such as found in XP." (http://www.scrummaster.com.au/Article.mvc/detail/48)

Jeg tror mye av grunnen til at Scrum ble så populært er nettopp fordi det var enkelt å forstå (i alle fall prinsippene) uten å måtte forholde deg til tekniske ting - og dermed noe som var lett å selge til mellomledere/prosjektledere.

Alistair Cockburn snakket i Agile 2009 keynoten om hvordan forrige ti-år har handlet om agile, mens neste vil handle om craftsmenship.

Christian har et godt poeng i forhold til JavaZone. Nå har jo også .NET miljøet fått en skikkelig konferanse (NDC) med gode tekniske foredrag. Men jeg syns likevel vi ikke skal spore helt av den tekniske delen og glemme at vi faktisk skal levere kjørende kode til slutt, og at prosessen i seg selv ikke er det viktigste.

Responding to change er punkt 4 i manifestet - og her tror jeg det er langt viktigere å ha en endringsvillig kodebase og teknologi stack (med automatisk testing og deployment) er langt viktigere enn hvilken prosess man har for håndtering av endringsønsker.

Jeg liker temaet"smidig programmering" - selv om vi har brukt ord som "smidig utvikling" generelt om utviklingsprosessen, så tror jeg at å bruke ordet "programmering" setter fokus på teknikken. Andre forslag kan være "smidige teknikker - mer enn prosess", "smidig programutvikling", "endringsvillig arkitektur og kodebase".

I tillegg til å finne en god tittel burde man og ha en god beskrivelse av temaet slik at de som foreslår foredrag vinkler presentasjonene sine opp mot smidig prinsippene, og ikke holder rene teknologidemonstrasjoner av typen "sjekk hvor kult HTML5 er". Om dette og kommer tydelig fram i programmet tror jeg også flere vil stikke innom de tekniske foredragene for å lære om hvordan teknologi også er viktig for å oppnå smidighet.

- Jonas

2010/8/18 Christin Gorman <christi...@gmail.com>

[Jonas Follesø]

Beklager - mente selvsagt Christin og ikke Christian :-|

- Jonas:)

2010/8/18 Jonas Follesø <jo...@follesoe.no>

[Filip van Laenen]

Er ikke saken også at det kommer mye mer prosjektledere og andre ledere til Smidig som ikke er så opptatt av programmeringstekniske aspekter i forhold til smidighet? Mange av dem har ingenting å gjøre på de tekniske foredragene, med mindre de får et akutt nostalgi.

Filip

Op 18-08-10 14:08, Karianne Berg schreef:

[Karianne Berg]

Mange gode innspill her, håper flere vil komme med sine meninger også.
Personlig tror jeg at en av grunnene kanskje er at det er en litt ond
sirkel. Folk tror at det ikke er tekniske temaer på Smidig, så de
sender ikke inn tekniske lyntaleforslag, og de mest "tekniske"
menneskene drar ikke på Smidig, siden de ikke synes det angår dem. Men
metodikk angår jo oss alle, mener jeg! Og programmering er en viktig
del av metodikk, selv om den har blitt satt litt i baksetet med Scrum.

Filip: Mitt inntrykk er at det er en overvekt av utviklere på Smidig,
selv om det absolutt er endel prosjektledere også.

- Karianne

2010/8/18 Filip van Laenen <f.a.va...@ieee.org>:

[Anders Sveen]

Synes teknisk absolutt er en undervurdert del av smidig og at en del prosjektledere burde får høre mer om det. Selv om det kanskje kan være vanskelig å få de dit. :)

Hvordan skal du være endringsdyktig dersom enhver refactoring tar en hel sprint? Hvordan skal du være smidig hvis utviklerne ikke tør å gjøre endringer i sentrale komponenter? Absolutt noe mange av PMene burde få høre og. Man kan ikke kjøre på og presse igjennom "enkleste løsning" hele tiden hvis de skal ha mulighet til å tilpasse seg senere.

For min del er en viktig vinkling hvordan vi skal få forklart dette og synliggjort det. Kanskje det kan rettes mot smidige systemer og arkitektur som flere andre har nevnt?



Anders,

2010/8/19 Karianne Berg <karian...@gmail.com>

--
Anders Sveen
http://blog.f12.no - http://twitter.com/anderssv

[Ole Morten Amundsen]

"Jeg bryr meg kun om at dere leverer, jeg bryr meg ikke om kodekvalitet og fancyschmancy løsninger", sa en prosjektleder til meg en gang.

Spørsmål og oppfatninger som dette er ganske vanlig tror jeg, og det er svært viktig at vi som fagpersoner, vi som lever av å lage og levere systemer, får trening i å svare og utdanne ignorante økonomer med forenklede virkelighetsoppfatninger.

Så, hvordan svarer man på dette på en god måte?

En kommentar til kommentaren.
Kommentaren sitert vitner om total mangel på forståelse av systemutvikling. Kodekvalitet gjør at du holder høy hastighet over tid, ikke bare høyest fart til den umiddelbart nærest stående leveransen. Elegante løsninger kan spare mange månedsverk.

Jeg synes det er svært vanskelig å forklare viktigheten av kodekvalitet til "amatører". Hva ville du svart?

Ole Morten Amundsen

2010/8/19 Anders Sveen <and...@f12.no>

[Tarjei Huse]

Hmm, etter å ha brukt ~5 timer på å rydde i pom filer etter at jeg måtte oppgradere en haug med ting til Spring 3, så har jeg lyst å stille spørsmålet:

Hvordan skal en takle magi?

De fleste rammeverkene ender opp med å være magiske. Enten det er Maven, Hibernate, Spring eller Symfony  - noe magi er det et eller annet sted. Hvordan skal en unngå at magien ta overhånd men samtidig klare å ta ut de store gevinstene disse løsningene gir?

Finnes det noen store fallgruver en kan unngå?

Litt av problemet her er at dette er en diskusjon som fort kan splitte seg inn i veldig små detaljer i enkeltløsninger (f.x. ikke bruk en global foreldremodul i Maven), samtidig som til en viss grad er det nettopp de tingene som er viktige.

Kansje en kunne ha delt diskusjonen opp i en innledning og forslag på twitter el noe sånn at en kan samle tipsene et sted til slutt?

T

-- 
Regards / Med vennlig hilsen
Tarjei Huse
Mobil: 920 63 413

[Jonas Follesø]

Kunne til en viss grad forstått om en slik kommentar kom fra en kunde, men fra en prosjektleder i et IT utviklingsprosjekt er jo helt hårreisende og vitner om total mangel på forståelse for hvilke prosjekter de leder.

Uansett, jeg ville prøvd å se på det som en mulighet snarere enn en hindring. Det er jo en ren ansvarsfraskrivelse fra prosjektleder, og en mulighet for utviklingsteamet selv å definere _hvordan_ de skal levere.

Så jeg ville svart noe ala:

"Greit - da tolker jeg det slik at du ikke legger føringer på hvordan vi jobber, eller hvilke teknologier vi bruker, så lenge vi tar ansvaret og klarer å levere. Det betyr og at vi må kutte ned på møter og prosesser som ikke direkte hjelper oss som utviklingsteam til å levere."

Så det kommer jo egentlig tilbake til selvorganiserende team og hvor ansvarsbevisst den enkelte utvikler er.

2010/8/19 Ole Morten Amundsen <ole.morte...@gmail.com>

[Ole Morten Amundsen]

2010/8/19 Jonas Follesø <jo...@follesoe.no>

Kunne til en viss grad forstått om en slik kommentar kom fra en kunde, men fra en prosjektleder i et IT utviklingsprosjekt er jo helt hårreisende og vitner om total mangel på forståelse for hvilke prosjekter de leder.

Uansett, jeg ville prøvd å se på det som en mulighet snarere enn en hindring. Det er jo en ren ansvarsfraskrivelse fra prosjektleder, og en mulighet for utviklingsteamet selv å definere _hvordan_ de skal levere.

Så jeg ville svart noe ala:

"Greit - da tolker jeg det slik at du ikke legger føringer på hvordan vi jobber, eller hvilke teknologier vi bruker, så lenge vi tar ansvaret og klarer å levere. Det betyr og at vi må kutte ned på møter og prosesser som ikke direkte hjelper oss som utviklingsteam til å levere."

Takk for forslaget! Men.. :)
Slo PL deg som typen du kan si slikt til? Han går mer i verdensmester-kategorien. Da kan man ikke være arrogant eller nedlatende tilbake. Se for deg at du er eneste innleid konsulent i et slikt miljø (kultur). Nei, her trengs andre metoder. Hva?

Ikke et lurespørsmål, jeg har faktisk ikke anelse om hva som er best, min løsning var å fordufte.
-Ole Morten

PS: Må vel legge til at javakoden ikke var objektorientert, at man ikke skrev tester (egen etter-prosjekt aktivitet) og at smidig var useriøse greier. Da får du et kulturinnblikk.
 

[Christin Gorman]

Jeg ville svart noe som:

Jeg skjønner akkurat hva du mener, og det er bra du ikke legger deg opp i tekniske avgjørelser, men lar de tekniske avgjørelsene være opp til de som har peiling på slikt. Men jeg regner med at du vil at det vi leverer skal fungere bra, og at våre leveranser skal kunne fortsette å komme regelmessig i fremtiden. For å få til dette, er vi faktisk nødt til å kvalitetssikre arbeidet vi gjør.  Akkurat som i alle andre bransjer.  Du er en proffesjonell prosjekt-leder, og jeg er en proffesjonell utvikler, du passer på at vi leverer, og jeg passer på at arbeidet er godt utført.

 

-c

 

 

2010/8/19 Ole Morten Amundsen <ole.morte...@gmail.com>

"Jeg bryr meg kun om at dere leverer, jeg bryr meg ikke om kodekvalitet og fancyschmancy løsninger", sa en prosjektleder til meg en gang.

[Ivar]

Etter min mening er teknikse verktøy en viktige elementer i smidige i
utviklingsprosjekter.

Ting som:
- Versjonskontrollsystem
- Kontinuerlig bygging, testing (automatisk) og integrasjon
- Verktøy som bistår med refatorering
- Byggestystem (f.eks maven)

Klarer vi oss uten dette, samtidig være smidige og tåle hyppige endringer??

Ivar

2010/8/19 Christin Gorman <christi...@gmail.com>:

[Filip van Laenen]

Jeg regner med at han ikke brukte fancyschmance verktøy som PowerPoint og Microsoft Project for SINE oppgaver? Uansett så er jeg bare glad han er en IT-prosjektleder, og ikke en pølsemaker…

Filip

Op 19-08-10 10:19, Ole Morten Amundsen schreef:

[Christin Gorman]

Nå skal jeg kverulere litt her.

Jeg ser faktisk ikke noe galt i kommentaren fra prosjektlederen i det hele tatt. Er det virkelig full krise om prosjektlederen ikke interesserer seg for de tekniske detaljene? Det er jo tross alt bare DET han sier.  Man trenger ikke tolke sitatet i verste mening.  Når det kommer til stykket ER det prosjektlederens oppgave å passe på at ting blir levert i tide. Det er VÅRT ansvar, vi som vet hva kodekvalitet betyr, å passe på at kvaliteten er god.  Jeg synes nesten det SKAL være en liten konflikt mellom prosjektleder og arkitekt.  Det er sunt, så lenge det er balanse i forholdet og de to respekterer hverandre. Men dette innebærer også at vi må respektere prosjektlederen.  Hvis prosjektlederen ikke er interessert i å høre om hvordan vi kommer frem til leveransene, så burde vi slutte å informere ham.  Kanskje det at han til stadighet blir informert om tekniske løsninger han ikke forstår, er det som gjør ham vanskelig å ha med å gjøre. Kanskje det får ham til å føle seg dum, og at han dermed blir defensiv.  Ikke alle kan forstå seg på programmering. Jeg synes det er helt fantastisk når de som ikke kan noe holder seg utenfor. Det motsatte er mye verre: folk som IKKE har peiling på det de snakker om, men som insisterer på å styre de tekniske (fancy-schmancy) avgjørelsene likevel. 

 

- kverulerende Christin

2010/8/19 Filip van Laenen <f.a.va...@ieee.org>

[Ole Morten Amundsen]

2010/8/20 Christin Gorman <christi...@gmail.com>

Nå skal jeg kverulere litt her.

Jeg ser faktisk ikke noe galt i kommentaren fra prosjektlederen i det hele tatt. Er det virkelig full krise om prosjektlederen ikke interesserer seg for de tekniske detaljene? Det er jo tross alt bare DET han sier.  Man trenger ikke tolke sitatet i verste mening.  Når det kommer til stykket ER det prosjektlederens oppgave å passe på at ting blir levert i tide. Det er VÅRT ansvar, vi som vet hva kodekvalitet betyr, å passe på at kvaliteten er god.  Jeg synes nesten det SKAL være en liten konflikt mellom prosjektleder og arkitekt.  Det er sunt, så lenge det er balanse i forholdet og de to respekterer hverandre. Men dette innebærer også at vi må respektere prosjektlederen.  Hvis prosjektlederen ikke er interessert i å høre om hvordan vi kommer frem til leveransene, så burde vi slutte å informere ham.  Kanskje det at han til stadighet blir informert om tekniske løsninger han ikke forstår, er det som gjør ham vanskelig å ha med å gjøre. Kanskje det får ham til å føle seg dum, og at han dermed blir defensiv.  Ikke alle kan forstå seg på programmering. Jeg synes det er helt fantastisk når de som ikke kan noe holder seg utenfor. Det motsatte er mye verre: folk som IKKE har peiling på det de snakker om, men som insisterer på å styre de tekniske (fancy-schmancy) avgjørelsene likevel. 

 

- kverulerende Christin

du kverulerer ikke, jeg setter stor pris på alle innspillene :) Jeg er enig i at det er bra med en PL som ikke har peil, men lar utviklerne ta avgjørelsene (redesign, refactoring, etc) bestemme. Men det skjer vel oftere at dette ikke er tilfellet?

Du kan heller ikke anta at alle utviklere er enige heller, ikke alle skriver tester, følger DRY eller andre gode praksiser og synes det er tull. Ja, det er vår plikt og ansvar, det er vel her "software craftmanship" kommer inn, men alle er ikke like interesserte som deg og meg, og enda flere er redde for forandringer.

Det jeg tror jeg er ute etter, er en elevator pitch for hvorfor kodekvalitet er viktig. Hvordan viser kodekvalitet seg på budsjettet og leveransetidspunkter?
Hvordan kan vi øke fokus på kodekvalitet og selvutvikling?
Jeg er overbevist om at det viser seg på bunnlinja, men det er vanskelig å kvantifisere.

-ole morten
 

[Ivar]

Etter min knappe erfaring har jeg kommer frem til følgende:
"God kodekvalitet koster mer på kort sikt men betaler seg tilbake på
lang sikt. Dårlig kode kan være lønnsomt på kort sikt, men koster mye
mer på lang sikt."

ivar

2010/8/20 Ole Morten Amundsen <ole.morte...@gmail.com>:

[Ole-Marius Moe-Helgesen]

Det er flere spørsmål som dukker opp rundt dette.

- Hvor god kvalitet er lønnsomt sett hele kodebasens levetid under ett?
- Er det situasjoner der det er riktig å ha full fokus på kortsiktig
lønnsomhet og ignorere kodekvalitet helt?
- Mange utviklere virker å like bedre å jobbe i miljøer med fokus på
høy kvalitet. Hvordan settes verdien på dette?
- Er argumentasjonen for lønnsomheten av kvalitet egentlig
vikarierende argumenter fra utviklere fordi de gjerne vil jobbe i
miljøer der kvalitet har høy fokus?

Dette har vel blitt diskutert mye, men er uansett et spennende tema.
For Open Space kanskje?

Ole-Marius

2010/8/20 Ivar <ivar...@gmail.com>:

[Christin Gorman]

Ja, i enhver konflikt/diskusjon må en huske på at det er mulig at det er en selv som tar feil. 

Ryanair er populært selv om de har null service. Vil du gi god service til dine kunder, er Ryanair feil arbeidsgiver for deg.  Folk flytter gladelig inn i "billige" ferdighus, heller enn å bruke en formue på arkitekt-tegnede boliger designet for deres unike livssituasjon.  Folk foretrekker oftest "billigst" fremfor "best". Det er nok mye morsommere å jobbe i selskap som fokuserer på å være skikkelig gode, heller enn skikkelig billige. Men det betyr ikke at de billige firmaene ikke har livets rett.

MEN, i både fly-bransjen og bygge-bransjen er det jo STRENGE MINIMUMSKRAV til kvalitet, som MÅ følges.  Kanskje man kunne lære av hvordan kravene i disse industriene ble kjempet frem?

 

-c

2010/8/20 Ole-Marius Moe-Helgesen <ole-m...@moe-helgesen.no>

[thomasKjeldahlNilsson]

Hei,

en tanke til det opprinnelige spørsmålet - hvorfor er det få proposals
og lav deltakelse rundt tekniske lyntaler? Min teori er policy-en som
SmidigXX har hatt om at man ikke får bruke egen laptop, og bare må
levere slides istedet.

Jeg skjønner motivasjonen bak (få ting til å gli mellom hver lyntale,
mindre risk for tekniske mishaps etc). Problemet med dette er at gode
tekniske foredrag (selv om de bare er 10 min lange) ofte fordrer at
man faktisk kan VISE noe praktisk, ikke bare stå og tørrprate og vise
screenshots. Dette gjør at iallfall jeg er mindre tilbøyelig til å
både gå på (og selv levere inn forslag til) tekniske lyntaler på
Smidig-konferansen.

mvh ThomasN

[Jonas Follesø]

Godt poeng. En ide er å ha et teknisk track, hvor man utvider taletiden til f.eks 15 eller 20min, men tillater egen laptop?

Selv kjørte jeg jo en "teknisk" sesjon i fjor hvor jeg kom rundt dette problemet med å spille inn demoen min på video på forhånd, som jeg så snakket til mens den ble spilt av i slidene.

Men selvsagt balansegang, siden det let blir kjedelig om tid går bort til bytte av laptop etc.

- Jonas

2010/8/20 thomasKjeldahlNilsson <thom...@gmail.com>

--