Jeg havde nøjagtig samme oplevelse.
Gjorde skolen tydeligt opmærksom på, at min søn ikke skulle deltage. De "glemte" at sikre dette i deres håndteringen af sagen.
Efterfølgende forsøgte jeg at få slettet data, men fik et lamt svar om at det var for sent. Det var ligeledes "min" skyld...
Kunne der være en tendens der skal undersøges her?
Efter min opfattelse er deres kobling er på principniveau og ikke metoder.
De fem principper som jeg kender dem
- Identificer kundens behov
- Kortlæg værdistrømme
- Skab flow
- Introducér flow
- Stræb efter perfektion
Forskellen på de agile og "vandfalds" metoderne er, at i de først nævnte har man fokus på disse fem principper. Hvor den mere klassike model ikke har alle principperne indbygget, eller først har dem senere i processen eller slet ikke.
Jeg overvejer om man ikke burde dykke lidt længere ned og prøve at dokumentere mere præcist hvilke metoder, der har indflydelse fra hvilke andre metoder, og jeg vil ikke udelukke at jeg vil tage det emne op på et senere tidspunkt.
Kunne være super fedt at se et take på dette :)
Agile, som i det agile manifesto, har ikke sine rødder i 17 folk der satte sig i en hytte og definerede reglerne.
De står på den platform der blev lavet tilbage i 80'erne hvor Toyota udviklede en model der udkonkurerede de amerikanske bilfabrikker.
Hvis man tjekker op på det, vil man kunne genkende de principper som Agile Manifesto bygger på.
Hejsa,
Hvor er svaret på overskriften "KU-forskere vælger skyen fra: For dyrt og for langsomt"?
Der er ingen sammenligninger og man fremhæver kun 2,5miokr, uden at tage hensyn til alle de andre omkostninger ved at have et datacenter :)
Mvh Søren
Synes artiklen påpeger flere essentielle områder, som jeg også har oplevet i forskellige organisationer.
- Der er en tendens til, at Enterprise Arkitektur, er rigtig svært at definere. Set i lyset af den udpenslede vigtighed af enterprise arkitekter, er det underligt at der ikke findes en formelt adopteret definition. I forhold til ESDH casen kunne det være interessant, at se hvilken besparrelse eller ekstra omkostning det vil være at findføre et system fremfor de tre.
Der bliver efterhånden på agilitet i alle lag, men uden afkobling og autonomi er det rigtigt svært at blive agil. En samlende rolle som Enterprise Arkitekt vil have det rigtigt svært, hvis der ikke anlægges en forståelse omkring arkitetur og software som en levende organisme, som beskrevet i en anden artikel her på version2.dk
- Skygge IT anses som et problem, fordi det ikke er effektivt. Min erfaring med SkyggeIT er, at der alt for ofte opstår et monstrøst køsystem i organisationerne af en vis størrelse. Det ses ofte som issue handling, hvor IT afdelingen har Hotlines, mail support osv. til at håndtere alle de udfordringer der er med de kørende løsninger. Derudover har man "change request" systemer, som skal sikre at man kun indfører kontrollerede ændringer, så alting virker. Mit gæt er, at de fleste IT afdelinger har rigtig lange cycle tider og jeg har observeret min mængde af trivielle ændringer der er blevet blokeret i månedsvis. Den typiske reaktion i organisationer hvor IT afdelingen er havnet i en form for langsom deadlock er, at forskellige afdelinger indfører IT systemer som løser deres problem nu og her.
Det bliver selvfølgelig beskrevet som ineffektivt, men her vil jeg gerne have nogle tal eller andet på bordet. Noget der rent faktisk beviser, at det forretningsmæssigt er værd at vente på, at der bliver plads i planlægningsmaskinen til at varetage behovet. Mit mistanke/erfaring er nemlig, at den mistede agilitet i organisationen er langt dyrere end den værdi der skabes ved at centralisere.
- Svaret er selvfølgelig at indføre en organisatorisk flaskehals i form af governance. Jeg tænker, at denne opgave skal gribes grundlæggende anderledes an. Det virker som om, at organisationer er fastlåst i, at IT kun er for IT afdelingen.
Men for at sikre, at man har de nødvendige muskler til at konkurrere pg udnytte IT til fulde, bør man i min optik sikre, at der er tilstrækkelige IT kompetencer til stedet i organisationen. Således organisationen er i stand til at reagere og udnytte de konkurrence fordele der løbende dukker op, uden at skulle vente på tid i planlægningsmaskinen.
Vi anvender SVN og Buildbot.
Buildbot giver en masse fleksibilitet, og vi har udviklet lidt ekstra til den, så den kører med nogle segmenterede konfigurationsfiler.
SVN er i stand til at trigger buildbot, således at den ud fra commits kan få bygget den nye version af koden.
Alt i alt synes jeg vi har en udemærket løsning, uden at den bliver for tung og besværlig at benytte.
/Søren
En af grundelementerne er at man ikke får stykket en arkitektur sammen, som afgrænser mulighederne fremover. Mary Poppendieck har udtrykt som "The last responsible moment" i hendes bog om Lean Software development.
Min personlige oplevelse er at transitionen fra vandfaldsmetoden til en agil process er krævende for udviklere. Primært fordi man skal vænne sig til at man ikke længere har det store gyldne design at implementere. I stedet man skal være villig til at ændre den implementering man en gang har lavet på et område, fordi designet ikke længere holder til det det skal kunne klare.
Med frekvente iterationer bliver dette dog nemmere, fordi man ikke skal trevle et halvt eller helt års udvikling op men kun 2 måneder, alt efter hvordan man har strikket sin proces sammen.
/Søren
Hvilket omfang havde projektet...
Det virker ikke specielt stort med 3 sprints. Hvis projektet i forvejen er lille og overskueligt, så er det vist begrænset hvor meget man kan tilskrive udviklingsmetoden?
Personligt har jeg det bedst med et "ryddeligt" skrivebord, uden at det skal være totalt ryddet.
Jeg kunne huske en ældre artikel fra JP, som kan ses her http://fpn.dk/penge/article66755.eceMen det kan jo altid diskuteres!
Dog skal det siges at der skal være en grad af ryddelighed, da det forbedrer arbejdsmiljøet betragteligt, hvis det er til at komme til at gøre rent :)
Finnerne er sikkert foran teknologisk, hvilket vi nok kunne lære noget af. Desværre har vi fået en kultur hvor man slår hårdt ned på fejl og er knapt så gode til at belønne innovative og progressive folk. Forhåbentlig kommer der snart ændringer på denne side.
På arbejdsmiljøsiden er jeg ikke sikker på finnerne er foran. Den måde hvorpå du beskriver deres ryddelighed og stiltiende arbejdsmoral virker meget steril og utrolig kedelig hvis du spørger mig. Vi tilbringer en stor del af vores vågne tid med at være på vores arbejde. Hvis der ikke var social interaktion ville jeg personligt føle det var utroligt kedeligt og hurtigere brænde ud på min arbejdsplads.
/Søren
Der er jo ikke noget som gratis E-Mails - Det er en illusion at det er gratis at spamme.
Vi betaler alle for den infrastruktur der skal til for at sende alle de mails, og efter min mening burde vi tage den slags meget mere seriøst. Havner man på de "effektive" spamlister kan man lige så godt give op og få en ny mail addresse - Hvilket ikke er nogen lille ting, da man skal ind og skifte den alle de steder hvor man har brugt den for at tilmelde sig, som f.eks. her på stedet.
Der skal ikke nogen ny teknologi til - teknologien findes allerede. Erstat anonyme emails med positiv genkendelse af afsender, som f.eks. Microsoft har gjort i Messenger. Det afskaffer alt modtagelse af anonymt afsendte mails. Hvis folk vil på din liste af personer du modtager "mails" fra, så kan de anmode om det. Hvis man afviser, så smid dem i en sort liste, hvor de beskeder der sendes til en bliver slettet eller aldrig videresendt fra serveren.
Jeg vil ikke betale ekstra fordi nogen ikke kan finde ud af at bruge systemet på behørig vis - Så vil jeg hellere afskaffe muligheden for at misbruge systemet.
Søren Pedersen