Çoklu Repolarımızı Azure Board Üzerinde Yönetebilir miyiz?

Hanifi Tayfur
lTunes Tribe
Published in
5 min readOct 29, 2020

Çok repomuz, çok projemiz var tek board üzerinden yönetebilir miyiz? Bilmiyoruz çözüm üretiyoruz, deneyeceğiz.

Agile nedir, scrum, kanban ya da diğer proje/ürün yönetim modellerine girmeyeceğim. Belki bu konuya daha sonra değiniriz. Bunları kenara koyarak proje/ürün yönetim modellerinden herhangi birini kullandığımızda “board” ihtiyacını içten içte hissederiz. Özellikle bu pandemi döneminde uzaktan çalışma modeline geçtiysek ihtiyaç kaçınılmaz hale geliyor.

Daha önce çalıştığım agile takımımızın scrum masterı ve ekip agile konusunda yetkin ve başırılıydı. Buradan onlara selam olsun, her ne kadar duymasalar da :) Bu başarılı ekip ile geliştrmeye çalıştığımız x’ler ile dolu bir ürün üzerinde çalışıyorduk. Ürün mü proje mi konusunda çok konuştuk, tartıştık. Ürün de olsa proje de olsa yönetimini Azure DevOps kullanarak gerçekleştirdik. Bir zaman sonra tek repo ve tek board üzerinden yürüttüğümüz serüvene ek olarak yeni proje daha geldi. Artık x ve y adında (x ve y proje isimleri simgeseldir) geliştirmeye çalıştığımız iki projemiz vardı. Bu durum bize yeni bir sorunu da doğurdu haliye. İki projeyi aynı ekip ile “nasıl yönetiriz” sorunsalı. Çözüm olarak ekipçe şöyle karar alındı; zaten microserviceler üzerine kurulu yapımız var gelen projeyi ayrı bir servis olarak düşünüp tek board üzerinden yöneteceğiz. Makul mu ihtiyaca göre evet.

Eski konulara neden girdim..?
Yaşadıklarımızdan ders alabilirsek ve yeni şeyler öğrenebilirsek bu
tecrübe olur, yaşadıklarımızdan ders alamıyorsak, hayatımıza ders anlamında bir girdisi çıktısı olmamışsa bu kazık olur.

Şimdi ise yukarıda anlatmış olduğum duruma benzer ama daha büyük bir sorumumuz var. Azure Devops üzerinde tek organizasyon, yüze yakın belki daha fazla repolarımız (gerçek hayatta proje) var. Boardumuz ise farklı bir mecrada, plannerda. Çok Kalabalık bir ekip, çok proje ve tek yönetim ortamını hayal ediyoruz.

Zaten Azure DevOps’u kullanıyoruz ve bu toolu da çok başarılı buluyorum. “Neden boardumuzu Azure DevOps’a taşımıyoruz?” tartışmalarına girdik. Bu tartışmalarımız hala devam ediyor, çözümlerimizi henüz hayata geçirmedik. Bu soruna yönelik çözümlerimiz,düşünlerimiz, seçeneklerimiz var bunlardan söz edeceğim. Sözünü edeceğim çözüm seçeneklerinden birini hayata geçireceğimiz olursa, tecrübe ettikten sonra, verdiğimiz bu kararın etkilerini, avantajlarını ,dezavantajlarını da anlatmak istiyorum.

Çözüm seçeneklerimizden birine karar vereceğiz. Karar vermemizde etkili olacak parametrelerimiz var, bunları mutlaka düşünmek zorundayız.

  • Proje sayısı kadar developer yok
  • Proje sayısı kadar product owner(PO) yok
  • Ekipler farklı developerdan oluşabilir
  • Aynı developer farklı ekipte olabilir
  • Bir PO farklı ekipte olabilir
  • Bazı projelerde tek developer çalışıyor olabilir. Tek başına bir ekip yani. Ekipsiz ekip ama ekip :)

Tüm bu parametleri kapsayacak ve aynı zamanda ekibin genel durumunu, projelerin gidişatını tek bir board üzerinden yönetmeyi hedefliyoruz.

1- Multi Project — Single Repo — Multi Board

Azure DevOps
Azure DevOps

Her bir repoyu bir proje gibi düşünüp boardunu da ayrı kurgulayabiliriz. Bu repo sayısı kadar board demek. Yani organizasyonumuza yeni projeler yaratacağız , yarattığımız bu projenin hayat serüveni kendisine has olduğundan boardu da ayrı olacak. Bu işlemi, New project butonundan ilerletebiliriz.

Her projenin kendine ait reposu ve boardu olacağından dolayı gayet temiz.
Peki ayrı ayrı olan bu projeleri ve boardları tek bir ana board üzerinden nasıl göstereceğiz? Bu bizim için çok önemli.Queryler ile yapılabilir mi diye baktım ama maalesef. Dolasıyla bu seçenek kendi içerisinde ne kadar tutarlı ve güzel dursa da ihtiyacımız karşılamıyor gibi duruyor.

Azure DevOps’un kullanılabilir çok başarılı Chart ve Dashboard özelliklerinden de faydanabilmemizi de zorlaştırıyor.

2- Single Project — Single Board — Multi Repo — Multi Tag

Tek projemiz, onlarca repomuz ve tek boardumuz var. Yukarıda sözünü ettiğim parametreleri düşündüğümde çözüm gibi duruyor. Detayı şu. Proje-1 adıyla tek bir projemiz, projemin altında onlarca repomuz olacak.

Repolarımız çoklu,bu zaten parametrelerimizden biriydi. Peki repo bazlı epic, feature veya user story’leri ve hatta bug kayıtlarını (Work Item) nasıl yaratabilirim?

Herhangi bir workitem detayında “tag alanına” projenin adıyla tag yaratıyorum

Yarattığım bu tag’e yeni “tag rule” tanımladığımda tek board üzerinden veya backlogdan farklı renk kartlarıya görebiliyorum.

Bu bir çözüm ama içime sinmeyen bir çözüm. Boardu tag ile ayrıştırmak ilerde farklı sorunlar doğurabilir. Stabil değil. En önemlisi ise tage bir iş kuralı yüklüyoruz. Kelimelere, rakamlara iş kuralı yüklemekten kaçınmamız gerektiğini düşünüyorum.

3- Single Project — Single Board — Multi Repo — Multi Areas

Yeni bir kavram olarak areası görüyoruz.
Proje ilk create edildğinde azure devops sizin için projenin adıyla base bir board ve area yaratır, default olarak tanımlar. Azure DevOps’un en çok sevdiğim özelliklerinden biri, tanımlanan ayarları ihtiyacımıza göre customize edebiliyoruz. Board kolonlarını, workitem tiplerini, areasları kısacası repo, board, team gibi bir çok alanını customize edebiliyoruz.

Başından beri çözmek için düşündüğüm sorunu sanırım Azure DevOps’un sunduğu bu hizmet ile çözebilirim.

İşlem adımlarımız sırasıyla,

  1. Project settings
  2. Board- Project configuration
  3. Areas
  4. New child
  5. Team configuration
  6. Areas
  7. Select Area

Board- Project configuration altında bulunan “Areas” tıkladığımızda sözünü ettiğim default cerate edilmiş area görünücektir. Ben de bunun karşılığı “Interaktif Projeler Demo”. Bu itemı seçerek child eklediğimize dikkat edelim. Yoksa seçtiğimiz areanın altına ekleyecektir.

Bir sonraki işlemimizin ekran görüntüsü şu şekilde.

Team configuration menüsü altında bulunan Areas tabını seçiyorum. Select Area diyerek project configuration alanında oluşturduğum areslar listenecektir. Eklemek istediğim area ile birlikte “include sub areas” seçerek save diyorum.

Include sub areas senaryomuzda çok önemli bir görevi var. Seçtiğiniz areayı default base areamıza dahil eder ve default areanın bir parçası gibi davranmasını sağlar. Bu bakımdan bizim senaryomuzda bu alanı mutlaka seçmemiz gerekiyor.

Bu ayarlamalarımız yaptıktan sonra boardumuza giderk “style rule” tanımı yapıyoruz.

Burada hoşuma gitmeyen durum, boardunuzu workitem bazında renklendirmek istiyorsak bu işlemi tüm workitemlara ayrı ayrı yapmamız gerekiyor. Ekranda görüntüsünde örnek olarak epic bazlı style rule tanımı yaptım.

Sonuca ulaşmış olduk. Tüm bu işlemlerden sonra projelerimizi, repolarımızı, ekiplerimizi tek board üzerinden yönetebiliyor, ayrı ayrı chart ve dashboardlar oluşturabiliyoruz. Hatta tüm projeleri kapsayacak chartlar ve dashboardlar da olusturabiliyoruz, raporlayabiliyoruz. Queryler üzerinden çok daha fazla özellikleri kullanabiliyoruz.

Dediğim gibi hangi seçeneği kullanacağımıza daha karar vermedik. Belki de çok farklı, kullanılabilir bir seçenek daha çıkabilir onu kullanırız. Ama en azından Azure DevOps üzerinde repolarımızı tutuyorken buranın Wiki, Artifact, Board gibi bir çok özelliğini de kullanabiliriz düşüncesindeyim.
Ayrıca eski boardumuzun planner de olması iyi avantaj. İkisi de microsoft ürünü olduğundan board üzerindeki taskları taşımamız daha rahat olur.

Ben bunları yazarken çocukların yaramazlıkları, gürültülerini duyuyorum. Sanırım bir yerleri kırıyor, dağıtıyorlar. Gitmem lazım

--

--

Hanifi Tayfur
lTunes Tribe

software developer, tech, code, ,coder, web, js,leader, dad,son, husband, life...