Azure DevOps serisinin üçüncü bölümünde, bir proje yönetim ürünü olan Azure Boards’tan bahsetmek istiyorum. Eğer serinin önceki bölümlerine göz atmak isterseniz Mert Yeter‘in yazılarına buradan ulaşabilirsiniz:
1. Azure DevOps – Bölüm 1: Azure Repos Nedir?
2. Azure DevOps – Bölüm 2: Azure Artifacts Nedir?
Azure Boards bizlere, bir yazılım projesini planlamayı, iş takibini ve yönetimini yapmayı, takım içerisindeki iş birliğini sağlamayı, hataları ve müşteri sorunlarını kayıt altında tutmayı kolaylaştıran bir arayüz sunar. Agile ve DevOps prensiplerine uygun olarak çalışabileceğimiz bir ortam sağlarken, Work Item Process seçeneği ile projemizi Basic, Agile, Scrum ve CMMI yaklaşımlarından herhangi biriyle planlama ve
yönetebilme imkânı verir. Azure Boards ile ilgili örneklere geçmeden önce kısaca bu work item süreçlerinden söz edelim.
Basic
Azure DevOps’ta yeni bir proje oluştururken work item tipi default olarak Basic’tir ve Resim – 1‘de gördüğünüz gibi üç temel kısımdan oluşur. Issue ve Task’lar işi izlemek için kullanılırken, Epic’ler daha büyük senaryolar altındaki çalışmaları gruplandırmak için kullanılır. Bunu daha açıklayıcı bir şekilde anlatmamız gerekirse, projemiz için önemli olan özellikleri veya gereksinimleri takip etmek için Epic’leri kullanabiliriz. User Story’leri, hataları veya diğer küçük iş öğelerini izlemek için Issue’ları, daha küçük miktarlardaki işleri gün ve saatleri ile izlemek için ise Task’ları kullanabiliriz.
Her work item, süreç ilerledikçe farklı durumlara (state) geçer. Bu durumlar, seçilen sürece göre farklılık gösterir. Basic’te yalnızca üç durum vardır: To Do, Doing ve Done.
Resim – 1
Agile
Agile süreci, isminden de anlaşılacağı üzere Agile ilkelerine bağlıdır. Work item’ları tanımlamak için kullanılan terminoloji ve mevcut işlevselliği bu board tipini sıklıkla tercih edilir kılıyor. Resim – 2‘de gördüğünüz gibi iş girişimlerini izlemek için Epic’leri kullanabiliriz. Belirli uygulamaları veya bir dizi işi izlemek için Feature’ları ekleyebiliriz. Takım üyelerine atayacağımız işleri takip etmek için User Story’leri ve hataları kayıt altında tutmak için Bug’ları kullanabiliriz. Son olarak, küçük miktarlardaki işlerimizi Task’lar halinde oluşturabiliriz. Ayrıca Bug’ları, User Story ve Task seviyesinde yönetebiliriz. Agile sürecinde ilerledikçe işlerimizin durumlarını New, Active, Resolved, ve Closed olarak güncelleriz.
Resim – 2
Scrum
Karmaşık yazılım süreçlerinin yönetimi için tercih edilen Scrum, projeyi planlamak ve izlemek için aşağıdaki objeleri destekler. Product Backlog Item ve Task’ları, çalışmayı takip etmek için kullanabilir, Bug’lar ile kod hatalarını izleyebiliriz. Epic’ler ve Feature’lar ile çalışmamızı daha büyük senaryolar altında gruplandırabiliriz. Scrum sürecinde işlerimizin durumlarını New, Approved, Committed ve Done olarak güncelleriz.
Resim – 3
CMMI (Capability Maturity Model Integration)
Dilerseniz, Azure DevOps ile CMMI süreçlerini de yönetebilirsiniz. Epic’ler teslim edilecek projenin en üst düzeyidir ve bir Epic birden fazla Feature içerebilir. Bu iki objeyi, çalışmamızı büyük senaryolar altında gruplandırmak için kullanabiliriz. Requirement’lar ile proje ihtiyaçlarını nasıl karşılayacağımızı belirler, Task’lar ile bağlı olduğu Requirement’a ait çalışmaları birden fazla parçaya bölebiliriz. CMMI sürecinde işlerimizin durumlarını Proposed, Active, Resolved ve Closed olarak belirleriz.
Resim – 4
Azure Boards’ın ne için kullanıldığına ve work item’lara değindikten sonra demo’ya geçebiliriz. 😊
Demo’ya Azure DevOps üzerinde yeni bir proje oluşturarak başlayalım. Resim – 5′te gördüğünüz üzere projeyi oluşturma aşamasında bir proje ismi, projenin görünebilirliğini, hangi versiyon kontrol sistemini kullanacağımızı ve yukarıda bahsettiğim work item süreçlerinden birini seçtikten sonra Create Project‘e tıklayarak projemizi oluşturalım. Ben bu örnekte work item process olarak Scrum‘ı seçtim.
Resim – 5
Projemiz oluştuktan sonra bizi aşağıdaki sayfa karşılıyor. Burada Project Settings‘e tıklayarak ayarlar sayfasına gidelim.
Resim – 6
Proje ayarları sayfasında Teams‘i seçelim. Aşağıda gördüğümüz üzere default olarak bir proje takımımız var. Biz New Team‘e tıklayarak yeni bir takım oluşturalım.
Resim – 7
Yeni takımımıza bir isim vererek Create butonuna tıklayalım.
Resim – 8
Yine Teams sayfasında yeni oluşturduğumuz takıma tıklayalım.
Resim – 9
Şu an takım içerisinde default olarak sadece admin’i görüyoruz. Dilerseniz bu ekranda yeni takım üyeleri ekleyebilir, notification’ları ve dashboard’ları yönetebilirsiniz. Takım içerisinde yapılacak işler, iteration ya da sprint adı verilen düzenli çalışma aralıklarında planlanır ve takip edilir. Bunu yapabilmek için mshowto-web içerisinde Iterations and Area Paths‘e tıklayalım.
Resim – 10
Karşımıza çıkan sayfada Iterations‘a gelelim ve sprint’lerimizi oluşturmak için Select Iteration(s)‘a tıklayalım.
Resim – 11
Karşımıza gelen ekranda Sprint 1’i seçelim ve Save and Close‘a tıklayalım. Bu örneğimizde üç sprint oluşturacağız.
Resim – 12
Yukarıdaki işlemi tekrarlayarak Sprint 2 ve Sprint 3’ü oluşturduktan sonra aşağıda gördüğünüz gibi Edit ile sprintlerimize bir başlangıç ve bitiş tarihi verebiliriz.
Resim – 13
Resim – 14
Resim – 15′te gördüğünüz gibi üç haftalık sprintler oluşturduk. Bu örneğimizde Sprint 1’i geçmiş sprint, Sprint 3’ü gelecek sprint olarak düşünelim. Demo’nun ilerleyen adımlarında güncel olarak Sprint 2 üzerinde çalışacağız.
Resim – 15
Son olarak Resim – 11′de göreceğiniz Areas sekmesine gidelim. Include sub areas‘a tıklayarak takımın tüm sub-area’lara erişebilecek şekilde ayarlayalım. Bu, herhangi bir takımın backlog’unda görünen tüm work item’ların, bizim takımızın backlog’unda da görüneceği anlamına geliyor.
Resim – 16
Takımımızın programını ve kapsamını tanımladıktan sonra Azure Board’da work item’lar ile çalışmaya başlayabiliriz. 😊
Demo’nun en başında projemiz için work item process’i Scrum olarak belirlemiştik. Şimdi Azure Board’a giderek Scrum sürecini uygulayalım. Azure DevOps ekranında Boards -> Work Items‘a gidelim. Öncelikle yeni bir Epic ekleyeceğiz. Azure DevOps’ta work item eklemenin birden fazla yolu bulunuyor. Biz Work Items sayfasında New Work Item diyerek Epic’i seçelim.
Resim – 17
Karşımıza gelen ekranda Epic ismini Web Page Improvements olarak güncelleyelim ve Epic’i kendimize atayalım. Daha sonra Area kısmını mshowto\mshowto-web ve Iteration kısmını ise üzerinde çalışacağımız sprint olan mshowto\Sprint 2 olarak belirledikten sonra Save‘e tıklayalım.
Bu ekranda dilerseniz work item için bir Description yazabilir, Discussion alanında takım arkadaşlarınızı etiketleyerek bir tartışma başlatabilirsiniz.
Resim – 18
Şimdi, bu Epic’e bağlı olarak yeni bir Feature ekleyelim. Yine aynı sayfada Related Work -> Add Link‘e tıklayarak New Item‘ı seçelim.
Resim – 19
Karşımıza gelen ekranda Link type alanını Child, Work item type alanını Feature olarak belirleyelim ve bu yeni Feature’ı Web Page Improvements – Phase 1 olarak isimlendirelim. Zorunlu olmamakla beraber bu adımda bir comment de yazabiliriz.
Resim – 20
İlgili alanları doldurduktan sonra OK‘a tıkladığımızda karşımıza oluşturduğumuz Feature’a ait form sayfası geliyor (Resim – 21). Burada atanan kişi, Area ve Iteration alanlarının bağlı olduğu Epic ile aynı olmasına dikkat etmeliyiz. Daha sonra Save & Close‘a tıklayalım.
Resim – 21
Bir sonraki adımımız oluşturduğumuz Feature’a bağlı olarak bir Product Backlog Item (PBI) eklemek olacak. Yeni work item’ı bu defa başka bir yol ile eklemeyi deneyelim.
Sol ana menüde Boards -> My team boards‘a gelip mshowto-web boards‘ı seçelim.
Resim – 22
Burada projemize ait work item’ların tamamlanma durumuna göre nerede olduklarını bize gösteren Kanban board’ı görüyoruz. Resim – 23′te gördüğünüz üzere sağ taraftaki dropdown’da istediğimiz work item’ı seçerek süreçleri takip edebiliriz. Work item’ların durumlarını, onlara ait formu açarak güncelleyebileceğimiz gibi bu item’ları board üzerinde sürükleyerek kolayca değiştirebiliriz.
Bu kısa bilgiden sonra sağdaki dropdown’da Features’ı seçelim.
Resim – 23
İlgili Feature’a ait dropdown’a tıklayarak Add Product Backlog Item‘ı seçelim ve PBI’lardan birini Web Page UI Changes, diğerini de New Login Page olarak isimlendirelim.
Resim – 24
Resim – 25′te gördüğünüz gibi Web Page UI Changes ve New Login Page adında iki tane PBI oluşturduk. Şimdi, bu PBI’lar içinde küçük Task’lar oluşturmak istiyorum. Öncelikle Web Page UI Changes’e tıklayarak bu PBI’ın form sayfasına gidelim.
Resim – 25
Burada daha önce Feature oluşturduğumuz yöntemi izleyerek Task ekleyeceğiz. Tek farkı, work item tipini Task olarak seçeceğiz.
Resim – 26
Change Background Color ve Change Page Layout adında iki adet task oluşturalım. Yine Related Work alanında oluşturduğumuz Task’ları görebilmekteyiz (Resim – 27). Aynı şekilde bu task’lardan birine giderek formu inceleyelim.
Resim – 27
Benzer şekilde bu Task’ı bir ekip arkadaşımıza atayabilir, Task için bir Description yazabilir, Discussion alanında ilgili kişileri etiketleyerek bir tartışma başlatabiliriz. Remaining Work alanında Task için bir süre tanımlayabiliriz. Ayrıca bu bir UI değişikliği olduğu için Task’ımıza UI Changes isminde bir etiket verebiliriz.
Resim – 28
Azure DevOps serisinin 3. Bölümünde Azure Boards nedir ve work item tipleriyle nasıl çalışabiliriz sorularına yanıt vermeye çalıştım. Bir sonraki bölümde Azure Pipelines ile devam edeceğiz.
Faydalı olması dileğiyle. 😊
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
https://docs.microsoft.com/en-us/azure/devops/boards/sprints/scrum-overview?view=azure-devops
