Atlassian

[embed]
[/embed]

[embed]
[/embed]

[embed]
[/embed]

Hipchat har länge varit ett alternativ till Slack för grupp kommunikation, men hittils är det Slack som gått segrande i de flesta fallen. Nu ger Atlassian ut en ny variant på Hipchat som heter Stride och den ser riktigt intressant ut.

 

 

 


[embed width=960" height="540]http://www.youtube.com/watch?v=tkIITaq9shk[/embed]


 

Jag vet inte hur många gånger som Slack varit det som använts i projekten jag varit med i, men det har varit i nästan alla projekt vill jag påstå. Jag har försökt några gånger att introducera HipChat, men utan någon riktig framgång. Mest för att jag själv inte ser nyttan över Slack.
Stride är Hipchat, fast som den skulle ha varit. Samma härliga uppsättning med rum och användare som Slack och HipChat, fast nu med större fokus på direkt kommunikation. Grupp samtal med video, skärmdelning och till och med remote access är precis vad många team saknar och det kommer nu med Stride.

Beslut och att göra listor kan göras direkt i Stride, vilket är mycket, mycket användbart. Det inbyggda fokusläget är perfekt för utvecklare som behöver kunna fokusera, men ändå vill hålla sig uppdaterade.

 


Med samma fantastiska integrationer med resten av Atlassian sviten som slår Slack på fingrarna så kan jag mycket väl se Stride som en lämplig ersättare för Slack i framtiden och jag ser fram emot att läsa mer om vart Stride hamnar när det gäller kampen om användarna i IT projekt.

Vad tror du om Stride? Kan det ersätta Slack i framtiden och i så fall vad tror du behövs för att Stride ska lyckas med det?

Atlassian med sitt flaggskepp Jira och sidekicken Confluence annonserade i början på Juni att man kommer att ta bort fyra av de mest populära pluginsen, nämligen Greenhopper, Bonfire, Team Calendars och Sharepoint connector...eller snarare så kommer man att byta benämning på dem.
 
För mig som jobbar dagligen i Jira/Confluence med Greenhopper så satte jag kaffet i vrångstrupen när jag läste att Atlassian skulle ta bort Greenhopper, men som tur var så är det bara benämningen som försvinner, inte produkten. I ett försök att förenkla så har man valt att ändra namnen på de fyra pluginsen så att de knyts närmare till Jira och Confluence.
 
 
 

 
På Atlassians blogg blev det genast lite diskussioner hurvida det var ett bra eller dåligt drag från Atlassians sida, men jag tror att det bara kommer att handla om vana för det kommer ju att ta ett tag att vänja sig vid att säga Jira Agile istället för Greenhopper osv. I övrigt tycker jag det är ett smart drag av Atlassian och det blir tydligare vilken grundprodukt som pluginet hör till.
 
Vad tycker du, bra eller dåligt att byta namn på produkterna?

Cloud, Server och Data Center. Tre distinkt olika produktlinjer. Detta är för mig Atlassians stora problem idag. Inte nog med att det komplicerar för kunderna, det skapar en hel del oreda för utvecklarna också.
När du ser alla häftiga och underbara nya funktioner för till exempel Jira, ja då är det nästan alltid Jira Cloud som du ser. Server varianten ligger alltid rejält efter och DC lite efter Server.
Om vi kikar vidare på Jira så har Jira server inte ens fått den nya layouten som Jira cloud har haft ganska länge nu. En liten refresh kom i höstas, men den stora design ändringen får vi nog vänta på till efter Jira 8. Då är vi över ett år bakom Cloud, förmodligen närmar två år till och med.
Om du jobbar på ett någorlunda stort företag så har du förmodligen server eller datacenter varianten av Atlassians produkter. När då Atlassian släpper nya funktioner för Cloud så kommer det alltid en hel del förfrågningar på när de funktionerna kommer till din produkt. Av den enkla anledningen att för den stora massan så är exempelvis Jira en produkt och inte tre.
Bortsett från den lilla frustrationen att alltid ligga steget efter och att användarna inte förstår varför de inte får sina funktioner nu utan måste vänta år på att få dem så har vi plugins också.
Återigen så förstår inte användarna skillnaden mellan de olika varianterna på Atlassians produkter. Ingenting är så frustrerande som att diskutera ett plugin eller kanske till och med ta fram budget för att köpa in det, bara för att upptäcka att det bara finns till en annan variant än den du har.
För de som bygger plugins så blir det också en hel del extra jobb att bygga för flera versioner. Inte nog med att du måste hålla koll när du bygger pluginet, du måste också hålla koll på minst 2 versioner i varje release. Det är en av anledningarna till att många plugins bara finns till en av versionerna.
För Atlassian själva så blir det en del extra arbete i supporten där man måste be kunderna specificera inte bara produkt, utan vilken variant av produkten. Dokumentationen ska göras i tre varianter och alla defekter och förslag på förbättringar måste hanteras i tre parallella varianter.
 
Jag förstår varför man vill hålla olika versioner, men för slutanvändarna är det ingen bra upplevelse. För utvecklarna är det krångligt och fler än en administratör har lyckats köpa fel licens och blivit lite småsura på sig själva.
Jag skulle gärna se att Atlassian fokuserar på en version för att minska slöseriet av utvecklings tid i tre paralella versioner av samma produkter OCH för att minska förvirringen hos deras kunder.
Det lär inte hända den närmaste tiden, men vill man utmana giganter som ServiceNow så måste man kunna få ut nya produkter och funktioner snabbt. Det blir mycket svårare med tre parallella produktlinjer...
 

Atlassian har presenterat nya Jira och deras nya Next Gen vision och det ser fantastiskt ut! Med en ny layout för boards som är tydligt inspirerat av Trello som Atlassian numera också äger så ser boards mer dynamiska och kraftfulla ut än någonsin. Nya funktioner som timelines som jag vet att många använder plugins för idag så kommer du att älska nya Jira.
 

 
Nya Jira är en helt ny upplevelse samtidigt som den fortfarande har samma Jira känsla i botten. Jag ser framför mig en helt ny användarbas som kommer att tycka att Jira är fantastisk och det är icke-utvecklande teams som idag använder Trello eller Planner.
 
För dessa användare så har det länge varit lite an en tröskel med Jiras lite fyrkantiga upplägg. Med Next Gen boards så har dessa användare nu samma fantastiska upplevelse som i mindre verktyg som Trello och Asana. Samtidigt så ligger de utvecklingsnära när deras arbete ska realiseras i kod eller implementering.
 
Jag ska skiva lite om varje funktion tänkte jag om någon är intresserad?

Äntligen är det dags att sätta tänderna i en certifiering igen. Den här gången är det JIRA och Confluence som ligger framför mig, något som jag haft på min att göra lista ganska länge. Det passar dessutom riktigt bra just nu eftersom jag sitter som JIRA expert på mitt nuvarande uppdrag.
 
Planen är att plugga på lite nu i Januari och Februari för att sedan ta dubbel certifiering i Mars eller April. Det beror lite på hur mitt uppdrag ser ut och hur mycket tid jag har att plugga. Det är ACP-100 och ACP-200 som jag kommer att ta. Jag funderar på ACP-500 och ACB-110 också, men de väntar jag lite med känner jag.
 
Förberedelserna blir att plugga lite och jag har köpt in två böcker för att få lite myspys att dyka ner i. Jag kommer att posta recensioner om dem i Februari troligtvis så du vet om det är värt pengarna. Jag kommer även att köra certification prep innan certifiering för att kolla vad det är för något.
 
Eftersom det blir mycket JIRA nu framöver, både med certifieringarna och i mitt uppdrag tänkte jag köra en serie här där jag går igenom grunderna och ger lite tips och tricks. Om det går bra kanske det till och med blir en lite bok om det också vad det lider. Det verkar som att många saknar en svensk bok om JIRA och Confluence.
 
Har du några frågor om JIRA eller Confluence som du vill ha svar på?

Det finns många plugins till Jira som är väldigt bra, men ibland dyker det upp plugins som ger en liten extra wow känsla. Label Manager för Jira är ett sådant plugin då det har flera, väldigt användbara, funktioner i ett plugin.
 
Ett behov som många användare av Jira har är att det saknas möjlighet att ha ett dynamiskt uppmärkningssystem som enkelt kan administreras, men inte missbrukas. Labels använde många, men det är en lös koppling med många möjligheter till att göra fel.
 
Andra använder Components som fungerar precis som många önskar, men det är bara ett fält som ofta behövs för just komponent gruppering. Det saknas med andra ord något och det är där som Label Manager för Jira kan fylla det tomrummet.
 
Med Label Manager kan du definiera upp ett eller flera custom fields att fungera med Label Manager. Som projekt admin kan du sedan hantera värdena för dessa custom fields, ungefär som du gör med Components. Användarna kan sedan välja från de definierade värdena, precis som för Components.
 
Bara där fyller Label Manager en viktig lucka genom att ge projekt admin kontroll över värdena som användarna sedan kan använda. Det finns dock ytterligare en dimension som gör Label Manager till något ännu mer användbart: Färgkodning som kan kopplas till workflows!
 
Om projekt admin så önskar kan man aktivera Label Coloring. Detta gör att de värden som definieras har 4 states som kan ändras genom att man klickar på dem. Grå, röd, gul och grön färg finns att tillgå vilket gör att det är enkelt att använda som en slags checklista för till exempel definition of done.
 
Label Manager har ytterligare en funktion och det är att det går att sätta upp regler i arbetsflödet. Reglerna kan baseras på om ett värde finns innan transition får genomföras (mandatory) och du kan till och med definiera att värdena måste ha en viss färg för att tillåta transition.
 
Jag har sett många riktigt, riktigt bra plugins till Jira och Confluence och Label Manager är en av de mest flexibla och användbara pluginsen som jag sett på senaste tiden. Prislappen är helt ok med tanke på det värde som man får och pluginet verkar väl supportat med regelbundna uppdateringar från Codecentric som är ett välbekant namn bland Jira Plugins.

Som gruppledare för Atlassian Stockholm så ska det planeras minst 4 events per år. Under 2018 blev det inte riktigt så av flera anledningar, men nu sätter vi igång med planerna för 2019. Totalt är det 8 tillfällen som är inplanerade, men det finns gott om utrymme för flera tillfällen.
Planeringen för 2019 är att experimentera lite med tider och dagar. 4 tillfällen blir kvällsmöten med ett tema. Tanken är att hålla två presentationer per kväll med lite tilltugg. 4 tillfällen blir kortare morgon möten med en presentation där vi fokuserar på att låta medlemmarna presentera och göra en liten kompetens överföring.
Riada och Claremont ställer upp med lokaler så jag ska boka upp de tillfällena som är satta. Nästa steg blir att be medlemmarna om ämnen och boka in presentatörer för eventen. För det håller jag på att sätta upp Jira Service Desk så vi har en naturlig plats att hantera inflödet av medlemskontakt. Jag har även satt upp en publik Confluence för att hantera filer och mötesanteckningar och så vidare.
De preliminära datumen för 2019 är följande:
Event (vanliga kvällsevent av AV-typ)
19:e Mars 28:e Maj 19:e September 5:e December QuickTalks (30-60 minuters morgon möte)
19:e Februari 23:e April 19:e Augusti 12:e November Samtliga event kommer att läggas upp på AUG Stockholm så fort planeringen är klar. Just nu så är det framförallt lokalerna som ska säkerställas och sedan kan vi börja lägga in olika ämnen. Jag har redan fått lite förfrågningar om GDPR, Bitbucket Pipelines, Slack integrationer och så klart lite hands on i nya Jira Cloud. Jag funderar även om det kan vara lämpligt med lite introduktioner till Bitbucket, Crowd, och Bamboo då de sällan får så mycket uppmärksamhet.
2019 kommer att bli riktigt spännande för oss som gillar Atlassians produkter, så varför inte kika över till AUG Stockholm och registrera dig så du inte missar något? Det är gratis och kommer helt utan krav. Om något vi presenterar verkar intressant, då är du alltid välkommen, men det finns inga krav på närvaro eller liknande.
 
 

Som du kanske redan vet så är jag gruppledare för Atlassians Stockholmsgrupp och i veckan höll jag en presentation om design av arbetsflöden i Jira. Det är ett ganska populärt ämne och jag fick bra feedback.
Presentationen i sig är ingenting konstigt egentligen, men eftersom så många som designar arbetsflöden i Jira inte förstår skillnaden mellan flödesscheman och tillståndsdiagram så brukar man bland friskt. Resultatet när man gör det blir sällan bra och du måste skapa manualer och alternativa flöden för att flera grupper ska kunna arbeta inom samma flöden.
Förutom en väldigt kort genomgång av de olika designprinciperna jag använder och en förklaring om vad skillnaderna mellan transitional och producing items är så gick jag även igenom nackdelarna med flera stängda statusar och varför krav och deploy inte bör vara en del av arbetsflödena.
Saker som att inte designa flöden isolerat så det blir flera olika statusar för samma saker eller att saker som faktiskt följer samma flöden, som defekt och utveckling, inte har olika flöden eller statusar.
Lite kort om att jobba med boards istället för projekt så att alla kan samarbete över projektgränserna blandade jag med en lite annorlunda hierarki inspirerat från SAFe. Även en standard princip som fetch and release verkade ganska okänd och många gillade tanken att färgkoda issue types utifrån ansvarsområden.
Överlag var det en trevlig presentation som blev ännu bättre tack vara en engagerad publik som ställde många bra och intressanta frågor. Många uttryckte en önskan att höra mer om hur SAFe kan sättas upp i Jira och Confluence och det vara några som med mig identifierat vissa brister med Portfolio for Jira till exempel.
Nästa AUG möte är planerat till Augusti med ett nytt spännande ämne, så missa inte det! Vill du att jag ska komma och dra den här presentationen för din organisation så säg bara till.