Microsoft har bestämt sig för att sluta uppdatera IE version 10 och äldre från 12:e Januari 2016 vilket man vetat sedan åtminstone februari detta år (https://www.gartner.com/doc/2993017/microsoft-plans-end-support-windows). Sen är det enbart IE 11 och Edge som gäller framöver. Detta betyder att säkerhetsuppdateringar inte längre släpps för de äldre versionerna. Dags att slänga ut <= IE 10 från företagen! Lättare sagt än gjort såklart men man får väl drömma.

Mer information här https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support

 

De flesta som har börjat den agila resan har gjort detta genom att anamma det agila ramverket/processen SCRUM. Till en början är det oftast guld och gröna skogar, men efter en tid kan det börja kännas som att det är mer kattguld än något annat. Allt hårt arbete, men progressen uteblir.

Var är det skon klämmer?
Det kan vara på både det ena och det andra stället, men en sak som är värd lite uppmärksamhet är att lära sig uppskatta storlek på User Stories och förstå vad uppskattningen faktiskt innebär.

Min generella rekommendation är att använda Story Points (SPs) på User Story (US) nivå. SPs är en rent fiktiv enhet som följer Fibonacci-serien (1,2,3,5,8,13 osv). Syftet med SPs är, enligt mig, främst att tydliggöra den relativa storleken på en User Story jämfört med en annan. Om User Story 1 uppskattas till 2 SPs och User Story 2 till 5 SPs är det rimligt att tänka sig att User Story 2 tar åtminstone dubbelt så lång tid att införa. Det är således en viktig input till Produktägaren när denne skall prioritera det arbete som skall utföras i nästkommande Sprint.

Notera att varje User Story måste ha väldefinierade acceptanskriterier, annars blir det svårt att uppskatta dem. En generell Definition of Done/User Story rekommenderas.
Om man väljer att jobba med SPs på US-nivå så kan det vara nödvändigt att använda en ytterligare tidsenhet för varje uppgift som behövs för att utföra en US. Om det är ett team av veteraner som har god erfarenhet av både SCRUM och applikationen i fråga räcker det ofta med SPs på US-nivå, annars kan det vara bra att definiera t.ex. effektiva timmar/uppgift. Om man väljer att definiera tidsenheter på uppgiftsnivå är det viktigt att följa Fibonacci-serien även på den nivån. Min rekommendation är att en uppgift aldrig ska vara större än maximalt 13 effektiva timmar. Helst  mindre än 8h så att det, åtminstone under optimala förhållanden, går att slutföra en uppgift/dag. Generellt väcker det stor tillfredställelse hos människor att få känna att en uppgift är avslutad och klar, således bör det vara vår målbild även i det dagliga arbetet! Det finns ingen given tumregel för hur många uppgifter en viss US behöver utan låt tiden per uppgift vara vägledande. Det man vill komma åt är klar insikt i vad som behöver göras, att täppa till eventuella logiska luckor så tidigt som möjligt samt den insats som krävs för att realisera det som behöver göras.

På vilken nivå ska man mäta hastighet/Sprint?
Det anser jag helt bero på den genomsnittliga storleken på User Stories. Är det realistikt att slutföra flertalet per Sprint? Om ja, satsa på att mäta SPs/US, om nej satsa på att mäta effektiva timmar/US. Som alltid gäller att endast en avslutad uppgift får räknas in i hastigheten. Det är inte OK att räkna med nästan klara uppgifter då dessa alldeles för ofta har en unik förmåga att släpa från en Sprint till en annan. Med samma logik så är det endast en US där alla uppgifter är avslutade som kan räknas till hastigheten om man mäter på US-nivån.
Med denna korta vägledning hoppas jag att ni kan fortsätta utveckla er agila process och göra den ännu mer effektiv. Lycka till!

Äntligen här! Kommande Liferay CE 6.3 kommer med support för att visa annonser integrerat direkt i portalen! Förhoppningsvis kan det med hjälp av cookies utifrån Google och Facebook ge riktad reklam, som passar den inloggade användaren bäst.

Citat:

"Due to the cost involved in producing CE releases we've decided to make this and future community releases ad-supported. What does this mean? It means you'll start seeing advertisements from our sponsors and related products within Liferay and on websites built with Liferay (see screenshots below). And best of all, this is a completely free service for you. Ad revenue will go directly to Liferay and used for improving Liferay, and occasionally used for important executives on important business meetings using a new corporate jet we've leased." (Länk)

 

Ett av de roligare April-skämten idag? Tycker iallafall jag :) Riktigt kul och kreativt av Liferay! Såvida det fortfarande inte skulle stå samma sak imorgon :)

Microsoft utvecklar just nu efterföljaren till Internet Explorer som för tillfället går under arbetsnamnet Project Spartan (msdn.com) och ska finnas tillgänglig i Windows 10. Den nya webbläsaren kommer inte att ersätta IE i Windows 10 utan IE kommer att leva vidare en tid framöver, vilket kan jämföras med hur Windows XP fortsatte att leva vidare en tid innan den slutade supportas. Den nya webbläsaren ska gå under ett nytt namn som ännu inte bestämts/avslöjats. Läs mer här (sophos.com).

 

Anno 2015 har även de flesta större systemutvecklade företag tagit sig så pass långt i mognadsnivå att någon form av agilmetodik tillämpas. Den vanligast förekommande metodiken idag är utan tvekan Scrum.  Låt oss för enkelhetensskull anta att man valt att applicera en klassisk tvånivåsmodell för ärendehantering: Product backlog item (PBI) och uppgift.  En PBI kan ha noll till många uppgifter; oftast ett par stycken. Denna modell är inte tänkt att vara komplett utan främst vara en grund för resonemanget kring Definition of Done (DoD).

Definition av Definition of Done (DoD)

Definition of Done är något som beskriver när en PBI och dess ingående uppgifter anses klara av Scrum -teamet.  Eftersom Produktägaren ingår i teamet så känner även denne till DoD och förstår dess innebörd.

DoDens konsumenter

Den är till för att skapa transparens inom Scrum -teamet (men kan även användas av produktägaren för att spegla status mot stakeholders). Det är därför centralt att alla i teamet förstår vad DoD innebär för de olika typer av aktivteter som teamet åtar sig. Jobbar man i ett företag där flera Scrum -team jobbar i en och samma produkt så behöver det finnas en gemensam DoD för att undvika tråkiga överraskningar i kritiska lägen. Reflektera själv över hur det kan sluta om TeamX har sin DoD och teamY har en helt annant och deras kod sedan ska sammanstråla. Kommer det smärtfritt om deras ändringar överlappar?

DoD behövs

Studier visar att en överväldigande majoritet av alla människor uppskattar att känna att de gör konkret nytta och de tar sig framåt med åtagna uppgifter. Utan en DoD hur ska man någonsin veta när man är klar? Hur ska någon annan veta? Hur ska hen få en känsla för hur hen ligger till?
Således är DoD inte bara viktigt för teamet utan även för individen.

En DoD per typ

Det är viktigt att särskilja mellan DoD för en PBI och dess uppgifter. En uppgift är en väldefinierad avgränsad del av det som behöver göras för att förverkliga PBIn.  Det är av yttersta vikt att alla i teamet förstår innebörden av varje uppgift och dess DoD. Har man inte förstått vad som ska göras eller när det anses klart blir det svårt att uppskatta insatsen som krävs.
Det samma gäller givetvis PBIn. Om den inte går att göra väldefinierad under en grooming eller Sprint-planering är PBIn sannolikt inte mogen för att ingå i en Sprint ännu.

Vår DoD håller inte

Givetvis får man återvända till sin DoD och justera den efterhand. Det är till och med rekommenderat. Se dock till att inte justera den under pågående Sprint! Det kan skapa total förvirring i ledet. Insikterna teamet får efter att ha arbetat tillsammans är guld värda. Det är en av anledningarna till att ”statiska” team är så högt värderad i den agila världen.  
Se således inte er DoD som slutgiltig utan ett pågående arbete.
Kom ihåg:
Det enda som är konstant i världen är förändring!

RSS (Öppnar nytt fönster)
Visar 1-5 av 50 resultat.
av 10