Projekt intranät Office 365 av Per Ekstedt

Transkript

1 Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget gäller att bygga ett intranät i Office 365. Lösningen ska förutom dokumenthantering även innehålla samarbetsplatser och integrationer mot externa system. Ett agilt arbetssätt baserat på SCRUM ska användas vid genomförandet. 1.1 UTMANINGAR OCH SÄRSKILDA HÄNSYN Eftersom Office 365 i förhållande till kunden är en extern webbplats i den meningen att det inte självklart ryms inom kundens egna domäner i form nätverk och förvaltning så finns särskild hänsyn att ta till såväl säkerhet som möjlighet till integrationer mot kundens övriga system. Plattformen som valts har stora möjligheter att erbjuda önskade funktioner direkt ur lådan eftersom det är en produkt för dokumenthantering och samarbete. Det finns däremot några viktiga punkter att ta speciell hänsyn till under arkitekturarbetet. Scrum Tillgänglighet Säkerhet Användbarhet Utveckling Förvaltning Drift Integration Dokumentation

2 1.1.1 Scrum För att kunna tillämpa metodiken effektivt behöver det säkerställas att det finns produktägare tillgängliga innan och under utvecklingstiden. Ett kravarbete kan redan ha påbörjats med många krav redan definierade och då kan dessa läggas in i backloggen för att utgöra grunden för kommande förfining inför sprintplaneringen. Sannolikt behöver backloggen gås igenom både en och två gånger innan den första sprinten kan ta form vilket betyder att detta arbete måste påbörjas i god tid innan det är tänkt att utvecklingen ska var igång. När backloggen är i sitt första skede och användarberättelserna är översiktliga är det inte nödvändigt att alla projektdeltagare är närvarande men produktägare och arkitekter måste vara med. När förfiningsarbetet börjar för att bryta ner berättelserna är det däremot viktigt att så många som möjligt är med. För att sedan bestämma aktiviteterna till sprintplaneringen kan eventuellt produktägarna få ledigt förutsatt att de har prioriterat backloggen Sprintar En sprint representerar en iteration av det totala arbetet med projektet. De måste vara planerade så att juste de uppgifterna som ingår kan få fullt fokus och sprinten avslutas med något som är så färdigt att det skulle kunna levereras. I princip ska funktionerna i en sprint kunna ändras först i en kommande om det blivit fel. Längden på en sprint får inte vara så kort att teamet inte hinner bygga klart funktionerna i sprinten och den får inte vara så lång att det utgör en projektrisk ifall de byggda funktionerna inte duger. Sammanfattningsvis ska en sprint vara så kort att man inte hinner känna behovet att ändra riktning under sprintens gång, men så lång att teamet faktiskt hinner göra klart något som är värdefullt. En standard som vuxit fram på området ger vid handen att sprintar längre än 3 veckor bör undvikas Planeringsmöten Varje sprint bör planeras in tillsamman med utvecklingsteamet och produktägarna och helst efter att produktägarna har prioriterar backloggen. Syftet är att tillsammans vara överens om vad i backloggen som går att bygga inom ramen för en sprint. För att kunna uppskatta hur lång varje enskild aktivitet ska inte enheten tid användas. Poäng kan vara en bra angivelse varefter man sedan endast utrycker sig i poäng när man mäter sprintlängder Dagliga möten Varje arbetsdag i projektet ska på morgonen hållas ett kort möte (inte längre än 15 min) där korta redogörelser för läget kommuniceras. Varje deltagare som tagit sig an en uppgift berättar vad som hände igår och vad kan tänker göra idag. Om det finns något problem kan det flaggas upp vid detta möte Återblick Efter varje sprint är det viktigt med ett återblicksmöte som ger alla deltagare en möjlighet att berätta vad som är bra, kan förbättras eller bör upphöra. Detta för att hela tiden förbättra arbetet i projektet Demo När en sprint är klar är det meningen att det ska finnas funktioner som är klara och möjliga att visa upp. Ett möte där produktägarna och deras respektive verksamheter får möjlighet att se resultatet bör därför planeras in efter varje sprint. Mötet är ett viktigt verktyg för att verksamheten ska få möjlighet att påverka utvecklingen i rätt riktning.

3 1.1.2 Tillgänglighet Medarbetare med nedsatt syn kan ha speciella utmaningar att tillgodogöra sig information på en webbplats som ett intranät ju är. Offentliga arbetsgivare som kommuner och landsting har ofta en hög ambitionsnivå på det här området. Exempelvis kan synskadade personer behöva talläsare vilket i sin tur ställer hårda krav på den tekniska utformningen av de sidor som byggs Säkerhet Ett intranät för kundens medarbetare i Office 365 kan behöva en säkerhetslösning baserad på en trust mellan kundens normala behörighetssystem och det som finns i den domän där Intranätet finns. Detta för att medarbetarna kanske inte är kända hos intranätet på grund av att systemen inte tillhör samma domän. Leverantören av Office 365 plattformen erbjuder tjänster (ACS) för det som kan underlätta men kunden måste då kunna möta de tjänsterna på sin sida vilket kan vara en utmaning. Best practice här är annars autentisering med Claims. En autentiserad claim kan sedan användas för att ge användare auktorisation till rätt funktioner. Integrationer med andra system som befinner sig utanför den domän där intranätet finns har motsvarande utmaning och kan eventuellt också lösa autentisering och auktorisation med Claims Användbarhet Många kunder är ofta bundna till att följa gemensamma policys vad gäller webbläsare och versioner av dessa samt att använda program (word, acrobat) för att jobba med dokument av olika slag och specifika versioner av dessa. Valet av webbläsare kan ibland ha stor betydelse för vilken teknik som kan användas vid eventuell egen utveckling vilket kan påverka utformningen och därmed också användbarheten. En del funktioner i Office 365 i samband med dokumenthantering är ofta starkt bundna till att den senaste versionen av vissa program finns hos kunden. Den valda plattformen har stora möjligheter att konfigureras för att få bra funktionalitet för användarna men väldigt ofta behöver egna anpassningar göras för att nå den riktiga nyttan och acceptansen hos användarna. Att hitta balansen mellan att kunna använda det som redan finns och den egna anpassningen utan att förändra produkten för mycket kan vara utmanande. De inbyggda arbetssättet som plattformen (SharePoint) erbjuder direkt ur lådan är trots många bra funktioner, inte alltid en favorit bland användare. Det ställer därför stora krav på en aktiv produktägare som kan föra fram användarnas perspektiv för att användarna ska vilja ta emot systemet.

4 Utveckling Plattformen (Office 365) som har valts innehåller redan det som är grunden för ett bra intranät nämligen dokumenthantering och samarbetsytor. Även om det som redan finns är bra så uppstår nästa alltid önskemål om förbättringar eller förändringar av det som finns för att riktigt passa de som ska använda intranätet. Möjligheterna till att anpassa den här webbplatsen direkt i plattformen är väl definierade men för en utvecklare begränsade till enbart webbutveckling. Det är inte möjligt att bygga egen programkod som kör i leverantörens maskiner som utgör plattformen för Office 365, den är helt reserverad för leverantörens förändringar av plattformen Egna anpassningar Begränsningarna för att utveckla egna anpassningar i Office 365 är inte nödvändigtvis begränsande för vad som kan byggas men den sätter en delvis ny profil på en utvecklare av SharePoint lösningar. En utvecklare av lösningar i Office 365 bör huvudsakligen kunna bemästra webbutveckling där programmen måste byggas med JavaScript som exekverar i användarnas webbläsare istället för i plattformen. När programmen jobbar med webbplatsens innehåll på ett eller annat sätt nås det via tjänster (REST) i plattformen för ändamålet. För att den här typen av lösningar (sidor) ska bli riktigt bra kan strukturerade ramverk (ex. TypeScript) användas i webbsidorna. Best practice här är att använda designmönstret MVVM. Även om plattformen innehåller ett väl definierat sätt för en utvecklare att komma åt innehållet och bygga högfunktionella sidor på det så uppstår inte sällan behovet av att kunna hämta information från externa källor eller bara utföra komplexa operationer som inte bör ske i användarens webbläsare. En sådan extern källa kan vara ett annat system hos kunden som inte går att nå på ett passande sätt. I dessa fall kan egna tjänster behöva byggas, som sedan lösningarna i Office 365 lätt kan konsumera, men dessa kan inte ha sin hemvist i Office 365 utan måste placeras på en server som lätt kan nås från webbplatsen. Leverantören av Office 365 erbjuder sådana möjligheter som kan underlätta genom sina övriga molntjänster (Azure) men den egna tjänsten kan också placeras hos kunden. I det fall tjänster av det här slaget behöver byggas finns inga av de begränsningar som styr utvecklingen i Office 365 och det kan också finnas fördelar med att förlägga mycket kodande här istället för i Office Isolera funktionalitet Det kan också vara klokt att inte bygga sina lösningar alltför tätt knutna till leverantören av intranätet för att inte behöva bygga allt på nytt igen när kunden väljer en annan leverantör. Det ska helst vara möjligt att byta ut både underliggande såväl som yttre system utan att behöva göra om allt på nytt. Stor vikt måste därför läggas vid designen av alla egna anpassningar för att göra det möjligt. Kunden kan ibland ha planer på att de funktioner byggs ska kunna användas av andra delar av organisationen eller att användare själva ska kunna välja vilka funktioner de vill ha i exempelvis en samarbetsyta. Plattformen erbjuder stora möjligheter att isolera funktionalitet och erbjuda dem som paketerade Appar. Best practise hos leverantören här är att isolera funktioner på detta sätt om det går.

5 Installation Att installera egenanpassade lösningar i Office 365 handlar egentligen om att ladda upp filer i olika systembibliotek och att konfigurera den befintliga webbplatsen. Best practice är att använda PowerShell för det ändamålet. Med dessa skript kan troligen det mesta göras och skripten bör finnas från början, användas och uppdateras allteftersom lösningen växer fram för att närhelst de körs sätta upp den senaste versionen av webbplatsen. Alla utvecklare som jobbar med lösningar som direkt rör Office 365 måste ha en egen version av en Office 365 developer site och regelbundet uppdatera den med hjälp av de senaste skripten. All kod som tas fram ska så ofta som möjligt checkas in i ett gemensamt system för källkod. Innan de egna lösningarna checkas in har utvecklaren tagit ut den senaste koden och testkört den med sin egen Gemensam utvecklingsmiljö För att kunna leverera en sammanhållen lösning måste det finnas en gemensam webbplats där den färdiga lösningen kan sättas upp i en så produktionslik version som möjligt (Systemtest eller integrationstest). Beroende av projektets behov måste det när som helst vara möjligt att med skript sätta ihop alla byggda funktioner på denna webbplats innan en sammanhållen leverans från projektet kan ske. I den här miljön måste det också vara möjligt att pröva alla eventuella integrationer mot andra system Acceptanstest och utbildning När projektet har internt testade funktioner att leverera är det viktigt att kunden har en egen webbplats (acceptanstest) för att verifiera att leveransen motsvarar förväntningarna. Det är av stor vikt att den miljön är produktionslik för att kunden ska få en så rätt bild som möjligt av att köra lösningen. Det kan vara en bra rutin att, efter varje sprintdemo, installera den nya versionen i denna miljö för att ge användare möjlighet att känna på lösningen så fort som möjligt. Optimalt kan ytterligare en parallell miljö med acceptanstestmiljön sättas upp där användare kan utbildas.

6 1.1.7 Förvaltning Under tiden som lösningen byggs så växer troligen mängden kod vilket innebär större och större utmaningar när ändringar eller tillägg görs för att inte riskera att redan utvecklade funktioner ofrivilligt förändras. Även efter det att lösningen är satt i produktion kan det finnas att behov av att utveckla lösningen vidare. Ett sätt att göra det mindre utmanande varje gång förändringar ska till är att under utvecklingstiden också bygga automatiserade tester för de funktioner som byggs. Tester som körs efter varje förändring för att säkerställa befintlig funktionalitet. Om detta görs minimeras riskerna för den framtida förvaltningen att göra nödvändiga förbättringar. Plattformen som valts (Office 365) har många inbyggda funktioner som inte ska behöva testas eftersom de tillhör den färdiga produkten men alla egna anpassningar är bra att testa. Eftersom det framför allt handlar om att bygga webbsidor kan det vara utmanande att bygga automatiserade tester av koden eftersom det inte finns några riktigt bra testverktyg för sådan kod tillgängliga på marknaden. Däremot finns det goda möjligheter att bygga automatiserade GUI tester av webbsidor. Det kräver däremot ofta en speciell kompetens som kan vara svår att hitta hos alla utvecklare så en specialist kan behöva anlitas. För den kod som förläggs till egna tjänster och kör på maskiner som kunden kan kontrollera själv finns däremot goda möjligheter att använda befintliga testverktyg och ramverk för att utveckla automatiserade enhetstester av koden och bra designmönster för kod finns tillgängliga som gör det lättare att bygga tester. Många utvecklare har också redan stor vana att arbeta på det sättet. Best practice här kan vara att använda designmönstret MVC när de egna tjänsterna byggs. Om den framtida förvaltningen av kod har en hög prioritet för kunden bör lösningen så långt som möjligt bygga på kod i egna tjänster som kan konsumeras lätt av de webbsidor som byggs i Office 365. Detta för att underlätta för automatiserade enhetstester. Behovet av automatiserade GUI tester kan detta till trots behövas ändå Drift Eftersom den valda plattformen är Office 365 så hanteras inte driften av kunden. Driften av maskinerna och webbplatsens domän ansvarar leverantören för men den dagliga driften i form av att ge användare rätt behörigheter, skapa nya samarbetsytor eller annat inom webbplatsen kan det vara kunden som ansvarar för. Det finns ofta särskilda rutiner hos kunden för daglig hantering av det här slaget som påverkar utformningen av lösningen vilket gör de som ansvarar för dessa rutiner till viktiga kravställare på lösningen. Det är av allra största vikt att den delen av kundens organisation finns med tidigt i projektet för att kunna sätta sin prägel på lösningen. Inte minst för att underlätta det kommande mottagandet av systemet.

7 1.1.9 Integration Den valda plattformen (Office 365) har sin hemvist i en egen domän hos en leverantör på internet och det kan därför vara utmanande när behovet av en integration mot ett system utanför denna domän uppstår. En utmaning kan vara autentisering och auktorisering mot det system ska integreras och även om leverantören erbjuder tjänster (ACS) som kan underlätta så måste ändå båda systemen kunna möta varandras teknik för kommunikation. Plattformen erbjuder direkt ur lådan möjlighet att visa och arbeta med extern data via BCS med stora möjligheter att konfigurera en anslutning. Till den finns också i lådan färdiga webbdelar att använda. Funktionerna är mycket enkla men kan räcka för att visa information i listform från ett externt system. Leverantören erbjuder också tjänster (BizTalk Services) för integration som är mycket flexibla och kan vara ett starkt alternativ till att bygga en egen tjänst. Verktyget i fråga ger stora möjligheter att bygga integrationer genom konfiguration och det går också bra att bygga egna anpassningar som körs inom tjänsten. Det kräver däremot ofta en speciell kompetens som innehas av mycket få utvecklare så en specialist kan behöva troligen anlitas. Om integrationen måste hanteras som en egen anpassning kan det vara bra att undvika direkt kommunikation med de system som ska integreras från för att undvika hantering av diverse olika kommunikationsmetoder direkt i JavaScript kod och undvika ett starkt beroende till det system som ska integreras. Best practice i ett sådant fall är att erbjuda den information som finns i det system man vill integrera mot via en egen tjänst (internt servicelager) som ansvarar för kommunikationen med den källa som efterfrågas Dokumentation När en lösning är satt i produktion är det viktigt med en bra dokumentation av systemet och det kan därför vara en naturlig leveranspunkt någon av de avslutande sprintarna i ett agilt projekt. Under tiden som en lösning växer fram hos arkitekten finns ofta ett behov av dokumentation trots att lösningen inte är färdig. Det kan exempelvis finnas andra delar av kundens organisation som har vissa beroenden till det som skall eller håller på att byggas. Innan utvecklingen har kommit igång bör arkitekten ändå ha en design som måste kunna kommuniceras både inom och utom projektet. Någon av de inledande sprintarna bör därför innehålla en uppgift att ta fram en logisk design av lösningen. Skulle det sedan uppstå ett behov under projektets gång av att visa upp den aktuella designen eller ytterligare detaljer måste sådana aktiviteter planeras in i en sprint alternativt förutses behovet redan innan och en löpande uppdatering av designen kan då läggas in i varje sprint.

8 1.2 UTFÖRANDET För att bäst använda en lösningsarkitekt är det viktigt att involvera en sådan så tidigt det är möjligt i projektarbetet. Om det agila arbetssättet inte redan har börjat kan det med fördel starta även om det kanske bara handlar om kravfångst. Det kan också fungera bra även om en viss kravfångst påbörjats innan arkitekten är på plats. När arkitekten väl är på plats kan det vara bra om kontakt så fort som möjligt etableras mellan arkitekten och samtliga produktägare inklusive drift och förvaltning. Arkitekten behöver så fort som möjligt veta vilka givna förutsättningar eller icke funktionella krav som finns för att kunna arbeta effektivt redan från början. Exempel på tidiga frågor: Vilka plattformar för eventuell lösningar måste användas? Vilka eventuella policys för utveckling, förvaltning och drift finns att förhålla sig till hos kunden? Vilka metoder för autentisering och auktorisering finns redan och ska användas? Finns det förväntningar på systemet som inte direkt rör den aktuella verksamheten (ex. rapporter, loggning)? Det kan vara effektivt om arkitekten får arbeta med frågor som dessa så tidigt som möjligt både innan och under tiden som det inledande arbetet med backloggen pågår. Om det finns utvecklare på plats redan i detta skede kan det vara bra om arkitekten etablerar kontakt med dem så snabbt det går för att involvera dem i arbetet med främst de icke funktionella kraven på lösningarna. De kan vara till stor hjälp för arkitekten när det gäller att pröva tekniska koncept och bidra med konstruktiva förslag och egna erfarenheter. När det gäller det inledande arbetet med backloggen är det däremot inte självklart att utvecklarna behöver vara med men produktägare och arkitekt måste vara med. Det kan vara bra om arkitekten kan visa en färdplan och design som alla tror på innan utvecklingen börjar. De första sprintarna kan alltså komma att innehålla arbete med backloggen och design samt om utvecklare är på plats även aktiviteter för att ta fram tekniska koncept. Vid sprintplaneringen av de första sprintarna behöver därför samtliga berörda projektdeltagare vara med. När det arbetet med backloggen kommit så långt att det finns möjlighet att tränga djupare ner i tillräckligt många användarberättelser kan förfiningsarbetet med backloggen börja och om inte förr så är det dags att involvera även utvecklarna. Så fort det finns förfinade användarberättelser som alla är överens om kan delas upp i enskilda utvecklingsaktiviteter och produktägarna prioriterat backloggen kan en sprintplanering hållas och utvecklingsarbetet kan komma igång. För att minska risken att arbetet går i fel riktning är det bra att hålla längden på en sprint till högst 3 veckor och därefter en sprintdemo för alla i projektet samt ett återblicksmöte så snabbt som möjligt efter sprintavslutet där alla kan vara med.

9 Det agila arbetssättet till trots så är det vanligt att de som ansvarar för budget och tidplan vill ha en uppskattning av tid och kostnad för projektet. För att kunna möta ett sådant behov redan i början på projektet kan det bli nödvändigt med ett längre arbete med backloggen innan utvecklingen kan komma igång ordentligt. Det som kan göras i detta skede kan då vara en grov uppskattning i tid för varje användarberättelse tillsammans med hela teamet där medelvärdet används som den totala tidsåtgången. Övningen kan sedan upprepas regelbundet eller vid behov under projektets gång för att förfina estimaten. Ett stort intranät har förutom många dagliga användare ofta många redaktörer och administrativa användare av olika slag. Det är av stor vikt att deras synpunkter fångas upp av produktägarna för att lösningen ska bli lyckad och väl mottagen. Det kan därför vara bra att de så tidigt som möjligt har tillgång till en webbplats där de kan testa alla funktioner som tas fram av utvecklingsteamet, lämpligen efter varje sprintdemo. I god tid innan projektet ska vara klart är det bra om sprintarna innehåller aktiviteter för att sätta upp en utbildningsmiljö där optimalt kanske projektägarna genomför utbildning av alla kommande användare och redaktörer. För att slutligen kunna överlämna lösningen till kundens drift och förvaltning är det optimalt bra om det under hela utvecklingens gång funnits medlemmar (ex. utvecklare) av den kommande förvaltningen representerade i utvecklingsteamet för att minska ett framtida beroende av arkitekten eller extern personal.