3.6
Utvärdering
Grunden för denna utvärdering har varit intervjuer med anställda på Medius samt personliga reflektioner. I de fall där det är jag som anser något skriver jag ut det, annars är det baserat på intervjuer.
Det finns ett antal brister när det gäller dokumentation av vissa PBI:er. De har inte de dokument kopplade till sig som de ska ha, och i vissa fall är innehållet i dokumenten väldigt begränsat. Författaren har bara skrivit en rad eller två för att skriva något, inte lagt ner tid på att skriva ett ordentligt lösningsförslag. Ett relaterat problem är att vissa dokument kan vara långa men väldigt svåra att sätta sig in i då de förutsätter stor kunskap om koden, som inte alla har. Denna åsikt kom från en nyanställd så detta löser sig troligen med tiden.
När utvecklingen med en PBI är avslutad uppdateras dokumentationen bara i vissa fall, i många andra lämnas dokumentationen som den är. I de PBI-specifika dokumenten är detta sällan ett problem men när det gäller produktdefinition, användarhandböcker och andra dokument som är aktiva under en längre tid blir detta ett problem.
Några dokument ska skrivas till varje PBI: testning, design, lösningsförslag etc. Alla dessa dokument går emot den dokumentlösa grundtanken med Scrum vilket Medius är medvetna om, men har valt att kompromissa.
Konsulterna har i dagsläget ingen ordentlig kanal för informationsutbyte mellan sig för att förmedla hur långt ett projekt har kommit. I dagsläget har de en tillfällig lösning som inte ger någon överblick eller vettigt perspektiv över detaljer.
Uppdateringar av dokument prioriteras i en del fall ned, i enstaka fall glöms de även bort eller missas helt, mail blir liggande i inkorgar eller arkiveras bort.
Det finns några möjliga orsaker till detta. Medius har växt i väldigt snabb takt under flera års tid och fortsätter att växa i samma takt medan dokumenthantering och arbetsprocesser inte verkar ha hängt med i samma takt. Interna processer har ofta en tendens att bli lidande i vanliga fall, företag fokuserar naturligt på de delar som får in pengarna, och jag tror att detta fenomen blir förstorat under kraftig uppgång. Det faktum att Medius utökat från ett kontor till flera kontor i både Sverige och utomlands och de kommunikationsproblem detta medför bidrar troligen också.
Medius dokumenthantering och -uppdatering har tidigare varit bristfällig och har fortfarande ett antal brister. De är dock medvetna om många av problemen och jobbar för att åtgärda dem. Om min nya process kan underlätta detta arbete anser jag att arbetet har lyckats.
Kapitel 4
Ny process
Den nya processen har utvecklats för att uppnå funktionalitetsriktlinjerna som finns i Appendix A. Kapitlet är uppdelat i fyra Adelar, först kommer beskrivningar av hur hantering av uppdateringar respektive genereringar kan ske, detta följs av ett avsnitt som beskriver tekniken bakom och slutligen ett avsnitt om hur detta skulle kunna implementeras.
Processen består av två huvuddelar. • Hantering av uppdateringar av dokument • Generering av dokument från dokumentdelar
4.1
Hantering av uppdateringar av dokument
Processen ska klara av att hantera uppdateringar av existerande dokument. När en utvecklare checkar in kod ska rätt person(er) uppmärksammas på att rätt delar av rätt dokument bör uppdateras.
Figur 4.1. En översiktsbild av dokumentuppdatering med den nya processen
4.1.1
Scenarion
Fyra scenarion beskriver hur arbete enligt den nya processen skulle kunna fungera. Det finns ett antal roller i dessa scenarion.
• Programmeraren Per
• Programmeraren Pernilla
• Marknadsförare Markus
• Chef Charlotte
Scenario 1 - Direkt till samma utvecklare
Figur 4.2. Scenario 1
Per har precis blivit klar med en PBI och ska checka in filerna relaterade till den. När han checkat in kommer det upp en dialogruta som talar om att kapitel 2, avsnitt 3 av manualen och kapitel 4, avsnitt 5 och 7 av produktdefinitionen behöver uppdateras. Modulen hämtar hem och öppnar dokumenten så att Per kan redigera dem direkt. När modulen hämtat hem och öppnat alla väntar den tills alla fönster har stängts ned igen och då skickar den tillbaka alla till TFS:en.
4.1 Hantering av uppdateringar av dokument 33
Scenario 2 - Till annan utvecklare
Figur 4.3. Scenario 2
Pernilla har blivit klar med arbetet med två PBI:er men har fått ett viktigt uppdrag vid sidan av som måste bli klart innan hon kan uppdatera dokumenten till PBI:erna. Hon hör med Per som har det lite lugnare, han blev ju precis klar med sin PBI och han säger att han kan ta på sig att uppdatera dem så att han har hyfsad koll på vad PBI:erna innebar. När hon checkar in koden ber hon servern att lägga dem på Per istället med en notering om att de egentligen är Pernillas.
Scenario 3 - Till säljare
Pernillas ena PBI var en markant skillnad i gränssnittet, tillräckligt stor för att produktbladet behöver uppdateras med nya skärmbilder och lite ny text. Då produktbladet ligger på säljare läggs avsnitt 4 av produktbladet till på Markus lista, och när alla listor körs genom vid midnatt går ett mail ut till Markus om att avsnitt 4 av produktbladet behöver uppdateras (skulle även kunna gå till alla säljare så att de får dela upp arbetet mellan sig). När uppdateringen är klar går de in på en webbsida och markerar att uppdateringen är klar, görs inte detta inom ett antal dagar skickar systemet ut en påminnelse.
Figur 4.5. Scenario 4
Scenario 4 - Chef
Charlotte är chef över en samling medarbetare och vill ha lite översikt över hur mycket dokumentationsarbete de lämnar efter sig. Då kan hon gå in på webb- servicen och se vilka dokument som ska uppdateras av vilka personer, vilka som redan är uppdaterade och liknande information. Om hon ser att en anställd sackar efter med sina dokumentuppdateringar kan hon ta ett samtal med personen innan det spårar ur helt.