Değer akışı haritalarıyla işlem verimliliğini değerlendirme
Bir değer akışı eşlemesi veya VSM oluşturduğunuzda, geçerli yayın döngüsü sürecinizi analiz etmenize yardımcı olur. VSM'nin amacı, bir ekibin bu süreçte nerede değer oluşturduğunu ve nerede israf olduğunu görsel olarak göstermektir. Amaç, müşteriye minimum atıkla maksimum değer sunan bir sürece ulaşmaktır. VSM, herhangi bir değere katkıda bulunmayan veya ürünün değerini azaltan alanları saptamanıza yardımcı olabilir.
Tailspin'in nasıl ölçülmesine bakalım.
Takıma yeni katılan Mara, var olan süreci anlamasına yardımcı olmak için bir VSM oluşturacak. VSM ile ekibin DevOps olgunluk modeline nerede uyum sağlandığına ilişkin bir his edinecektir. Görünüşe göre, daha olgun takımlar genellikle daha hızlı, daha fazla güvenle ve daha az olgun takımlara göre daha az hatayla yayınlar.
Mara henüz her şeyi anlamadığını biliyor, bu yüzden toplantı odasındaki beyaz tahtada hızlı bir VSM oluşturacak. Bazı boşluklar ve cevaplanmamış sorular olacaktır, ama sorun değil. Bu bir başlangıç. Olabildiğince işi bittiğinde, bunu ekiple paylaşacak. VSM, Tailspin'in web sitelerini geliştirme ve yayınlama şeklini iyileştirmeye yönelik ilk adımları belirlemek için herkese ortak bir başlangıç noktası sağlar.
Haritaya bir göz atalım.
Geçerli işlemi anlama
Mara, VSM'sini sunmak için ekibi toplantı odasında toplar.
Mara: VSM, bir sürecin müşteriye ne kadar değere sahip olduğunu ve herhangi bir değer üretmeden zaman aşımına uğramasını ölçmemize yardımcı olur. Haritamız, yazılımın işlevsel belirtimiyle sol üst köşeden başlar. Şimdi yalnızca bir özelliği izleyerek geçerli sürüm döngümüzde nasıl hareket etti olduğunu görelim.
Bazıları gözlerini yuvarlar ama Mara bastırır.
Geliştirme süreçleri
Yeni özellik oluşturma şu anda kaynak denetiminde 
etiket oluşturma ile başlar. Etiket oluşturabilecek tek bir kişi var ve o da Andy. E-posta ile etiket talep ediyoruz. Merkezi bir sürüm denetimi sistemi kullanırız, bu nedenle Andy etiketi oluşturmadan önce mevcut kodun tümü iade edilene ve kararlı hale gelene kadar bekler. Etiket oluşturulduktan sonra çalışmaya başlayabileceğinizi belirten bir e-posta alırız. Bu işlem üç güne kadar sürer ve müşteri için hiçbir değeri yoktur. Müşteri için değeri olmayan şeyler mümkün olduğunca az zaman almalıdır.
Bir özelliği kodlamak, ihtiyacımız olan 
tüm dosyalara erişebilmemiz için bir kişi için yaklaşık dört gün sürer. Kaynak denetimine erişmek için şirket ağında olmamız gerekir. Bu sürenin müşteri için değeri vardır. Bu özelliği istiyorlar.
Test işlemleri
Kararlı bir derlemeye sahip olduğumuza karar verdikten sonra, Amita'ya test için hazır bir derleme olduğunu ve nerede bulacağımızı bildirmek için bir elektronik tabloyu güncelleştiriyoruz 
. Bildirim alması iki gün sürer.
Amita derlemesini 
el ile test ediyor. Kod tabanı büyüdükçe bu işlem uzar. Şimdilik üç gün diyelim. Ardından Andy'e hata raporlarıyla e-postalar atmış. Test değer katmaz, ancak gereklidir.
Ardından Andy'nin hataları önceliklendirmesi ve iş ataması zaman alacaktır. Andy'nin sorunları anlaması ve doğru geliştiricilere ulaşabilmesi üç gün daha sürebilir.
İşlem süreçleri
Amita bir yapıyı onayladığında, onu Tim'e devreder. Tim'in daha fazla test için bu derlemeyi üretim öncesi sunuculara dağıtması gerekiyor. Genellikle, ön üretim sunucuları web sitesini çalıştırmak için gereken en son yamalar ve güncelleştirmelerle eşitlenmez. Tim'in ön üretime dağıtılması ve bazı testleri çalıştırması yaklaşık iki gün sürer. Yine, ön üretime dağıtmak değer katmaz, ancak gereklidir 
.
Bir derleme üretime hazır olduktan sonra yönetimin dağıtılmadan önce yayını onaylaması gerekir. Onay bir toplantıda gerçekleşir. Liderlerin yayını bir araya getirmesi ve gözden geçirmesi dört gün sürer.
Sonunda Tim özelliği dağıtır ve özellik, vsm'nin sağ üst köşesinde müşteriye gönderir. Üretim sunucusu yapılandırması, ön üretimle eşitlenmemesi için kaydıysa, Tim'in önce bunu güncelleştirmesi gerekir ve bu da bir gün 
sürer.
Müşteri değeri ölçümlerini hesaplama
Artık önemli performans ölçümlerine bakabilir ve nasıl ölçüm yaptığımıza bakabiliriz.
Toplam sağlama süresi , bir özelliğin müşteriye gelmesi için geçen süredir. Burada toplam süre 22 gündür. İşlem süresi , müşteri için değerli olan bir özellik için harcanan süredir. Burada işlem süresi, kodlama için dört gün ve özelliği dağıtmak için bir gün içerir ve bu da toplam beş gün verir.
Etkinlik oranı , işlem süresinin toplam sağlama süresine bölünmesidir:
$${Etkinlik\ oranı\ =\ }{\dfrac{İşleme\ süresi}{Toplam\ sağlama\ süresi}}$$
Bu bizim verimliliğimiz. Yüzde elde etmek için verimliliği 100 ile çarpın. Sonuç %0'dan büyük ve genellikle %100'den azdır. Daha yüksek bir yüzde, verimliliğin daha yüksek olduğunu gösterir.
Numaralarımızı değiştirdiğimizde şu değerleri elde ederiz:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
Sonucu 100 ile çarparak %23 elde edersiniz.
Gördüğünüz gibi, geliştirme için çok fazla alanımız var. Bir özelliğin geliştirilmesi 22 gün sürerse çok uzundur.
Bu bize nasıl yardımcı olur?
Buradan nereye gideceğiz?
Atıkların olduğu alanları tespit edebilmemiz için şu anda nerede olduğumuzu görmemizi sağlıyor. Müşteri için hiçbir değeri olmayan harcadığımız süreyi en aza indirmek istiyoruz. DevOps yaklaşımını benimseyerek verimliliğimizi gerçekten geliştirebileceğimize inanıyorum. Bir kere, bu adımların çoğunu otomatikleştirebiliriz ve bu da zamanı kesinlikle azaltabilir.
Mevcut süreçlerimizi bırakmamızı önermiyorum, ancak şu anda mevcut olanı bozmadan küçük artışlarla daha verimli bir süreç için çalışacağımızı düşünüyorum.
Geliştirebileceğimiz birkaç alana göz atalım.
En baştan başlayabiliriz. Yeni özelliği başlatabilmemiz için koda etiket eklemem uzun sürüyor. Geliştiricilere gidip neler yaptıklarını kontrol etmelerini istemek zorundayım. Bunu nasıl hızlandırabileceğinizi bulursanız, dikkatimi çekebilirsiniz.
Ayrıca, derlemenin kendisi için orada zaman olmadığını fark ettim. Şu an yarım gün sürüyor. Zamanın gelişeceğini görmek güzel olurdu.
Amita: Geliştirme, test edilmesi gereken yeni bir derleme olduğunu bana bildirmek için elektronik tabloyu her zaman güncelleştirmez. Bu bölümün tamamlandığından emin olmak için bir yol varsa zaman kazandırır.
Mara: Harika! DevOps'un tüm bu endişelerle bize yardımcı olabileceğini düşünüyorum.
Şu anda süreci değiştirmek için vaktimiz yok. Irwin'i duydun. Burada kriz modundayız!
Anlıyorum. Şimdilik her zaman yaptığımız şeyi yapalım. Ancak hepimiz süreçteki rolümüzü ve nasıl geliştirebileceğimizi düşünebiliriz. Mevcut süreçlerimize paralel olarak küçük değişiklikler yapmaya başlayabiliriz. Ardından DevOps'un sahip olduğumuz şeyleri bozmadan bize yardımcı olup olmadığını görebiliriz. Bu haritayı ve performans ölçümlerini saklayacağım. Azure DevOps uygulamalarını benimsediğimizde sayıları yeniden ziyaret edebiliriz. Belki bir noktada VSM'yi güncelleştirebiliriz.