Det börjar brännas ordentligt nu gällande HTTP/2. Alla stora webbläsare har stöd för det men få verkar hoppa på tåget? Syftet med HTTP/2 är främst prestanda och det kan man väl knappast få för mycket av?

Java-gurus väntar måhända på Servlet 4.0 men många fördelar finns redan där bara att hämta hem. Bara att det är multiplexed(hur vi nu översätter det på svenska?) samt att det är binärt tillsammans med header-optimeringen bör snabba på en stor mängd siter redan nu. Server push känns intressant också men det får vi i java-världen vänta på givet att man inte vill köra något väldigt "bleeding edge".

 

 

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).

 

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