Møder

Møder kan være meget forskellige og med forskellige formål. For
at opnå et effektivt møde må formål og mødeform stemme
overens. Hvis man er i en brainstorm proces, bør mødet være
kreativt og frit og stole og borde bør ikke være tilstede i
traditionelform, da disse begrænser kreativiteten. I stedet kan
der være sofaer eller evt. en seng.

Når man afholder et kreativt møde, er det vigtigt at de
implicerede anvender højrehjernedel til at tænke med, da dette
er den kreative hjernedel. Dette kan f.eks. gøres ved at skrive
med den modsatte hånd end den man plejer at bruge19, hvorved
man skifter mellem hjerne halvdelen eller man kan lave noget
andet kreativt. En anden mulighed er at lade en gåtur indgå i
mødet, hvor man får mulighed for at få frisk luft og snakke
uofficielt om ideer med de implicerede, hvorved nye tanker kan
opstå.

Hvis mødet imidlertid ikke skal være kreativt, men snare
effektivt og kort. Bør lokalet indrettes med et højt bar bord og
whiteboards eller touchscreens, da stående møder ikke vare så
længe som siddende.

Når kreative mennesker mødes til møder, kommer de tit væk fra
det der egentlig var emnet. Hvilket i den kreative proces kan
være en fordel men på andre tidspunkter en stor ulempe, da
møderne kommer til at vare meget længere og ikke altid er
særlig konstruktive. John Evan-Jones beskriver i sin bog Hot
Teams hvordan dette kan undgås ved at man til møderne tage
forskellige hatte ”på” alt efter hvordan sagen skal gribes an.

Denne tekst anvendte vi som baggrund for vores mødeafholdning

Tidsplan

Dette er en af artefakterne fra Foranalyse fasen. Vi har udarbejdet en Gantt tidsplan

Faser

En fase er en delsekvens i et projektforløb. Hver fase indeholder mange aktiviteter fra de forskellige discipliner, fasen genererer artefakter, og fasen afsluttes med en milepæl og et review. En fase består af en eller flere iterationer, i dette projekt har jeg besluttet at en iteration er på 10 mandedage eller 2 uger.
Der er forskel på tids- og ressourceforbrug i de enkelte faser. Et typisk mellemstort projekt vil have ressourcer og tid fordelt som vist her: figur 1

Da vi skal skrive en del dokumentation er min Foranalyse og Detaljerings fase lidt længere end dem som er illustreret på figuren. Vi har udeladt Overleverings fasen da den ikke har relevans for vores projekt. Vi har beskæftiget mig med følgende Metode 2 faser:

Foranalyse:
Formålet med Foranalysen er at formulere og fastlægge systemets scope (mål og rammer) samt etablere en aftale (Projektbeskrivelse) med kravstilleren om hvad der skal udvikles.

Alle laver, aftale med projektlederen om en eventuel projektbeskrivelse.

Udover de nævnte artefakter der skal laves en projektdefinitionen, som indeholder indledning, problemformulering og afgrænsning. Denne fase skal være færdig efter
første iteration.

Hovedaktiviteter i Foranalysen:
· Afdække og formulere projektets scope og systemets grænser.
· Overordnet at beskrive de fremtidige forretningsprocesser og systemets Use Cases.
· At udarbejde en overordnet projektplan for hele projektet samt en detaljeret plan for den
første iteration i Detaljeringsfasen
· At udarbejde en Projektdefinition, herunder:
o Indledning
o Problemformulering
o Afgrænsning
· At udarbejde og dokumentere en Analyse som ligger til grund får valget af
løsningsmodellen.

Detaljering:
Det primære formål med Detaljeringsfasen er at få bygget en stabil arkitektur for den færdige løsning. Resultatet af denne fase er et ”skeletagtigt” men kørende system, der demonstrerer den endelige applikations arkitektur. Med hensyn til dokumentationen skal analyse afsnittet skrives i denne fase. Denne fase skal være færdig efter 2 iterationer eller 2 uger.

Hovedaktiviteterne i Detaljeringsfasen er:
· At få en bedre forståelse for de indsamlede krav, System Use Cases
· At designe, implementere og verificere en arkitektur, der kan understøtte den færdige
løsning

At implementere de kritiske System Use Cases og hændelser, der blev identificeret i
Foranalysefasen
· At sikre at miljøet omkring projektet, så som projekt databaser, udviklings- og test miljøer,
værktøjer og lokaler der er behov for til Konstruktions fasen, er på plads
· At få defineret og beskrevet test-strategier og test planer
· At få dokumenteret Design delen af projektet.

Konstruktionsfasen:
Formålet med Konstruktionsfasen at udvikle den resterende del af løsningen, på baggrund af den arkitektur, der blev defineret og udviklet i Detaljeringsfasen. Det er også her at den resterende funktionalitet udvikles og iterativt indarbejdes i applikationen.
Det primære resultat af Konstruktionsfasen er en produktionsklar version af den samlede løsning, der opfylder de krav til funktionalitet, der er blevet indsamlet og godkendt under detaljeringsfasen. I denne fase skal Implementerings afsnittet af rapporten skrives. Denne fase varer 2 iterationer.
Hovedaktiviteter i Konstruktionsfasen:
· Beskrivelse af de resterende krav, System Use Cases og Supplerende Specifikationer, der
skal implementeres i de enkelte iterationer
· Færdiggøre Analyse og Design af den resterende funktionalitet
· Implementering af de resterende dele af løsningen og integrere disse i den samlede løsning
· Løbende test af de dele af løsningen der udvikles i de enkelte iterationer
· At få dokumenteret Implementerings delen af projektet.
I konstruktionsperioden er det implementeringen af den valgte løsningsmodel som har første
prioritet. Det eneste der skal dokumenteres i denne fase de problemstillinger man vil komme til at
møde når man implementerer.

>Tak Dennis… Det er fint…
>
>Glæder mig også til at se dig frisk og frejdig
>
>Knus M
>
>
>On 25/11/06 23:25, “Dennis Mister x” wrote:
>
> > Hey marlene, venter altså med at sende mailen til dig, til du kommer
>hjem;
> > tænkte at du har fået det vigtigste afvide da vi snakkede alligevel – og
>du
> > skal ikke spekulere på vores rapport, imens du er afsted – det eneste
>jeg
> > sender til dig de næste 4 dage, vil være løbende status rapporter over
>hvad
> > mig og camilla laver, samt designet løbende:
> >
> > Brugte et par timer på at skrive den, og kan ikke lige gengive den
>hurtigt.
> >
> > Dertil står meget af det jeg skrev i det reffereat du har sendt, har
> > underligt nok først lige modtaget den nu:
> >
> > Hvis det bliver noget specifikt du er i tvivl om, eller nogen som helst
> > problemer så tøv ikke med at sige det til mig … anything!
> >
> > Hav et par fantastiske dage, på dit ide haløj, og med din bedstemor i
> > morgen..
> >
> > Glæder mig til at se dig, totalt u-stresset, livsglad, entusiastisk, og
> > motiveret.
> >
> > Knus D

Hej hårdtarbejdende Gruppe medlemmer.

Vi skal have fart på i næste uge. Men vi skal nok nå det. Jeg vil lige skrive en motiverende og informativ lille mail til Jer…

Først og fremmest så er i vildt seje og i gør begge et rigtigt godt stykke arbejde. Keep on doing that!

Som Dennis ved og Camilla nok ikke ved så kom der lidt kaffe i min computer i fredags så den er til reperation så nu bruger jeg Mikkels. Derfor vil det være bedst vil Camilla kan låne Dennis computer eller må vi sidde og arbejde hos mig. For så kan Camilla skrive på den stationære.

Herudover skal vi jo lige være sikre på at vi ikke skrive hinanden tekster så jeg vil bare lige sige at jeg er igang med følgende:

Database struktur
Forms (jeg skriver om hvad vi har vurderet som vigtigt i vores form med baggrund i en af de artikeler som dennis har sendt samt nogle andre jeg selv har fundet)

Jeg begynder også at ligne op til at lave en design manual. Hvis jeg har ramt noget andre gerne vil lave, må I lige maile tilbage.

God JUL Husk at vi skal være glade, tossede og søde

Mange knus Marlene

Ps. Gider en af jer at sende index filen samt problemformuleringen.
Ps. Vi har ikke fået svar fra de gloværdie lærer.
Ps. Min mave har det godt.

” How does a farmer count a herd of cows? With a Cowculator

Læringsmål – Marlene

Mine primære mål med projektet var at blive bedre til projektdelen. Dvs. blive bedre til at arbejde i grupper, til at koordinere og til at skrive rapporter. Jeg mener selv jeg har fået utroligt meget ud af projektet. Jeg har lært nogle ting, som jeg forhåbentligt aldrig vil glemme. Så jeg ikke begår de samme fejl igen. Vi var især presset hvad angår deadline, da vi midt i projektet ændrede kurs. Jeg er dog ikke ked af det kursskifte. For det gjorde at jeg kunne arbejde meget hårde, da jeg virkelig kan stå inde for den nye kurs vi har valgt. Jeg vil til en hver tid foretrække at knogle for noget jeg tror på, fremfor bare at lave tingene færdige uden gejst.

Jeg har lært en del om databaser og kode igennem projektet. Herudover er mit kendskab til web 2.0, Virtuelle workspaces, SOA også vokset enormt.

Jeg har helt sikkert lært nogle vigtige ting. Det kan godt ske, at det jeg lærte, ikke helt var det ,jeg ville lære, men det var helt sikkert det, jeg havde brug for at lære.

Designproces

Vi havde igennem projektet en længere design proces, hvor vi kom rundt omkring mange forskellige design. Vores design tog udgangspunkt i enkelthed, men sitet skulle stadig være ”smart”. Vi fandt derfor frem til sider som vi syntes indeholdt disse kriterier. Heriblandt fandt vi frem til google, skype, wishlistr og mange flere.
Vi vil her vise et udplug af vores design.

Ovenstående design er en af vores design, det har den lette baggrund, men falder igennem på det tunge grønne.

Det næste blev lidt mindre tungt, men er stadig for tungt.

Her er et andet design som igen er enkelt og let men måske for enkelt.

Til sidst kom vi frem til følgende design forslag som både var enkelt og visuelt tiltrækkende, syntes vi.
Senere i processen fandt vi imidlertid frem til ,at det var for enkelt, da det ikke var brugervenligt.

Herved kom vi frem til følgende ved at se lidt på andre design som www.wishlistr.com.

Usabillity

Vi startede ud med at kode applikationen efter vores oprindelige design timepuzzle.kwark.dk, men måtte ændre både design og derfor også koden da vores tests viste, at sitet ikke var så brugervenligt, som vi regnede med.
I stedet for den informative tekst til venstre på applikationen, vil der være en informativ tekst første gang man benytter applikationen. Efterfølgende vil det kun være muligt at se denne tekst, hvis man benytter linket hjælp og vejledning.
Dette er gjort pga. det gav for meget spildplads, at have informationerne på sitet konstant.
Vi fandt også frem til, at det var nødvendigt med en deadline funktion, så brugerne kunne se, hvornår der var sidste frist for at afgive mødetidspunkt.

Punktet Organisation blev også slettet fra vores form, da det er muligt tilføje dette sammen med emne eller koordinator. Det resultere i færre felter der skal udfyldes, og derfor bliver det hele mere overskueligt.

Et andet punkt vi fjernede, var dobbelt mail. Det skulle ellers være muligt, at tilføje flere mail adresser, men det blev for rodet og forvirrende, så vi droppede den ide.

En helt essentiel ting vi ændrede på applikationen, var vores kalendere. Fra at kunne vælge enten datoer eller timer en bestemt dag, ændrede vi det til, at det skulle være muligt, at kunne gøre begge dele samtidigt. Hvis man var interesseret i, at arrangere et møde en bestemt dato kunne man vælde det, og herefter skulle det være muligt også at vælge et tidspunkt. Dette gjorde det meget mere overskueligt, og det var også en af de ting målgruppen havde problemer med at finde ud af.

Kalenderen er synlig med det samme man får siden frem, hvorimod på det gamle site skulle man selv vælge enten dato eller timer hvorefter kalenderen loadede.

Eftersom design layoutet er ændret, har vi også tilføjet den grønne farve, for at skabe fokus på de korte eksempler.

Vi har som skrevet, lavet tests og revurderet og ændret vores design flere gange. Dette har resulteret i, at vores applikation er blevet langt bedre, flottere og mere brugervenlig, men det har været problematisk at skrive rapport afsnittet – design. Vi har ikke fulgt planen om først, at lave design, derefter kode og til sidst skrive rapport, men derimod lavet tests til det sidste. Vi har måttet rette i rapporten derefter, og det har forrykket tidsplanen drastisk.

Social proces styring

Igennem den arbejdsprocessen har vi anvendt en del teknikker fra Stephen R. Covey , John Evan Jones og Thomas Lütken ,som er kendte indenfor personligt management, læring og idéudvikling. Ved hjælp af disse teknikker, har vi sikret at engagementet hele tiden er i højsædet og at alle parter har det godt socialt. Vi har bygget samarbejdet på åbenhed og lighed, men har dog fra starten haft en nogenlunde fast rollefordeling, som har mindsket tvivlen ved arbejdsfordeling på mange områder .

Vi startede processen med at skabe synergi mellem os som et team. På den måde måde har vi været i stand til, at løse de konflikter der nødvendigvis må opstå. Vi har også arbejdet en del med læringsstile, ved videreformidling af informationer internt i gruppen. Herudover har vi arbejdet med tidspunkter for indlæring, ved at planlægge vores møder efter, hvornår vi er mest kreative/produktive.

For at arbejde så effektivt som muligt, har vi anvendt teknikker fra bogen ”Lær at lære” af John Evan Jones. Her har vi anvendt hjernedels skift. Når vi har haft behov for at være kreative, har vi skiftet til højrehjerne halvdel og når vi har haft brug for at være rationelle og konstruktive har vi skiftet til venstrehjerne halvdel.

Til møderne har vi skiftet til at forberede PowerPoints eller keynotes med målsætninger for mødet. Herudover har vi også skiftes til at finde på noget inspirerende, som har kunnet motivere os.

Proces styring

Det vil naturligvis være både meningsløst og inkonsekvent at bruge månedsvis på at agitere for fordelene ved web 2.0, decentralisering, organisk organisation etc., men i praksis benytte sig af stenalderagtige samarbejdsmetoder. Af samme årsag har vi benyttet 37signals “basecamp” til det der før i tiden hed projektstyring. Nu hedder det “project collaboration”, og har intet med styring at gører. Derimod har det alt med samarbejde og deling af information og viden at gøre, hvilket tager sig ud i form af delte milepæle, todo-lister osv. – det mest interessante i den forbindelse er funktionen “writeboard”, der er en online tekstprocessor som muliggør at flere mennesker kan skrive på de samme dokumenter, og derved på bedst mulig vis udnytte teamets fulde kompetencer. Dette minder tilnærmelsesvist om en Wiki. Denne funktion har vi dog udelukkende brugt i vores research-fase, idet at vi af tidsmæssige årsager, her menes voldsom op prioritering af prototypen, ikke har kunne retfærdiggøre for meget tekstuel ping-pong. Desuden har vi gjort brug af del.icio.us til obbevaring af relevante bogmærker.
Del.icio.us skriver om sig selv: “del.icio.us is a social bookmarking website – the primary use of del.icio.us is to store your bookmarks online, which allows you to access the same bookmarks from any computer and add bookmarks from anywhere, too. On del.icio.us, you can use tags to organize and remember your bookmarks, which is a much more flexible system than folders. You can also use del.icio.us to see the interesting links that your friends and other people bookmark, and share links with them in return. You can even browse and search del.icio.us to discover the cool and useful bookmarks that everyone else has saved – which is made easy with tags.”.