Photo by Clark Young on Unsplash

Jira ile Değişen Hayatlar… Jira’yı Nasıl Kullanıyoruz?

40 yıl düşünsem şöyle doya doya Jira övmesi yapacağım aklıma gelmezdi.

Şakası bir yana, işbu yazıda derdim kendi süreçlerimizde Jira’yı nasıl özelleştirdiğimizi, neler öğrendiğimizi, ne konularda eksik yaşadığımızı paylaşmak. Eğer sizin süreçlerinize bir katkısı olursa ne mutlu, bizimkine ekleyebileceğimizi düşündüğünüz bir şey olur da paylaşırsanız daha da ne mutlu :).

Neden bir iş yönetim aracına ihtiyaç var?

İlk sorulması gereken soru bu olsa gerek. Size “iş takibi abiiee” goygoyu yapmayacağım. Ama asıl sebepleri anlamak için biraz JTBD’cilik oynayabiliriz.

Tek başıma iş yaparken Notes kullanıyorum. Bunun temelde sebepleri şöyle:

1- Ne kadar iş kaldığını, ne zaman “Bitirdim” diyebileceğimi görmek istiyorum.

2- İş sayısı çoğaldığında, hepsini aklımda tutmak için efor sarfetmek istemiyorum.

3- Bitirdiğim işleri gördüğümde kendimle gurur duymak ve vicdanım rahat bir şekilde uyuyabilmek istiyorum.

Bir başkasına bağımlı bir projede ise bir iş yönetimi uygulamasına şu yüzden ihtiyacım oluyor:

1- Ekip arkadaşlarım ne kadar hızlı çalışıyor görebilmek istiyorum. Bu sayede kendimi değerlendirebilirim.

2- Benim işimi bloklayan bir iş varsa ne durumda görebilmek istiyorum.

3- Gelecekte neler yapacağız, şu an büyük resimde neredeyiz görebilmek istiyorum, bu sayede yaptığım işin önemini kolayca anlayabiliyorum.

Bununla beraber, her liste uygulamasında ya da iş takibi uygulamasında asabımı bozan şeyler de yok değil. Her iş kalemi eşit büyüklükte değil. Herhangi bir iş ile onun 4–5 katı büyüklüğündeki başka iş aynı yeri kaplıyor ve aynı süreçten geçiyor. Bu durum benim canımı epey sıkmakta. Henüz bunu çözemedim.

Alternatiflerimiz Neler?

Şimdi ihtiyacı daha iyi biliyoruz. Bütün ekibin ortak olarak kullanabileceği bir araca ihtiyacımız var. Bu aracın kullanımı kolay olmalı ve sürecimize uygun şekilde çalışabilmeli. Hem geçmişi hem de geleceği görebilmeli, yaptığımız işle ilgili detayları bulabilmeliyiz.

Alternatif çok fazla tabii ki. Burada iki yaklaşım sergilemek mümkün; ilki Trello, Asana gibi proje yönetimi ve görev paylaşımı yapabileceğiniz araçlar kullanmak ya da daha uzun soluklu ve periyodik düzende görev dağılımı yapabileceğiniz VersionOne, Jira gibi araçlar…

Biz de ilk etapta “Jira çok bayık” tribine girip bu işi Trello ile kotarabileceğimizi düşündük. Lakin olmuyor. Özellikle uzun süreli işlerde Trello’nun limitli özellikleri her ne kadar PowerUp’larla coştursanız da yetmiyor. Trello’nun mimarisi aşağı yukarı şöyle:

Trello Mimarisi

Oysa Jira ya da VersionOne tipi araçlar şöyle bir mimari sunuyor:

Jira Mimarisi

Görsellerde atladığım şeyler olabilir, lakin temel mesajı veriyor. Bizim 2 mobil uygulama 1 internal dashboard ve 1 external dashboard olmak üzere 4 adet ürünümüz var. Hatta bu listeye bütün bu ön yüzleri besleyen ve bunun haricinde de kullandığımız Backend API’ı da eklersek 5 temel ürün. Bunların roadmapleri tahmin edeceğiniz üzere birbiriyle oldukça sık kesişiyor. Ama sadece kendilerini ilgilendiren geliştirmeler de mevcut. İşin daha fazla detayına girip sizi boğmayacağım ama bizim için de şöyle bir yapı var:

Hal böyleyken ister istemez daha yetenekli bir araca ihtiyaç duyuyoruz. Peki Asana’lar Trello’lar gitti. Elimizde kalan tek şey Jira mı? Hayır. Atlassian bir süredir bütün ürünlerini yeniliyor ve daha güzel arayüzlü, mobil destekli hale getiriyor. Fakat bundan 1 sene önce durum tek kelimeyle üzücüydü. Sadece Jira değil VersionOne vs. de en az Jira kadar çirkindi(onlar hala öyle).

Siz de eğer benim gibi bir online ürün hipsterıysanız Jira’dan daha güzel görünen bir tek ürün var: Craft.io. Hakikatten güzel. Lakin orada da subtask olayını çözemediğimizden ilerleyemedik. Bir de ürünü o kadar güzel yapmışlar ki, yaptığınız işe odaklanmak yerine çeşitli butonlara basasınız geliyor. Daha önce beni bu sendroma sokan başka ürünler de olmuştu. Yine de eğer subtask ihtiyacınız yanıp kavrulmuyorsa Craft’a bakmakta fayda var.

Jira’nın en büyük artısı aşırı derecede özelleştirebileceğiniz yapısı. Şimdi biraz Jira’yı işimize yarar hale getirmek için yaptıklarımızdan bahsedeceğim.

Bizim Jira

Bugüne kadar çalıştığım bir çok firmada Jira’nın kullanıldığını gördüm. Fakat neredeyse hiç birinde herhangi bir özelleştirmenin yapıldığına şahit olmadım. Genelde workflowlara, issue type’lara çok dokunmadan, amiyane tabirle etliye sütlüye karışmadan Jira kullanılmaktaydı. Ben de daha önce hikayeye hep sonradan dahil olduğumdan pişmiş aşa su katmak istemedim, ortama uyum sağlayıp çok da kurcalamadım neler yapabildiğimizi.

Twentify’da ise hikayeyi sıfırdan yazıyorduk. Haliyle duvarları kırıp, neler yapabileceğimizi anlamak ilk önceliğimizdi.

Boards & Workflows

Jira üzerinde şu anda 6 tane board bulunmakta.

Twentify Dev bizim ana boardumuz. Backlog’u orada tutmaktayız. Geliştiricilerin görevlerini aldığı ana yer burası. Scrum teması seçilerek açıldı. Workflow da şu şekilde;

“Currently Working On” sectionı tam olarak o anda kim ne ile uğraşıyor görebilmemiz için “In Progress”ten ayrılmış vaziyette. “In Staging” statusunun “Ready To Deploy” kolonunda olmamasının sebebi de Jira’nın ‘Resolved’ hesabını bozuyor olması. Yoksa onun asıl durması gerek yer bir yandaki kolon. Bu boardun doğrudan bir issue collector’ı yok. Tamamen bizim kontrolümüzde.

Operational Tasks, sadece internal dashboardumuz üzerine gömülü issue collector ile dolan bir board. Burada “Basic Project Management” temasını kullandık. İşimizin biraz doğası gereği sık sık (~aşağı yukarı 2 günde 1) operasyonel olarak yapılması gereken bir işle karşılaşabiliyoruz. Genellikle raporlama ve mobil uygulamada yaşanan problemlere ilişkin oluyor bu işler.

Burada şöyle bir workflow kurguladık:

Bu boardun bir diğer önemli özelliği tamamen public olması ve issue collector üzerinden bildirim yapan şirket sakinlerinin bu işin durumunu doğrudan takip edebiliyor olması.

Design & UX boardu ise Kanban temasıyla açtığımız tasarım işlerinin içerisinde bulunduğu mekanımız. Tasarımda Kanban uygulamamızın sebebi, sabit zaman aralıklarının tasarım ihtiyaçları için iş görmüyo oluşu ve aynı anda limitli sayıda noktaya odaklanmak isteyişimiz.

Orada şöyle bir akışımız var:

Bu boardun Jira’da olmasının güzelliklerinden bir tanesi, farklı boardları birbiriyle ilişkilendirebilmek. Yani Design&UX boardunda Done kısmına geçmiş bir iş daha sonra Twentify Dev üzerinde linklenebiliyor. Bu sayede geliştirici tasarım ihtiyaçlarına Jira üzerinden doğrudan erişme olanağı kazanıyor(pratikte bunu henüz beceremedik :) ).

Product, Product Requests, Dreams&Ideas boardları bizim için birer Trello niteliği taşıyan yerler. Buradaki tek istisna Product Request boardu için de issue collector kullanmamız.

Özetle boardları ürünler özelinde açmak yerine disiplinler özelinde açmayı tercih ettik. Bu sayede aynı disiplinde çalışan insanların ortak işlerini tek bir yerden görme fırsatı oldu, diğer disiplinlerdeki bağlı işleri ise görev ilişkilendirmeleriyle çözdük.

Issue Types

Bütün boardlarda kendilerine özgü issue typelar kullanıyoruz. Ama burada sadece ana boardumuz Twentify Dev için olanları inceleyeceğim.

• Epic
• Story
• Platform Task
• Task
• Bug
• Research
• Team❤

Epiclere mümkün mertebe ekleme çıkarma yapmıyoruz. Şu an için 21 tane epic konumuz var. Bu konular bizim uzun dönem boyunca maintain etmemiz, geliştirmemiz gereken konular. Aslında her birini minik birer ürün gibi de düşünebiliriz. Yani Twentify çok büyüdüğünde — KOCAMAN OLDUĞUNDA MESELA — 21 tane ürün ekibi çıkabilir gibi düşünebilirsiniz. Yapılan her iş mutlaka bir epic’e dokunmak durumunda. Eğer bir iş herhangi bir epic’e girmiyorsa, belli ki bir şeyleri hatalı yapmışız demektir. Bu durumda ya yeni epic açılır ya da varolan epicler gözden geçirilir.

Storylerin bizdeki anlamı normalde olduğundan biraz daha farklı. Yazının başında temelde 5 adet ürünün olduğunu söylemiştim. Kimi zaman geliştirdiğimiz konular birden çok ürüne aynı anda etkileyecek şeyler oluyor. Somutlayalım; internal dashboard’umuz üzerinde bir tane anket hazırlama aracımız bulunmakta. Bu anket hazırlama aracına yeni bir soru tipi ekleyeceğiz: Video Soruları. Bu geliştirme, hem internal dashboardda, hem external dashboardda, hem mobil uygulamalarda, hem de Backend API tarafında geliştirme gerektiriyor. Bu da bizi Story’ye getiriyor. Bu şekilde yapacağımız geliştirmelerle ilgili bütün detayları, dökümantasyonu (eğer Confluence’a yazmamışsak) Story içerisinde topluyoruz. Adettendir diye bir adet gerçek User Story’yi de ekliyoruz içine :). Daha sonra her platform için birer Platform Task tipinde issue açılıyor. Örneğimizde tam 5 adet Platform Task açıldı demek oluyor :). Daha sonra Story ile bu tasklar arasında “has” ilişkisi kuruyoruz. Bu sayede hem bilgi yalnızca 1 kere oluşturuluyor, hem de ayrı ayrı süreçlerini takip etmek mümkün hale geliyor. Burada Platform Task yerine sub-task olamaz mıydı? Muhtemelen olabilirdi ama bize böylesi çok daha kolay geldi.

Platform Task’tan bahsettim. Sadece Platform Tasklar aslında dummy issue type olduğu için, içeriğini de boşalttığımızı bilmenizde fayda var :).

Tasklar tek başına yapılabilen, başka bir bağımlılığı olmayan işler. Örneğin internal dashboardda yapılacak bir bilgi mimarisi değişikliği yalnızca o component’ı ilgilendiren bir Task. O yüzden bu şekilde açılıp, bilgilendirme bu şekilde giriliyor.

Bug ve Research kerameti kendinden menkul isimlere sahipler zaten, detaya girmiyorum.

Team ise yan projeler, dev-ops işleri vs. için kullandığımız issue type.

Herhangi bir issue’da mutlaka Epic, Labels, Components kullanılmakta. Hızlı filtrelerimizi bunlar üzerinden çalıştırıyoruz.

Estimation & Schedule

İşlerin büyüklüğüne ilişkin varsayımları custom field olarak açtığımız Story Point üzerinden takip ediyoruz. Jira bu işi zaman yönetimi çerçevesinde değerlendirmiş. Scrumla ilgili anlaşamadığım konulardan en önemlisi bu. 2 haftalık time-boxlar içerisinde sprint koşarken, alınan işleri 2 haftaya sığdırmaya, boş kalan yerlere ufak işler bulmaya çalışır noktaya geliyorsunuz günün sonunda. Dev bir saçmalık. Sistem bizim işimize yaramalı, biz sistemin işine yaramaya çalışmamalıyız.

Bu sebepten ötürü kendi yaptığımız 2 haftalık periyotları aslında sadece durum değerlendirmesi yaptığımız mihenk taşları gibi değerlendiriyoruz. Bir sprintteki bütün taskların tamamlanması ya da tamamlanmaması bizim için herhangi bir sorun teşkil etmiyor. Yeri geldiğinde başka bir şeyi ekleyebiliyoruz, yeri geldiğinde çıkarıyoruz. Bütün hikaye doğru önceliklendirmeyi doğru saikler çerçevesinde yapabilmek ve bunu yaparken herkesi flow’da tutabilmek.

Extensions (Add-ons)

Jira’nın herhalde en dandik yanı eklenti ekosistemi. Hakikatten baştan aşağı leş eklentiler ve para tuzaklarıyla dolu gibi geliyor bana. Biz parayla sadece All-In-One Jira Reports’u kullanıyoruz. Bu eklenti Jira’nın varsayılan raporlarının yanına çok daha ekstrem raporlar oluşturabileceğiniz bir araç. Custom Field olarak açtığımız Story Point üzerinden performans ölçümümüzü de bu sayede çok daha rahat yapabiliyoruz. Jira’nın getirdiği Velocity Report ve Sprint Report dışında en çok kullandığım raportlamalar All-In-One üzerinde kendi yarattıklarım.

Bunun haricinde Confluence’a draw.io çıktılarını gömmemizi sağlayan bir extension daha var ama çok mühim olduğunu düşünmüyorum.

Integrations

Entegrasyon tarafında ise Jira çok daha başarılı. Benim en hayran olduğum entegrasyonumuz Rollbar ile kurduğumuz ilişki. Ürünlerde alınan exceptionları Rollbar üzerinden takip ediyoruz. Aynı exception “n” kere alındığında Jira’da otomatik olarak Bug açılıyor ve backloga ekleniyor. Ürüncüler olarak “yeni”nin peşinde koşmaya çok meraklıyız bu yüzden elimizdekini koruyabilmek kimi zaman önemsemediğimiz bir konu oluyor. Bu tarz otomasyonlar bunun önüne geçmek için çok kritik.

Bunun haricinde Jira’nın bir çok başka toolla entegrasyonu var. Slack ve Trello entegrasyonları aracılığıyla iletişim ağımızdaki başka araçlarda doğrudan issueları paylaşabiliyoruz. Git ile de bir entegrasyon var ama bir türlü kontrol edemeyip Jira saçma sapan hareketler yaptığı için, bunu kullanmaz olduk :).

Ve Issue Collector’lar. Her ne kadar istediğimiz kadar özelleştiremiyor da olsak, issue collector’ları mümkün olan her açık alana yerleştirmeye çalışıyoruz ki neler olup bittiğinden haberdar olalım. Sadece bu iş için kullanılabilecek geribildirim araçlarına dünya kadar para vermek yerine Jira’da hali hazırda bulunan bu özelliği ziyadesiyle sömürüyoruz diyebilirim.

Nasıl daha iyi yapabiliriz? Eksik kalan yerler neler?

Son bir sene içerisinde biz kurduğumuz sistemi üzerine koyarak inşa ettik. Bir kural kitabı hazırlayıp ona riayet etmek değil, kendimizi tanıyıp ihtiyaçlarımızı analiz edip bunun özelinde sistemin adını koyarak ilerliyoruz. Ürün geliştirirken kullandığımız yaklaşımın aynısını sistem geliştirirken de kullandığımızı, sürekli tekrarlayarak bir şeyler ekleyip bir şeyler çıkararak ilerlediğimizi söylemek en kolay özeti olacak.

Şu sıralar gözümüze çarpan en önemli eksiklerimizden biri, 3 ayrı ortam (test — preprod — prod) kullanmak yerine 2 ayrı ortam kullanmamız (staging — prod). 2 ayrı ortamı yönetmesi elbette çok daha kolay. Fakat UAT testleriyle, kullanılabilirlik testlerinin aynı ortamda yapılması iş akışında anlamsız durumlara sebep olabiliyor. Canlı ortam datalarından ziyade, test ortamında “canlıya yakınsayan ortam” datalarıyla son kontrollerimizi yapıyoruz. Jira’nın iş akışını ise sanki 3 ayrı ortamımız varmış gibi kurguladık. Bir iş “In UAT” durumundan “Accepted” durumuna geçtiği durumda, aslında zaten staging’de olduğu için iş “In Staging”e de geçmiş oluyor. Bu durumda “Accepted” anlamsız bir durum halini alıyor.

Jira ya da başka bir şey, bir araç neden kullanılır?

Son olarak ara ara değindiğim konuya tekrar gelmek istiyorum. Bizim Jira’yı nasıl kullandığımız elbette sizin için kritik bir bilgi değil. Ama mühim olan konulardan ilki şu, lütfen siz de öğrendiklerinizi paylaşın. “Aaa, öyle bir şey yapabiliyor muymuşuz?”u birbirimizden esirgemeyelim. Diğeri ise kullandığımız metodolojilerin, araçların bizi yönetmesine engel olmak lazım. Bu seneler geçtikçe daha da farkettiğim bir durum. En iyiye giden yol, her şirkete her ekibe ayrı şekilde çizilmesi gereken bir yol. O yüzden “bunlar her yazılım, ürün ekibinde olan şeyler” varsayımıyla ortaya çıkmış bütün metodlar sizi “en iyi”den uzak tutacak ve en fazla “mediocre” seviyeye çıkaracak şeyler. Bu metodlar sayesinde devasa yanlışlar yapmayız muhtemelen ama potansiyelimizin en üst seviyesine de çıkamayız. Bunun için bir oyun hamuruymuş gibi yoğurmak lazım elimizdeki her şeyi. Yukarıdaki hikaye bizim yoğurduğumuz hali :).

Umarım keyif aldığınız, faydalı bir yazı olmuştur. Paylaşarak, alkışlayarak önce benim mutluluğumu ardından kolektif bilgiyi çoğaltabilirsiniz :). İlerleyen dönemde kullandığımız diğer araçlarla ilişkimizi ve kendi içimizdeki seremoni çemberimizi de anlatmak istiyorum. Yayındaki diğer yazılarda da bize dair çok şey bulmanız mümkün.